A Be inc. csődje és a felvásárló Palm inc. eddíg kiszivárgott tervei alapján az eredeti BeOS hosszú távú jövője nem túl bíztató a folyamatos driver-utánpótlás ellenére sem. Új számítógép vásárlásakor csak tudatosan kiválasztott alkatrészekkel lehet gépünket BeOS futtatására bírni, ezt pedig csak a megszállottabb BeOS rajongók hajlandók megtenni. Több szervezet is próbálkozott a BeOS forráskódjának és jogainak megszerzésére, de a Palm rendre elutasította a kezdeményezéseket. A BeOS R5.1 eltulajdonított forráskódjára épülő DANO pedig nem nagyon lehet alapja a BeOS hosszú távú fennmaradásának.

  Ezért a beos rajongók több projektet is megindítottak kedvenc oprendszerük kiváltására. Ezek mindegyike használ valamilyen kiindulópontot a nyílt forráskódú operációs rendszerek világából. ( NewOS, a Linux kernel, az AtheOS bizonyos részei és még sok más GNU, BSD program vagy kódrészlet ) A próbálkozásokat alapvetően két csoportra bonthatjuk: A linux alapú beos kompatibilis rendszerek, és a BeOS-hoz hasonló felépítésű megoldások. Az első csoportba sorolható a Cosmoe a BlueEyedOS és a Leonardo, míg a második ma gyakorlatilag az OpenBeOS-ból áll mert az AtheOS BeOS kompatibilissé való kiterjesztése az OS fejlesztőjének rosszallása miatt egyenlőre csak terv marad.

