Care e problema cu Torvalds și aprobatul de „AI”

Într-o ieșire tipică, Torvalds a explicat că „dacă nu vă convine, faceți chestia aia open source în care copiați codul și-l modificați”. Vorbea, desigur, de „AI” tools, și de faptul că lui i se pare foarte ok să le folosească în conjuncție cu kernelul Linux. Și simt că omul a răspuns la întrebarea greșită și nici nu înțelege foarte bine ce răspuns a dat. Așa că o să reamintesc aici câteva probleme legate de „AI” și de ce Torvalds ar putea să le ignore.

O să încep cu o aserțiune foarte importantă: în momentul ăsta, numărul extrem de mare de probleme găsite (și reparate) în kernelul Linux este cam singurul argument pentru utilitatea LLM-urilor. Suspiciunea mea e că Torvalds e impresionat de ceea ce pot produce LLM-urile și că e sigur că pe viitor atitudinea „AI”-friendly o să aducă rezultate similare în perpetuitate. Sau poate nici el nu e la fel de naiv și vede cum canalele de comunicație sunt supraîncărcate cu AI-slop. Mă gândesc că se gândește că singura modalitate de a lupta cu aspectele negative ale LLM-urilor este „mai multe LLM-uri”.

În fine, nici nu mă deranjează că a spus că da, „AI”-tools sunt binevenite. Așa că încep să înțeleg și de ce insistă cu includerea Rust în kernel. Vedeți, noi trăim acum cu o poveste moralistă despre un individ orgolios luând niște decizii greșite și ținându-se cu dinții de ele.

O problemă de orgoliu

Acum mult timp Torvalds a fost întrebat de ce nu a adoptat C++ în git, și răspunsul lui a fost extrem de spumos și agresiv. Oricine știe despre ce vorbește Torvalds acolo știe că în afară de „mă simt special și mă deranjează codul scris în C++”, așadar în afară de preferința personală nimic din lucrurile pe care le povestește acolo nu sunt relevante:

• Se plânge de STL și Boost de parcă ar trebui să folosească bibliotecile respective, între timp în C a trebuit să reinventeze fix ce fac nu doar STL și Boost dar și alte nenumărate biblioteci care ai și alte scopuri decât să fie soluții generaliste.
• Modele de abstracție ineficiente pe care nimeni nu-i impune să le folosească, și pe care oricum le emulează cu structuri în C.
• Incapacitatea lui de a vedea utilitate în tot ce nu e C în C++, unde, desigur, vorbim doar de opinia lui dar și înțelegem mai bine limitările lui.

Există în alte părți alte intervenții similare legate de C++. Argumentele lui sunt mereu laterale de tipul „există aspecte deranjante”. C este vast mai problematic decât C++ și treaba asta e văzută și în numărul mare de CVEs care sunt atribuite C/C++ dar sunt în cea mai mare proporție în cod C. Iar kernelul e C.

Rust a fost o soluție de compromis după ce vreme de 30 de ani Torvalds a refuzat cu obstinație să intre C++ în kernel. Dacă ar fi acceptat C++ în Linux, ar fi fost un mare avantaj pentru toată lumea, inclusiv pentru comunitatea C++, și pentru testabilitatea kernelului. În mod sigur am fi văzut mult mai puține probleme nu doar în ultima perioadă, ci și de-a lungul timpului.

Pentru că asta aduce Rust în kernel, și ăsta e motivul pentru care Torvalds a luat în brațe Rust de îndată ce CISA a amenințat că nu-i mai place codul scris în C++ și cei de la Microsoft l-au presat cu „cât de bun e Rust”. De fapt, calculul e foarte simplu. Torvalds a fost obligat să accepte că C este o problemă pentru kernelul Linux. Acum omul încearcă să repare lucrurile.

Da, e despre C vs C++

C și C++ au avut o viață foarte diferită. În timp ce C a adăugat un număr foarte mic de modificări în standard în ultima vreme și rămâne ceea ce a fost dintotdeauna, un „portable assembler”, C++ a crescut enorm în ultimii ani, cu multe facilități care sunt țintite și către sistemele embedded. C++ a înglobat multe facilități pe care oamenii le văd în alte limbaje de nivel mai înalt. E de discutat cât de grozav a făcut lucrul ăsta (biblioteca standard a devenit o colecție de greșeli, dar tot oferă destul de multe lucruri bune), dar la nivel de limbaj și la nivel de tehnologie de compilare, C++ a crescut enorm.

