A Fedora 37 *NEM* kezdi meg a BIOS támogatás kivezetését

AlmaLinux, CentOS, Fedora, Red Hat, Rocky Linux

Változtatási javaslat érkezett a Fedora Engineering Steering Committee-hez (röviden: FESCo), amiben a beterjesztő a BIOS támogatás fokozatos kivezetésének megkezdésére tett javaslatot az UEFI-s platformokon (x86_64). A javaslatot a bizottság elutasította.

( sibike | 2022. 05. 05., cs – 12:09 )

Ameddig egyes gyártók UEFI támogatása ennyire gyatra, addig szerintem ez a bölcs döntés.

Olvastam egyszer az UEFI történetét.

Ugyanaz a "díszes társaság" találta ki, nyomatja, mint akik annak idején az ACPI-t is. Azzal is volt szívás pár évig.

Itt már a pár éven túlvagyunk.

Az biztos, hogy a BIOS architekturális korlátai elég komolyan mutatkoztak, de ez mondjuk megoldható lett volna egy 32/64 bites real módban való indulással is.

De ha már úgy is létrehoztak egy elvileg széleskörűbb (nem csak x86-ot támogató) szabványt, végül is logikus volt azt használni, mintsem újat barkácsolni, valamint ha nem kell bajlódni az üzemmód váltásokkal, egy idő után akár a processzorból is elhagyható ez az örökség,a 16 bites programokat már úgy tudom 64 bites Windows úgy sem kezeli natívan, Linux alatt meg szó se nagyon volt ilyesmiről.

A 16 bit nem a programok futtatása miatt jön be, hanem mert a BIOS architektúrában a proci real módban indul, amiben csak 1 MB a címezhető memória, és a periféria kezelő option ROM-ok ennek a felső 384k-jába vannak bemappelve.

Alatta található a híres-hírhedt 640k "conventional" memória, ami valóban RAM.

Ugyanis a PC BIOS eredetileg csak MDA és CGA monitort kezel, már egy EGA vagy VGA kezeléshez külön BIOS-ra van szüksége (VGABIOS). De ugyanígy a hálózati boot-hoz is megvan a hálókártya boot ROM-ja, ami szintén ebbe a 384k-ba van mappelve. Meg az USB driverek, meg a minden kutyafüle ami azóta jött.

Aztán ez az egy mega RAM egy kicsit kevés lett.

Most lehet le leszek oltva, de amúgy szép hogy a UEFI platformfüggetlen, de ki is használ UEFI-t PC-n kívül? Én még egyetlen embedded rendszeren sem találkoztam vele.

Ezzel még egyet is értenék, ha ez nem fordítva lenne. A gyártók (és virtuális gépek fejlesztői) UEFI támogatása azért gyatra, mert a sok őskövület OS, fejlesztő kiszolgálja azon lustaságukat, hogy elég a Legacy / CSM BIOS módot támogatni. Addig meg nem fognak mást rendesen támogatni, nincsenek rászorítva, ők várják el, hogy mások alkalmazkodjanak hozzájuk. Plusz sok konzervatív user is azért bootol még BIOS boottal teljesen szabályosan UEFI kompatiblis hardveren, mert „csak”, mert azt szokták meg.

Plusz azok a gépek, amiken a soványnak épp nem nevezhető Fedora alap spinek (Gnome 4x, KDE 5.x) jól futnak, azok úgyis támogatják az UEFI bootot és fordítva, azok a hardverek, amik nem (C2D, C2Q, ezeknek megfelelő Athlon x-akárhány proci, az még határeset kategória), azokon meg már a Fedora úgyis bloat (sok a procinak, meg RAM limitbe lehet futni), és élből valami soványabb disztró való rájuk, AntiX, Sparky Linux, alapabb WM-es Debian, MX, stb.

