Probabil ai în casă o cutie de aspirină undeva prin dulăpior. Toată lumea are. E cel mai banal medicament cu putință - îl iei când te doare capul, când ai febră, sau când simți că răceala pune stăpânire pe tine. Și totuși, cercetătorii ajung din ce în ce mai mult la concluzia că această pastilă ieftină și banală ar putea fi, în anumite situații, un instrument eficient împotriva cancerului.

Articolul publicat de BBC Future adună la un loc o serie de studii clinice serioase care arată că aspirina poate reduce riscul apariției și răspândirii anumitor tipuri de cancer și că oamenii de știință încep, în sfârșit, să înțeleagă de ce se întâmplă asta.

De unde a început totul

Povestea lui Nick James e un bun punct de plecare. E un tâmplar britanic de vreo 45 de ani care a decis să facă un test genetic după ce mama lui a murit de cancer și mai mulți membri ai familiei au dezvoltat cancer de intestin. Testul a arătat că poartă o mutație genetică specifică, asociată cu o afecțiune numită Lynch Syndrome - o condiție ereditară care crește dramatic riscul de a face cancer colorectal. Cam 80% dintre purtătorii acestei mutații dezvoltă boala la un moment dat în viață.

James a ajuns să fie primul participant dintr-un studiu clinic care testa dacă o doză zilnică de aspirină ar putea oferi protecție. Asta s-a întâmplat acum 10 ani. Și până acum nu a dezvoltat cancer. „A luat aspirină cu noi timp de 10 ani și nu a făcut niciun cancer până acum," spune John Burn, profesor de genetică clinică la Universitatea Newcastle, care a condus studiul.

Desigur, un singur om nu demonstrează nimic. Dar studiul lui Burn, publicat în 2020, a urmărit 861 de pacienți cu Lynch Syndrome pe parcursul a 10 ani și a concluzionat că cei care au luat zilnic 600 mg de aspirină timp de cel puțin doi ani și-au înjumătățit practic riscul de cancer colorectal. Un al doilea studiu al aceluiași grup, e în curs de evaluare de către specialiști din domeniu, sugerează că doze mult mai mici - între 75 și 100 mg pe zi - ar putea fi la fel de eficiente, dacă nu chiar mai mult.

Cum a intrat aspirina pe radarul cercetătorilor de cancer

Interesul serios pentru aspirină ca potențial agent anticancer a prins contur în 2010, când Peter Rothwell, profesor de neurologie clinică la Universitatea din Oxford, a reexaminat datele din studiile cardiovasculare mari în care aspirina era deja folosită pe scară largă. Ce a observat a fost surprinzător: participanții care luaseră aspirină aveau rate mai mici atât de apariție, cât și de răspândire a cancerului. Nu era efectul principal al studiilor respective, dar datele erau acolo.

De atunci, o serie de studii clinice au consolidat această observație. Unul dintre cele mai recente și mai spectaculoase a venit de la Institutul Karolinska din Suedia, unde profesoara de chirurgie Anna Martling a urmărit aproape 3.000 de pacienți cu cancer de intestin. Studiul ei, publicat în septembrie 2025, a arătat că pacienții cu anumite mutații specifice ale tumorii care luau zilnic 160 mg de aspirină după operație aveau mai puțin de jumătate din riscul de recidivă față de cei care luau placebo. Rezultatele au schimbat rapid practica medicală: din ianuarie 2026, Suedia a început să testeze sistematic pacienții cu cancer de intestin pentru aceste mutații și să le ofere aspirină în doze mici celor care le au.

De ce funcționează - mecanismele din spatele efectului

Asta e poate cea mai interesantă parte. Timp îndelungat, nimeni nu știa cu adevărat de ce aspirina ar putea ajuta împotriva cancerului. Acum încep să apară răspunsuri.

Un prim mecanism ține de sistemul imunitar. Rahul Roychoudhuri, imunolog la Cambridge, a identificat faptul că aspirina blochează un factor de coagulare care în mod normal suprimă capacitatea sistemului imunitar de a detecta și distruge celulele canceroase. Practic, trombocitele - celulele implicate în coagularea sângelui - eliberează o substanță care acționează ca un fel de frână pentru limfocitele T, celulele „forțelor speciale" ale sistemului imunitar. Când aspirina inhibă trombocitele, frâna dispare, iar limfocitele T pot urmări și ataca mai eficient celulele tumorale care încearcă să se răspândească în organism. Un studiu publicat în Nature în 2025 a arătat că în experimente pe animale, acest mecanism a redus semnificativ metastazele.

