Index cikk a BIOSrol

Fórumok

http://index.hu/tech/2010/06/11/halalan_van_a_bios/

Olyan kis aranyos :) Hoyg a BIOS-nak az a legnagyobb baja, hogy szoveges, nem egeres :) Hatigen, jo esetben max. evente nyul az ember a BIOS-hoz, akkor roppant fontos, hogy GUI legyen.

UPDATE: "Hoyg a BIOS-nak elsosorban az legnagyobb baja, hogy 2T meret feletti wincsirol nem tudo bootolni, masodsorban, hogy szoveges, nem egeres :) "

Hozzászólások

Eddig legalább a BIOS-t megírták abszolút funkcionálisan, assembly-ben. Most már ezt is kényelmesen, C-ben, v.milyen fordítóval, már a boot szintjén pazarolva az erőforrásokat. Hülyeség!

1-2 olyan kiegészítésnek viszont látnám értelmét, ami a boot-ot, működést gyorsítja. Mint pl. egy hardware-config mentéssel kikerülni a minden boot során lefutó komplett hw tesztet és detektálást, illetve esetleg az OS boot egy részét átemelni a HDD-ről a BIOS-ba.

Már 486-oson is volt egeret is kezelő, Win 3.11 felületét utánzó GUI BIOS setup. És nem kellett hozzá egérdriver sem!! Vajon hogy csinálták? :O (sőt billentyűzet driver sem, igazi boszorkányság)

(tipp: generic driverek, vesa, ilyesmi fogalmak ismerősek?)

szerk: látom a 486--P3 korszak kimaradt, akkor az sem ismerős, hogy régi BIOS-ok nemnagyon ismertek fel náluk x évnél újabb nagy merevlemezeket, volt 500 MB, 2 GB, 20 GB "korlát", egyszerűen nem készítették őket fel (upgrade-del általában megoldható, már ha a kínai lapodhoz volt megfelelő ROM image)

Gondolom a 2 TiB támogatást már kizárólag EFI-vel akarják megoldani (biztos sima BIOS-szal is lehetne), ezzel is kényszerítve a jónépet a 30. szülinapját ünneplő BIOS régóta esedékes kipusztítására. Az meg, hogy az EFI setupja GUI-s vagy nem, valójában nem érdekel. Ha megnézed a screenshotot, ez is ugyanolyan egyszerű menürendszer mint a karakteres BIOS setup, csak van mögötte egy háttér... ennyi.

> ez a fos grafikus bios majd detektálja a videókártyát? Esetleg drivert kell majd rá telepíteni?

Nem, ez még mindig csak linuxon kötelező.

Amúgy meg ha nem 15 éves lennél akkor tudnád mi az az AMI WinBios

[ #FreedomFlotilla ]

"a megfelelő modemparancs elküldésével lehetett bontani a win userek modemjét:) akkoriban is megvolt a linux előnye." - hupexpertize©

1. a BIOS kibaszott lassú, modern gépeken a boot idő jó harmadát teszi ki amíg tököl. Teljesen fölöslegesen: a funkcióit már semmi nem használja, DOS-t meg nem teszel C2Q-s gépre. A bootot meg sokkal hatékonyabban is meg lehet oldani.

2. A "C-ben írják" szerinted azt jelenti, hogy *.c meg *.h fileokat másolnak a ROM-ra és valami interpreteren fut? Szerintem lefordítják gépi kódra (aminek ~ugyanaz lesz az eredménye mintha ASM-ben írnád, bár igaz hogy egy tapasztalt programozó jobban optimalizál mint a fordítóprogram)

Erről az egész rinyáról amit itt lenyomtok a commentekben, az jut eszembe, amikor meglátták az emberek az első léghajót, és a "hülyeség...sátáni" skálán váltakoztak a vélemények.
Meg különbenis, az embereknek nincs szükségük a levegőbe emelkedni, jó a lovasszekér is, hát nem?

Ugye nem hiszed, hogy valakinek 11mp-be telik, amíg visszatér a suspendből? Ilyen lassú feléledéssel én még nem találkoztam.
Itt van egy 15sec-es Win7 boot, XP-vel ez méggyorsabb, bár itt a RAID utility timeout sajnos megdobja az egész boot időt.

---
BME-VIK '09
Compaq Mini 311 - N270 @ 2323 MHz - 3GB DDR3 @ 1240 MHz - ION

Felőlem boot-olhat akár 2 percet is, de amikor dolgozom már, akkor ne töltögessen semmit, mert agyf@szt tudok attól kapni, hogy dolgoznék, de még tölti a szükséges akármit a rendszer. Kíváncsi lennék, hogy mi van ezeknél a kész "boot"-oknál még betöltés alatt...
--
http://www.naszta.hu

Ez ok és tudom is. Csak arra akartam rávilágítani, hogy a napi (heti, havi stb.) egyszer lezajló indításkor a sebesség szinte az utolsó a prioritási sorrendben (nálam).

Az ilyen 11 másodperces desktop-ok meg komolyan kiritkított startup-pal érhetők el általában, sok utólagos töltögetéssel.
--
http://www.naszta.hu

Ezek nem :) Egész egyszerűen RAID-be kötött minőségi SSD-k, amik így hihetetlenül nagy átviteli sebességet nyújtanak.
Az utólagos töltögetések is általában a HDD sebessége miatt tartanak sokáig.

---
BME-VIK '09
Compaq Mini 311 - N270 @ 2323 MHz - 3GB DDR3 @ 1240 MHz - ION

Pld. Albatron alaplap ha valamely IDE csatorna automtata felismerésre van beállítva, és nem lóg a kábelen semmi, akkor vagy 10 másodpercig detektálja a semmit, míg ha ott az eszköz, akkor fél másodperc alatt kész az IDE detect. A BIOS-ban van olyan "feature" is, hogyha változott valami az IDE konfigban, akkor szól, hogy halihó, nem ugyanaz a BOOT order, mint korábban, és légyszi csekkold le vagy nyomj F1-t... és addig nem is megy tovább.

(Ezért szoktam általában manuális HDD beállításokat használni, és a nem használt csatornákat meg kikapcsolni)

1. Igy van, ez lenne az elonye. Mar a W95 ota minden oprendszer atlepi a BIOS rutunjait, szinte annyi a dolga, hogy betoltse az oprendszert (najo, meg az elsodleges ellenorzesek az eszkozokon)
2. C-hez van interpreter?

Egyebkent legjobb tudomasom szerint a Linux kernelbol is max 1000-2000 sor az assembly, a tobbi C. (jo, megszamolhatnam, ha ez lenne a perverziom, de nem ez)

Továbbra sem látom, mi a probléma, ha azt ígérik, *gyorsabb* lesz a bootolás mint BIOS-szal. Felőlem akár perlben is megírhatják, ha működni fog.

A driverek meg nem a Linux-féle "ma megy holnap nem" vagy a Windows-szerű "kérem a 2. CD-t" módon lesznek megoldva... egy VESA módhoz is driver kell, érted.

Örülnék ha végre a firmware képes lenne normálisan kezelni a bootot (pl. nem kéne várni amíg a grub fél percig pörgeti a bennfelejtett CD-t), esetleg a memória/VGA mennyiségén és meglétén kívül más diagnosztikára is képes lenne; és nem csak kerülgetnénk körbekörbe a 30 éves BIOS elavult hülyeségeit.

