Am citit articolul scris de Dan Abramov în care încearcă să explice de ce întrebarea „unde sunt instanțele Bluesky?” este pusă greșit. Nu e un articol rău, dimpotrivă, are câteva idei tehnice interesante, dar mi-a rămas ceva în cap care nu îmi dă pace.

Ideea centrală a articolului e că ATProto - protocolul pe care stă Bluesky - funcționează diferit față de cum funcționează Mastodon. În loc să ai instanțe care sunt și găzduire, și aplicație în același timp, ATProto separă lucrurile: ai un loc unde îți stau datele (PDS - Personal Data Server) și ai aplicații separate care agregă datele tuturor. Abramov compară asta cu RSS și Google Reader - tu ai blogul tău, Google Reader îl indexa și îl afișa alături de ale altora. Aceeași idee, dar pentru rețele sociale.

Și ca să înțelegi mai bine ce sunt Bluesky, Eurosky și Blacksky - nu sunt același lucru. Bluesky e o aplicație care rulează pe deasupra ATProto. Eurosky e un furnizor alternativ de găzduire, adică un PDS unde îți poți muta datele în loc să le ții la Bluesky. Blacksky e un relay comunitar cu o filosofie proprie de moderare. Dan Abramov menționează că și-a mutat datele pe Eurosky și că a mers aproape fără probleme. Asta e cu adevărat o idee bună în ATProto - portabilitatea identității. Dacă furnizorul tău de găzduire dispare, identitatea ta rămâne intactă pentru că nu e legată de el.

Până aici, totul e corect și bine explicat.

Problema pe care o am cu articolul e alta. Abramov spune explicit că nu se referă la ActivityPub, ci doar la Mastodon, pentru că altfel vine toată lumea să-i explice că ActivityPub nu e Mastodon. Dar imediat după asta compară Mastodon cu ATProto, care este un protocol exact ca ActivityPub, nu o aplicație ca Mastodon. Cu alte cuvinte, evită comparația corectă tocmai pentru că știe că nu iese bine. Dacă ar fi comparat ActivityPub cu ATProto sau Bluesky cu Mastodon, articolul ar fi arătat altfel.

Al doilea lucru pe care îl trece ușor e că infrastructura critică a ATProto e concentrată la Bluesky Inc. PDS-ul tău poate exista independent, poți să ți-l și găzduiești singur, dar ca să fii vizibil în rețea ai nevoie de un Relay care să indexeze datele și de un AppView care să le servească aplicațiilor. Astea sunt în mare parte operate de Bluesky Inc. Abramov menționează că relay-urile sunt ieftine de rulat, ceea ce e adevărat, dar nu înseamnă că există alternative reale la scară în momentul ăsta. Dacă Bluesky Inc dispare mâine, PDS-ul tău există în continuare, dar e invizibil pentru că nu mai e nimeni să-l indexeze.

Acum, despre cum văd eu lucrurile.

Rulând thinkroot.xyz am implementat ActivityPub direct în jurnal. Asta înseamnă că articolele mele ajung în Fediverse, pot urmări alte conturi, pot vedea cine comentează, pot răspunde și pot da like sau repost - aproape tot ce aș face pe Mastodon, dar fără să fiu pe Mastodon. Dacă Mastodon Social dispare mâine, eu nu simt absolut nimic. Cei care folosesc GoToSocial, Misskey, Pixelfed sau orice alt program care implementează ActivityPub tot îmi văd articolele, tot pot interacționa cu ele. Rețeaua continuă să existe pentru că nimeni nu deține protocolul.

Asta e descentralizarea pe care o înțeleg eu. Nu neapărat că îți poți muta datele de la un furnizor la altul, ci că nicio entitate centrală nu poate închide rețeaua. ActivityPub e implementat de zeci de proiecte complet independente - Mastodon, GoToSocial, Misskey, Pleroma, Pixelfed, Peertube, WordPress, Ghost și lista continuă. Poți să nu existe niciunul din ele și tot poți implementa protocolul singur, cum am făcut eu cu jurnalul.

ATProto are idei tehnice frumoase și portabilitatea identității e un avantaj real față de modelul clasic al instanțelor Mastodon. Dar ecosistemul real depinde de infrastructura Bluesky Inc într-un mod pe care nu cred că îl poți ignora când vorbești despre descentralizare. Nu e o critică la adresa oamenilor de acolo, ci o observație despre arhitectură.

Ambele protocoale rezolvă probleme reale, dar rezolvă probleme diferite. ATProto rezolvă mai elegant portabilitatea datelor și separarea dintre găzduire și aplicații. ActivityPub rezolvă mai elegant independența față de orice entitate centrală. Articolul lui Abramov prezintă primul avantaj ca și cum ar fi singura definiție validă a descentralizării, și tocmai asta mi s-a părut că nu stă în picioare.

A apărut systemd 261 și, ca de obicei, vine cu o listă lungă de noutăți, unele cu adevărat utile, altele care mă fac să ridic o sprânceană și să mă întreb încotro se îndreaptă acest proiect.

