Există proiecte open-source care apar, bifează câteva stele pe GitHub și dispar la fel de discret cum au venit. TuxPulse nu este unul dintre ele. De-a lungul a șase versiuni majore, proiectul a trecut printr-o transformare pe care puțini ar fi anticipat-o la început - de la un experiment în Python la o rescriere completă în Rust, după un audit de securitate care a pus totul sub semnul întrebării.

Un proiect construit în public, cu tot ce implică asta

TuxPulse a pornit modest, ca un exercițiu personal al dezvoltatorului. Prima versiune nu impresiona prin complexitate, dar stabilea un punct de plecare. Ceea ce a urmat a fost un proces vizibil pentru oricine urmărea repository-ul: versiunile s-au succedat rapid, fiecare aducând câte ceva în plus față de precedenta.

Momentul care a dat cu adevărat sens proiectului a fost v3.0, când a apărut un catalog de aplicații cu posibilitatea de instalare cu un singur clic - sau în lot, dacă voiai mai multe deodată. Nu mai era un script de sistem oarecare, ci un tool cu o utilitate concretă. Versiunea 4.0 a adus un redesign al interfeței și o restructurare a logicii interne. Versiunile 5.x și-au propus extinderea compatibilității spre Fedora și Arch Linux.

Pe hârtie, traiectoria părea liniară și promițătoare.

Când un audit îți arată ce nu voiai să știi

La un moment dat, cineva din comunitate a propus un audit de securitate al aplicației. Dezvoltatorul a acceptat. Concluzia a fost dureroasă: structura internă a codului introducea vulnerabilități serioase, iar lista problemelor identificate nu era scurtă.

Reacția inițială a fost să abandoneze proiectul. Este greu să construiești ceva versiune după versiune și apoi să afli că fundația are fisuri. Dar după o scurtă perioadă de reflecție, decizia a fost să repare, nu să renunțe. Versiunea v5.2 a rezolvat problemele cele mai critice și a stabilizat temporar situația.

Temporar - pentru că soluțiile aplicate tratau simptomele, nu cauza.

De ce Rust

Python a fost alegerea naturală la început: accesibil, rapid de scris, suficient pentru un proiect experimental. Dar un tool de sistem care rulează cu privilegii ridicate are cerințe diferite față de un script obișnuit. Siguranța la nivel de memorie, performanța și controlul fin asupra resurselor sunt lucruri pe care Python nu le poate garanta în același mod.

Dezvoltatorul mai scrisese în Rust - o aplicație de întreținere pentru sisteme Windows. Comparând cele două experiențe, concluzia a fost clară: pentru ceea ce urma să devină TuxPulse, Rust era singura alegere care avea sens pe termen lung.

Așa că totul a luat-o de la capăt.

Versiunile 6.0.0 și 6.0.1

v6.0.0 este primul pre-release al noii generații - o aplicație rescrisă integral, cu o interfață regândită și cu securitatea tratată ca prioritate de la primul rând de cod, nu ca un strat adăugat ulterior. v6.0.1 continuă în aceeași direcție, adăugând detalii treptat.

TuxPulse nu face telemetrie, nu colectează niciun fel de date și rămâne complet gratuit și open-source. Este un proiect construit din curiozitate și menținut din principiu - exact tipul de software pe care comunitatea Linux îl merită mai des.

Dacă vreți să îl testați sau să contribuiți, codul se găsește în întregime pe GitHub.

Pe 9 aprilie 2026, ultimul angajat plătit al Session Technology Foundation (STF) și-a încheiat ultima zi de muncă. De atunci, una dintre cele mai serioase alternative private la WhatsApp și Signal este dezvoltat exclusiv de voluntari, cu infrastructura finanțată doar până pe 8 iulie 2026. Dacă până atunci nu sunt strânși 1 milion de dolari, proiectul se închide.

Ce este Session

Session este un messenger open source, criptat end-to-end, care nu îți cere nici număr de telefon, nici adresă de email pentru a-l folosi. La înregistrare primești pur și simplu un ID generat aleatoriu. Mesajele nu trec printr-un server central, ci printr-o rețea de tip onion routing - similar cu Tor - ceea ce face ca metadatele să nu fie colectate deloc. Cine vorbești, când, cu cine - nimic din toate astea nu ajunge nicăieri.