Există și un al doilea mecanism, care ține de genetica tumorilor. Studiul de la Karolinska a identificat că aspirina este deosebit de eficientă la pacienții cu mutații ale genei PI3K - mutații care apar frecvent în cancerele colorectale, dar și în alte tipuri de cancer. Aspirina pare să selecteze împotriva celulelor cu aceste mutații, frânând evoluția tumorii. Asta explică de ce nu toți pacienții răspund la fel, efectul e mult mai pronunțat la anumite profiluri genetice.

Această logică a mutat discuția dinspre „aspirina ca medicament general" spre o abordare de tip medicină de precizie: nu toată lumea ar beneficia de ea, dar la persoanele cu anumite mutații, ar putea face o diferență reală.

Ce se întâmplă acum

Ruth Langley, de la University College London, conduce în prezent cel mai mare studiu de acest fel de până acum - un studiu clinic controlat cu 11.000 de participanți din Marea Britanie, Irlanda și India, care au avut cancer colorectal, de sân, gastroesofagian sau de prostată. Studiul testează doze zilnice de 100 mg și 300 mg de aspirină, iar rezultatele sunt așteptate anul viitor.

Suntem cu adevărat primii care explorăm rolul aspirinei în alte tipuri de tumori, spune Langley

Dacă rezultatele confirmă ce s-a văzut deja la cancerul colorectal, ar putea deschide o perspectivă complet nouă pentru un medicament care există de peste un secol și costă câțiva lei.

Atenție - nu înseamnă că ar trebui să înghiți aspirină pe cont propriu

Toate astea sunt vești interesante, dar există o avertizare importantă pe care cercetătorii o subliniază constant: aspirina nu e inofensivă. Poate provoca sângerări interne, ulcere gastrice și, în cazuri rare, hemoragii cerebrale. La persoanele fără factori de risc specifici, beneficiile nu justifică riscurile. Decizia de a lua aspirină regulat trebuie luată împreună cu un medic, mai ales dacă există factori de risc genetic sau antecedente oncologice în familie.

Ideea nu e că toată lumea ar trebui să ia aspirină ca măsură de precauție, ci că pentru anumite grupuri - cei cu Lynch Syndrome, cei cu mutații PI3K în tumori colorectale, poate în viitor și alte categorii - aspirina ar putea deveni o componentă serioasă a tratamentului sau a prevenției. Și asta, la prețul unui medicament pe care oricum îl ai acasă, e ceva care merită urmărit cu atenție.

Am mai petrecut câteva ore astăzi lucrând la Pure Blog Discover și sunt câteva lucruri noi.

Cel mai important lucru adăugat este suportul pentru feed-uri RSS. Atunci când cineva adaugă un jurnal în director, sistemul încearcă automat să detecteze feed-ul RSS al jurnalului respectiv - fie căutând tag-ul <link rel="alternate" type="application/rss+xml"> în codul paginii, fie încercând câteva căi comune ca /feed, /feed.xml sau /feed.php. Dacă îl găsește, iconița portocalie de RSS apare în colțul din dreapta jos al cardului și poți da click direct pe ea ca să te abonezi.

Pentru jurnalele deja existente în listă am adăugat manual link-urile spre feed-urile lor, deci iconița ar trebui să apară la aproape toate.

Tot azi am adăugat trei feed-uri și pentru situl în sine - dacă vrei să urmărești când se mai adaugă jurnale noi în director, poți să te abonezi la RSS, Atom sau JSON Feed. Iconițele pentru ele sunt vizibile în header, lângă numărul de jurnale listate.

Un alt lucru util este butonul de export OPML, pe care îl găsești lângă bara de căutare. Dacă folosești un cititor RSS și vrei să te abonezi dintr-o dată la toate jurnalele din director care au feed detectat, descarci fișierul OPML și îl imporți direct - în Newsflash, Miniflux, NetNewsWire sau orice alt cititor care suportă formatul.

Pe lângă astea, am mai rezolvat câteva probleme mai mici: bara de căutare nu funcționa din cauza unui scope issue în JavaScript - funcția era definită într-un IIFE și nu era accesibilă global, exact același tip de problemă pe care o avusesem anterior cu paginarea. Am mai corectat și câteva locuri unde scrisesem greșit numele platformei ca PureBlog în loc de Pure Blog.

De ceva vreme folosesc Pure Blog pentru jurnalul meu și, cu cât am descoperit mai mulți oameni care fac același lucru, cu atât mi-am dat seama că nu există niciun loc unde să le poți găsi pe toate la un loc. Câteva jurnale interesante le-am dat peste ele întâmplător, altele mi-au fost recomandate de alții, dar nu era nimic centralizat.

Așa că am decis să construiesc eu unul.

