Majoritatea oamenilor nu urăsc Linux-ul, urăsc faptul că trebuie să reînvețe cum se deschide o conservă după ce au folosit toată viața doar mâncare la plic.

În majoritatea cazurilor așa stau lucrurile. Omenilor le este lene să mai învețe ceva ce îi poate ajuta.

Pe 25 martie 2026, un juriu din California a hotărât că Meta și Google sunt vinovate de neglijență în proiectarea platformelor lor și le-a obligat să plătească șase milioane de dolari în despăgubiri unei tinere de 20 de ani, pe care o vom numi Kaley, după ce aceasta a demonstrat că utilizarea compulsivă a rețelelor sociale i-a provocat depresie și tulburări de imagine corporală. Este prima dată în istorie când un juriu a tratat în mod explicit aplicațiile de socializare ca pe niște produse defecte, proiectate în mod deliberat să exploateze creierele în formare ale copiilor. Puteți citi știrea originală în engleză pe situl NPR.

Kaley a început să folosească YouTube la vârsta de șase ani și Instagram la unsprezece ani, cu mult înainte de limita minimă de treisprezece ani impusă de Meta prin propriile reguli. Juriul nu a trebuit să decidă dacă aceste platforme au creat problemele ei de sănătate mintală, ci dacă utilizarea lor compulsivă a fost un factor important în suferința ei - și răspunsul a fost da. Pe parcursul a cinci săptămâni de proces, jurații au ascultat mărturii din partea terapeuților, inginerilor, directorilor executivi, inclusiv a lui Mark Zuckerberg, și a Kaley înseși, care le-a povestit cum alerga la toaleta școlii ca să vadă câte aprecieri primeau postările ei și cum nu se mai putea concentra la ore pentru că singurul lucru pe care și-l dorea era să rămână lipită de aplicații.

Ceea ce face acest proces interesant din punct de vedere juridic este strategia abordată de avocații reclamantei: în loc să atace conținutul de pe platforme - ceea ce ar fi fost blocat de Secțiunea 230 din legea americană din 1996 care apără companiile de tehnologie de responsabilitatea pentru ceea ce postează utilizatorii lor - ei au atacat modul în care au fost proiectate aceste aplicații. Scroll-ul infinit, notificările constante, videoclipurile care pornesc singure, filtrele de frumusețe, toate acestea au fost prezentate ca elemente ale unui „cazinou digital" construit intenționat să fie imposibil de abandonat, mai ales pentru copii și adolescenți.

Avocatul principal al reclamantei, Mark Lanier, a spus un lucru care mi se pare esențial: „Cum faci un copil să nu mai pună jos telefonul? Asta se cheamă ingineria dependenței." Nu este o metaforă poetică, ci o descriere destul de exactă a ceea ce arătau documentele interne ale Meta - documente în care chiar Zuckerberg și alți directori discutau deschis despre strategii de atragere a copiilor de la vârste cât mai mici. Un astfel de document spunea explicit: „Dacă vrem să câștigăm din plin cu adolescenții, trebuie să-i aducem când sunt încă copii." Un alt document intern arăta că fetele de unsprezece ani aveau o rată de revenire pe Instagram de patru ori mai mare decât pe aplicațiile concurente - și asta în condițiile în care Instagram pretinde că nu acceptă utilizatori sub treisprezece ani.

Zuckerberg a apărat totul cu aerul lui obișnuit de om care nu înțelege de ce îl întreabă lumea lucruri atât de evidente: „Dacă oamenii simt că nu au o experiență bună, de ce ar continua să folosească produsul?" Este genul de răspuns care sună logic dacă ignori complet ce spune știința despre dependența de dopamină și despre vulnerabilitatea specifică a creierelor adolescentine. Desigur, Meta și Google au anunțat că vor face apel la decizie.

Suma acordată - trei milioane în despăgubiri directe și alte trei milioane nesoluționate, din care Meta suportă 70% - este ridicolă raportat la valoarea companiilor implicate. Avocatul reclamantei a recunoscut-o el însuși, arătând juriului un borcan cu bomboane M&M în care fiecare bomboană reprezenta un miliard de dolari din valoarea companiilor: „Trebuie să vorbești cu Meta în bani de Meta." Totuși, verdictul nu este important prin suma de bani, ci prin precedentul juridic pe care îl creează, pentru că este legat de aproximativ două mii de alte procese intentate de părinți și districte școlare din Statele Unite împotriva acestor companii de tehnologie.

Comparația cu procesele împotriva industriei tutunului din anii nouăzeci circulă deja printre avocați și analiști, și nu e lipsită de sens: și atunci a durat mulți ani până când juriile au început să ia de bun că o industrie uriașă poate fi trasă la răspundere pentru prejudicii deliberate aduse sănătății publice. În plus, chiar în ziua anterioară verdictului din California, un juriu din New Mexico a obligat Meta să plătească 375 de milioane de dolari pentru că nu a protejat utilizatorii tineri de prădători sexuali pe Instagram și Facebook.

Platformele nu sunt construite pentru noi

