Názory k článku
JFS možná bude odstraněn z jádra

Jak jsem psal, linuxové jádro není ideální. Ale ono nic není ideální. To, že se používají starší verze jádra, podle mne neznamená, že je to jádro špatné. Naopak to popírá vaše tvrzení o tom, že jádro není future-proof.

To, že něco trápí vývojáře, ještě neznamená, že je to špatně.

A proc vyvojari delaji tedy nova jadra, kdyz to roky stare jadro je tak skvely ze se porad pouziva?

Myslim ze popirate realitu vy.

To, že je staré jádro skvělé, neznamená, že nové nemůže být ještě skvělejší. Tak jednoduché to je.

Nebo vy si myslíte, že nová jádra jsou horší, než ta stará? A je to setrvalý trend, že od vydání jádra před třiceti lety je každá další verze horší a horší? Nebo se dříve jádra zlepšovala a pak se začala zhoršovat? U které verze zhruba k tomu zlomu došlo?

Vývojáře něco obvyklé trápí proto, že je to špatně navrženo nebo tomu ujel vlak. Takže když něco vývojáře trápí, je to vážná indicie, že to špatně opravdu je. 🤷‍

🟥 Tento názor čeká na redakční schválení.
OH FFS! že jsem zas na něco reagoval! 🤦‍♂️

14. 1. 2023, 13:47 editováno autorem komentáře

@RDa [...] ukaz mobil, ktery ma 6.xx kernel. [...]

PinePhone jadro 6.1 ? :-)

http://repo.mobian-project.org/pool/main/l/linux-6.1-sunxi64/linux-image-6.1-sunxi64_6.1+sunxi64-1_arm64.deb

404 Not Found

A to te ve skole neucili ze kdy url not found, mas zkusit odmazavat od konce? ;⁠-⁠)

http://repo.mobian-project.org/pool/main/l/linux-6.1-sunxi64/

Tak zrovna Allwinner A64 je historický, docela tupý procesor, který se ani tak nevyhnul klasice - co vím, tak oproti původnímu 4.x kernelu výrobce nefunguje korektně crypto a h.264 encodér...
A takhle je to vždy, a právě to, co RDa říká...
U Rockchipu si také můžu většinou vybrat - buď krásný starý 4.4, který už moderním GCC ani nelze zkompilovat, nebo mainline, ale bez VPU. A samozřejmě - proč také ne, že - liší se i parametry v rámci device tree.

Prave naopak. Zadne linuxove jadro neni future-proof, protoze "budoucnost nikdo nezna".

Jadro Linuxu je zasazeno (zaseknuto) v soucasnosti, na aktualni platforme, pokud mate chut (lidi/zdroje) se s tim "hrat". Ale toto trvrzeni vubec neznamena ze tato platforma je plne podporovana.

Pokud nemate (lidi/zdroje), je jadro v nejakem zarizeni zaseknuto nekde v minulosti.

A toto opravdu neni idealni stav. Proc by GPU drivery vazane na konkretni API model jadra, meli blokovat moznosti filesystemu (napr. ExFAT v novejsim kernelu) ? A backporting je znova a zrovna ten hnuj, o kterem jsem jiz psal.

Proc by GPU drivery vazane na konkretni API model jadra, meli blokovat moznosti filesystemu (napr. ExFAT v novejsim kernelu)?

Tedy až na to, že by bylo těžko obhajitelné, že DRM má mít stabilní kAPI a VFS ne. Takže pokud by bylo stabilní kAPI pro out-of-tree grafické drivery, vývojáři out-of-tree filesystémů by se ho určitě dožadovali taky. Stačí se podívat, co je zlé krve, kdykoli out-of-tree ZFS driver narazí na nějakou změnu kAPI.

A stabilní kAPI by samozřejmě problém byl i u těch filesystémů. Už takhle v mnoha ohledech třeba btrfs naráží na některá historická omezení modelu VFS - a to je in-tree driver. Out-of-tree filesystémy svázané stabilním kAPI by byly postižené ještě víc.

V ramci Linux kernelu bohuzel *nic* nema stabilni kAPI. Cele je to pojato v stylu YMMV a GL&HF. To by se prave od OS ktery si hraje na solidni reseni nemelo stavat.

Jako delali jsme i neco pod MS a tam se taky sem-tam neco zmeni mezi edicema (W10, jednou az dvakrat rocne)

To by se prave od OS ktery si hraje na solidni reseni nemelo stavat.
Takže vy vlastně nechcete operační systém, který je připraven na budoucnost, ale takový, který je připraven na minulost. Tak si zvolte třeba Windows, ty úzkostně dbají na zpětnou kompatibilitu. Akorát se musíte smířit s tím, že udržování zpětné kompatibility brání rozvoji, takže zůstanete na postupně umírající platformě Windows, zatímco Linux se bude rozšiřovat do nových ekosystémů.

Konkretni kernel by byl pripraven na budoucnost (future-proof) pokud ho neni potreba CELY vymenit, kdyz chcete driver na nejake zarizeni, ktere nebylo predtim podporovane nebo pridat subsystem ktery tam drive nebyl.

Soucasny kernel proste takovy neni, a byt "vyvoj" jde dopredu, v realnem kritickem nasazeni se vzdy cpe dokola ten stary kernel, opatchovanej milionkrat backportama zaplat.

Myslim ze jaderni vyvojari jsou si toho problemu take vedomi a vytvorili LTS verze - aby se dalo alespon chvili nekde setrvat a ty backporty resili centralne, a ne kazdy uzivatel a integrator sam.

RDa: Každý máme jinou představu o budoucnosti. Vy si pod budoucností představujete zítřek, já si pod budoucností představuju pět, deset, dvacet let.