Proiectul se numește Pure Blog Discover și ideea e simplă: dacă ai un jurnal construit pe Pure Blog, îl poți adăuga în listă, iar vizitatorii pot descoperi jurnale noi pe care altfel nu le-ar fi găsit niciodată. Nu e nimic complicat din perspectiva utilizatorului - introduci adresa jurnalului, îi dai un nume, apeși un buton și sistemul verifică automat dacă jurnalul folosește platforma Pure Blog. Dacă da, jurnalul apare imediat în listă, fără nicio aprobare manuală din partea mea.

Cum funcționează verificarea automată

Partea care m-a preocupat cel mai mult a fost tocmai detecția automată, pentru că nu toți oamenii care folosesc Pure Blog au un jurnal identic cu cel implicit - mulți l-au personalizat destul de mult și nu mai rămân semne evidente că platforma de bază este Pure Blog.

Am ajuns la un sistem bazat pe punctaj: serverul descarcă pagina jurnalului trimis și caută o serie de semnale specifice platformei. Dacă găsește string-ul pure blog direct în cod, înseamnă că jurnalul nu a fost modificat radical și primește imediat punctajul maxim. Dacă jurnalul e mai personalizat, sistemul caută alte lucruri mai subtile - variabile CSS specifice temei Pure Blog, tag-ul meta generator cu valoarea Jekyll, structura HTML caracteristică și alte câteva semne mai mici. Fiecare semnal adaugă puncte și, dacă suma depășește un anumit prag, jurnalul e aprobat.

Există și situații în care detecția eșuează - de obicei când cineva a modificat atât de mult tema încât nu a mai rămas nimic recognoscibil. În cazul acesta, mesajul de eroare îți explică că poți adăuga tag-ul <meta name="generator" content="Pure Blog"> în template și să încerci din nou, sau să mă contactezi direct la discover@thinkroot.xyz și adaug eu jurnalul manual.

Ce am folosit ca să îl construiesc

Proiectul e construit complet din PHP și JavaScript obișnuit, fără niciun framework și fără nicio bază de date - datele se salvează în fișiere JSON simple. Am ales în mod intenționat această abordare pentru că voiam ceva care să meargă pe orice hosting shared fără dependențe speciale, iar complexitatea unui server dedicat sau a unei baze de date relaționale n-ar fi adus niciun beneficiu real pentru genul acesta de proiect.

Codul sursă e disponibil public pe depozitul de pe Forgejo sub licența MIT, deci dacă vrei să îl instalezi și tu pe domeniul tău, sau vrei să contribui cu ceva, ușa e deschisă.

Am construit și un panou de administrare protejat cu parolă, de unde pot adăuga sau elimina jurnale, pot edita informațiile și pot vedea statistici simple legate de câte jurnale sunt listate pe fiecare limbă. Lista suportă și paginare, câte 20 de jurnale pe pagină, și există o bară de căutare pentru a găsi rapid un jurnal după nume sau adresă.

Un lucru care m-a surprins plăcut

Am construit proiectul cu ajutorul Claude, ceea ce a fost o experiență interesantă în sine - nu în sensul că am stat să accept cod generat automat fără să înțeleg ce face, ci mai degrabă că am putut să iterez foarte rapid, să discut fiecare decizie tehnică și să ajungem împreună la soluții pe care poate nu le-aș fi gândit singur atât de repede. Securitatea, de exemplu - protecția împotriva SSRF, tokenurile CSRF, honeypot-ul pentru boți - toate astea au fost gândite și implementate în mod deliberat, nu adăugate la urmă ca un gând.

Dacă ai un jurnal pe Pure Blog și vrei să îl adaugi în director, procesul durează mai puțin de un minut.

Dacă folosești Bitwarden CLI în vreo automatizare de pe server, ar fi bine să citești ce s-a întâmplat ieri.

Versiunea 2026.4.0 a pachetului @bitwarden/cli publicată pe npm a fost compromisă ca parte dintr-un atac supply chain mai amplu, descoperit de cercetătorii de la Socket în timp ce monitorizau o campanie activă legată de Checkmarx. Practic, cineva a reușit să injecteze cod malițios direct în fișierul bw1.js din cadrul pachetului, înainte ca acesta să fie publicat oficial pe npm, iar utilizatorii care l-au descărcat în acea perioadă au primit deja versiunea infectată fără să știe.

Modul în care s-a întâmplat asta e destul de îngrijorător: atacatorii ar fi exploatat un GitHub Actions workflow din pipeline-ul CI/CD al Bitwarden, adică au intervenit direct în momentul în care se construia și publica pachetul, nu în codul sursă în sine. Exact aceeași tehnică a fost documentată anterior în campania Checkmarx, unde atacatorii furau credențiale, modificau workflow-uri și extrăgeau secrete din depozite, după care republicau pachete npm compromise ca să se răspândească mai departe.

