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.

Mi-au rămas legumele fierte de la supa de tăiței. Ca să nu arunc legumele am improvizat o rețetă rapidă 😀

Ingrediente

• 1 cartof
• 3 morcovi
• 2 păstârnaci
• 1 țelină
• 3 căței de usturoi
• 1 ceapă
• zeamă de supă
• un pic de unt
• 2 lingurițe iaurt grecesc
• boia dulce
• sare
• piper

Pași

1. Am tocat legumele în tocătorul electric până s-au făcut ca o pastă - se poate folosi și blender.
2. Conținutul l-am turnat într-un bol și am amestecat cu sare, piper, boia și zeama de la supă.
3. Am amestecat bine cu telul. După care am pus compoziția la încălzit (dacă legumele sunt calde nu mai este nevoie de pus la încălzit).
4. După ce s-a încălzit am adăugat untul și am amestecat până s-a topit complet.
5. La final am pus iaurt. Bineînțeles după ce am luat oala de pe foc.

Note Legumele pot fi fierte special pentru această rețetă sau rămase de la o supă. Cu cât zeama de supă e mai gustoasă, cu atât crema iese mai bună. Iaurtul se adaugă obligatoriu după ce dai oala jos de pe focul, altfel se taie.

Săptămâna trecută, GitHub a anunțat că, începând cu 24 aprilie, datele tale de interacțiune cu Copilot vor fi folosite pentru antrenarea modelelor de inteligență artificială ale Microsoft. Dacă vrei să ieși din această schemă, trebuie să cauți singur setarea și să o dezactivezi.

Am renunțat la GitHub și drumul a fost destul de lung: am plecat de la GitHub, am trecut prin GitLab, am ajuns la Codeberg și, în final, m-am stabilit pe Forgejo - pe care îl găzduiesc la cod.linuxromania.ro. Am ajuns acolo tocmai pentru că nu am vrut să depind de bunăvoința unei companii mari, iar ce se întâmplă acum cu GitHub mi-a confirmat că instinctul acela a fost corect.

O promisiune făcută public, uitată în liniște

Când Microsoft a cumpărat GitHub în 2018 pentru 7,5 miliarde de dolari, lumea dezvoltatorilor a fost nervoasă. Microsoft era compania care numise Linux „un cancer", care îngropase Netscape cu Internet Explorer și care tratase dezvoltatorii ca pe un public captiv. Cedarea celei mai mari platforme de cod din lume în mâinile lor părea, pentru mulți, o greșeală.

Satya Nadella știa asta, și tocmai de aceea a promis explicit, în scris, pe jurnalul oficial al Microsoft: GitHub va funcționa independent, va păstra spiritul orientat către dezvoltatori și va rămâne o platformă deschisă. Mai mult decât atât, i-a invitat pe oameni să-i judece după fapte, nu după vorbe.

În august 2025, CEO-ul GitHub, Thomas Dohmke, a plecat fără ca Microsoft să anunțe un succesor. În schimb, GitHub a fost absorbit în divizia CoreAI a Microsoft, condusă de Jay Parikh. Fără ceremonie, fără comunicat, fără nicio recunoaștere publică a faptului că promisiunea de independență tocmai încetase să mai fie valabilă.

Și în martie 2026, a venit și pasul următor: datele tale de interacțiune cu Copilot vor hrăni modelele de inteligență artificială ale Microsoft, dacă nu te deranjezi să oprești asta manual.

Ce înseamnă, concret, „date de interacțiune"

Merită să citești cu atenție ce intră în această categorie, pentru că nu e vorba doar de codul pe care îl scrii. Sunt incluse mesajele pe care le trimiți către Copilot, sugestiile pe care le accepți sau le modifici, contextul din jurul cursorului tău, comentariile și documentația pe care le redactezi, numele fișierelor și structura depozitului, modul în care navighezi prin funcționalitățile Copilot și chiar feedback-ul dat cu butonul de apreciere sau dezaprobare.

Aceste date ajung la GitHub și la „afiliații" săi - adică, după cum precizează ei înșiși în politica de confidențialitate actualizată, la Microsoft.

Există o excepție: dacă ești client de tip Business sau Enterprise, contractul tău corporativ interzice explicit această utilizare a datelor. Ești protejat. Dacă ești dezvoltator individual, colaborator la proiecte open source sau un simplu utilizator care lucrează pe un cont personal, ești inclus în schemă până când ieși singur din ea.

Oamenii care au construit comunitatea ce a făcut GitHub să valoreze 7,5 miliarde de dolari sunt exact cei cărora li se aplică această politică. Clienții corporativi cu contracte mari au protecție.

Răspunsul comunității

Imediat după anunț, au apărut ghiduri de migrare către Codeberg și Forgejo. Nu reacții furioase pe rețelele de socializare, ci documentație concretă: pași pentru mutarea depozitelor, redirecționarea legăturilor, reconfigurarea pipeline-urilor de integrare continuă.

Asta spune ceva important. Utilizatorii care au ani de istoric de commit-uri, fire de discuții, configurații complexe și o prezență publică legată de GitHub - adică exact oamenii pentru care costul plecării este cel mai mare - au ales să scrie instrucțiuni de ieșire în loc să depună reclamații.

Eu am trecut prin același proces ceva mai devreme, și pot spune că migrarea nu este la fel de complicată pe cât pare la prima vedere. Există instrumente care importă depozitele împreună cu issues, pull request-uri, etichete și release-uri - nu e nevoie să o iei de la zero cu linia de comandă.

Ce poți face acum

Dacă folosești în continuare GitHub și ai Copilot activ, poți dezactiva această opțiune din Setări → Copilot → Confidențialitate → „Allow GitHub to use my data for AI model training". Dacă ai mai multe conturi, trebuie să faci asta pentru fiecare în parte.

Dacă vrei să mergi mai departe și să nu mai depinzi de bunăvoința unei companii care a demonstrat că o poate retrage oricând, Codeberg este o alternativă găzduită de o organizație non-profit, cu sediul în Europa, fără finanțare de risc. Iar dacă preferi să controlezi tu totul, Forgejo poate fi instalat pe propriul tău server.

Eu am ajuns la concluzia asta cu ceva timp în urmă și nu mi-a părut rău nicio clipă. Codul stă acum pe o instanță Forgejo la cod.linuxromania.ro - indiferent de ce decide vreo corporație despre politica sa de confidențialitate.

Nadella a spus că să fim judecați după fapte. Sfat bun. Mai ales acum.