Dar superioritatea nu pornește din anul 2011, când au început să apară noile standarde C++, ci încă din anii ‘90 unde puteai să îți construiești lucruri precum smart pointers care să facă „ce trebuie”, și să construiești tot felul de sisteme robuste, testabile, refolosibile. Văzusem undeva o statistică în care C și C++ sunt separate - în momentul în care dai la o parte /-ul ăla din C/C++, și te uiți discriminat, vezi că majoritatea problemelor apar în cod C, și un număr extrem de mic în cod C++. Numai că din conveniență (și un pic din language marketing), /-ul ăla rămâne între C și C++.

C++ nu este o opțiune mai bună în 2026, a fost o opțiune mai bună pentru kernelul Linux chiar și în anul 1995. Torvalds însă a fost prea arogant și probabil prea timid. De înțeles. Dar asta nu înseamnă că nu l-a tras în jos opțiunea. Și poate el să explice cum toată lumea care îi spune de C++ sunt bullshitters, dar aici chiar a bușit-o el. Și rezultatele sunt destul de rele. Acum ies la suprafață 30 de ani de bad practices de software development. Și ne dăm seama că Linux este un produs software condus prost.

Advisory-ul CISA din 2024 în care se spunea în clar că nu se vor mai accepta sisteme care sunt scrise în C/C++ probabil (și) pentru Torvalds a fost scris, și corporațiile au putut atunci să împingă Rust în kernel. Dar Torvalds nu poate să vorbească despre asta în termenii ăștia, nu poate să spună că oamenii din corporații i-au forțat mâna, și nici să dea înapoi la o eroare strategică în care a persistat vreme de 30+ ani.

Și acum, că corporațiile i-au demonstrat găsindu-i problemele vechi de zeci de ani în cod că nu este un bun lider de proiect, normal că omul e mai mult decât încântat să ia apărarea oamenilor care îl manipulează de ceva vreme. În fond, traiul ăla în state e bun pentru el, nu vede problemele, și a început să creadă că ceea ce face el e sustenabil.

Care sunt problemele pe care le uită?

Chiar dacă pentru el uneltele astea LLM sunt de mare ajutor, ce nu-și dă seama Torvalds e că se face white-washing cu kernelul. „Uite, am găsit probleme, reparăm chestii, îl salvăm pe bietul Torvalds de spam, îi rezolvăm automat problemele detectate, AI e bun!”

Nu vede costurile din spate. Nu vede concedierile, nu vede furtul intelectual. Nu vede criza economică care se apropie și care va afecta bunăstarea tuturor, poate mai puțin el, care va fi păstrat într-un cocon de către corporații, că e bine să ai câte-un ambasador al binevoinței. Între timp, corporațiile care îl țin în puf pe Torvalds lucrează din greu să distrugă bunăstarea tuturor celorlalți, dar Torvalds va trăi bine în continuare, sunt sigur de asta. Nu mă tem pentru el.

Dar cel mai tare mă enervează acel „do the open source thing, and fork it”. După ce am investit cu toții în a-l transforma într-o figură centrală a acestei tehnologii, e cam greu să construim un nou centru de încredere, nu? Că nu codul sursă e problema, ci ierarhia de încredere care s-a format în jurul lui Linus Torvalds. E un sistem în care am investit cu toții, de la ăia care au contribuit cod în kernel la cei care au scris sau vorbit despre Linux când Microsoft avea 99.3% cotă de piață. Am trecut prin vremurile alea, și și eu am pus umărul la ridicarea ierarhiei din jurul lui Torvalds. Ce a făcut el e să se construiască o biserică special pentru el, și când e biserica gata construită el să vină din amvon și să spună „păi mergeți și vă faceți altă construcție dacă nu vă convine ce fac eu de-aici”. Construcția din jurul lui e mult mai mare decât el, și este un proiect de 35 de ani la care au contribuit milioane de oameni.

Treaba asta nu e despre „AI”. Este despre un proiect monumental, unic în istoria omenirii, la care au lucrat milioane de oameni. Știm că Torvalds e ocazional un bully și un individ neplăcut. Așa că e normal să fim nemulțumiți atunci când omul vine și dă mâna cu Joker, Penguin și Lex Luthor și ne explică nouă că dacă nu ne convine ce fac prietenii lui să ne luăm jucăriile și să plecăm din Gotham.