Vestea mai bună e că perioada a fost destul de scurtă. Bitwarden a confirmat că pachetul malițios a fost disponibil pe npm între 17:57 și 19:30 (ora EST) pe 22 aprilie, deci cam o oră și jumătate. Dacă nu ai descărcat pachetul exact în intervalul ăla, cel mai probabil nu ești afectat. Compania a revocat accesul compromis, a depreciat versiunea pe npm și a pornit imediat investigația. Spun că nu există dovezi că parolele și datele salvate în Bitwarden ar fi fost accesate sau că sistemele de producție au fost atinse - problema a vizat strict doar modul în care pachetul ajungea la tine prin npm, nu codul sursă sau datele stocate.

Ce face toată situația mai serioasă e contextul mai larg al campaniei Checkmarx, descoperită împreună cu Docker și Socket. Payload-ul folosit în campanie colecta tokeni GitHub, credențiale cloud (AWS, Azure, Google Cloud), tokeni npm, chei SSH și variabile de mediu din mediile de dezvoltare. Și mai rău, se comporta aproape ca un vierme - folosea tokenii furați ca să injecteze automat workflow-uri malițioase în alte depozite accesibile, extinzând atacul mai departe în lanțul de distribuție software. Nu s-a confirmat încă dacă și compromiterea Bitwarden include exact același payload, dar faptul că s-a folosit exact aceeași metodă prin GitHub Actions lasă să se înțeleagă că e vorba de aceiași oameni.

Dacă ai folosit Bitwarden CLI în scripturi automate în ultimele zile, merită să verifici că nu ai versiunea 2026.4.0 instalată și să te uiți prin log-urile de CI/CD după activitate neobișnuită. Iar dacă există vreo șansă că pipeline-urile tale au rulat cu versiunea respectivă, cel mai bine ar fi să schimbi toate parolele și tokenii care ar fi putut fi expuși.

Supply chain attacks sunt periculoase tocmai pentru că lovesc în locul în care avem cel mai mult încredere - în uneltele pe care le folosim zilnic și în procesele automate pe care le-am construit. Bitwarden a reacționat repede și transparent, ceea ce e de apreciat, dar cazul acesta e un semnal clar că nici ecosistemul open source nu e imun la astfel de atacuri.

Dacă folosești Linux Mint de ceva vreme, probabil ai observat că screenshot-urile sunt salvate automat în ~/Imagini/ - sau într-un director similar, în funcție de limba sistemului. Pentru cei mai mulți utilizatori este suficient, dar dacă vrei să organizezi fișierele altfel sau să îndrepți capturile spre un director specific, schimbarea nu este complicată deloc.

Aplicația de screenshot implicită în Linux Mint este gnome-screenshot, care se integrează bine cu mediul Cinnamon și se activează automat la apăsarea tastei Print Screen. Configurația sa, inclusiv directorul de salvare, este stocată în sistemul gsettings - un strat de configurare bazat pe GSettings și dconf, utilizat de aplicațiile din ecosistemul GNOME.

Tot ce trebuie să faci este să deschizi un terminal și să rulezi:

gsettings set org.gnome.gnome-screenshot auto-save-directory 'file:///home/utilizator/Directorul/Tau'

Înlocuiește calea cu cea dorită, asigurându-te că directorul există deja pe disc. Dacă nu există, îl poți crea rapid cu:

mkdir -p ~/Directorul/Tau

De exemplu, pe sistemul meu comanda arată astfel:

gsettings set org.gnome.gnome-screenshot auto-save-directory 'file:///home/thinkhome/Imagini/Captură de ecran'

Caracterele speciale românești (ă, î, â, ș, ț) și spațiile din numele de directoare funcționează fără probleme în ghilimele simple, deci nu este nevoie de niciun escape special.

Poți confirma că modificarea a fost aplicată corect cu:

gsettings get org.gnome.gnome-screenshot auto-save-directory

Ar trebui să returneze exact calea pe care ai setat-o. Din acel moment, orice captură de ecran realizată cu tasta Print Screen va fi salvată automat în directorul respectiv, fără niciun dialog intermediar.

Este unul din acele lucruri mici care fac experiența cu Linux mai plăcută - câteva secunde de configurare și nu mai trebuie să te gândești la unde ajung capturile de ecran.

De ceva vreme mă tot gândeam că thinkroot.xyz arată prea auster. Nu era nimic greșit în mod particular, dar ori de câte ori îl deschideam îmi dădea senzaia unui document tehnic mai degrabă decât a unui loc în care scriu cu plăcere despre lucruri care mă interesează. Fundalul era alb-gri, textul era negru, linkurile erau albastre - clasicul web din anii 2000 fără nicio personalitate.

