A Bell Labs az emberiség egyik legtermékenyebb kutatóintézete, amely több forradalmi technológiai újítást adott a világnak. Itt született meg a tranzisztor, a lézer, az információelmélet (Claude Shannon révén), a Unix operációs rendszer, a C programozási nyelv, valamint a DSL technológia, az adatmodemek és a digitális jelfeldolgozás alapjai is. Több kutatója – köztük Bardeen, Brattain, Shockley és Shannon – Nobel-díjat is kapott munkásságáért.
A Bell Labs a modern távközlés és számítástechnika fejlődésének egyik kulcsszereplője. Az 1980-as évek közepén a Bell Labs veterán fejlesztői – akik a Unixot és a C nyelvet is létrehozták – új vállalkozásba kezdtek: egy modern, hálózati működésre tervezett operációs rendszer kidolgozásába. Így született meg a Plan 9, amely a Unix alapelveit egy elosztott, gépek és szolgáltatások összekapcsolt világába ültette át. A most debütáló PingvinBázis blog első bejegyzésében a Plan9 from Bell Labs történetét tekintjük át, illetve beletekintünk egy mély technikai elemzés formájában a rendszer felépítésébe és működésébe is.
Tartalomjegyzék
A Plan 9 története
Út a kutatási platform létből az első kiadásig
A név – Plan 9 from Bell Labs – ironikus tisztelgés Ed Wood 1957-es Z-kategóriás sci-fi filmje, a Plan 9 from Outer Space előtt, ami már önmagában is utalt arra, hogy a rendszer egyfajta alternatív valóságot képvisel az operációs rendszerek világában.
A fejlesztés éveken át házon belül zajlott, a rendszer kizárólag a Bell Labs kutatóinak szolgálta az operációs rendszerek új modelljeinek kipróbálását és értékelését. Az első kiadás végül 1992-ben jelent meg, és csak egyetemek számára volt elérhető. A rendszer célja már ekkor is az volt, hogy a különböző gépek – CPU-szerverek, fájlszerverek és terminálok – egy közös, egységes rendszerré álljanak össze, ahol minden erőforrás fájlként érhető el, és a névterek tetszőlegesen alakíthatók.
A projekt élén olyan meghatározó és elismert szoftvermérnökök álltak, mint Rob Pike és Ken Thompson, míg Dennis Ritchie szakmai támogatása a háttérből erősítette a munkát. (Érdekesség, hogy Ken Thompson és Dennis Ritchie volt az akik megalkották 1969-ben a UNIX előfutárát a MULTICS-ot majd végül a UNIX operációs rendszert) Az eredmény egy formabontó rendszer lett, amely új szintre emelte a „minden komponens egy fájl” koncepcióját, mely megelőzte a korát, és több ma is használt technológiai alapelv megszületését inspirálta.
Kereskedelmi szárnybontogatások és annak korlátai
1995-ben a Plan9 második kiadását az AT&T már nemcsak egyetemeknek, hanem kereskedelmi célra is elérhetővé tette. A kiadást egy könyv formájában, a Harcourt Brace kiadó közreműködésével árusították, és a hozzáférés 350 dolláros forráskód előfizetéssel járt. A célcsoport elsősorban az ipari beágyazott rendszerek piaca volt, nem pedig az általános asztali vagy szerverpiac. Dennis Ritchie maga is elismerte, hogy nem vártak áttörést, mivel a kereskedelmi operációs rendszerek – különösen a Unix-származékok – már túlságosan elterjedtek voltak ahhoz, hogy a Plan 9 kiszorítsa őket.
Fejlesztési irányváltás és a hanyatlás kezdete
1996-ra a Plan 9 fejlesztése háttérbe szorult, mivel a Bell Labs az Inferno nevű rendszerre koncentrált, amelyet a Java platform vetélytársának szántak. A Plan 9 hivatalos kereskedelmi támogatása fokozatosan megszűnt, miután a Bell Labs új tulajdonosa, a Lucent Technologies, más prioritásokat jelölt ki. A projekt azonban nem halt el teljesen: 2000-ben megjelent a harmadik kiadás, ezúttal már nyílt forráskódú licenc alatt, amely lehetővé tette, hogy a fejlesztés közösségi alapon folytatódjon. 2002-ben megjelent a negyedik kiadás is, szintén szabad szoftveres licencelés mellett.
Az open source közösség mentette meg a rendszert a végső elmúlástól
A Plan9 hivatalos fejlesztése az évek során fokozatosan elcsendesült, de a közösség nem hagyta magára a rendszert. Korábbi és jelenlegi Bell Labs alkalmazottak, valamint független fejlesztők ISO lemezképek formájában napi frissítéseket kezdtek terjeszteni. A Bell Labs egészen 2015-ig biztosított hivatalos kiadást, ekkor jelent meg az utolsó stabil verzió. Bár ezután a Bell Labs más projektek felé fordult, a Plan 9 életben maradt a közösségi fejlesztések révén.
A 9front nevű közösségi fork különösen aktív maradt, havi frissítéseket és jelentős fejlesztéseket biztosítva, többek között Wi-Fi és USB támogatással, audio meghajtókkal, beépített játékemulátorral és új felhasználói programokkal. Emellett számos más Plan 9-alapú rendszer is megjelent, mint a Harvey OS, a Jehanne OS vagy az Inferno, amelyek különféle célokra és architektúrákra adaptálták az eredeti koncepciót.
A fordulópont 2021. március 23-án érkezett el, amikor a Bell Labs hivatalosan átadta a Plan9 projekt szerzői jogait a Plan9 Foundation nevű nonprofit szervezetnek. Ezzel párhuzamosan a teljes kódbázist MIT-licenc alá helyezték, ami az egyik legszabadabb és leginkább elfogadott open-source licenc. Ez a lépés új lendületet adott a fejlesztéseknek, hiszen a közösségi projektek immár jogilag is függetlenül és szabadon dolgozhatnak tovább a rendszer bővítésén, modernizálásán és alkalmazásán.
A Plan9 tervezési alapelvei: a fájlrendszer, mint univerzális interfész
Elosztott működés, névterek és az Üzenet-alapú fájlrendszer protokoll
A Plan 9 egyik központi célkitűzése az volt, hogy egy heterogén, földrajzilag is széttagolt számítógépes hálózat úgy viselkedjen, mintha egyetlen koherens rendszer lenne. Ehhez minden komponens – a termináloktól a fájlszervereken át a számítási csomópontokig – egy egységes névtérbe illeszkedik. A rendszer két pillérre épül: az egyik az egyedi, folyamatonkénti névtér (namespace), a másik egy üzenet-alapú fájlrendszer-protokoll.
A folyamatonkénti névtér azt jelenti, hogy minden futó program saját fájlrendszer-térképet kap, amelyet a felhasználó vagy a rendszer dinamikusan építhet fel. Ugyanaz az útvonal így más-más erőforrást jelenthet különböző programok számára. Ez lehetővé teszi, hogy minden program a számára szükséges környezettel dolgozzon, miközben a globális rendszer integritása megmarad. A szabványos helyek és a névterek kötési műveletei (bind) révén ez a rugalmasság jól kezelhető.
A másik alapelv, az üzenet-alapú fájlrendszer lehetővé teszi, hogy programok saját „virtuális fájlokat” szolgáltassanak más programoknak, ezáltal a fájlművelet maga válik kommunikációs csatornává. A rendszer minden erőforrást fájlokként jelenít meg: a perifériákat, hálózati kapcsolatokat, vagy akár ablakkezelőket. A hagyományos API-k (mint a sockets, ioctl) helyett minden eszközzel a fájlműveleteken – például read, write, open – keresztül lehet kommunikálni. Ehhez egy egységes protokollt, a 9P-t használják, amely a fájl-alapú szolgáltatások mögötti üzenetküldést szabályozza. A protokoll továbbfejlesztett változata 9P2000 néven ismert.
A grafikus felület mint fájlrendszer
A Plan9 ablakkezelői, például az eredeti 8½, a rendszer filozófiáját követve szintén fájlokon keresztül kommunikálnak. Egy terminál három fő álfájllal rendelkezik: mouse (az egér eseményei), cons (szöveges bemenet és kimenet), valamint bitblt (grafikai műveletek). Az ablakkezelő új névteret hoz létre minden ablak számára, ezek a fájlok így az ablakon belül a program számára elérhetőek, a háttérben pedig az ablakkezelő multiplexálja és továbbítja őket a fizikai eszközökhöz.
Elosztott végrehajtás, union könyvtárak
A Plan9 egyik legérdekesebb képessége az elosztott végrehajtás, amelyet a cpu parancs tesz lehetővé. Ennek segítségével a felhasználó egy távoli szerveren futtatott programot úgy indíthat el, hogy az képes legyen hozzáférni a helyi terminál erőforrásaihoz. A rendszer a felhasználó aktuális névterének egy részét exportálja a távoli gépre, így az ott futó alkalmazások elérhetik az egér, a billentyűzet és a kijelző funkcióit. Ez a megoldás egyesíti a távoli bejelentkezés és a fájlrendszer-szintű integráció előnyeit, lehetővé téve egy egységes felhasználói élményt elosztott környezetben.
A Plan9 egy másik fontos újítása az úgynevezett union könyvtárak használata. Ez a mechanizmus lehetővé teszi több különálló könyvtár tartalmának logikai egyesítését egy közös, egységes névtérbe. Az így létrejövő struktúrában a fájlkeresés sorrendje meghatározható, így a felhasználó pontos kontrollt gyakorolhat a névütközések feloldása felett. Ez a modell lényegében kiváltja a Unix rendszerekben megszokott $PATH környezeti változót, mivel az elérhető programokat egyszerűen egymás alá lehet „kötni” a /bin könyvtárban. A rendszer támogatja a per-process névtereket és a külön mount táblákat is, így minden folyamat saját, izolált fájlrendszerrel dolgozhat – hasonlóan a chroot-hoz, de annál lényegesen rugalmasabb módon.
Virtuális fájlrendszerek, kódolás és fejlesztői környezet
A Plan9 a hagyományos rendszerhívások helyett fájlrendszer-alapú interfészeket használ a legtöbb rendszerfunkció eléréséhez. A folyamatkezelés a /proc könyvtáron keresztül történik, ahol minden futó folyamat egy-egy mappaként jelenik meg, és azok tartalmán keresztül lekérdezhetők vagy vezérelhetők. A hálózati kommunikáció szintén fájlműveleteken alapul: a /net alá szervezett fájlstruktúrában például a TCP kapcsolatok létrehozása és kezelése olvasással és írással történik.
A karakterkódolás egységesítésére a rendszer teljes egészében Unicode-ot alkalmaz. A Plan9 környezetében fejlesztették ki az UTF-8 kódolást, amely visszafelé kompatibilis a C nyelv null-terminált karakterláncaival, és lehetővé teszi többnyelvű karakterláncok megbízható láncolását és feldolgozását. Ez az egységes kódolási séma kiküszöböli a karakterkód-váltogatásból eredő problémákat, és a rendszer egészében leegyszerűsíti a szövegkezelést.
A Plan9 igazi ereje azonban akkor válik nyilvánvalóvá, amikor az említett architekturális elveket együtt használjuk. Egy NAT szerver például képes lehet a saját /net fájlrendszerét egyesíteni egy routerével, egy VPN-t például a távoli /net könyvtár saját névterébe való beillesztésével (bind) valósíthatunk meg. Hasonló módon, több távoli gép /proc fájlrendszerének egyesítésével egy olyan hálózat építhető, ahol a különálló csomópontok úgy kezelhetők, mintha helyi folyamatok lennének.
A fejlesztői eszközkészlet minimalista, de következetes. Az alapműveleteket – fájlmásolás, szövegkeresés, törlés – az egyszerű szintaxisú rc shell biztosítja. A hitelesítést a factotum szolgáltatás végzi, amely központosítja a kulcskezelést és az azonosítást. A grafikus környezetet a rio ablakkezelő biztosítja, amelyben minden ablak egy-egy shellt vagy grafikus programot futtat. A sam és acme szövegszerkesztők egyszerre támogatják az interaktív és scriptelhető munkavégzést.
A fájlrendszerek között a Fossil nyújt snapshot-alapú mentést, amely a Venti nevű archiváló rendszerrel is integrálható. A fordítókészlet a Plan9 saját C-dialektusát támogatja, amely gyors fordításra és egyszerű kódszerkezetre optimalizált. A rendszer korai verzióiban még szerepelt az Alef nevű párhuzamos nyelv, amelyet később egy szálkezelő C-könyvtár váltott fel.
Unix és Linux kompatibilitás
Bár a Plan9 a Unix koncepcióinak továbbfejlesztésére épült, nem célja a kompatibilitás. Sok program neve ismerős lehet Unix környezetből, de működésük eltér. A POSIX-kompatibilitást az APE (ANSI/POSIX Environment) biztosítja, amely egy saját környezetet ad a szabványos C-programok fordításához és futtatásához.
A Plan9 from Bell Labs operációs rendszer technológiai alapjai jelentősen különböznek a Unix és Linux rendszerekben megszokottaktól, így a rá írt natív alkalmazások közvetlen futtatása Linux alatt nem lehetséges. Ez elsősorban annak tudható be, hogy a Plan 9 saját rendszerhívásokat, saját bináris formátumot és eszközkezelést használ, amelyek nem kompatibilisek a Linux kernel által biztosított POSIX-környezetekkel. Azonban a közösség több olyan megoldást is kidolgozott, amelyek lehetővé teszik a Plan 9 szoftveres környezet részleges vagy akár kiterjesztett használatát Linuxon – forrásból történő portolással, emulációval vagy éppen a rendszer komponenseinek integrációjával.
Az egyik legismertebb és legaktívabb ilyen projekt a Plan 9 from User Space, röviden plan9port. Ez a kezdeményezés a Plan 9 eszközeinek és filozófiájának Unix-szerű rendszerekre történő áthozását célozza meg. A plan9port keretében például a Plan 9 ikonikus fejlesztőeszközei – köztük az acme és sam szövegszerkesztők, az rc shell, valamint az auth és plumber szolgáltatások – Linuxra portolt változatban is elérhetők. Ezek az alkalmazások a Linux X11 ablakkezelő rendszerét használják, de felépítésükben és működésükben a Plan 9 eredeti logikáját követik, így például a fájlrendszer-alapú kommunikációs mechanizmusokat, vagy az input/output kezelés módját.
Fontos, hogy a Plan 9 alkalmazások szintaxisa és viselkedése több esetben is eltér a Linuxos megfelelőiktől – például a Plan 9-féle grep vagy sed más reguláris kifejezési szabályokat alkalmaz. Ezért a plan9port telepítésekor ajánlott az eszközök külön elérési úton (például $PLAN9/bin) való használata, hogy ne írják felül a rendszer szintű parancsokat.
Egy radikálisabb próbálkozás volt a Glendix projekt, amely a Plan 9 bináris alkalmazásait próbálta közvetlenül Linux kernel alatt futtatni. Ennek megvalósítása során a fejlesztők a Plan 9 rendszerhívásait beépítették a Linux kernelbe, és egy speciális build-rendszert alakítottak ki, amely képes volt a Plan 9-es formátumú futtatható állományokat kezelni. Bár a projekt prototípus szinten működött, és számos Plan 9 program valóban futtathatóvá vált, sosem vált széles körben használt megoldássá. Ugyanakkor demonstrálta, hogy a két rendszer közötti bináris kompatibilitás elméletileg megvalósítható.
Egy további kísérleti megközelítést jelentett a 9vx, amely egy módosított Plan 9 kernelt futtatott egy Vx32 nevű, felhasználói szintű virtuális gépben Linux alatt. Ez a megoldás anélkül tette lehetővé Plan 9 alkalmazások futtatását, hogy kernelmódosításra lett volna szükség, és lényegében egy sandbox-szerű környezetet biztosított a Plan 9 programok számára. A 9vx révén akár egy teljes Plan 9 asztali környezet is futtatható volt egy Linux ablakban, így lehetőséget nyújtott a két operációs rendszer natív programjainak egyidejű használatára ugyanazon gépen belül.
Noha ezek a projektek ma már jellemzően inaktívak vagy csak részlegesen karbantartottak, a plan9port továbbra is fejlesztés alatt áll, és az egyik legpraktikusabb módja annak, hogy a Plan 9 eszközeit használhassuk egy Linux környezetben. A portolt eszközök nemcsak technikai értelemben működnek jól, hanem a Plan 9 filozófiáját – az egyszerű, fájlalapú, moduláris működést – is elérhetővé teszik azok számára, akik a megszokott Unix modellel szemben egy alternatív szemléletre kíváncsiak.
Összességében elmondható, hogy bár a natív Plan 9 binárisok közvetlen futtatása Linux alatt nem triviális feladat, a különféle technikák és portolási megoldások révén a két világ közötti átjárás – legalábbis funkcionális szinten – megvalósítható. A plan9port az egyik legkézenfekvőbb út, ha valaki szeretné kipróbálni a Plan 9 fejlesztői eszközeit Linux alatt, míg a Glendix és 9vx történelmi szinten fontos példák arra, hogy milyen mélységig lehetett a két rendszer technikai világát összekapcsolni.
Miért nem terjedt el soha a Plan9 az iparágban?
A Plan 9 from Bell Labs elterjedésének fő akadálya éppen az volt, hogy túlságosan megelőzte a korát, amelybe érkezett. A 80-as évek végén és a 90-es évek elején, amikor a Plan 9 fejlesztése zajlott, az iparági fókusz elsősorban a meglévő Unix-származékok és a feltörekvő Windows rendszerek stabilizálására és piacosítására irányult. A szoftverfejlesztés ekkor még erősen a monolitikus rendszerek, hagyományos fájlrendszerek és szabványos POSIX-API köré épült, és az új típusú szemlélet – mint amilyet a Plan 9 képviselt – nem illett bele a megszokott gyakorlatokba.
A Plan 9 által felvetett innovatív megoldások különösen rugalmasak és elegánsak voltak, de a fejlesztőknek teljesen új módon kellett gondolkodniuk: az operációs rendszer használata, a programozás, a hibakeresés, sőt még a szövegfeldolgozás is eltért a megszokottól.
A probléma az volt, hogy a Plan 9 ökoszisztémája nem volt kompatibilis a már széles körben elterjedt Unix- és Linux-eszközökkel, szoftverekkel és fejlesztői módszertanokkal. Hiányzott belőle a POSIX-kompatibilitás (Mely egyébként szándékos fejlesztői lépés volt), a meglévő Unix szoftverek nem futottak rajta módosítás nélkül, és a rendszer saját fejlesztőeszközöket és build-mechanizmusokat követelt. Ez azt eredményezte, hogy bár technikailag sok szempontból előrébb járt, a gyakorlati alkalmazhatóság szűk körű maradt.
Az ipari környezet sem mutatott komoly érdeklődést, mivel az új architektúra elsajátítása és integrálása komoly képzési és portolási ráfordítást igényelt volna – mindezt egy olyan időszakban, amikor a Linux éppen felfutóban volt, és az x86 architektúrán stabil, POSIX-alapú környezetet kínált egyre bővülő driver- és szoftvertámogatással. A Plan 9 ehhez képest egy viszonylag szűk hardverkört támogatott, és nem rendelkezett kereskedelmi háttérrel vagy marketinggépezettel.
Így a Plan 9 története egy klasszikus példája lett annak, amikor egy technológia túl előremutató a saját korához képest. A rendszer nem vált széles körben elterjedtté, de későbbi fejlesztéseket mélyen inspirált – ilyen például a Linux namespace modellje, a Windows Subsystem for Linux fájlmegosztási mechanizmusa (9P), vagy maga az UTF-8 karakterkódolás. Bár nem hódította meg a piacot, a kutatási közösségben és a unix-szerű rendszerek rajongói körében kultikus státuszt vívott ki magának.
Összességében a Plan 9 technikai koncepciói – az egységes fájlalapú interfész, az elosztott névterek és a 9P protokoll – nemcsak a saját működését határozták meg, hanem hatást gyakoroltak más operációs rendszerekre is. A Linux átvette a 9P2000 protokollt, az UTF-8 pedig mára a világ egyik legelterjedtebb karakterkódolási szabványává vált. Noha a Plan 9 sosem lett mainstream termék, technológiai tisztasága és következetes tervezése révén máig elismerés övezi.
A cikkben leírt technikai információk forrását a „Architectural overview of Plan 9” című kiadvány és 9p.io weboldal adta
