Plán 9 od Bell Labs - Plan 9 from Bell Labs

Plán 9 od Bell Labs

Glenda, maskot Plan 9, nakreslený Renée French
Instalace plánu 9
Vývojář	Plan 9 Foundation, nástupce Bell Labs
Napsáno	Dialekt ANSI C
Pracovní stav	Proud
Zdrojový model	Otevřený zdroj
První vydání	1992 ; Před 29 lety (univerzity) /  ( 1992 ) 1995 ; Před 26 lety (široká veřejnost) ( 1995 )
Konečné vydání	Čtvrté vydání / 10. ledna 2015 ; před 6 lety ( 2015-01-10 )
Úložiště	9p .io /zdroje /plán9 /sys /src /
Marketingový cíl	Výzkum operačních systémů, síťová prostředí, obecné použití
K dispozici v	Angličtina
Metoda aktualizace	replika
Platformy	x86 / Vx32 , x86-64 , MIPS , DEC Alpha , SPARC , PowerPC , ARM
Typ jádra	Monolitické
Ovlivněn	Výzkum Unix , Cambridge Distributed Computing System
Výchozí uživatelské rozhraní	rio / rc
Licence	2021: MIT 2014: pouze GPL-2.0 2002: LPL-1.02 2000: Plan 9 OSL
Uspěl	Inferno Jiné deriváty a vidlice
Oficiální webové stránky	p9f .org

Plan 9 from Bell Labs je distribuovaný operační systém , který pochází z Výzkumného centra Computing Science (CSRC) v Bell Labs v polovině 80. let minulého století a vychází z konceptů UNIX, které zde byly poprvé vyvinuty na konci 60. let minulého století. Od roku 2000 je Plan 9 zdarma a open-source . Konečné oficiální vydání bylo na začátku roku 2015.

Pod Plan 9, Unix má všechno je soubor metafora je prodloužena přes všudypřítomné sítě-centric souborového systému , a kurzor adresou , terminál na bázi I / O v srdci UNIX-like operační systémy nahrazuje okenního systému a grafickým uživatelským rozhraní bez adresování kurzoru, přestože rc , shell Plan 9 , je textový.

Název Plan 9 od Bell Labs je odkazem na kultovní Z-film sci-fi Ed Wood z roku 1959 Plán 9 z vesmíru . (Název maskota projektu „Glenda, králíček z plánu 9“ je pravděpodobně odkazem na Woodův film Glen nebo Glenda .) Systém nadále používají a vyvíjejí výzkumníci a fandové operačních systémů.

Dějiny

Plan 9 from Bell Labs byl původně vyvinut, začínat v pozdní 1980, členové Computing Science Research Center v Bell Labs, stejné skupině, která původně vyvinut Unix a C programovací jazyk . Tým Plan 9 původně vedl Rob Pike , Ken Thompson , Dave Presotto a Phil Winterbottom s podporou Dennise Ritchieho jako vedoucího oddělení výzkumu výpočetních technik. V průběhu let se na projektu podílelo mnoho pozoruhodných vývojářů, včetně Briana Kernighana , Toma Duffa , Doug McIlroy , Bjarne Stroustrup a Bruce Ellis .

Plán 9 nahradil Unix jako primární platformu Bell Labs pro výzkum operačních systémů. Prozkoumala několik změn původního unixového modelu, které usnadňují používání a programování systému, zejména v distribuovaných prostředích pro více uživatelů . Po několika letech vývoje a interního používání společnost Bell Labs dodala operační systém univerzitám v roce 1992. O tři roky později byl plán 9 zpřístupněn pro komerční strany společností AT&T prostřednictvím vydavatele knih Harcourt Brace . Se zdrojovými licencemi v ceně 350 $ se AT&T zaměřila spíše na trh s vestavěnými systémy než na počítačový trh jako celek. Ritchie poznamenal, že vývojáři neočekávali „velký posun“ vzhledem k tomu, jak se staly zavedenými jinými operačními systémy.

Na začátku roku 1996 se projekt Plan 9 byl „dát na zadní hořák“ od AT & T ve prospěch Inferno , zamýšlel být konkurentem Sun Microsystems ' platformě Java . Na konci devadesátých let nový majitel společnosti Bell Labs Lucent Technologies upustil od komerční podpory projektu a v roce 2000 bylo třetí vydání distribuováno pod licencí open-source . Čtvrté vydání na základě nové licence svobodného softwaru proběhlo v roce 2002.

