Tanenbaum víziója a "nagymama-biztos" operációs rendszerről

Érdekes felvetés. De ezt csak célgépeken, előre összerakott hardvereken lehetne megoldani, ahogy az Apple csinálja. Akkor az összeomlás veszélye csökken.
A Minix3 lehet hogy kicsi és stabil, ámde teljesíti-e azokat a követelményeket, amiket egy átlagos felhasználó elvár tőle? Lehet-e könnyen telepíteni bármely átlagos hardverre, lehet-e könnyen használni, van-e támogatása hardverekhez, szoftverekhez, amik fontosak, népszerűek? Ahogy megvalósítanánk a minixben a felhasználók teljeskörű kiszolgálását, úgy lenne az is egyre bugosabb.

ez meg a dvorak mindig gondoskodnak a könnyes szemről és a térdcsapkodásról

"Mivel egyes helyeken az átlagos bug ráta 10-75 / 1 000 sor közt van, a hibára futás esélye jelentősen megnőtt. "

Ekkora FUD-t, már Open source korökben is divat a FUD :)

Ezt azért én nem állítanám egy kiadott kernel kódra, még a kicsipuhájé sem lehet ennyire bugos.

------
gentóhuszár

Nekem a digitalis tv vevo fagyot mar le, sima kihuzom bedugom nem volt neki eleg, vagy 5 percig kihuzva kellett hagyni es csak utan indult ujra. szep uj vilag mar a tv is fagy ...

Már futottam olyan szituációba, amikor kellett volna a TV-re (nem ATV-re, hanem a TV-re - éééérteeed?) is a reset gomb. Behalt a menüje. Maradt a kikapcs-bekapcs.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nekem mindig az az érzésem, hogy Tannenbaum-nak savanyú a szőlő. Évek óta hirdeti, hogy a Minix mennyivel jobb, mint minden más, mégis a Linux terjed.

A kis modulos dologban pedig nem értek vele egyet. Ha szabadon értelmezzük, akkor a mostani Linux/Windows/... disztribúciók gépi utasítás méretű modulok sokaságából állnak. Azt akarom ezzel érzékeltetni, hogyha olyan kis méretű modulokat írunk, amik biztosan hibátlanok, akkor rengeteg kell belőlük egy normális disztróhoz, és ilyenkor már a modulok összeillesztése lesz nehezebb, mint azok megírása.