Mă tot uit la știri despre Meta, Google, TikTok și toate celelalte platforme mari și mă întreb când o să priceapă lumea că aceste companii nu sunt făcute pentru noi - pentru că de fiecare dată când ies la suprafață dovezi că știau de mult timp ce rău fac, răspunsul lor este același: un comunicat de presă îngrijit formulat, o promisiune vagă că „siguranța utilizatorilor este prioritatea lor„, și apoi totul continuă ca înainte. Meta a spus după verdictul din California că sănătatea mintală a tinerilor „este profund complexă și nu poate fi legată de o singură aplicație." Google a spus că YouTube este „o platformă de streaming construită responsabil, nu o rețea de socializare." Adică fix ce te-ai fi așteptat să spună.

Ce mă surprinde este că mai există atâta uimire colectivă de fiecare dată când iese câte un scandal nou. Problema nu este că Meta sau Google au dat cumva greș în misiunea lor, ci că misiunea lor reală nu a inclus niciodată binele utilizatorilor ca obiectiv principal. O companie care câștigă bani din publicitate are un interes fundamental în a te ține cât mai mult timp pe platformă, indiferent de costul pe care îl plătești tu pentru asta - fie că ești adult, fie că ai șase ani și abia ai învățat să citești. Atâta timp cât modelul de afaceri rămâne neschimbat, schimbările cosmetice nu vor face decât să mute problema dintr-un loc în altul.

Verdictul din California este, totuși, un semn că ceva se mișcă. Nu pentru că șase milioane de dolari ar doare pe cineva de la Meta sau Google, ci pentru că juriul a spus clar că proiectarea deliberat adictivă a unui produs poate fi considerată un defect de fabricație - și asta deschide o ușă prin care pot intra mii de alte procese. Dacă această abordare juridică prinde, companiile vor fi nevoite să aleagă între a-și schimba cu adevărat produsele sau a plăti despăgubiri la nesfârșit. Poate că atunci, și numai atunci, va deveni mai profitabil să construiești ceva care nu distruge oameni.

Când o să priceapă lumea că aceste companii nu sunt făcute pentru noi

Am primit ieri, pe 2 aprilie 2026, o fotografie de la Alex care lucrează la o firmă mare din Marea Britanie - una care nu doar produce trenuri, ci administrează și o parte din rețeaua de cale ferată a țării. În fotografia de mai jos se vede un monitor pe care scrie „You're locked out!" și, dacă ar fi fost vorba de un singur calculator, poate nu merita discuție. Dar nu este vorba de unul. Sunt nouă din douăzeci, și nimeni nu știe de ce.

Ce se întâmplă de fapt în acel birou

Ca să înțelegi de ce nouă calculatoare blocate simultan sunt o problemă cu adevărat serioasă, trebuie să știi cu ce se ocupă oamenii din acel centru, mai ales noaptea.

Primul lucru care poate părea surprinzător dacă ești obișnuit cu trenurile CFR este că trenurile de pasageri din Marea Britanie au bucătărie la bord, bucătar, ospătari și, evident, un manager de tren. Înainte ca trenul să ajungă la depou, managerul de tren trimite deja comanda pentru următoarea cursă: zece sticle de șampanie, zece Cola și tot ce mai este nevoie pentru serviciul de la bord. Scopul este ca echipa de la depou să aibă tot pregătit din timp, să încarce rapid cele necesare și să trimită trenul înapoi în cursă fără întârzieri. Iar asta se face de pe acele calculatoare.

În același timp, poate trimite un mail cu observații tehnice: „băieți, când vine trenul în depou, uitați-vă la frigiderul 9, nu mai merge, și nici ușa 6 nu funcționează corect." Aceste mesaje trebuie văzute, înregistrate și transmise echipei tehnice înainte ca trenul să plece în următoarea cursă - care poate veni după o oră, după două, nu neapărat a doua zi dimineață. Dacă calculatoarele sunt blocate și nimeni nu poate accesa e-mailul sau sistemul de tichete, există riscul real ca problemele tehnice semnalate de manager să rămână nerezolvate.

Mai departe, în fiecare zi se strică câte ceva pe undeva - un senzor de ușă, un buton, o componentă electronică - și piesele de schimb trebuie comandate cu suficient timp înainte, mai ales pentru trenurile Hitachi, unde comanda se face în China și timpul de livrare nu iartă pe nimeni. Un calculator blocat câteva ore înseamnă că cineva poate scăpa fereastra de comandă pentru ziua respectivă.

Există și un sistem de planificare: echipa urmărește câte trenuri intră în depou în fiecare noapte, pentru că asta determină câte vor putea pleca a doua zi și pe ce rute. Este un puzzle logistic care trebuie rezolvat în timp real, pe baza datelor din sistem.

Raspberry Pi monitorizate de pe Windows

În infrastructura feroviară din UK, macazele sunt controlate prin Raspberry Pi-uri, acele minicalculatoare pe care în lumea Linux le cunoaștem bine din diverse proiecte de hobby. Ei bine, în infrastructura feroviară britanică, aceeași tehnologie face treabă serioasă, la scară industrială. Iar tot ce transmit acele Raspberry Pi-uri este monitorizat de pe calculatoarele cu Windows din biroul din fotografie.