Așa că m-am apucat să schimb câte ceva.

Primul lucru care s-a schimbat a fost fontul

Juralul folosea JetBrains Mono pentru absolut tot - și titluri, și navigație, și textul articolelor. JetBrains Mono e un font excelent pentru cod, dar pentru paragrafe lungi pe care le citești de plăcere nu e tocmai ideal. Literele au toate aceeași lățime, ceea ce face textul mai greu de parcurs când ai de citit mai mult de câteva rânduri.

Am trecut textul articolelor pe Figtree, un font proporțional, rotunjit, cu un caracter mai prietenos. JetBrains Mono a rămas pentru titluri, navigație, cod și toate elementele de interfață - acolo chiar se potrivește. Combinația dintre cele două mi se pare că funcționează bine, există un contrast clar între structura paginii și conținutul propriu-zis.

Apoi au venit culorile

Paleta veche era negru, gri și albastru. Funcțională, dar rece. Am înlocuit-o cu ceva mai cald - fundal crem, text maro-închis, accente portocaliu-terracotta. Genul de culori care îți dau senzația că citești ceva pe hârtie, nu pe un ecran de birou.

Fundalul nu e o culoare plată, ci un gradient subtil care trece prin câteva nuanțe de crem și bej. Nu e ceva care să sară în ochi, dar face pagina să pară mai puțin rigidă decât un fundal uniform.

Dark mode-ul a primit același tratament - tonuri de espresso și maro închis în loc de negrul standard, cu accente portocalii care se potrivesc cu paleta din light mode.

Câteva efecte care fac navigarea mai plăcută

Pe lângă culori și fonturi, am adăugat și câteva lucruri mici care nu sunt vizibile imediat dar se simt când folosești jurnalul. Titlul din header are un gradient care trece din maro în portocaliu. Linkurile din articole au un underline animat care apare de la stânga la dreapta când treci cu mouse-ul. Articolele de pe pagina principală se evidențiază ușor la hover pe desktop și la tap pe telefon. Bara de progres din partea de sus a paginii îți arată cât ai citit dintr-un articol.

Nimic spectaculos, dar împreună dau senzația că jurnalul e viu, nu static.

N-a mers totul din prima

Cel mai mare necaz a fost cu Safari. La un moment dat textul devenea aproape invizibil pentru că fontul nu se încărca și culorile nu se aplicau corect. Am rezolvat problema treptat, testând pe mai multe navigatoare și ajustând CSS-ul până când a arătat bine peste tot.

Brave pe iOS a dat și el bătăi de cap, dar s-a dovedit că era vorba de setările navigatorului, nu de codul meu - Shields-ul lui Brave bloca fonturile de la Google.

La final

Nu am făcut o schimbare dramatică - structura și logica jurnalului sunt exact la fel ca înainte. Dar acum când îl deschid îmi dă o senzație mai bună, ceea ce cred că e suficient ca să merite efortul. Un jurnal pe care îl deschizi cu plăcere e unul la care îți vine și să scrii mai des.

Se pare că avem câțiva români care au pus mâna pe treabă și lucrează la propriile distribuții Linux, ceea ce este un lucru cu adevărat îmbucurător. Nu este ușor să construiești o distribuție de la zero sau chiar pornind de la una deja existentă, pentru că implică timp, răbdare și destul de multă muncă în spate pe care utilizatorul obișnuit nu o vede. Două dintre aceste proiecte aflate în dezvoltare se numesc Danubix (din păcate nu există niciun depozit online) și RetroLinux, și îi felicit pe dezvoltatori pentru curajul de a se apuca de un astfel de proiect.

Acum, că am spus asta, am și ceva de criticat - nu în mod răutăcios, ci constructiv, pentru că mi se pare important să fie spus.

Problema pe care o am cu ambele distribuții este tema vizuală aleasă de dezvoltatori. Danubix folosește un verde aprins pe fond aproape negru, totul plecând de la ecranul de autentificare și continuând în terminal și în mediul desktop. RetroLinux merge pe un roz-violet, cu un aspect retro-nostalgic specific anilor '80. Nu spun că aceste culori sunt urâte în sine, dar când o singură culoare domină absolut tot ce vezi pe ecran, devine obositor după o vreme.

O temă bună nu înseamnă să alegi o culoare care îți place și să o aplici peste tot. Înseamnă să combini mai multe culori, să ai tonuri calde și neutre care să nu forțeze ochiul, care să lase conținutul să respire. Când stai ore întregi în fața ecranului - fie că scrii cod, citești documentație sau administrezi un server - ultimul lucru de care ai nevoie este o paletă de culori agresivă care să îți obosească vederea.