Uživatelská a vývojová komunita, včetně současných i bývalých zaměstnanců Bell Labs , produkovala menší denní vydání ve formě obrazů ISO . Vývoj byl hostitelem Bell Labs. Strom vývojových zdrojů je přístupný přes protokoly 9P a HTTP a slouží k aktualizaci stávajících instalací. Kromě oficiálních komponent operačního systému obsažených v ISO, Bell Labs také hostí úložiště externě vyvinutých aplikací a nástrojů.

Jak se Bell Labs v posledních letech přesunulo k pozdějším projektům, vývoj oficiálního systému Plan 9 se zastavil. 23. března 2021 se vývoj obnovil po převodu autorských práv z Bell Labs na Nadaci Plan 9. Neoficiální vývoj systému pokračuje i na 9front Forku, kde aktivní přispěvatelé poskytují měsíční sestavení a nové funkce. Vidlice 9front dosud poskytovala systému ovladače Wi-Fi, ovladače zvuku, podporu USB a vestavěný emulátor hry spolu s dalšími funkcemi. Mezi další nedávné operační systémy inspirované Plan 9 patří Harvey OS a Jehanne OS.

datum	Uvolnění	Komentář
1992	Plán 9, 1. vydání	Vydáno Bell Labs na univerzity
1995	Plán 9, 2. vydání	Vydáno společností Bell Labs pro nekomerční účely
2000	Plán 9, 3. vyd. ( Brazílie )	Vydáno společností Lucent Technologies pod licencí open source
2002	Plán 9, 4. vydání	Vydáno společností Lucent Technologies na základě nové bezplatné licence softwaru

Koncepty designu

Plan 9 je distribuovaný operační systém navržený tak, aby síť heterogenních a geograficky oddělených počítačů fungovala jako jeden systém. Při typické instalaci Plan 9 uživatelé pracují na terminálech se systémem rio okenního systému a přistupují k serverům CPU, které zpracovávají procesy náročné na výpočet. Trvalé ukládání dat zajišťují další síťoví hostitelé fungující jako souborové servery a archivní úložiště.

Jeho designéři tvrdí, že

Základy systému jsou postaveny na dvou myšlenkách: prostoru názvů pro proces a jednoduchém protokolu systému souborů orientovaném na zprávy.

-  Pike a kol.

První myšlenka (prostor názvů jednotlivých procesů) znamená, že na rozdíl od většiny operačních systémů mají procesy (spuštěné programy) každý svůj vlastní pohled na obor názvů , což odpovídá tomu, co ostatní operační systémy nazývají souborový systém; jeden název cesty může odkazovat na různé prostředky pro různé procesy. Potenciální složitost tohoto nastavení je řízena sadou konvenčních umístění pro společné zdroje.

Druhá myšlenka (souborový systém orientovaný na zprávy) znamená, že procesy mohou nabízet své služby jiným procesům poskytováním virtuálních souborů, které se objevují v oboru názvů ostatních procesů. Na klienta Proces je vstup / výstup na takovém souboru se stane inter-proces komunikace mezi dvěma procesy. Plán 9 tímto způsobem zobecňuje unixový pojem souborového systému jako ústředního bodu přístupu k výpočetním prostředkům. Přenáší myšlenku Unixu na soubory zařízení zajišťující přístup k periferním zařízením ( myši , vyměnitelná média atd.) A možnost připojit souborové systémy umístěné na fyzicky odlišných souborových systémech do hierarchického prostoru jmen, ale přidává možnost připojit připojení k serveru program, který mluví standardizovaným protokolem a považuje své služby za součást oboru názvů.

