Nu am avut nicio problemă cu systemd, spre deosebire de mulți alții. Știu că există o tabără întreagă de oameni care îl detestă și care consideră că încalcă filosofia Unix de a face un singur lucru și a-l face bine. Înțeleg argumentele, le-am citit, dar personal nu m-am simțit deranjat de prezența lui pe sistemul meu. Funcționează, este rapid, are unelte utile și cam atât.

Acum însă a apărut ceva care mă face să privesc lucrurile puțin diferit, și anume direcția în care se îndreaptă Flatpak.

Ce se întâmplă cu Flatpak

Dezvoltatorii Flatpak discută niște schimbări arhitecturale majore pentru ceea ce ei numesc „Flatpak Next", adică o versiune viitoare care ar putea aduce o reproiectare completă a platformei, ceva în stilul unui salt la versiunea 2.0. Sebastian Wick, unul dintre dezvoltatorii principali ai proiectului, a publicat o actualizare a proiectului încă din noiembrie anul trecut, în care recunoștea că ritmul de dezvoltare încetinise după ce unii contribuitori se retrăseseră, dar că lucrurile au reintrat în normal. Mai recent, el și Adrian Vovk au discutat public despre această viziune la Linux App Summit 2026.

Piesa centrală a acestei arhitecturi viitoare este ceva numit systemd-appd, o componentă propusă pentru systemd care ar urma să ofere informații despre instanțele de aplicații care rulează. Concret, systemd-appd ar trebui să gestioneze autentificarea instanțelor Flatpak, să permită sandbox-uri imbricate, să îmbunătățească integrarea cu PipeWire și să înlocuiască în cele din urmă modelul actual bazat pe proxy-ul D-Bus.

Nu este vorba de o cerință prezentă în versiunile stabile ale Flatpak, deci deocamdată nu se schimbă nimic practic. Problema este direcția pe termen lung, pentru că noua arhitectură este proiectată în jurul unei infrastructuri care face systemd tot mai greu de evitat.

De ce contează asta

Flatpak a fost mereu gândit ca o platformă universală pentru desktop-ul Linux, nu legată de o anumită familie de distribuții. Dacă viitoarele versiuni vor necesita systemd-appd fără vreo alternativă compatibilă, distribuțiile care evită systemd - Alpine, Void, Devuan și altele - vor fi puse în fața unei alegeri neplăcute: să aplice patch-uri proprii, să mențină un strat de compatibilitate sau să renunțe complet la suportul Flatpak.

Motivația tehnică există și este reală. Flatpak are nevoie de metode mai solide pentru a identifica aplicațiile care rulează, pentru a gestiona permisiunile și pentru a suporta sandbox-uri complexe cum sunt cele din navigatoare. Dar soluția aleasă ridică o întrebare sensibilă în ecosistemul Linux: un format de aplicații gândit să funcționeze pe orice distribuție chiar ar trebui să depindă de o componentă specifică unui singur sistem de init?

Unde mă pierd eu

Cum spuneam, nu am avut treabă cu systemd. Mi s-a părut mereu că discuțiile despre el sunt prea încinse față de impactul real pe care îl are asupra utilizatorului obișnuit. Dar acum se schimbă ceva, pentru că nu mai vorbim doar despre sistemul de init al distribuției tale, ci despre o platformă de distribuție a aplicațiilor care devine dependentă de el.

Asta înseamnă că alegerea sistemului de init nu mai este o decizie strict a distribuției, ci începe să afecteze și compatibilitatea cu aplicații pe care le folosești. Dacă ești pe o distribuție fără systemd și vrei să rulezi o aplicație Flatpak, s-ar putea să nu mai poți, pur și simplu. Nu din cauza unui capriciu al distribuției tale, ci pentru că platforma în sine a decis că are nevoie de o componentă specifică.

Și asta mă îngrijorează. Nu dramatic, nu catastrofic, dar mă îngrijorează. Linux a fost mereu despre libertatea de a alege și despre faptul că poți construi un sistem după nevoile tale. Pas cu pas, prin decizii de genul acesta, acea libertate se erodează. Ecosistemul devine mai rigid, mai puțin flexibil, mai controlat - și asta seamănă tot mai mult cu ce se întâmplă pe Windows, unde lucrurile sunt legate unele de altele intenționat, tocmai pentru a reduce opțiunile utilizatorului.

Oamenii au venit la Linux și tocmai din cauza acestui gen de control. Ar fi ironic ca Linux-ul să ajungă exact acolo de unde au fugit ei.

Uneori dai peste o aplicație care ți se pare exact ce căutai, dar când o cauți în App Store descoperi că nu există. Nu că ar fi dispărut sau ar fi cu plată - pur și simplu nu e disponibilă în regiunea ta. Asta mi s-a întâmplat cu Forum, o aplicație dedicată grupurilor de Facebook, disponibilă doar în App Store-ul din SUA.

