blog.michalt.pl

Minix 3 – szop żyje czy już nie?

09.09.2019 21:50 - Tech

Czemu szop? To wredne, przebiegłe i cwane zwierzątko znajdziemy w logo systemu operacyjnego Minix 3. Od czasu moich ostatnich przygód z tym zapchlonym futrzakiem minęło ładnych parę lat i nasze zetknięcie było średnio sympatyczne. Ów zwierz robił ładne oczka, jak na szopa przystało, ale gdy odwróciłem wzrok, potrafił napsocić i wszystko kończyło wielkim bałaganem – typowe dla tego stworzenia… Jak na ironię, przyjrzę się jego niestabilnej wersji, czyli 3.4.0 release candidate 6, która pochodzi z 9 maja 2017 roku i jest najświeższym wydaniem systemu. Czyżby ktoś ustrzelił szopa? Dziś wracam do Miniksa i chętnie podzielę się z Wami moimi wrażeniami z obcowania z nim.

Nim przejdę do eksploracji osobnika tegoż inwazyjnego gatunku, opowiem troszeczkę o technicznych i historycznych zakamarkach systemu.

Minix 3 powstał w drugiej połowie lat 80. ubiegłego wieku. Swoje narodziny zawdzięcza holenderskiemu profesorowi Andrew Stuardowi Tanenbaumowi, którego wielu może kojarzyć z książek: „Systemy operacyjne” i „Sieci komputerowe”. System powstał w celach edukacyjnych, które rozszerzono wraz z jego trzecią odsłoną. Trzeci unix-like Tanenbauma miał być dodatkowo systemem użytkowym przeznaczonym dla rozwiązań wbudowanych.

Co ciekawe, Minix był źródłem inspiracji dla Linusa Torvaldsa w tworzeniu jądra Linuksa. Oto jeden z jego cytatów z grupy dyskusyjnej:

„Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on minix? No more all- nighters to get a nifty program working? Then this post might be just for you :-)” [źródło]

Minix 3 jest systemem uniksopodobnym (znaczy to mniej więcej tyle, że nie jest do końca zgodny ze standardem POSIX), opartym na monolitycznym mikrojądrze i wydawanym na otwartej licencji BSD. Ponadto jest on w jakiś sposób kompatybilny z systemem NetBSD i co ciekawe, pozwala na uruchamianie jego paczek. Działa on na 32-bitowych platformach x86 i ARM.

Czas uruchomić futrzaka!

Do zabawy z Miniksem wykorzystałem Virtualboksa w wersji 6.0.6. Zapewne zastanawiacie się, czemu postanowiłem sięgnąć po niedokończoną wersję systemu? Otóż stabilna 3.3.0, okazała się niestabilna już na etapie instalatora, który miał problem z partycjonowaniem dysku. Ten sam (lub jego łudząco podobny) wariant ruszył na wydaniu, które powinno być mniej stabilne i udało się zainstalować 3.4.0. Instalacja systemu, mimo że tekstowa, była bardzo prostym i krótkim procesem polegającym na wpisaniu odpowiedzi w tekstowy formularz (chyba zawsze pojawiała się propozycja domyślnej wartości) . Wszystko przebiegło bardzo szybko i niesamowicie łatwo. Po zainstalowaniu systemu mamy do dyspozycji tryb tekstowy wraz z domyślną, znaną z systemów BSD powłoką ksh (opcjonalnie preinstalowana jest rówież csh) i dwa dosyć archaiczne menedżery okien: twm i ctwm – aby móc uruchomić któryś z nich, należy najpierw uruchomić X-y poprzez polecenie xinit, a następnie wpisać nazwę któregoś z window managerów. Na samym początku istnieje jedynie użytkownik root i na jego koncie nie ma przypisanego hasła. Dodawanie nowego użytkownika w trybie tekstowym wygląda podobnie jak w Linuksie i większości uniksów z tą różnicą, że tu trzeba nieco bardziej się natrudzić i np. manualnie stworzyć dla niego katalog domowy, a także ustawić hasło.

System dysponuje również menedżerem pakietów pkgin, który podczas moich zabaw bardziej nie działał niż działał. Próba aktualizacji systemu doprowadziła do jego częściowej wysypki i całkowitej wysypki owego menadżera. Po którymś przywróceniu snapshota postanowiłem spróbować polecenia pkgin_all, które miało zainstalować wszystkie dostępne w repozytorium Miniksa pakiety. W jej trakcie regularnie pojawiały się komunikaty o niespełnionych zależnościach dla niektórych pakietów. Proces zakończył się błędem i powtarzającym się w kilku liniach komunikatem: „Shared object ‘libarchive.so.13” not found”. Większość aplikacji, które próbowałem zainstalować pojedynczo, miała niespełnione zależności.


Postanowiłem zajrzeć do repozytoriów i spróbować rozwiązać problem. Wyedytowałem plik repositories.conf (preinstalowanym edytorem vi) znajdujący się w katalogu /usr/pkg/etc/pkgin i odkomentowałem repozytoria dla NetBSD. Jednak pkgin nie poradził sobie z ich zaciągnięciem, ponieważ okazały się one nieaktualne i pochodziły z piątej wersji tegoż systemu. Podciągnąłem wpis z repozytorium do najstarszej dostępnej wersji NetBSD, czyli 6.0 i w pojawił się pierwszy mały sukces. Repozytorium wciągnięte, ale niestety wystąpiły konflikty przy próbie zainstalowania czegokolwiek lub znowu były niespełnione zależności.


Problemy z siecią oraz menedżerem pakietów spowodowały, że niespecjalnie miałem okazję spróbować pobawić się systemem. Ponadto ciągle czułem się jak we FreeBSD lub Linuksie, tyle że bardzo niestabilnym. Obsługa pakietów NetBSD skłania również do zadania sobie pytania: „Ile jest Miniksa w Miniksie, a ile kodu z zewnątrz...”. Mimo całkiem sporej ilości pamięci operacyjnej (1GB), system potrafił się na chwilę zawiesić, ale zdarzało się to wyjątkowo rzadko.


Podsumowując: Nie wiem co myśleć o najnowszym systemie spod znaku szopa. Tym razem ten wredny futrzak okazał się nieco bardziej łaskawy. Pamiętajmy, że założenia projektu zakładają raczej cele edukacyjne i w moim odczuciu na chwilę obecną jedynie w tym obszarze powinniśmy go rozpatrywać. Czuję spory niedosyt. Widać, że wredny zwierz nieco przyczesał futerko, stał się mniej kapryśny i gdy wspaniałomyślnie dał się udomowić, przestano o niego dbać. To mimo wszystko ciekawy projekt z przejrzystą dokumentacją. Mam nadzieję, że powstanie on z popiołów, ale jako szop-feniks, a nie szop-zombie.
Zachęcam Was do zapoznania się z projektem na stronie: www.minix3.org.
Ja sam jeszcze troszkę się z nim pobawię i może wrócę do jego tematu na łamach bloga.