Și nu este o problemă exclusivă a distribuțiilor românești. Dacă mă gândesc la distribuțiile Linux în general, niciuna nu vine din cutie cu o temă cu adevărat plăcută ochiului. Fie că sunt prea albe, fie că prea cenușii, fie că sunt prea negre, fie că au culori stridente ca să pară „moderne„ sau „distincte". Nu înțeleg de unde vine această modă și de ce nimeni nu încearcă să aducă ceva mai echilibrat. Nici în comunitatea de teme pentru Linux lucrurile nu stau mult mai bine - temele plăcute, cu o paletă de culori caldă și neutră, sunt rare și greu de găsit.

Poate că tocmai de aceea cei de la Danubix și RetroLinux au ales să meargă pe un accent cromatic puternic - ca să iasă în evidență, să aibă o identitate vizuală clară. Îi înțeleg, dar tot cred că există o cale de mijloc între „gri și plictisitor„ și „o singură culoare care țipă pe tot ecranul".

Sper ca, pe măsură ce aceste distribuții evoluează, să vedem și o maturizare a laturii vizuale. Fondul tehnic există și se vede că există implicare - Danubix vine deja cu un toolkit de securitate integrat, iar RetroLinux pare să aibă un sistem propriu de gestionare a configurațiilor. Acum ar fi momentul potrivit să se lucreze și la o temă mai prietenoasă cu ochii utilizatorului care o va folosi zilnic.

Acum câteva zile scriam despre cum HDD-ul extern atașat la Intel NUC se demonta noaptea din cauza USB autosuspend - nucleul punea adaptorul JMicron JMS578 în sleep după câteva secunde de inactivitate, iar când încerca să scrie pe el, primea device offline error și demonta partiția de urgență. Am dezactivat autosuspend-ul printr-o regulă udev, am adăugat nofail în fstab și am crezut că am închis subiectul.

Azi dimineață, la 6:46, același scenariu. A treia oară în trei săptămâni.

Ce spuneau jurnalele de data aceasta

Primul lucru pe care l-am verificat a fost dacă regula udev era activă și dacă JMicron-ul avea power/control setat la on. Discul apărea în lsblk ca sdd, ceea ce confirma că se reconectase singur după demontat, iar fstab folosea UUID, nu device name - deci nu era nici problema cu schimbarea numelui. Pur și simplu nu era montat.

Am rulat sudo journalctl -b | grep -E "mnt-data|sdd|mount" și am găsit ceva ce nu observasem înainte. La momentul exact al demontării, în jurnal apăreau mesaje de genul acesta:

sdd: Failed to create/update device symlink ... ignoring: Inappropriate ioctl for device

Discul se deconecta și reconecta instantaneu - un reset cycle complet al adaptorului - iar udev nu reușea să creeze symlink-urile din /dev/disk/by-id/ pentru că adaptorul nu răspundea corect la anumite comenzi SCSI. Asta era un semnal clar că problema nu era la nivelul power management-ului, ci la nivelul driverului cu care nucleul comunica cu adaptorul.

UAS - driverul care creează probleme pe adaptoare ieftine

Kernelul Linux suportă două moduri de comunicare cu dispozitivele de stocare USB: BOT (Bulk-Only Transport), care e protocolul clasic și simplu, și UAS (USB Attached SCSI), introdus pentru performanță mai bună prin paralelizarea comenzilor SCSI și reducerea latency-ului. Pe hârtie, UAS e superior. În practică, multe adaptoare USB-SATA ieftine - inclusiv cele cu chipset JMicron JMS578 - au implementări firmware defectuoase ale UAS care duc la comportamente imprevizibile: reset cycles, erori de I/O sau, cum era cazul meu, demontări bruște.

Am verificat cu sudo dmesg | grep -i uas și răspunsul a fost imediat:

scsi host3: uas
scsi host2: uas
scsi host4: uas

Trei instanțe, câte una pentru fiecare reconectare a adaptorului din ultimele săptămâni. Nucleul detecta JMicron-ul, alegea UAS ca driver, pentru că adaptorul declara suport pentru el, și la un moment dat, în mod regulat, driverul intra în conflict cu firmware-ul adaptorului și provoca un reset.

Soluția: forțarea fallback-ului pe usb-storage

Linux are un mecanism de quirks prin care poți instrui kernelul să trateze anumite dispozitive diferit față de cum le-ar trata în mod normal, identificate prin idVendor și idProduct. Pentru a dezactiva UAS pe JMicron JMS578 și a forța folosirea driverului usb-storage (BOT), am creat un fișier de configurare:

sudo nano /etc/modprobe.d/usb-storage-quirks.conf

Cu conținutul:

options usb-storage quirks=152d:0578:u