Én egyébként mindenkit bátorítani szoktam, hogy UEFI bootot használjon, és szakítson a Legacy boottal, ha a hardvere támogatja. Az UEFI boot és a hozzá dukáló GPT több szemponból kulturáltabb: az UEFI önmagában is egy boot manager, kiválthatja a GRUB-bal ökörködést (helyette systemd-boot vagy EFI stub boot is elég), az egyes OS-ek nem írják át egymás alatt az első szektort, hanem a bootindító kódjuk megfér egymás mellett az EFI partíción .EFI fájlok formájában. A GPT ezen felül azért is jó, mert több partíciót támogat, 128-ig, nem kell elsődleges, kiterjesztett, logikai partíciófajtákkal, bootflagekkel, stb.-vel szórakozni. GPT-nél még sorban sem kell a partícióbejegyzéseknek tárolva lennie, és átnyúlhatnak partíciók egymáson. Plusz jó pár gép van, ami gyorsabban bootol UEFI-vel, mivel ebben a módban a gép induláskor kihagy egy csomó hagyományos BIOS POST tesztet, meg gyorsabban detektálja a lemezeket, bootolható rendszereket, néha így több másodperc is lefaragható a bootidőből. NVMe SSD-kről bootolásnál is kötelező az UEFI boot.

Innen nézve szerintem ilyen modern gépekre való bleeding edge rolling disztróknál teljesen jó, ha nyomják a 64 bit és UEFI only témát. A secure boottal és TPM-mel nem értenék egyet, azok túlzottan MS-os módszerek már, de a másik kettő ma már abszolút alap. Akinek meg régi gépe van, sok másik konzervatív disztrót talál magának, Debian, Slackware, Alma/Rocky, de Archot, Arch32-őt és Gentoo-t is bármikor fel lehet tenni bármilyen bootmódban, régebbi architektúrákra is.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

GPT vs. MBR = teljesen külön téma. Azt nem tudom hogy UEFI tud-e bootolni MBR-ről, de a BIOS egész biztosan tud GPT-ről. A BIOS boot ugyanis annyi, hogy betölti a diszk első szektorát a RAM-ba, és elkezdi futtatni. Ennyi. Tökmindegy, hogy milyen fájlrendszer van rajta.

Más kérdés, hogy sok UEFI (ami csak emulálja a BIOS-t) ha GPT-t lát akkor nem hajlandó legacy boot-al elindulni.

Pont fordítva van. Az UEFI tud MBR-ről, de a BIOS-nál a GPT boot általában nincs, legalábbis a szabvány szerint, egyes nem szabványos implementációk elbírhatnak vele. Ez a BIOS boot meg csak addig királyság ám neked, amíg nem akarsz több OS-t multibootolni, meg amíg az indítókód belefér az első szektorba. Ha ezek nem állnak fent, onnantól a fetrengés van vele, és az UEFI boot az egyszerűbb. Mint írtam, UEFI-nél is épp úgy tölti a RAM-ba az OS indítókódját, de nem az első szektorból, hanem a FAT fájlrendszerű (ez lehet akármilyen hagyományos, nem exfat, hanem klasszik FAT, FAT12, FAT16, FAT32) partícióról emeli be EFI fájlként, ezek lehetnek akármilyen nagyok és kulturáltan megférnek egymás mellett, ezzel a bootmanager is elhagyható, mert az UEFI egymagában is egy boot manager már.

Ami miatt sok ember utálja az UEFI-t, mert összevettek egy csomó szutykos harvert, amin nem szabványos az UEFI implementáció, 32 bites, vagy Windowsra drótozott (főleg HP-knál probléma), meg erőltetik feleslegesen a secure bootot, és nem értik, hogy hogyan működik az egész.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Nem, nincsen fordítva. A rendes PC BIOS teljesen független az alkalmazott fájlrendszertől. Igen, vannak limitációi, 512 byte valóban nem sok, ám ez eddig senkit nem akadályozott meg, sem az MS-DOS idejében, sem a LILO-t, sem a GRUB-ot.

A limitáció ott létezik, hogy a BIOS megvalósítása során implementálni kell a BIOS hívásokat: https://en.wikipedia.org/wiki/BIOS_interrupt_call

A 13h hívás a lemezkezelés. Ez pedig valóban a BIOS-tól függ, hogy mekkora diszket tud kezelni, hiszen hiába van egy level 2 bootloader valahol a diszken, ha a BIOS interfész olyan ősi, hogy nem éri el. 512 byte-ba pedig nemigen fér el diszk driver, főleg ha mindenféle SATA meg egyéb lemezeket kell támogatni.

Megoldás? Természetesen van, egy megfelelő diszk driverrel felül kell csapni a 13h hívást (erre a PC architektúra lehetőséget ad). Ezt egy olyan lemezről kell betölteni, amit a BIOS elkezel. A DOS időkben, amikor még a 13h-val ment a lemezkezelés (a DOS-nak nincs saját diszk drivere), akkor ilyen utility-ket lehetett betölteni, amivel a DOS-BIOS limitációkat megkerülve lehetett kezelni a nagyobb lemezeket.

