Plan 9

A lap 2012. november 13., 04:42-kori változata

1 Plan 9 from Bell Labs

A Plan 9 from Bell Labs - röviden Plan 9 - kezdetben egy kisérleti operációs rendszer volt, melyet a UNIX folytatásának szántak. A UNIX alapvető filozófiáját viszi tovább utópisztikus szintekre. Nevét Ed Wood Plan 9 from Outer Space című sci-fi filmjéről kapta. A Plan9 kabalafigurája, Glenda is egy Ed Wood filmből származik. A rendszert kutatók és hobbisták máig fejlesztik. Unix és linux kompatibilitási modulokat írnak hozzá, fejlesztik a hardvertámogatását, illetve folyamatosan kerülnek át belőle ötletek népszerűbb operációs rendszerekbe.

2 Története

Ugyanaz a Computing Science Research Center at Bell Labs nevű csoport fejlesztette eredetileg, akik a UNIX-ot és a C-t kifejlesztették, többek között Ken Thompson, Dennis Ritchie, Brian Kernighan és Bjarne Stroustrup. A fejlesztés a 80-as évek közepén kezdődött, és 92-re készült el az első kiadás egyetemek számára. Később megélt egy kereskedelmi kiadást, a további verizókat pedig nyílt forrással adták ki. Az utolsó verziót 2002-ben adták ki, de azóta is fejlesztik, és jönnek hozzá frissítések.

3 Alapvető irányelvek

A Plan9-et úgy tervezték, hogy legyen “unixabb a unixnál”, tehát a unix elveit feljesztették tovább. A visszafelé kompatibilitást nem tartották szem előtt, sem a korábbi konvenciókat, csak az elveik alapján folyt a tervezés. A következőben az Eric S Raymond - The Art of Unix Programming című könyvében található unix alapvető filozófiai szabályai közül hozok néhány példát.

3.1 Minden objektum fájl vagy fáljrenszer

• Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
• Rule of Simplicity: Design for simplicity; add complexity only where you must.
• Rule of Transparency: Design for visibility to make inspection and debugging easier.

Plan9-ben fájlokon keresztül lehet elérni a rendszer összes funkcióját, jelenthetnek ablakokat, hálózati kapcsolatokat, processzeket és bármi mást, amit a rendszerben el lehet érni. A fájlokat névtereken keresztül lehet elérni. Egy névtérbe több helyről lehet fájlokat gyűjteni, létre lehet hozni mappák unióját(union directory). A processzeknek saját névterekik vannak, melyekben átlátszóan történik a távoli és helyi erőforrások elérése. A kernel processzenként külön mount táblát is tarthat fenn, így minden processz saját névtérrel/fájlrendszerrel dolgozhat. A felhasználó így egyszerre dolgozhat olyan programokkal, melyek más fájlrendszert látnak, így akár chroot szerű sandboxokat is létre lehet hozni a processzeknek.

3.2 9P (9P2000)

• Rule of Modularity: Write simple parts connected by clean interfaces.
• Rule of Clarity: Clarity is better than cleverness.
• Rule of Composition: Design programs to be connected to other programs.
• Rule of Least Surprise: In interface design, always do the least surprising thing.
• Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.[4]

A 9P - és az újabb verziója a 9P2000 - hálózati protokoll, melyet a Plan9 komponenseinek összekapcsolására hoztak létre. Ezzel csökkentették a Plan9-ben az API-k számát, mivel a plan9 összes lehetséges interfészt 9P-ben implementálták. A protokoll szerver-kliens alapon működik, processzeket, programokat és adatot köt össze, illetve a így kötődnek a programok a felhasználói felülethez is. Mivel hálózati protokoll, transzparansen lehet a szerver és a kliens más gépen, így téve a plan9-t grid operációs rendszerré. A programok nem használhatnak socketeket és ioctl hívásokat. Az eszközmeghajtóknak is fájlként van implementálva az interfészük, így a 9P protokollon keresztül elérhetők, és megoszthatók, akár a hálózatban is. Ezen irányelvek következményeként a rendszerben szinte mindent el lehet végezni ls, cat, grep, cp, rm és a shell műveleteivel, anélkül, hogy tudnánk az adott erőforrásról, hogy melyik gépen van.

3.3 /proc

A proc fájlrendszeren a korábban említett elvek érvényesülnek. A processzek mappaként jelennek meg, ezekben vezérlő és információt hordozó fájlok vannak, melyeket egyszerű fájlműveletekkel lehet vezérelni. Ezzel a módszerrel nagyon megkönnyíti a processzek managelését, és még egy apit megspórol. A módszer annyira bevállt, hogy innen vette át később a módszert a BSD, a solaris és a linux is.

3.4 /net

Rendszerhívások és ioctls-ek nélkül a hálózati réteg is fájlrendszer alapon működik, a /net fájlrendszer használatával. Vezérlő fájlokba lehet írni és olvasni, így valósul meg a hálózati kommunikáció. Külön tcp és udp mappák vannak a kapcsolatok protokol szerinti szétválasztására. A rendszer hálózati információit az ndb nevű fájl alapú adatbázisban tárolja.

3.5 Unicode

Hogy tovább csökkentsék a rendszer komplikáltságát, a teljes rendszerben bevezették az unicode karakterkódolást. Ken Thompson dolgozta ki az UTF-8-at, és ez lett a natív karakterkódolást a teljes rendszerben. Innen terjedt el az UTF-8 a többi operációs rendszerre is.

“Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.” —Eric S. Raymond[3]

3.6 Az alapelvek felhasználása

