Názory k článku
Čištění kódu x86 APIC, vývojář volá: zbavme se 32 bitů
-
Takze neschopnost vyvojaru spravne spravovat multiplatformni kod (lol, kdyz APIC je pouze na jedne platforme - intel/pc), si odnesou zas uzivatele.
To same se zamky, ktere 30 let nevadili, ale najedou je 32bit SMP fujky a UP vetev to nejvetsi zlo?
Na tohle si budu kluci stezovat porad - protoze to je neschopnyma rukama. Chapu ze dnesni programatori neumi low level, a stari hardcore vyvojari postupne vymiraj.. ale probuh, udelejte to tak, aby nebylo tim jedinym resenim to smazat. Takove reseni vseho zla nechme na okenare :)
-
Peter FodrekZlatý podporovatel
Tom G. určite vie robiť low level. On robi(l) RT preempt.
Ale práve tam robí ten starý APIC alebo až PIC 8259A.
EPIC a x2APIC, xAPIC a každý z nich má inú latenciu
k tomu 8254 a jej emulácie/náhrady.A tan už aj cesty na PCB hrajú významnú úlohu pri tuningu odozvy na zlomky mikrosekúnd.
-
Ono to fungovalo doposud, a ze to je hnuj zjistili sami az se to snazili predelat.
Otazka - proc se akceptoval hnuj do jadra? Nebo "to uhnilo samo" casem, skrze to, jakym zpusobem se kernel placa bez jasnych a future-proof pravidel?
Otazka - opravdu verite, ze si na to nechaji sahnout ciziho?
Otazka - opravdu verite, ze vyvojari kernelu priznaji sve pochybeni?
Doposud se veskere podobne spory resili vyhazovanim kodu.
Je velice nepochopitelne, jak si projekt ktery si hraje na vrchol multiplatformovosti (jista odnoz BSD at tady promine), neni schopen vytvorit paralelni implementace pro 32b UP (s primitivy od 386 po P4), 32b SMP (P/PPro az cokoliv) a 64b at je SMP-only a X86S proof.
Namisto toho existuje jedina za#ifdefovana vetev pro to vsechno.
-
Otazka - proc se akceptoval hnuj do jadra? Nebo "to uhnilo samo" casem… [nepodstatné urážky]?
1. Je normální, že takhle velký a aktivně vyvíjený projekt nevyhnutelně podléhá tomu, že se některé části kódu postupnými změnami znepřehledňují. Každá drobná změna, která tím směrem vede, sama o sobě má dobrý smysl a v tu chvíli stojí za to, ale v určitou chvíli už je potřeba se nad tím zamyslet a celé to pročistit. 2. Svět se mění a kompromisy kvůli podpoře i386, které byly jednoznačně přijatelné v roce 2003 a třeba i 2013, už vypadají optikou roku 2023 trochu jinak. Realita je taková, že mainstreamové distribuce už začínají překládat balíčky tak, že nepoběží ani na prvních verzích x86_64 procesorů, opravdu má smysl to pořád ještě komplikovat kvůli i386?
Otazka - opravdu verite, ze si na to nechaji sahnout ciziho?
Pokud se mu podaří je přesvědčit, že je jeho řešení opravdu přínosem, není důvod, proč by nenechali. Každý (kromě Linuse samotného), kdo něčím významným přispěl do jádra, byl někdy "cizí". Problém je ale často v tom, že ten, kdo s nějakou "zázračnou" změnou přijde, trpí často tunelovým viděním, má před očima jen ten svůj specifický use case a neřeší buď to, že jeho změna rozbije spoustu jiných, nebo že přinese řadu praktických problémů, na které nemyslel.
Otazka - opravdu verite, ze vyvojari kernelu priznaji sve pochybeni?
Děje se to dnes a denně
Je velice nepochopitelne, jak si projekt ktery si hraje na vrchol multiplatformovosti (jista odnoz BSD at tady promine), neni schopen vytvorit paralelni implementace pro 32b UP (s primitivy od 386 po P4), 32b SMP (P/PPro az cokoliv) a 64b at je SMP-only a X86S proof. Namisto toho existuje jedina za#ifdefovana vetev pro to vsechno.
Pokud byste se snažil si o tom něco zjistit, věděl byste, že původně to bylo právě tak, že i386 a x86_64 byly dvě samostatné architektury, a současný stav je naopak výsledkem významného pročištění, protože se stále víc a víc ukazovalo, že většina kódu je duplicitní a může být sdílená a bude přehlednější, když to bude jedna architektura a rozdělené budou jen ty části, u kterých je to potřeba. Pokud se ale (konečně) usneseme, že už nastal čas nechat i386 odejít do historie, bude to pochopitelně ještě přehlednější a ještě snazší na údržbu. Čím déle se to bude odkládat, tím mizivější bude přínos podpory historických procesorů v porovnání s komplikacemi, které to vyžaduje.
Nemalá část problému je i v tom, že kdykoli se začne diskutovat otázka, zda už konečně nenastal čas i386 zahodit, zvedne se sice hlasitá vlna odporu, ale vždy se ukáže, že mezi těmi, kdo křičí, jak je podpora 32-bitových procesorů nepostradatelná, není nikdo, kdo by byl schopen a ochoten ji spravovat. Nebo aspoň zaplatit někoho, kdo by se o to staral - ostatně třeba SLE nemá žádnou 32-bitovou architekturu už od SLE12 (rok 2014) a RHEL AFAIK přibližně stejně dlouho; to dává určitou představu, jak velká je ochota "hlasovat peněženkou" pro zachování jejich podpory.
-
Argument RHEL je stejny jako ze neni 32bit W11. Proste to komercni vyrobce urizne, aby snizil naklady, kdyz v tom nevidi smysl - a uzivatele at se bodnou. RHEL ma za cil bezet jenom na aktualnim hw pod zarukou, stejne jako Win (cca hw zaruka ~ sw zaruka).
Ta ochota spravovat nejakou vetev/subsystem imho klesa s tim, jaky je v tom jadru gulas a nema to jasne dany smer a kompatibilitu - protoze tady nejde o nejakou spravu kodu ve smyslu "dohledu hlidace pole", ale ta sprava obnasi cyklicke preoravani vseho, protoze nekdo si usmysli ze je treba pouzivat jine API modely, jine alokatory, iteratory, atd.
Takze cely vyvoj neskutecne mrha (nejen lidskymi) prostredky, a jde pouze o preslapovani v bahne, a kdo uklouzne, bude eliminovan. Viz prave vas priklad i386 a x64 .. bylo zvlast, bylo spolu, byl to hnuj, smazeme i386. Pritom kdyby to zustalo zvlast, mohla nadale existovat i vykonna 386/UP verze pro dedky jako ja.
-
Proste to komercni vyrobce urizne, aby snizil naklady, kdyz v tom nevidi smysl - a uzivatele at se bodnou.
Správný výraz není uživatelé ale zákazníci. To je v tomto případě významný rozdíl. Pokud by se totiž našlo dost zákazníků ochotných položit na stůl dostatečně velký balík peněz, dopadlo by to tehdy jinak. Myslíte, že třeba ty příšerné opičárny kvůli zachování kABI při backportech děláme proto, že nás to baví? Ne, vůbec nás to nebaví, ale děláme je proto, že to zákazníci chtějí a jsou ochotni za to platit tolik, aby se to firmě vyplatilo. Za i386 ochotni platit nebyli - nebo aspoň ne dost, aby nám stálo za to ji zachovat. Nemám důvod si myslet, že v RH to funguje zásadně jinak.
Pritom kdyby to zustalo zvlast, mohla nadale existovat i vykonna 386/UP verze pro dedky jako ja.
Nepřestává mne fascinovat tohle přesvědčení některých lidí, že vývojáři a maintaineři provádějí zásadní redesign kódu jen tak pro zvrácené potěšení, jak tím zase někoho jako vy naštvali, i když to jim samotným zkomplikuje práci, protože to tak bude pro všechny horší.
Kdyby se Linux vyvíjel tak, jak vy si představujete, tedy nic nepředělávat a neodstraňovat, všechno předem do detailu naplánováno, zpětná a dopředná kompatibilita až za hrob… nebyl by to vůbec takový ráj, jak se snažíte tvrdit. Spíš by dnes už žádný Linux neexistoval a pokud ano, byl by to jen okrajový hobby projekt pro pár nadšenců. To, že je místo toho nejúspěšnějším operačním systémem současnosti, je mimo jiné zásluhou právě upřednostnění pragmatického přístupu před dogmaty a ochoty a schopnosti přizpůsobit se měnící se situaci a požadavkům. Ne všechna designová rozhodnutí, která byla optimální v době, kdy typické nasazení bylo na 32-bitovém jednoprocesorovém systému s 8 MB paměti, jsou pořád optimální v době, kdy je naprostá většina systémů 64-bitových a víceprocesorových a je potřeba, aby všechno rozumně fungovalo i na tisících procesorů a s terabyty paměti.
Jenže kdyby se všechno od začátku navrhovalo na dnešní podmínky, tak by ten systém byl naopak prakticky nepoužitelný tehdy. Nemluvě o tom, že některé věci se předvídat ani nedají; nebo vy si troufnete předpovědět, jaké budou potřeby a typické nasazení za dalších 30 let? Já takový jasnovidec rozhodně nejsem.
Mimochodem, už to sousloví
výkonná 386/UP verze
zní v dnešní době dost úsměvně.19. 7. 2023, 01:45 editováno autorem komentáře
-
"Jenže kdyby se všechno od začátku navrhovalo na dnešní podmínky, tak by ten systém byl naopak prakticky nepoužitelný tehdy. Nemluvě o tom, že některé věci se předvídat ani nedají; nebo vy si troufnete předpovědět, jaké budou potřeby a typické nasazení za dalších 30 let?"
Nejenže by nebyl použitelný tehdy, on by nabeton nebyl použitelný ani teď, protože tehdy by docela určitě nikdo správně netrefil předpoklady dalšího vývoje, a architektury, takže by to byl systém pro před-30-lety-hypotetickou-a-nikdy-neuskutečněnou-architekturu :-)
-
Otazka - opravdu verite, ze si na to nechaji sahnout ciziho?
Ano. Tak to ve vývoji jádra úplně běžně funguje. Samozřejmě v případě komplexnějších věcích si to musíte obhájit.
Otazka - opravdu verite, ze vyvojari kernelu priznaji sve pochybeni?
Někdy ano, někdy ne... je to člověk od člověka jako u všeho...
-
Ja treba nejake stroje na 32b Core mam (notebooky jako terminaly) a mit tam novsi jadro a userspace je nutnost (nespoleham na binarni distra.. jedu Gentoo), protoze ta druha OSS banda zas deprekuje predesle verze SMB, NFS a SSL jak smyslu zbavena. Jesteze se nikdo neopovazil takhle tvrde zakrocit a vypnout IPv4.
18. 7. 2023, 23:36 editováno autorem komentáře
-
32bit na desktopu možná ano. Ale v průmyslu ani náhodou mrtvé není. Životní cyklus velkých strojů a jiných drahých zařízení je úplně jiný než v cloudu.
Udržovat architekturu v kernelu je fakt hodně práce, protože to tempo změn je tam vražedné. A ty změny táhnou hlavně velké firmy s placenými vývojáři, takže tam existuje poměrně silný tlak určitým směrem. Jako jednotlivec nebo někdo mimo mainstream obor nemáte šanci udržet krok, pokud se tomu nevěnujete denně.
Otázkou je, jestli nebude pro ten průmysl levnější přejít na ARM. Ale tam je taky vývoj hlavně u těch 64 bit platforem.
-
Ale v priemysle plati, ze ako sa ten stroj nainstaluje a nakonfiguruje, tak sa nan nesahne dalsie desiatky rokov. Hlavne, ak sluzia, ako ovladanie strojov. Nikto si nevezme na zodpovednost, ze po nejakych zmenach sa rozbije jadro a zastavi vyroba, kym sa to da do poriadku.
Nedavno som videl staru tlaciaren, kde pocitac mal win98, nikto nemal odvahu vymenit ho (klasicky stolny pc) za novsi, lebo spravne nastavenie formatu a programov, ktore tam bezia bolo otazkov tyzdnov. -
32bit na desktopu možná ano. Ale v průmyslu ani náhodou mrtvé není. Životní cyklus velkých strojů a jiných drahých zařízení je úplně jiný než v cloudu.
To je sice pravda, ale u takových zařízení na druhou stranu není nějaká zásadní poptávka po tom, aby na nich běželo aktuální nebo dokonce budoucí jádro. Spíš tam bývá opačný problém: zakonzervované historické verze veškerého software s hromadou neopravených chyb včetně bezpečnostních. Opravuje se jen to, co bezprostředně vadí požadované funkcionalitě, a i pak spíš jen vážné chyby, protože se to celé chová jako chátrající budova: na jedné straně zatlučete hřebík a někde jinde se to začne rozpadat.
-
> zakonzervované historické verze veškerého software s hromadou neopravených chyb včetně bezpečnostních
No právě.. a dneska, kdy se na internet přesouvají snad i varné konvice (Industry 4.0 a nadčasový https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol).
Navíc ty ovládací počítače mohou dostat aktualizace, jenže se asi nikomu nebude chtít přepisovat ty firmware bloby co k tomu jsou potřeba na 64 bit.
V nemocnicích to samé.. diagnostika beztak běží na 32 bit Win XP, protože software a drivery od výrobce už nikdo nikdy neaktualizuje.
Bylo by z hlediska bezpečnosti lepší, kdyby pro takové případy 32 bit distra mohla existovat. Ale zájem je malý a hodně specifický, takže běžná komunita to nemá zájem udržovat no. A lidi z těch oborů to zase nezvládnou.
-
L.Stříbrný podporovatel
> A lidi z těch oborů to zase nezvládnou.
Zvládnout to nemusí, stačí, když jich bude dost, aby za to někomu zaplatili.
-
Jan HrachStříbrný podporovatelDebian teď vydal poslední x86-32 verzi (možná ještě někdo bude držet neoficiální port). Ale stejně tak je zprávička o tom, že se x86-32 vyhodí někdy z nějaké budoucí verze kernelu - stávající normálně fungují. Pak tu bude ještě LTS kernel, a pak to stejně lidi používají i dlouho po konci podpory, takže x86-32 bude potřeba doopravdy vyhodit tak za 10 let.
-
Michal ŠmucrBronzový podporovatel
Já mám zkušenost spíš blíž tomu, co říká M. Kubeček. Tzn. kompletně zachovat původní uzavřený SW a zařídit, aby to běželo na novém funkčním HW (starý uhnil ;)), než obráceně -zkoušet aktualizovat SW, aby běžel na původním HW.
Paradoxně kolikrát si třeba technici jsou schopni i na koleně opravit různé senzory, serva a hardware okolo resp. mají tolik jednotlivých součástek, že by jim to stačilo na dekády :), ale je tam pořád původní software a nespolehlivé staré PC. Výrobce toho celku třeba má novou řadu, nebo skončil příp. se spojil s někým jiným (což je často stejné).
V tomhle ohledu sláva hypervizorům s emulací Intel 440FX. Pokud to komunikuje po standardní síti, je to nejjednodušší, u nějakých standardních lokálních rozhraní (parallel, USB s isochronními přenosy a citlivé na timing) se to dá řešit PCI/PCIe řadičem a passthrough do VM, u specifických proprietárních rozhraní je to ještě opepřeno kompatibilitou s novým MB (ale samozřejmě ISA - pro tohle bez šance).
I když to vypadá jako opičárna navíc, tak se tím dá získat nový hardware, obvyklé výhody virtualizace (snapshoty, vzdálená správa, redundantní uložení dat, filtrace síťového provozu do guesta atd.), navíc to poskytne i třeba další možnosti zabezpečení a segmentace sítě, když se někde ven povolí jen vzdálený KVM přístup (ať už třeba přes VMWare konzoli, VNC, nebo SPICE).19. 7. 2023, 11:48 editováno autorem komentáře
-
Neco na tenhle zpusob provozuji taky - WinXP ve VM, pristup pres RDP.
A zkusenost z toho mam strasnou - po updatu FreeRDP klienta z v1.2 na 3.neco (GIT), najednou nefunguje nejake akcelerovane GDI, ale prenasi se snad kazdy call ke kresleni na klienta, takze vidim jak se 3-5sec prekresluje scena s excelem/wordem, pri maximalizaci okna nebo skoku na dalsi stranku. Se starou verzi rdp klienta to bylo v pohode - zcela realtime - ale nova bud pada (not implemented) nebo dela artefakty. Tak nevim zda jim to uhnilo, nebo z tama neco prozirave vyhodili.. abych mohl porad drzet svuj nazor konzistentne :D Bugy nahlaseny, ale pro tvurce je reseni vypnout akceleraci skrze option.. jen pak je to UX totalne v haji.
Porad je to to same - vsude - delame delame, jen aby to bylo horsi.
-
Zkuste si jenom představit, co by pro tvůrce znamenala oprava toho vašeho bugu. On už totiž pravděpodobně nemá k dispozici mašinu s XPčkama aby to vůbec mohl navodit. A kdoví jestli ta chyba není ještě souhra nějakých daleko vzácnějších okolností. Co když vám ten bug opraví a tím to rozbije někomu jinému, jako jste vy?
Software prostě hnije. Buď díky tomu, že ho někdo mění. Nebo díky tomu, že ho někdo nemění (a jiný kus systému třeba někdo aktualizuje ;) ). Zpětná kompatibilita je ideál, ke kterému se snažíme přiblížit, ale realita do toho trochu hází vidle.
-
Predpokladam ze clovek, ktery pise freerdp/librdp ma k dispozici stroje s win, kde je rdp server v ruznych verzich. Proc jsou nektere BLT operace not-implemented ale fakt nevim - jestli to je taky bile misto ve volne specifikaci, nebo nejaka proprietarni akcelerace, kterou jsou vyvojari rdp klienta lini znova reverznout.
Jako samozrejme jako uzivatel muzu sr*t na jejich roky snazeni a nainstalovat si proste starou, funkcni verzi.. ale komu tim prospejeme? :D (pokud tedy nebude mit jine zavislosti na nejakych starych verzich libek zas)
-
Michal ŠmucrBronzový podporovatel
Tak to se stát může, asi tam budou mít nějakou regresi se starou verzí RDP protokolu z Windows XP, kde byla, tuším, 6. Tak snad se jim to podaří replikovat a vyřešit. Nebo sám zkusit nějak poskákat zpátky a bisectem dohledat, co to rozbíjí.
Ale ty verze freerdp klienta, co píšete jsou nějaké divoké, ta větev 1.x skončila už před pár lety, už docela dlouho je hlavní i vývojová 2.x, a poslední stable 2.10.
Já z Linuxu používám na univerzální vzdálený přístup Reminnu, která má pro RDP protokol freerdp-lib. Na zásadnější problémy jsem nenarazil, ale nepřipojuji se na WinXP.. i když teoreticky bych to mohl vyzkoušet, jestli někde dohledám starou qcow image :)
Jinak RDP do Windows guesta je fajn, když to chodí, samozřejmě je to asi nejefektivnější. Ale v podstatě funguje dobře i RealVNC, nebo TightVNC (pro Windows XP jde ozkoušet i stará verze TightVNC 1.3, kde fungoval DFMirage driver, který efektivněji zachytával obrazovku.
Ale samozřejmě záleží na konkrétním použití, někde ta odezva nebude tak kritická, jinde se může hodit třeba tunelování USB portů nebo sériového portu v RDP do klienta na nějaký panel atp. Jinde zas vůbec nemusí být možnost použít v guestovi vestavěný vzdálený přístup, protože tam běží exotičtějí OS (např. QNX), a je to nutné posílat nahrubo jako framebuffer z hypervizoru, proto jsem mluvil třeba o SPICE, nebo VMWare konsoli.
Laborování included :) -
Michal ŠmucrBronzový podporovatel
Ze zajímavosti jsem to teď v rychlosti zkoušel na jednom ze svých počítačů s lokálním QEMU-KVM. Guest - Windows XP SP2 (ty jsem měl někde schované a nechtělo se mi podstupovat martyrium s offline stahováním aktualizací), typ grafiky virtio, povolil jsem RDP a testoval.
Ze softwaru Remmina to vše chodilo jak z praku i v 2560x1440, žádné artefakty a rychlost v podstatě jako lokálně (myšleno při práci s normálními aplikacemi, nehrál jsem video). Vy jste zkoušel přímo freerdp a říkal jste nějaké úplně jiné verze, ale kdyžtak pro info - relevantní verze balíčků (CentOS Stream 9), možná to můžete zkusit taky.
remmina-1.4.31-1.el9.x86_64
remmina-plugins-rdp-1.4.31-1.el9.x86_64
freerdp-libs-2.4.1-5.el9.x86_64SPICE s QXL typem grafiky a virt-viewer klientem jsem si chtěl otestovat, ale je to v RHEL 8.3 a vyšších deprecated, což se promítlo i do Streamu... musel bych si udělat svou kompilaci QEMU.. do čehož se mi něchtělo, ale pokud alespoň v této podobě šlape RDP, tak mi stejně přijde bezpředmětné.
Jinak máte kdyžtak nějaký odkaz na bugreport třeba na Github freerdp, co jste zmiňoval? -
Jop, zde je pad:
https://github.com/FreeRDP/FreeRDP/issues/9070A jinak me vadi vertikalni cara veprostred:
https://github.com/FreeRDP/FreeRDP/issues/9071Zkousim: net-misc/remmina-1.4.31 (gentoo), pri +rdp to taha zavislost onen net-misc/freerdp, tentokrat ve verzi 2-9999 (tj. nejakou 2.x vetev z githubu).
Vysledek:
- levobocek xfreerdp je:
This is FreeRDP version 2.10.0 (2.10.0)
funguje realtime s tim nedoporucovanym prepinacem /gdi:hw (takze to je rozbity jen v 3.x - pristi/dev verzi?)renmina se zkompilovat nenecha, vidim tam ale:
/usr/bin/i686-pc-linux-gnu-gcc -DFREERDP_REQUIRED_MAJOR=3 -DFREERDP_REQUIRED_MINOR=0 -DFREERDP_REQUIRED_REVISION=0coz tedy nesouhlasi se zavislosti balicku, chjo. Takze vracim 3.x freerdp, a zkousim instalovat renmina bez zavislosti, natvrdo (emerge --nodeps). - taky fail, je to naky rozbity momentalne.
Tak tedy dam posledni 2.x z gitu, zapnu tomu zas /gdi:hw a budu si uzivat ze to zas jede jako predtim. Diky moc za postouchnuti!
-
Michal ŠmucrBronzový podporovatel
Děkuju za odkazy, hledal jsem to předtím, ale nedošlo mi, že už je to zavřené.
S tou Remminou a tvrdou závislostí na FreeRDP 3.0.0 v Gentoo Portage je to divné Ta verze, co používám, se sestaví v pohodě proti FreeRDP 2.x,
https://src.fedoraproject.org/rpms/remmina/blob/epel9/f/remmina.specAž se k tomu doberu, tak si zkusím sestavit git verzi FreeRDP, jestli se mi ty issues projeví taky. U toho binárního balíčku 2.4.1 v CentOSu jsem subjektivně nepozoroval žádný rozdíl v rychlosti v /gdi:sw oproti /gdi:hw ani v těch vyšších rozlišeních, ale to může být i dalšími faktory (používám např. wayland, resp. xwayland pro běh X11 aplikací) a z pohledu Gentoo budu mít asi všude obstarožní knihovny :).
Jinak, jestli u vás chodí aspoň stable 2.x verze, tak bezva, ale samozřejmě pokud mají nějakou regresi v master větvi, tak by to bylo fajn odstranit, než z toho udělají release.
Co jsem se do toho v rychlosti díval, tak jediný commit, který se vykreslování GDI týká, a zároveň není v 2.x, je tohle:
https://github.com/FreeRDP/FreeRDP/commit/ff3c7c82eee7e9220feb8c10d8274e262e7f7584
Teoreticky by se to mohlo zkusit revertnout a sestavit, ale samozřejmě neznám úplně kontext, třeba to řeší nějaké předchozí změny ve vývojové větvi. -
Nic nebrání tomu průmyslu to podporovat.
Pokud už neexistuje jiné odvětví, kterému by se to vyplatilo udržovat, tak buď přejít jinam (X86_64, ARM) a nebo tu podporu zaplatit. Otázka jen je, co je v tomto případě levnější.
32-bit X86 už stejně nikdo ani netestuje, takže nasazovat to někde je hazard sám o sobě.
20. 7. 2023, 10:25 editováno autorem komentáře
-
32-bit X86 už stejně nikdo ani netestuje, takže nasazovat to někde je hazard sám o sobě.
"Nikdo" je možná trochu přehnané, ale za posledních pár let už jsem párkrát narazil na to, že se pro i386 během merge window rozbil build i s celkem normální konfigurací a prošlo to i do rc1, zatímco na x86_64 takové věci obvykle nějaký build bot odhalí (a to i s méně běžnou konfigurací), jakmile se dostanou do mainline nebo i dřív (někdy dokonce hned po poslání patche). No a o míře testování i386 v reálném provozu si nedělám iluze už vůbec.
Nakonec je dost dobře možné, že k odstranění i386 nedojde proto, že by se Linus a maintaineři x86 dohodli, že už nastal čas, ale prostě proto, že se objeví nějaká komplikovanější chyba specifická pro i386 a nenajde se nikdo, kdo by ji chtěl a uměl opravil. IIRC už k tomu dvakrát nebo třikrát nebylo moc daleko.
-
Jádro se aktivně vyvíjí a mění. A udržovat věci, testovat je a dodávat podporu není úplně jednoduchá věc. Když je málo správců a uživatelů daného hardwaru, prostě jde časem pryč.
Není to tak, že tam ten kód zůstane a dokud na něj nikdo nesáhne tak tam bude. Teda vlastně je, ale třeba už ani nepůjde zkompilovat. A jestli půjde zkompilovat, tak třeba ani nebude fungovat. Bude jen štvát vývojáře snažící se pracovat na něčem, co lidé dneska používají.
-
suhlasim, ze raz za par rokov je dobre zakonzervovat vetvu a vyhodit veci, ktore v dnesnej dobe pouziva mozno zopar ludi na starych pc.
Aj tak novsi kernel uz to zariadenie nemusi potiahnut a u starych priemyselnych strojoch je zvykom, ze co sa tam nahodi a nakonfiguruje na zaciatku, tak sa do toho nesaha, kym to ide.
Kto chce linux na starom stroji, tak si tam predsa da verziu +- z tej doby, ktora je vyladena na vtedajsi vykon pocitacov. -
Ono to udržování 32b už opravdu ztrácí smysl protože do 14 let musí všechny tyto systémy stejně zmizet. Zatím se o tom moc nemluví, asi je to pro většinu lidí daleko, ale důvod je jednoduchý: 19. 1. 2038 03:14:07 GMT.
Tedy okamžik kdy na 32b systémech s 32b time_t příští sekundou nastane 13. 12. 1901 20:45:53 GMT. -
Neexistuje důvod, proč by 32-bitový systém nemohl mít 64-bitový typ
time_t, jen to zabere trochu víc místa a některé operace budou trvate déle, ale to je holt život. Problém je spíš s existujícími komunikačními protokoly a datovými formáty, kde jsou natvrdo 32-bitové časové známky (případně jejich obdoba), ale ten se týká úplně stejně i 64-bitových systémů. -
Teoreticky máte pravdu, SUS váže time_t na long a není důvod proč by na 32b systému nemohl být long 64-bitový. Kdysi jsem to dokonce považoval za logické - tedy že na 32b systému je short 16b, int 32b a long 64b.
Jenomže v reálu mi v minulosti prošlo rukama dost 32b *nix systémů a nevzpomínám si na jediný kde by byl 64b long. Pravda, všechno to byly serverové / desktopové OS, s řídícími systémy jsem se nesetkal takže tam nevím. Ale protože předpokládám že důvod implementace longu na délku slova procesoru je ve výkonu tak bych nečekal že u nich to bude jinak, ale to by mohl posoudit spíš někdo kdo s nimi pracuje.
A platilo to i pro Win ale s těmi naštěstí už dlouho nemám co do činění. Nicméně pokud tu někdo zmiňoval řídící systémy ve zdravotnictví založené na 32b WinXP tak tam bych to viděl jako reálnou hrozbu. A pokud vím tak např. bankomaty jsou to samé. -
Ale jsme zas u toho:
Namisto toho, aby tvurce takoveho udelatka nasadil proste aktualni mainline a userspace, ktery resi problematiku prechodu 32 na 64 bit unixtime komplexne, tak je situace tahle (z duvodu, ze puvodni platforma nebo nektere device drivery tam uz nejsou):
Nekde se musi vyhrabat sada patchu ktera prinesla 32->64 prechod (vsechny promenne, novy syscall), pak to musi nekdo pretvorit na starou verzi kernelu, ktera v tom udelatku byla. Po nasazeni se zjisti, ze je treba udelat omnoho vice - treba userspace hwclock tool, nebo hardcodovat dalsi epochu. Takze vznikne nejake bastl reseni / nedokonaly hack. A to nemluvim o padajicim glibc, ktery je taky sprazen bud s 32b nebo 64b casovanim a syscally.
Jop.. zazil jsem tu dobu kdy byl kernel napred ale muj userspace nikoliv a dost jsem se divil ze takova blbost jako timestamp nesla resit lepe, kdyz se o problemu vedelo.
Bohuzel stav, ze vse se vsim souvisi a neexistuje stabilni verzovane API, ktere by mohli koexistovat zaroven, protoze vzdy jsme v nejakem prechodnem obdobi nenahrava dobremu jmenu.
Tento smer ale adopovali nedavno i W10/W11, kde kdyz tvorite drivery, tak mate s tim porad praci i kdyz se u vas nic nemeni. Pritom vypadavaji moznosti, ktere tam predtim byly a uz nejsou. Plus neustale zmeny ve zpusobu podepisovani, atd.
-
Tady máte prostě jenom dilema, kdo ty náklady na vývoj ponese.
Buď to bude "platit" vývojář driverů, protože se mu bude měnit api jádra.
Nebo to budou platit vývojáři jádra, protože budou muset udržovat X starých verzí. A navíc ty staré verze budou formovat další vývoj, protože některé změny do nich promítnout prostě nepůjdou.Jo, Microsoft na tu zpětnou kompatibilitu hodně tlačil. A díky tomu je i nejnovější winapi totální hnus. Protože i nová funkčnost musí brát v úvahu zkamenělé rovnáky na vohejbáky z dob 16b intelů. Tohle taky nenahrává dobrému jménu, jen u jiné skupiny lidí.
-
To mi připomnělo původní hru Transport Tycoon Deluxe. Jednou (už je to dávno, člověk měl čas na hraní) jsem totiž dosáhl u své společnosti na účtu částky £2,147,483,647. Hra kupodivu nespadla a ani to nepřeteklo do záporné hodnoty. Jen hodnota společnosti najednou spadla až někde "do pekla" na -£2,147,483,648 . Obě hodnoty při dalším hraní zůstávaly stejné bez ohledu na to, co člověk dělal. Trochu jsem měl strach aby mne nekoupil nějaký konkurent ale tehdejší "AI" to neměly ve zvyku :-)
