Vlákno názorů k článku
Podpora pro Itanium/IA-64 zřejmě zmizí z linuxového jádra od RDa - Tohle je jen dalsi dukaz spatne kvality kodu...

Tohle je jen dalsi dukaz spatne kvality kodu a celkoveho rizeni ci organizace projektu.

Nedokazu si predstavit, ze software samovolne casem uhnije, vzdyt ta platforma je porad stejna - neni duvod aby neco prestalo fungovat.

A jestli to nekdo rozbil? Ehm.. na to by snad meli existovat mechanismy kontroly commitu, ne? Nebo takovy skodny patch lze do kernelu dostat no problemo?? Tak to maji hosi jeste vetsi prukak a odstranenim architektury se snazi zahladit stopy? :-)

Si predstavte, ze by jste neotevrel v roce 2023 treba AVI, protoze "to nikdo nepouziva" a loader kontejneru samovolne "uhnil".

Takhle bych to nezjednodušoval, technologie se pořád mění a to velmi rychle. Kodeky a kontejnery jsou defakto zamrzlé specifikace v čase. Protože se stále používají tak je i někdo přepisuje a opravuje tak aby pasovaly na nejnovější architektury. Je to defakto jen roura do které lezou nebo vylézají ven data.
Rozhraní jako takové je velmi primitivní.

Jádro samotné je mnohem hlouběji v systému. Vyžaduje komplexní integraci s okolím.

Rozbil tedy není přesné slovo - spíš nerozumí si s okolím = nefunguje / nelze přeložit atd. nikdo nepoužívá = nelze otestovat.

Nikde navíc není psáno, že nelze používat starý kernel. Běžně se používají 2.x 3.x s backporty. Není v tom žádný problém.

Vy mi přippomínáte některé monkey-managery v IT, kteří si celkem pravidelně myslí, že když jednou někdo něco naprogramuje a potom pracuje na něčem jiném, to, co naprogramoval se už nikdy nerozbije a nikdo to už nikdy nebude měnit.

Což je pochopitelně naprostý nesmysl.

Osobne si myslim, ze je chyba, ze Linux ma vnitrne jadro tak dynamicky se menici se. Linux neni jen o serverech, kde mam novy HW, a tim i vlastne nova jadra. Podle meho nazoru nejaka compatibility layer by se hodila, klidne i v nejakem fallback rezimu. Tedy ze by treba drivery byly updatovany tak, ze pujdou snadno backportnout, idealne pomoci podminene kompilace.

Netyka se to jadra, ale obecne - mam celou radu ruznych nastroju na navrh PLD (CPLD/FPGA), dlouhodobe to delam pod Windows, ale zacal jsem koketovat s myslenkou, ze bych si udelal Linuxovou instalaci, kde bych je mel vsechny tak nejak zaarchivovane, kdybych se potreboval k necemu za par let vratit. No ale ukazalo se to jako nepruchozi, protoze jsem nedokazal splnit ruzne zavislosti na starych knihovnach. (Usecase je jednoduchy: loni jsem nakupoval nejake soucastky 12 let stare a zjistil, ze nove uz neni ani free licence ispLeveru classic, tak jsem musel oprasit starou instalaci na nejakem odlozenem HDD a hledat k ni i pocitac aby prosla licence locknuta na MAC sitovky :) ). Tohle mi prijde jako hrozna skoda...

taková kompatibilita ale existuje, kernel je běžně udržovaný v několika větvých a věci se backportují. Pak tady jsou společnosti, které tu údržbu dělají ještě nad rámec, např. RedHat.

Závislosti na starých knihovnách? To asi není věc linuxu, ale přece distribucí a případně autorů daných závislostí jak dlouho to drží.

Děláme to tak, že udržuji staré image zmražené v čase pro podobné debugování. Chceš-li dlouho stabilní systém, přeborník je třeba openbsd, kde si na to velice dbají.