Înainte să intru în detalii, trebuie să spun că am ajuns într-un punct în care relația mea cu systemd a început să devină... complicată. Mi-a plăcut când a apărut, părea o idee bună: un manager de servicii modern, cu pornire paralelă, cu jurnalizare centralizată, cu o interfață mai coerentă decât SysV init-ul care era o adunătură de scripturi bash lipite cu scotch. Dar de la versiune la versiune, systemd tot crește, tot absoarbe funcționalități noi, și mă întreb sincer dacă nu cumva, la un moment dat, o să avem un sistem de operare numit systemd care rulează pe un kernel Linux, nu invers.

Dar să vedem ce aduce versiunea 261.

Una dintre noutățile principale este un nou subsistem pentru accesarea metadatelor din cloud, prin systemd-imdsd. Practic, dacă rulezi o mașină virtuală pe Amazon EC2, Azure, Google Compute Engine, Hetzner sau alte platforme, acest serviciu creează o interfață locală unificată prin care programele pot citi metadatele instanței, fără să se conecteze direct la endpoint-ul fiecărui furnizor în parte. Ideea în sine nu e rea - standardizarea accesului la metadate are sens dacă lucrezi cu infrastructură cloud. Există și o bază de date hardware (hwdb.d/40-imds.hwdb) care identifică platforma pe care rulezi prin informații SMBIOS, recunoscând furnizori precum Scaleway, Tencent Cloud, Alibaba ECS sau Vultr, nu doar cei mari.

Tot la capitolul cloud, versiunea 261 adaugă și posibilitatea de a restricționa accesul la rețea către serviciile de metadate ale platformelor recunoscute, lucru recomandat pentru instalările unde securitatea contează, deși notele de lansare avertizează că poate intra în conflict cu unelte clasice precum cloud-init care se așteptau la acces direct.

O altă noutate este storagectl, un nou instrument în linie de comandă care expune resursele de stocare printr-o interfață Varlink unificată, destinat stocării gestionate pentru utilizatori. Și mai interesant pentru cei care se joacă cu instalări noi este systemd-sysinstall, un installer textual simplu pentru sisteme de operare, care folosește capacitățile de partiționare și gestionare a credențialelor deja existente în systemd, copiind sistemul de pe un mediu temporar de boot precum un stick USB. Da, ai citit bine - systemd are acum și un installer de sistem de operare.

Pe partea de TPM, sistemul primește ConditionSecurity=measured-os, o condiție nouă pentru unități care verifică dacă sistemul a pornit cu semantici de boot măsurat, mai generică decât vechea ConditionSecurity=measured-uki. systemd-boot și systemd-stub măsoară acum și date SMBIOS de tip 1, 2 și 11 în PCR 1, pentru cazurile în care firmware-ul nu face aceste măsurători. A fost adăugat și un serviciu nou, systemd-tpm2-swtpm.service, pentru a rula un TPM software ca fallback pe sisteme care nu au TPM fizic.

PID 1 suportă acum mecanismele Live Update Orchestration și Kexec Handover din kernel, ceea ce înseamnă că unitățile din spațiul de stocare al descriptorilor de fișiere peste kexec dacă kernel-ul permite și dacă FileDescriptorStorePreserve=yes este setat. Același lucru este disponibil acum și pentru managerii de sesiune ale utilizatorilor.

systemd-networkd primește și el câteva lucruri noi, inclusiv comanda networkctl dhcp-lease INTERFACE care afișează informațiile despre DHCP activ. systemd-resolved suportă acum înregistrări DNS statice din fișiere JSON în directoare drop-in sub systemd/resolve/static.d/, extinde rolul clasicului /etc/hosts cu ceva mai flexibil, și recitește intrările din /etc/hosts la reload.

La capitolul containere și mașini virtuale, systemd-vmspawn primește suport pentru volume bind, operare headless, gestionare NVRAM EFI, boot direct fără firmware UEFI, tipuri selectabile de disc și manipulare a stocării prin interfața Varlink io.systemd.MachineInstance.

Există și o noutate de genul ConditionFraction=, o condiție pentru rollout-uri treptate pe flote de mașini, care folosește ID-ul mașinii și un șir de tag-uri pentru a determina dacă o unitate trebuie să ruleze pe un anumit procent din sisteme. Util dacă administrezi zeci sau sute de servere și vrei să testezi ceva pe 10% din ele mai întâi.

Acum că am trecut prin lista de noutăți, revin la ce spuneam la început. Am fost un timp convins că fragmentarea Linux-ului este o problemă și că ar fi nevoie de mai multă unificare - un init system mai consistent, unelte mai standardizate, mai puțină diversitate care complică lucrurile. Și systemd părea răspunsul la asta, cel puțin la nivel de init. Dar cu fiecare versiune nouă îmi dau seama că tocmai diversitatea asta, faptul că există distros care fug de systemd, că există oameni care construiesc alternative, că nu există o singură cale, este de fapt ceea ce face Linux-ul interesant și rezistent. Nu mai sunt pro-unificare. Uniformitatea vine cu propriul ei set de probleme.

