Vlákno názorů k článku
Linux se zbaví historických síťových ovladačů, v éře hledání chyb s AI nedává údržba smysl
od Franta Kučera - Z mého pohledu je škoda, že končí doba,...
-
Z mého pohledu je škoda, že končí doba, kdy každá další verze Linuxu byla lepší než ta předchozí. Místo toho budeme spekulovat, jakou verzi použít případně se vrátíme do dob, kdy bylo běžné si Linux kompilovat a patchovat.
Linux tady bohužel dojíždí na svoji monolitickou povahu. Sice má „moduly“ ale ty se nacházejí všechny v jednom repozitáři a kompilují se dohromady. K ovladačům, které se dají vyvíjet nezávisle, to má dost daleko. Jedna věc je napsat si „Hello world“ modul vystavující třeba blokové zařízení nebo souborový systém a druhá věc je reálný ovladač nějakého hardwaru – udržovat tohle mimo hlavní strom už není jen tak. Nemluvě o distribuci a nasazování.
Vývojový model Linuxu dobře škáluje, pokud se přidává – stačí jít kolem, poslat kód ovladače a je to. Díky tomu máme obstojnou podporu všeho možného hardwaru. Ale pokud jde o údržbu a odpovědnost, tak ten systém neškáluje vůbec. To už leží na menším počtu vývojářů, kteří mají pocit, že musí u všech ovladačů udržet stejnou úroveň kvality a hodně toho radši smažou, než aby se o to starali, protože nestíhají. Tohle těžko bude fungovat ve světě, kde mají uživatelé odlišné priority. Když mám nový server připojený k internetu, na který každou chvíli někdo útočí, tak jsem v úplně jiné situaci a mám jiné priority, než někdo, kdo provozuje izolovanou síť nebo samostatný počítač se starým hardwarem. Toho zajímá, aby jeho PCI nebo dokonce ISA karty nebo USB zařízení fungovala, ale sám si na svůj stroj útočit nebude.
-
Ty kernelove moduly ale nejsou "ovladace" v klasickem pojeti - je to pouze salamova metoda - lazy loading. V dobe, kdy linux vznikal, jste zacinali na 4-8MB pameti ve stroji, a tim, ze kernel kod je neswapovatelna pamet - pevne zapinovana, tak drzet v ramce kod v plnem rozsahu by bylo mrhani zdroji. Takze krome volby Y/N se vytvorilo M, coz vytvorilo pseudo-swapping na "aplikacni" urovni. Jiste, kazda featura se da obhajit jak je big-bjutiful, ale tohle spise spada taky do architektonickeho pekla - protoze nekoho napadlo, zda by neslo nahrat i OOT moduly tedy, ktere se prisajou na exporty, ale musite si pohlidat zda mate stejne ABI a architekturu a vlastni i verzi jadra a verzi prekladace.. takze se zavedl rovnak na ohejbak jmenem module magic. Kdo davneji vyvijel OOT kod/moduly, nebude na tohle obdobi vzpominat s laskou. Plus pak mate komercni snahy, jak drzet kod proprietarni skrze lepici vrstvy, ze ano.. nvidia, vmware..
Dneska ten aplikacni swapping pro moduly nedava vubec smysl - jadro ma max 64MB kodu, ktery si klidne muze zit cely a vzdy v ram - je to uz nejaka doba co mame 1G pameti a netrapi nas problemy kvuli kterym se modularizace zavedla.
Vyvojovy model jadra - kdy existuje silny filtr ktery vam odmitne prispevek a zaroven neni tam zadna snaha o future-proofing je proste spatne.
Uz jen ta politika toho, ze symbol/konstanta, ktera se nepouziva, nebude prijata je blbe (typicky nas to potkalo u definovani video formatu ve V4L .. nemuzeme napsat OOT driver pro 10b video, kdyz zadny kernelovy driver nema 10b pixel format).
A podporu pro non-512 based diskove formaty ... linux je tu s nama 30+ let, a to opravdu za tu dobu od paralelnich scsi nemel nikdo ani trocha snahy pridat plnou podporu scsi standardu?? anebo je za tim... jakasi forma uplatku a mafianstvi, ze velci storage hraci maji na Linuse slozku, kterou vytahnou jakmile jim bude svym free produktem konkurovat?