"1. Igy van, ez lenne az elonye. Mar a W95 ota minden oprendszer atlepi a BIOS rutunjait, szinte annyi a dolga, hogy betoltse az oprendszert (najo, meg az elsodleges ellenorzesek az eszkozokon)"

nah pont ez a problema, hogy meg kell kerulni, mert mar nem hozza azt a funkciot, amire valo lenne...

--
NetBSD - Simplicity is prerequisite for reliability

Ezt nem értem.

Fő feladatát elvégzi, átadja a vezérlést az OS-nek (ill. a betöltőjének).

Más feladatokra meg nem azért nem használják, mert elavult vagy sem, egyszerűen lassabbak a BIOS hívások.
Sok esetben DOS alól is éppen ezért kerülték meg. pl. "közvetlen lemezhozzáférés", ha mond valamit...

Csak kis "kötekedés":

" Szerintem lefordítják gépi kódra (aminek ~ugyanaz lesz az eredménye mintha ASM-ben írnád, bár igaz hogy egy tapasztalt programozó jobban optimalizál mint a fordítóprogram)"

Igen-igen-igen-igen-igen vért kell izzadnia egy akármennyire tapasztalt programozónak, hogy jobb asm-et állítson elő, mint egy normális C fordító.
(Jelenleg "jobb programozó" csak az SSE és hasonló műveletek esetében tud labdába rúgni.)
Csak kivételes assembly programozók képesek erre, de kétségeim vannak, hogy megéri-e elpöcsöéni napokat-heteket egy-egy rutinnal 0.00001% sebességnövekedésért.

Baromság. Halál ugyanaz mint a régi bios, csak lehet klikkelni. "Óriási ötlet". Nem kell hozzá megismerni a le föl nyialk esc... gombok használatát. Azon felül egy rakat erőforrást pocsékol el.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Az ilyen elmés beszólásokat egyébként azok a binuxosok eresztik meg, akik más topicokban azért bevallják, hogy "Majd Ubuntut, de az cserélve lesz mert még így kiherélve (openbox, nano, midori, mc, stb) is sokat eszik (imho)... Ha lesz egy kis időm, jöhet az Arch."

[ #FreedomFlotilla ]

"a megfelelő modemparancs elküldésével lehetett bontani a win userek modemjét:) akkoriban is megvolt a linux előnye." - hupexpertize©

Passz, én már ott elvesztem az ilyen kórképeknél a fonalat, hogy valaki még 2010-ben is linux-szal szopatja magát :)

(nna, kiszerkesztetted amire válaszoltam) :(

[ #FreedomFlotilla ]

"a megfelelő modemparancs elküldésével lehetett bontani a win userek modemjét:) akkoriban is megvolt a linux előnye." - hupexpertize©

Passz, én már ott elvesztem az ilyen kórképeknél a fonalat, hogy valaki még 2010-ben is linux-szal szopatja magát :)

Ez a "szopatás" nem minden esetben igaz. Vannak olyan buildek, ahol lehetnek problémák a Linux üzembehelyezése során (nálam spec. out-of-box megy az Ubuntun minden), de 1000% (igen, ezer százalék), hogy vindóznál is van olyan környezet, ami megizzasztja az embert.

eszes
----------------
Ubuntu 10.04 LTS - Acer AS3100

Csomót tanul arról, mennyire jó olyan emberek munkájától függeni, akik sz.rnak bele az egészbe.
(én azt, hogy rájövök hogy xy driver teljesen működésképtelen és biztos nem fogják javítani x hónapig, illetve adott program idegesítő hibáját csak a még több hibát tartalmazó aktuális fejlesztői snapshotban javították és a következő stabil hónapok múlva lesz ha lesz, keserű tapasztalatnak nevezném, nem tanulásnak)

Ha megengedsz egy baráti jó tanácsot - én is hasonló cipőben jártam és k*rvára utáltam - próbáld ki a Gentoo-t. Tudom hogy nem túl vonzó hogy kb egy hétig fordísd a rendszered magadnak, de ha kész lesz...

Valóban olyan rendszered lesz amilyet szertnél. Nem kell pl. a legújabb kernelt, legújabb libeket használnod, de mégis lehet up-to-date redszered. Nekem 2.6.12-es kernelem volt a 2.6.22-es kernelig mert a 2.6.13-ba bejött egy regression. És mindeközben lehetett legújabb kde-m mert azt használtam.

Én magam is egy megkurtitott buntut használok. De ennek egy oka van. Néha kell az összes RAM ami elérhető. Inkscape EPS export pl nálam gyakran becuppant 1.7GB -t a kettőből. És a mostani gépemben nem nagyon látok teret memóriabővítésre. Majd a következőben.
persze kiengedhetem SWAP-ra. de akkor meg brutálisan belassul.
Van hogy még X-et sem indítok amíg konvertálok.

De ide lehet rángatni a hibernáláshoz szükséges időt.

Meg amúgyis... kinek milyen gépe van.

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#1000H/UbuFb

Jó, most erre mindjárt jön 10 "hazucc a bubuntunak kevés RAM kell, biztos vindózt használsz annak sokkal több" meg 3 "worksforme, pebkac" (tudod, biztos te vagy a hülye mert a program sok memóriát eszik)

Amúgy igazad van. Hardy, 1 GB RAM, és egy rohadt Java programot nem tudok swappelés nélkül elindítani. És nem azért, mert a Java enne sokat.... ha nem is kezdjük máshoz hasonlítani, elég szánalmas teljesítmény úgy objektíven.

És nem, a Xerox Alto GUI-t (1981) idéző csoda ablakkezelő (vagy az X lelövése) nem megoldás, csak workaround egy egyátalán nem kezelt problémára a sok közül.

Mivel ezek az alaplapok nagyrészt 2,4 2^n magos processzorokkoal, és legalább 4 giga rammal fognak rendelkezni, ezért ha bekapcsoláskor (amikor amúgy sincs multitasking lehetőség, tehát csak elegendő az is, ha a gép teljes terheltség mellett épp elviszi az UEFI-t) mondjuk kihasznál 64 mega ramot, és 2-3% CPU-t, majd az oprendszer úgyis betöltődik, és az UEFI meg már nem fut a háttérben, akkor szerintem ez teljesen mindegy, hogy a Boot alatt mennyit pocsékolt el.

Nagy Péter
www.konquer.org

A régi p1-es gépemben is volt már grafikus bios, ablakokkal, meg egérrel (ha jól emlékszem valamilyen compaq deskpro volt). Akkoriban be bukták az ötletet, ugyanis iszonyatosan lassú volt, ráadásul merevlemezre volt installálva a grafikus bios, amelyet szépen el is vesztettem mikor lehalt a vinyó, ezek után már nem lehetett semmit se átállítani.

Bocs, kicsit rosszul fogalmaztam. Lényegében csak a gui volt a merevlemezen, amelyet le lehetett floppy-ra menteni (és gondolom fel lehetett volna másik merevlemezre installálni), viszont a hibás merevlemezemnek köszönhetően a második floppy írása közben errort dobott, fájl nem olvasható, és kifagyott az egész.
Viszont megnéztem a pontos típusát, Compaq Deskpro 590, talán google talál valamit róla :)