Linux alapon

  A legígéretesebb fejlesztésnek ebben a kategóriában a Cosmoe tűnik, mivel kezdetleges, de már működő verziói le is tölthetők. A Cosmoe-nak a minnél több hardverrel és szoftverrel való kompatibilitás a célja mint a BeOS-al való teljes hasonlóság, de a technikától eltekintve a felhasználói felületetben és kezelhetőségben valami hasonlóra törekednek. A Cosmoe Linux kernelen és AtheOS apps-serveren alapul, és forrásszinten kompatibilis a BeOS és a MacOS Carbon API-jával. Ez így elsőre elég nyakatekertnek tűnik, de nézzük meg hogyan is jutottunk el idáig.

  Felépítése miatt az AtheOS-t már a kezdetekben is sokan a BeOS nyílt forráskódú testvérének tekintették, bár nem futottak rajta a BeOS programok. A fejlesztője Kurt Skauen nem akarta hogy a rendszere egy BeOS klónná váljon ezért minden erejével küzdött bármilyen hasonló kezdeményezés ellen. Ezért az egyik fejlesztő, Bill Hayden az AtheOS-re alapulva egy új projektet hozott létre a Cosmoe-t. A Cosmoe nem csak beos kompatibilitással ruházza fel az atheos apps-servert, hanem annak kernelét is kicseréli linux-ra.

  Sokakban felmerül, hogy ez csak egy újabb linux disztribúció lesz ami véletlenül képes ugyan BeOS programokat futtatni, de bonyolult és nehézkes mint a linuxok többsége. A Cosmoe viszont egy jelentős dologban eltér a KDE-től, Gnome-tól vagy egyéb felületeketől amiket a linuxok használnak, mivel nem használja az X-szervert. Az X-szerverrel egy nagy hátránya ( bizonyos szempontból előnye is ), hogy nincs beépített eszközkészlete ( Tool Kit, Widget ) és programozási felülete, (API ) mint például a BeOS-nak, Windows-nak vagy a MacOS-nek. Ezért alakultak ki a különböző eszközkészletek mint a Motif, GNUStep, a QT ( amit a KDE használ ) vagy a GTK ( a Gnome alapja ) és ezeknek a különböző ( egymással nem mindíg kompatibilis ) verziói. Ha tehát X-et használunk és alkalmazásaink véletlenül mind-mind más eszközkészletet használnak, elég össze-vissza képet tudnak mutatni, nem is beszélve a vágólapok, és a programok közötti kommunikáció kaotikusságáról, és a nagy memóriaigényről. ( Egy eszközkészletben olyan elemek vannak mint pl. a gomb, scroll-bar, a legördülő menü vagy a beviteli mező. Ezeket álalában nem kell minden alkalmazásban külön leprogramozni hanem az operációs rendszer ezt meghívható szolgáltatásként nyújtja. Ettől lesz valamennyire egységes pl a BeOS vagy Windows-os programok kinézete és használata. ) A Cosmoe apps-server viszont rendelkezik saját API-val, méghozzá nem is akármilyennel. A Cosmoe API ugyanis úgy lett kialakítva, hogy a BeOS, a MacOS Carbon és bizonyos AtheOS felületre írt alkalmazások mind ugyanarra az Cosmoe API-ra fordulnak majd le. ( Ebből a BeOS nagyjából készen van a Carbon még várat magára. ) Ezek az újrafordított alkalmazások Cosmoe alkalmazásokká válnak, egységes képet mutatnak és jóval kevesebb erőforrást igényelnek mintha más-más eszközkészleteket használnának.

  A Cosmoe tehát csak a BeOS programok újrafordításával lesz képes azok futtatására. Az API elkészülte után, tervezik még az OpenTracker portolását, és a felület csinosítását is. Ha Haydennek sikerül a megvalósítani, akkor a mostani Linux disztribúciókra telepíthető változat mellett készülni fog egy teljes, telepíthető Cosmoe operációs rendszer is, amely szintén a linux kernelt használja, de alapból a Cosmoe grafikus felületével indul.

  Az hogy a rendszer Linux kernelt használ, a felhasználó szempontjából nem sok hátrányt fog jelenteni mivel a BeOS értékes tulajdonságainak többségét úgysem a kernel hanem az apps-server a translation-kit és a multimedia-kit hordozza, ami Cosmoe-ban is megvalósítható lesz. Egy hátrányt mindenképpen hoz a Linux ez pedig a virtuális eszközmeghajtók hiánya. Így valószínűleg nem lesz olyan egyszerű drivereket telepíteni mint BeOS-ban ahol szinte minden komponens plug-in alapú, de a Linux eleve gazdag driver ellátottsága, a jobb hálózatkezelése és stabilitása ellensúlyozhatja ezt. Ha figyelembe vesszük, hogy a BeOS elterjedésének egyik legnagyobb gátja pont a gyenge hardware-támogatás volt a linux ebből a szempontból előnyös lehet. Ha szükséges a későbbiekben még nyitva áll a kapu valamilyen microkerneles rendszerre való átállásra mint a BSD vagy a Darwin ( a MacOS X kernele ), de ennek a kevés gyakorlati előny miatt kicsi a valószínűsége. Mivel a Cosmoe nem használ X-szervert a videókártya meghajtókról, itt is gondoskodni kell majd. Jelenleg a képet FrameBuffer, Direct FrameBuffer, vagy a legújabb verzióban ideiglenesen bevezetett X-driver segítségével lehet megjeleníteni. A végleges verzióban egy olyan driver interface lesz, amihez az X-szerverben levő drivereket könnyen át lehet majd venni.

  A másik két Linuxot használó BeOS klónról nem sokat lehet tudni. A BlueEyedOS ( régebben BlueOS ) francia fejlesztői R1 verzióban egy X-szerverre épülő, R2 verzióben pedig egy új apps-servert használó rendszert terveznek készíteni. Az oldalukon megjelent grafikonok alapján a BeOS API egy részét már elkészítették, de kipróbálható verzió még nem jelent meg.

  A Leonardo a legfrissebb projekt. Róluk még semmit sem lehet tudni, csak egy szűkszavú weboldal erejéig mutatnak valamit a tevékenységükből.