Problema cu regiunea din App Store

Primul impuls a fost să schimb limba și regiunea telefonului pe engleză și SUA, gândindu-mă că asta va rezolva problema. Nu a rezolvat nimic. App Store-ul nu ține cont de setările telefonului, ci de contul Apple ID - mai exact de regiunea asociată contului. Deci am pierdut puțin timp degeaba cu asta.

Cum am rezolvat

Am intrat în setările contului Apple ID, la Media & Purchases, și de acolo am schimbat Country/Region pe United States. Imediat a apărut un formular de adresă de facturare americană. La metoda de plată am ales „None", pentru că voiam doar să descarc o aplicație gratuită.

La adresă am completat cu una din Portland, Oregon - am ales Oregon pentru că nu are sales tax, deci nu apar taxe suplimentare dacă ajung vreodată să cumpăr ceva. A mai trebuit să completez și un număr de telefon american valid, ceea ce a necesitat puțină atenție la format. După câteva încercări am găsit combinația corectă și formularul a trecut mai departe.

Odată apăsat „Done", Forum a apărut imediat în căutare și am instalat-o fără probleme.

Înapoi la setările normale

După instalare am revenit la regiunea inițială a contului. Aplicația a rămas instalată și funcționează în continuare fără nicio problemă.

Cum e Forum în practică

Forum e construită special pentru grupurile de Facebook și se vede că cei care au făcut-o au gândit-o bine de la început. Interfața e curată, navigarea e intuitivă și tot ce ține de grupuri e la îndemână fără să te pierzi prin meniuri. Față de aplicația oficială Facebook, unde grupurile sunt îngropate sub straturi de feed și notificări, Forum taie tot zgomotul și îți arată exact ce te interesează. Se folosește ușor și nu simți că lucrezi împotriva interfeței ca să ajungi unde vrei.

La momentul scrierii acestui articol, Forum nu apare în App Store-ul din România - cel puțin pe telefonul meu nu am găsit-o. Dacă ești pe iOS și grupurile de Facebook sunt o parte importantă din activitatea ta online, merită efortul.

După ce am pus writedeckul pe picioare, au mai rămas câteva lucruri mărunte de rezolvat. Nu sunt modificări spectaculoase, dar fac experiența de zi cu zi mai plăcută.

Sudo fără parolă

De fiecare dată când aveam nevoie de o comandă cu privilegii, trebuia să introduc parola. Pe un dispozitiv care este pornit rar și folosit exclusiv de mine acasă, asta nu are prea mult sens. Am eliminat cererea de parolă pentru sudo:

sudo visudo

Am adăugat la final:

thinkroot ALL=(ALL) NOPASSWD: ALL

GRUB cu timeout 0

La fiecare pornire stăteam 5 secunde să privesc meniul GRUB înainte să se încarce sistemul. Pe un dispozitiv cu un singur sistem de operare instalat, cele 5 secunde sunt pur ceremoniale. Am eliminat așteptarea:

sudo nano /etc/default/grub

Am schimbat GRUB_TIMEOUT=5 în GRUB_TIMEOUT=0, după care:

sudo update-grub

Acum laptopul pornește direct, fără opriri inutile.

Screenshot în TTY cu fbcat și tmux

Acesta a fost cel mai neașteptat lucru de rezolvat. Nu există un PrintScreen în TTY - cel puțin nu unul evident. Am încercat câteva soluții care nu au mers, până la fbcat care capturează framebuffer-ul și funcționează cu kmscon.

Am adăugat un binding în ~/.tmux.conf care face screenshot la apăsarea lui F12:

bind -n F12 run-shell 'fbcat | pnmtopng > /home/thinkroot/screenshot-$(date +%H%M%S).png'

Fișierul apare direct în PNG cu timestamp în nume, fără pași suplimentari.

Taste rapide pentru reboot și shutdown

Tot prin tmux, am adăugat două taste rapide pentru a opri sau reporni laptopul fără să ies din micro:

bind -n F10 run-shell 'sudo shutdown now'
bind -n F11 run-shell 'sudo reboot'

F10 oprește laptopul, F11 îl repornește.

Transferul screenshot-urilor pe PC cu scp

Pentru a trimite screenshot-urile de pe writerdeck pe PC, folosesc scp. Ca să nu scriu comanda de fiecare dată, am adăugat un alias în ~/.bashrc pe PC:

alias t440p='scp thinkroot@IP_LAPTOP:/home/thinkroot/screenshot-* /home/thinkhome/Imagini/T440p'

De acum, când vreau să transfer toate screenshot-urile de pe writerdeck, rulez pur și simplu t440p din terminal.