Firma este împărțită în zone geografice - ceea ce are sens, dat fiind că nu vorbim doar de o fabrică, ci de o organizație care gestionează efectiv circulația trenurilor pe o parte din rețeaua britanică: o echipă monitorizează centrul țării, alta Londra, alta nordul țării, alta vestul, și tot așa, cu mai multe puncte de lucru răspândite prin toată Marea Britanie. Fiecare zonă are calculatoarele ei, fiecare calculator are un rol bine definit în lanțul ăsta de monitorizare și coordonare nocturnă.

Windows, mereu cu surprize

Acum că știm cu ce se ocupau acele calculatoare, hai să vorbim despre ce le-a blocat - sau mai degrabă despre faptul că nu se știe cu certitudine ce le-a blocat, și asta spune destul de mult despre cum funcționează Windows.

Pe ecranul din fotografie este mesajul de recuperare BitLocker, sistemul de criptare a discului integrat în Windows. Cauza exactă este necunoscută - ar putea fi o actualizare de sistem aplicată automat în fundal, o modificare de configurație aplicată de la distanță fără știrea nimănui, sau poate cineva a greșit parola de câteva ori. Nimeni nu știe, și asta, în sine, este o problemă la fel de mare ca blocarea propriu-zisă: fără să știi ce s-a întâmplat, nu poți garanta că nu se va repeta.

Într-un sistem bine gândit, un eveniment de această amploare - aproape jumătate din parcul de calculatoare al unui centru critic, blocat simultan - ar trebui să genereze automat un jurnal clar, un mesaj trimis echipei IT și o procedură de recuperare simplă. În schimb, avem nouă ecrane albastre și un semn de întrebare.

Aproape jumătate din birou, blocat simultan

Impactul a fost cât se poate de concret, și l-a descoperit managerul care a intrat în tura de noapte: nouă ecrane albastre în loc de instrumentele de lucru obișnuite. Calculatoarele au așteptat cuminte în starea asta până când primul om a venit la muncă. Comenzile de catering pentru a doua zi, mesajele tehnice de la managerii de tren, piesele de schimb care trebuiau comandate, planificarea trenurilor - totul blocat de la primul minut al turei. Iar undeva, macazele continuă să fie monitorizate - sperăm - de pe calculatoarele care au avut norocul să nu fie printre cele nouă.

Ironia este că tocmai mecanismul menit să protejeze datele firmei a fost cel care a oprit firma din a-și face treaba. Și nu pentru că ar fi fost un atac, sau o defecțiune hardware, sau o catastrofă de vreun fel - ci pur și simplu pentru că Windows a decis că este momentul potrivit să facă ce vrea el, fără să consulte pe nimeni.

Același Windows, același film

Dacă urmărești știrile din lumea IT de câțiva ani, știi că scenariul ăsta nu este nou. Actualizările Windows care repornesc calculatoarele în mijlocul lucrului, BitLocker-ul care se activează singur după un update și lasă utilizatorii fără acces, ecranele albastre care apar fără avertisment pe sisteme critice - toate sunt povești pe care le-am mai auzit. Cel mai recent exemplu este chiar din martie 2025, când actualizarea KB5053598 pentru Windows 11 24H2 a cauzat blocări, ecrane albastre și sisteme care refuzau să mai pornească, iar Microsoft a fost nevoită să o retragă după ce utilizatorii au raportat în masă problemele - exact cum a scris și ArenaIT.

Linux nu este perfect și nu pretind că este, dar are o filozofie fundamental diferită în ceea ce privește actualizările și controlul asupra sistemului: tu decizi când se actualizează, ce se actualizează și ce se repornește. Sistemul nu ia decizii în locul tău în momente în care ai nevoie să funcționeze.

Undeva în UK, un manager de tură de noapte a deschis ușa biroului, a privit cele nouă ecrane albastre și și-a dat seama că noaptea va fi mai lungă decât se așteptase. Nu din cauza unui atac cibernetic, nu din cauza unei pene de curent, ci pentru că Windows a fost Windows.

Iar ca să fie tabloul complet: firma care oferă suportul IT este din Polonia. Era noapte, deci oricum mai puțini oameni la lucru. Iar totul s-a întâmplat în ajunul Vinerii Mari - astăzi Polonia intră în vacanța de Paște. Norocul a fost și mai mic decât părea la prima vedere.

Trenurile au început să întârzie. O parte din motiv este că echipa care monitorizează și schimbă macazele funcționează acum cu doi oameni în loc de cinci - restul nu pot accesa sistemele. Cu cât Windows ține mai mult calculatoarele blocate, cu atât întârzierile vor crește. Și asta este doar începutul: comenzile de catering neprocessate, piesele de schimb necomandate, defecțiunile tehnice nesemnalate echipei de la depou - toate acestea își vor arăta efectele pe rând, una după alta, cu siguranță mai grave decât cele unsprezece minute de mai jos.

Nu dramatic, nu catastrofal dar suficient cât să vezi cum un ecran albastru cu „You're locked out!" dintr-un birou de monitorizare se transformă, pas cu pas, într-un pasager care stă în gară și privește panoul de afișaj. Asta este frumusețea și fragilitatea unui sistem interconectat: un calculator cu Windows care decide să se blocheze la momentul nepotrivit poate ajunge să miște, sau mai bine zis să oprească, tone de oțel pe șine.

