A MINIX 3 bemutatása

"Milyen gyakran indítottad újra a TV készülékedet az elmúlt évben? Valószínűleg sokkal kevesebbszer, mint a számítógépedet. Természetesen ennek számos "oka" van, amelyekről a nem-technikai felhasználók egyre inkább nem akarnak hallani. Ők csak azt akarják, hogy a számítógépük mindig tökéletesen működjön, és sose essen hanyatt. A MINIX 3 egy projekt, amely olyan operációs rendszert fejleszt beágyazott rendszerekhez és küldetés-kritikus alkalmazásokhoz, de a jövő 50 dolláros egychip-es laptopjaihoz és általános desktop felhasználáshoz is, amely hasonlóan megbízható, mint a TV készülék. A legfőbb szempont, hogy legyen kicsi, egyszerű és megbízható."

Körülbelül ezekkel a szavakkal vezeti be Andy Tanenbaum - a MINIX atyja - az OSNews-on a MINIX 3-at népszerűsítő cikkét. A cikk ismerteti a MINIX múltját, jelenét, a tervezésének és működésének főbb szempontjait, elérhetőségét.

Igazi kedvcsinálónak készült azt hiszem. Elolvasható itt.

Hozzászólások

Azért nem fagy le a tévém, mert nincs, és így jó. Küldetéskritikusan kibasztam. :D

Software is like sex, it's better with a penguin. :D (r)(tm)(c)

Elképzelhetőnek tartom, hogy rövid idő alatt a MINIX átveszi a linux helyét. Linuxnál már számtalanszor bebizonyosodott, hogy a monolotikus kernelfejlesztési modell kezelhetetlenné, átláthatatlanná vállik egy kis idő után.

Disztrók kijönnének linuxszal, és MINIX-szel.
Ahol nem a teljesítmény, a gyorsaság a legfontosabb, ott valóban jó döntés lenne a MINIX.

"One reason is that C++ simply is a lot more complicated, and the compiler often does things behind the back of the programmer that aren't at all obvious when looking at the code locally. Yes, you can avoid features like virtual classes and avoid these things, but the point is that C++ simply allows a lot that C doesn't allow, and that can make finding the problems later harder.

Another reason was related to the above, namely compiler speed and stability. Because C++ is a more complex language, it also has a propensity for a lot more compiler bugs and compiles are usually slower. This can be considered a compiler implementation issue, but the basic complexity of C++ certainly is something that can be objectively considered to be harmful for kernel development."
(Linus a C++-rol. es igaza van, es ezt ast is tudja)

Ezzel tényleg nem lehet vitatkozni, mert igaza van.

A kérdés az, hogy bevállaljuk-e a hátrányokat, az előnyökért (mert azért azok is vannak bőven). Ez döntés kérdése.
Ők így döntöttek.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Honan veszed hogy, mert monolitikus nehezebb fejleszteni ?
Szerinted ossze vissza van kavarva forrasa? Netan ugyan abba a fileba/konyvtarba kerul a soros port kodja meg mondjuk a swap kezelese?

*BSD -nek sem sikerult igazan megkozeliteni a linux elterjedtseget, natan "Andy" MINIX3 -nak tobb eselye van? Miert is ?

Onnan veszi, hogy ezt szokták mondani.
Ez persze marhaság, mivel egy monolitikus kernel forrása is lehet egyszerű, értelmesen tagolt, moduláris felépítésű.
Hogy a linux ilyen-e azt nem én fogom eldönteni. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Én Linux kernel forrását, szépen tagoltnak tartom.

wiki:
"Monolithic kernels tend to be easier to design correctly, and therefore may grow more quickly than a microkernel-based system. However, a bug in a monolithic system usually crashes the entire system, while this doesn't happen in a microkernel with servers running apart from the main thread."

Vagyis egy microkernelenel egy kernel bug, kisebb esellyel vagja tacsra az egesz rendszert, cserebe "lasabb", és nehezebb fejleszteni.
Szerintem egy kernel-be 0 hiba kell és inkább derüljön ki egy fájdalmas Kernel Panic során minthogy benne maradjon.

Hardware driver fejlesztők gyakran nem sokat látnak abbol, hogy a moduljuk micro vagy monolitikus kernelre irják a driverüket.
"./drivers/usb/misc/usbled.c" egy elég egyszerű USB -eszköz drivere, 3 -LED -et kapcsol.

szerk:
ja és arrol se feledkezzünk meg, hogy pl. usb drivereket lehet user spacben is fejleszteni, vagyis a fejlesztés során nem kell hazavágni a kernelt egy kisebb bug miatt, ugyebár van FUSE -is és más userspaceben történő fejlesztést lehetővé tévő eszközök.