Ez azonban mind csak a nagyon ősi hardverekre vonatkozik, praktikusan a 2000 után néhány évvel kijött BIOS-ok már "akármekkora" lemezeket kezelnek, és bootolni is fognak róla, akkor is ha GPT van rajta. Tudom, csináltam.

Más a helyzet viszont az UEFI gépekkel, ne tévesszen meg a "legacy boot" mód. Ott UEFI van, ami aztán emulál egy BIOS-t, de a fentebb említett okosságokkal van megtűzdelve, és ott bizony én is találkoztam olyannal, hogy GPT-ről nem tudott bootolni BIOS módban. Ugyanaz a lemez tökéletesen elindult egy régebbi, UEFI-t nem ismerő gépben.

Ez a fenti mese amit leírtam, annak mi a tanulsága? Hogy amikor a BIOS-t kitalálták, hogy adjanak egy szabványos interfészt, mi lett a vége? Hogy senki nem használta, mert lassú volt. Direktben kezelték a hardvert. A UEFI-ben ennél 100x bonyolultabb interfészeket kell megvalósítani, de az OS számára ezek az interfészek már nem elérhetők. Akkor meg mi értelme volt az egésznek?

Mert ha mondjuk megcsinálnak egy szabvány VGA kezelést pl. az tök jó lehetett volna mint egy fallback driver ha más nincs. A BIOS ezt tudta. Más kérdés, hogy az nem az alaplapi, hanem a VGA kártya saját BIOS-a volt.

Nem értem, hogy miért hajtogatosd ezt a fájlrendszert. Az MBR nagy limit ma már, 512 bájt semmi, semmi nem fér bele. Plusz a legnagyobb korlátja a legacy BIOS-nak, hogy a proci valós módban megy, 16 bitesen, egy feladat, alapból nuku multitasking, 1 procimag 100%-ra kipörgetve, kihevítve, 640 KB-os memóriakorlát, amibe szintén nem fér bele. Legalábbis a  mai igények nem, grafikus-egeres GUI UEFI felület, fancurve kezelése, online frissülő BIOS, egyéb kényelmi funkciók. Pont ez a baja az MBR-nek, legacy BIOS-nak, hogy a DOS korszakban rekedt meg, aminek már 25-30 éve vége. Ez a INT 13h is addig szép, amíg sztenderd IDE interface-en lógnak a meghajtóid, ahogy elkezdesz USB-s meghajtóval, meg SATA2-3/AHCI, NVMe, stb. meghajtókról bootolni, nagyon gyorsan véget ér a tudománya. Ma már senki nem használ analóg VGA-t, meg 16 bites módot, már rég 64 bites gépek mennek, több mag, több giga RAM, mindenféle modern SSD-k, inkább ösztönözni és rugdosni kelll a gyártókat, hogy ezt támogassák, ami rendesen kihasználja a hardver lehetőségeit, és ne egy 30 éves megoldásba konzerválódjanak be. Már pedig itt a Fedora esetén egy modern, 64 bites rendszerről van szó.

Az, hogy a FAT fájlrendszertől függ az EFI, az meg nem jelentős korlát. Lényegében egy nagyon primitív fájlrendszer, nyílt forráskódú, szabad licencű (lejártak róla a szabadalmi jogok), minden natívan támogatja. Az meg teljesen jó, hogy az UEFI nem elérhető az OS-nek, ne is használjon UEFI, BIOS hivásokat, mert akkor BIOS/gyártófüggő lesz a kód.

GPT-t meg a klasszik BIOS nem támogatja. Az ne tévesszen meg, hogy néhány modern BIOS, meg modern UEFI által emulált BIOS mód támogatja a GPT-t, az kivétel, nem fő szabály. Ez a legacy BIOS ma már csak fallback opció, csak akkor ajánlom bárkinek a használatát, ha nincs más választása, olyan régi a gép, vagy valami legacy OS-t kell bare metal futtatni, ami nem tud máshogy bootolni. Lassan már ez a fallback opció is megszűnik, mert majd jönnek sorra az olyan gépek, amiken már az UEFI legacy BIOS-t sem emulál, pl. Intel Core i 10-12. gentől már vannak ilyen alaplapok, és ugyan AMD-n támogatott, de már ott is csak egy kis ideig, és eleve sok ilyen rendszer legacy visszafelé kompatibilitását már úgy is kinyírta, hogy nincs IDE emuláció sem.