Například původní okenní systém s názvem 8½ využil tyto možnosti následujícím způsobem. Plán 9 představuje uživatelské rozhraní na terminálu pomocí tří pseudosouborů: myš , kterou je možné přečíst v programu pro upozornění na pohyby myši a kliknutí na tlačítka, nevýhody , které lze použít k provádění textového vstupu/výstupu, a bitblt , do kterého se zapisují grafické operace (viz bit blit ). Okenní systém tato zařízení multiplexuje: při vytváření nového okna, ve kterém se má spouštět nějaký program, nejprve nastaví nový obor názvů, ve kterém jsou myši , nevýhody a bitblt propojeny samy se sebou, přičemž skrývají skutečné soubory zařízení, ke kterým má sám přístup. Okenní systém tak přijímá všechny vstupní a výstupní příkazy z programu a zpracovává je odpovídajícím způsobem, a to odesláním výstupu na skutečné zařízení s obrazovkou a aktuálně zaměřenému programu dává vstup z klávesnice a myši. Program nemusí vědět, zda komunikuje přímo s ovladači zařízení operačního systému nebo s okenním systémem; pouze musí předpokládat, že jeho obor názvů je nastaven tak, aby tyto speciální soubory poskytovaly druh vstupu a přijímaly druhy zpráv, které očekává.

Distribuovaná operace Plan 9 se spoléhá také na obory názvů jednotlivých procesů, což umožňuje klientským a serverovým procesům komunikovat mezi počítači způsobem, který byl právě naznačen. Například příkaz cpu spustí vzdálenou relaci na výpočetním serveru. Příkaz exportuje část svého místního oboru názvů, včetně zařízení uživatelského terminálu ( myš , nevýhody , bitblt ), na server, takže vzdálené programy mohou provádět vstup/výstup pomocí myši, klávesnice a displeje terminálu, což kombinuje efekty vzdáleného přihlášení a sdílený síťový souborový systém.

Protokol 9P

Všechny programy, které chtějí poskytovat služby jako soubory jiným programům, hovoří jednotným protokolem s názvem 9P. Ve srovnání s jinými systémy to snižuje počet vlastních programovacích rozhraní . 9P je obecný, středně agnostický protokol orientovaný na bajty, který zajišťuje zprávy doručované mezi serverem a klientem. Protokol se používá k odkazování na procesy, programy a data a ke komunikaci s nimi, včetně uživatelského rozhraní a sítě. S vydáním 4. vydání byl upraven a přejmenován na 9P2000.

Na rozdíl od většiny ostatních operačních systémů Plan 9 neposkytuje pro přístup k zařízením speciální rozhraní pro programování aplikací (jako jsou zásuvky Berkeley , prostředky X nebo systémová volání ioctl ). Místo toho, řidiči Plan 9 zařízení provádět své řídicí rozhraní jako souborový systém, takže hardware lze přistupovat pomocí běžného souboru vstupně / výstupních operací čtení a zápisu . Sdílení zařízení v síti lze tedy provést připojením příslušného stromu adresářů k cílovému počítači.

Union adresáře a jmenné prostory

Plán 9 umožňuje uživateli shromažďovat soubory (nazývané názvy ) z různých stromů adresářů na jednom místě. Výsledný sjednocený adresář se chová jako zřetězení podkladových adresářů (pořadí zřetězení lze řídit); pokud složkové adresáře obsahují soubory se stejným názvem, výpis sjednocovacího adresáře ( ls nebo lc ) jednoduše nahlásí duplicitní názvy. Řešení názvu jedné cesty se provádí shora dolů: pokud jsou adresáře nahoře a dole spojeny do u s nahoře , pak u/name označuje top/name, pokud existuje, dole/název pouze pokud existuje a top/název ano neexistuje a neexistuje žádný soubor, pokud žádný neexistuje. Neprovádí se rekurzivní sjednocení podadresářů, takže pokud existuje horní/podadresář , soubory ve spodním/podadresáři nejsou prostřednictvím sjednocení přístupné.

Sdružený adresář lze vytvořit pomocí příkazu bind :

; bind /arm/bin /bin
; bind -a /acme/bin/arm /bin
; bind -b /usr/alice/bin /bin

Ve výše uvedeném příkladu je /arm /bin namontován na /bin , obsah /arm /bin nahrazuje předchozí obsah /bin . Acme ‚s bin adresáře je pak union namontován po / bin , a Alicin osobní bin adresáře union namontována předtím. Když je soubor požadován z /bin , je nejprve vyhledán v /usr/alice/bin , pak v /arm/bin a nakonec v /acme/bin/arm .