Nem megoldhatatlan feladat.
Csak ahhoz olyan együttműködés kell a hardware és a software piac terén, ami pénzügyi okok, licensz, vagy piaci részesedések miatt nem kivitelezhető. Ha sikerülni is, akkor meg a gyártó cégek még az eddigi helyzetnél is jobban monopól hatalomhoz jutnának, ami teljesen ellehetetlenítené a piacot.
Ha meg mindere nyilt szabványt alkalmazunk, akkor meg olyan nagy volna a választék, hogy kiválasztani a megfelelőt, megint csak problémákba ütközne.
Szerintem nincs semmi rossz a zárt fejlesztésben. Csak akkor a gyártó biztosítsa a megfelelő felületet. A jó példa az NVIDIA. Mind Windows mind *nix alá nagyon jó drivereket készítenek. Könnyen telepíthető és kezelhető.
A minix-nek is talán akkor volna létjogosultsága.
De a piac nem erre hajlik sajnos. :-(
A Linux alatt is nagy problémám, hogy igazán nincsenek egységesítve a dolgok, persze, ha az ember használ egy disztrót, akkor ami benne megvan program biztos működni fog, de ha már egy olyan progi kell ami nincs benne. És esetlegesen a fejlesztő olyan technikákat használ, ami a disztribúcióban sincs benne, akkor ott kezdődnek az egyszerű ember fejfájásai. Linux alatt nem egy hétköznapi feladat Mari néni számára, hogy felrakjon egy programot forrásból, csak azért mert nincsen benne az XY linux disztróban. És akkor még ha függőségek merülniek fel, no akkor jön a pánik és teljesen jogosan.
Persze van, hogy a szóban forgó programot már valaki elkészítette az adott csomagban, hogy könnyű legyen felrakni csomagkezelővel, de még ott is a halandók számára nem könnyű az élet. Mondjuk ha fedora alatt akarsz mp3-at hallgatni. Akkor hack-eld meg a yum file-ait, stb, stb, stb..., és ha jól ügyeskedtél akkor a hangszóró kipréseli magából a megfelelő dallamot.
Persze sokan mondják, hogy a Windows legnagyobb gyengesége, hogy egységes. Az összes Windows-nak ugyanaz a hibája meg stb..., de ahhoz, hogy tökéletesen biztonságos rendszert alkossunk kell az egységesség. És ha bele is akarunk tenni valami újat, akkor annak könnyen elérhetőnek, telepíthetőnek és kezelhetőnek kell lennie. Ami a jelenlegi OpenSource társadalomban még nem áll a helyzet magaslatán.
De ezek csak a szerény meglátásaim.

A céleszköz is lehet bugos, ezt "konstrukciós hibának" hívták már 50 éve is, javasolt javítása egy ököllel az eszközre kifejtett pillanatnyi, heves erőhatás (ezt követően opcionálisan a garancia érvényesítése).

Kommersz informatikai eszközöktől pedig szinte elvárható hogy ilyenekkel legyen tele, gondoljunk csak a házi "DSL router" szrokra (amelyik véletlenül nem melegszik túl 2percenként/döglik meg tervezési hiba miatt, annak a firmware-je bughalmaz).

Nekem is a modularis mikrokerneles elgondolas a szinpatikus. Mondjuk hatrany, hogy az IPC lassabb, mint a monolitikus kernelen beluli foggvenyhivas. Olyan architektorat kell kifejleszteni, amin gyors es hatekony IPC-t lehet megvalositani. Esetleg nem kell minden kis szirszart kulon processzbe tenni (pl. az osszes networking mehet 1 processzbe, azon belul a egyes funkciok kulon-kulon pluginekbe, stb.) (talan a BeOS hasonlo?)

A linux kernel.... hat... Ilyen osszetett dolog installalasahoz szerintem jo volna egy olyan cucc, mint a gentoo portage-e. Vhogy nem jo egyenkent a millio config opci kozzul kivalasztgatni, hogy nekem melyik kell es melyik nem.

Q 0-as lifetime meg szerintem nem csak az OS felepitesetol fugg. A bug-ok fuggetlenek a szep ideologiaktol, ha a filerendszer szerver hibazik pl. akkor nagy bajok lehetnek.

Arrol nem is beszelve, hogy mekkora csusztatas egy oprendszert osszehasonlitani egy TV-vel. Johogynem kalapacsot hozott fel peldanak.

jut eszembe: emlekszik meg valaki a Color Star-ra? :)

A hülye hasonlatok teszik az egész számítástechnikai kérdést gügyögő idióták szintjén történő beszélgetéssé.

Talán Tanenbaum tudhatná, hogy mi a számítógép, ha már oktat és ír róla. A számítógép egy bonyolult, komplex, összetett, kifinomult mérnöki eszköz. Több tízezer matematikai, fizikai, informatikai és gyártástechnológiai tudása, évtizedes munkája tette azt lehetővé, hogy egyáltalán eljusson a számítógép odáig, hogy most ezt a hozzászólást megírjam és mások esetleg lássák is.

Ha már hasonlítgatunk, akkor a tv a számítógéphez képest olyan mint a zsebkés az atommeghajtású tengeralattjáróhoz képest.

Nem az a célom, hogy azt mondjam, csak mérnökök használjanak számítógépet, vagy aki az átlagosnál jobban érti mi megy "belül", mert attól, hogy a számítógép micsoda, még roppantul hasznos az olyan emberek kezében akik azt hiszik, a számítógép ugyanolyan mint a tv és ugyanolyanok az elvárásaik is - "csak működjön".