Pl. pár éve próbáltam egy régi Core i-s laptopon valódi MS-DOS-t futtatni, bare metal alapon. Tehát nem virtuális gép, emuláció, hanem fizikai hardverről. Már azt is nehéz volt belőni, hogy a SATA SSD-t lássa, bootoljon, de bootolás után semmit nem lehetett vele kezdeni, pl. a HIMEM.SYS, EMM386 szépen kiakadt, mert nem tudta kezelni az A20 vonalat (mikor az 1 MB feletti memóriarészt kellett volna elérni), plusz semmilyen hardverhez nem volt driver. Próbáltam egy 2. genes Ryzen-es gépen is, ott még rosszabb eredmény volt, mivel IDE emuláció sem volt az UEFI-ben, így hiába is kapcsoltam be a CSM legacy BIOS módot, már nem bootolt be. Erről ennyit, hiába a visszafelé kompatibilitás az x86-tal, ez már csak marketing, semmire nem használható. A mai procik eleve rég már nem is x86-osak PC-ben sem, inkább csak hardveres emulálják az x86-os utasításokat és módokat. Mióta a memóriavezérlőt is integrálják, azóta meg a memóriakezelés is le lett húzva a wc-n, nyugdíjazva lett a floppy, IDE, stb. is.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Rengeteg tévedés van abban amit írsz.

Az MBR nagy limit ma már, 512 bájt semmi, semmi nem fér bele.

Az MBR-be bőven belefér annyi, hogy hol találja a rendes bootladert. Több nem is kell bele.

A BIOS 16 bites futásáról: a BIOS 16 biten adja át a végrehajtást az MBR-ben tárolt kódnak, de a BIOS előtte természetesen megy protected módban (vagy talán "unreal módban") is, hisz máshogy hogyan csinálna memóriatesztet?

alapból nuku multitasking, 1 procimag 100%-ra kipörgetve, kihevítve, 640 KB-os memóriakorlát, amibe szintén nem fér bele

Nem használja senki manapság már a BIOS interfészeket. Nem is mondtam, hogy nem elavult. Csak azt mondtam, hogy nem biztos hogy a UEFI lett volna a legjobb irány.

Legalábbis a  mai igények nem, grafikus-egeres GUI UEFI felület, fancurve kezelése, online frissülő BIOS, egyéb kényelmi funkciók.

Ezt mind meg lehet valósítani BIOS alatt is. Grafikus felület már volt a '90-es években is (AMI winbios). Fancurve: alaplapi firmware kezeli, nem a UEFI. Ne tévesszük össze a setup-ot a BIOS-al! A setup program egy BIOS gépen is lehet akármilyen bonyolult, nyugodtan futhat protected módban, elérheti a teljes memóriát, minden eszközt. Ez nem BIOS korlát.

A BIOS maga: Basic Input-Output System. A BIOS maga az általam fent linkelt BIOS hívások megvalósítása. A BIOS annyi, hogy ezeket az IBM által szabványosított interfészeket biztosítja a programok számára. Nincs köze sem a POST teszthez, sem a setup programhoz.

Ez a INT 13h is addig szép, amíg sztenderd IDE interface-en lógnak a meghajtóid, ahogy elkezdesz USB-s meghajtóval, meg SATA2-3/AHCI, NVMe, stb. meghajtókról bootolni, nagyon gyorsan véget ér a tudománya.

Fenéket. Int13h driver simán megy AHCI-val, mindig is ment. NVMe-ről valóban nem hallottam, de elméleti akadálya nincs. USB boot szintén volt a BIOS korszakban, bőven. Az igaz, hogy az int13h megvalósítás (de nem az interfész!) valóban változott az idők során. Mivel amikor kijött, akkoriban még a mai diszk méretek elképzelhetetlenek voltak. De ezeket már rég megoldották, 1994-ben már volt 28 bites LBA (128 GB limit), és 2003-ban a 48 bites LBA (128 EiB limit).