Samostatné obory názvů procesů tak obvykle nahrazují pojem vyhledávací cesty v shellu. Proměnná prostředí cesty ( $path) stále existuje v rc shellu (shell používaný hlavně v Plan 9); Nicméně, cesta proměnná prostředí RC je běžně obsahuje pouze /bina .adresářů a úpravě proměnnou je znechucený, namísto toho, přidávat další příkazy by mělo být provedeno vazbou několik adresářů dohromady jako jeden /bin. Na rozdíl od plánu 9 by proměnná prostředí cesty unixových prostředí měla být nastavena tak, aby zahrnovala další adresáře, jejichž spustitelné soubory je třeba přidat jako příkazy.

Kromě toho může jádro uchovávat oddělené připojovací tabulky pro každý proces, a proto může každému procesu poskytnout vlastní obor názvů systému souborů . Obory názvů procesů mohou být konstruovány nezávisle a uživatel může pracovat současně s programy, které mají heterogenní obory názvů. Jmenné prostory mohou být použity k vytvoření izolovaného prostředí podobného chrootu , ale bezpečnějším způsobem.

Architektura sjednocovacího adresáře Plan 9 inspirovala implementace souborových systémů 4.4BSD a Linux , přestože vývojáři zařízení pro montáž odborů BSD shledali, že rekurzivní sloučení adresářů v Plánu 9 je „příliš omezující pro obecné použití“.

Speciální virtuální souborový systém

/proc

Místo systémových volání specificky pro správu procesů poskytuje Plan 9 systém souborů /proc . Každý proces se zobrazí jako adresář obsahující informační a řídicí soubory, s nimiž lze manipulovat běžnými systémovými voláním IO souboru.

Přístup k systému souborů umožňuje správu procesů Plan 9 pomocí jednoduchých nástrojů pro správu souborů, jako jsou ls a cat ; procesy však nelze kopírovat a přesouvat jako soubory.

/síť

Plán 9 nemá specializovaná systémová volání nebo ioctly pro přístup k síťovému zásobníku nebo síťovému hardwaru. Místo toho se používá souborový systém /net . Síťová připojení jsou řízena čtením a zapisováním řídicích zpráv do řídicích souborů. Jako rozhraní k jejich příslušným protokolům se používají podadresáře jako /net /tcp a /net /udp .

Unicode

Aby se snížila složitost správy kódování znaků , Plan 9 používá Unicode v celém systému. Počáteční implementace Unicode byla ISO/IEC 10646-1: 1993 . Ken Thompson vynalezl UTF-8, který se stal nativním kódováním v Plánu 9. Celý systém byl převeden na obecné použití v roce 1992. UTF-8 zachovává zpětnou kompatibilitu s tradičními řetězci zakončenými nulou , což umožňuje spolehlivější zpracování informací a řetězení vícejazyčných řetězec dat s unixovými kanály mezi více procesy. Použití jediného kódování UTF-8 se znaky pro všechny kultury a oblasti eliminuje potřebu přepínání mezi sadami kódů.

Kombinace konceptů designu

Ačkoli byly koncepce návrhu Plan 9 samy o sobě zajímavé, měly být v kombinaci nejužitečnější. Například pro implementaci serveru pro překlad síťových adres (NAT) lze vytvořit sjednocený adresář překrývající strom adresářů routeru s /net s vlastním /net . Podobně lze virtuální privátní síť (VPN) implementovat překrytím v hierarchii adresářů a /net ze vzdálené brány pomocí zabezpečeného 9P přes veřejný internet. Sdružený adresář s hierarchií /net a filtry lze použít k sandboxu nedůvěryhodné aplikace nebo k implementaci brány firewall . Stejným způsobem může být distribuovaná počítačová síť složena se sjednocovacím adresářem /proc hierarchií ze vzdálených hostitelů, což umožňuje interakci s nimi, jako by byly místní.

Při společném použití tyto funkce umožňují sestavení komplexního distribuovaného výpočetního prostředí opětovným použitím stávajícího hierarchického systému jmen.

Software pro plán 9

Výhodou systému je, že většinu úkolů v plánu 9 lze provést pomocí nástrojů ls , cat , grep , cp a rm v kombinaci s rc shellem (výchozí prostředí Plan 9).

Factotum je server pro autentizaci a správu klíčů pro plán 9. Zpracovává autentizaci jménem jiných programů, takže tajné klíče a podrobnosti implementace musí znát pouze Factotum.

Grafické programy