A cél az lenne, hogy az ilyen veterán oktatók illetve informatikusok mint Tanenbaum ne tagadják le a tényeket, hanem kezdjenek azon filozofálni, hogy hogyan lehet valamit azzal a ténnyel kezdeni, hogy a felhasználók soha nem fogják tudni megérteni azt az eszközt amit használnak illetve hogy mit lehet tenni annak érdekében, hogy egy átlagember - a hasonlatnál maradva - biztonsággal elvezesse azt az atomtengeralattjárót és közben ne lője ki a rakétákat.

Az nem megoldás, hogy akkor butítsuk le a számítógépet a tv szintjére. Van egy mondás, hogy a biztonság egészen a használhatatlanságig fokozható. Ez szerintem igaz a "megbízhatóságra" is. Lehet mikrokernelt írni, meg beépíteni háromszázmillió ellenőrzést, ezt meg is teszik pl a NASA-nál. Ott ez gazdaságos és indokolt. A személyi számítógépek kategóriájában ez lehetetlen, mivel nem gazdaságos. Ha ez megtörténne, akkor az informatikai fejlődés nem lelassulna, hanem évtizedekkel visszapörögne. A perfekcionizmusomat bántja, de a gányhalom a gazdaságos.

Lehet azért sokmindent tenni annak érdekében, hogy a számítógép és az átlagember közti szakadékot kisebbítsük. Az első az oktatás. A második az informatikai rendszerek nyitottsága. Nyílt protokolok, semmi DRM, kumulatív fejlesztés. A diverzitás jót tesz az informatikának, de csak addig amíg a diverzitás nem jelent teljes elszigeteltséget. A tv-s hasonlatokkal meg a francba.

Szerény véleményem szerint kifejezetten jót tenne az informatikának ha a hardver fejlődés üteme lelassulna, mert a szoftver oldal éretté tudna válni. Szigorúan informatikai szempontból persze, ez nem jelenti azt, hogy ezt kivánom vagy akár esély lenne erre. Így az informatikának marad a lag, ahogy megpróbál a technológiai fejlődéssel lépést tartani.

Szerintem pl. egy műhold, vagy hasonlóan nehezen javítható eszköz esetén lehet értelme egy ilyen oprendszernek. Ott nem számít az elterjedtség, gondolom van pénz egyedi meghajtót fejleszteni, stb. viszont a magas szintű rendelkezésre állás és a hibatűrés fokozottan szükséges.

Ha már fel lett emlegetve a TV fagyás: nagybátyám dvd lejátszója szokott fagyni. Rendszerint hibás lemeznél. (Pl. karcos) Egyszercsak megáll a kép, és onnantól kezdve nem tudsz csinálni semmit. A kijelzőjén pedíg a lenyomott gombok számát írja ki. Szóval még ki se lehet kapcsolni szabályosan. Ha kihúzzuk majd visszadugjuk, akkor meg nem kapcsol be, mivel bennemaradt a lemez. Ha kivesszük a lemezt csavarhúzóval, akkor megjavul... :)

Kicsit pontosítanám azt a TV reset gombot, ha jól értelmezem a kapcsolási rajzot (sikerűlt olyat venni, amihez adnak ilyesmit), van olyan TV, ahol van reset gomb, csak nincs kivezetve. Felirat: "For Software Development only - (RES)".
Fejlődik még egy kicsit a technika és előbb-utóbb ki lesz vezetve, idővel meg az lesz a legnagyobb gomb...

Sokat gondolkodtam beírjak-e ide valamit. Végül is mindegy, legfeljebb leugatnak. Szóval a következőket tudom mondani a témáról (bár nekem úgy tűnik, hogy itt már mindenki tud mindent és feleslegesen koptatom az ujjaimat).

Monolitikus kernel

Kernel módban rendszerint az alábbi komponensek futnak:
- megszakításkezelés (interrupt manager)
- MMU (Memory Management Unit),
- ütemező (scheduler),
- folyamatok közti kommunikáció (IPC - Inter Process Communication),
- eszközmeghajtók (drivers),
- hálózatkezelés (network management),
- memóriakezelés (memory management),
- fájlkezelés (file system).

Felhasználói módban általában az alábbi komponensek futnak:
- parancssori környezet (shell),
- fordítóprogramok (compilers),
- felhasználói programok (user programs),
- stb.

