De la ultimul articol am mai adăugat câteva lucruri la Pure Blog Discover. Unele sunt vizibile imediat, altele funcționează în fundal.

Sortare și filtrare

Lista de jurnale are acum două opțiuni de sortare - ordinea aleatorie care exista deja și o nouă sortare alfabetică A-Z. Butonul de comutare între ele e vizibil deasupra grilei.

Tot acolo a apărut și un dropdown de filtrare după limbă. Codul de limbă al fiecărui jurnal e detectat automat din atributul lang al paginii la momentul adăugării, iar dropdown-ul se populează dinamic cu toate limbile prezente în director. Dacă vrei să vezi doar jurnale în română, sau doar în engleză, dai un click.

Widget de statistici

Sub header apare acum un mic panou cu două informații: distribuția jurnalelor pe limbi, afișată ca pill-uri colorate cu numărul de jurnale per limbă, și o listă cu ultimele 5 jurnale adăugate în director. Ambele se actualizează la fiecare încărcare a paginii, fără nicio configurare.

Aprobare manuală în admin

Scanarea automată săptămânală marchează jurnalele unde nu mai detectează Pure Blog cu un badge Needs review. Dacă jurnalul respectiv e legitim - poate a schimbat tema temporar sau a avut o problemă de server în ziua scanării - anterior singura opțiune era să aștepți scanarea următoare sau să ștergi și să re-adaugi jurnalul.

Acum există un buton „Approve" direct pe rândul jurnalului marcat. Apăsând pe el, jurnalul revine la approved imediat, fără reload complet și fără să mai aștepți luni dimineața. La următoarea scanare automată, dacă detecția eșuează din nou, jurnalul va fi re-marcat.

Pe de altă parte, scanarea face și operațiunea inversă automat: dacă un jurnal era deja marcat cu needs_review și la verificarea următoare Pure Blog este detectat din nou, statusul revine la approved fără intervenție manuală.

Câteva detalii tehnice

IP-urile celor care adaugă jurnale nu se stochează în clar în blogs.json - fiecare IP trece printr-un hash SHA-256 înainte de salvare. Nu e ceva vizibil pentru utilizatori, dar era ceva ce trebuia rezolvat din perspectiva datelor personale.

Tot în backend, blogs.json se scrie acum printr-un fișier temporar care apoi e redenumit atomic. Înseamnă că dacă două requesturi simultane încearcă să scrie în același timp, fișierul nu ajunge corupt.

Există și un endpoint de diagnostic la api.php?action=ping care returnează starea mediului - versiunea PHP, dacă cURL e disponibil, dacă sesiunile funcționează și dacă fișierele de date sunt accesibile și au permisiuni de scriere. Util la deploy pe un hosting nou sau la depanare.

De la ultimul articol despre Pure Blog Discover au trecut câteva zile, dar am lucrat destul de mult. Încerc să rezum ce s-a schimbat față de cum arăta proiectul atunci.

Descrierile jurnalelor

Cel mai vizibil lucru nou sunt descrierile care apar acum pe carduri. Când un jurnal este adăugat în director, serverul preia automat textul din tag-ul <meta name="description"> al paginii și îl salvează împreună cu celelalte informații. Nu toate jurnalele au o astfel de descriere, dar cele care o au arată acum mai bine în listă - cardul e mai informativ și ai o idee mai clară despre ce găsești pe acel jurnal înainte să dai click.

Feed-uri RSS

Acum când adaugi un jurnal, sistemul detectează automat și feed-ul RSS al acestuia - fie căutând tag-ul <link rel="alternate"> în codul paginii, fie încercând câteva căi comune. Dacă îl găsește, apare o iconiță portocalie de RSS în colțul din dreapta jos al cardului, pe care dai click direct pentru a te abona.

Tot pentru director există acum trei feed-uri proprii la care te poți abona ca să urmărești când se adaugă jurnale noi: RSS, Atom și JSON Feed. Iconițele sunt vizibile în header.

Și un buton de export OPML lângă bara de căutare, dacă vrei să imporți toate feed-urile deodată în cititorul tău RSS favorit.

Paginile Submit și About

Formularul de adăugare a jurnalelor a fost mutat pe o pagină separată la /submit, astfel încât pagina principală să fie mai curată și să afișeze doar lista de jurnale.

Am adăugat și o pagină About cu informații despre cum a apărut proiectul, cum funcționează detecția automată și cine l-a construit.

Butonul de share

După ce un jurnal este aprobat și adăugat în director, apare acum un prompt cu trei butoane - Mastodon, Bluesky și Copy text. Textul pregătit spune că tocmai ai adăugat jurnalul tău în Pure Blog Discover și include link-ul spre director. Mastodon deschide mastodonshare.com unde îți alegi instanța, Bluesky deschide direct fereastra de postare.

Scanare automată

Un cron job rulează acum în fiecare luni dimineața și verifică toate jurnalele din director - dacă Pure Blog Discover nu mai detectează semnăturile platformei pe acel jurnal, este marcat cu un badge de avertizare în panoul de administrare.

Director oficial

Am descoperit că există acum și un director oficial Pure Blog la roll.pureblog.org. Ce e interesant e că pagina About a directorului oficial menționează explicit că Pure Blog Discover - alături de proiectul lui Waldemar de la werschreibt.de.cool - a arătat că există interes real pentru un astfel de director și a inspirat crearea celui oficial.

Cele două directoare nu se exclud reciproc deoarece funcționează diferit.

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.