Na rozdíl od Unixu byl Plan 9 navržen s ohledem na grafiku. Po spuštění spustí terminál Plan 9 rio okenní systém, ve kterém může uživatel vytvářet nová okna zobrazující rc . Grafické programy vyvolané z tohoto shellu jej nahradí v jeho okně.

Instalatér poskytuje komunikaci mezi procesy mechanismus, který umožňuje celý systém hyperlinking.

Sam a acme jsou textové editory Plan 9.

Úložný systém

Plán 9 podporuje souborové systémy Kfs, Paq, Cwfs, FAT a Fossil . Poslední byl navržen v Bell Labs speciálně pro plán 9 a poskytuje možnost ukládání snímků. Lze jej použít přímo na pevném disku nebo zálohovat pomocí systému Venti , archivačního systému souborů a systému trvalého ukládání dat.

Vývoj softwaru

Distribuční balíček pro Plán 9 obsahuje speciální varianty kompilátoru a programovací jazyky a poskytuje přizpůsobenou sadu knihoven spolu se systémem uživatelského rozhraní s okny specifickým pro Plán 9. Převážná část systému je napsána dialektem C ( ANSI C s některými rozšíření a některé další funkce vynechány). Kompilátory pro tento jazyk byly vytvořeny na zakázku s ohledem na přenositelnost; podle jejich autora „rychle kompilují, načítají pomalu a vytvářejí středně kvalitní objektový kód“.

V prvních dvou edicích byl k dispozici souběžný programovací jazyk s názvem Alef , ale poté byl z důvodů údržby zrušen a nahrazen knihovnou vláken pro C.

Kompatibilita s Unixem

Ačkoli plán 9 měl být dalším vývojem unixových konceptů, kompatibilita s již existujícím unixovým softwarem nebyla nikdy cílem projektu. Mnoho nástrojů příkazového řádku plánu 9 sdílí názvy unixových protějšků, ale fungují jinak.

Plan 9 může podporovat aplikace POSIX a může emulovat rozhraní soketu Berkeley prostřednictvím prostředí ANSI/POSIX Environment (APE), které implementuje rozhraní blízké ANSI C a POSIX , s některými běžnými rozšířeními (nativní rozhraní Plan 9 C nevyhovuje ani jednomu standardu). Obsahuje také shell kompatibilní s POSIX. Autoři APE tvrdí, že jej použili k přenesení systému X Window System (X11) do plánu 9, ačkoli X11 neposílají, „protože jeho správná podpora je příliš velká práce“. Některé binární soubory Linuxu lze použít s pomocí aplikace „linuxemu“ (emulátor Linuxu); je to však stále nedokončená práce. Naopak, virtuální stroj vx32 umožňuje mírně upravenému jádru Plan 9 běžet jako uživatelský proces v Linuxu a podporuje nemodifikované programy Plan 9.

Recepce

Srovnání se současnými operačními systémy

V roce 1991 návrháři Plan 9 porovnali svůj systém s jinými operačními systémy z počátku devadesátých let, pokud jde o velikost, což ukazuje, že zdrojový kód pro minimální („pracovní, i když ne příliš užitečnou“) verzi byl menší než jedna pětina velikosti Machu mikrokernel bez ovladačů zařízení (5899 nebo 4622 řádků kódu pro plán 9, v závislosti na metrice, vs. 25530 řádků). Kompletní jádro obsahovalo 18 000 řádků kódu. (Podle počtu z roku 2006 bylo jádro asi 150 000 řádků, ale to bylo porovnáno s více než 4,8 miliony v Linuxu .)

