Linus a Linux kernel jövőjéről

Kernel
  • Van-e elég fiatal fejlesztő? (van egy csomó új)
  • Van-e elég karbantartó? (rohadt nehéz találni, mert az egy heti hét napot igénylő pozíció)
  • Eljön-e majd az idő, amikor a C mellett például Rust-ban vagy Go-ban fognak programozni? (Linus biztos abban, hogy ez meg fog történni)
  • Mi a helyzet az ARM-mal? (Linus szerint az Apple ARM-ra váltása segíteni fogja az ARM ökoszisztémát fejlesztési szempontból)

A Dirk Hohndellel (a VMware nyílt forrással foglalkozó vezetőjével) folytatott beszélgetésének kivonata itt olvasható.

( pehsa | 2020. 06. 30., k – 14:41 )

A kommentek között van egy gyöngyszem :D

 Just give it to Poettering...

...I'm sure he'll do the right thing by it.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

( meskobalazs | 2020. 06. 30., k – 14:54 )

„kernel colonel” – jaj, ez fájt :)

( kl3on v | 2020. 06. 30., k – 20:29 )

Emlkékeim szerint Linus többször is azt mondta, hogy majd lesz más nyelv ha mutat bárki olyan jót (a célra) mint a C. Ez az elsô alkalom hogy megnevez egy lehetséges nyelvet ami lehet az új?

Nem csak az a fontos, hogy a nyelv alkalmas-e, hanem lehet-e embert találni, aki abban programozik. A feladatra az Ada pl. alkalmas, de nem igazán népszerű. Míg van olyan metró, aminek a szoftverét Adában írták, a Siemens villamosokon tudtommal C++-ban írt kód fut. Meg eddig inkább ilyen jellegű felhasználását ismmerem, még ha van belőle AWS is (Ada Web Server).

> Nem csak az a fontos, hogy a nyelv alkalmas-e, hanem lehet-e embert találni, aki abban programozik.

Így van, őrült nagy tehetetlensége van az iparágnak.

Az Ada a korának megfelelő biztonsági pluszokat hozta, ez előny, de akkora áttörést nem hozott, mint most pl. a Rust (és ami felé úgy látom, maga Stroustrup prof. is mozdul).

Szerk: Adáról még annyit, hogy amellett a némi plusz mellett viszont elég terjengős kódokat kell írni benne, ami SZVSZ nem javít az átláthatóságon, ami pedig szempont, ha a biztonság is szempont.

Erre én is emlékszem, de ezt gőgből mondta, mert tudja, hogy nem tudnak neki jobbat mutatni, vagyis próbálkozhatnak vele, de ő nemet fog mondani. Több másik interjúban már leszögezte, már évekkel ezelőtt, hogy a Linux kernel mindig is C-ben lesz, ebből csak a holttestén át enged, nem képezi alku tárgyát.

Egyébként igaza van, egyetértek vele, a C-t kifejezetten erre találták ki, hogy Unix meg unix-like OS legyen benne fejlesztve, és még a magas szintű nyelvek között még ez van a legközelebb a hardverhez, egy 50 éve bizonyított konstrukció. Lehet nem szeretni a C-t, de vitatni, hogy nem ez a legalkalmasabb erre a feladatra, azt szerintem nem.

A Rust-ot meg hiába hájpolják, szerintem egy rossz vicc. Az egész egy szutyok. Nem programoztam még benne, de forgattam le pár linuxos projektet Rust-ban, egy rémálom az egész, a függőségeivel meg mindennel. Aki nem hisz nekem, nem ismeri még a nyelvet, próbáljon pár rustos projektet forráskódból kipörgetni, majd a saját bőrén fogja megtapasztalni, hogy mi a baj vele.

Írom ezt úgy, hogy a C hozzám sem áll annyira közel, a C++ nekem mindig is szimpatikusabb volt, a típusossága meg multiparadigmás lehetőségei miatt. De azt eszem ágában sem lenne indítványozni, hogy a kernel C++-ban legyen fejlesztve.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igazából itt sosem arról volt szó, hogy adott nyelv és eszközei alkalmasak-e egy adott feladat megvalósítására, hanem, hogy adott fejlesztő mennyire elhivatott a dolgában. Ott van egy csomó másik kernel, amit más nyelvekben írtak meg és a saját ökoszisztémájukban el is vannak. Ott a Redox a Rust esetén. Lentebb lett linkelve kernel D nyelven. Ahogy már említették JS-ben is írtak már olyan eszközt ami képes Linux kernel futtatásra.

Bármilyen nyelven lehet technikailag kiemelkedőt alkotni, de az más kérdés, hogy mennyire kapják fel adott projektet.

A Linux kernel akkor alakult ki, mikor a C nyelv sokkal jobban a köztudatban volt és rengeteg fejlesztő volt/van aki tud C-ben programozni, így tudtak/tudnak fejleszti benne.

A Rust-nak még van mit fejlődnie, de szerintem kifejezetten alkalmas kernel programozásra. Ha valakinek ez áll jobban kézre, annak nem lesz problémája vele.

Ha a Linux később fejlődött volna ki, akkor nem biztos, hogy a C nyelv lenne az alapja.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

> egy 50 éve bizonyított konstrukció.

Ez jelent valamit, de nem mindent.  Sőt, bevallottan máshogy találták volna ki, ha ma csinálnák volna.  De ugye a kompatibilitás egy programnyelv esetében elsődleges szempont.  Szóval az újdonságnak is van létjogosultsága, abszolút.