Konkretni kernel by byl pripraven na budoucnost (future-proof) pokud ho neni potreba CELY vymenit, kdyz chcete driver na nejake zarizeni, ktere nebylo predtim podporovane nebo pridat subsystem ktery tam drive nebyl.

Jeden OS, (jehož jméno se zde vyslovuje jen s opovržením), zavedl do svého kernelu pluginy (extenze) a dost dlouho (~10 let) to fungovalo. Prostě pokud jste potřeboval nový FS/HW zařízení/síťové zařízení/VPN apod., tak jste prostě vytvořil extenzi do kernelu a bylo to.

Dokonce se přišlo na to, že extenze napsané špatně výrazně ovlivňují stabilitu kernelu a OS jako takového.
Ale vývojáři se poučili, výrobce OS dodával stéle lepší nástroje na debugování těchto extenzí a situace se zdála být sluníčková.

Pak se ale přišlo na to, že takový doplněk může být mega bezpečnostní průšvih v případě že autor není tak úplně čestný a software/malware tak může mít přístup k počítači na úrovní jádra.
Takže se od toho zase pěkně rychle ustoupilo a IMHO během posledních 3 let už tyto extenze jsou výrazně nedoporučovány a v blízké budoucnosti už budou zakázány úplně. Aby ale výrobce OS nekazil výrobcům SW byznys musel zavést na všechny věci které šly udělat extenzí vlastní API (FS/VPN…) a výrobci SW zase musí vše přepisovat z extenzí na API operačního systému.

Tak to je jen můj postřeh k future-proof.

Zadne linuxove jadro neni future-proof, protoze "budoucnost nikdo nezna".
Ano, právě, budoucnost nikdo nezná. Takže jádro, které má být připravené na budoucnost, nemůže být připravené tak, že si teď někdo sedne, hluboce se zamyslí a vyvěští, jaká bude budoucnost za 10 let. Jak byste si to představoval vy. Protože nikdo budoucnost nezná, jediná možnost, jak se na ni připravit, je být pružný a dokázat rychle reagovat na změny, které budoucnost přinese. A to zvládá linuxové jádro už třicet let a velký podíl na tom má Linusův přístup k jádru. Vy byste chtěl, aby se API zakonzervovalo v současném stavu, tj. nemohlo by reagovat na přicházející změny. To by způsobilo, že by jádro začalo zastarávat.

Pokud nemate (lidi/zdroje), je jadro v nejakem zarizeni zaseknuto nekde v minulosti.
Přesně tak. Ale je to problém toho jednoho zařízení. Vy byste chtěl, aby se v té minulosti zaseklo celé jádro a všechna zařízení. Z pohledu toho jednoho zařízení by to samozřejmě bylo dobré (všichni by na tom byli stejně špatně), ale z hlediska všech ostatních by to bylo špatně.

Mimochodem, ten vámi preferovaný model úzkostného zachovávání zpětné kompatibility mají Windows. Proto jsou uzamčená ve svém ekosystému, nedostanou se na superpočítače, na jednoúčelová zařízení, na mobily, do cloudu. Pokud chcete konzervativní jádro, používejte Windows – ale počítejte s tím, že jejich životní prostředí se postupně zmenšuje, protože nedokážou dostatečně pružně reagovat na změny.

Necakal som ze toto niekedy napisem na vas prispevok ale toto ste naozaj trafil. Nikde som necital lepsiu definiciu toho preco mam rad Linux a Windows sa mi zda zastaraly.

Sorry, ale současný stav je dokola prodrátový mrdník, kde člověk vždycky skončí v tom, že reversuje zdrojáky, aby pochopil, jak se přesně co chová. Ke spoustě věcí není ani aktuální dokumentace. Přitom pro 95% typů zařízení není žádný technický problém v rozumné míře API držet, protože jde o stále stejné věci.
Je to bastlení. I jen úsilí nutné k udržování toho, co už v kernelu je neustále roste a to je samo o sobě neudržitelné, protože to jsou jalové náklady. Navíc je to fakticky netestovatelné - definavané API testovatelné je.
Zrovna jsem si užíval s jedním driverem, 15 různých verzí stejného driveru ve 3 verzích kernelu, pořádně nefunkční žádná....takže jsem vyrobil 16.....opravdu paráda, takový bordel.
Kolik kernelových driverů jste napsal nebo udržoval?

Kolik kernelových driverů jste napsal nebo udržoval?

Já mám to štěstí - nebo smůlu - že tu problematiku znám z obou stran, tedy jak z pohledu vývojáře in-tree kódu, tak z pohledu někoho, kdo udržuje out-of-tree driver tak, aby fungoval i s akutálními jádry. (Mimochodem, abych napodobil váš nevhodný dotaz: jak jste na tom vy? Máte i zkušenosti s vývojem jádra jako takového nebo jen s bastlením out-of-tree driveru?)

Na základě té zkušenosti můžu říct, že i když udržování out-of-tree driveru je občas otrava, není s tím zdaleka tolik práce, jak se nám někteří lidé snaží namluvit, pokud se to dělá průběžně (a také pokud se to vůbec dělá). Problém s těmi krabičkami běžícími na letitém a neupdatovaném jádře 4.4 nebo ještě starším je totiž především v tom, že ty drivery byly většinou napsané stylem "napsat, hodit přes plot a zapomenout" a dál už se jimi nikdo nezabýval. Koneckonců i ten repozitář zmíněný výše existuje právě proto, že příslušný vendor na to tak trochu kašle (i když zdaleka ne tolik jako jiní). Na druhou stranu mám trochu představu, jak by vypadal vývoj jádra, kdyby byl svázán požadavkem stabilního kAPI, a k jakým hrůzám by to vývojáře nutilo. Za sebe můžu říct, že by to byla naprostá katastrofa, takže ne, to v žádném případě.