MINIX 3.3.0

UNIX, UNIX-szerű

Andrew S. Tanenbaum bejelentette a MINIX 3.3.0-s "stable" kiadását.

Új funkciók:

  • The first release with ARM support, three Beagle targets are supported
  • Experimental USB support for the Beaglebones (hubs & mass storage)
  • Cross-compiling for both ARM and x86 - the buildsystem is very portable

Fejlesztések:

  • Big source code cleanup - cleaner C types in messages, improved NetBSD compatibility, all minix-specific code moved to a top-level minix/ folder
  • Updated packages overall - a big set is built now; and they are dynamically linked now
  • Improved driver modularity

[ kiadási megjegyzések | letöltés ]

( pehsa | 2014. 09. 16., k – 22:06 )

Pont tegnap toltottem le a 3.2.1-et es telepitettem VM-ekre. Ha ezt tudom, akkor varhattam volna meg egy napot ezzel. :D

( palmaci | 2014. 09. 16., k – 22:44 )

Nem az a lényeg mennyire használható desktopknak vagy servernek.
A tanulás a lényeg. A hozzá tartozó könyvet imádom. Rengeteget tanunltam az oprendszerekról. Programozásról a minix forráskódját elmezgetve. Mert a minixnek a forrás a lényege. Nem is az, hogy létezik belőle binary.

Redben, nem akarok vitatkozni, nincs is hozzá elég ismeretem, de egy kérdés felmerült bennem amire valószínűleg számomra kielégítően tudod a választ.
A Linux forráskódja is szabadon elérhető, ráadásul ez elterjedt és a mindennapi használatra is alkalmas. Akkor miért jobb tanulásra a Minix forráskódja? (Mondom nem vita, csak egy kérdés.)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Azt, hogy te mit hiszel, az engem nem erdekel. De nyugodtan nezz csak utana. Ez valahogy nem sikerult. Ertem en, ez csak azert van mert valaki a tokeletes Linux-rol nem jot irt.

"ütemezőét, a virtuális memória kezelőét, meg a többi core rendszerét"
Hat ehhez meg sok szerencset, ha a Linux kernelben akarod ezt tanulmanyozni.

Bár a dokumentálás nem követelmény, a drivereknek azért van egy de facto standardja, aminek meg kell felelnie, hogy az adott alrendszer karbantartója beengedje.

Erről olyan cégek tudnának mesélni mint az Intel, Broadcom vagy a Marvell. Nem kevés driverük tengődött a vanillán kívül, én meg nem keveset kínlódtam azzal, hogy fordítgassam őket különböző rendszerekhez.

Persze rá lehet mondani a Linux standardokra hogy foshalom, de azt nem, hogy kontroll nélküli foshalom.

A minix még a relatíve átlátható kaliber. A Linux kernelt szerintem az egész planétán mindössze néhányan látják át _teljesen_.

Gyors gugli után az első felsorolási pont igazol is (részben): http://www.minix3.org/other/reliability.html
------------------------
Everyone is a winner*

Összegezve: A Minix kisebb, egyszerűbb és van a Minix forráskódra hivatkozó tankönyv.
Ez elég nyomós érv. Csak ugye az elméletet aztán át kell ültetni a gyakorlatba. A Linux kód tanulmányozása esetén ez a jelentős lépés kimaradt volna, vagy sokkal egyszerűbb lett volna, de ha a Linux ennyivel összetettebb, nehezebben átlátható, akkor a Minix-en kell megtanulni az elveket!

--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Értem én, hogy a Minix célja az oktatás, de azért mégis többet várnék.

Szerintem a mikrokernel hívei adósak egy igazi proof of concept megoldással. Mondjuk egy gép terve hiába nagyon szép elméletben, meg rajzon, ha aztán kiderül, hogy nem lehet legyártani, vagy nem működik. Ugyanez a helyzet a programokkal is. Én kívülállóként kiváncsi volnék, milyen eredményre jutnak.

Minixes élményeim:
1) régen: Natív Minix telepítés. Kívülről sshfs-sel akartam nézelődni rajta, determinisztikusan lefagyott. No nem a mikrokernel (amiről ugyebár tudjuk, hogy atombiztos), hanem a körülötte ügyködő szerverek, de az is elég, hogy resetelni kelljen a gépet.

2) kevésbé régen: Qemu telepítés. Nincs pthread. A CCC lefordul, de érthetetlenül lassú. Először nem is értettem, hogy mi van, azt hittem le van fagyva, de nem, csak lassú. Kiderült, hogy a memóriakezelő rendszer (malloc, free) a hibás. Írtam egy saját memóriakezelőt, azzal valamennyire ment.

3) most: Jó gondolat, hogy áttértek a NetBSD pkgsrc-re, most viszont nem találom, hogy melyik csomagból lesz cc, gcc, c++, g++ parancsom. Gyanúm szerint még mindig nincs pthread.

Közben telnek az évek, unalmas.
--
ulysses.co.hu

"Szerintem a mikrokernel hívei adósak egy igazi proof of concept megoldással."

Én nem értek hozzá meg hívő sem vagyok, de pl QNX-re épülő motyók, Symbian? Vagy ezek nem számítanak? Meg van ilyen is, hogy (se)L4. (Meg hibrid motyók, ilyen jelentéktelenek, mint a Tru64, meg XNU, WinNT, BeOS, OS2...).

Az, hogy mi terjedt el és mi az épeszű, nem feltétlen esik egybe nem csak az oprendszereknél.

( mrev | 2014. 09. 17., sze – 09:07 )

Az első negyedórában: 


# mc
# ldd bash 
bash:
        -lterminfo.1 => /usr/lib/libterminfo.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lintl.8 => /usr/pkg/lib/libintl.so.8
**Pth** SCHEDULER INTERNAL ERROR: no more thread(s) available to schedule!?!?
[1]   Abort trap (core dumped) mc
#

Az baromi jó lehet, ha a mikrokernel sosem száll el, de a használhatósághoz az is kéne, hogy a szerverek is működjenek.

--
ulysses.co.hu