Peste 1,5 milioane de oameni îl folosesc lunar. A fost descărcat de peste 13 milioane de ori. A ajuns un instrument important pentru jurnaliști, activiști și cetățeni din țări unde guvernele blochează sau monitorizează comunicațiile. În perioada conflictului din Iran, echipa Session a înregistrat în jur de 50.000 de conturi noi pe zi, doar din acea regiune.

Cum s-a ajuns aici

Chris McCabe, co-fondatorul Session, a publicat în martie 2026 un apel personal în care explica situația fără menajamente: organizațiile care stau în spatele proiectului au trecut prin ani dificili, iar supraviețuirea lui nu mai este garantată. El cerea ca fiecare utilizator să contribuie cu cel puțin un dolar - dacă toți cei care folosesc aplicația ar fi făcut asta, problema ar fi fost rezolvată pe loc.

Nu s-a întâmplat. Comunitatea a donat, dar insuficient. Până la data de față, STF a primit aproximativ 65.000 de dolari - bani care ajung să țină infrastructura de bază în viață până pe 8 iulie, dar nu și să plătească programatori.

Rezultatul este că dezvoltarea este oprită. Nu vor fi lansate versiuni noi în această perioadă. Defectele existente vor rămâne cel mai probabil nerezolvate. Funcționalitățile în lucru - Protocol v2, care aduce forward secrecy, criptografie post-quantum și gestionare îmbunătățită a dispozitivelor, și Session Pro, un abonament premium menit să asigure sustenabilitate financiară pe termen lung - au fost înghețate.

De ce contează

Trăim într-un moment în care supravegherea digitală devine tot mai normalizată. Platforma pe care o folosești pentru a comunica cu familia, cu colegii, cu prietenii nu e neutră - fiecare mesaj trimis printr-un serviciu centralizat poate fi, la un moment dat, accesat, interceptat sau folosit împotriva ta.

Session nu e perfect. Are probleme de adopție, interfața nu e la fel de șlefuită ca Signal, și modelul de finanțare s-a dovedit fragil. Dar ideea din spatele lui - un messenger care nu știe cine ești și nu poate ști cu cine vorbești - rămâne valoroasă. Și e greu de înlocuit.

Dacă proiectul dispare, codul rămâne pe GitHub. Poate că cineva va continua. Poate că nu. Dar o comunitate de 1,5 milioane de utilizatori activi care nu reușește să strângă 1 milion de dolari pentru a salva un instrument care îi protejează spune ceva despre cât de mult prețuim cu adevărat confidențialitatea - nu în vorbe, ci în fapte.

Dacă proiectul îți pare valoros, STF acceptă donații la getsession.org/donate. Termenul limită e 8 iulie 2026.

Am mai citit câteva știri despre războiul din Iran. De această dată SUA a arătat cât de slabă este. Și pierde un război important și acest lucru îl vede China și Rusia, dar și Europa.

Europa sper să învețe ceva din acest lucru și din toate experiențele cu SUA de când Trump este Președinte.

Pe 8 aprilie 2026, guvernul francez a făcut un anunț pe care mulți dintre noi îl așteptau de mult timp: DINUM, direcția interministerială pentru digitalizare a Franței, a anunțat oficial că statul va abandona Windows-ul în favoarea Linux pe stațiile de lucru guvernamentale. Nu e un zvon, nu e un pilot izolat undeva într-un colț de minister - e o declarație formală, publicată pe situl oficial al guvernului, cu ministri care semnează și cu termene concrete.

Contextul mai larg este că Franța vrea să-și reducă dependența față de tehnologiile digitale din afara Europei, iar această mișcare face parte dintr-o strategie mai amplă de suveranitate digitală. Ministrul David Amiel a spus-o destul de direct: statul nu mai poate accepta să depindă de soluții ale căror reguli, tarife și evoluții nu le controlează nimeni din Europa. Suveranitatea digitală nu mai e o opțiune, e o necesitate - cam ăsta e mesajul.

Concret, DINUM va coordona un plan interministerial, iar fiecare minister (inclusiv operatorii publici) trebuie să-și formalizeze propriul plan până în toamnă, acoperind mai multe domenii: stațiile de lucru, uneltele de colaborare, antivirusul, inteligența artificială, bazele de date, virtualizarea și echipamentele de rețea. Practic, un audit complet al dependențelor tehnologice, cu un calendar clar pentru reducerea lor.