Háát a sebesség relatív. Pár ilyen gépet raktam össze (egy sulinak anno kellett vagy 20, és mind ilyen grafikus BIOS-sal volt megáldva), és tudott forogni szépen a homokóra a menüpont váltások között, meg szemmel követhető volt időnként a képalkotás.... A mai processzor sebességeknél biztos jobb a helyzet, de akkoriban nem csodálkozom, hogy nem lett népszerű... Azóta is mély levegőt vettem, ha hasonló BIOS-sal találkoztam :D

Igen, ez az AMI WinBIOS, vagy mi a neve, ez volt az ami teljesen ROM-ból futott. Hasonló grafikus megoldást láttam még Acer P2-es alaplapnál is, bár a kinézete más volt. A Compaq cucccánál meg a ROM-ból kihagyták az egész BIOS beállító menürendszert és HDD-ről töltődött be, ami egy roppant "elmés" ötlet volt, nyilván 3,5¢-et sikerült megspórolni a gép előállítási költségéből a kissebb ROM-mal.

Nem mellesleg egyébként IBM pSeries gépeknél is grafikus a system firmware (többé-kevésbé a BIOS ottani megfelelője) boot beállító menüje - már ha van grafikus vezérlő a gépben
---
Internet Memetikai Tanszék

Nem akarom védeni a zindex-et, de olyat, hogy "a BIOS-nak az a legnagyobb baja, hogy szoveges, nem egeres", nem írtak. Olyat viszont igen, hogy probléma a 2 terabyte-nál nagyobb lemezről a boot-olás a régi BIOS-szal. Miért nem ezt emeled ki a cikkből, hogy erre is megoldás az EFI (UEFI).

Nos, ahogy en ertelmezem:
KET dolgot emlitenek a BIOS lecserelese kapcsan:

"Amíg az elavult BIOS csak szöveges információkat jelenít meg, és billentyűzettel kezelhető, addig az UEFI interfésze már szépen megrajzolt, és egérrel is működik. Az UEFI ennél is lényegesebb tulajdonsága,"

Szoktam konyvet es ujsagot is olvasni, szoval azt hiszem, a szovegertelmezesem turheto, es ebbol nekem az latszik, hoyg KET dolgot tart erdemesnek megemliteni. Nyilvan a masodik a lenyegesebb (kozepfok, melleknev), de ehhez hozzatartozik, hogy az elso is lenyeges, kulonben nem emlitene. (alapfok nelkul nincs kozepfok)

Jaigen: a problema lehet, hopyg fennall, nem tudom, 2T -nel nagyobb lemezt felismer-e, de nem hiszem, hoyg most mindneki kidobja a 2T-nel kisebb lemezeket, hogy csak a 2T-nel nagyobbak maradjanak. Jelenleg (asszem) 80G-2T kozott eleg szeles valasztek van wincsikbol (IDE is max 1/2 T), tehat _ezekrol_ tovabbra is lehet bootolni.

Uhum. Ket tulajdonsagot emeltek ki, igaz, a grafikus csak a masodik helyen volt, a 2T elso. De ez mellett vszinuleg lesz meg jopar egyeb tulajdonsaga is, ami sztem fontosabb.

Namost, ha ezt a kettot talaltak legfontosabbnak (oke, a 2T fontosabb, mint a grafikus, de megiscsak ez a ketto a legfontosabb), akkor mindjart javitom topicot.

Az senkinek sem tűnt fel, hogy a cikk szerint a C64-korszak tele volt BIOS-szal? :)

Lehet, de itt inkabb loptak. Proper 16 meg hasonlok.
Mondjuk, en eloszor XT-t lattam/hasznaltam, '91-ben. 512K RAM, 20M wincsi. Kicsit gyorsabb volt, mint a C64 :)

De nem hiszem, hogy nagyon sok ceg vett (nemcsak itt, mashol sem) IBM PC-t, eleg gyorsan rarepultek a klongyartok arra is es toredekaron dobtak piacra.

--
http://www.micros~1

Nekem még van egy ilyen alaplapom. Igaz, hogy a ROM-BASIC csak egy gyors próba erejéig volt a gépben, mert akkor kaptam, amikor éppen átépítettem az XT-met AT-ra. AT-ban, meg már nem volt hova dugni, (minek is raktam volna bele?).

Az XT alaplapon a legfelső foglalatba volt a ROM-BIOS, az alatta lévőkbe kellett bedugdosni a BASIC ROM-jait - ha jól emlékszem négy darabból állt.

Ha nem volt elindítható op. rendszer, akkor a basic értelmező indult el (azt hiszem, hogy valamelyik szoftver-megszakítás meghívásával is indítható volt). A 640kB RAM-ból 64kB-ot tudott használni, valamint az PC/XT előtti "sima" PC-re csatlakoztatott kazettás magnót használta háttértárnak.

Ideje volt már. Még megfelelőbb lenne ha az operációs rendszerek várakozás nélkül betöltenének, a bootolás kezdetekor persze diagnosztikai lehetőségekkel.

A bitmap kevés lesz, valamiféle animációra szükség lesz, esetleg 3D gyorsításra.

Gondolom beviteli eszközök széles skáláját fogják tudni támogatni az érintőképernyőtől a mozgás- és hangérzékelőig.

Nekem olyan dolgok hiányoznak a BIOS-ból ami megkönnyíthetné a hardver tesztelést. pl. memória, cpu, hdd teszt. A HP laptopokhoz (Pavilion-ban láttam ilyesmit) hasonló tökéletes lenne. De igazából nem létkérdés szvsz.

Leírom ide is, amit a másik topicban, hátha érdekel valakit:

Feltettem ide egy videot egy 486-os gép grafikus BIOS-áról.
Kicsit ügyetlen voltam, de mentségemre bal kézzel pöcköltem a trackpoint-ot (vagy mit). :)

A video az imént készült, ha jól rémlik, 100 Mhz-es proci van benne.

A fake_path nem tudom, miért van benne, nem értek a youtube-hoz /nem érdekelt annyira/... :D

Nálam előfordult anno, hogy megakadályozta emiatt a lilo (lol) installálását, így nem ment a linux. Végülis megmenekültem a vírustól :)

[ #FreedomFlotilla ]

"a megfelelő modemparancs elküldésével lehetett bontani a win userek modemjét:) akkoriban is megvolt a linux előnye." - hupexpertize©

És tényleg, nekem is, bár nem laptopban. Ha nem látom nekem se jut eszembe :D Bár jó rég volt az tény, talán 486-os volt az is, és ha jól emlékszem win98 futott rajta. Nagy szám volt (számomra), hogy akadás nélkül tudott mp3-at játszani... :)

---
BME-VIK '09
Compaq Mini 311 - N270 @ 2323 MHz - 3GB DDR3 @ 1240 MHz - ION

Ez az egész egy teljesen felesleges valami, ráadásul SOKKAL lassabb, mint a jelenlegi BIOS. Ez ügyben érdemes megfontolni Linus szavait szerintem:

Btw, that's not totally new. I think some people played around with EFI on
x86 even before Apple came around. And don't get me wrong - the problem
with EFI is that it actually superficially looks much better than the
BIOS, but in practice it ends up being one of those things where it has
few real advantages, and often just a lot of extra complexity because of
the "new and improved" interfaces that were largely defined by a
committee.

I think a lot of the "new standards" tend to be that way. Trying to solve
a lot of problems and allow everybody to add their own features, instead
of just saying that it's better to just standardize the hardware.