Flag-ul u din lista de quirks înseamnă exact NO_UAS - nucleul va ignora faptul că adaptorul declară suport pentru UAS și va folosi în schimb usb-storage. Valorile 152d:0578 sunt idVendor:idProduct ale adaptorului, obținute cu lsusb.

Pentru ca modificarea să fie inclusă în initramfs și să se aplice la boot, înainte ca kernelul să încarce driverele USB, am rulat:

sudo update-initramfs -u
sudo reboot

După repornire, sudo dmesg | grep -E "uas|usb-storage|152d" a confirmat că totul funcționează corect:

usb 2-4: UAS is ignored for this device, using usb-storage instead
usb-storage 2-4:1.0: Quirks match for vid 152d pid 0578: 1800000

Ce am înțeles greșit în primul rând

Articolul anterior nu era complet greșit - USB autosuspend poate provoca exact aceleași simptome pe același tip de adaptor și rămâne o problemă reală pe sisteme unde discul stă inactiv ore întregi. Regula udev pentru power/control=on e în continuare validă ca măsură de precauție.

Dar cauza principală a reseturilor era UAS, nu autosuspend-ul. Cele două probleme pot coexista și se pot masca reciproc, mai ales că simptomele sunt aproape identice: device offline error, demontat brusc, reconectare imediată cu alt device name. Diferența e că autosuspend intra în acțiune după perioade lungi de inactivitate, în timp ce UAS putea provoca reset-ul și în mijlocul unei operații de scriere, ceea ce explica de ce problema persista chiar și după ce dezactivasem autosuspend-ul.

Dacă folosești un adaptor USB-SATA bazat pe JMicron JMS578 sau orice alt adaptor ieftin și ai probleme similare de stabilitate, primul lucru pe care ar trebui să-l verifici este dacă nucleul folosește UAS. Dacă da, dezactivarea lui prin quirks e simplă și din experiența mea rezolvă problema definitiv.

Dacă mă urmărești de ceva vreme pe jurnal, știi deja că am tot redus lista de servicii și platforme pe care le folosesc, mai ales pe cele ale companiilor mari care tratează utilizatorul ca pe un produs. Am scris deja cum am început să renunț și apoi cum am renunțat la Google, iar acum a venit rândul altor trei platforme cu care aveam o relație destul de veche: X (fostul Twitter), Reddit și Instagram.

Nu a fost o decizie luată dintr-odată, ci mai degrabă ceva ce s-a tot copt în timp, pe măsură ce observam că timpul petrecut pe aceste platforme nu îmi aducea mare lucru - poate câteva informații interesante din când în când, dar și multă agitație, conținut irelevant și senzația că derulezi la nesfârșit fără un scop anume.

X (fostul Twitter)

La fel ca orice rețea socială mare, X colectează o cantitate impresionantă de date despre tine - ce citești, cât timp petreci pe fiecare postare, ce legături accesezi, ce dispozitiv folosești, de unde te conectezi - și toate acestea sunt folosite pentru a construi un profil cât mai detaliat care să fie valorificat prin publicitate. Nu este nimic surprinzător în asta, este modelul de business al întregului ecosistem al rețelelor sociale, dar cu cât mă gândeam mai mult la asta, cu atât mi se părea mai greu de justificat că ofer toate aceste informații în schimbul unor postări pe care le uitam în câteva minute.

La un moment dat mi-am dat seama că deschideam aplicația mai mult din obișnuință decât din interes real, ceea ce este un semn destul de clar că era timpul să renunț și am șters contul.

Reddit

Reddit are o mulțime de articole și discuții interesante și recunosc că am găsit acolo conținut util de-a lungul timpului - probleme tehnice, discuții despre homelab, sfaturi despre hardware, comunități de nișă unde găseai oameni care știau exact despre ce vorbesc. Dar interesul față de conținut nu înseamnă că trebuie să ignori ce se întâmplă cu datele tale, iar Reddit colectează destul de agresiv - istoricul de navigare, postările pe care le citești chiar dacă nu interacționezi cu ele, adresa IP, dispozitivul, și tot ce se poate deduce din comportamentul tău pe platformă. Mai mult decât atât, Reddit a vândut accesul la toate datele generate de utilizatori unor companii terțe pentru antrenarea modelelor de inteligență artificială, fără să-i întrebe nimeni pe cei care au generat acel conținut. Asta mi s-a părut o limită destul de clară și, sincer, renunțarea la cont nu a fost deloc grea.

Instagram

