 Hozzászólások  A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
(Persze nem teljes idle-ben, hanem fut a torrentkliens a háttérben.)
|
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+%. :)
|
> Valószinüleg nem kernel space driverek rágják a memódat, hanem userspace cuccok.
Ezt honnan veszed?
|
Szo nem volt itt szerveriparrol, sem annak a felnivalojatol.
|
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%)
|
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ó.
|
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.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
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
|
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."
|
SAS
Azért ne féltsd a szerver piacot, nem fognak desktop csatolókra átállni. Nem biznisz nekik.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
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.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
Az USB 3.0-mat tavaly mutattak be, az lesz az ami verni fog SCSI-t, egyebeket. 4.8 Gb/s.
|
> 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.
|
Jogos, en emlekeztem rosszul. Ezek szerint nem ez az egyetlen rossz diagramm (kis "b", nagy "B" dilemma). 
|
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
|
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."
|
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.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
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.
"The voices are back... Excellent."
|
> 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.
|
> 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... 
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...
|
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..
"The voices are back... Excellent."
|
> 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.
|
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.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
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
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
> Értsem úgy, hogy virtulizálva fut maga az OS is, mint EFI guest?
Persze. Mi ezzel a baj?
|
> 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.
 480 Mb/s
|
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 :)
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
 |