Nu e vorba doar de desktop-uri, cum explică și cei de la Linuxiac. Franța poziționează adoptarea Linux-ului ca parte dintr-o politică mai largă axată pe suveranitate și interoperabilitate. Paralel cu asta, Casa Națională de Asigurări de Sănătate migrează cei 80.000 de angajați ai săi către unelte din suita interministerială suverană - Tchap, Visio și FranceTransfert - iar platforma de date de sănătate urmează să fie mutată pe o soluție de încredere până la finalul lui 2026.

Ce distribuție Linux vor folosi? Deocamdată nu se știe, decizia urmând să vină ceva mai târziu, pe măsură ce fiecare minister își conturează planul propriu. Primele „întâlniri industriale ale digitalului" sunt programate pentru iunie 2026, unde se vor formaliza coalițiile public-privat pentru suveranitate europeană.

Ce mi se pare important de subliniat e că nu vorbim despre o aventură idealistă a unor entuziaști Linux dintr-un birou oarecare, ci despre o decizie politică la cel mai înalt nivel, cu responsabilități clare și termene asumate public. E genul de mișcare pe care, dacă o face o țară de talia Franței, devine greu de ignorat și pentru celelalte guverne europene.

Și inevitabil mă gândesc la România, care plătește în continuare licențe Microsoft din bani publici, fără ca subiectul să ajungă vreodată cu adevărat pe agenda nimănui. Nu cer miracole, dar măcar o discuție serioasă la nivel guvernamental despre suveranitate digitală și soluții open source ar fi un început. Franța a demonstrat că se poate, că există voință politică și că nu e nevoie să aștepți ca Microsoft să-ți spună când și cum îți upgradezi infrastructura. Rămâne de văzut dacă și la noi se trezește cineva la un moment dat.

De două ori în același număr de săptămâni, m-am trezit cu Nextcloud inaccesibil și cu un mesaj de eroare despre directorul de date invalid. De fiecare dată, cauza era aceeași: HDD-ul extern pe care îl folosesc ca stocare principală pe thinkserver nu mai era montat.

Prima dată am crezut că am uitat să-l adaug în /etc/fstab. L-am montat manual, am adăugat intrarea corectă cu opțiunile defaults,nofail și am crezut că am rezolvat problema. La câteva zile distanță, același scenariu. De data aceasta era clar că ceva mai adânc nu funcționează cum trebuie.

Ce spuneau jurnalele

Am rulat sudo journalctl -b | grep -i "mnt|sd|fstab|mount" și răspunsul a fost imediat. La ora 6:36 dimineața pe 4 aprilie, și din nou la 6:20 pe 9 aprilie, apăreau aceste mesaje în jurnal:

device offline error, dev sdb, sector 0 op 0x1:(WRITE)
EXT4-fs (sdb1): shut down requested (2)
Aborting journal on device sdb1-8.
systemd: Unmounting mnt-data.mount - /mnt/data...
systemd: mnt-data.mount: Deactivated successfully.

Kernelul detecta că device-ul a dispărut brusc în timp ce scria pe el, oprea jurnalul EXT4 ca să nu corupă datele, și demonta partiția în mod de urgență. HDD-ul se reconecta imediat după, dar cu un alt device name - sdb devenea sdc și invers - iar systemd nu îl remonta automat.

Problema nu era în fstab. Problema era că HDD-ul se deconecta fizic.

Cauza: USB autosuspend

HDD-ul este conectat printr-un adaptor USB-SATA cu chipset JMicron JMS578. Linux are o funcție numită USB autosuspend care pune device-urile USB în sleep după o perioadă de inactivitate pentru a economisi energie. Valoarea implicită pe acest sistem era de 2000 de milisecunde - adică 2 secunde de inactivitate erau suficiente pentru a suspenda adaptorul.

În timpul zilei, cu containere Docker care accesează constant datele de pe HDD, autosuspend-ul nu apuca să intre în acțiune. Dar noaptea, după ore de inactivitate, adaptorul intra în sleep și nu se trezea corect atunci când kernelul încerca să scrie pe el. Rezultatul era device offline error și demontarea de urgență.