Ha pedig jönne egy új driver típus? Semmi gond, mert mint mondtam a BIOS hívások felülírhatók szoftveresen, így kb. _BÁRMI_ támogatható. A DOS erában is meg tudták oldani a nem LBA kompatibilis BIOS-okkal, hogy kezeljék a nagyméretű lemezeket. A syslinux-ban van egy utility, a memdisk: https://wiki.syslinux.org/wiki/index.php?title=MEMDISK

Beleáll az int13h-ba, és akár komplett CD vagy HDD lemezképeket tud emulálni bármi számára ami int13h-t használ lemezkezelésre (DOS, Win9x).

Ma már senki nem használ analóg VGA-t

A VGABIOS soha nem az analóg VGA kimenetről szólt. Szomorú hogy ez keveredik. VGABIOS ma is van az összes GPU-ban, mégpedig azért hogy BIOS gépbe is be tudjad dugni, de lehet hogy a UEFI rutinok is itt vannak, ehhez nem értek. ISA buszon megy? Nem. Ettől még funkcionálisan ugyanazt csinálja: a memória egy jól meghatározott helyére be van mappelve a GPU BIOS chipje, ahol ismert bináris hívások találhatók. Ezekkel a hívásokkal megvalósítható bármilyen GPU alapvető kezelése. Ezért tud menni egy modern alaplapban akár egy S3 Trio (ha van benne PCI foglalalt), meg akár egy bármilyen modern PCIe csoda is: mert ugyanaz a szabványos interfész rendelkezésre áll.

A VGA kezdeti korában még nem volt nagyon divat a BIOS frissítés, de ez nem korlát: mivel a VGABIOS-t a sebesség miatt átmásolták a RAM-ba, az is felülcsapható. Sok kártyán így biztosították a VBE támogatást, és akkor tudott menni a quake 1 640x480-ban is :D

GPT-t meg a klasszik BIOS nem támogatja. Az ne tévesszen meg, hogy néhány modern BIOS, meg modern UEFI által emulált BIOS mód támogatja a GPT-t, az kivétel, nem fő szabály.

Mondom hogy fordítva van. Mutatok neked bármikor 2008 körüli, UEFI-t nem tudó gépet. Simán bebootol GPT-vel, akármekkora lemezről. Ehhez csak annyi kell, hogy tudja a 48 bites LBA-t, amit írtam hogy 2003 óta van.

Igen, UEFI gépekben valóban fallback opció van csak, és ott találkoztam olyannal, ami jól kezeli, meg olyannal is, ami nem.

A DOS-részhez: nemigen próbáltam ennyire modern gépen MS-DOS-t futtatni, és valóban lehetnek vele gondok. De ennek megint nem az A20-hoz van köze. A gate A20 rég nem a keyboard kontrollerben van megvalósítva, de a gépek kompatibilitás miatt ezt szokták emulálni. A gate A20 egyébként épp a régi, 16 bites programokhoz kell, protected módban nem kell. Tehát ha nincs támogatás, akkor épp folyamatosan elérné az 1 mega feletti memóriát. Olvass utána hogyan működött, meg miért kellett.*

Mióta a memóriavezérlőt is integrálják, azóta meg a memóriakezelés is le lett húzva a wc-n, nyugdíjazva lett a floppy, IDE, stb. is.