hehe, nekem a tv=gép, nincs külön tv-m. rem rendeshez bőven elég a tuner, mást nem is nagyon nézek :)

A 2.0-ás Minixben lévő ftpd-ben gigaLOL remote root bug volt. "Biztos forrásból tudom, hogy mind a három interneten fellelhető Minix gépet azon keresztül törték fel." >;D

És a legjobb az egészben, hogy nem is Tanenbaum bácsi írja, hanem csóró egyetemistánka adja ki darabokban pár száz EU-ért. (Ez is biztos forrás:)
--
A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station

hirtelen fellelkesedésemben le is töltöttem, de hibásnak bizonyult mindkét tömörített cd képfile :( eek ,az egyik jó :)
ricsi

A Minix mindig is opensource volt? Vagy rosszul emlekszem...?

Tetszik. Olyan puritán. Pedig még csak a VMWare-es image-t nézegetem. De keresek a kamrában egy kiöregedett notebook-ot és felinstallálom rá. :-)

Ave, Saabi.

Szolni kene neki, hogy nem az oprencer miatt van ujrainditva a gep..

Nem tudom, ki hogy van vele, de nekem az asztali pc-m egy évben kétszer-háromszor van kikapcsolva, újraindítva.
A TV-met meg meglehetősen kímélem, gyakorlatilag szinte csak a barátnőm használja amikor itt van, szóval el lehet mondani, hogy a TV gyakrabban van újraindítva, mint a PC... :)))

Morzel

Valószínű, hogy az eredeti szövegben szereplő "TV set" (ami nagyvonalakban TV készüléket jelent) nem a klasszikus TV készüléket jelentheti, hanem a TV set(-top box)-ot, ami hasonló a parabola beltéri egységekhez. Na, azokat van úgy, hogy évekig nem kapcsolod ki/be. Nem akartam belemagyarázni a szövegbe olyat, ami nem biztos, de valószínűleg AST nem a TV ki/be kapcsolásra gondolt.

--
trey @ gépház

A tv-met nem kapcsolom ki soha, mert nincs... Viszont a hütö kivételével szinte mindent kinyomok/kihúzok (pl. mosógép), amikor kirakom a lábam a lakásból 1-2 óránál hosszabb idöre...

Mellesleg, ha már beágyazott rendszerek, cimborámnál a lakás fütés, melegvizellátás szabályozását lassan 16 éve egy jó öreg ZX Spectrum látja el, rom-ba égetett - még az idök hajnalán pascalban összetúrt némi assembler-rel megtoldott - sw segitségével. A 8 bites csöpség azóta is végzi a dolgát rendületlenül, megért már egy fütés korszerüsitést de ö maradt, mert müködik és a feladatot tökéletesen megoldja (6 szoba termosztát jel fogadása, 10 mágnes szelep vezérlés külsö hömérséklet, napszak és évszak figyelembe vételével). Valószinüleg csak az alkatrészek elöregedése fogja korlátozni szegénykémet. Mivel az összetákolt vezérlés forrása elveszett, na meg a meglehetösen barbár módon épitett I/O vezérlö leirása is elkallódott, csak reménykedünk, hogy birja még egy darabig...

Vannak itt még kiaknázatlan lehetőségek, úgy érzem. Pl. hangérzékelő szenzorok a lakás különböző pontjain elhelyezve a végbényíláson át hangkísérettel távozó bélgázok érzékelésére - esemény után automatikusan beindulna a szellőztető ventillátor-rendszer -, no és persze a szagmintákat elemző érzékelők, amik a sunyi-lapos változatot tapogatnák le. És így tovább, a lehetőségek száma szinte végtelen... Mindez ZX Spectumon futtatott Minix3-mal vezérelve. Már, ha fut azon is.

le kéne róla szedni az adatokat és visszafejteni a kérdéses progit! :D
az I/O-t meg röntgennel lehetne átvilágítani és az alapján elemezgetni, de lehet h szerencsésebb egy vadiúj kütyü fejlesztése, ahol figyelembe lesz véve, h 20-30 v 40 év múlva csereberére szükségeltetik...

Engem az érdekelne, hogy mlg mindig olyan átlátható és olvasmányos a kódja, mint régen volt? Megjegyzések, stb... ugye ez az a rendszer, ahol nem annyira az optimalizácóra és hatékonyságra mentek ki, hanem arra, hogy az operációs rendszerekkel ismerkedőknek a segítségére legyen.

Csak azért kérdem, mert akkor kiírom lemezre, és beteszem a könyvbe, a "hivatalos" cd-melléklet mellé... :)

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven