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.
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.
> 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
Kernel interfaces jsou podle mě na Linuxu velice stabilní, ty ses setkal s nějakým případem kdy ti třeba nefungoval syscall? Lidi (i ty teď, mi přijde) si stěžují na nekompatibilitu knihoven v userspace. Naopak BSD nemá kernelová rozhraní kompatibilní, ve smyslu že by třeba fungovaly různé verze ekvivalentu jejich programů jako „ip“ a „iptables“ s různými jejich kernely, a dokonce i „uživatelské“ syscally jsou nekompatibilní, proto třeba Go na Linuxu volá syscally přímo a jejich binárky fungují na různých kernelech, ale na BSD musí volat přes jejich knihovny (doufám že teď nepíšu nesmysly / už to nějak nezměnili / ...). Je to přesně naopak než píšeš… random odpověď na SO o tom, random openbsd
Praktickou kompatibilitu user-space knihoven na BSD posoudit nedokážu (BSD neprovozuju), ale přijde mi divné, že by nedělali takové ty populární věci co vždycky všechno rozbijou, typu GTK 1-2-3-4, Qt 3-4-5, ale i různé nové libusb a vůbec všechny libfoo.
A třeba ten problém co popisuješ můžeš řešit tak, že si to staré Ubuntu nainstaluješ do chrootu - ani není potřeba plná virtualizace.
> Ve Windows to kupodivu zatim vse +/- funguje.
Protože si tam ta aplikace tahá všechny knihovny s sebou?
17. 2. 2023, 20:16 editováno autorem komentáře
Myslel jsem intrakernelove rozhrani, tedy treba ovladace.
Ty odkazy co zminujete, v nich nevidim problem, jestli clovek definuje ze POSIX vrstva je pres knihovnu (kde jsou posixove fce typu open/read/close), nebo nekdo definuje i ty syscally.
Takovy priklad (byt blbe) udelane zpetne kompatibility jsou Windows, tam si na to hodne hraji, a Linux by se mel inspirovat (a hlavne neopisovat jejich pristup "radsi to ohackujeme jen abychom nerozbili aplikaci XYZ" - pak v kodu vznikaji prasarny o kterych je https://devblogs.microsoft.com/oldnewthing/ :) ).
Problem s Quartusem nebyl ze by ji chybela nejaka knihovna, ale ze jsem snadno nebyl schopen dosahnout stavu, ze na systemu budu mit chybejici knihovnu. Ano, chroot byl mozna reseni, jestli jsou pro to stare Ubuntu jeste funkcni repozitare. Ve Windows muzu mit ispLever/iceCUBE/Quartus/ISE/nevimcojeste pohromade.
> Myslel jsem intrakernelove rozhrani, tedy treba ovladace.
Dobře, ale to nesouviselo s tématem (rozbitý Quartus).
A konečně vidím místo, kde by šel použít "AppStore argument" :-). Díky tomu, že se do Linuxu dávají tak obtížně 3rd party kernelové ovladače, nemáme ten strašný hell s nestabilními ovladači jako na Windows! :) (kde to dospělo do tak strašného stavu, že museli udělat celý ten WHQL proces a teď ovladače centrálně reviewují, zakazují a podepisují - a to jsou podle mě Windows ještě „easy“ protože podporují poměrně úzkou množinu PCček)
> a Linux by se mel inspirovat (a hlavne neopisovat jejich pristup "radsi to ohackujeme jen abychom nerozbili aplikaci XYZ"
To je podle mě nedosažitelný cíl, buď máš kompatibilitu a spoustu legacy hacků, nebo ne.
> Takovy priklad (byt blbe) udelane zpetne kompatibility jsou Windows, tam si na to hodne hraji
Myslím, že je to o tom, že na Windows si aplikace táhnou mnohem víc knihoven s sebou, a využívají jenom rozhraní řekněme podobná tomu co poskytuje Linux (libc/syscally + X protokol pro grafiku). Je to trochu posunuté skutečně směrem k „stabilní linuxové API poskytuje méně zejména grafických primitiv“, ale ne nějak zásadně. Vždyť oni si snad tahají i vlastní libc ("Visual C++ Redistributable"). A i na Windows byly pokusy různé knihovny centralizovat, zejména co se týče runtime a frameworků (.NET, Java), a dopadlo to naprosto tragicky, řekl bych že kvůli absenci normálního balíčkovacího systému ještě hůř než na Linuxu.
Skoro bych si vsadil, že ta knihovna, co na Ubuntu chyběla, ve Windows vůbec neexistuje a je bundlovaná.
> jestli jsou pro to stare Ubuntu jeste funkcni repozitare
Například pro Ubuntu 6.06: http://old-releases.ubuntu.com/ubuntu/dists/dapper/ (a stejně tak pro Debian)
Mate pravdu, ze bych mozna mohl zkusit moderni CPU a moderni nastroje, driv tam penalizace byla velika, ze mne to nebavilo. Ona ta synteza/fitting chvili trvaji.
Ono se to pri rychlosti IT nezda, ale mame zakazniky, kteri pouzivaji dodnes HW z roku 2002-3 (?), tech jsou pravda asi uz minimalni pocty. Ale dodnes funguji urcite stovky uzivatelu na hardware z roku 2008 a poskytujeme stale aktualizace. Bohuzel zdarma.
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.
nikoliv, ten kód byl kvůli podpoře architektury (to není jen nějaký driver), která již 3 roky na trhu neexistuje a u které nikdo neprojevil za tu dobu zájem jí udržovat, hlavní udržovatelé již několik let do jádra nepřispěli a kód teď nikdo neudržuje.
Linux Kernel není produkt nějaké firmy, ale komunitní projekt mnoha firem a jednotlivců, když v nich nikdo není ochoten se na tom podílet, je logické to odstranit.
Kterým lidem, kdo co zrušil a nemohou to provozovat?
Ne, kód byl funkční a nebyl nahovno v době vzniku. Ale například závisí na něčem, co potřebuje přepracovat kvůli bezpečnostní chybě. Odstranění chyby způsobí změnu chování, která jinde nevadí/je žádaná, ale v kódu pro Itanium způsobí jeho nefunkčnost. No dobře, potud je vše v pořádku, ale ono to je vlastně všem jedno, až na jediného uživatele, který tento problém reportoval. A protože není nikdo ochotný/schopný ten kód pro Itanium opravit, co bys dělal Ty?
Jako proč držet podporu pro něco, co reálně nikdo nepoužívá? Proč držet podporu pro 386, když na většině mašin současné jádro ani není schopno nabootovat pro nedostatek paměti? A vlastně k čemu potřebuješ jádro 6.1 na 386? Kvůli podpoře USB3.2 a PCI Expres? Nebo snad NVMe? Vždyť je i problém sehnat vhodnou (myšleno kompatibilní s dnešními standardy) síťovou kartu do takového počítače. Mám tu 486 notebook a marně sháním FUNKČNÍ 16bit PCMCIA síťovou kartu za rozumné peníze.
Já vím, 386 není Itanium, ale problém je stejný - nikdo to nepoužívá. Nikdo si delší dobu nevšiml, že je to rozbité. A nikdo to není ochoten/schopen opravit. A zrovna ta 386 by mohla být zachována alespoň z nostalgie. Vždyť je to první podporovaný porcesor.
Jde o princip.
Treba ja mam stejny codebase, ktery bezi jak na 8-bitovem AVR, tak na 64-bit PC / AA64. Protoze jsem fakt linej udrzovat dve verze toho sameho (jedna se konkretne napr. o custom drivery I2C periferii).
Kernel je hodne konfigurovatelny - a procpany makry. Tak mi nerikejte, ze to nejde pouzit v nejakem redukovanem, kompatibilnim rezimu. Vzdyt co nenavolite v kconfig, tak to se ani nepreklada..
Aby clovek vyhrabal nejakou IA64 a udelal bisect, at se ukaze prstem na toho chytraka co to rozbil, a toho druheho co to schvalil, a tretiho co to vclenil.
Ale vždyť přesně tak se to také stalo, ví se přesně jaký commit a proč to rozbil https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=228345bf98cd78f91d007478a51f9a471489e44a
Ano, kernel je hodně konfigurovatelný, právě proto to nikdo nějakou dobu neviděl, než to zkusili zbuildit s vanilla default kconfigem a spadlo to.
Bavíme se tady o podpoře platformy, která již je v důchodu, není to jen nějaký driver, který stačí lehce udržovat, ale je to podpora nepřeberného množství driverů a konfigurací na Itanium platformě ve stavu, kdy jí už pomalu nikdo nemá.
Všechny Itania, která jsem v ČR viděl (moc jich teda nebylo) používala HP-UX, HPE to ani s linuxem nikdy nedodávalo a to je největší dodavatel pro Itanium.
A když zjistíš, že nemá smysl se crcat s 8bit AVR, přestaneš ho používat, už ho ani nikde mít nebudeš, tak stejně budeš udržovat podporu pro toto AVR? Co když budeš potřebovat přidat podporu pro jinou architekturu, která bude znamenat větší změny v kódu? Poběžíš si koupit nějaké to AVR, abys zachoval i jeho podporu i když je ti reálně k ničemu?
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 nerecertifikovatelne 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.
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.
Bohuzel... kdyz OSS vzniklo prave jako protiklad k proprietarnim a uzavrenym platformam/nabidkam, 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.
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.