Przez wiele lat użytkowników Amigi dręczyły dwa główne problemy: brak nowego sprzętu oraz brak "prawdziwego" rozwoju systemu. Długo trzeba było czekać, aby coś drgnęło. Pomijając politycznie rozważania, powstały dwie zbliżone do siebie, nowoczesne platformy amigowe - AmigaOne z systemem AmigaOS 4.0 oraz Pegasos z systemem MorphOS. Zarówno jedno, jak i drugie rozwiązanie oparte jest o technologię PowerPC. Mało jednak osób wie, że istnieje jeszcze trzecia ścieżka - trochę inna, bardziej wyboista, posiadająca jednak te same cechy co wyżej wymienieni: szybkość i dostępność do nowego sprzętu. Mowa o AROS-ie - AROS Research Operating System (dawniej, Amiga Research Operating System).
AROS jest projektem opartym na wolnych źródłach, którego głównym celem jest stworzenie portowalnego systemu operacyjnego, który posiada klimat, wygląd i kompatybilność AmigaOS 3.1. Projekt został zapoczątkowany przez Aarona Digulla w połowie lat 90-tych, gdy mrzonką wydawało się wypuszczenie jakiegokolwiek uaktualnienia do AmigaOS 3.1. Commodore zbankrutowało, Escom zdawał się długo nie pociągnąć tego interesu i wyglądało na to, że ma trochę inne aspiracje niż rozwój systemu. Osoby odpowiedzialne później za AROS-a doszły do wniosku, że skoro społeczność amigowa nie może liczyć na oficjalny dalszy rozwój AmigaOS, to może czas najwyższy wziąć sprawy w swoje ręce i samemu zacząć rozwijać "własny".
Ten bardzo ambitny plan zaczął jednak wchodzić w życie. Rozpoczęto od założeń. Jako priorytet obrano otwartość źródeł, aby zapewnić, że w przyszłości problem braku chętnych do rozwoju systemu się już nie pojawi. Reimplementacja AmigaOS nie jest zadaniem prostym. Tworząc AROS-a, deweloperzy musieli rozpocząć wszystko od podstaw wykorzystując jako dokumentację API AmigaOS i cenną wiedzę programistów. Istniejący system w żadnym razie nie mógł stanowić pomocy, gdyż skomplikowane sprawy związane z licencją wokół poszczególnych elementów AmigaOS, praktycznie uniemożliwiały otwarcie systemu.
Drugim istotnym założeniem AROS-a jest jego portowalność, aby możliwym było uruchamianie "nowego systemu" na nowym sprzęcie. Zapewnienie kompatybilności z systemem 3.1 również nie było zadaniem prostym. Założono, że AROS musi być kompatybilny na poziomie "binarek", to znaczy, że amigowe oprogramowanie musi uruchomić się na AROS-ie, a oprogramowanie AROS-a na systemie AmigaOS. Na innej architekturze, jak np. na pecetach, AROS uzyskuje kompatybilność na poziomie kodu źródłowego, a to z kolei oznacza, że ten sam kod źródłowy da się skompilować i uruchomić na każdej platformie (oczywiście osobną kwestią wówczas pozostaje, że utworzone w ten sposób pliki znajdą zastosowanie wyłącznie na platformie na którą zostały skompilowane).
Tu się właśnie zaczęły przysłowiowe schody. O ile źródła dały się kompilować i uzyskane pliki dały się uruchamiać, to już kwestia kompatybilności z AmigaOS 3.1 wypadała kiepsko. Wymagane było stworzenie pewnego rodzaju emulacji. Nie udało się dojść do żadnych konkretnych rozwiązań. Ostatecznie przeportowano dla AROS-a UAE, które rozwiązało ten problem. Oczywiście jest to półśrodek, lecz do dzisiaj nie wymyślono nic innego.
Kolejna cecha AROS-a to jego natywne działanie jako osobnego systemu operacyjnego na docelowym sprzęcie lub też jako nakładka na już istniejący system. W tej materii obecnie obsługiwany jest Linux i BSD. Podczas takiej pracy AROS tworzy coś na miarę UAE (uruchomienie np. w okienku lub na nowym ekranie) z tą różnicą, że tylko API jest emulowane, a nie komponenty sprzętu. Binarki uruchamiane w tym trybie działają z pełną, natywną prędkością. Wbrew pozorom, takie rozwiązanie przynosi twórcom AROS-a dużo pożytku z uwagi na to, że pracując w tym trybie AROS nie wymaga dużej ilości sterowników i jest doskonałym sposobem na prowadzenie prac nad rozwojem.
Po ośmiu latach prac AROS wreszcie osiągnął stadium, w którym stał się użyteczny. Nadal jest w wersji alpha, jednak głowne jądro systemu, włączając w to AROS-owe odpowiedniki Exec, Intuition i AmigaDOS, są w znacznej części ukończone. Prace nadal posuwają się do przodu, a głównie polegają na implementacji elementów wyższego poziomu, takich jak np. Wanderer czyli AROS-owy odpowiednik Workbencha oraz wszelkiego rodzaju programów narzędziowych, których spodziewalibyśmy się w AmigaOS. AROS posiada datatypes, commodities, interpreter Rexxa i nawet swój własny odpowiednik HDToolboxa. W system wbudowano mnóstwo implementacji oprogramowania tzw. third-party. W AROS-ie znalazły się biblioteki ReqTools i CyberGraphX. Stworzono także odpowiednik MUI, który nazwano Zune. Wykorzystywany jest przez samego Wanderera oraz niektóre z programów preferencji AROS-a.
Aktualnie najbardziej zaawansowane są porty AROS-a, które pracują samodzielnie (natywnie) na pecetach oraz jako nakładki na Linuxa. W roku 2003, Genesi podarowało autorom AROS-a jednego Pegasosa, na którego AROS również powstaje. Eksperymentalna wersja dostępna jest także na Palma. W każdej chwili można wypróbować jak sprawuje się aktualna wersja AROS-a. Ze strony projektu można pobrać bądź też same uaktualnienia, bądź też obrazy ISO gotowe do wypalenia na płytę. Dla osób chętnych tworzyć własne oprogramowanie dla AROS-a, też zamieszczono stosowne archiwa i obrazy ISO.
Najnowsza wersja AROS-a przeznaczona dla peceta zawiera w sobie podstawowy zestaw sterowników. Obsługują one myszy i klawiatury na PS/2, standardowe porty szeregowy i równoległy, dyski ATA i CD-ROM-y. Obsługiwane są także karty graficzne VESA, a obsługa NVidia zapewniana jest przez eksperymentalny sterownik, który swoją premierę miał dosyć niedawno. Trwają prace nad obsługą USB. Jak widać, sterowniki to chyba najsłabsza część AROS-a, która aktualnie wymaga sporo pracy. AROS obecnie "nie wydaje" z siebie dźwięków. Co prawda Martin Blom przeportował AHI dla AROS-a, które jest do niego dołączane, lecz nie ma sterowników do kart dźwiękowych. Z istotnych braków warto wspomnieć o braku stosu TCP/IP (dużo mówi się o implementacji AmiTCP 3.0, lecz pojawiają się również informację, że będzie to port LWIP-a lub całkiem od nowa pisany element) i jakichkolwiek aplikacji z prawdziwego zdarzenia. Na chwilę obecną istnieją także porty Dooma i Quake'a dla AROS-a, lecz jak widać to dopiero początek.
Prace nad systemem AROS nadal trwają. Pokaźny sztab osób zajmuje się rozwojem systemu. Tempo prac jest różne, czasami pojawia się kilka aktualizacji miesięcznie, a czasami "posucha" trwa przez kilka tygodni. Warto wspomnieć, że istnieje pewnego rodzaju inicjatywa polegająca na tym, że pewne osoby płacą programistom z AROS Team (czasami niemałe pieniądze) za wykonanie określonego komponentu systemu. Przyznać trzeba, że jest to niezwykle motywujący czynnik.
Czy w dobie AmigaOS 4.0 i MorphOS-a, AROS jest potrzebny? Trudno udzielić odpowiedzi na to pytanie. Z jednej strony jest to trzeci AmigaOS-podobny system operacyjny, który środowisko może podzielić jeszcze bardziej. Niemniej, dla zwykłego, pacyfistycznego użytkowania jest to zjawisko pozytywne. Może się zdarzyć, że na AROS-a powstanie coś oryginalnego i dzięki otwartości źródeł, ktoś z konkurencynej frakcji przeniesie to do siebie. Póki co przenoszenie odbywa się w drugą stronę, lecz nie wiadomo co może przynieść przyszłość. Z kolei dla kogoś, kto na przykład posiada peceta i z różnych powodów nie może mieć nowoczesnej lub klasycznej Amigi, jest to pewnego rodzaju kompromis, znacznie ciekawszy niż Amithlon czy WinUAE. Baza użytkowników systemu AROS (a co w sumie za tym idzie - AmigaOS) może tylko wzrosnąć. To jest oczywiście przyszłość, która nie jest powiedziane że się spełni.
AROS, mimo, że jeszcze nawet nie zaistniał na półce u końcowego użytkownika, już wywarł ogromny wpływ na rozwój systemu AmigaOS. Nie można przecież zapomnieć, że niektóre komponenty AROS-a zostały wykorzystane w AmigaOS 3.9. Znaczna ich większość znalazła zastosowanie w MorphOS-ie. Można spokojnie zaryzykować stwierdzenie, że AROS także pomógł przy pracach nad AmigaOS 4.0, może niekoniecznie w sposób bezpośredni, ale jako np. wzór do naśladowania w kwestii rozwiązania portowalności czy kompatybilności. Może nie do końca jesteśmy tego świadomi, ale AROS (a co za tym idzie - propagacja AmigaOS) może odegrać wielką rolę w świecie systemów operacyjnych. Zamiast dzielić i zniechęcać, może połączyć skłócone środowiska. Przewodnik z implementacji amigowego API, może okazać się pomocny przy pisaniu lub ulepszaniu obecnie istniejących systemów operacyjnych.
AmigaOS 4.0, MorphOS i AROS są do siebie bardzo podobne. Są po prostu amigowe. Czemu więc to podobieństwo nie mogło by zostać wykorzystane do stworzenia otwartego standardu, który racjonalnie i rozsądnie wykorzystany przez programistów mógłby stać się spoiwem, które ułatwiłoby tworzenie jednego programu działającego z powodzeniem na trzech systemach? Korzyści mogłyby być jak widać ogromne. Warto chyba równolegle wspierać AROS-a, jeżeli idea i sens jego istnienia może przyczynić się dla dobra wspólnej sprawy.
Na sam koniec pozostaje jeszcze kwestia legalności. Czy stworzenie klona systemu operacyjnego jest nielegalne? W świetle prawa - tak, lecz jeżeli implementacja systemu operacyjnego sprowadza się do sklonowania API, które nie jest czymś co można opatentować czy zastrzec, wówczas można już dyskutować. Mimo wszystko, autorzy AROS-a tworząc system musieli bardzo uważać, aby nie zawrzeć w nim elementów, które należą do intelektualnej własności Amiga Inc. Dla przykładu, AROS nie zawiera możliwości "przeciągania ekranów" ani pull-down menu, które objęte są amigowymi patentami. Podobnie rzecz ma się z innymi elementami. Niemniej jednak pozycja AROS-a jest dosyć niepewna. Amiga Inc. jak dotąd nie wypowiedziała się na ten temat. Fakt, że od tylu lat w tej sprawie nic nie robi może oznaczać nieoficjalną aprobatę. Jak wiadomo, w zapisach prawa nic takiego nie istnieje i warto by było, aby Amiga Inc. zajęła konretne stanowisko w tej sprawie. Z całą pewnością sytuacja uległaby klarowności.
Ciekawe miejsca:
Główna strona projektu
Portal poświęcony AROS-owi
AROS Team Bounty