Linux Mint e distribuția pe care o folosesc și, în general, nu am prea multe motive de nemulțumire. Vine cu tot ce am nevoie, e stabilă și nu mă pune să configurez sistemul de la zero de fiecare dată. Totuși, la un moment dat am observat că sistemul pornește mai lent decât ar trebui și că, atunci când îl opresc, mai durează ceva până când ecranul devine negru. Problema nu era gravă, dar era deranjantă, mai ales că știam că se poate face ceva în privința asta.

De unde am început

Prima oprire a fost comanda systemd-analyze blame, care îți arată cât timp a durat fiecare serviciu să pornească. Rezultatele au fost destul de clare:

29.577s mintupdate-automation-upgrade.service
14.288s apt-daily.service
 6.373s NetworkManager-wait-online.service

Doar aceste trei servicii consumau aproape 50 de secunde din boot. Restul erau neglijabile. Practic, de fiecare dată când porneam calculatorul, sistemul verifica și instala actualizări, descărca liste de pachete și aștepta ca rețeaua să fie complet inițializată înainte să continue - toate astea blocând procesul de boot.

Dezactivarea upgrade-ului automat la pornire

mintupdate-automation-upgrade.service e un serviciu specific Linux Mint care rulează un upgrade automat la fiecare pornire a sistemului. E o idee bună în teorie, dar în practică înseamnă că de fiecare dată când pornești calculatorul, acesta poate sta 30 de secunde sau mai mult descărcând și instalând actualizări.

Am încercat să îl dezactivez cu systemctl disable, dar am primit un mesaj care spunea că unitatea nu are configurație de instalare și că timer-ul aferent rămâne activ. Soluția corectă a fost să folosesc mask în loc de disable, ceea ce creează un symlink către /dev/null și împiedică systemd să pornească serviciul în orice circumstanță:

sudo systemctl mask mintupdate-automation-upgrade.timer
sudo systemctl stop mintupdate-automation-upgrade.timer

Actualizările automate nu dispar complet - apt-daily-upgrade.timer rămâne activ și rulează complet în fundal o dată pe zi, fără nicio intervenție din partea mea. Aplicația Mint Update e doar interfața vizuală prin care pot vedea ce actualizări sunt disponibile, nu e necesară pentru ca procesul automat să funcționeze.

Mutarea verificării pachetelor după boot

apt-daily.service e responsabil pentru descărcarea listelor de pachete și rulează imediat la pornirea sistemului, adăugând 14 secunde la boot. Nu există niciun motiv pentru care această operațiune trebuie să se întâmple exact în momentul în care pornesc calculatorul - poate la fel de bine să aștepte câteva minute.

Am editat timer-ul cu sudo systemctl edit apt-daily.timer și am adăugat următoarele:

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d

Astfel, verificarea pachetelor începe la 15 minute după boot, nu imediat, și se repetă o dată pe zi.

Dezactivarea NetworkManager-wait-online

NetworkManager-wait-online.service blochează procesul de boot până când conexiunea la rețea este complet stabilită. Pe un server, asta are sens - serviciile care depind de rețea nu pot porni fără ea. Pe un calculator obișnuit, însă, nu e necesar, pentru că aplicațiile se conectează singure când au nevoie.

sudo systemctl disable NetworkManager-wait-online.service

NetworkManager continuă să funcționeze normal și se conectează automat la rețea la fel ca înainte - doar că nu mai blochează boot-ul pentru a confirma că totul e gata.

Optimizarea shutdown-ului

Implicit, systemd așteaptă 90 de secunde pentru fiecare serviciu să se oprească înainte de a-l forța. Asta înseamnă că dacă un serviciu îngheață sau pur și simplu e lent, poți sta un minut și jumătate doar pentru el.

Am editat /etc/systemd/system.conf și am adăugat la final:

DefaultTimeoutStopSec=10s
DefaultTimeoutAbortSec=10s
ShutdownWatchdogSec=10s

DefaultTimeoutStopSec limitează cât așteaptă systemd după fiecare serviciu înainte să îl oprească forțat. DefaultTimeoutAbortSec face același lucru pentru serviciile care primesc SIGABRT. ShutdownWatchdogSec e un mecanism de siguranță - dacă systemd însuși îngheață în timpul shutdown-ului, hardware watchdog-ul repornește mașina forțat după intervalul setat.

Cu aceste valori setate la 10 secunde, niciun serviciu nu mai poate bloca shutdown-ul pentru o perioadă lungă de timp.

Rezultatul

Modificările sunt simple și nu afectează funcționalitatea sistemului. Actualizările tot se instalează, rețeaua tot funcționează, serviciile tot se opresc ordonat - doar că totul se întâmplă mai rapid și fără să blocheze inutile procesul de pornire sau oprire. Uneori optimizarea nu înseamnă să schimbi tot, ci doar să muți lucrurile la momentul potrivit.

Am tot urmărit în ultimii ani evoluția cotei de piață a Linux-ului pe Steam, cu speranța că într-o zi voi vedea cifre care să justifice entuziamul comunității. Ei bine, momentul acela a venit: conform datelor publicate de Valve în cel mai recent Steam Hardware & Software Survey, Linux a depășit pentru prima dată pragul de 5% din totalul utilizatorilor activi ai platformei Steam.