Am confirmat că autosuspend-ul era activ cu:

for d in /sys/bus/usb/devices/*/idVendor; do
  vendor=$(cat $d)
  if [ "$vendor" = "152d" ]; then
    dir=$(dirname $d)
    echo "autosuspend_delay_ms: $(cat $dir/power/autosuspend_delay_ms)"
  fi
done

Rezultatul: autosuspend_delay_ms: 2000.

Rezolvarea

Soluția este să forțezi device-ul USB să rămână activ permanent prin setarea power/control la valoarea on:

for d in /sys/bus/usb/devices/*/idVendor; do
  vendor=$(cat $d)
  if [ "$vendor" = "152d" ]; then
    dir=$(dirname $d)
    echo on | sudo tee $dir/power/control
  fi
done

Cu control: on, valoarea autosuspend_delay_ms este ignorată complet, indiferent ce valoare are.

Pentru ca setarea să persiste după reboot, am creat o regulă udev:

sudo nano /etc/udev/rules.d/99-usb-hdd-nosuspend.rules

Cu conținutul:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="152d", ATTR{idProduct}=="0578", ATTR{power/autosuspend_delay_ms}="-1", ATTR{power/control}="on"

Valorile idVendor și idProduct le-am obținut din lsusb. Regula se aplică de fiecare dată când adaptorul este detectat de sistem, fie la boot, fie după o reconectare fizică.

Am reîncărcat regulile udev și am remontat HDD-ul:

sudo udevadm control --reload-rules
sudo mount -a

Ce am învățat

Un HDD extern conectat prin USB nu se comportă la fel ca unul intern conectat SATA. Kernelul îl tratează ca pe orice alt device USB și îi aplică politicile de economisire a energiei, indiferent că pe el rulează date critice pentru servicii. Opțiunea nofail din fstab este utilă - împiedică sistemul să se blocheze la boot dacă HDD-ul nu e disponibil - dar nu face nimic pentru a preveni demontarea în timpul funcționării.

Dacă folosești un HDD extern ca stocare pentru servicii self-hosted, autosuspend-ul USB este primul lucru pe care trebuie să-l dezactivezi.

Nu am treabă cu programarea și nici nu lucrez în IT, dar am dat peste câteva articole care m-au prins și am rămas să citesc până la capăt. Primul a fost The Cathedral, the Bazaar, and the Catacombs al lui Andrew Nesbitt, care extinde o metaforă mai veche pe care o știam vag - și tot citind am ajuns să înțeleg lucruri pe care credeam că le știam deja.

Catedrala și Bazarul

Știu că există cartea The Cathedral and the Bazaar, scrisă de Eric S. Raymond și publicată prima dată ca eseu în 1997, dar crezusem că este despre Linux și open source în general. De fapt este despre cum se construiește software, iar Linux e doar exemplul care demonstrează că un anumit mod de a lucra funcționează mai bine decât altul.

Modelul Catedralei este cel clasic - o echipă mică, bine organizată, lucrează în liniște și lansează programe rafinate la intervale mari de timp. Proiectul GNU al lui Richard Stallman era exemplul tipic: arhitectură gândită cu atenție, control strict, calitate ridicată, dar ritm lent.

Modelul Bazarului descrie exact opusul - felul în care Linux s-a construit: cod publicat devreme și frecvent, contribuitori din toată lumea, discuții publice, iterații rapide. Pe hârtie nu ar fi trebuit să funcționeze, dar a funcționat extraordinar de bine. Din acest model s-a născut și Legea lui Linus: given enough eyeballs, all bugs are shallow - cu suficienți oameni care se uită la cod, orice problemă devine ușor de găsit. ESR a botezat-o astfel în onoarea lui Linus Torvalds, iar ea a rămas până astăzi argumentul tehnic central al dezvoltării open source.

Al treilea model: Casa Misterelor

Până de curând, discuția se oprea aici. Dar Drew Breunig a adăugat în martie 2026 un al treilea model, inspirat de o clădire reală din San Jose, California - Winchester Mystery House, reședința Sarei Winchester, văduva moștenitorului fabricantului de arme Winchester.