Instagram era platforma pe care o deschideam destul de des, probabil din obișnuință mai mult decât din interes real. Meta este probabil cea mai agresivă companie în ceea ce privește colectarea datelor - Instagram urmărește tot ce faci în aplicație, dar și în afara ei prin pixeli de urmărire și integrări cu alte situri, combină datele cu tot ce știe Facebook despre tine și construiește un profil extrem de detaliat care merge mult dincolo de ce ai distribuit tu vreodată în mod voit. Tocmai pentru că o deschideam atât de des, mi-am dat seama că ofeream foarte multe date în schimbul unui beneficiu real destul de mic, și acesta a fost motivul principal pentru care am decis să renunț.

Cu ce am rămas

Acum că am renunțat și la cele trei, tabloul arată cam așa, și nu o să mint că este unul perfect din punct de vedere al confidențialității.

Facebook îl mai folosesc în principal pentru câteva grupuri interesante unde se mai întâmplă discuții care merită urmărite - altfel probabil că și acesta ar fi plecat de mult. WhatsApp este mai greu de ocolit câtă vreme toată România este acolo, și nu poți renunța la un canal de comunicare fără să pierzi legătura cu oameni reali din viața ta. Netflix îl mai țin pentru că soția îl folosește, deși în casă există și Stremio ca alternativă. YouTube rămâne pentru că am YouTube Family și pentru că nu există cu adevărat o alternativă viabilă.

Cât despre Claude AI, îl folosesc pentru că nu știu altceva mai bun în momentul de față pentru ce am eu nevoie, dar mă joc și cu alte opțiuni - Lumo AI, Mistral AI și Venice AI - ca să văd ce oferă fiecare și cum evoluează lucrurile.

La telefoane, situația este similară - Android și iOS sunt departe de ideal, iar ce mă atrage cu adevărat ar fi un Fairphone cu /e/OS, care combină un hardware reparat ușor cu un sistem de operare degooglet, sau pe viitor un Motorola cu GrapheneOS. Deocamdată nu am făcut pasul, dar ideea este acolo.

Sunt conștient că lista de mai sus nu este tocmai curată, dar renunțarea la servicii nu înseamnă că trebuie să fii perfect dintr-odată, ci că mergi pas cu pas în direcția în care crezi că e bine să mergi. Și față de acum câțiva ani, diferența este deja uriașă.

Acum câteva zile am primit un mail de la un urmăritor al canalului meu de PeerTube și al jurnalului. Mi-a scris că îi plac articolele și că urmărește canalul cu interes, ceea ce m-a bucurat sincer, pentru că nu este ceva obișnuit să primești un mesaj de genul acesta.

Însă mailul nu s-a oprit acolo. Urmăritorul respectiv era curios - și totodată sceptic - dacă folosesc sau nu inteligența artificială pentru a scrie articolele. A menționat despre etichetele AI Usage și Note by AI, lucruri despre care am auzit, dar cărora nu le-am acordat prea multă atenție.

I-am răspuns la mail, dar nu i-am spus direct dacă folosesc sau nu AI-ul la articole, și am făcut asta dintr-un motiv simplu: din felul în care a scris, mi-am dat seama că este unul dintre acei oameni care pune etichete, fie pe oameni, fie pe lucruri, fără prea multă nuanță. Nu am nicio problemă să fiu transparent, dar nu simt nevoia să mă justific în fața cuiva care a venit deja cu o concluzie formată.

Eu nu sunt genul de om care să pună etichete, nici oamenilor și nici lucrurilor, și tocmai de aceea nu îmi plac oamenii care fac asta. Prefer să judec lucrurile după ce le înțeleg, nu după ce aud despre ele.

Acum, ca să fiu clar cu toată lumea care citește jurnalul: eu sunt o persoană simplă, îmi place comoditatea și prețuiesc orice unealtă sau lucru care îmi face viața mai ușoară. Exact din același motiv am renunțat la Arch și Fedora și am trecut la Linux Mint - nu pentru că celelalte distribuții sunt rele, ci pentru că Linux Mint îmi face viața mai simplă și mai liniștită. Același principiu îl aplic și la orice altceva, inclusiv la inteligența artificială.

Dacă folosesc AI la articole sau nu este, în primul rând, problema mea. Nu am nicio obligație față de nimeni să explic cum scriu, cu ce instrumente lucrez sau cât timp petrec în fața tastaturii. Ceea ce contează este că ceea ce ajunge publicat pe acest jurnal reflectă gândurile și experiențele mele reale, nu ale unui algoritm.

Dacă totuși cineva nu este de acord cu modul în care aleg să lucrez, îl invit respectuos să nu mai urmărească jurnalul, canalele de YouTube și PeerTube, și nici conturile de socializare. Nu îmi doresc să pierd cititori sau urmăritori, dar nici nu am de gând să îmi schimb felul de a fi sau de a lucra pentru a satisface așteptările altcuiva.