Az MSI kidobná a BIOS-t az alaplapokból
Oldal 1 / 3Következő →
Jelentkezz be a hozzászóláshoz.
#111
(Persze nem teljes idle-ben, hanem fut a torrentkliens a háttérben.)
#110
3. Van egy olyan, hogy RightMark CPU Clock Utility, AMD procikhoz. Külön méri az OS által közölt, és a valódi prociterhelést. Nos, miközben az OS (WinXP) ilyen néhány %-okat jelez, a valódi terhelés szép csendben 30+%. :)
#109
> Valószinüleg nem kernel space driverek rágják a memódat, hanem userspace cuccok.
Ezt honnan veszed?
Ezt honnan veszed?
#107
1. Hogy neked miert lesz jobb/rosszabb azt te tudod. Azoknak viszont mindenkeppen akik csak azert nem tudnak megvenni egy igenyeiknek megfelelo hardvert, mert nincsen a celfeladathoz valasztott OS-re driver. Ha te nem ilyen user vagy akkor nem neked valo.
2. Szinten egyeni szoc prob.
3. Akkor ha nincsen kardiologus a kozeledben NE szamolj utana (benchmark), hogy az OS-ed kerneljenek mekkora az overheadje. (min 30-40%)
2. Szinten egyeni szoc prob.
3. Akkor ha nincsen kardiologus a kozeledben NE szamolj utana (benchmark), hogy az OS-ed kerneljenek mekkora az overheadje. (min 30-40%)
#106
Fejlesztettem már PC-vel USB-n kommunikáló hw-t ipari célra. Mikrokontrollerrel volt megvalósítva az eszköz oldali USB kezelés, és nem mondhatnám, hogy túl bonyolult volt a program. Persze egy egyszerû soros port-kezelésnél bonyolultabb volt. Na és? Viszont jól szervezett az egész, jópár féle eszköz-típust alapból ismer, szabványosított protokollok vannak, amik lekezelése eleve benne van az OS alatti driverben, stb. Nem kell 0-ról kitalálni mindent (mindenkinek máshogy, össze-vissza), OS alatti driverét 0-ról megcsinálni, stb.
Abban a többszázezer(???) soros OS driverben nem csak egyszerûen az USB port lekezelése van, hanem jópár szabványosított eszköztípus lekezelése, protokollok, stb. Neked application-programozóként nagy részével nem kell foglalkoznod, készen kapod az adatokat. Ha valamilyen nem-szabványos eszközhöz kell is kiegészítõ driver, az sem sokkal bonyolultabb, mintha egy sima soros interfészrõl lenne szó.
Abban a többszázezer(???) soros OS driverben nem csak egyszerûen az USB port lekezelése van, hanem jópár szabványosított eszköztípus lekezelése, protokollok, stb. Neked application-programozóként nagy részével nem kell foglalkoznod, készen kapod az adatokat. Ha valamilyen nem-szabványos eszközhöz kell is kiegészítõ driver, az sem sokkal bonyolultabb, mintha egy sima soros interfészrõl lenne szó.
#105
EFI drivert ugyan azok fogják irni akik winest.
Valószinüleg nem kernel space driverek rágják a memódat, hanem userspace cuccok.
AZ ELLEN NEM VÉD.
Valószinüleg nem kernel space driverek rágják a memódat, hanem userspace cuccok.
AZ ELLEN NEM VÉD.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#104
4GFC 4.25 Gbit/sec Fibre Channel.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#103
nekem spec megérne +2%-al több proci idõt, ha a windóz nem 4+ gigán hanem csak másfélen terjeszkedne, mert az efi-driverek megoldják.
\"The voices are back... Excellent.\"
#102
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#101
1. És akkor azok a workaroundok az EFI -ben lesznek az miért jobb nekem ?
2. De éreznék. Hatáskorömön kivüli kód miatt sokkal rosszabbul aludnék :)
3. Inkább 2% -ra saccolom minimum , ezen felül kb. 0.1 usec hozzá adódik minimum minden rendszer hívás jellegû dolgohoz. Ami sok rövid rendszer hivás esetében az idõ nagyobb részét teheti ki, EFI feleslegesen rágja a 33% -ot mondjuk, vagy többet.
Real time mûködés, felejtõs lesz.
2. De éreznék. Hatáskorömön kivüli kód miatt sokkal rosszabbul aludnék :)
3. Inkább 2% -ra saccolom minimum , ezen felül kb. 0.1 usec hozzá adódik minimum minden rendszer hívás jellegû dolgohoz. Ami sok rövid rendszer hivás esetében az idõ nagyobb részét teheti ki, EFI feleslegesen rágja a 33% -ot mondjuk, vagy többet.
Real time mûködés, felejtõs lesz.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#99
> Nem ezért veszek nagyobb hardwaret, hogy egy letisztultnak nevezett modell szerint felépülõ nyavaja pocsékolja a hátammögöt az erõforrásokat.
Akkor megegyszer:
1. Ez a letisztultnak nevezett nyavaja - tobbek kozott - azert pocsekol hangyanyi eroforrast, hogy kesobb kilehessen szorni olyan workaroundokat a kernelekbol, hogy azok tucatjaval szabaduljanak meg mas jellegu "eroforraszabaloktol".
2. Az EFI akar virtualizacios reteg felett futtatja a user OS-t akar nem, szamottevo kulonbseget nem fogsz eszrevenni.
3. A jovo processzorai mar egyre inkabb virtualizacios extensionnel erkeznek, amik ezt a temerdek (kb. 0.1%) EFI overheadet is eltuntetik.
Akkor megegyszer:
1. Ez a letisztultnak nevezett nyavaja - tobbek kozott - azert pocsekol hangyanyi eroforrast, hogy kesobb kilehessen szorni olyan workaroundokat a kernelekbol, hogy azok tucatjaval szabaduljanak meg mas jellegu "eroforraszabaloktol".
2. Az EFI akar virtualizacios reteg felett futtatja a user OS-t akar nem, szamottevo kulonbseget nem fogsz eszrevenni.
3. A jovo processzorai mar egyre inkabb virtualizacios extensionnel erkeznek, amik ezt a temerdek (kb. 0.1%) EFI overheadet is eltuntetik.
#98
Jogos, en emlekeztem rosszul. Ezek szerint nem ez az egyetlen rossz diagramm (kis "b", nagy "B" dilemma). <#smile>
#97
Nem ezért veszek nagyobb hardwaret, hogy egy letisztultnak nevezett modell szerint felépülõ nyavaja pocsékolja a hátammögöt az erõforrásokat. Ettõl kisebb pocséklások miatt is lázadozok. Ill. kisebb nem elenörzött/nem látható kódok miatt is .
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#96
nem is attól tartok hogy nem kikapcsolható, mert gondolom feltelepíted, aztán az efi konzolján beállítod hasonlóan mondjuk egy apache-hoz. de ha pl nem tök nyílt az az efi, akkor ki garantálja, hogy az os és a hardver közé nem pakolnak egy olyan progit, ami esetleg árulkodik rólam?
\"The voices are back... Excellent.\"
#95
SCSI
A digrammod rosz. azok mega BYTE per sec ek.
Az USB meg Mega BIT.
Kb. 10 éves lehet a 160MB/sec -es.
"Amiert ugye nem a csatoloszabvany teheto felelosse hanem az erintett operacios rendszer."
Valószínüleg igazad van.
A digrammod rosz. azok mega BYTE per sec ek.
Az USB meg Mega BIT.
Kb. 10 éves lehet a 160MB/sec -es.
"Amiert ugye nem a csatoloszabvany teheto felelosse hanem az erintett operacios rendszer."
Valószínüleg igazad van.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#94
usb - 480 megabit/sec = 60 megabyte/sec
a linkelt képen meg magebyte-ok vannak.
tehát a komolyabb scsi rendszereknek nem lenne elegendõ az usb nyújtotta sávszél.
a linkelt képen meg magebyte-ok vannak.
tehát a komolyabb scsi rendszereknek nem lenne elegendõ az usb nyújtotta sávszél.
\"The voices are back... Excellent.\"
#93
> szerintem ha kipakolják az os-ekbõl a mindenféle varázslást, hókuszpókuszt és kapnak egy letisztult csatlakozási felületet, akkor a virtualizáció lassító hatása már nem is lsz olyan félelmetes
Ez a vegso cel. Kilapatolni a ganyolast a kernelekbol es konnyen karbantarthato, egyszeru felepitesu kerneleket fejleszteni a komplexitasban elveszo, lassu monstrumok helyek.
> nekem egyetlen bajom van az egésszel, az pedig hogy nem kell oprendszer, hogy kívülrõl az adataimhoz férjenek.
Ezek mind kikapcsolhato funkciok lesznek.
Ez a vegso cel. Kilapatolni a ganyolast a kernelekbol es konnyen karbantarthato, egyszeru felepitesu kerneleket fejleszteni a komplexitasban elveszo, lassu monstrumok helyek.
> nekem egyetlen bajom van az egésszel, az pedig hogy nem kell oprendszer, hogy kívülrõl az adataimhoz férjenek.
Ezek mind kikapcsolhato funkciok lesznek.
#92
> Lassú. Kapok egy felesleges memoria managert ami nem kell, kapok egy köztes réteget amin keresztül kell tolnom a legegyszereûbb mûveleteket is, ami jó esélyél egy pár felesleges context switchet is jelent, ami sok pici egyszerû mûveletnél, jelentõs hatékonyságbeli veszteség.
A kernelspace/userspace mappelese is egy ilyen reteg... <#ravasz1>
Ugyanezekbol az okokbol a kernelek 60%-a is egy ilyen felesleges reteg.
> Rengeteg CPU -mat basztató kód, memória, cpu idõ kikerül a látómezõmbõl. Hiba beazonositás szinte lehetetlen lesz.
Azert a multitaszkos kernelek alatt ezt eddig is megoldottuk valahogy... <#ravasz1>
A kernelspace/userspace mappelese is egy ilyen reteg... <#ravasz1>
Ugyanezekbol az okokbol a kernelek 60%-a is egy ilyen felesleges reteg.
> Rengeteg CPU -mat basztató kód, memória, cpu idõ kikerül a látómezõmbõl. Hiba beazonositás szinte lehetetlen lesz.
Azert a multitaszkos kernelek alatt ezt eddig is megoldottuk valahogy... <#ravasz1>
#91
szerintem ha kipakolják az os-ekbõl a mindenféle varázslást, hókuszpókuszt és kapnak egy letisztult csatlakozási felületet, akkor a virtualizáció lassító hatása már nem is lsz olyan félelmetes (pláne mire elterjed, addigra alap lesz a 4 magos proci).
plusz, lejjebb linkeltem az intel féle efi megoldás efi-tools honlapját. http, ftp szervereket lehet csinálni az efi-vel, ha tényleg virtualizál akkor az os-en kívül. ez ugye mondani sem kell biztos gyorsabb, mint egy os-en belüli valami, hiszen célspecifikus.
nekem egyetlen bajom van az egésszel, az pedig hogy nem kell oprendszer, hogy kívülrõl az adataimhoz férjenek. mondjuk ezt is át lehet hidalni az os által titkosított particiókkal, de azért remélem nem ilyen kuruzslással kell majd védeni az adatokat..
plusz, lejjebb linkeltem az intel féle efi megoldás efi-tools honlapját. http, ftp szervereket lehet csinálni az efi-vel, ha tényleg virtualizál akkor az os-en kívül. ez ugye mondani sem kell biztos gyorsabb, mint egy os-en belüli valami, hiszen célspecifikus.
nekem egyetlen bajom van az egésszel, az pedig hogy nem kell oprendszer, hogy kívülrõl az adataimhoz férjenek. mondjuk ezt is át lehet hidalni az os által titkosított particiókkal, de azért remélem nem ilyen kuruzslással kell majd védeni az adatokat..
\"The voices are back... Excellent.\"
#90
> 480Mbit, egy modern SCSI csatoló ettõl jovál többet tud.
Ja, meg se kozeliti.
> Sokak szerint nem megy ilyen jól sem a gyakorlatban, Latency-ket, meg CPU terheléseket szoktak emlegetni
Amiert ugye nem a csatoloszabvany teheto felelosse hanem az erintett operacios rendszer.
Ja, meg se kozeliti.
> Sokak szerint nem megy ilyen jól sem a gyakorlatban, Latency-ket, meg CPU terheléseket szoktak emlegetni
Amiert ugye nem a csatoloszabvany teheto felelosse hanem az erintett operacios rendszer.
#89
Lassú. Kapok egy felesleges memoria managert ami nem kell, kapok egy köztes réteget amin keresztül kell tolnom a legegyszereûbb mûveleteket is, ami jó esélyél egy pár felesleges context switchet is jelent, ami sok pici egyszerû mûveletnél, jelentõs hatékonyságbeli veszteség.
Rengeteg CPU -mat basztató kód, memória, cpu idõ kikerül a látómezõmbõl. Hiba beazonositás szinte lehetetlen lesz.
Ezeket kódokat ugyan azok fogják írni akik a BIOS-okat vagy kékhalál drivereket.
Lehet, hogy lehetõségem sem lesz javítani a bugjaikat. Honan fogod tudni, hogy melyik rejtett folyamat eszi meg CPU -dat,memóriádat , mivel nem látod cpu idõ monitoron, csak azt látod, hogy kurva lassú az égész szemetes ládád.
Rengeteg CPU -mat basztató kód, memória, cpu idõ kikerül a látómezõmbõl. Hiba beazonositás szinte lehetetlen lesz.
Ezeket kódokat ugyan azok fogják írni akik a BIOS-okat vagy kékhalál drivereket.
Lehet, hogy lehetõségem sem lesz javítani a bugjaikat. Honan fogod tudni, hogy melyik rejtett folyamat eszi meg CPU -dat,memóriádat , mivel nem látod cpu idõ monitoron, csak azt látod, hogy kurva lassú az égész szemetes ládád.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#88
480Mbit, egy modern SCSI csatoló ettõl jovál többet tud.
Sokak szerint nem megy ilyen jól sem a gyakorlatban, Latency-ket, meg CPU terheléseket szoktak emlegetni
Sokak szerint nem megy ilyen jól sem a gyakorlatban, Latency-ket, meg CPU terheléseket szoktak emlegetni
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#87
> Értsem úgy, hogy virtulizálva fut maga az OS is, mint EFI guest?
Persze. Mi ezzel a baj?
Persze. Mi ezzel a baj?
#86
> Az más kérdés, hogy SCSI sokak szerint nem elég egységes.
De nem igazán alternativa, mert sebbeségben nincs ott az USB.
<#wilting> 480 Mb/s
De nem igazán alternativa, mert sebbeségben nincs ott az USB.
<#wilting> 480 Mb/s
#85
Nem tudom te hányszor kerülted meg bios-t, mert a te kódod jobb, gyorsabb, jobban illeszthetõ .. etc. Ez az EFI nekem kurvára réteg modellnek tûnik, amit nem kerülhetsz meg . Sõt, ha jól sejtem még, ha keresztül engedõ üzemmodba is váltod a dolgot akkor abban sem lesz köszönet, olyanról még nem halottam, hogy virtualizáció gyorsított volna hardware elérésen.
SCSI specifikációt nem láttam, de nem fogadnék rá, hogy az USB specek egyszerûbbek (már csak topológiailag sem). Az más kérdés, hogy SCSI sokak szerint nem elég egységes.
De nem igazán alternativa, mert sebbeségben nincs ott az USB. Sõt sokan esküsznek rá, hogy pl. a FireWire is jobb, pl. kamerákhoz.
Ha nagyon akarod akkor az r=1 lusernek egyszerûbb dolga van vele.
Olyan rémhirek is keringenek, hogy te mint mezei programozó/gép vásárló nem leszel jogsult sáját kódodat bele passzintani. (Sealed storage)
Valami OEM-ek meg akkarják törni a Pokoli Operátor hatalmát :)
SCSI specifikációt nem láttam, de nem fogadnék rá, hogy az USB specek egyszerûbbek (már csak topológiailag sem). Az más kérdés, hogy SCSI sokak szerint nem elég egységes.
De nem igazán alternativa, mert sebbeségben nincs ott az USB. Sõt sokan esküsznek rá, hogy pl. a FireWire is jobb, pl. kamerákhoz.
Ha nagyon akarod akkor az r=1 lusernek egyszerûbb dolga van vele.
Olyan rémhirek is keringenek, hogy te mint mezei programozó/gép vásárló nem leszel jogsult sáját kódodat bele passzintani. (Sealed storage)
Valami OEM-ek meg akkarják törni a Pokoli Operátor hatalmát :)
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#84
"A system and method is disclosed for protecting extensible firmware interface (EFI) runtime services utilizing virtualization technology. The runtime services used by an operating system (OS) are executed by a runtime services monitor (RSM) rather than the operating system itself. When the OS accesses a runtime service, the processor mode automatically switches context to the RSM, which then executes the runtime service and puts the results back in a shared memory location. Virtualization technology is used to effect the automatic context switching. Other embodiments as described and claimed above are disclosed."
src
Értsem úgy, hogy virtulizálva fut maga az OS is, mint EFI guest ?
!= jó.
src
Értsem úgy, hogy virtulizálva fut maga az OS is, mint EFI guest ?
!= jó.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#83
> Mi az, hogy OS független driver?
Ekkora baromságot még az életemben nem hallottam.
Akkor eppen itt volt az ideje. Az OS fuggetlen driver azt jelenti, hogy az EFI-hez keszit drivert az adott hardverelem gyartoja, igy az OS felol elegendo csupan az EFI azon absztrakcios reteget kezelni ami az adott hardverelemhez biztosit kotest. Magyarul: van egy vodornyi, kulonbozo gyartotol szarmazo EFI tamogatott halozati kartyad, melyek hasznalatahoz nem kell vacakolnod driverekkel kulon minden OS-nel, hanem elegendo feltenned az adott kartyahoz tartozo EFI drivert. Onnettol kezdve barmilyen EFI tamogatott OS-t teszel fel, automatikusan latni fogja a kartyat. Ezt jelenti az OS fuggetlen driver.
Ekkora baromságot még az életemben nem hallottam.
Akkor eppen itt volt az ideje. Az OS fuggetlen driver azt jelenti, hogy az EFI-hez keszit drivert az adott hardverelem gyartoja, igy az OS felol elegendo csupan az EFI azon absztrakcios reteget kezelni ami az adott hardverelemhez biztosit kotest. Magyarul: van egy vodornyi, kulonbozo gyartotol szarmazo EFI tamogatott halozati kartyad, melyek hasznalatahoz nem kell vacakolnod driverekkel kulon minden OS-nel, hanem elegendo feltenned az adott kartyahoz tartozo EFI drivert. Onnettol kezdve barmilyen EFI tamogatott OS-t teszel fel, automatikusan latni fogja a kartyat. Ezt jelenti az OS fuggetlen driver.
#82
Köszön mester, hogy hozzám szolottál.
Bizonyára csak nekem tûnt úgy, hogy bonyolultabb, mint egy RS-232 UART haverral, specifikáció is csak véltelenül van egy csaknem 10Mb .zip fileban (amit pár éve olvasgattam), biztos, mert a csatlakozók fényképeivel van tele. Linux kernel-ben is csak véletlenül van párszezezer sor ,csak usb host controller és core miatt.
És csak ezért, mert egy usb device controlert elég egyszerû bekötni, és libusb -vel userspace drivert csinálni, attól még nem lesz egyszerû a mögötte megbúvõ több százezer félvezetõ elembõl álló eszközök hada. De te biztosan naponta tudsz ilyet tervezni, csak lusta vagy rá. Ha még is idõt szakítanál rá örömmel venném ,ha feltöltenéd a terveket. http://www.opencores.org -csak rád várt eddig.
Bizonyára csak nekem tûnt úgy, hogy bonyolultabb, mint egy RS-232 UART haverral, specifikáció is csak véltelenül van egy csaknem 10Mb .zip fileban (amit pár éve olvasgattam), biztos, mert a csatlakozók fényképeivel van tele. Linux kernel-ben is csak véletlenül van párszezezer sor ,csak usb host controller és core miatt.
És csak ezért, mert egy usb device controlert elég egyszerû bekötni, és libusb -vel userspace drivert csinálni, attól még nem lesz egyszerû a mögötte megbúvõ több százezer félvezetõ elembõl álló eszközök hada. De te biztosan naponta tudsz ilyet tervezni, csak lusta vagy rá. Ha még is idõt szakítanál rá örömmel venném ,ha feltöltenéd a terveket. http://www.opencores.org -csak rád várt eddig.
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#81
Turul. Itt a technologia nem marol holnapra valo egyszerusiteserol van szo hanem egy hosszutavon megterulo fejlesztesrol. Ezt tessek megerteni. Nyilvan rovidtavon osszetettebbe valik egy rendszer tole, de hosszutavon eltavolithatok lesznek mas egysegek.
> Nem váltotta ki. Csak van ahol azt hiszik.
Egyszerûbb lett ? Nem. (See USB spec.)
Lenyegesen egyszerubb mint az SCSI, UW SCSI, stb.
> Nem váltotta ki. Csak van ahol azt hiszik.
Egyszerûbb lett ? Nem. (See USB spec.)
Lenyegesen egyszerubb mint az SCSI, UW SCSI, stb.
#80
> Nem lehet hibátlant gyártani? Hát, te sem láttál még Ferrarit.
Vezettem is. Ettol meg az osszehasonlitasi alap tovabbra is messze van a BIOS/EFI kerdestol.
> És azért van még pár dolog a világon, amelybõl hibátlant gyártanak, a pulóvertõl a repülõgépekig
1. Egy pulover az osszetettsegeben fenyevekre van egy gozgeptol is, nemhogy szamitogep alkatreszektol.
2. Repulogepek kozott sincsen hibatlan, ezert vannak a kulonbozo biztonsagi berendezesek is. Redundans hajtomuvek, robot pilotak, uzemanyagtartalyok, szivattyuk, stb. Ha valami leall, hasznaljak annak valamelyik redundans parjat. Ja, hogy ha van ilyen incidens nem basszak oda lepten-nyomon az utasok orra ele? Ettol meg a problema letezik.
Vezettem is. Ettol meg az osszehasonlitasi alap tovabbra is messze van a BIOS/EFI kerdestol.
> És azért van még pár dolog a világon, amelybõl hibátlant gyártanak, a pulóvertõl a repülõgépekig
1. Egy pulover az osszetettsegeben fenyevekre van egy gozgeptol is, nemhogy szamitogep alkatreszektol.
2. Repulogepek kozott sincsen hibatlan, ezert vannak a kulonbozo biztonsagi berendezesek is. Redundans hajtomuvek, robot pilotak, uzemanyagtartalyok, szivattyuk, stb. Ha valami leall, hasznaljak annak valamelyik redundans parjat. Ja, hogy ha van ilyen incidens nem basszak oda lepten-nyomon az utasok orra ele? Ettol meg a problema letezik.
#79
<#eljen>
#78
Vakok közt a félszemû a király, mi?
#77
Ha neked túl bonyolult az USB (akár OS, akár hw oldalról), inkább ne programozz...
#76
Látom, te is magasra fejlesztetted a lényeg levételének képességét...
#75
Ha esetleg gondolkodni is eszedbe jutott volna...
Mond az valamit, hogy standard (szoftver) interfészek...? (Ipari standard, nem egy cég belsõs standardja.)
Ha az OS-ekben lennének ilyenek a fõbb input/output csatornákra/eszközökre, ezekhez az interfészekhez illeszthetne az alaplapi driver, nem az adott OS sajátságaihoz (mint pl. DirectX, ami csak Windowson van).
Na, pislákol már valami?
Mond az valamit, hogy standard (szoftver) interfészek...? (Ipari standard, nem egy cég belsõs standardja.)
Ha az OS-ekben lennének ilyenek a fõbb input/output csatornákra/eszközökre, ezekhez az interfészekhez illeszthetne az alaplapi driver, nem az adott OS sajátságaihoz (mint pl. DirectX, ami csak Windowson van).
Na, pislákol már valami?
#74
szerintem úgy értik az os-független drivert, hogy a microcode ugyanaz ami viszi a hardware-t különben rá se bagózna mit szövegel a szoftver. ergó ha szabványosítjuk a rendszer eléréséhez szükséges bios feletti rétegeket, akkor az os gyártók rá lennének kényszerülve egy szabványos interface használatára (az os rész alatt ugyanazt használnák). így aztán meg tök mindegy lenne, hogy egy linux egy solaris egy windóz vagy unix vagy freebsd vagy akármi nyúl a hardware-hez, mindegyik ugyanazt látná. de ez csak talán a távoli jövõ. mindenesetre átjárhatóság és fejleszthetõség tekintetében egyszerûbb dolga lenne a programozóknak. a felhsználók meg azt vennék észre hogy minden mûködik minden os alatt. szvsz.
itt valaki lentebb írta, hogy minden os gyártó és programozó nekiáll "összetaknyolni" azt ami nincs meg, gyártsunk egy _sajátot_. na ez szûnne meg legalább driver téren. talán.
itt valaki lentebb írta, hogy minden os gyártó és programozó nekiáll "összetaknyolni" azt ami nincs meg, gyártsunk egy _sajátot_. na ez szûnne meg legalább driver téren. talán.
\"The voices are back... Excellent.\"
#73
"Itt nem hiszem, hogy sokan ismerik a sed-et turul :D Ez nem az a hely."
Ideje kulturálódniuk :)
Ideje kulturálódniuk :)
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#72
Itt nem hiszem, hogy sokan ismerik a sed-et turul :D Ez nem az a hely.
Szerintem az USB azért bizonyos szempontokból mindenképpen egyszerûséget hozott. Ha nem is feltétlen programozói oldalról.
Szerintem az USB azért bizonyos szempontokból mindenképpen egyszerûséget hozott. Ha nem is feltétlen programozói oldalról.
#71
Nem váltotta ki. Csak van ahol azt hiszik.
Egyszerûbb lett ? Nem. (See USB spec.)
Egyszerûbb lett ? Nem. (See USB spec.)
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#70
Az alaplapok évtizeek óta képesek merevlemez nélkül elindulni, mi több, régen nem is nagyon volt a gépekben merevlemez, ugyebár...
#69
Nem lehet hibátlant gyártani? Hát, te sem láttál még Ferrarit. Lehet, hogy a technológiával párhuzamosan fejleszthetõ, de nem HIBÁS, mert akkor senki nem venné meg. És azért van még pár dolog a világon, amelybõl hibátlant gyártanak, a pulóvertõl a repülõgépekig (persze meghibásodhat valami, de nem gyárilag rossz), csak sztech-ben nem találsz hibátlan árut. Talán így már érthetõbb neked is.
Mi az, hogy OS független driver?
Ekkora baromságot még az életemben nem hallottam.
A driver az OS-hez illeszti az eszközt, ezért nem lehet tõle független.
A driver legfõbb tulajdonsága, hogy OS specifikus legyen.
Lila gõzöd nincs arról, hogy mirõl beszélsz!
Ekkora baromságot még az életemben nem hallottam.
A driver az OS-hez illeszti az eszközt, ezért nem lehet tõle független.
A driver legfõbb tulajdonsága, hogy OS specifikus legyen.
Lila gõzöd nincs arról, hogy mirõl beszélsz!
Munkaállomás: C64 64K RAM 5,25\" floppy & Dataset Szerver: XT8086 640K RAM 10 MB MFM HDD 12\" Hercules Monitor DOS 1.0 Megy rajta a Crisys, mint az állat!
#67
"200 Mbyte-ot hagyott az efi particiora"
"a rendszer elerje a particiojat"
"tehat az alaplap akar merevlemez nelkul is kepes elindulni"
Hihi, azért képzelem, mit éreznek ezeket a sorokat olvasva azok, akik szerint jó az a BIOS úgy, ahogy van... :)
"a rendszer elerje a particiojat"
"tehat az alaplap akar merevlemez nelkul is kepes elindulni"
Hihi, azért képzelem, mit éreznek ezeket a sorokat olvasva azok, akik szerint jó az a BIOS úgy, ahogy van... :)
#66
> Kinek lesz egyszerûbb ?
Kinek lett egyszerubb az USB? Kivaltotta a soros/parhuzamos portot, ps/2-t, SCSI kulso csatolokartyakat, halozati csatolokent is tud uzemelni, stb.
Kinek lett egyszerubb az USB? Kivaltotta a soros/parhuzamos portot, ps/2-t, SCSI kulso csatolokartyakat, halozati csatolokent is tud uzemelni, stb.
#65
s/íraj/Írjak/g
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#64
"Es megegyszer: az EFI celja NEM az IT bonyolitasa, hanem osszessegeben az egyszerusitese."
Kinek lesz egyszerûbb ?
Egy újabb absztrakciós réteg beiktatása, rendszerint újabb érõforrás elpocsékoláshoz vezet.
Ha mondjuk gyártok egy speciális PCI kártyát, akkor mit kell tennem ? íraj egy EFI drivert is linux driver -alá ?
Kinek lesz egyszerûbb ?
Egy újabb absztrakciós réteg beiktatása, rendszerint újabb érõforrás elpocsékoláshoz vezet.
Ha mondjuk gyártok egy speciális PCI kártyát, akkor mit kell tennem ? íraj egy EFI drivert is linux driver -alá ?
Linux nem Win: http://www.unixlab.hu/LNW/index.html gentoo : http://www.gentoo.org/main/hu/philosophy.xml
#63
> Csak a sztech iparban lehet szar terméket eladni, mert megmagyarázzák a népnek, hogy ezért és ezért bizony nem lehet hibátlan hardvert, szoftvert gyártani
Merthogy nem lehet semmibol sem hibatlant gyartani. Ez nem kifejezetten az IT privilegiuma, hanem minden amit ember hozott letre az tokeletlen. Az mas kerdes, hogy a felhasznalo hova helyezi a nivot. Egy elsoosztalyu szobafestesben is lehet hibat talalni, ha az ember keres. Ez azonban korant sem olyan hiba ami napi bosszusagot okozhat.
Es megegyszer: az EFI celja NEM az IT bonyolitasa, hanem osszessegeben az egyszerusitese. Nem holnaputan fog megterulni, hanem evek multan, ahogy pl. az USB is. Annak idejen mindenki nyafogott, hogy minek "meg egy" csatlakozoszabvany, holott pont az volt a celja (a neve is takarja), hogy legyen egy univerzalis csatlakozoszabvany. Az EFI az Itanium alaplapokon es az Apple gepein mar bizonyitott eles kornyezetben is es megerett a szeleskoru alkalmazasra is.
Merthogy nem lehet semmibol sem hibatlant gyartani. Ez nem kifejezetten az IT privilegiuma, hanem minden amit ember hozott letre az tokeletlen. Az mas kerdes, hogy a felhasznalo hova helyezi a nivot. Egy elsoosztalyu szobafestesben is lehet hibat talalni, ha az ember keres. Ez azonban korant sem olyan hiba ami napi bosszusagot okozhat.
Es megegyszer: az EFI celja NEM az IT bonyolitasa, hanem osszessegeben az egyszerusitese. Nem holnaputan fog megterulni, hanem evek multan, ahogy pl. az USB is. Annak idejen mindenki nyafogott, hogy minek "meg egy" csatlakozoszabvany, holott pont az volt a celja (a neve is takarja), hogy legyen egy univerzalis csatlakozoszabvany. Az EFI az Itanium alaplapokon es az Apple gepein mar bizonyitott eles kornyezetben is es megerett a szeleskoru alkalmazasra is.
#62
"Persze kérdés mekkora tárhely áll az EFI rendelkezésére és hogy bõvíthetõ-e."
Az apple kb. 200 Mbyte-ot hagyott az efi particiora, oda jelenleg a legtobb altaluk tamogatott hardver driver-e elfer. Bovitheto, mert az alaprendszer rom-ja csak annyit tartalmaz, hogy a rendszer elerje a particiojat. Ha ezt atpakoljuk egy flash kartyara, akkor mindjart diszk fuggetlenne valik a rendszer, tehat az alaplap akar merevlemez nelkul is kepes elindulni. Ez utobbit hasznalta a regi openboot szabvany es ezt hasznaljak az efi-s itanium-os szerverek is. Az apple csak sporol ezert rakta az efi-t a diszkre, de innen fut a bootmanager es a gepek grafikus feluletu ontesztje is (ha jol lattam egy macos9 image alol). Az efi egy szabvanygyujtemeny ahogy a bios is az volt, csak mig az efi kepes a mai gepeknek megfelelni, addig a bios csak a pc-xt-ig volt fejlesztheto, mivel az isa buszra epulo bovitokartya strukturat es az 1 Mbyte-os cimteret vette alapul. Minden kartya kapott egy rom teruletet: a video a 0xc0000-t, a masodik kartya a 0xd0000-t, a harmadik pedig a 0xe0000-t, es az alaplap a 0xf0000-t) Ezert a bios 16 bites isa-s x86-os gepeken, maximum 1 Mbyte rammal, 16 Mbyte ems-el es maximum 3 bovitokartyaval erte el a limitjeit. Azota csak foltozgattak.
Az apple kb. 200 Mbyte-ot hagyott az efi particiora, oda jelenleg a legtobb altaluk tamogatott hardver driver-e elfer. Bovitheto, mert az alaprendszer rom-ja csak annyit tartalmaz, hogy a rendszer elerje a particiojat. Ha ezt atpakoljuk egy flash kartyara, akkor mindjart diszk fuggetlenne valik a rendszer, tehat az alaplap akar merevlemez nelkul is kepes elindulni. Ez utobbit hasznalta a regi openboot szabvany es ezt hasznaljak az efi-s itanium-os szerverek is. Az apple csak sporol ezert rakta az efi-t a diszkre, de innen fut a bootmanager es a gepek grafikus feluletu ontesztje is (ha jol lattam egy macos9 image alol). Az efi egy szabvanygyujtemeny ahogy a bios is az volt, csak mig az efi kepes a mai gepeknek megfelelni, addig a bios csak a pc-xt-ig volt fejlesztheto, mivel az isa buszra epulo bovitokartya strukturat es az 1 Mbyte-os cimteret vette alapul. Minden kartya kapott egy rom teruletet: a video a 0xc0000-t, a masodik kartya a 0xd0000-t, a harmadik pedig a 0xe0000-t, es az alaplap a 0xf0000-t) Ezert a bios 16 bites isa-s x86-os gepeken, maximum 1 Mbyte rammal, 16 Mbyte ems-el es maximum 3 bovitokartyaval erte el a limitjeit. Azota csak foltozgattak.
Oldal 1 / 3Következő →