Sarah Winchester a construit această casă timp de 38 de ani neîntrerupt, fără arhitect, ghidată exclusiv de propriile gusturi și de banii pe care îi avea din belșug. Rezultatul este o clădire cu 160 de camere, scări care duc în tavan, uși care se deschid spre perete și coridoare care nu duc nicăieri. Nu pentru că Sarah era nebună, ci pentru că fiecare decizie avea sens local, în momentul în care era luată, fără nicio grijă față de ansamblul final.

Breunig observă că mulți programatori din era AI construiesc exact în felul acesta. Când un agent de cod poate genera 1.000 de linii pe commit - față de cele 10-30 pe care le scrie un om pe zi - costul codului scade dramatic și nu mai ai nevoie de echipă, de plan de ansamblu sau de feedback extern. Construiești ce vrei, pentru tine, ghidat de propriile nevoi. Rezultatul este un program idiosincratic, sprawling și, în fond, distractiv de construit - exact ca o casă a misterelor.

Problema cu acest model nu este că produce cod prost în mod necesar, ci că singurul feedback disponibil ești tu însuți. Legea lui Linus se bazează pe ochi externi, pe oameni care privesc codul din unghiuri diferite. Dacă singura buclă de feedback ești tu, dacă singura buclă de feedback ești tu, viteza e maximă, dar perspectivele sunt zero.

Catacombele, pe care toată lumea le ignoră

Și ajungem la ideea care m-a mirat cel mai tare, cea a lui Nesbitt. El observă că în aproape 30 de ani de discuții despre Catedrală și Bazar, nimeni nu a scris despre ce se află sub ambele modele - rețeaua de dependențe tranzitive, pe care Nesbitt o numește Catacombele.

Un proiect JavaScript obișnuit trage sute de dependențe pe care nimeni din echipă nu le-a citit vreodată, scrise de oameni pe care nu i-a auzit nimeni niciodată, actualizate ultima dată acum câțiva ani de un întreținător care aproape că a uitat că pachetul respectiv există. Și totuși, acel pachet ține în picioare tot ce ai construit deasupra lui.

Legea lui Linus presupune că există ochi care se uită. Dar în catacombe nu se uită nimeni sistematic - nici arhitecții din Catedrală, nici mulțimea din Bazar. Și tocmai de aceea catacombele devin vectori de atac. Backdoor-ul xz din 2024 nu a forțat nicio ușă principală - un co-întreținător a petrecut doi ani câștigând încrederea comunității pentru o bibliotecă de compresie aflată adânc în rețeaua de dependențe al aproape oricărui sistem Linux, iar codul malițios a intrat prin acea ușă laterală, nevăzută de nimeni.

Nesbitt arată că nici modelul Casei Misterelor nu ajută la rezolvarea problemei - din contră, o agravează. Agenții de cod trag dependențe mult mai agresiv decât ar face-o un om, extind această rețea în direcții pe care e greu să le revizuiești chiar și în principiu, și nu au niciun stimulent să se întrebe ce se află sub fundație.

Ce rămâne

Cele trei modele descriu cum se construiesc programele - cine participă, ce forță economică sau tehnologică face procesul posibil, cum arată feedback-ul. Catacombele nu sunt un al patrulea model, ci un strat care există indiferent de modelul ales, comun tuturor. Poți construi o Catedrală sau un Bazar sau o Casă a Misterelor - sub toate există același labirint de tuneluri pe care nimeni nu l-a proiectat ca întreg și pe care puțini îl înțeleg cu adevărat.

Internetul a ieftinit coordonarea și ne-a dat Bazarul. AI-ul a ieftinit codul și ne-a dat Casa Misterelor. Ce nu am rezolvat încă este cum să facem catacombele mai puțin opace - și asta pare să fie problema următorilor ani. Eu unul nu am nicio soluție, dar mi se pare că e o întrebare care merită pusă și de oameni din afara domeniului.

Dacă stai cât de cât pe rețelele sociale sau citești știri despre tehnologie, probabil ai dat peste același tip de postare: AI-ul va elimina doctorii, avocații, programatorii, șoferii și aproape orice altă meserie la care te-ai gândit. Unii entuziaști din tech spun asta cu o asemenea convingere, încât e greu să nu te ia cu griji.

Și înțeleg de ce lumea e îngrijorată. Părinții nu știu ce meserie să le recomande copiilor, tinerii nu știu dacă are sens să se apuce de o facultate sau un domeniu care poate că nu va mai exista când termină. E o întrebare legitimă.