Nézzük tehát mi a probléma a monolitikus kernellel?
- szinte a teljes operációs rendszer és annak érdemi része kernel módban fut,
- a komponensek közös memória címterületet használnak,
- nincsenek elszigetelve egymástól az esetleges hibás modulok,
- minden kód (a driver is) a legmagasabb jogosultsági szinten fut,
- a nagyméretű kódhalmaz miatt sokkal több a rejtett (programozói) hiba,
- harmadik gyártótól származó, megbízhatatlan kódok vannak a kernelben (pl.: különféle eszköz-driver),
- az összetettsége és egymásra utaltsága miatt nagyon nehéz karbantartani (programozási szempontból).

Mikrokernel

Itt kernel módban rendszerint az alábbi komponensek futnak:
- megszakításkezelés (interrupt manager)
- MMU (Memory Management Unit),
- ütemező (scheduler),
- folyamatok közti kommunikáció (IPC - Inter Process Communication).

Felhasználói módban általában az alábbi komponensek futnak:
- eszközmeghajtók (drivers),
- hálózatkezelés (network management),
- memóriakezelés (memory management),
- fájlkezelés (file system).
- parancssori környezet (shell),
- fordítóprogramok (compilers),
- felhasználói programok (user programs),
- stb.

Az látszik, hogy a monolitikus kernellel ellentétben egy mikrokerneles operációs rendszer magjában csak a legfontosabb komponensek találhatók. Kizárólag ezek használhatják a közös memóraterületet, csak ezeknek lehet teljes joguk, ezen kívül moduláris a felépítésük és nem utolsó sorban nagyon kevés kódsort (ezáltal kevés hibát) tartalmaznak. Minden "veszélyes" modul átkerült a felhasználói módba, ahol elkülönített memóriaterületen, minimális és ellenőrzött jogosultságokkal futhatnak. Ha ezek közül bármelyik megadja magát, akkor bizony mi egy csepp könnyet se ejtünk értük. A hiba a többieket , de főleg az operációs rendszert egyáltalán nem befolyásolja, miáltal a megbízhatósága drámaian növekedhet.

Azért mikrokernelnek is van hátránya, az pedig a sebesség. Ugyanis a felhasználói módban futó moduloknak, folyamatoknak is kell kernel funkciókat használniuk.

Példa egy driver kernel és felhasználói módú rendszerhívásaira (a idő mikromásodpercben van megadva):

 Rendszerhívás   Kernel   Felh.   Veszteség   % 
 getpid           0.831    1.011  0.180      22
 lseek            0.721    0.797  0.076      11
 open+close       3.048    3.315  0.267       9
 read 64k+lseek  81.207   87.999  6.792       8
 write 64k+lseek 80.165   86.832  6.667       8
 creat+wr+del    12.465   13.465  1.000       8
 fork            10.499   12.399  1.900      18
 fork+exec       38.832   43.365  4.533      12
 mkdir+rmdir     13.357   14.265  0.908       7
 rename           5.852    6.812  0.960      16
                               -----------------
 Átlag                          (1.12), azaz 12%

A példából látszik, hogy átlagosan 12% lehet a hívási időveszteség. Valójában ennek csak akkor van számottevő hatása, ha a hívások ciklikusan, több milliószor ismétlődnének (egyébként észrevehetetlen maradna). Így tehát pl.: 10 db. egymás utáni folyamat létrehozása (Minix-fork) mindössze 19 mikromásodperccel lassúbb a mikrokerneles megoldás esetén, a monolitikus kernelhez képest.

Példa egy lemez I/O kernel és felhasználói módú rendszerhívásaira (a idő mikromásodpercben van megadva):

  Fájl olvasás   Kernel    Felh.    Veszteség   %
    1 KB          2.619     2.904    0.285     11
   16 KB         18.891    20.728    1.837     10
  256 KB        325.507   351.636   26.129      8
    4 MB       6962.240  7363.498  401.258      6
   64 MB         16.907     17.749   0.841      5
                                  ----------------
  Átlag                            (1.08), azaz 8%