Ca să înțelegem cât de semnificativ este acest lucru, trebuie să privim puțin înapoi. Acum aproximativ un an, Linux se afla undeva în jurul valorii de 2% pe platforma Steam. În noiembrie 2024, era la 2,03%. Un an mai târziu, în noiembrie 2025, atinsese 3,20%, un nou record absolut, iar în decembrie 2025 a urcat și mai sus, la 3,58%, după ce Valve a corectat cifrele inițiale care îl plasau la 3,19%. Ianuarie 2026 a adus o ușoară coborâre la 3,38%, iar februarie a venit cu o anomalie statistică bine-cunoscută: utilizatorii vorbitori de limbă chineză au crescut cu 30% față de luna anterioară, ceea ce a dus la o scădere artificială până la 2,23%. Valve obișnuiește să corecteze aceste anomalii ulterior, și se pare că de data aceasta corecția a fost una spectaculoasă.

Acum suntem la 5%, și nu știu cum altfel să descriu asta decât ca pe un moment pe care comunitatea Linux l-a așteptat de ani de zile.

De unde vine această creștere?

Există mai mulți factori care au contribuit la această evoluție, și nu cred că se poate atribui totul unui singur motiv.

Steam Deck-ul Valve continuă să joace un rol important. Dispozitivul rulează SteamOS, un sistem de operare bazat pe Arch Linux, și a introdus milioane de oameni în ecosistemul Linux fără ca aceștia să-și dea neapărat seama.

Cam un sfert din utilizatorii Linux de pe Steam sunt pe SteamOS Holo, adică pe Steam Deck, dar lucrul cu adevărat îmbucurător este că restul de trei sferturi sunt utilizatori de desktop și laptop care au ales în mod deliberat să treacă pe Linux. Asta înseamnă că creșterea nu este artificială, susținută exclusiv de o consolă portabilă, ci reflectă o adopție reală a Linux-ului ca sistem de operare principal.

Proton, stratul de compatibilitate dezvoltat de Valve, a ajuns la un nivel de maturitate remarcabil. Aproape 90% din jocurile disponibile pe Windows rulează acum pe Linux prin Proton, ceea ce a eliminat principalul obstacol care ținea jucătorii departe de Linux. Nu mai e nevoie să verifici dacă jocul tău preferat funcționează, în cele mai multe cazuri funcționează, și adesea la performanțe comparabile cu cele de pe Windows.

Sfârșitul suportului pentru Windows 10 în octombrie 2025 a împins o parte din utilizatori să caute alternative. Nu toți cei cu hardware mai vechi vor plăti pentru upgrade-ul la Windows 11 sau vor accepta cerințele suplimentare ale acestuia, și o parte din ei și-au îndreptat atenția spre Linux ca opțiune viabilă și gratuită.

Distribuțiile orientate spre gaming, precum Bazzite și CachyOS, au crescut semnificativ în popularitate. Bazzite oferă o experiență aproape plug-and-play pentru gaming pe Linux, ceea ce a redus bariera de intrare pentru utilizatorii care nu vor să petreacă ore întregi configurând sistemul. Este genul de distribuție care ar fi putut exista cu zece ani în urmă și ar fi schimbat probabil traiectoria adopției Linux-ului.

Ce înseamnă pragul de 5%?

Există de multă vreme o discuție în comunitate despre ce număr anume ar trebui să declanșeze o schimbare reală de comportament din partea dezvoltatorilor de jocuri și a producătorilor de hardware. Mulți au spus că 5% este acel prag de la care nu mai poți ignora Linux ca platformă, de la care un bug care afectează utilizatorii Linux devine un bug care afectează 1 din 20 de jucători ai tăi, un număr suficient de mare pentru a justifica o rezolvare.

AMD a fost deja vizibil mai atent la suportul pentru Linux, în parte datorită popularității Steam Deck-ului care folosește un APU AMD. Aproximativ 67-72% din utilizatorii Linux de pe Steam folosesc procesoare AMD, față de aproximativ 38-47% pe Windows, ceea ce reflectă atât succesul Steam Deck-ului, cât și preferința generală a comunității Linux pentru driverele open-source ale AMD.

Faptul că acum depășim 5% global înseamnă că argumentul „prea puțini utilizatori pentru a merita efortul" devine tot mai greu de susținut. Asta nu înseamnă că mâine toate jocurile vor primi suport nativ pentru Linux, dar înseamnă că presiunea comercială pentru compatibilitate continuă să crească.

O notă despre cum se măsoară aceste lucruri

Merită menționat că Steam Survey-ul are limitele sale. Este o anchetă voluntară și anonimă, distribuită aleatoriu utilizatorilor, și rezultatele pot fi distorsionate de valuri mari de utilizatori dintr-o anumită regiune sau limbă, cum s-a întâmplat în repetate rânduri cu utilizatorii vorbitori de chineză. Valve obișnuiește să corecteze aceste anomalii ulterior, motiv pentru care cifrele pentru unele luni au fost revizuite în sus sau în jos.