For example, instead of ACPI, we could just have had standardized hardware
(and a few tables to define things like numbers of CPU's etc). It would
have been simpler for everybody. But no, people seem to think that it's
somehow "better" to have wild and crazy hardware, and then have a really
complicated way of describing it - and driving it - dynamically.

So EFI has this cool shell, a loadable driver framework, and other nice
features. Where "nice" obviously means "much more complex than the simple
things they designed in the late seventies back when people were stupid
and just wanted things to work".

Of course, it's somewhat questionable whether people have actually gotten
smarter or stupider in the last 30 years. It's not enough time for
evolution to have increased our brain capacity, but it certainly _is_
enough time for most people to no longer understand how hardware works any
more.

Not a good combination, in other words.

Not that I'd ever claim that the BIOS is wonderful either, but at least
everybody knows that the BIOS is just a bootloader, and doesn't try to
make it anything else.

The absolutely biggest advantage of a BIOS is that it's _so_ inconvenient
and obviously oldfashioned, that you have to be crazy to want to do
anything serious in it. Real mode, 16-bit code is actually an _advantage_
in that sense. People know how to treat it, and don't get any ideas about
it being some grandiose framework for anything else than "just load the OS
and get the hell out of there".

Linus

(http://kerneltrap.org/node/6884)

Röviden összefoglalva: minek bonyolult csilivili firmware, mikor úgyis csak az a dolga, hogy betöltse az OS-t, aztán eltakarodjon a pokolba?

Alapvetően nem vagyok biztos abban, hogy Linus "security people are leaches" Torvalds véleménye bármit is számít akármilyen kérdésben

[ #FreedomFlotilla ]

"a megfelelő modemparancs elküldésével lehetett bontani a win userek modemjét:) akkoriban is megvolt a linux előnye." - hupexpertize©

Akkor csak gondolj bele abba, mire használod most a firmware-t (mármint a BIOS-t), és rájössz, hogy egy teljesen felesleges valami, ami csakis a gép bekapcsolása utánni pár másodpercben bír jelentőséggel.
Szerinted megéri ezt lecserélni egy speckó programokkal teli FAT32-es rendszerpartícióra?
És ha már security: a BIOS a ROM-ban van, nem lehet átírni (szoftveresen legalábbis), míg az EFI-t úgy telepakolhatod trójaival, ahogy nem szégyelled.

Ez tényleg hasznos funkció lenne, de szerintem nem nagy ár a mostani tedd-be-a-cd-t megoldás. Régen is így mentek a BIOS setupok, külön floppy-n volt a beállító program.
(Szóval az érv jó, de szerintem nem indokolja az EFI komplexitását, meg lehetne ezt tenni kis ROM proggival is, az lenne az igazán tuti.)

Hová lett a "frappáns" idézet az aláírásodból? :)
Azt hiszed beszólhatsz úgy, hogy nincs ott egy "diplomás", "openssl", "modem linux", "manieyebalz", "linus avilagleghulyebbembere torvalds" alátámasztásnak az aláírásodban?! Mégis, hogy képzeled? :)
---
Internet Memetikai Tanszék

> Hová lett a "frappáns" idézet az aláírásodból? :)

A legtöbb HUPeducated ubuntussal ellentétben én tartom a content vs signature arány törvényét, egyébként nem csodálom hogy még arcoskodva-vicceskedve-fikázgatva tanúbizonyságot is teszel ismereteid tragikus hiányáról

egyébként nem csodálom hogy még arcoskodva-vicceskedve-fikázgatva tanúbizonyságot is teszel ismereteid tragikus hiányáról
Konkrétan? (amúgy komolyan Te képes vagy bárkin számonkérni, hogy "arcoskodva-vicceskedve-fikázgatva" ?!)

Én úgy emlékszem a múltkor a snapshot témánál is te égtél be, amikor a ZFS-nél beszéltél hülyeségeket össze-vissza. Ja ugye az ilyenek gyorsan elfelejtődnek.
---
Internet Memetikai Tanszék

Hát igen, ugyanis én a Blob szót "Block of Bytes" jelentésében használtam. Te pedig elkezdtél mögélátni mindenféle (talán OpenBSD-s eredetű?) "blob gonosz" fixációt, mert mindenkiről feltételezed, hogy winmodemkiller, bubuntu tini.

Viszont én most fölteszem neked a $100-os kérdést: mi az, ami szerinted *jó*? Mondjuk az ontopicság kedvéért a BIOS és UEFI témakörben.
---
Internet Memetikai Tanszék

Hát a blob azért jelent még egyet s mást. Adatbázisoknál is szokták így hívni a bináris objektumokat, szóval ez sokkal általánosabb jelentés, amit te idézel az pedig egy elég specifikus részterületen mindenféle konotációkkal megtűzdelt változata ennek.

Én is szeretem a Doctor Who-t, viszont egyben sajnálom is, hogy megint menekülőre fogod, ha azt kéne leírni, hogy szerinted itt mi a jó. Én tudom, hogy mindegyiknek megvannak a maga hátrányai, de ezért nem támadok le mindenkit, legfeljebb előveszem az én érveimet is. Igazából nem sok kihívás van abban, hogy mindenkit lefikázol, mert mindenütt találni valami könnyű konkrét példát, amire jól hivatkozhatsz. Így könnyű. Viszont, ha valami _mellett_ kéne állást foglalni, nos akkor már jobban ott kell lenni a szeren, mert tudhatod, hogy az sem tökéletes. Mutasd meg, hogy tudod ezt is és akkor meglátjuk, hogy mennyit érsz!
---
Internet Memetikai Tanszék

...viszont akkor igazán kijavíthatná valaki azt a teljesen félrevezető és erősen kérdőjelezhető pártatlanságú ill. hangnemű wikilapot... minden második szavára [citation needed] kéne (és pár szemellenzős FOSShívő magánblogján kívül nem lenne forrás semmire)

És nem, az OpenBSD song nem forrás LOL.

A HUPwiki többi lapja nem szokott ilyen nulla minőségű lenni.

> hogy szerinted itt mi a jó

Tudom, hogy ez egy fikazos szal, es senki se kerdezte az en velemenyemet, de azert megiscsak leirom.;-)

Szerintem a Qi lenne az idealis megoldas.

A legszuksegesebb minimumot csinalja.

Foleg amikor tizedmasodperc alatt fel kell ebrednie a rendszernek...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nekem csak kérdéseim lennének:

Aki ezt az egészet kitalálta, annak az édes anyukája jelenleg hogy érzi magát?
Ez a szoftver az alaplaphoz tartozik. Mit keres bármilyen része is a winchesteren? Ezen túl, ha új lemezt akarok rakni a gépembe, majd előbb EFI-t telepítek? Miért nem lehet neki biztosítani egy dedikált flash memóriát az alaplapon?

Minek a grafika? A szakemberek nem hinném, hogy félnek a karakteres felülettől, az átlag user meg húzzon a BIOS közeléből is. Eddigi tapasztalataim szerint abból csak a baj van (elrontott BIOS flash, bootolhatatlan laptop, etc...). Egy autót sem úgy gyártanak le, hogy a motorházban minden kis szalagokkal meg képecskékkel van feldíszítve, hogy ha a szőke cica felnyitja a géptetőt, vidámabb napja legyen. Neki ott semmi keresnivalója!