V rámci komunity výzkumů operačních systémů a komerčního světa Unix byly další pokusy o dosažení distribuovaných počítačů a vzdáleného přístupu k souborovému systému provedeny souběžně s návrhovým úsilím Plan 9. Patřil mezi ně Network File System a související vnode architektura vyvinutá ve společnosti Sun Microsystems a radikálnější odklony od unixového modelu, jako je Sprite OS od UC Berkeley . Vývojář Sprite Brent Welch poukazuje na to, že architektura SunOS vnode je ve srovnání s možnostmi Plan 9 omezená v tom, že nepodporuje vzdálený přístup k zařízení a vzdálenou meziprocesovou komunikaci čistě, i když to mohla mít, již existující sokety domény UNIX (které " lze v zásadě použít k pojmenování serverů na úrovni uživatelů “) byly integrovány s architekturou vnode.

Jedna kritika návrhu „vše je soubor“, komunikace podle textu v Plánu 9, poukázala na omezení tohoto paradigmatu ve srovnání s typovanými rozhraními objektově orientovaného operačního systému Sun , Spring :

Plán 9 omezuje, aby vše vypadalo jako soubor. Ve většině případů obsahuje skutečný typ rozhraní protokol zpráv, které musí být zapsány do deskriptoru souboru a z něho číst. To je obtížné specifikovat a dokumentovat a zakazuje to jakoukoli automatickou kontrolu typu , kromě chyb souboru za běhu. (...) [A] název cesty vzhledem k kontextu implicitního kořenového adresáře procesu je jediným způsobem, jak pojmenovat službu. Vázání názvu na objekt lze provést pouze zadáním existujícího názvu objektu ve stejném kontextu jako nový název. Odkazy na rozhraní jako takové jednoduše nelze předávat mezi procesy, tím méně mezi sítěmi. Komunikace se místo toho musí spoléhat na konvence, které jsou náchylné k chybám a nemají měřítko.

-  Roscoe; důraz v originále.

Pozdější retrospektivní srovnání Plan 9, Sprite a třetího současného distribuovaného operačního operačního systému výzkumu, Amoeba , to zjistilo

prostředí, která [Amoeba a Sprite] vytvářejí, jsou v operačním systému pevně propojena, což ztěžuje komunikaci s externími službami. Takové systémy trpí radikálním odklonem od modelu UNIX, který také odrazuje od přenositelnosti již existujícího softwaru na platformu (...). Nedostatek vývojářů, velmi malý rozsah podporovaného hardwaru a malá, dokonce ve srovnání s plánem 9, uživatelská základna také výrazně zpomalily přijetí těchto systémů (...). Při zpětném pohledu byl Plan 9 od té doby jediným distribuovaným operačním systémem pro výzkum, který dokázal přilákat vývojáře a být používán v komerčních projektech dostatečně dlouho, aby to zaručilo jeho přežití dodnes.

-  Mirtchovski, Simmonds a Minnich

Dopad

Plán 9 ukázal, že integrální koncept Unixu - že každé systémové rozhraní lze reprezentovat jako sadu souborů - lze úspěšně implementovat do moderního distribuovaného systému. Některé funkce z plánu 9, jako kódování znaků UTF-8 Unicode, byly implementovány do jiných operačních systémů. Unixové operační systémy, jako je Linux, implementovaly 9P, protokol Plan 9 pro přístup ke vzdáleným souborům a přijaly funkce rfork , mechanismu vytváření procesů Plan 9. Navíc v Plánu 9 z uživatelského prostoru bylo několik aplikací a nástrojů Plan 9, včetně editorů sam a acme, přeneseno do systémů Unix a Linux a dosáhlo určité úrovně popularity. Několik projektů se snaží nahradit programy operačního systému GNU obklopující jádro Linuxu programy operačního systému Plan 9. Správce oken 9wm byl inspirován 8½ , starším okenním systémem Plan 9; wmii je také silně ovlivněn plánem 9. Ve výzkumu počítačové vědy byl plán 9 použit jako platforma gridových počítačů a jako prostředek pro výzkum všudypřítomných počítačů bez middlewaru . V obchodě je plán 9 základem úložných systémů Coraid . Plán 9 se však nikdy nepřiblížil k popularitě Unixu a byl primárně výzkumným nástrojem:

[Nevypadá to, že by plán 9 selhal jednoduše proto, že nedosáhl dostatečně přesvědčivého vylepšení Unixu, aby vytlačil jeho předka. Ve srovnání s plánem 9 Unix vrže a cinká a má zjevná rezavá místa, ale svou práci zvládne dostatečně dobře, aby si udržel svoji pozici. Pro ambiciózní systémové architekty je zde lekce: nejnebezpečnějším nepřítelem lepšího řešení je existující základna kódu, která je dostatečně dobrá.

-  Eric S.Raymond

Mezi další faktory, které přispěly k nízkému přijetí plánu 9, patří nedostatek komerčního zálohování, nízký počet aplikací pro koncové uživatele a nedostatek ovladačů zařízení .

Navrhovatelé a vývojáři plánu 9 tvrdí, že problémy bránící jeho přijetí byly vyřešeny, že byly splněny jeho původní cíle jako distribuovaný systém, vývojové prostředí a výzkumná platforma a že se těší mírné, ale rostoucí popularitě. Inferno je díky svým hostitelským schopnostem nástrojem pro přenos technologií Plan 9 do jiných systémů jako hostovaná součást heterogenních výpočetních sítí.

Na rozšíření plánu 9 pracuje několik projektů, včetně 9atom a 9front. Tyto vidlice rozšiřují plán 9 o další hardwarové ovladače a software, včetně vylepšené verze e-mailového systému Upas , kompilátoru Go , podpory systému řízení verzí Mercurial (a nyní také implementace git) a dalších programů. Plán 9 byl přenesen na jednodeskový počítač Raspberry Pi . Projekt Harvey se pokouší nahradit vlastní kompilátor Plan 9 C GCC , využít moderní vývojové nástroje jako GitHub a Coverity a urychlit vývoj.

Deriváty a vidlice

Inferno je potomkem Plan 9 a sdílí mnoho koncepčních návrhů a dokonce i zdrojový kód v jádře, zejména kolem zařízení a protokolu Styx/9P2000. Inferno sdílí s Plan 9 unixové dědictví od Bell Labs a unixovou filozofii . Mnoho nástrojů příkazového řádku v Infernu byly nástroje Plan 9, které byly přeloženy do Limba .

• 9atom rozšiřuje distribuci Plan 9 přidáním jádra 386 PAE , procesoru amd64 a terminálového jádra, nupas, hardwarové podpory pro další počítače, IL a Ken's fs.
• 9front je vidličkou plánu 9. Byla zahájena k nápravě vnímaného nedostatku vyhrazených vývojových zdrojů v Bell Labs a nahromadila různé opravy a vylepšení.
• 9legacy je alternativní distribuce. Obsahuje sadu záplat na základě aktuální distribuce Plan 9.
• Akaros je navržen pro mnohojádrové architektury a rozsáhlé systémy SMP.
• Harvey OS je snaha dostat kód Plan 9 k práci s gcc a clang.
• JehanneOS je experimentální operační systém odvozený z Plan 9. Jeho uživatelská země a moduly jsou většinou odvozeny z 9front, jeho systém sestavení z Harvey OS a jeho jádro je vidličkou 64bitového jádra Plan9 Plan9-9k .
• NIX je vidlice Plan9 zaměřená na vícejádrové systémy a cloud computing.
• Plán B navržený pro práci v distribuovaných prostředích, kde se sada dostupných zdrojů liší v různých časových bodech.
• node9 je skriptovaný derivát Plan9/Inferno, který nahrazuje programovací jazyk Limbo a virtuální stroj DIS jazykem Lua a virtuálním strojem LuaJit . Rovněž nahrazuje I/O hostované Inferno na platformě hostováním libuv Node.js a I/O pro konzistentní hostování napříč platformami. Je to proof-of-concept, který ukazuje, že distribuovaný operační systém lze zkonstruovat z oborů jmenných prostorů a obecných cloudových prvků k vytvoření obrazu jednoho systému libovolné velikosti.

Licence

Počínaje vydáním čtvrtého ročníku v dubnu 2002, plný zdrojový kód Plan 9 z Bell Labs je volně dostupný pod Lucent veřejnou licencí 1.02, což je považováno být open-source licencí podle Open Source Initiative (OSI), zdarma softwarovou licenci od Free Software Foundation a prochází Debian Free Software Guidelines .

V únoru 2014 byla Kalifornská univerzita v Berkeley autorizována současným držitelem autorských práv Plan 9 - Alcatel-Lucent -k vydání veškerého softwaru Plan 9, který se dříve řídil veřejnou licencí Lucent, verze 1.02, pouze pro GPL-2.0 .

23. března 2021 bylo vlastnictví plánu 9 převedeno z Bell Labs na nadaci Plan 9 Foundation a všechna předchozí vydání byla znovu licencována na licenci MIT .

Viz také

• Alef (programovací jazyk)
• Rendezvous (Plán 9)
• Inferno (operační systém)
• Minix
• HelenOS

Reference

externí odkazy

• 9p.io : Archivované zrcadlo původního oficiálního webu Plan 9 na plan9.bell-labs.com
• 9fans : Polooficiální seznam adresátů pro uživatele a vývojáře Plan 9
• Nadace Plan 9