Látható, hogy ezesetben még kevesebb, mindössze 8% az átlagos időveszteség. Ez persze kritikus alkalmazásoknál, ismétlődő műveletek esetén nem elhanyagolható. Azonban a biztonság oltárán 8%-ot feláldozni nem olyan nagy feladat.

Példa egy alkalmazás kernel és felhasználói módú rendszerhívásaira (a idő mikromásodpercben van megadva):

  Program           Kernel   Felh.  Veszteség  %
  Build image        3.630   3.878  0.248      7
  Build POSIX teszt  1.455   1.577  0.122      8
  Sort              99.2   103.4    4.2        4
  Sed               17.7    18.8    1.1        6
  Grep              13.7    13.9    0.2        1
  Prep             145.6   159.3   13.7        9
  Uuencode          19.6    21.2    1.6        8 
                                  ---------------
  Átlag                           (1.06), azaz 6%

Itt is észlelhető legalább 6%-os időveszteség. Egyéni döntés kérdése, hogy ez vajon sok vagy kevés.

A minimum kernelméret jó példájaként érdemes felemlíteni a már oly sokszor hivatkozott, Tanenbaum-féle Minix mikrokernelének esetét. A Minix3-ban a kernel 45 db. fájlból, 2947 sor C, és 778 sor assembly-ből áll, amelyek összesen 1729 utasítást tartalmaznak. Ezek azok, melyek kernel módban futnak. Minden másnak irány a biztonságot jelentő felhasználói mód. Ez azért már teljesítmény3 nem igaz?

A moduláris mikrokernel és/vagy a felhasználói mód kiterjesztésének alkalmazásával kapcsolatban a következő megoldások fordulnak elő:
- fejlesztői nyelv által létrehozott biztonsági mechanizmusok (pl.: OKE - Open Kernel Environment),
- ellenőrzött felhasználói módú meghajtók monolitikus kernelen belül,
- minimális kernel méret (kevesebb kód, kevesebb hiba),
- virtuális gépekben és exokernelekben futtatott meghajtó szoftverek,
- stb.

Ezekre nézve voltak is már kísérletek, pl.:
- a Mach kernel a Berkley UNIX-on,
- a University of New South Wales linux kísérleti meghajtó szoftverei (csak diszk és Ethernet driver),
- a Brinch Hansen-féle RC4000 rendszer,
- a 80-as években készült Amoeba, Chorus és V. rendszerek,
- a QNX - UNIX (valós idejű rendszer minimum kernel megoldással),
- Jochen Liedtke által készített L4 (assembly), L4/Fiasco és L4Ka::Pistachio (C++) - Univeresity of Karlsruhe.

Mindezekről egyébként épp Tanenbaum írt egy tanulmányában, melynek címe: "A Lightweight Method for Building Reliable Operating Systems Despite Unreliable Device Drivers".

Ami pedig magát Tanenbaumot illeti: személy szerint nem hiszem, hogy különösebben zavarná a linux térnyerése a Minixszel szemben, hiszen a Minix elsősorban oktatási céból készült. Ezen kívül ő nem csak az operációs rendszerek témában járatos, hanem az elosztott rendszerek, hálózatok, számítógép architektúrák tárgykörökben is. Rengetegen nála tanultak (egy darabig Torvalds maga is). A tudása megkérdőjelezhetetlen. Bár csak a tizede az én fejemben lenne.

Akit érdekel a téma részletesebben, vagyis aki nem csak a másikat akarja szekálni, az kérem, hogy olvassa el ezt a két könyvet:
- Tanenbaum: Modern Operating Systems
- Tanenbaum-Steen: Elosztott rendszerek - Alapelvek és paradigmák

PutAbout

Jelenleg ugy nez ki, hogy az MS egy ideje elkezdett figyelni a Tanenbaum kategoriaju emberekre es olyan technologiakba invesztalni, amelyeket nagymegbizhatosagu szoftverek letrehozasara hasznalnak. Szoval lehet el kene kicsit gondolkodni...