Scriptelhetőség, shell, driverek? Ez egy oprendszer. Minek? Abból nem pont elég egyet betölteni?

Persze, értem én, hogy a BIOS elavult. De miután semmi más dolga, mint betölteni az operációs rendszert, ami utána úgyis magasról tesz a BIOS-ra (12 éves gépemben is vidáman működik a 2TB-os merevlemez, például...), miért piszkáljk már megint azt, ami működik? Számomra ez teljesen érthetetlen.

Húbazz egyre nyomósabb érveket hoztok fel
- GUI ezért biztos lassú (ROFL)
- Drivereket tartalmaz ezért rossz (2*ROFL)
- Jó a BIOS ahogy van (ROFL^2)
- Biztos drága lesz (ROFL^3)
- Regisztrálni kell a doksiért (ROFL^4)

Szerintem minden alaplapgyártó azonnal sírva menekül vissza a BIOS-hoz, ha ezeket a rendkívül komoly érveket meglátja :)

Ne idegeskedj, vess egy pillantást pl erre:

> miután semmi más dolga, mint betölteni az operációs rendszert

Ezeknek a tini huppereknek van 1 db IBM kompatibilis személyi számítógépük, penciummal, buzuntuval. Elindul a gnóm, és rajzanak ide a hupra a bugrókával. Halvány lepkefingnyi tapasztalatuk sincs SRM, OF, remote konzol és hasonló "obskurus" dolgokról. Mindenesetre poén ahogy vergődnek.

[ #FreedomFlotilla ]

"a megfelelő modemparancs elküldésével lehetett bontani a win userek modemjét:) akkoriban is megvolt a linux előnye." - hupexpertize©

Tévedés. Nagyon is jól ismerem. Légyszíves meséld el nekem, hogy pl egy sparc boot promptban hol van:
1. grafikus felület
2. mikor kell drivereket betöltögetned (pl hwdiaghoz)
3. mennyi van belőle a rendszerwinyón tárolva
4. hányféle alternatív, teljesen más paraméterezésű boot parancsod van?
Na ugye.

Vagy, ha nem ismered a sparc-ot, akkor mesélhetsz még nekem VAX hwpromptról, van mainframeről is. Ezek azok a firmware-k, amiket jónak tartok (szubjektív véleményem).

Az EFI nem a HDD-n van.

A karakteres felület még rendben van, de mi van ha nincs billentyűzet.

A szolgáltatásokról, mint a diagnosztikai lehetőségek nem is szólva.

Ez nem egy másik operációs rendszer, inkább a jelenlegiektől vesz át feladatokat (boot loader stb.), így azok egységesítve lesznek.

Ha nincs billentyűzet, az tényleg egy olyan helyzet, ahol jó lehet, erre nem is gondoltam. Erre vannak ugyan a spec. kábelek, de ahhoz már kell egy másik gép is, szóval nem igazán alternatíva.

Nekem van egy DELL Inspiron gépem, amin van egy komplett diagnosztikai rendszer, memóriát és különböző hardvereket tud ellenőrizni, és egy darabkája sincs a merevlemezen, mert azt azóta már kétszer is cseréltem, mégis működik.

Alapvetően nincs azzal baj, hogy okosítani akarják a dolgokat, de nekem a merevlemezre ne kerüljön _semmi_, ami kell ahhoz, hogy a gép működjön.

(Ezeket az infókat egyébként az efi speci. gyors átfutásából vettem, szóval bocsánat, ha pontatlanok. Ott láttam az efi partícióról szóló dolgokat is, de azt nem néztem meg, hogy nélkülük azért csökentett funkcionalitással bootolható-e a gép.)

Az EFI partíció a bővítményeknek van, illetve ha olyan rendszert bootolsz aminek a partícióját nem tudja az EFI olvasni akkor onnan is mehet a rendszer indítás. (Bootsector itt már nincs.) A Mac-ekben csak az EFI frissítések telepítésénél van szerepe - persze a user nem tud róla, mert az összes többi bővítmény az alaplapon van tárolva, beleértve a HFS+ partíciók támogatását is, így onnan tudja betölteni a rendszert.
Szóval: ez csak egy lehetőség.

Tévedés. EFI partíció nélkül semmise nincs. Az MBR megfelelőjét is onnan tölti be (\EFI\BOOT\boot(arch).efi nevű file egész konkrétan, vagy egy másik file, pl \EFI\Microsoft\WINNT50\IA64LDR.EFI. Szóval keresheted majd, hogy akkor melyik program is indul tulajdonképpen. Ehhez már mindenképp FAT32 olvasás és értelmezés kell, ami jóval lassabb, mint berántani a legelső sectort). És innen tölti be a hwdiag programokat is mellesleg.

Mac alatt egyébként nem használt, ha megnézed tök üres, mégis felzabál 128 Mbyteot minden diszkemből. Ott ezt úgy oldották meg, hogy nem szabványos a bootolási folyamat, és a hardware egyből az Apple Boot Loader-t keresi, mielőtt az EFI Boot agymenésnek nekiállna. Ez az a file, ami kezeli a HFS+-t és betölti a kernelt.

Ez is félre van magyarázva. Nem arról van szó, hogy nem kezel 2T-nél nagyobb diszkeket, hanem hogy /boot partíciónak kell a winyó első 2T-jében lennie. Volt már ilyen, mikor átlépték a 1024 cylindert, mégsem volt para, mindenki tudta, hogy az operndszer indítóját a 0-1023 cylinderre kell rakni, aztán kalap kabát. Az oprendszer drivere meg vígan lekezelte az összes 1023+ cylindert. Na most ugyanez van, csak 2T limittel. Most őszintén, kit érdekel, hogy az rendszerpartíciót a winyó elejére kell rakni, és az adatpartíciót utánna? Úgyis mindig (na jó 99%) így szokás.

Szerk: utánnanéztem, az egész bullshit, a BIOS 64 bites LBA címeket kezel. Nem tudom, honnan vették ezt a 2T-s limitet, de ez max egy implementációs korlát lehet, semmiképp sem specifikációs.
http://www.ctyme.com/intr/rb-0708.htm

Ezt csak egy példának írtam, hogy marhára mindegy, mit tud a BIOS, egy modern operációs rendszer úgyis maga kezel mindent.

A gép egy NAS, adattárolásra van használva, és benne 2db merevlemez - messze a BIOS által támogatott 30GB méret felett - egy olyan PCI-os SATA vezérlőn lóg, amit a BIOS konkrétan nem is tud, hogy ott van. Illetve igen, de ha nem tiltom le, adatátvitel alatt random fagyásokat produkál. Még ebben az ősöreg gépben is tud ~45 MB/sec olvasási sebességet.

Van egy harmadik lemez is, PATA-ra kötve. Az csak 250GB. Erről vígan bootol a gép. Összesen annyit kellett tennem, hogy a megfelelő helyekre kézzel beírtam úgy a lemezre jellemző adatokat, mintha a kapacitás ~20GB körül lenne, az automatikus felismerésbe ugyanis érthető okokból belefagy. A lemez elejéről betöltődik egy kernel, ő meg már látja az egészet.

Az lspci azt mondja:
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01), illetve:
00:12.0 RAID bus controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01)

Szóval én továbbra is értem, mi az efi célja, csak azt nem, hogy miért van erre szükség.

