AROS - No schedule & "rockin'"?

A minap az OWB post kapcsán szóba jött az AROS, mint a harmadik számú Amiga alternatív OS.

Ráadásul mint egyetlen, amelyik natívan fut x86-on, plusz az egyetlen nyílt forrású, az összes Amiga-variáns közül. És hát nem voltam róla túl jó véleménnyel. Ezért kipróbáltam, mit tud a legújabb vmwAROS, hátha mióta legutóbb próbáltam, változott annyit, hogy pozitív irányba korrigálhatom a véleményem.

Elkezdtem vele játszani, eltekintettem a lépten-nyomon fellépő refresh-bugoktól, meg hogy natív x86 kód létére lassabban bootol mint rommá-skinnelt OS3.1 az UAE-ben.


Rommá skinnelt AmigaOS 3.1 UAE-ben, (c) 1994, Commodore

Ugyanez AROS alatt. A vmwAROS skinje 1:1-ben OS4 lopás de ettől tekintsünk el, mert legalább használhatóan néz ki, ellentétben a korábbi AROS disztribúció próbálkozásoktól.


vmwAROS alap look and feel

Attól is eltekintettem, hogy a natív VMWareSVGA driver szanaszét hal, és ezért csak VESA driverekkel használható. Ott legalább a grafikai refresh viszonylag gyors. Az átlátszóság effektek természetesen a jól bevált fake cuccok, vagyis ha a lenyílt átlátszó menü alól elmozgatom az ablakot (vagy megváltozik a tartalma) a menüben látható rész nem követi... Jó pont viszont, hogy rengeteg alkalmazást adnak hozzá alapból, hálózati cuccokat is, más kérdés, hogy továbbra is random fagy. Pl. duplakattal elindítottam az IRC klienst, és megfagyott. Egérkurzor megáll, aviszontlátás... A Wanderer, a desktop ránézésre jó, és a viselkedése is jobban követi a modern rendszerekben megszokottakat mint az ősöreg Workbench, de továbbra sem tud gyakorlatilag semmit az ikonok megjelenítésén, a könyvtárakban való mászkáláson és a programok elindításán kívül. De a próbálkozást akkor hagytam abba, amikor a hálózati beállítások közben (full DHCP minden) ez fogadott:


Öööööö... He?

Ilyen ablakot már 10 éve, a classic Amigámtól sem toleráltam volna. Mármint a hálózati beállítás esetén történő rebootot. "Note:"-t meg nem is minősíteném, köszönjük, leülhet. Továbbra is elégtelen.

(Megj: a "sometimes" tapasztalatom szerint 10-ből 9 alkalmat jelent. Minimum. Mondjuk már az is vicces, hogy ennyiszer kellett rebootolni, mikozben gyakorlatilag az égvilágon semmit sem csináltam vele, mivel nem tudtam vele semmit sem csinálni, mert vagy lefagyott, vagy rebootot kért.)

( prygme | 2009. 02. 11., sze – 17:43 )

kár érte. pedig az AROS lett volna az életképes irány. ez a 90es évek közepén még nem volt egyértelmű. így viszont ide nem jutott a feladathoz szükséges méretű és tudású devteam.

for free speech

Lehetne ebből használható rendszer, csak iszonyatos mennyiségű bugfix kéne hozzá, meg néhány triviálisabb usabilty fejlesztés. Kár, hogy az AROS húzókóderek most találták ki, hogy inkább Anubis néven egy másik (nem AmigaOS API kompatibilis, de Amiga-inspirált) OS fejlesztésébe fognak. Újabb végtelen történet, amigás módra... :(

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

( kikke | 2009. 02. 11., sze – 18:05 )

Kipróbáltam én is. :) Hasonló tapasztalatokkal gazdagodtam, olyasmi ez, mint amikor Pingwinek néven készített valaki egy kipróbálható Haiku live CD-t, a fejlesztők minden igyekezete ellenére. Szépen lassan halad.

( Smokey2k | 2009. 02. 11., sze – 19:08 )

amúgy hogy megy ez az AROS?

68k-s binaryk mennek atomatikussan emulálva mint mondjuk macosx alatt a rosetta? Pl diropus megy , vagy portolni kell ?

API kompatibilis. Bináris kompatibilitás nincs, tehát nem olyan mint MorphOS vagy OS4 esetén, hogy majdnem tökmindegy, hogy egy alkalmazás 68k vagy PPC. Az alkalmazásokat minimum újra kell fordítani, és endian-fixelni (mivel az x86 little endian, ellentétben a 68k-val és a PPC-vel ami big endian).

A bináris kompatibilitás egyébként pont ezért nem, vagy csak igen nehezen megoldható. Sajnos az AmigaOS API olyan, hogy az alkalmazások elérhetnek egyes rendszerstrukturákat, valamint az processzek-közötti kommunikáció is arra épül, hogy nincs memóriavédelem. Namost, nyilván a 68k-s alkalmazások mind arra építenek, hogy a rendszerstruktúrák bigendianok, miközben AROS/x86-on nem azok...

A fentiek miatt nem lehet egy jól definiálható felületen megoldani a big->littleendian fordítást, mint azt pl. az OSX csinálja Intelen, a Rosettával. Így AmigaOS bináris kompatibilitás csak bigendian processzoron, vagy teljesen szeparált emulátorban oldható meg. Egyébként volt rá próbálkozás, hogy részben x86-natívvá tegyék az AmigaOS-t a bináris kompatibilitás megoldásával: az Amithlon és az AmigaOS-XL keretében. Ezek olyan patchelt UAE-k, amelyek bizonyos gateway-eken keresztül lehetővé tették, hogy az emulált AmigaOS környezetben futó alkalmazások kommunikáljanak az x86 külvilággal, sőt az Amithlon a környezeten belül is tudott x86 natív alkalmazásokat futtatni: egy patchelt GCC segítségével, ami bigendian kódot generált x86-ra. Apró hátrány, hogy a folyamatos byte-swappolás miatt az x86 "natív" kód sebessége majdnem olyan lassú lett, mint a 68k JIT emulátor által futtatott régi kódoké... De ez egy másik történet. :)

Visszatérve az AROS-ra, egyébként mivel a Directory Opus 4 nyílt forrású lett, ezért az pont van rá... :)

Szerk: És természetesen a fentiek csak az x86 AROS-ra vonatkoznak, PPC-n vagy 68k-n futó AROS-on lehet bináris kompatibilitást megvalósítani. Ezt ki is használja pl. az AROS for AmigaOS projekt, amely egyes elavultabbnak számító 68k AmigaOS komponenseket AROS modulok felhasználásával frissít.

Szerk#2: De egyébként a fentiek ellenére alapból az AROS PPC-n sem kompatibilis az OS4-gyel vagy a MorphOS-sel. (A MorphOS kompatibilitásra egyébként talán nagyobb esély lenne, mert a MorphOS sokmindent a 68k-s OS-hez hasonlóan csinál, mig az OS4 sokkal távolabb került tőle. Pl. a library-k működését tekintve.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-