Dacă ne uităm doar la utilizatorii vorbitori de limbă engleză, procentul Linux era deja la 7,09% în noiembrie 2025. Asta pentru că o bună parte din baza globală de utilizatori Steam este concentrată în Asia, unde Linux are o prezență mai mică pe desktop. Cifrele pentru utilizatorii anglofoni oferă poate o imagine mai fidelă a tendinței în comunitățile occidentale de gaming.

Cert este că, indiferent de cum privești datele, direcția este una clară: Linux crește constant pe Steam, și o face mai repede decât o făcea acum câțiva ani.

Un gând personal

Nu sunt jucător hardcore, dar urmăresc această evoluție cu interes pentru că mă interesează ecosistemul Linux în general. Fiecare procent în plus înseamnă că mai mulți oameni descoperă că pot face aproape tot ce au nevoie pe Linux, inclusiv să se joace, fără să fie nevoiți să trăiască în lumea Microsoft. Și pentru cineva care folosește Linux de ani de zile și crede în independența digitală și în software-ul open-source, asta contează.

Acum, mai rămâne de văzut dacă cifra de 5% se va menține și va continua să crească, sau dacă va urma un recul la luna viitoare. Probabil va fi un drum cu suișuri și coborâșuri, cum a fost mereu, dar tendința pe termen lung e greu de contestat.

Am văzut o postare pe Mastodon despre Sudoku - nu mai știu exact dacă era despre un joc online sau despre altceva. Astfel mi-a venit ideea să creez un joc Sudoku online.

Problema este că nu mă pricep la programare - știu un pic de HTML. CSS știu și mai puțin, iar JavaScript nu știu deloc. Așa că am decis să încerc un experiment: i-am cerut lui Claude să construiască jocul de la zero, eu urmând să supervizez și să ajustez rezultatul.

Ce am cerut și ce am primit

Cerința inițială a fost destul de simplă - un joc de Sudoku cu trei niveluri de dificultate: ușor, mediu și greu. Claude a generat tot codul dintr-o singură solicitare, iar rezultatul a fost surprinzător de complet: generator de puzzle-uri care produce un joc unic la fiecare pornire, sistem de greșeli cu maximum trei încercări, indicii, mod de notițe pentru marcarea candidaților și navigare cu tastatura.

Design-ul a ieșit în tonuri închise, cu auriu și verde mint ca accente, destul de plăcut de privit și fără să aglomereze ecranul cu elemente inutile.

Cum am ajuns de la o idee la un fișier gata de urcat pe server

Primul lucru pe care l-am cerut după generarea inițială a fost să împart codul pe fișiere separate - index.html pentru structură, style.css pentru stiluri și script.js pentru logică. Îmi place ca lucrurile să fie organizate, iar un singur fișier uriaș nu este ceva cu care să lucrezi ușor ulterior.

Apoi am vrut o coloană cu instrucțiuni în stânga jocului, pentru că pe un ecran lat rămânea mult spațiu gol și mi se părea o risipă. Coloana a apărut, dar centrarea jocului a creat ceva bătăi de cap - sidebar-ul ocupa spațiu în layout și împingea jocul spre dreapta. Claude a rezolvat asta folosind position: fixed pentru coloana cu instrucțiuni, astfel încât jocul să rămână centrat față de întreaga pagină, independent de sidebar.

Pe ecrane mai mici, sidebar-ul dispare complet și instrucțiunile apar sub joc, ceea ce face ca totul să funcționeze decent și pe telefon sau tabletă.

S-a mai adăugat un favicon SVG - o grilă 3×3 minimalistă în culorile jocului - și un footer cu mențiunea că jocul a fost creat cu Claude AI și că tot codul este distribuit sub licența MIT.

Unde îl găsești

Jocul este disponibil la thinkroot.xyz și codul sursă este publicat pe code.linuxromania.ro pentru cine vrea să îl studieze sau să îl modifice. Nu are dependențe externe, nu folosește niciun framework și rulează complet în browser.

Ce am învățat din tot procesul

Cel mai interesant aspect nu a fost jocul în sine, ci modul în care am colaborat cu un AI pentru a-l construi. Nu am scris eu codul, dar am luat toate deciziile: ce funcționalități să aibă, cum să arate, cum să fie organizat, unde să fie publicat. Fără aceste decizii, rezultatul ar fi fost ceva generic și neinteresant.

Cred că aici este diferența dintre a folosi un AI ca pe o unealtă și a-l lăsa să decidă în locul tău.

Dacă ai chef să îl încerci, intră pe thinkroot.xyz/sudoku și dă drumul la cronometru.

Alex mi-a dat două linkuri deodată - unul către fsonline.app, un sit de filme online, și unul către Roforum.net, un forum românesc.

La primul, primul lucru care mi-a sărit în ochi nu a fost colecția de filme, ci ce scrie în footer: Fs Online © 2020 Toate drepturile rezervate. Am citit de două ori să mă asigur că nu am văzut greșit.

Ce drepturi rezervate, mai exact? Situl în cauză oferă filme fără să plătească nimănui nimic, fără licențe, fără acordul producătorilor - adică piraterie curată - și totuși proprietarul sitului a considerat că e cazul să pună acolo un copyright ca și cum ar fi o companie serioasă. Ironia asta m-a distrat mai mult decât orice film de pe sit. Practic, singurul drept pe care îl ai pe un sit de piraterie este dreptul de a nu fi prins, nu dreptul de autor.