Nem én vagyok az, aki nem fogja fel. Én csak egy példát hoztam arra, hogy lehet bármilyen hülye is a BIOS, semmiféle hátrányom nem származik belőle.
Az említett gép saját idejében a merevlemezek többsége ~4GB volt. 30GB-ig hivatalosan is tudja kezelni őket, 120GB-os lemezzel még próbáltam, abba még nem fagy bele, de csak az első 30 Gb-ot látja a BIOS. Hangsúlyozom, a BIOS. Mert a felette lévő operációs rendszer az egészet. Összesen annyit kell "trükköznöm", hogy a rendszerpartíciót az első 30GB-ra rakom. Mivel ezt amúgy is így csinálnám, nem érzem, hogy hátrány érne, amiért a BIOS nem tud megbirkózni ekkora lemezzel.
Jó, előfordulhat, hogy valaki több rendszert rak a gépére, de nehezen tudom elképzelni, hogy értelmes keretek közt ne férjen bele az összes rendszerpartíció a 2TB-os határba. (Bár, majd jön a Windows 9 ;))

Én inkább azt nem értem, hogy a bios vagy efi, esetleg fifi, tréfi, stb. miért nem korlátozódik arra manapság, hogy hw tesztet csinál és ha minden ok, akkor az egyetlen állítható paramétere szerinti tömegtárolóról - mindegy mi az - a legelső szektort beolvassa, bedobja a memóriába és ráadja a vezérlést. Ezzel kb egy életre el lenne intézve minden.

A BIOS nem csak a boot-ról szól. Tele van egy rakás hardvare és software interrupt kezelő programmal, ami ahhoz kell, hogy egy kevésbé fejlett oprendszer (pl. DOS) is tudja kezelni az alap hardvereket, pl. merevlemez, billentyűzet, kijelző (elsősorban videokártyákon szokott saját bios is lenni, hogy ne az alaplapi bios-nak kelljen minden videokártyához saját megszakításkezelést tartalmaznia).
A fejlettebb oprendszerek (linux, windows, bsd, ecs, stb) ezt saját maguk intézik, egyrészt a bios szoftver megszakításainak átirányításával, másrészt a hardver megszakítások saját driverrel történő lekezelésével.

Ilyen értelemben igazad van, de szerintem ezeket a megszakításokat nem használja manapság a kutya se, nyugodtan ki lehet(ne) dobni. Ha meg DOS-t akarna valaki mégis futtatni egy ilyen BIOS-ú gépen, akkor config.sys-ben be kell tölteni a BIOSEMU.SYS-t, bár nem hiszem, hogy lenne rá igény.

A felszabaduló helyre meg lehetne értelmesebb kódot rakni, pl részletes hwdiag vagy GPT értelmező.

Tudom.
Éppen ezért írtam, hogy az egészet újra kellene gondolni, mert most a kompatibilitás miatt van egy rakás szarakodás. Senki nem meri bevállalni, hogy a felhasználókkal kidobassa a jelenlegi szoftvereiket. Pedig akár a MS, akár bármely más cég megtehetné, hogy az elavult szoftvereket használóknak jelentős kedvezménnyel adja az újat, ha a régi telepítőlemezeit leadják. (MS-nek volt ilyen akciója Win95-tel, amikor Win3.1 és DOS6.22 lemezekért cserébe féláron lehetett megvenni a dobozos 95-öt.) Sajnos ez hardverrel nehezebben játszható el a magasabb költségek miatt.

Az a baj, hogy az eszközök tervezésekor sosem gondolkoznak kellően előre. A harminc éves szabályokat használó hardvertervezők és programozók még mindig abban bíznak, mint harminc évvel korábbi elődeik, hogy hamarosan jön majd valami jobb, ami leváltja a mára végképp elavult dolgokat. (Példák: 1) Az alaplapi buszok csak adatszélességben és sebességben tudnak többet, de a koncepció ugyanaz, mint az ISA esetén. 2) Az SSD-t hülyeség ugyanúgy kezelni, mint a merevlemezt, de a kompatibilitás miatt mégis azt csinálják.) De lépni senki nem mer, mert évekig nincs belőle haszon. Az nem érdekes, hogy utána az alacsonyabb fejlesztési költségekkel vissza lehetne hozni a kiesést, mert manapság csak a rövidtávú haszon számít, ha nem tudsz ilyet felmutatni, leírnak a tőzsdén és tönkreteszik a cégedet.

A vége nagyon offtopic lett, elnézést.

Egyetértek. Egy dolog csak, vannak azért próbálkozások, pl itt is írta már valaki a corebootot, de sajnos azok is ágyúval verébre. Pont az lenne a lényeg (ahogy a neve is mondja, Basic Input/Output System), hogy faék egyszerűségű legyen, ne pedig egy komplett oprendszer a ROMban.

Mondjuk ami tényleg működőképes lehetne, az egy in-rom-Grub, beépített memtest és hwtest opciókkal. Na, az király süti lenne tényleg, és még csak kompatibilitási problémákat se vetne fel, hisz minden mainstream (és baromi sok nem mainstream) OS-el kompatíbilis, valamint szabványos az OS interfésze (úgy ahogy... :-) ld MultiBoot)

Szamomra egyedul az nem vilagos, hogy manapsag, mikor mar az egerben is "dual bios" van, miert nem lehet egy bios, illetve egy "kapcsolaztmegy" ic kulon beepitve. Atan a user arra indit (felolem akar dip kapcsoloval is) amelyiket szeretne...

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

Ertem. De nem lassu, illetve fogyaszt sokat?
Igazabol itt a "szamitastechnikai hulladek" tovabb hasznalata, aminek a letjogosultsagat nem ertem. -_-! Mi a igazi oka hogy nem egy modernebb deszka van alattuk?

--
"Biztos én vagyok a béna, de csak azt sikerül elérnem, hogy kikapcsol a monitor."

Például hogy valamikor régen, amikor még az atomos lapocskák aranyárban voltak, ez volt kéznél, és mivel csak 100Mb/sec-et kellett kihajtania, pont megfelelt. Azóta ugyan gigabitre váltottam, de nem volt még időm átköltöztetni, ami rajta van. (Hogy ne tűnjek lustának: FTP, TFTP, DHCPD, AoE, iSCSI, Apache, mysql, nfs, samba, cups, azureus, OpenVPN, nbd az optikai meghajtó távoli elérésére, saját "démonnal", ami automatikusan ki-be kapcsolgatja a megosztást szükség szerint, hogy ne kelljen ssh-n bökdösni, meg egy nagyon ritkán nx-en át használt wine+strongdc, amivel kicsit megizzadtam, mikor elsőre összehoztam) Elszörnyedés előtt: hobbi és tanulási céllal összeállított gép, és nem érdekel, hogy mennyivel csökkenti a biztonságot, ha ennyi dolog van rajta.

A teljes rendszer fogyasztása a 3 lemezzel 45-50W közt van idle állapotban, terheléssel sem több 60-nál, és bár már gondolkodtam rajta, hogy lecserélem egy asrock a330gc-re, még addig sem jutottam el, hogy megvegyem.