OpenBeOS

  Az OpenBeOS projekt célja a BeOS R5 teljes újraírása. Ez a csapat élvezi a legnagyobb támogatást a BeOS közösségen belül, és száznál is több fejlesztőt tudhat magáénak. Ők is felhasználnak a már meglevő nyílt forráskódú kódrészekből, de semmit nem vesznek át egy az egyben, mert az sok esetben korlátozná őket a teljes BeOS hasonlóság elérésében. Az OpenBeOS-ban a NewOS kernelt vették alapul ami a legjobban hasonlít az eredeti BeOS mikrokerneles felépítésére. A NewOS POSIX kompatibilis, nyílt forráskódú és készítője valamikor a Be inc.-nél dolgozott. A kernelt már leválasztották a NewOS fejlesztési vonaláról, s azóta külön fejlődnek. Egy ideig az OpenBeOS egyes részei külön-külön készültek. Miután azonban megnyitották az OpenBeOS kernel fát, megkezdődhetett a komponensek integrálása és kernelhez igazítása.

  A fontosabb részek közül a filekezelés funkcionálisan már működik. Az alapot a linuxos BeFS kernelmodul adta és már csak a tesztelés, a terhelési próbák és a kernelbe integrálás van vissza. Az OpenBeOS az eredeti BeOS által is használt 64 bites BeFS filerendszert fogja használni. A storage kit ami a filekezelés logikai részéért lesz felelős szintén alpha stádiumban van.

  Az apps-server elkészítése jelenti a legnagyobb munkát, mivel itt nem volt kiindulási alap, csak a BeOS R5 hivatalos dokumentációja. A tervezés fázisán már túljutottak. A Prorotype 6 már le is tölthető, és ez a csapat is megkezdte a kernelhez igazítást. A network-kit a BSD ből lett átvéve, és bizonyos tesztekben a NetPositive már képes volt használni azt.

  Az alapvető részek tehát rendelkezésre állnak ahhoz, hogy létrehozzák az első fejlesztői verziót, mivel a kernel a file-kezelés és az apps-server nagy része készen áll. Ezzel felgyorsulhat azon komponenes készítése is, amelynél célszerűbb az új rendszeren írni. Egyébként nem kis munka és idő lesz az OpenBeOS-t megírni, de a projekt vezetői szerint nem fog olyan sokáig tartani mint egy új operációs rendszer fejlesztése, mivel egy meglévő és kipróbált rendszer nyílt forráskódú újraírása sok tervezési és tesztelési munkát megspórol. Az is gyorsíthat a folyamaton, hogy egyes részek elkezdéséhez nem kellett megvárni az OpenBeOS alapvető részeinek elkészültét, mivel az eredeti BeOS-on is elkezdhető volt jópár dolog, amit később könnyen beleillesztenek majd az új rendszerbe.

  Az OpenBeOS R1 a BeOS R5-el való kompatibilitást fogja nyújtani és egyenlőre csak kevés új funkció kerül bele. A kezdeti cél itt is a forrásszinten való kompatibilitás, de mivel a részegységek funkcionálisan meg fognak egyezni az eredetivel ezért jó eséllyel tudunk majd eredeti BeOS programokat is futtatni rajta. Az új rendszer tehát örökli az eddigi alkalmazások, és driverek egy részét, de ezek hiányát is részben. A nyílt forráskód miatt viszont sok olyan dolgot lehet majd átvenni amiket eddig a zárt kód miatt a pl a GPL liszensz nem tett lehetővé.

  Az BeOS világ jövője tehát úgy tűnik az OpenBeOS kezébe került mégpedig az általuk létrehozott Glass Elevator porject-en keresztül. Ez a projekt hivatott az OpenBeOS R2 új funkcióit, fejlesztéseit és API-ját megtervezni, tehát ők fogják meghatározni hogy mi kell egy jövőbeni BeOS program futtatásához és ezzel valószínűleg hatással lesz a többi BeOS programok futtatására alkalmas rendszerre is. Ha ez nem így történne akkor az a sajnálatos eset is bekövetkezne, hogy sok egymással forrásszinten sem teljesen kompattibilis beos változat kerülne ki. Ezt az esetet próbálja elkerülni a BeUnited.org is az OSBOS ( Open Source BeOS-compatible Operating System ) egységesítési törekvése is, amelyhez a YellowTAB is csatlakozott. Egyébként a YellowTAB szintén készül valamire a de erről nem sokat lehetett eddíg hallani.

Egyéb ...

  Mivel az AtheOS fejlesztése megrekedt, a fejlesztők egy csoportja szintén kivált a projektből és Syllable néven folytatták a munkát. Itt még ugyan nem esett szó BeOS kompattibilis irányvonalról, de a szintén AtheOS-re épülő Cosmoe ilyen irányú fejlesztéseit valószínűleg nem lenne nagy ördöngősség átvenni, ha a fejlesztők úgy döntenek.

Zárszó

  A BeOS tehát él, és ezt mi sem bizonyítja jobban mint a gomba módra szaporodó klóntervek. A vezető szerep ezek között mindenképpen az OpenBeOS-é mivel ők próbálnak az eredetivel legjobban megegyező rendszert készíteni és nekik van a legnagyobb a fejlesztői gárdájuk. A Cosmoe szerepe is érdekes lehet, mert úgy tűnik előbb tudnak használható változatokkal előállni, és a kezdetben jóval szélesebb körben lesz majd használható, bár a teljes elkészülés nekik is sok időt fog igénybe venni. A többiek jövőjéről még nem nagyon lehet mit mondani, de nagy lemaradásban vannak ahoz, hogy belátható időn belül valami eredményt tudjanak felmutatni.