> A Rust-ot meg hiába hájpolják, szerintem egy rossz vicc. Az egész egy szutyok. Nem programoztam még benne

Ilyen kijelentések előtt pedig érdemes lenne megpróbálni (bár előre szólok, hogy az első hónapokban valami más miatt lesz nehéz, pont nem a túlhízása miatt).

Egyébként nem csak hájpolják, hanem használják ezerrel.

Vannak elszállt Rust-os projektek.  De hogy minek mennyi függősége van, az nyelvfüggetlen téma.

( turul16 v | 2020. 07. 01., sze – 09:51 )

Go nem jo erre.
Rust talan ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Rust esetén fut a unix-szerű Redox, az RTOS-szerű Tockos és sok egyéb bare metal programming projekt.
Go az nem igazán rendszerprogramozásra, inkább alkalmazás írására tűnik használhatónak.

Viszont a D nyelv nagyon a háttérben leledzik. Ez mennyire alkalmas rendszerprogramozásra, bare metal programmingra?
https://en.wikipedia.org/wiki/System_programming_language#Major_languag…

A D valahol a C++ es C# kozott van,
Valamiert nem tul nepszeru, pedig egyaltalan nem rosz tool.

Megha 'D'  altalban probal memoriat managelni,
a legtobb esetben hagyja hogy felul birald.

https://dlang.org/library/core/volatile/volatile_load.html
https://wiki.dlang.org/Memory_Management

Nem lehetetlen D -t hasznalni, de nincs is jo ok
arra hogy C helyett azt hasznald a bare metal programozni ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( sigellef | 2020. 07. 01., sze – 15:42 )

... a gcc-t fejlesztik kb. 30 éve, a rust, go meg max 10 éves lehet. Biztos, hogy jobb? ... vagy majd egyszer valamilyen kritikus helyzetben kiderül, hogy valami gond van a binárisokkal?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

A fordító félrefordítása ahogy írod, kicsi de valós kockázat, tehát érdemes odafigyelni. Ellenben ma sokkal nagyobb kockázat az általunk írt kódban elkövetett, például memória allokáció ill. felszabadítás körül elkövetett hiba.
Nézd meg a C és Rust példákat. Valós, elkövethető és el is követett hibák: https://web.stanford.edu/class/cs110l/slides/lecture-02.pdf
Microsoftnál volt egy ilyen projekt egy biztonságosabb C létrehozására: https://www.microsoft.com/en-us/research/project/checked-c/ ... végül kiütötte a Rust.

( meditor | 2020. 07. 03., p – 06:26 )

Érdekes ez a nyelvi kérdéssel kapcsolatos ötletelés. Én fordítva gondolom: nem az a kérdés, hogy milyen új nyelv alkalmas unix_like oprendszer írásására, hanem az, hogy a 'C' alkalmas-e.Ha nem, akkor miért nem és, ha igen, akkor miért kell piszkálni. Van egy régi szabály, amit betartok: ha működik, ne piszkáld.

> Sol omnibus lucet.

Ez kicsit attól is függ, hogy mivel kell lépést tartani.  Ha nem muszáj, én sem szeretek hirtelen váltást.  Sok szempontból nyilván alkalmas a C.  Amiben a Rust jobb:

  • nincs dangling referencia
  • nincs adatversenyhelyzet
  • "invalid iterátor", általánosabban: átlapolt író referencia esete megtiltva
  • jóval kisebb esély deadlock-ra és memóriaszivárgásra
  • van rendes modulrendszer (itt panaszkodtam a C-s megoldásra)
  • jobb típushelyesség, jobb const correctness
  • algebrai adattípus (más nevén "tagged union", vagy kb. "variant", de jobb nyelvtannal támogatva)
  • array és string slice
  • lambda + closure
  • aszinkron vezérlés
  • implicit konverziók tiltva
  • meg még sok apróság...

Semleges:

  • a közvetlen hardverkezelés ugyebár semmivel nem lesz biztonságosabb, mint a C;  ezeket unsafe {} blokkba kell tenni, erre egy programnyelv nem tud garanciát vállalni.

Hátrányaként a C-hez képest talán ilyesmit mondanék:

  • tényleg nehéz, főleg az elején
  • beágyazott eszközökhöz, kernelhez kicsit pucolgatni kell, de meg lehet csinálni
  • egyik szabályát kerülgetve (amelyikkel pl. az invalid referenciákat is tiltja) komolyabb kognitív, és minimális futásidejű terhelésre lehet számítani.  Az utóbbi mérési hiba alatt van, illetve unsafe-fel még az is elkerülhető, ha úgy tetszik.  Az előbbi viszont nem egyszerű. :)
  • Ha valahol túl sok unsafe kódrészlet kell, az kissé zavaró is lehet.  Valaki azt írta, ő egy kernel hardverközeli részeit inkább Zig-ben írná, a többit Rust-ban.
  • Lassú fordító.

Ha C++-hoz is viszonyítjuk:

  • az OOP szintaxisát újra kell tanulni, és kicsit a szemantikát is.

Valami ehhez hasonló listát mérlegelnék.  Azért az elmúlt 50 évben történtek fejlődések.  Ha úgy gondolod, hogy megéri, akkor "go" (de nem arra a go-ra gondolok. :) )