Az említett alapelvek betarátsa nem feltétlenül jelent korlátozást, hiszen egyeszerűbb, atomibb elemekből sokkal könnyebben építhetünk bonyolultabb dolgokat, illetve bonyolultabb dolgok valósíthatók meg így egyszerűbben. Ha például egy Plan9-et futtató gépnek van internet elérése, más gépekkel pedig egy hálózatban van, akkor azokon a gépeken 9P protokoll segítségével union directory-t csinálunk a /net fájlrendszereikből, így lehetőség nyíilik új kapcsolatokat nyitni arról a gépről az internet felé. Ezzel a megoldással NAT-tal ekvivalens működést valósítunk meg. Nagyon különleges, hogy a hálózati rétegek kapcsolata itt is fájl szintű, és transzparansen működik, így olyan a NAT-oló gépen kapcsolatot nyitni, mintha lokális gépen lenne. Ha például az interneten keresztül több gépet kapcsolunk össze a biztonságosá tett 9P protokolllal, és a /net fájlrendszereket Union fájlrendszerként összevonjuk, akkor VPN szerű működést valósítunk meg. A /proc fájlrendszer közösítésével elosztott számítási felhőt lehet létrehozni. A lehetőségek száma korlátlan.

4 Felhasználói felület

A unix-al ellentétben a Plan9 grafikus felületre van tervezve. Rendelkezik csak szöveges terminállal is, de a funkcionalitása lényegesen gyengébb. A grafikus felület a rio nevű ablakkezelőt használja. Az ablakok kezdetben az rc nevű shell-t futtatják, a később itt futtatott grafikus programok átveszik az ablakot.

rc

A Plan 9 parancssora, a UNIX 10-es verziójából származik. Hasonlít a bourne shellre, de egyszerűbb szintaxissal.

rio

A Plan 9 ablakkezelője. Jellegzetessége, az alkalmazások számára teljesen átlátszó. Minden ablak saját namespace-ben fut, és a rio és csak egy namespace-t kap az operációs rendszertől, így nincs akadálya, hogy rio-kat ágyazzunk egymásba. Mivel a 9P protokollt használja, hálózaton keresztül is teljesen átlátszóan működtethető. Az ablakok is szövegesek, és minden sorukba lehet írni.

plumb és plumber

A plumbing mechanizmus a Plan 9 rendszerben a processzek közti kommunikációban az üzenetek kezelését és továbbítását jelenti. Természetesen az üzenetek 9P formátumúak, így a plumber egy 9P fájlszerver. A szoftverek a plumb program segítségével üzennek a plumbernek, aki továbbítja az üzeneteket.

5 Felhasználói programok

Számos olyan programmal és parancssori elemmel rendelkezik, amikkel a UNIX is, grafikus felületén azonban egészen másképp működnek a dolgok. A rio sajátosságai miatt nagyon érdekes felhasználói szoftverek alakultak ki. A programok a 9P protokollon kommunikálnak, gombok nem léteznek, a menük csak szövegesek lehetnek, az ablakok minden részébe lehet írni. Ezek miatt egészen másképp működik egy ilyen rendszer, mint azt megszokhattuk.

sam

Egy többfájlos struktúrális regurális kifejezés alapú szövegszerkesztő program. Használata megköveteli az aktív háromgombos egérhasználatot. Rendelkezik egy egyszerű ám erőteljes, részben az ed nevű szövegszerkesztőtől örökölt parancsnyelvvel, ami nagyban épít a reguláris kifejezésekre.

acme

Egy szövegszerkesztő, egy fájlkezelő és egy ablakkezelő program együttvéve. A program ablakán belül egy belső ablakkezelő működik, és fájlrendszer és fájltartalom böngésző ablakokat lehet nyitni, és menedzselni őket. Ahogy a többi plan9 alkalmazás, ez is igényli a 3 gombos egér aktív használatát. Például a menügombok itt a középső gombbal működnek. Mivel azonban nincsenek felületi elemek, úgy van megoldva, hogy bármilyen futtatható kifejezésre lehet a középső gombbal kattintani, az le fog futni, akkor is ha egy fájl tartalma. A jobb gombbal pedig meg lehet nyitni egy fájlt, akkor is ha egy fájlban szerepelt a fájlnév, vagy akár bárhová leírtuk, hiszen bárhova lehet írni az ablakokban.

6 Tárolás

Fossil

A Plan9 fájlrendszere. Természtesen 9P protokollon keresztül lehet elérni a fájlrendszer tartalmát, és így a gépek számára átlátszó, hogy helyi vagy távoli tárat érnek el éppen. Emiatt a Fossil hálózati fájlrendszer(NAS). A fossil daemonként fut a user space-ben. A fájlrendszerben lehetséges pillanatképeket készíteni, és saját fájljaikról a felhasználók is készíthetnek snapshotot, és vissza is tölthetik azt.

Venti

A venti blokk alapú tárolórendszer a Plan 9 operációs rendszerhez. 160 bites SHA-1 hasheli a tartalmat blokkonként, és ez alapján helyezi el a táron. Ezzel csökkenti a töredezettséget, és a duplikációt is. Ha a Fossil fájlszintű rendszert a Venti blockszintű megoldása felett használjuk, akkor lehetőség nyílik permanens snapshotok készítésére. A venti nem 9P protokollon működik, hiszen az fájl alapú. Egy TCP alapú RPC megoldást használ, így a venti egy hálózati tárolórendszer(SAN).

replica

Egy 9P alapú adatreplikációs rendszer. A Fossil fájlrendszer logjai alapján képes szinkronba hozni a fájlrendszereket.