uristen hup egyre sotetebb
a biosnak nem az a funkcioja, hogy pistike allitgasson benne ezt-azt, az csak a setup resze.
pl egy jol megirt firmware kepes lenne inicializalni a vga-t ugy, hogy utana framebufferkent hasznalhato egy minimalis driverrel, vagy firmware hivasokkal lehet kulonbozo hw-eket elerni es piszkalni, meg en pl orulnek, ha nem a raid kartyarol kellene futtatni valami 16 bites gepkodot, ha szeretnem hasznalni, hanem egy pendriverol feltelepithetnem a firmware-be a driverjet, ami igy teljesen integralodva grafikus management feluletet adna a raid-hez

ha itt valaki latott mar volna SRM-et, OF-et, vagy akar IPL-t, akkor nem irna ilyen hulyesegeket omg

--
NetBSD - Simplicity is prerequisite for reliability

pl egy jol megirt firmware kepes lenne inicializalni a vga-t ugy, hogy utana framebufferkent hasznalhato egy minimalis driverrel, vagy firmware hivasokkal lehet kulonbozo hw-eket elerni es piszkalni

De akkor működni is fog Linuxon, és nem szerzel "hatalmas tapasztalatot" szopásból...
Meg nem lesz opensource a driver, és RMS szomorú lesz, és megint elkezdi 12 éves Pistike szinten fikázni az MS-t... :(

egy jol megirt firmware kepes lenne inicializalni a vga-t ugy, hogy utana framebufferkent hasznalhato egy minimalis driverrel
Ja, mint az AtomBIOS az ATi grafkártyáknál. Nem volt ám szopás vele soha senkinek...

Az a gond, hogy amiket te felhozol példának, azok nem gagyi tömegcuccokban, hanem elég drága szerverekben fordulnak leginkább elő, ahol az ár jelentős részét a tesztelés és validációs költség teszi ki. Mert annak működnie kell, azért fizetnek ki érte az ügyfelek annyit, ha nem volna fontos nekik, akkor megvennék a sarki boltban az első szembejövő alaplapot. És nem sírnak amiatt, hogy a bejáratott gyártójuktól a legújabb fajta CPU-val szerelt szerver esetleg csak 6 hónap múlva fog piacra kerülni.

Ha ugyanezeket a technológiákat beszabadítják a dzsunkapc világba, akkor itt is meg fognak jelenni a nagyon gyorsan piacra dobott, de sajnos "kissé" broken implementációk. Én inkább pont ettől félek, az alap BIOS interfészeket még csak-csak tudják kódolni meg tesztelni a kis kínaiak, de egy ennyivel bonyolultabb rendszert milliószor többféle módon lehet elrontani és el is fogják...
---
Internet Memetikai Tanszék

Na, ez megint jól néz ki. Szépen megrajzolt felület? Kinek? A szakembernek, aki beállításokat végez rajta, vagy a hozzáértő felhasználónak, aki kétévente 8 másodpercet tölt el a felületén?
Egyébként legyen csak gyorsabb, ügyesebb, okosabb az alaprendszer, nincs ezzel gond, de ne legyen drágább, csak mert csili-vili felület kell már ide is.

Igen, kb 20 Ft/alaplap árral drágább lehet (nem tudom mennyi a licenszdíj, de valahogy nem hiszem hogy olyan drága, ha egy FAT32-t kezelő kínai MP3 lejátszó 4000 Ft -- amiből ~1500 az Artisjus matrica)

Persze a kezdeti EFI-s lapok jóval drágábbak lesznek, mert ugye a "new exciting technology" matricával mindenre rá lehet verni +40%-ot.
De miután általánossá válik, normalizálódik az ára.

szerk: egy fórumbejegyzés szerint 0.25$/db az ára, de csak ha hosszú fileneveket használsz (a még érvényes szabadalom csak arra szól), anélkül azt csinálsz amit akarsz.

Szóval nem 20 hanem 60 Ft, de akár 0 is lehet (nem hiszem hogy egy ilyen rendszer igényelné a LFN-t)

Üdv Mindenki!

Kihasználnám a topic által nyújtott lehetőséget és kérdeznéek egy viccest. Van egy HP Pavilion DV6960hu típúsu laptopom és révén, hogy elég paranoid vagyok mindent jelszóval védek - rendszer is LVM2-vel van védve -, ide tartozik a BIOS is. (Phoenix BIOS). A boot úgy van állítva, hogy a hdd az elsődleges és ha valamit telepíteni akarok akkor átálítom gyorsba a jelszó megadása után. Node van egy olyan lehetőség, hogy amikor csinálja a postot akkor nyomok egy F9-et és ad egy listát, hogy mit szeretnék bootolni. Ez azért számomra nem túl kielégítő :S
Valaki tud erre valamilyen megoldást? Le lehet tiltani/védeni ezt a funkciót valamilyen módon?

Szerk.:Version: F.58

Előre is köszi.
--
Favorite DesktopOS's: OpenSuse 11.2, Fedora13, Mandriva 2010.0, Ubuntu 9.04
Favorite ServerOS's: Debian 3.1, CentOS 5.4

Zsír, elmondod, hogy hogy kell, mert van egy info menü, egy engedélyezed a cd bootot / nem menü, a security ahol bios jelszót tudok hozzáadni meg betudom állítani a boot sorrendet. :D
Kb ennyi ami van, szívesen megmutatom személyesen is :D:D
--
Favorite DesktopOS's: OpenSuse 11.2, Fedora11, Mandriva 2010.0, Ubuntu 9.04
Favorite ServerOS's: Debian 3.1, CentOS 5.4

"Sajnos nem egyszerű átállni az UEFI-re, legalábbis nem a már legyártott alaplapokkal. Az UEFI nagyobb tárhelyet igényel, mint a BIOS, és nem támogatja az összes alaplapot, mindegyiken saját UEFI-kódot kell futtatni"
és mik az előnyei ennek kihalásnak???????????????
A szom akar butulni TB-os lemezekről.
Egészen pontosan milyen tárhelyre gondolt? RAM, ROM? lyukszalag, Hollerith-kártya, ferritgyűrűs memória (asszem ez a legnagyobb)
:-)

"ezzel szemben az UEFI programnyelve C, ami rugalmasabban kezelhető"


fiction bios {
   click; drag; move; drop; omg!
} 

Ha már ennyit görcsölnek ezen nem lehetne futtában kezelhető parancssoros felület is?

egyébként csak tudd meg, raktam össze már olyan "szolgagép"et, ami bekapcsolás után soros aszinkron porton várta az ibm lyukszalagos hexadump formátumában rögzített további "BIOS"-át - sőt volt hozzá interface kazettás magnón Kansas City formátumban rögzített kód beolvasásához is.

Ez akkor volt, amikor napi használatban volt a leporellós konzolírógéppel ellátott lyukszalag író-olvasó.