Numai că am mai văzut această panică și înainte.

Când a apărut mașina cu aburi, muncitorii din fabrici erau convinși că rămân fără rost. Când tractorul a înlocuit munca la câmp, lumea se întreba ce se va alege de cei care trăiau din agricultura manuală. Când calculatoarele personale au intrat în birouri, contabilii și dactilografele simțeau că pământul le fuge de sub picioare.

De fiecare dată, lucrurile s-au schimbat cu adevărat. Unele meserii au dispărut sau s-au transformat atât de mult, încât mai păstrează doar numele. Dar în locul lor au apărut altele pe care nimeni nu le anticipase, iar lumea a mers mai departe.

Nu vreau să zic că de data asta nu e nimic diferit. AI-ul evoluează mai repede decât orice tehnologie anterioară și, spre deosebire de tractor sau de mașina industrială, afectează și munca intelectuală, nu doar pe cea fizică. Asta e o schimbare reală și ar fi naiv să o ignorăm.

Dar e o diferență mare între „lucrurile se schimbă și trebuie să ne adaptăm„ și „totul va dispărea și nu mai are rost să faci nimic". Prima e adevărată. A doua e o exagerare care îți face mai mult rău decât bine.

Oamenii s-au recalificat mereu. Bunicii noștri au trecut de la plug la tractor fără să fi făcut vreun curs de reconversie profesională. Părinții noștri au învățat să lucreze cu calculatorul la o vârstă la care mulți ar fi zis că e prea complicat. Noi vom învăța să lucrăm cu AI-ul.

Avem și un avantaj față de generațiile anterioare: accesul la resurse de învățare e mai mare ca oricând. Poți să înveți aproape orice online, gratuit sau la un cost mic. Singura barieră reală e dacă vrei sau nu.

Dacă ești îngrijorat, încearcă să nu te uiți prea mult la scenariile catastrofice de pe internet. Istoria a arătat că omul se adaptează, că apar locuri de muncă noi și că valurile tehnologice, oricât de mari, nu au lăsat în urmă o lume fără muncă. Au lăsat o lume diferită, dar nu neapărat mai rea.

Lumea merge mai departe. A făcut-o mereu.

Când am scris prima oară despre TuxPulse, era la versiunea 3.0 și tocmai primise un app store integrat, suport pentru mai multe distribuții și o arhitectură nouă care separa interfața grafică de operațiunile cu privilegii de root. De atunci, proiectul s-a mișcat repede - poate mai repede decât m-aș fi așteptat pentru o aplicație atât de tânără. În intervalul dintre 20 martie și 7 aprilie 2026 au apărut nu mai puțin de șapte versiuni noi, iar ultima dintre ele, v4.0, a adus suficiente schimbări ca să merite o privire mai atentă.

Cum arată drumul de la v3.0 la v4.0

Versiunile 3.1 și 3.2 au venit la câteva zile după 3.0 și au rezolvat lucruri concrete din tab-ul Installer: interfața a început să facă distincție vizuală între aplicațiile instalate și cele care nu sunt pe sistem, logica de căutare a fost ajustată ca să verifice mai întâi pachetele native și abia apoi Flatpak, iar interfața afișează acum câteva statistici de bază - câte aplicații sunt în catalog, câte sunt instalate, câte nu sunt și câte ai selectat pentru o operațiune. Tot atunci a fost rezolvată și o problemă cu modul în care se afișau aplicațiile în Installer.

Versiunea 3.3 a rezolvat o problemă mai serioasă: după ce rulai funcția de mentenanță completă, interfața intra uneori în blocare. Cauza era că run_full_maintenance() construia un script care executa pe rând apt update, apt full-upgrade, apt autopurge, apt autoremove și apt autoclean, plus flatpak update dacă Flatpak era prezent pe sistem. Pe un sistem Linux Mint, Debian sau Ubuntu folosit într-o sesiune grafică, o astfel de secvență de comenzi putea face aplicația să pară complet blocată, iar v3.3 a venit tocmai pentru a rezolva asta.