Iar systemd continuă să crească. Acum are subsistem cloud, installer de OS, gestionare de stocare pentru utilizatori, TPM software, și câte și mai câte. La câte funcții se tot adaugă, atât utile cât și mai puțin necesare, proiectul a ajuns să nu îmi mai placă în aceeași măsură în care îmi plăcea la început. Nu că ar fi rău, are și lucruri bine gândite, dar direcția e clară: systemd vrea să fie totul. Și dacă mai continuă în ritmul ăsta, la un moment dat va fi mai ușor să întrebi ce nu face systemd decât ce face.

Canonical a anunțat zilele astea un proiect nou pentru Ubuntu 26.10 (Stonking Stingray) care mi-a atras atenția - se numește Myna și este un instrument de dictare locală, adică transcriere din voce în text, care va fi integrat direct în desktop-ul Ubuntu.

Numele vine de la o pasăre tropicală cunoscută pentru că imită vocea umană cu o precizie destul de surprinzătoare, ceea ce e o alegere poetică pentru un astfel de proiect. Practic, apeși o combinație de taste, vorbești, și textul apare direct în aplicația pe care o ai deschisă în acel moment, fără să fie nevoie să copiezi sau să lipești nimic.

Ce mi se pare interesant este că totul se întâmplă local, pe calculatorul tău, fără nicio conexiune la internet după ce modelul de recunoaștere vocală a fost descărcat o dată. Microfonul se activează doar când pornești dictarea și audio-ul este procesat în memorie, după care este șters - nimic nu ajunge pe serverele Canonical sau ale altcuiva. Asta e exact abordarea pe care aș vrea să o văd mai des în lumea Linux, mai ales acum când fiecare a doua funcție nouă înseamnă date trimise undeva în cloud.

Versiunea inițială, care va ajunge în Ubuntu 26.10, va fi destul de simplă intenționat - nu vine cu asistent vocal, nu controlează desktopul cu comenzi vocale, nu traduce și nu detectează automat limba. Potrivit echipei Canonical, scopul este unul singur și clar: dictare fiabilă pe desktop. Restul pot veni mai târziu, pe baza feedback-ului de la utilizatori.

Arhitectura este modulară, cu recunoașterea vocală separată de gestionarea dictării și de inserarea textului în aplicații, ceea ce înseamnă că în viitor ar putea fi extinsă fără să se refacă totul de la zero. Deocamdată ținta principală este GNOME pe Wayland, dar proiectul este gândit să poată suporta și alte medii de desktop pe viitor.

Linuxiac observă că aceasta face parte dintr-o mișcare mai largă a Canonical de a construi un desktop „context-aware” cu funcții de inteligență artificială locale, Myna fiind unul dintre primele lucruri concrete care ies din această viziune.

Nu știu dacă voi folosi personal dictarea vocală vreodată, sincer - prefer tastatura și o să rămân la ea, dar înțeleg că pentru accesibilitate sau pentru cei care scriu mult și vor să dea mâinile o pauză, o funcție ca asta integrată nativ și fără să trimită nimic în cloud este o veste bună. E mai bine decât să instalezi ceva terț care îți înregistrează vocea pe serverele altcuiva.

Guvernul canadian a introdus Bill C-36, un pachet legislativ amplu care ar urma să reformeze complet modul în care companiile tratează datele personale ale canadienilor. Legea propusă se numește Protecting Privacy and Consumer Data Act (PPCDA) și, dacă va trece, va înlocui legislația actuală care datează din era dinaintea smartphone-urilor și a rețelelor sociale.

Concret, cetățenii canadieni ar urma să capete dreptul de a cere ștergerea datelor lor personale în anumite condiții, să primească explicații mai clare despre cum le sunt folosite informațiile și să beneficieze de cerințe mai stricte de consimțământ. Legea include și prevederi de portabilitate a datelor, ceva asemănător cu ce există deja în GDPR-ul european.

Un accent special e pus pe protecția datelor copiilor, organizațiile fiind obligate să trateze orice informație despre minori ca date sensibile și să respecte standarde mai ridicate când le colectează sau le folosesc. Sunt incluse și cerințe de transparență pentru sistemele de inteligență artificială și pentru deciziile automate, adică companiile vor trebui să explice cum funcționează algoritmii lor și cum îți afectează viața.

Ceva interesant e că legea vizează și practica numită surveillance pricing, adică situația în care companiile folosesc datele tale pentru a-ți stabili prețuri personalizate, mai mari sau mai mici decât cele pe care le vede altcineva, deși nu o interzice explicit.

Pe partea de amenzi, noua autoritate de supraveghere propusă, Digital Safety and Data Protection Commission of Canada, ar putea aplica penalități de până la 10 milioane de dolari canadieni sau 3% din veniturile globale ale companiei pentru încălcări obișnuite, și până la 25 de milioane sau 5% din veniturile globale pentru cele mai grave. Sunt cifre în linie cu ce permite GDPR-ul în Europa.

Bill C-36 intră acum în dezbatere parlamentară, deci mai e cale lungă până să devină lege, dar direcția e clară.