Já to říkám pořád - technický pokrok je hrozné svinstvo.
Lepší je nepřítelem dobrého.
Dependency hell je toho důsledkem.

Ohledně Vašeho usecase: nebyla by řešením virtualizace? Nastavit MAC adresu je ve virtuálu trivka. Je to snazší, než k tomu překecat hardwarovou síťovku, což se taky často dá. Ostatně i proto jsem viděl nekolik softů, které časem přešly na složitější zámek.
Pokud by byla potřeba, udržet v chodu staré prostředí, dá se zaarchivovat celý virtuál nastojato. Nebo si v moderním virtuálu znovu nainstalovat staré distro. Jenom člověk v zájmu udržení rozumné kapacity musí asketicky instalovat nepodstatné věci...

Tyhle věci mívají kontrolu virtualizace, takže ještě bude muset nastavit emulátor, aby se emulovalo CPUID, různé stringy z BIOSu, možná to bude detekovat i „klasické virtualizované chipsety“ a tak.

Na druhou stranu tyhle věci nemívají kernelový modul, který by to DRM enforcoval (protože dělat uzavřený kernelový modul je naštěstí strašný pain :), takže by mohlo stačit hooknout ty funkce přes strace. Stejně se ukáže že to ve skutečnosti spouští a parsuje výstup ifconfigu.

Osobně jsem to ale nedělal, protože tyhle drahé softwary provozujeme v práci a pro komerční použití si myslím že by se měly licence dodržovat. Kdybych dělal hobby projekt tak si možná nějaké crackování zkusím.

> No ale ukazalo se to jako nepruchozi, protoze jsem nedokazal splnit ruzne zavislosti na starych knihovnach.

To je zajímavé, protože ta FPGA vývojové prostředí bývají desítky GB veliká a táhnou si úplně všechny knihovny s sebou a nic externího typicky nevyžadují. (osobně teda nemám zkušenost, nejstarší co aktuálně provozuji je Quartus 17.1 a Vivado 2020.2, ale nedávno jsem se tu s někým hádal když tvrdil že mu nebude fungovat Firefox/Thunderbird a já jsem bez jakéhokoli hackování úspěšně spustil první 64bit verzi Firefoxu z roku 2011)

Proč na tom budeš se starými Windows (třeba nějaká první release Win10, už nepodporovaná) líp než třeba s Ubuntu 16.04 LTS?

> Podle meho nazoru nejaka compatibility layer by se hodila, klidne i v nejakem fallback rezimu. Tedy ze by treba drivery byly updatovany tak, ze pujdou snadno backportnout, idealne pomoci podminene kompilace.

Cool, myslím že to stačí zaplatit.

Zrovna nejaky Quartus ma s nejakym novejsim Ubuntu problem, chybi tam nejaka knihovna, kterou jsem tedy chtel zkompilovat ze zdrojaku a dostal jsem se do slepe ulicky, kdy ani to neslo protoze neco v distribuci bylo zase spatne a vznikl tak nesnadno resitelny kruh zavislosti.

Ve Windows to kupodivu zatim vse +/- funguje.

Virtualizovat to nechci, ona ta synteza a fitting trva celkem dlouho i bez ni na nativnim zeleze, je pro mne asi lepsi mit treba nekolik HDD a ty prehazovat.

ad druhy bod, ta compat layer, ja myslim, ze by to melo byt soucasti solidniho navrhu OS mit z casti stabilni 'kernel interfaces', byt by zabranily vyuziti nejakych modernich vystrelku. Treba BSD se toho umi drzet celkem dobre. Rekl bych.

Takze kdyz stavite dum, nevadi vam kdyz sem tam neco delnici rozbiji, obcas zbori zed, obcas rozbiji okno nebo prekopnou privod vody,… vzdyt to vpohode jako investor zaplatite…s timle pristup by jste je asi hnal… proc by to melo byt u softver jinak?