"és mik az előnyei"
Nincs neki... Na jó, lenne, az alapötlet teljesen jó, csak hát megint elkummantották a kivitelezést :-(

"A szom akar butulni TB-os lemezekről."
Tudsz, az csak egy bullshit, hogy nem. Mint korábban írtam, a BIOS extended read 64 bites LBa címeket kezel.

"Egészen pontosan milyen tárhelyre gondolt?"
Egy licensz díjas FAT32 partícióra a winyódon. Ha egész pontos akarok lenni, akkor a GPT-ben kell lenni egy olyan bejegyzésnek, hogy {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}, és innen fog bootolni. Nincs többé olyan, hogy aktív partíció, helyette fifikás efi exe listák és default path-ok vannak.

"Ha már ennyit görcsölnek ezen nem lehetne futtában kezelhető parancssoros felület is?"
Hogy a viharba ne, (meglepő módon) EFI Shell-nek hívják. http://docs.hp.com/en/A5201-90017/apbs02.html

Ja 60 Ft/alaplap licenszdíj (meg azt is meg kéne nézni, mikor jár le a szabadalom, 10 éven belülre tippelek)
Bele fogunk halni.

PE (.exe) formátummal mi a baj?

Aktív partíció: én örülök neki hogy annyi. Vicces dolgokat tud csinálni, ha két, egymást nem ismerő OS (pl. Linux és Windows) van a gépen, aztán sakkozni kell hogy melyik legyen MBR, melyik aktív, meg mi passzolja át a bootot minek. Nálam MBR-ben grub, aktív viszont a win partíciója (az XP-s NTLDR csak így indul normálisan), tehát a funkció teljesen elvesztette a szerepét.
Ezt valahogy kulturáltabban is meg lehetne oldani.

Igen, 1980-ban még nem volt több OS egy gépen. Most mintha pont 30 évvel később járnánk....

szerk: amúgy a boot loaderek minden szarja most is a HDD-n van (boot.ini, /boot/grub/* [itt filerendszer driverek is], stb). Ezt egységesítené a boot partíció.

Hogy ne mondjátok, csak fikázok, összefoglalom, mi lenne a jó szvsz.
1. EFI PE futtathatók, meg toolchain, egye fene, ez maradhat. Kell egy egységes formátum.
2. Alap EFI API (BIOS műveletek megfelelői) ez is ok
De! És innentől más.
3. Legyen benne az egész a ROM-ban (EEPROM stb.) a mostani BIOS helyén.
4. A driverek legyenek úgy, mint a mostani BIOS ROM extension-ök, de EFI applikációk legyenek (C8000-as címtől bemappelve a kártyák ROM-jai)
5. Ne kelljen EFI rendszerpartíció a bootoláshoz, maradjon csak meg a jól bevált töltsük be a partíció elejét és ugorjunk rá séma. Esetleg annyit módosítanék, hogy ne az első, hanem az első 16 szektort töltse be
6. Az esetlegesen szükséges további EFI fileok legyenek egy alaplapra intergrált 128M-es flash-ben, de csak akkor kelljen használni, ha valami speckó diag programra van szükség, vagy az egyik ROM driver helyett frissített EFI executable-t kell betölteni.
7. A ROM-ban lévő EFI-nek tartalmaznia kell(ene) mindent a következő taskok winyó nélküli ellátására: boot menü, netboot, egyszerű diag (memtest stb.), rescue shell (lehetőség a flashen lévő további fileok futtatására). Ennyi.

Na, ha így nézne ki az EFI, egy szót se szólnék, leborulnék az Intel nagysága előtt :-D

Defaultból ennyit pocsékol el az OSX minden diszkemből "EFI System partition" címszóval. És nem lehet letiltani, se kisebbre venni, ráadásul minden diszkemre rárakja, nemcsak a rendszerdiszkre, pfff. 256 megás pendrivenál kifejezetten jó. (Mielőtt belémkötnének, igen, tudom, hogy pár ezer forintért van nagyobb, de amire használom, ez is bőven elég (lenne). Itt kérem elvekről van szó.)

Én a világ minden kincséért se akarok ellentmondani a Magyar HUP Unix Linux Ubuntu Portál Hatalmas Szaktekintélyeinek, főleg nem akarom azt implikálni hogy hazudnak mint a vízfolyás, de annyit azért bepastelnék, hogy

$ diskutil list disk2
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *513.8 MB disk2
1: DOS_FAT_16 513.8 MB disk2s1

[ #FreedomFlotilla ] [ hupexpertize© ]

OSX-es diskutil-ot használtál? Eddig csak ott jött ez elő. A hibajelenség az, hogyha letiltom az efi partíciót, akkor látszólag megcsinálja, majd hibaüzenetet dob, és mountolni sem engedi, hibás diszknek nézi. Ha hagyom, hogy feltegye, akkor minden szép és jó. Csak GPT-nél, IBM PC partíciókkal nincs gond.

Aham.

$ diskutil partitionDisk disk2 1 GPT HFS+ ize 512M
Started partitioning on disk2
Unmounting disk
Creating partition map
Waiting for disks to reappear
Formatting disk2s1 as Mac OS Extended with name ize
Finished partitioning on disk2
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *513.8 MB disk2
1: Apple_HFS ize 513.8 MB disk2s1

[ #FreedomFlotilla ] [ hupexpertize© ] [ hupdiploma ]

:-D

1. ha poén, akkor jó
2. ha nem poén, akkor is, ugyanis én is megtettem :-) Írtam egy kis C proggit, ami kiszámolja a megfelelő crc összegeket, aztán becsépeltem, mikor már eldurrant az agyam :-) Sajnos az OSX-nek nem tetszett (nem tudom miért), Linux alól minden további nélkül működött, és semmilyen ellenőrzés nem dobott rá hibát, úgyhogy passz.

Sot a Mac OS 9 sem ment x86_64 alatt. Mar csak arra kene rajonni, ez hogy kapcsolodik a szalhoz, aminek relevans resze ezzel indul:

Darwin turduss-iMac.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:57:13 PST 2010; root:xnu-1504.3.12~1/RELEASE_X86_64 x86_64

Erre irtad, hogy humor topicban mit vartal, amire kerdezte Finder, hogy mi a gond vele. Erre irtad, hogy 10.3-as OS X nem fut x86_64 alatt. Ami igaz, csak eppen semmi koze sincs ahhoz amibol az egesz kiindult, mivel az Darwin 10.3, nem pedig OS X 10.3

Amennyiben meg mindig ugy gondolod hiba van a gondolat menetben, kerlek ird le hol hibaztam.

Nekem ezt dobja az uname -a:


Darwin pscs-MacBook-Pro.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386

Az Activity Monitor szerint rengetek program 64 bites módban fut.
A hackintoshoz nem értek, de azt gyanítom, hogy az a RELEASE_X86_64 az hackintosh-t takar.
Ha tévedek, elnézést.

update:
Eszerint: http://osxdaily.com/2009/09/07/how-to-tell-if-youre-running-the-32-bit-…
Ebből nem következik semmi, csak annyi, hogy bootoláskor a "6" és a "4" gombok egyidejü lenyomásával a 64 bites kernel lett betöltve.
Úgyhogy nem tudom.

Nem hackintosh, teljesen gyári. Mondjuk volt egy köröm vele, hogy 64 bites kernelt bootoljon, a Macbookomon nem is sikerült (mint kiderült azért, mert a drágalátós Munkás Pisti azt mondta, "csak"). Ehhez egyébként a kernelnek bootidőben kell átpasszolni egy "arch=x86_64" változót, és akkor nem kell nyomogatni a "6"/"4"-est.

Maga a gép teljesen 64 bit kompatibilis (mármint a macpro-d), úgyhogy nincs mit csodálkozni azon, hogy 64 bites alkalmazásokat is futtat, csak a kerneled belseje 32 bites, így konvertálgat a két api között, ami lassít, de egyébként megy. Ha ugyanezt fordítva csinálja (32 bites appot futtat 64 bites kernelen), az egy nagyságrenddel gyorsabb, mivel hardware támogatás van hozzá proci szinten, ezért raktam át.