---

Pe lângă asta, tot de la Alex am aflat și de o știre care m-a pus pe gânduri, legată de același Roforum.net - forumul a anunțat că începând din ianuarie 2025 accesul va deveni contracost:

Începând din ianuarie 2025, accesul la Roforum.net va fi contracost. Această decizie a fost luată pentru a susține platforma și a păstra calitatea discuțiilor.

Costul este de doar 10 euro pe an, ceea ce înseamnă aproximativ 0,83 euro pe lună. O sumă accesibilă pentru un mediu civilizat unde îți poți exprima opinia liber.

Sunt și de acord cu decizia asta, și nu sunt de acord, în același timp - ceea ce înseamnă că subiectul merită câteva rânduri.

Pe de o parte, înțeleg perfect situația, pentru că și eu ofer servicii gratuite în cadrul Linux România și știu că în spate există costuri reale: hosting, timp, energie, întreținere. Când ești la început, lansezi ceva gratuit ca să atragi lumea, ceea ce este normal și logic. Problema apare atunci când, după ce ai construit o comunitate pe promisiunea că totul e gratis, schimbi regulile. Nu e neapărat greșit, dar e o decizie cu dus-întors, cum am spus.

Pe de altă parte, dacă ar fi cerut o donație voluntară în loc să impună o taxă obligatorie, cred că reacțiile ar fi fost mai blânde. Există o diferență psihologică mare între „ajută-ne dacă poți„ și „plătește sau nu mai ai acces", chiar dacă suma în sine este mică - ceea ce sună a big tech..

Ce mă bucură, totuși, este că forumul este activ - și asta e mare lucru în 2026, când forumurile românești au cam fost abandonate unul câte unul. Un spațiu unde oamenii se adună să discute în română, fără să fie subordonat algoritmilor vreunei rețele sociale, merită să existe, indiferent de modelul de finanțare ales.

MidnightBSD este un sistem de operare de tip BSD orientat spre desktop, derivat din FreeBSD, cu propriul său sistem de pachete numit mports și cu o comunitate relativ mică, dar dedicată. Versiunea 4.0.4, lansată la finalul lunii martie 2025, aduce o noutate care a stârnit destul de multă discuție: introducerea unui mecanism de verificare a vârstei direct în sistemul de operare, ca răspuns la presiunile legislative din Statele Unite.

Practic, au apărut două programe noi în sistem: aged și agectl. Primul este un daemon care pornește automat la boot și gestionează informații despre vârsta utilizatorilor înregistrați, iar al doilea este instrumentul din linia de comandă prin care poți seta vârsta unui cont sau data de naștere. Comanda adduser a fost modificată pentru a întreba de vârstă la crearea unui cont nou, iar managerul de pachete mport va verifica grupul de vârstă al utilizatorului care instalează pachete și va aplica reguli de control al accesului negative pentru a bloca anumite aplicații în cazul celor care nu au vârsta minimă necesară. La momentul lansării, niciun pachet din mports nu are o restricție de vârstă setată, deci în practică mecanismul există, dar nu face nimic concret deocamdată.

Contextul din spatele acestei decizii este unul destul de îngrijorător dacă ne gândim la implicațiile mai largi: mai multe state din SUA au adoptat sau intenționează să adopte legi care impun verificarea vârstei la nivel de sistem de operare, nu doar la nivel de aplicație sau website. Autorii MidnightBSD au ales să implementeze acest mecanism în avans, pentru a putea respecta aceste cerințe legale fără a fi luați prin surprindere. Dacă locuiești într-o jurisdicție fără astfel de legi, poți dezactiva daemonul cu sysrc aged_enable=NO în /etc/rc.conf și nu va mai porni la boot.

Din punct de vedere tehnic, developerii au expus și un API pentru cei care vor să integreze această funcționalitate în propriile aplicații, prin două funcții disponibile în libutil - una pentru a obține grupul de vârstă al unui utilizator și una pentru a seta vârsta. Este o abordare corectă din perspectiva ingineriei: nu forțezi o soluție rigidă, ci pui la dispoziție funcții de bază pe care alții le pot folosi în propriile aplicații.

Contextul mai larg este unul care merită urmărit cu atenție: dacă astfel de legi se extind și ajung să impună cerințe tot mai complexe, proiectele independente cu resurse limitate vor fi primele care vor resimți presiunea, fără să aibă mijloacele necesare pentru a răspunde.

Dacă ești nou în domeniul HomeLab/VPS cum sunt și eu, la un moment dat dai peste termenul bare-metal și, la fel de inevitabil, te întrebi la ce anume se referă lumea când îl folosește. Nu e nimic complicat la mijloc, deși la prima vedere poate părea un concept abstract.

Bare-metal înseamnă, la modul cel mai simplu, că rulezi programe direct pe hardware fizic, fără niciun strat de virtualizare între ele. Metalul gol, cum ar veni - hardware-ul real, fără nimic altceva pus deasupra înainte să ajungi la sistemul de operare sau la aplicație.

Serverele bare-metal