Ale ten dům stojí a přistavuje se další pokoj, zároveň se rekonstruuje koupelna, protože vodovodní trubky jsou už staré a ve spojích prosakují. Tak je vhodné popřemýšlet nad ťím, jestli to umyvadlo nedáme raději rovnou jinam, protože tam jsme se o ně praštili pokaždé, když jsme lezli do vany. A problém s tím, že do umyvadla ústil odpad z pračky zůstane nepovšimnut dokud jeden člověk nebue chtít prát. Pak má možnost problém odstranit, aby mohl prát, nebo pračku zahodit a použít stejné řešení jako ostatní.

Takze jinak receno ten kod byl na hovnicemu kdyz uz vznikl a ted ho vlasnte vylepsuji… kdyz pristavuji zimru tak nebudu menit rozvody v celym baraku. S kernelem je to opravdu slozity a chapu frustraci lisi kteri se snazi neco provozovat a pak jim to v kernelu zrusi s tim ze preci muzou porad provozovat stary kernel.

Až na to, že tohle není dům, ale vyvíjející se software. To přirovnání kulhá na obě nohy. Dům postavíte a už se obvykle moc nevyvíjí a pokud, pak kompletně s jinou dynamikou.

Mozna nejde o monkey manazery ale o manazery kteri prisli z vyrobni sfery / prumyslu. Kde se bere software jako zapecena "part number" v BOM. Proste to narachame dohromady a uz nikdo s tim hybat nebude.
To lze castecne chapat u systemu bez vnejsiho vlivu na te stejne soucastkove bazi vyrabene dekady. I tam ale je vsak treba cas od casu udelat opravu. Nebot takovy manazer si neuvedomuje ze slozitost a vzajemne interakce u neceho tak tezko lidskymi smysly uchopitelneho muze vest i pres ruzne audity k nepredpokladanym chybam.

Dusledky takoveho jednani vidim neustale. Zapecene nerecertifiko­vatelne medicinske pristroje, rizeni turbiny plne blobu , image masin ktery uz nikde bezet nebude nebo binarni bloby v prumyslovych pristrojich vykazujici vazne chyby kde jediny mozny zpusob je odeslat vsechny desky vyrobci.
Takove desky jsou mnohokrat prelakovane s prilepenymi soucastkami a preprogramovavat kdyz to "manazer" povazoval za funkcni je zlo. Byva nutno zamestnat par inzenyru na vyvinuti a pak lidi z ciny rucni praci na "opravu" ehm preprogramovani roz....... desky nebo od....... svabu.

uh, co?

Intel divizi Itanií zavřel, vývojáře rozpustil nebo přesunul. Do teď se o implementaci v jádře starali právě zaměstnanci Intelu, ty už to několik let nědělají a ač proběhlo několik žádostí o to, jestli si to někdo nechce vzít na starost, nikdo se nepřihlásil. Ten proces trvá několik let.

Právěže ty kontroly existují a právě proto se objevilo, že build je rozbitý, jen se ve vytyčeném okně nenašel nikdo, kdo by udělal opravu, tak to Linus fixoval sám bez možnosti to otestovat. To už je 3 roky.

Poznamenal bych ze byva vzhledem ke stari hardware uz takove zmeny nekde v realu otestovat. Respektive overit implementaci na realnem HW.
Pokud zmena pro specifickou hw platformu neni otestovana na realnem hw tak se presouva do rise akademickych pokusu a v realne praxi nema co delat.

Pak by mohlo nastoupit vice akademiku a prejit s testovanm do QEMU.

Ale jo, porad ve sporne otazce, nekdo bude muset vytahnout skutecne zelezo a zkusit to tam, at je zjisten onen ground-truth, kdyz neni ze specifikace a dokumentace jasny.