Az AMD-ben már rég integrált memóriavezérlő van, ennek semmi köze ahhoz, hogy milyen interfészeket valósítanak meg. Van AM2-es gépem, abban már bőven integrált memóriavezérlő van, aztán mégis van benne IDE-is, floppy is, meg még a DOS is elfut rajta (https://www.gigabyte.com/Motherboard/GA-MA78GM-S2H-rev-10). Ezek nem architekturális problémák miatt lettek kivezetve, hanem mert nem volt már rájuk igény.

*Na most csak a kedvedért beröffentettem a DOS-t ryzen gépen... működgetett :D

Memóriadiskről is (network boot), és CF kártyáról is (USB olvasóval): elindul, igen a HIMEM is, látja is a RAM-ot. Viszont gyakorlatilag semmilyen grafikus programot nem sikerült rajta elindítani, szétesik a kép. Ez vélhetően már VGABIOS limitáció, nem kezelik ezeket a régi hívásokat.

Win98SE install ISO-t nem tudtam network boot-al elindítani. ODD nem volt ebben a gépben.

Nagyon szépen összefoglaltad a dolgokat. Sőt, ebből rájöttem az egyszerű megfejtésre! Miről is van szó?

Alaplap + BIOS (firmware) + DOS - Ez egy működőképes rendszer.

Menjünk el kicsit a nagyob és zártabb világba!

A szervereknél OpenFirmware és a CHRP (Common Hardware Reference Platform) valósította meg a hadver egységes támogatását, azaz a firmware-t. Bár ez zártabb világ, de később belátták, hogy "külsősöket" is be kell engedni a zárt világukba.

A szerverek nem kényszerültek olyan kompatibilitási problémák kezelésére, mint a 16 bites programok futtatása 20-30 év múlva, ezért könnyebb dolguk volt.

A pécé világ ezért mozgott lassan és nehézkesen, de most megérkezett az uefi, ami érdekes módon így néz ki:

Alaplap + firmware + oprendszer = működőképes rendszer. Szóval semmi sem változot: Az oprendszer nem támogatja a hardvert, nem képes elindulni róla, és ehhez egy helperre van szüksége. Ez pedig a firmware - bárhogy is hívjuk.

Ma már sok és bonyolult hardver elem kerül egy pécébe, lehetetlen mindenre felkészülni. Ehhez szükséges még egy kis fs, amin elfér az összes driver (eszközfüggő firmware). Pont olyan, mint a linux kernel + initrd, csak próbálják jól-rosszul egységesíteni.

Mi volt a BIOS és az UEFI között? Az AM3-as alaplapomon a dmraid másképp működött Windows és linux alatt. Míg a linux kernelben megítrák a kezelését, a Windows dll-eket töltött be a helyes működéshez. De ezek a dll-ek a BIOS-ból érkeztek, és ez elég szörnyű!

Ha az MBR-en kívüli bootkódot nézed, az épp úgy egy fájlrendszeren lesz. Ehhez képest az EUFI előrelépés, mert az egész egy fájlrendszeren van, és nem írogatják az egyes OS-ek felül egymás MBR kódjait. Ha modern rendszert bootolsz, akkor a fájlrendszerhez kötöttséget sehol nem fogod tudni elkerülni.

Az UEFI-ről még én sem állítom, hogy jobbat nem lehetett volna kitalálni, de a Legacy BIOS-os MBR bootnál különb, rugalmasabb. Továbbá nem kevem, BIOS-on több mindent értenek. Nem csak a BIOS hívásokat, az is része, de ezen kívül beleértenek bizony mindent, a setup részét is. Lehetni lehet ennek ellenére sok mindent a hagyományos BIOS-szal is, de túl sok ma már a limitje, amit kerülgetni kell. El kéne engedni, 30 évvel ezelőtti helyzethez készült, mikor még XT-k meg floppy-k, MFM HDD-k uralkodtak, 16 bites DOS korszak volt, stb., ezt már keresztben-hosszában meghaladtuk, ennek ellenére körbehekkelésekkel (lemezméret korlátai, bootflagekkel szórakozó bootloaderek, stb.), életben tartották, de így is már túl régóta van életben tartva. Ezért feleselges további hozzá ragaszkodással életben tartani még nem tudom hány évig, mert ezzel csak a fejlődést hátráltatod, és a gyártókat (meg szoftverfejlesztőket) hozzászoktatod, hogy nagyon helyesen teszik, hogy az UEFI-t nem támogatják rendesen szabvány szerint, mert te az elavult rendszerükkel, gyakorlatukkal is beéred. Fedoráék pont ezért próbálták most ez behúzni, hogy háhta ezzel kényszerhelyzet teremtődk. Ahogy pl. sok disztró, és a Gnome-osok a default Wayland sessionnel nyomást gyakoroltak az Nvidiára. Igen, ez a fajta kényszer fájdalmas lehet egyeseknek, de valamilyen ár nélkül nem megy.

Az AHCI-vel és VGA BIOS-szal kapcsolatban valószínű tényleg tévedtem, de az is igaz, hogy idekeversz annyi félét, hogy lehetetlen követni. DOS-ról nem tudom hogy tudtad működésre bírni. Nem csak az EMM386 volt a gond, DOS4GW-s, PMODE32-es, DPMI-s játékok is beleálltak a földbe, nem indultak, valami illegal instruction error, vagy valami hasonló crash kíséretében. Mint írtam, nálam ryzen-es gépen be sem bootolt, régi intelesen igen, de ott sem volt használható. Ez is csak azért írom, mert sokan a visszafelé kompatiblitással jönnek, ami mára már csak mese habbal. A régi, klasszik IBM PC / DOS-kompatilibis platformból már nem maradt semmi, szinte az összes részét leváltotta valami modernebb interface, protokoll, stb.. Aki meg régi rendszert akar futtatni, az használjon virtuális gépet, emulátort, a modern hardvernek már nem nagy overhead a bare metal futáshoz képest.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Igen, ebben igazad van, technikailag pontatlanul írtam. Az MBR-ben lévő indítókódot támogatja, nyilván a partíciós tábla részére nem kíváncsi. Viszont szabvány, klasszikus megvalósításban nem támogatja pl. a GPT-t semmilyen szinten. Az ne tévesszen meg senkit, hogy egyes modern BIOS-ok implementálták, hogy lehessen GPT-t is használni, meg az újabbak gépek úgy csalnak, hogy valójában UEFI-ről van szó, és a legacy BIOS módot csak emulálja, de nem valódi BIOS-t futtat.

Az egészen nyugodtan csűrhetjük-csavarhatjuk még 100 hozzászóláson át, hogy mi mit támogat, meg technikailag hogy pontos nevezni, az lényeg lényegében a lényege, hogy sokan indokolatlanul félnek az UEFI boottol, mert egyszer valami ótvar gyártó ótvar gépén egy tré, nem szabványos UEFI implentáció, vagy egy rosszul megírt OS intaller, és esetleges felesleges secure bootos meg céges Bitlockeres kavarás jól megszopatta őket, nem tudtak telepíteni, vagy lement telepítést bebootolni, és elment tőle a kedvük. Emiatt sokan elkönyvelték, hogy ez is valami modern, komplex fos, amit nem lehet megérteni, fekete mágia, fölösleges, stb., közben meg egy jó dolog, ha észszerűen van használva, és nem hogy nem bonyolítja a bootolást, hanem egyenesen megkönnyítheti. Nyilván, ha valami nem szabványos implementációjával találkozik az ember (pl. Windowshoz fixen van bedrótozva és lekorlátozva, meg pl. 32 bites implementációról van szó, amit sok OS nem támogat), az néha tényleg pain in the ass, mire működésre bírja, meg ugye ott vannak a régi gépek, amik nem támogatják, bár utóbbiak fokozatosan kopnak ki.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( solt87 | 2022. 05. 05., cs – 14:24 )

Azt mondta a FESCo,
Nem kell itt a feszkó:
Megmarad a BIOS --
rémhírek, adios!

( Raynes | 2022. 05. 21., szo – 22:15 )

Egyébként senki ne örüljön, hogy nem vezették ki, a Red Hat ökoszisztémában továbbra is erőltetve lesz a fejlődés, majd dobják még 1-2 verzió múlva, ami késik, nem múlik, ezt garantálom. Pl. vannak már userek, akik azon kapták magukat, hogy a 2014-es dual core i5 Haswell-es Macjükön nem megy az RHEL9, mert az x86_64-v2 feature levelnek nem találja megfelelőnek a procit.

Kicsit meredek, de nem teljesen bullshit. Épp most olvastam a Phoronixon, hogy az újabb RHEL-alapú disztrók milyen gyorsak lettek. Régen ezek jóval le voltak maradva egy Clear Linuxhoz és Arch/Fedora kombóhoz képest, még ilyen hagyományos Ubuntuktól is kikaptak, most mekkorát fordult az egész. Jó, a Clear Linux vezet még, de ott az Intel csal, eleve agresszíven van a legújabb procikra optimalizálva a kód, meg nem teljesen full generic disztró, pl. desktopnak nem jó, mert egy csomó csomag nem érhető el a tárolójukból, mert az egész felhőzésre van belőve. Kicsit az RHEL is csal, mert default performence P-mode CPU governor van belőve, ami max. alapfrekin járatja a procit. Első nekifutásra féltem tőle, de most tesztelem én is Archon a default shedutil helyett, és bár gyorsabbnak eddig nem érzem, de annak ellenére, hogy a procit nem 1,4-1,7 GHz-es órajelen pihenteti, hanem a 2 GHz-es alap frekin tartja, ahhoz képest csak alig pár fokkal melegebb a Ryzen 4700U proci, és ha nincs terhelés alatt, a venti is épp úgy leáll rajta.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)