"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ó.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
> 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.
|
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.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
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 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.
|
Vakok közt a félszemű a király, mi?
|
Ha neked túl bonyolult az USB (akár OS, akár hw oldalról), inkább ne programozz...
|
Látom, te is magasra fejlesztetted a lényeg levételének képességét...
|
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?
|
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.
"The voices are back... Excellent."
|
"Itt nem hiszem, hogy sokan ismerik a sed-et turul :D Ez nem az a hely."
Ideje kulturálódniuk :)
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
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.
|
Nem váltotta ki. Csak van ahol azt hiszik.
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
|
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...
|
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!
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!
|
"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... :)
|
> 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.
|
s/íraj/Írjak/g
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
"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á ?
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
> 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.
|
"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. |
És akkor végül vagy olyan programozók dolgoznak a bios-okon (EFI-ken), akik meg is tudják csinálni, amit kell, vagy a gyártó jön rá, hogy nem lehet X idő alatt használható bios-t (EFI-t, bármilyen szoftvert) írni, ha nem marad több fejlesztője. Végső soron tehát az a fogyasztó járna jól, akire most magasról tesznek. Szar munkára nincs mentség, csak kifogás. Vagy a gyártók/fejlesztők járjanak 80%-ban működőképes kocsival, nézzenek 80%-ban működő tévét, stb, ha számukra ez elfogadható, de ők azért vszleg az első hiba láttán dühösen rohannának a szervizbe.
A vásárlót meg nem is kell, hogy érdekelje, miért nem működik valami. Ő kifizeti a pénzt a termékért, amelyet hibátlanul kellene megkapnia. 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, aztán elámítják a maflábbakat mindenféle "fejlesztéssel", ahelyet hogy azt tennék használhatóvá, ami már megvan, csak rossz.
|
> Felhasználóként, és szakemberként sem érdekel, hogy mi az OKuk a szar bios-oknak, elcseszett, hibáktól hemzsegő operációs rendszereknek, szoftvereknek. Aki ilyet ír, rúgják ki, menjen kőfejtőbe.
Tudod ezzel az az oriasi baj, hogy ez nem kivansagmusor a fejlesztoknek. A szarul megirt BIOS-okert vagy eszkozvezerlokert a gyartoi erdekellentetek felelnek, az egymas kozti egyutmukodesre valo nemhajlandosag. A fejleszto meg teszi amit a fonokei mondanak neki. Ha azt mondjak neki, hogy BIOS-t kell neki taknyolni napi 8-12-16 oraban, akkor o BIOS-t fog taknyolni, kulonben az jon amit te magad kivantal neki: "rúgják ki, menjen kőfejtőbe".
|
> Magam is dolgoztam fejlesztőként, és már akkor is rühelltem, hogy fejlesztők akarják megmondani, mi kell a népnek, mert láttam, a nép mennyire nem vevő a fejlesztők idióta ötleteire.
Te felhasznaloi szoftverek fejlesztoirol beszelsz, ahol EGYENI megrendelesre EGYEDI szoftverek keszulnek a Kedves Felhszanalo igenyei alapjan. Itt pedig egy rendszerszintu API fejlesztesrol van szo, szabvanyokrol ami emberek szazmillioit/milliardjait fog erinteni. Hat nehony mar a sajat kicsi IT-mikrovilagabol kiindulo Kedves Felhasznalo szabja meg, hogy amit eddig 100x energiabefektetessel tudtunk megoldani azt most nem tehetjuk meg 1x energiabefektetessel, mert a szakmaban jaratlan vagy tajekozodni nem akaro par laikusnak jo volt igy is. Mert ugye nekik nem szamit az sem, hogy miert kerul n%-kal tobbe egy BIOS fejlesztese adott alaplaphoz, vezerlokhoz egyeb rendszerelemekhez.
Azt is magasrol szarja le a "fejleszto", hogy A20-tol, a video BIOS-ig, shadow-tol a video RAM-ig minden anyjapicsaja a konvencionalis memoriara van mappelve. Csak akkor nyafog amikor az x86-os alaplapon a 4GB memoriabol harmat lat a BIOS mert a tobbit mar nem tudja megcimezni (kiveve ha ujabb szuksegmegoldassal meg van taknyolva az OS nemi teljesitmenyveszteseg aran). |
Legrosszabb esetben legalább alap szinten minden OS alatt használhatók lennének a cuccok.
Most már csak egyéb interfészeket kellene (nyitott) szabványosítani, és az egész számtech egy jobb világ lenne.
|
Az meg igen nagy előny lenne mindenkinek (kiv. MS), ha OS-független driverek lennének. Legalábbis egy alsó szintjük az lenne, aztán a GUI-t már mások is megcsinálhatják hozzá a saját kedvenc OS-ükhöz. Persze előfordulhat, hogy szükség van egyéb magasabb szintű összetevőre is OS szinten, de azt még mindig könnyebb a gyártónak többféle OS alá megcsinálnia (meg másoknak is), mint az egész drivert.
|
Ezt a felhasználót sem a BIOS, sem az EFI nem érdekli. Akkor most hogy is jön ide? Ha viszont az EFI valami módon megkönnyíti a fejlesztők dolgát, az jó dolog, attól függetlenül, hogy ez nem érdekli az egyszeri felhasználót.
|
Ilyen alapon nincs olyan OS, ami ne lenne használhatatlan bughalmaz..
Az mondjuk engem is meglep, miket tudnak szerencsétlenkedni sima BIOS-okkal is. Kérdés, ezt az EFI-s dolgot ki fejlesztené az adott laphoz? Ugyanaz, mint most a BIOS-t?
|
Frászkarikát. Magam is dolgoztam fejlesztőként, és már akkor is rühelltem, hogy fejlesztők akarják megmondani, mi kell a népnek, mert láttam, a nép mennyire nem vevő a fejlesztők idióta ötleteire. Bármily hihetetlen, rengeteg olyan ember van, aki annyit ért a számítógéphez, hogy bekapcsolja, és leállítja, nem is kíván többet. Tökéletesen megértem őket, ha azt akarják, hogy minden 100%-osan működjön, mert lesz.rják a mindenféle PC-s extrabaromságot, csak annak a szoftvernek a működése érdekli őket, amellyel dolgozni/játszani akarnak. Vitatkozhatunk mi itt akármiről, ez a felhasználók többségét egyáltalán nem érdekli.
Van bios, legyen jó, és van op. r., amellyel a felhasználó kiaknázhatja a PC-je képességeit. Ha gyors PC-t akar, RAM-drive-ra telepíti/telepítteti az OS-t. Nekem szakemberként sem kell egy alaplapra integrált rendszer, hogy aztán az szórakozzon a PC-mmel, aki csak akar, így is minden szar kis szoftver/driver lépten-nyomon a netre akar csatlakozni, nyilván nem azért, hogy segítse a munkámat.
Felhasználóként, és szakemberként sem érdekel, hogy mi az OKuk a szar bios-oknak, elcseszett, hibáktól hemzsegő operációs rendszereknek, szoftvereknek. Aki ilyet ír, rúgják ki, menjen kőfejtőbe. |
> Itt a dumával megint ránk akarnak sózni egy teljesen szükségtelen valamit, ez a lényeg.
Fraszkarikat. Eppen forditva. Evtizedeken at mi fejlesztok dumaltunk, hogy csinaljak meg mar normalisan es legyen belole vegre egy atgondolt fejlesztes.
> Sajnos ált. gyakorlat, hogy a "fejlesztéssel" csupán a hibák száma nő, és az élvezeti érték csökken.
Aminek ugye eppen az az oka, hogy evtizedeken at strategiai alapnak szamito szabvanyokat nem hajlandoak atgondoltan fejleszteni es minden gyarto kenytelen a sajat feje utan menni, a sajat hulye megoldasaival megoldani olyan problemakat ami mindenkit bosszant. Eredmeny: ahany gyarto annyi fele megoldas ugyanarra a problemara. Kovetkezmeny --> attekinthetetlen, szuksegtelenul tulbonyolitott szoftverek, melyek minel komplexebbek annal nehezebben attekinthetoek/karbantarthatoak.
|
Hát, valószinüleg nagyon utána kéne olvasnom ennek az EFInek, hogy kiderüljön számomra miért is lesz nekem ez jó a BIOS helyett. Soha az életbe nem volt bajom a BIOSsal, az hogy kell bootmanager meg oprendszer függő driver az sose vágott taccsra.
Felőlem csinálják, csak ne bonyolitsák túl vele az életem és működjön :)
|
már nem azért, de ez nem a játékipar... (pontosabban... félig az ugye, de azért a firmware-k, biosok írását nem úgy csinálják, hogy na, most kiadok nem érdekel, hogy félkész állapotban van, majd jön a peccs, addig meg kit érdekel, hogy csak 3 bekapcsolásból kécce indul el .. )
|
Szerintem a Játékokkal csak a lehetőségeket szeretnék megmutatni. Ahogyan lehet bios-t frissíteni úgy gondolom ezt is és ha rész programokat is le lehet cserélni rajta akkor valószínűleg le lehet majd cserélni a programokat az EFI-n. Például hasznos lenne CD, Mp3, esetleg film lejátszására alkalmas programokkal feltölteni, így nem kellene Oprendszer, ha az egyes hárdverek kezeléséhez szükséges meghajtóprogramok a kártyákon rajta lenne (videokártya, ...) akkor ez nem is annyira elképzelhetetlen. Persze kérdés mekkora tárhely áll az EFI rendelkezésére és hogy bővíthető-e.
|
Tényleg jó, hogy egyesek nagy baromságokat tudnak mondani. Főleg, akiknek az agyát kimosta a marketing.
A bios az legyen bios, és legalább használható. Hogyan írhatnának egy használható EFI-t, ha egy jóval egyszerűbb bios-ra sem képesek?
Itt a dumával megint ránk akarnak sózni egy teljesen szükségtelen valamit, ez a lényeg. Sajnos ált. gyakorlat, hogy a "fejlesztéssel" csupán a hibák száma nő, és az élvezeti érték csökken.
A rendszer beállítására ott a bios (lehet fejleszteni, bővíteni), a használatára meg az op.r.
|
Ez az EFI egy olyan dolog mint az UFO-k: mindenki beszél róluk régebb óta, páran állítják hogy látták, de senki se hiszi el hogy tényleg létezik vagy létezni fog...
|
A Linux életben maradásának egyik fő kulcsa a nyitottsága, ami által elegen fejlesztik ahhoz, hogy a driverekre is jusson némi kapacitás. De még ott sincs mindenhez driver, és sokszor elég körülményes a dolog.
Viszont az olyan, amúgy elég jónak induló OS-ek, mint BeOS, QNX, stb. kimúlásának meg a driverhiány volt az egyik fő kulcsa. Ha a Linuxtól nem is, legalább a többitől meg lehetett így (+ még néhány fortélyjal) szabadulni.
Majd meglátjuk, a Vista SP1-ben engedélyezve lesz-e a támogatás (vajon melyik érdek győz a cégen belül). Mert ugyebár megvan, csak le van tiltva, mint írta valaki. Hasonlóan XP-nél.
|
OS-en áltlános célú OS értettem, mert DSP-n is fut egy speckó OS.
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
talán egy fekete macskához nem kell ps3... igaz nem is biosból fogok munka/egyéb közben játszani:)
|
bakki, mondasz valamit :) :)
de tökmindegy, szerintem azért nem érdekli ez a Microsoftot, mert ha nem a HW gyártók, akkor a linuxos kockák két percen belül összedobnak egy drivert mindenhez... ráadásul véleményem szerint így legalább nem lesznek ilyen driver-problémák, mint a Vistánál (mármint, hogy nincs driver..)... ammeg a másik kérdés, hogy mennyire lesznek mindezek megírva, de akkor meg ott a szokásos megoldás, hogy az MS ír egyet magának..
|
Nem tetszik.
Még több ismeretlen (talán hibás) kód fog futni gépemen ami eszi CPU időmet , stb.
Még kevesebb dolgot fognak specifikálni a hardware tekintetben.
Kis érdekesség:
Speciális eszközökben használnak olyan megoldást, hogy DSP futnak mindenféle okosságok, egy ARM coron meg fut egy oprendszer. DSP -vel nagyábbol úgy kommunikál, mint, ha sok virtuális periféria lenne (DSP programjától függ.) A lényeg, hogy itt hardware bizgeréléshez szükséges kódnak nem az kell az OS-t futató magon futnia. (Dsp főleg tömörítésre, kodolásra /dekodolásra, és szürésre..stb. szokás használni) keywords: DaVinci, VirtualLogix
Parncsoros "bios"-osdi már ősrégi :)
Linux nem Win: http://www.unixlab.hu/LNW/index.html
gentoo : http://www.gentoo.org/main/hu/philosophy.xml
|
Minek bele játék, mikor a pcs játékoknak leálldozott?
|
Hát már jó lenne ha valamerre fejlődne az a bios.
Lehetne benne valami amivel az op rendszert átmásolhatom egy az egyben egy másik merevlemezre vagy csinálhatok vele kép fájlt rolla és ki írhatom DVDre.
|
Ha a nyamvadt játékok helyett inkább driverek lennének, sokkal hasznosabb lenne.. nincs olyan túl sok oprendszer, amihez ne lehetne alap drivereket mellékelni. Akinek meg ez nem elég, az tegyen fel újabbat/jobbat.
http://www.konzolpont.hu/
|
Ez parasztvakítás, mert pont azt csinálja, amit a BIOS-nak kell, tehát egy BIOS, amit nem annak hívnak.
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!
|
csak azért nehogy elmenj szó nélkül :)
|
Hallottál már ilyesmiről, hogy nem minden hw gyártó készít Linux-drivereket? Más OS-ekről nem is beszélve...
|
de ez miért lenne ellentétes az önös érdekeikkel?
|
valami hasonló! és igen, tök jó:)
|
hát neked se kellett volna billentyűzetet ragadnod:)
|
(Vagy hogy a berakott modulok számától függően csükken a hivatalosan támogatott maximális memóriaórajel. [Intelnél is.])
|
|
Nyomtatás
Elküldés e-mailben
Az MSI kidobná a BIOS-t az alaplapokból
GeForce 9600 és 9500 - az nVidia új középkategóriája
Egyre több a hamis USB-kulcs
A pornóipar is a Blu-ray mellett dönt?
AMD - mobil platform újabb csúszásokkal