Ale tady nejde o nějaký samostatně stojící kód, který by časem nějak uhnil. Pokud chcete podporovat nějakou hardwarovou architekturu v jádře, typicky ta podpora prochází podstatnou částí jádra. Pokud se mění, tak tam musí být někdo, kdo zajistí, že ty změny budou dobře fungovat i pro danou architekturu. Dřív to dělali lidi z Intelu, pak se na to vykašlali a nikdo jiný se nenašel. Není tam nikdo, kdo má zájem to udržovat? Jde to pryč, protože po ostatních, které ta architektura vůbec nezajímá, nemůžete chtít, aby tomu věnovali věnovat svůj čas.

Škoda, že v SGI naleteli a vsadili na IA-64.

R. I. P.

C'est la vi.

Nestačilo, že už jste to jednou napsal, musíte to pořád dokolečka opakovat pod každou zprávičkou o Linuxovém jádře?

Bohuzel... kdyz OSS vzniklo prave jako protiklad k proprietarnim a uzavrenym platformam/na­bidkam, ale uz nejakou dobu uspesne kopiruje vsechny spatne charakteristiky tohoto nepritele - vyrazovani podpory, vetsi a vetsi narocnost, off-tree binarni bastly (soc/sbc/nv).

Proc FSF / LF nema nejaky lab, kde by meli alespon jeden stroj od podporovane architektury, aby si to mohli otestovat?

Prah toho, aby se dostalo neco do mainline je hodne vysoky, a ten kdo rozhodne o prijeti "daru", by mel take nest odpovednost za udrzbu, pokud princip fungovani spociva v nekonecnem kultivovani pudy (jo, primer s kompostem je zde na miste).

Takove to - je to ted rozbity, tak to ukoncime a smazeme, velice pripomina reseni krizi v soucasne dobe. Nuz.. vitejme v moderni dobe.

OSS a jeho komunita tady přece není od toho, aby podporovala komerční HW pro enterprise segment. Itanium asi nikdo doma na nasku nemá, že?

Protože ten lab nejspíš měli ty minulý přispěvovatelé, které se o tu architekturu starali, ty platil Intel, on celé oddělení zavřel a ve LF (a ani jinde) se nenašel za ty 4 roky nikdo, kdo by to po nich převzal.

Tady se přece nebavíme o nějakém rychlém rozhodnutí, konec Itanií byl komunikován už při jejich poslední revizi někdy v roce 2017, o dva roky později to Intel oficiálně celé zaříznul. Dnes máme rok 2023. Přece nelze chtít po někom cizím, aby něco podporoval donekonečna, 6 let od posledního uvedení je pro tebe krátká doba?

Nebavíme se o nějakém modulu, který stačí upravovat, ale o celé architektuře, kterou musí každý driver, každý modul respektovat a přizpůsobovat se s ní, to je obrovský effort, který teď platil Intel, protože to byla jeho platforma.

Je to krata doba. Na zabiti platformy treba aby zacal umirat hw. Cca 15let mi prijde adekvatni. 20 let nejzassi hranice.

ten kdo rozhodne o prijeti "daru", by mel take nest odpovednost za udrzbu

Takhle to naštěstí v open-source projektech nefunguje a nikdy nefungovalo. Chceš, aby to podporovalo a umělo, co potřebuješ? Přispěj a dlouhodobě to udržuj, protože nikdo jiný tu povinnost to za tebe dělat nemá.

Mimochodem je to velmi efektivní způsob, jak se zbavovat věcí, které přestaly být relevantní. Linux je projekt, který funguje už 30 let a další desítky let fungovat bude. Nemůže udržovat napořád podporu všeho, co se v něm kdy objevilo. Kdy se rozhodnout, že toto už prostě nemá smysl v kernelu mít? To má zasedat nějaká komise, která bude vývojářům říkat "toto ještě udržovat budete a toto už ne?" Že se o podporu Itania v kernelu nechce nikdo starat je velmi dobrý indikátor toho, že ta architektura je dnes irelevantní a odstranění podpory pro ni na základě tohoto je podstatně přirozenější, než kdyby o tom rozhodovala nějaká komise.