Versiunea 3.4, lansată pe 29 martie 2026, s-a concentrat pe tab-ul Install, care a primit mai multe categorii și aplicații, un sistem de instalare cu prioritate clară pentru pachetele native față de Flatpak și o căutare care afișează rezultatele instantaneu, fără să aștepți ca aplicația să termine de scanat.

Versiunea 3.5 a rezolvat o problemă cu lansarea rapidă a aplicației, iar versiunea 3.6, apărută pe 6 aprilie 2026, a adus ceva util pentru oricine vrea să știe ce rulează pe sistemul lui: o secțiune About unde poți vedea versiunea instalată, ultima versiune disponibilă, locația proiectului și informații despre dezvoltator. Tot în 3.6 s-a lucrat la timpul de pornire și la viteza de schimbare a limbii.

Ce aduce TuxPulse 4.0

Pe 7 aprilie 2026, Eoliann a publicat v4.0 ca release „Latest", iar saltul la o versiune majoră are sens, pentru că schimbările din interfață și din comportamentul aplicației sunt suficient de mari ca să nu mai fie vorba de un simplu patch.

Cea mai vizibilă schimbare ține de navigare: tab-urile au fost mutate dintr-un rând orizontal într-un meniu din sidebar. Este un model de interfață mai familiar pentru aplicațiile de desktop și face navigarea mai logică atunci când numărul de secțiuni crește. Butoanele din Quick Actions au fost mutate în Maintenance, curățând astfel zona principală a interfeței, și au primit text wrapping, ceea ce înseamnă că textul nu mai este tăiat pe ecrane mai mici sau când eticheta e mai lungă.

La nivel funcțional, două dintre problemele cele mai deranjante au fost rezolvate în v4.0: acțiunile din Disk și cele din Install nu mai blochează interfața în timp ce rulează. Dacă ai folosit versiuni anterioare și ți s-a părut că aplicația îngheață când dai o comandă mai lungă, în v4.0 problema asta dispare.

Tot în v4.0 a apărut opțiunea de a comuta între Dark Mode și Light Mode, iar secțiunea About introdusă în v3.6 a fost refăcută complet.

De ce merită să treci la v4.0

Dacă folosești deja TuxPulse, motivul principal pentru actualizare este stabilitatea. Faptul că operațiunile mai lungi nu mai blochează interfața schimbă simțitor experiența de zi cu zi - nu mai ai senzația că ceva s-a blocat atunci când dai o comandă care durează mai mult.

Dacă nu ai încercat TuxPulse până acum, versiunea 4.0 este o versiune suficient de matură și de stabilă de la care să începi. Aplicația funcționează pe Debian, Ubuntu, Linux Mint, Arch Linux, Fedora și openSUSE, se instalează dintr-un fișier .deb sau din codul sursă și poate fi descărcată de pe pagina de releases de pe GitHub.

Proiectul este activ, se mișcă repede și merită urmărit. adymedia.ro a scris un articol detaliat despre v4.0 dacă vrei o altă perspectivă

Am dat peste un articol scris de Stefan Schüller - The Free Market Lie: Why Switzerland Has 25 Gbit Internet and America Doesn't - și chiar livrează ce promite. Nu e un text despre tehnologie în sine, ci despre cum ajunge infrastructura unui stat să fie excelentă sau mediocră în funcție de decizii politice și de reglementare. Merită citit în original, dar vreau să dezvolt câteva idei de acolo și să le pun în context.

Monopolul natural și dilema infrastructurii

Punctul central al articolului pleacă de la un concept economic destul de simplu, dar adesea ignorat în dezbaterile despre „piața liberă": monopolul natural. Există industrii în care construirea infrastructurii costă atât de mult, iar costul de a servi un client suplimentar este atât de mic, încât a lăsa mai mulți competitori să construiască infrastructuri paralele nu produce concurență reală - produce risipă.

Apa și electricitatea sunt exemplele clasice. Nimeni nu propune serios să sape trei rețele de apă paralele pe aceeași stradă, una pentru fiecare companie. Logica e clară: construiești infrastructura o singură dată, ca activ neutru și partajat, și lași companiile să concureze la nivelul serviciilor oferite peste acea infrastructură.

Internetul prin fibră optică se încadrează perfect în această categorie. Și tocmai în felul în care diferite state au ales să trateze această realitate stă explicația pentru decalajele enorme pe care le vedem azi.