Contextul în care auzi cel mai des termenul este cel al serverelor. Când închiriezi un VPS de la un furnizor de hosting, de fapt închiriezi o mașină virtuală care rulează pe un server fizic undeva într-un datacenter, alături de zeci sau poate sute de alte mașini virtuale ale altor clienți. Resursele hardware - procesorul, memoria RAM, stocarea - sunt împărțite între toți.

Un server bare-metal e altceva: închiriezi sau deții un server fizic dedicat în întregime ție. Nimeni altcineva nu împarte resursele cu tine, nu există hypervisor care să gestioneze mai mulți utilizatori pe același hardware, și ai acces direct la tot ce oferă mașina respectivă. Evident, asta vine de obicei cu un cost mai mare, dar și cu performanță și predictibilitate mai bune.

Instalare bare-metal

Al doilea context în care apare termenul este cel al instalării unui sistem de operare. Când instalezi Linux direct pe calculatorul sau pe serverul tău, aia e o instalare bare-metal - sistemul de operare rulează direct pe hardware, nu într-o mașină virtuală sau într-un container. Probabil că și tu ai făcut asta de mai multe ori fără să-i fi spus astfel.

Hypervisori de tip bare-metal

Există și o categorie de hypervisori - adică de programe care gestionează mașini virtuale - care rulează direct pe hardware, fără să aibă nevoie de un sistem de operare gazdă dedesubt. Acestea se numesc hypervisori de tip 1 sau bare-metal hypervisors. Proxmox, VMware ESXi sau Hyper-V sunt exemple cunoscute. Spre deosebire de ele, VirtualBox sau VMware Workstation sunt hypervisori de tip 2, adică rulează ca aplicații obișnuite peste un sistem de operare existent.

De ce contează distincția

În practică, distincția între bare-metal și virtualizat contează mai ales când ai nevoie de performanță maximă, de acces direct la anumite dispozitive hardware sau când vrei să eviți orice overhead introdus de un strat suplimentar de programe. Jocurile și aplicațiile care lucrează intensiv cu procesorul grafic, de exemplu, merg mult mai bine pe bare-metal decât într-o mașină virtuală.

Pe de altă parte, virtualizarea îți oferă flexibilitate și izolare - poți rula mai multe sisteme de operare pe același hardware, poți face snapshot-uri, poți migra mașini virtuale. Fiecare abordare are locul ei.

Ori de câte ori auzi bare-metal, ideea esențială rămâne aceeași: hardware real, fără virtualizare la mijloc.

Există o tendință care mă deranjează de ceva vreme și pe care nu am mai rezistat să nu o spun cu voce tare: tot mai multe jurnale și situri adoptă o temă întunecată ca și cum ar fi un semn de bun gust sau de modernitate, iar eu, ca vizitator, ajung să închid tab-ul mai repede decât am apucat să citesc primul paragraf.

Problema mea nu este cu modul întunecat în sine, pentru că înțeleg că există oameni care îl preferă, mai ales seara sau noaptea, când lumina unui ecran alb poate obosi ochii. Problema mea este cu acele pagini care au fundalul complet negru și textul alb sau de altă culoare deschisă, un contrast atât de dur încât, după câteva minute de citit, ochii încep să mă doară efectiv. Ziua, când lumina naturală este prezentă și ecranul meu este calibrat pentru acel context, un fond negru cu text alb devine aproape insuportabil de citit.

Știu că există plugin-uri pentru navigator care pot rezolva această problemă, dar nu am de gând să le instalez, pentru că nu vreau să încarc navigatorul cu tot felul de extensii doar ca să pot citi confortabil o pagină. Cu cât adaugi mai multe plugin-uri cu atât navigatorul merge mai greu, consumă mai multă memorie și, la un moment dat, ajungi să ai mai multe extensii decât pagini vizitate zilnic, ceea ce nu mi se pare o soluție serioasă.

Ceea ce m-ar mulțumi cu adevărat este să existe un buton simplu de comutare între o temă luminoasă și una întunecată, direct pe pagina respectivă, astfel încât fiecare vizitator să poată alege ce i se potrivește. Nu este o funcționalitate greu de implementat și există multe platforme de blogging sau teme pentru WordPress, Hugo sau alte generatoare de situri statice care o oferă deja din instalare. Este o chestiune de respect față de cei care îți citesc conținutul, pentru că nu toți avem aceleași preferințe și nu toți citim la aceleași ore din zi.

Înțeleg că pentru unii autori aspectul vizual al jurnalului este o chestiune personală și că tema întunecată poate părea mai elegantă sau mai tehnică, mai ales în spațiile dedicate programatorilor sau pasionaților de Linux. Și eu am o oarecare afinitate pentru estetica aceea, recunosc. Dar există o diferență mare între o temă întunecată bine gândită, cu contrast suficient și culori alese cu grijă, și un fond negru pur pe care s-a aruncat text alb fără nicio altă considerație.

Nu știu dacă această problemă o să se rezolve de la sine pe măsură ce mai mulți autori devin conștienți de importanța accesibilității vizuale, dar știu că astfel de situri le vizitez rar și le închid destul de repede, indiferent cât de bun ar fi conținutul. Conținutul bun contează, dar nu suficient cât să îmi sacrific confortul vizual de fiecare dată când îl accesez.