Trei modele, trei rezultate

Articolul lui Schüller compară trei abordări: cea americană, cea germană și cea elvețiană.

În Statele Unite, lipsa reglementării a dus la monopoluri teritoriale. Comcast acoperă o zonă, Spectrum altă zonă, AT&T o a treia. Pe hârtie există „concurență„, în realitate e un cartel în care fiecare operator deține teritoriul lui și consumatorul nu are de ales. Conexiunile sunt adesea de tip P2MP - adică partajate cu zeci de vecini - ceea ce înseamnă că „gigabitul" din reclamă devine 200 Mbit seara când toată lumea se uită la Netflix.

Germania, deși asociată cu reglementare excesivă, a ales modelul greșit de reglementare: a încurajat concurența la nivelul infrastructurii fizice, nu la nivelul serviciilor. Rezultatul e că mai multe companii sapă tranșee paralele pe aceeași stradă, cheltuind miliarde pe infrastructuri redundante în loc să investească în viteză și acoperire mai bună.

Elveția a ales altceva. Infrastructura fizică - fibra din pământ - este tratată ca activ neutru, construit o singură dată, adesea de entități publice sau semi-publice. Fiecare locuință primește patru fire de fibră dedicate, într-o conexiune punct-la-punct care nu este partajată cu nimeni. Aceste fire se termină într-un nod deschis, neutru, la care orice ISP se poate conecta în condiții egale. Init7, Swisscom, Salt sau un operator local mic - toți au acces la același fir fizic care intră în locuința ta. Schimbi providerul cu un simplu telefon, fără să vină vreun tehnician și fără ca cineva să sape strada din nou.

Rezultatul? Elveția are acum conexiuni rezidențiale de 25 Gbit/s, simetrice, dedicate, la prețuri rezonabile, cu concurență reală între zeci de provideri.

Nu e mai puțin capitalism, e capitalism mai bun

Asta e ideea pe care mi-am tot rulat-o în cap după ce am citit articolul. Modelul elvețian nu e anti-capitalist - e mai capitalist decât modelul american. Concurența există acolo unde are sens economic să existe: la nivelul serviciilor, prețurilor, calității suportului. Nu la nivelul infrastructurii, unde concurența nu produce valoare, ci risipă.

Piața liberă funcționează când există concurență reală. Dar într-un monopol natural, dacă nu reglementezi accesul la infrastructură, nu obții piață liberă - obții monopol. Operatorul dominant nu are niciun stimulent să îmbunătățească serviciul atâta timp cât nu ai alternativă.

Un detaliu interesant din articol: în 2008, chiar Swisscom - operatorul dominant - a fost cel care a propus modelul cu patru fire punct-la-punct, argumentând că o singură fibră ar crea un monopol și că reglementarea ar fi necesară. Evident, în 2020 compania a încercat să treacă la un model P2MP care ar fi eliminat practic accesul fizic al competitorilor. Init7, un ISP mic, a depus plângere la autoritatea de concurență elvețiană. Swisscom a pierdut în instanță, a primit o amendă de 18 milioane de franci și a fost obligată să revină la arhitectura originală.

Unde se situează România

România e un caz interesant în acest peisaj. Suntem de ani buni în topul european la viteze medii de internet, cu prețuri mici și penetrare mare a fibrei în orașe. Asta nu s-a întâmplat din întâmplare - a existat o piață relativ deschisă în care operatori mici au putut intra și construi rețele concurente, cel puțin în mediul urban. RDS/Digi a jucat rolul perturbatorului de piață care a forțat prețuri mici.

Dar infrastructura din România are și vulnerabilități. Acoperirea în rural rămâne slabă, unde nu există stimulent comercial pentru investiții private și unde modelul de infrastructură partajată ar putea funcționa excelent cu sprijin public. Iar concentrarea pieței e în creștere - ceea ce ar putea eroda treptat avantajele actuale dacă nu există reglementare adecvată.

Articolul lui Schüller nu oferă o rețetă universală, dar pune bine în evidență că infrastructura de internet e o problemă de politică publică, nu doar de piață. Statele care au înțeles asta la timp au cetățeni cu internet mai bun și mai ieftin. Cele care au lăsat lucrurile să meargă de la sine au monopoluri scumpe și conexiuni mediocre.