Michał Schulz znany jest głównie jako deweloper systemu AROS. Nie było łatwo uzyskać wywiad, ale warto było się starać. Zapraszam do lektury.
Powiedz parę słów o sobie.
Nie wiem co mogę o sobie powiedzieć, Michał Szulz, 41 lat, mieszkam w środkowych Niemczech, trójka dzieci, żona, dwa psy i kot. I dużo komputerów w okolicy.
Czym zajmujesz się zawodowo?
Zostałem tutaj „zaadoptowany” w instytucie fizyki. Zacząłem jako chemik, ale powiedzmy że mnie „przechrzcili” na fizyka i teraz zajmuję się materiałami piezoelektrycznymi w wysokich temperaturach. To są różne rodzaje eksperymentów: od podstawowych badań w stylu na przykład właściwości materiałów, przewodnictwo, piezoelektryczne właściwości itd., po praktyczne zastosowania w stylu różnych sensorów, czujników urządzeń, które są w stanie pracować w wysokich temperaturach. Przy czym wysokie temperatury to nie są prawdziwe wysokie temperatury dla fizyków, bo np. dla fizyka jądrowego wysoka temperatura to będzie powiedzmy milion Kelwinów, u nas to jest mniej więcej zakres temperatur od 500 do 1000 stopni Celsjusza. Ale to i tak jest dużo wyżej niż np. wysokie temperatury u biologów; u biologów wysoka temperatura to jest powiedzmy 40 do 60 stopni Celsjusza.
Skomplikowanie to zabrzmiało, ale już przynajmniej wiem mniej więcej, czym się zajmujesz. Czy masz jakieś hobby poza amigowaniem?
Mam różne, a przynajmniej z różnymi próbuję i jeżeli mam czas, to uprawiam je w miarę regularnie. Jedno z tych hobby znasz, już o tym rozmawialiśmy; wiele lat temu zacząłem obserwować jak moje dzieci chodzą na Taekwondo, no i wyglądało to na początku dosyć zabawnie, bo tam biegają różne małe dzieciaki, machają rączkami, nóżkami, w sumie to jest niezbyt składne, niezbyt ładne, ale dosyć egzotyczne. I zauważyłem, że w tej grupie Taekwondo u dzieciaków cała masa dorosłych, rodziców zaczynała po kolei eksperymentować. Każdy na początku przyprowadził swoje dziecko, wszystko było fajnie, dziesięć zajęć później dorosły stwierdzał „hmm, może to będzie jednak ciekawe, może spróbuję?”. I jak ja się zdecydowałem, to już byłem jednym z ostatnich rodziców, którzy dołączyli do grona. W ciągu roku stało się to dla mnie nie tylko jakimś ciekawym, ruchowym zajęciem, ale w sumie taką dosyć intensywną pasją. No i to tak ciągnie się już od 7-9 lat, nawet nie pamiętam dokładnie.
A poza tym z innych rzeczy to lubię czasami sobie troszeczkę pobiegać po lesie. Lubię poza Amigą albo poza ogólnym amigowaniem, zajmować się programowaniem. Nie tylko związanym z Amigą, ale też z innymi rzeczami, tudzież bawić się troszeczkę elektroniką. Czasami z lepszym, czasami z gorszym skutkiem.
Opowiedz o swojej przygodzie z Amigą.
Tak naprawdę wszystko zaczęło się od 8-bitowego Atari. Byłem na wakacjach i jeden z gości miał ze sobą komputer – Atari 800 podłączone do malutkiego przenośnego telewizorka. Maszyna zafascynowała mnie całkowicie, spędziłem przy niej długie godziny. Potem Atari pojawiło się u mnie w domu. Ze względów finansowych nie miałem na początku joysticka, więc nie mogłem za bardzo grać. Zamiast tego zacząłem przepisywać programy w BASIC-u i pisać własne. Tak zaczęła się moja przygoda z programowaniem.
Amiga zaczęła pojawiać się w okolicy. Najpierw na tak zwanej „giełdzie komputerowej”, gdzie ProTracker i Lemmingi były uruchamiane na przemian z X-Copy. Potem A500 pojawiła się u moich kolegów. Chodziliśmy całą bandą od jednego do drugiego i graliśmy do upadłego. W końcu A1200 wylądowała u mnie. Mało rozbudowana, tylko z dodatkowym FAST-Ramem. Z czasem doszła zewnętrzna stacja dysków, twardy dysk, CD, monitor VGA. Nigdy nie rozbudowywałem jej bardziej. Na Amidze mało grałem, głównie programowałem w assemblerze.
U schyłku Amigowego „złotego wieku” odwiedziłem giełdę komputerową we Wrocławiu i z wielkim bólem serca sprzedałem całość za jakieś śmieszne pieniądze, które wystarczyły tylko na kolorowy monitor SVGA do peceta. W tym momencie moja przygoda z Amigą się nie skończyła. Nauczyłem się assemblera x86 i zacząłem tworzyć własny system operacyjny bazujący na API AmigaOS. W którymś momencie stwierdziłem, że najwyższy czas dołączyć do zespołu AROS.
Czy istnieje jakiś element z perspektywy programisty, który w ekosystemie Amigi jest nadal dobrym rozwiązaniem w obecnych czasach, bądź takim który byłby wart rozwinięcia?
Trudno na ten temat coś sensownego powiedzieć. Wiem, że wielu ludzi, między innymi na portalu PPA, tudzież jeszcze amigowcy za granicą, bardzo chwalą sobie różne amigowe rozwiązania i uważają, że są naprawdę super, hiper. Powiedzmy, że w obecnych czasach pecety nie tylko dogoniły Amigę z dawnych czasów, ale ją też dosyć mocno przegoniły. Są interesujące rozwiązania w amigowym systemie, takie jak chociażby cały system datatypów, które są dosyć ciekawym rozwiązaniem i nawet w chwili obecnej nie byłyby jakieś takie bardzo dziwne. Okej, są troszeczkę przestarzałe, np. nie potrafią obsługiwać mediów strumieniowych, wszystko musi być od razu załadowane do pamięci – można sobie z tym jak poradzić, ale ogólnie jest to trudne. Nie wiem czy coś jeszcze, bo tak naprawdę to co AmigaOS oferował ludziom, można w tym momencie znaleźć na praktycznie dowolnej innej platformie, w taki albo inny sposób. To co jeszcze było fajne w Amidze to możliwość oskryptowania całej masy oprogramowania; mam tutaj na myśli porty AREXX-a, tego w obecnej chwili brakuje. Są języki skryptowe, za pomocą których można nad różnymi rzeczami popracować, ale one zwykle są każdy jeden osobno przywiązany do osobnego programu i nie pozwalają na jakąś sensowną wymianę danych między sobą. Chociaż pewnie, z pewnym nakładem wysiłku, dałoby się to jakoś załatać.
To co fajnego w systemie amigowym było i to czego w obecnych czasach naprawdę bardzo brakuje, to jest w sumie taka swoista prostota systemu; bo tak – jak pamiętasz, tak jak wszyscy amigowcy w sumie to mieli – po krótkim okresie używania każdy był w stanie powiedzmy w większy albo w mniejszy sposób zarządzać tym systemem, radzić sobie z tym. Struktura systemu była dosyć jasna i przejrzysta. W obecnych czasach, przy obecnych systemach operacyjnych, tak już niestety nie jest. To jest troszeczkę też spowodowane poziomem skomplikowania. Na przykład AmigaOS jak wystartował, to co mieliśmy? Parę programów na krzyż, które były uruchomione, powiedzmy został załadowany jakiś monitor, zostały assigny przypisane odpowiednio i to było w sumie wszystko. A w obecnych systemach jeżeli system operacyjny startuje, ładuje się masa usług, mniej lub bardziej użytecznych, ładuje się stos sieciowy, ładują się różne usługi sieciowe do wymiany danych – tego w Amidze nie mieliśmy, ale to też z drugiej strony czyniło system prostszym. I w sumie, do wielu zastosowań np. domowych wydaje mi się, że czegoś takiego ludziom może zabraknąć. Każdy ma jakiś system operacyjny – niektórzy używają Windowsa, inni używają Linuxa, macOS, mogą też ludzie używać nie klasycznego AmigaOS, tylko powiedzmy MorphOS-a albo AmigaOS 4. I tak, jeżeliby spojrzeć to poza MorphOS-em i AmigaOS 4 to wszystkie systemy są strasznie skomplikowane tak naprawdę. Bo nie jesteś w stanie, powiedzmy w parę dni albo w parę tygodni ogarnąć dokładnie co gdzie jest i być w stanie bez obaw, że wysypiesz cały system, powymieniać sobie jakieś biblioteki czy coś takiego. Mi się wydaje, że tego w obecnych czasach naprawdę brakuje. Dla nas Amiga była fajną przygodą, można było się z tym troszeczkę pobawić, a w obecnych czasach używasz systemu operacyjnego w sumie jak narzędzia albo jak skomplikowanego samochodu, w którym bez doświadczonego mechanika nie jesteś w stanie nic sam zrobić.
Czy według ciebie to jest zaleta tego systemu, że użytkownik ma nieograniczone możliwości grzebania w tym?
To jest zaleta i jednocześnie wada. W dawnych czasach nikt nie przykładał zbyt wielkiej uwagi do bezpieczeństwa. Większość protokołów sieciowych była w żaden sposób nie szyfrowana, powiedzmy HTTP czy FTP to są wszystko standardowe protokoły, w których podglądając pakiety można zobaczyć naprawdę całą masę informacji, która jest wymieniana między komputerem a serwerem. Bezpieczeństwo nie było aż tak istotne. W obecnych czasach jest to troszeczkę trudne, bo cała komunikacja poprzez internet jest w miarę możliwości lepiej albo gorzej szyfrowana. W tym momencie najsłabszym ogniwem zabezpieczeń jest jak zwykle użytkownik. Jeżeli użytkownik jest w stanie np. wymienić wszystko na co ma ochotę w systemie, to równie dobrze – świadomie albo nieświadomie – może wprowadzić całą masę dziur bezpieczeństwa. Więc z jednej strony to jest zaleta, z drugiej to jest wada, ale w obecnych czasach myślę, że trzeba rozróżnić bardzo między zastosowaniem domowym, w którym komputer nie ma wystawionych na świat zewnętrznych żadnych usług, żadnego dostępu sieciowego, a zastosowaniem bardziej profesjonalnym. I do takich bardzo prostych rzeczy myślę, że możliwość grzebania w systemie jest dosyć przyjemną sprawą.
System AmigaOS nie ma nawet przewidzianej takiej rzeczy jak tworzenie profili użytkownika. Ale jest jedna rzecz, która mnie zawsze nurtowała i muszę o nią zapytać. Czy jest, albo będzie kiedyś, zapotrzebowanie na komputer „offline”? Bo teraz jest komputer spięty z internetem, praktycznie komputer bez internetu dla wielu osób jest bezużyteczny. Czy według ciebie Amiga w jakiejś tam formie w przyszłości mogłaby wejść w taką niszę i być takim komputerem właśnie nie spiętym z internetem, prawdziwie osobistym komputerem? Jakby to powiedzieć „Personal Computer”, ale całkiem nowe pojęcie.
Pytanie jest tylko co na takiej Amidze mielibyśmy robić. Mi się wydaje że – nawet jeżeli niektórzy amigowcy tego nie przyznają otwarcie – stoimy naprawdę przed olbrzymim problemem, którym jest brak oprogramowania i brak zainteresowania świata naszym systemem. Bo co tak naprawdę możemy zrobić w tym momencie na Amidze? Nawet jeżeli jest niepodłączona do sieci. Jest niepodłączona do sieci? Okej, ale w momencie w którym chciałbym wysłać do kolegi e-maila, albo napisać mu jakąś wiadomość, albo tak jak teraz np. cała masa amigowców komunikuje się przez Discorda – tego w tym momencie już byś nie miał. A jeżeli chcielibyśmy na przykład o takim bardzo osobistym komputerze porozmawiać, który nie jest od sieci odcięty, to dochodzimy do kolejnego problemu, którym jest brak oprogramowania. Nie chcę tutaj szerzyć czarnowidztwa, bo obawiam się że wiele osób bardzo chętnie by na mnie psy powiesiło za takie wypowiedzi, ale wydaje mi się że – jeżeli z tej perspektywy patrzeć – to klasyczna Amiga, albo AmigaOS nawet w zaawansowanej formie na procesor PowerPC tak jak jest MorphOS albo OS 4, albo tak samo jak AROS – to są systemy, które swoją szansę, swoją okazję już troszeczkę przespały i niestety cały pociąg nazywany światem odjechał już dalej, a my tak zostaliśmy w swoim ogródku. I możemy się tym bawić, możemy się tym cieszyć, ale nie oczekiwałbym że jesteśmy w stanie w jakiś sposób wygrać jakąkolwiek niszę dla nas albo zawojować świat. Niestety. Przykro mi że tak marudzę, i to jest jeden z powodów dla których zawsze próbuję unikać wywiadów, bo w momencie w którym pojawiają się trudne pytania mam tendencję do raczej realistycznego albo negatywnego spojrzenia na tematykę. Powiedzmy, że taki radosny optymista już jakoś ze mnie troszeczkę uleciał dawno temu.
Trochę szkoda. Ale otwarte pytania, otwarta dyskusja, wymiana myśli, zawsze jest warta czasu. Przechodzimy pomału do AROS-a. Masz taki swój projekt Emu68 i czy mógłbyś podzielić się założeniami finalnej wersji jakie przyjąłeś na ten moment?
Bardzo chętnie. Zaczęło się od tego, że pracowałem nad AROS-em dla procesorów ARM (w sensie RaspberryPi) i tam mieliśmy po pierwsze możliwość zrobienia czegoś bardziej amigowego na bardzo tani komputer, bo to jest jeden z bardzo ważnych czynników. Nawet jeżeli, tak jak wcześniej wspomniałem, nie mamy już szans zawojować świata, jeżeli mamy wypuszczać nowe wersje systemów – to coś takiego jak np. mała „malinka”, która kosztuje naprawdę małe pieniądze i pozwala użytkownikowi bawić się na tysiąc możliwych sposobów, jest bardzo ciekawą alternatywą dla amigowych systemów. Zacząłem na „malinę” z AROS-em i w którymś momencie zastanawiałem się, czy można by było jakoś wykorzystać to, że procesory ARM w większości są w stanie pracować w trybie Little Endian i Big Endian. Postanowiłem spróbować cały port AROS-a przenieść właśnie na Big Endian, czyli dokładnie na taki sam (kolejność bajtów) jak mamy w procesorach Motoroli albo PowerPC. I w jakiś sposób nawet to działało, dosyć sprawnie; było potrzebnych parę poprawek, ale ogólnie funkcjonowało to, w lepszy albo gorszy sposób. W którymś momencie doszedłem do wniosku, że można by było do takiego systemu dorzucić jeszcze emulację procesora Motoroli, skoro już pracujemy w tym samym endianie. Ale brakowało mi do tego jakiegokolwiek emulatora. Jedną z bolączek świata Open Source jest niekonieczna kompatybilność licencji między sobą. Wszystkie emulatory jakie znalazłem, które byłyby w stanie zaemulować procesor Motoroli, były na licencjach niekompatybilnych z licencją AROS-a i to była bardzo fajna okazja, żeby spróbować samemu. Nigdy jeszcze czegoś takiego nie robiłem, ale lubię nowe wyzwania. Stwierdziłem, że „dobrze, spróbuję – raczej nie powinno boleć, a efekt może być interesujący”.
Wracając do tego emulatora, żadnego nie znalazłem i stwierdziłem, że spróbuję sobie zrobić samemu. No i spróbowałem. Troszeczkę to na początku zajęło. Powiedzmy pierwsze parę tygodni żeby w jakikolwiek sposób wypracować sobie metodologię robienia takiego emulatora, bo nigdy wcześniej tego nie robiłem. To jest emulator Just In Time, czyli taki który kompiluje kod Motoroli w locie do kodu procesora ARM i to wykonuje. W którymś momencie zaczęło to w miarę sensownie działać, zacząłem przeprowadzać testy i okazało się, że całość działa dosyć szybko. I w tym momencie zacząłem się zastanawiać nad pewną rzeczą; mianowicie w przypadku AROS-a jest tak, że system na 32 bitowe platformy występuje w różnych wariantach dla różnych procesorów. Mamy AROS-a dla procesorów Intela, mamy AROS-a dla procesorów PowerPC, mamy AROS-a dla procesorów ARM w trybie Little Endian, zaczął powstawać AROS dla procesorów w trybie Big Endian, do tego jeszcze inne architektury mogą się pojawić i w tym momencie one między sobą są niekompatybilne. Czyli program powiedzmy dla Intela nie może być uruchomiony na Motoroli i vice versa. I ogólnie jakakolwiek kombinacja nie jest tutaj możliwa. Do tego trzeba dla każdej wersji AROS-a wypracować odpowiedni interfejs binarny, także to jak mają pliki wykonywalne wyglądać. I w tym momencie zacząłem się zastanawiać: skoro emulacja samego procesora może być naprawdę szybka – a w tym momencie w aktualnej wersji mówimy o wydajności, która dochodzi do 30% prędkości natywnego kodu – można potraktować asembler Motoroli albo kodu dla procesorów Motoroli jako taki uniwersalny bajtkod, mniej więcej taki sam jak jest w C# albo w innych językach, w których kod jest na początku kompilowany do jakiegoś formatu przejściowego, a dopiero w czasie wykonania ten format przejściowy jest tłumaczony na wersję dla konkretnego procesora. Przyszło mi na myśl, że coś takiego można by było zrobić z AROS-em, żeby na przykład w 32 bitowym trybie każda wersja AROS-a pracowała w zasadzie tylko i wyłącznie na emulacji procesora Motoroli. Może gdzieś w przyszłości z możliwością uruchamiania kodu natywnego np. dla Intela, dla ARM-a, albo dla czegokolwiek innego, ale ogólny zamysł był taki, że w momencie kiedy Emu68 było już kompletne, powstanie na tą wersję osobna wersja AROS-a, która będzie pracowała tylko i wyłącznie w trybie 68k na RaspberryPi. Jeżeliby to działało w miarę sensownie, można by było się pokusić o podobny rodzaj emulatora pracujący bezpośrednio na Intelu. Tak samo można by było zrobić dla PowerPC i tak dalej.
Czy ten Emu będzie systemem 32 bitowym?
Tak, to byłby system 32 bitowy, dokładnie tak samo jak jest procesor Motoroli. W tym momencie działa on na procesorach ARM w trybie 32 bitów i w 64 bitach, przy czym w 64 bitach nadal emulowany jest procesor 32 bitowy. Tak że to by była taka platforma retro, bo – nie ma co się oszukiwać – wszystkie amigowe systemy są systemami retro, nawet jeżeli są w tym momencie w miarę zaawansowane. To by była platforma retro pracująca w 32 bitach i do tego się ograniczająca.
Załóżmy, że dałoby się na tym uruchomić oprogramowanie natywne amigowe, to co się nie odwołuje do czipsetu. A jak wygląda sprawa z programami z AROS-a? Nie wiem czy dobrze cię zrozumiałem, trzeba kompilować dla każdej wersji AROS-a oddzielnie, czyli one są niewymienne. Czyli program z AROS-a nie mógłbyś przenieść od razu do takiej dystrybucji?
Od razu programu z AROS-a np. w wersji x86 albo x86_64 nie byłbym w stanie na niej uruchomić, musiałbym ją skompilować dla procesora 68K. Czyli praktycznie kompletna arosowa dystrybucja dla Motoroli byłaby 1:1 używalna.
Czyli można powiedzieć, że robisz taką wariację Amigi pod wirtualny procesor zgodny z Motorolą?
Dokładnie. Przy czym emulowany jest naprawdę tylko i wyłącznie procesor, więc np. w tej chwili tak jak jest, to na Raspberry jestem w stanie w assemblerze 68K, najbardziej niskopoziomowo jak tylko się da, programować wszystkie komponenty z Raspberry. I tak by to mniej więcej działało. Tak że byłby to system bez czipsetu, to byłoby coś bardzo podobnego do komputera Draco, który kiedyś pojawił się na rynku – on też nie miał czipsetu, miał praktycznie tylko procesor, łatki na system i całą resztę. Później w przeszłości pojawiła się jeszcze próba, która się nazywała Amithlon. Konceptem tego systemu było mniej więcej to samo co ja w tej chwili robię, tylko że Bernie Meyer spróbował jeszcze w międzyczasie pracować z Linuksem, żeby nie walczyć z ogromem różnorodności sprzętu od peceta. On się posiłkował kernelem Linuksa, ale zamysł też był taki, że uruchamiała się jakaś bardzo cienka warstwa z emulacją procesora na komputerze, w tym przypadku na pececie, a cała reszta systemu pracowała z kodem Motoroli.
Czyli coś takiego jak chciał zrobić kiedyś Jim Collas z Gateway?
Tak
A jak bardzo zaawansowane są prace nad projektem Emu68?
Prace są zaawansowane na tyle, że praktycznie pełen zestaw instrukcji dla Motoroli jest już zaimplementowany. Koprocesor jest zaimplementowany w dużej części, brakuje kilku funkcji trygonometrycznych, cała reszta działa. Działają przerwania, działają wyjątki procesora, w tym momencie robię tylko małe poprawki I jednocześnie zająłem się już portowaniem AROS-a na ten procesor.
Gdzie widzisz zastosowanie swojego oprogramowania? Bo są różne spekulacje, czy jego miejsce mogłoby się znaleźć np. w projektach kart turbo dla Amig od Commodore, czy może jeszcze coś zupełnie innego?
Jest taki projekt, który się nazywa Pi Storm. Robi go Claude Schwarz z Niemiec i to jest w sumie emulator procesora 68K, który bazuje na RaspberryPi. Tam w tej chwili jest uruchomiony mały Linuks, na tym Linuksie pracuje emulator Musashi, czy jakkolwiek on się tam nie nazywał. To jest taki interpreter, który jest używany na przykład w różnych emulacjach konsol itp. rzeczy, tylko że ten emulator (przez to że jest interpreterem) jest dosyć powolny, ale Claude zaczął nad tym dzielnie walczyć. Udało mu się zrobić kartę turbo do Amigi 500, która jest zakładana zamiast oryginalnego procesora; na tym uruchamiany jest emulator i ten emulator emuluje konkretny procesor. W tym momencie z Claudem jestem w kontakcie mniej więcej od dwóch miesięcy i jesteśmy na takim etapie, że w najbliższym czasie będziemy próbowali przenieść Emu68 do jego emulatora.
Czyli współpraca. Nie ma tak, że robisz dla siebie do szuflady?
Powiedzmy tak: ja lubię robić dużo różnych dziwnych rzeczy, ale projektami zwykle się dzielę. Przez tyle lat pracy w AROS-ie nauczyłem się tego, że kiszenie w szufladzie nie ma naprawdę sensu. Bo tak naprawdę kończy się to tym – i w światku amigowym widzieliśmy to niejednokrotnie – że kilka osób zaczyna pracę nad tym samym, lub bardzo podobnymi rzeczami i nie rozmawiają ze sobą, bo dlaczego mieliby rozmawiać z deweloperami innych systemów. Jest jedna wielka kłótnia, jedno wielkie nieporozumienie, ja się trzymam od tego z daleka. Ja się staram nie wnikać w żadne wojenki, a wszystko co robię staram się upubliczniać. Każdy sobie może spojrzeć chociażby na GitHuba, na którym trzymam całą masę swoich projektów – wszystko jest otwarte, wszystko jest na liberalnych licencjach, każdy może brać i używać (albo i nie).
Jak duży procent wolnego czasu poświęcasz na pracę nad projektem?
W miarę możliwości dosyć duży procent wolnego czasu. Działa to mniej więcej tak, że jeżeli żona siedzi w biurze i pracuje, to ja się dosiadam też do komputera i czasami pogram sobie w Minecrafta, ale przez większość czasu siedzę i klepię w klawiaturę. Wtedy jestem powiedzmy nieosiągalny i niekomunikowalny ze światem zewnętrznym.
A czy masz jakieś inne projekty amigowe oprócz Emu68?
Z amigowych projektów tak, mam parę rzeczy jeszcze rozgrzebanych. Jedną z nich jest benchmark wydajności. Zaczęło się od tego, że w Emu68 musiałem jakoś testować wydajność. Napisałem, albo przekompilowałem sobie dla procesora M68K benczmark, który renderuje scenę w 3D. Przy czym on używa techniki śledzenia promieni, która jest dosyć intensywna dla procesora. No i zamierzam przenieść ten sam benchmark na prawdziwe Amigi, żeby można było mieć test, który nie wykonuje się przez 5 albo 10 sekund, tylko obciąża naprawdę komputer na godzinę, dwie, trzy albo cztery. Coś podobnego do tego „jubimarka”, o którym było niejednokrotnie dyskutowane na PPA. Tyle że „jubimark” np. to rendering sceny w LightWave, czyli wymaga mniej lub bardziej legalnej kopii programu. On sobie otwiera ekran w low resie w trybie HAM, rysuje na ekranie i podaje ile czasu mu to zajęło. To jest jedna rzecz. Poza tym to co jeszcze? Zacząłem dwa tygodnie temu, ale to jest tylko i wyłącznie zabawa (tyle że ją też opublikuję na sieci, bo dlaczego nie), zacząłem w Verilogu pisać moją własną reimplementację procesora 68K. Przy czym mówię: nie wydaje mi się, żeby coś z tego było, ale jeżeli ktoś będzie uważał, że można z tym coś zrobić albo można z tym coś zacząć, to będzie mógł się do tego dobrać. To jest mniej więcej to samo co Emu68, tylko nie na konkretny procesor, a napisany w Verilogu. Czyli skompilowany do takiej postaci, w której może to być jako strumień bitowy załadowany do FPGA, żeby można było sobie zaimplementować procesor Motoroli, mniej lub bardziej odpowiadający czemuś rzeczywistemu
Co z AIRIX-em? Opowiedz ogólnie o koncepcji tego systemu i czy będziesz rozwijał dalej ten projekt?
To jest projekt, który w sumie w którymś momencie będzie dalej rozwijany. On w tym momencie rozwija się bardzo powoli, bo rozwija się tylko i wyłącznie wtedy, gdy kiedy nie jestem zajęty czymkolwiek innym, a ja niestety mam tendencje do tego, że skaczę po tysiącu tematów, ale w którymś momencie też się znowu do niego zabiorę. To jest koncepcja, która krążyła mi w głowie od czasów studenckich, więc to będzie jakieś 20 lat temu. Chodzi mniej więcej o to, że chciałem tutaj wykorzystać kernel Linuksa, ale tylko i wyłącznie kernel, i na tym kernelu napisać zestaw bibliotek i zestaw programów, które mniej więcej odpowiadałyby temu co mamy w systemie AmigaOS. Przy czym w wypadku AIRIX-a jest tak, że starałem się odtworzyć biblioteki albo funkcje systemowe; nie w 100%, ale tylko i wyłącznie w takim zakresie jaki jest możliwy z wykorzystaniem kernela linuksa. Czyli np. w oryginalnym amigowym systemie w bibliotece Exec jeżeli wymieniamy wiadomości między procesami, to tak naprawdę wymieniany jest tylko wskaźnik do wiadomości, bo wiadomości znajdują się w pamięci RAM. Wszystkie programy pod Amigą, wszystkie procesy, wszystkie zadania mają dostęp do całej pamięci, więc nie było sensu kopiować wiadomości. Rozwiązanie samo z siebie jest super, bo jest bardzo szybkie, co pokazała już klasyczna Amiga 1000, która z bardzo słabo taktowanym procesorem posiadała naprawdę fenomenalną wydajność. Ale ma to swoje wady, bo na przykład wtedy automatycznie ochrona pamięci jest wykluczona. To co ja zacząłem robić w ARIX-ie to są chociażby takie podstawowe zmiany, czyli wiadomości są przekazywane nie jako wskaźnik, a jako wartość. Używam do tego niskopoziomowych mechanizmów z Linuksa. Koncept jest ogólnie taki, żeby stworzyć system operacyjny (albo biblioteki plus system operacyjny), który by odtwarzał w miarę podobnie łatwość amigowego systemu z jego prostymi bibliotekami, z jego szybkim czasem startowania itd, ale żeby jednocześnie bazował na nowszych technologiach jak chociażby kernel Linuksa.
Ja się obawiam właśnie… Z tego co ludzie marudzą przeważnie na AROS-a to na przykład jest taki zarzut, że po co było tworzyć coś niekompatybilne z MUI.
W tym przypadku to nawet wiem z której strony się ten zarzut pojawia. Z jednej strony tak, a z drugiej strony biblioteki MUI zawierają całą masę zachowań, które nie są w żaden sposób opisane w dokumentacji. W tym momencie nie jest fizycznie możliwe żeby odtworzyć cały zestaw tych bibliotek samemu tylko i wyłącznie z dokumentacji. W przypadku systemu AmigaOS dokumentacja jest o wiele lepsza i jest to możliwe, ale w przypadku MUI już nie. Więc to nie jest tak, że my celowo robimy niekompatybilną bibliotekę, ale robimy ją na tyle kompatybilną na ile jest to wykonalne. Okej, było parę zmian, które wprowadziliśmy celowo, przy czym to już lata temu było dyskutowane jeszcze na liście mejlowej. Chodziło mniej więcej o to, że niektóre wiadomości w MUI są zapętlane na swój sposób i w AROS-ie chcieliśmy tego uniknąć. Bo w przypadku błędów programistycznych może to doprowadzić do całkowitego zablokowania GUI (czyli graficznego interfejsu użytkownika) i tego chcieliśmy uniknąć u nas. Tak więc wprowadziliśmy jedną albo dwie zmiany, które wynikały z naszych decyzji, a reszta to są po prostu zachowania niezdefiniowane albo nieopisane przez dokumentację od MUI, więc nie jesteśmy tego w stanie zrobić lepiej.
Chciałem dopytać o bolączki amigowych systemów – czego nie da się tam zrobić łatwo, np. ochrony pamięci itd.?
Ochrony pamięci nie da się zrobić łatwo, bo – tak jak już wspomniałem – chociażby sam fakt, że wiadomości są zmieniane tylko przez wskaźniki, prowadzi do tego, że wszystkie programy, które wymieniają między sobą wiadomości, muszą korzystać z tej samej pamięci. Można próbować to obejść, można próbować tworzyć nowe rodzaje pamięci, które są prywatne tylko dla każdego procesu z osobna, ale to ma też swoje wady. Na przykład w przypadku AROS-a zastanawiałem się nad tym, żeby każde zadanie albo każdy proces miało własny stos we własnej przestrzeni adresowej, taki do którego nikt inny nie ma dostępu; ale chociażby z powodu wymiany wiadomości między zadaniami takie coś też już jest niewykonalne. Bo np. nikt nie może programiście zabronić, żeby stworzył sobie powiedzmy jakąś tablicę na stosie i do tej tablicy załadował dane za pomocą biblioteki DOS, która musi zrobić odwołanie do systemu plików; system plików jest w osobnym zadaniu i on musi mieć możliwość zapisania pamięci do prywatnego stosu innego zadania. Byłoby to już w tym momencie niewykonalne. Dokładnie tak samo jest z przekazywaniem wiadomości. Niektóre programy używają do tego celu stosu, co jest niezbyt dobre, ale niestety pojawia się – nie jesteśmy w stanie tego przeskoczyć, mleko się wylało, programiści tak to napisali, nie da się tego zmienić.
Co innego jest np. z SMP, czyli z wykorzystaniem wielu procesorów. Takie coś wprowadzić do systemu amigowego też jest szalenie trudno. I jedne i drugie rozszerzenie systemu gryzie się z tym co już wcześniej powiedziałem, plus jeszcze dochodzi do tego taki, że wszystkie biblioteki, wszystkie struktury systemowe w AmigaOS są udokumentowane, są używane przez użytkowników oprogramowania albo przez programistów. Nie jest tak jak w innych systemach, gdzie powiedzmy otwierasz sobie okno i dostajesz uchwyt do tego okna, w jakimś Windowsie, ale tak naprawdę nie wiesz co ten uchwyt posiada, co to jest, to jest po prostu jakaś 32 bitowa liczba albo 64 bitowa liczba i z nią pracujesz. Jeżeli chcesz np. z takiego windowsowego okna wyciągnąć jakieś informacje, albo ustawić jakieś parametry – używasz osobnych funkcji, w których podajesz uchwyt do okna i np. parametry, które chcesz zmienić. W amigowym systemie dostajesz wskaźnik na strukturę okno (to jest tylko jeden przykład, ale takich przykładów w amigowych systemach jest cała masa) i w tym momencie programista w tej strukturze może praktycznie pozmieniać wszystko na co tylko ma ochotę, bo wszystko jest udokumentowane. I w tym momencie, jeżeli np. chcielibyśmy wprowadzić ochronę pamięci w takich rzeczach już nie jesteśmy w stanie. W przypadku wieloprocesorowości są w bibliotece Exec struktury, które też na to nie pozwalają. Mamy różne funkcje blokujące wielozadaniowość, blokujące przerwania, nie wiadomo jak można by to było tak sensownie zrealizować przy wielu procesorach. Tak samo jest chociażby z przejściem na 64 bity. Dobrze, klasyczna Motorola tego nie potrafi, ale mamy OS 4, mamy MorphOS-a na procesory, które istnieją też w wersjach 64 bitowych – coś takiego też jest tylko w połowie wykonalne Czyli mniej więcej w taki sposób jak to zrobiliśmy z AROS-em, że jeżeli masz system 64 bitowy – automatycznie zrywasz całkowicie kompatybilność z 32 bitowym oprogramowaniem Na innych systemach, np. na Windowsie albo Linuksie czegoś takiego nie ma, między innymi dlatego, że system broni się przed programistą grzebiącym w jego „wnętrznościach”. Wrócę jeszcze do tego przykładu – dostajesz uchwyt do okna i co system z tym uchwytem do okna robi to jest tylko i wyłącznie sprawa systemu. W amigowych systemach tego już nie ma.
Nie dałoby się tego zrobić jakoś w ten sposób rozwiązać, że wszystkie stare klasyczne oprogramowanie działa w określonej pamięci, np. między 1 a 2 GB RAM? Taką jakby piaskownicę na to zrobić?
Można i taka piaskownica nazywa się UAE. Czyli można by było całe klasyczne amigowe oprogramowanie uruchamiać pod emulatorem, a system mieć po prostu nowy. Przy czym to jest też problematyczne, bo dużo amigowców czuje szalenie intensywne przywiązanie do klasycznego systemu i albo boją się, albo nie chcieliby takiej zmiany. Powiedzmy, że istnieje dosyć intensywny, dość duży opór.
Mówiłeś o SMP. Nie wszystkie osoby są techniczne, jakbyś mógł rozwinąć troszkę temat SMP: czym się różni obsługa SMP od obsługi kilku rdzeni w procesorze? I w kontekście tego: wiele osób może nie rozumieć, że jak to jest że Amiga obsługiwała dawniej kilka układów procesorów, bo były te układy specjalizowane, a teraz jest jakiś wielki problem coś dołączyć?
To jest tak, że układy specjalizowane to jest zupełnie inna historia. W przypadku SMP (to się nazywa symetryczna wieloprocesorowość) wszystkie procesory w systemie (tego samego rodzaju oczywiście) działają na równych uprawnieniach. Więc np. jeżeli uruchamiam jakiś program, jakiekolwiek zadanie, ono może pracować na dowolnym z tych procesorów. I tak naprawdę ani programistę, ani użytkownika nie interesuje na który procesorze to pracuje. Jeżeli taki program uruchamia wiele różnych procesów, wiele różnych wątków w obrębie samego siebie – one też mogą być rozdzielone między różne procesory i to należy do zadań systemu operacyjnego (decyzja na którym procesorze , na którym rdzeniu procesora, dana część zadania będzie wykonywana). System operacyjny może tym zarządzać, w zależności od tego jak bardzo który procesor jest obciążony. Równie dobrze można mieć procesory wykonujące taki sam rodzaj kodu, ale np. różniące się wydajnością. Tak mamy w przypadku całej rodziny ARM. Tam jest technologia, która się nazywa big.LITTLE, czyli jest kilka rdzeni energooszczędnych, które są dosyć powolne, ale za to pobierają mało prądu w czasie pracy i jest kilka rdzeni, które są bardzo wydajne, ale jednocześnie pobierają bardzo dużo prądu. I w tym momencie system operacyjny jest w stanie zarządzać, w zależności od tego ile ma dostępnej energii, jakie jest zapotrzebowanie użytkownika – czy zadanie pracuje bez przerwy, czy zadanie pracuje tylko krótko. System operacyjny może je rozdzielać albo na szybsze, albo na wolniejsze procesory i w ten sposób zarządzać całą energią.
W amigowych systemach czegoś takiego tak naprawdę nigdy nie było. Jeżeli mieliśmy procesory specjalizowane, no to po prostu każdy zajmował się swoim własnym rodzajem kodu. Powiedzmy mieliśmy, albo nadal mamy, Coppera, który wykonuje swój własny program i tworzy za pomocą tego programu obraz, ale to są rzeczy które nie są programowane tak jak w przypadku SMP. W takim przypadku rozdzielam: „okej, to jest akurat program Coppera – on będzie wykonywany przez Coppera; to jest program dla procesora – to będzie wykonywał procesor”. Nie mogę zrobić tak, że napiszę sobie program i system operacyjny wybierze mi co z tego będzie wykonane przez który podzespół komputera. To leży tylko i wyłącznie w kwestii programisty. Coś podobnego można zrobić w przypadku procesorów, technika nazywa się AMP czyli asymetryczna wieloprocesorowość. W tym przypadku procesor główny, albo ten wybrany podczas startu, jest kontrolowany przez system operacyjny i na nim pracuje system operacyjny i całe oprogramowanie, a programista może na przykład zarządzać jeszcze dodatkowymi mocami obliczeniowymi i decydować: „okej, mam tutaj dodatkowe procedury, które mogą być wykonane równolegle; proszę system operacyjny, żeby je wykonał powiedzmy w 10 kopiach na tylu dodatkowych procesorach na ilu jest to możliwe”. Coś takiego można by było pod amigowym systemem zrobić, ale trzeba było by pilnować dosyć intensywnych restrykcji, np. im więcej dałoby się zabronić takim dodatkowym procesorom, tym sprawniej by to funkcjonowało albo tym mniej nakładu byłoby potrzebne żeby to zrealizować. Na przykład jeżeli powiedzielibyśmy, że dodatkowe procesory mogą wykonać tylko i wyłącznie kod, ale nie mogą korzystać z żadnych systemowej biblioteki żeby to gdziekolwiek pokazać, przerobić, przetworzyć – to takie coś byłoby dosyć łatwe do wykonania. To by było dosyć podobne do tego co już mieliśmy w dawnych czasach, kiedy mieliśmy system operacyjny na motorolce i mieliśmy kartę turbo z PowerPC; na tym PowerPC pracowała własna wersja nie amigowego systemu operacyjnego tylko czegoś innego, ale pozwalało to na rozdzielenie kodu na parę zadań. Coś takiego byłoby w miarę wykonalne pod Amigą, ale z olbrzymimi ograniczeniami.
Mam takie pytanie nie związane z AROS-em, ale czuję, że możesz coś wiedzieć na ten temat. Jest (był) taki projekt Xena i Xorro i Dickinson to wtedy tłumaczył, że sięga do idei transputera. Kojarzysz to pojęcie na pewno. I jak widzisz w ogóle, czy jest możliwe współcześnie zastosowanie tego, w naszym oczywiście odniesieniu, w naszych współczesnych amigach?
Jak najbardziej. Sama idea jest bardzo ciekawa i daje dużo interesujących możliwości, ale wykonanie jest troszeczkę niewłaściwe.
Jak byś to zrobił?
Zrobiłbym to przede wszystkim tak, że cały ten układ udostępnił bym na osobnej karcie, nawet jeżeli miałaby być wewnątrz komputera na slocie PCI albo PCI Express albo na czymkolwiek, ale żeby to było w jakiś sposób oddzielone od komputera. Bo w tym momencie jeśli posiadałbym taki komputer jak Amiga X1000 czy tam X5000, jeżeli miałbym wydać naprawdę grube pieniądze żeby kupić taki komputer, a potem w ramach eksperymentów chciałbym do niego podpiąć kilka kabelków, mając świadomość tego że jeżeli zadrży mi lekko ręka, albo jeżeli coś przeoczę, coś podłączę nie tak, to w najlepszym razie spalę tylko Xenę – ona jest na płycie głównej i ona w tym momencie już jest nieużywana, a w najgorszym razie taka Xena zepsuta, spalona pociągnie za sobą cały komputer – to w tym momencie od strony elektronika-hobbysty, który lubi sobie poeksperymentować, bałbym się cokolwiek do tego podłączyć. Jeżeli Xena byłaby chociażby w trochę inny sposób podłączona do komputera, żeby w przypadku błędu dało się ją wymienić powiedzmy za 200 euro, to z bardzo dużym bólem ale można by z tym eksperymentować. Ale jeżeli bawiąc się w elektronikę ryzykuję zepsucie komputera, który kosztuje 1000 euro albo więcej, to niestety to nie jest dobra droga. I w tym momencie większość elektroników hobbystów raczej zdecyduje się na procesory z tej samej serii, które można kupić na płytkach eksperymentalnych podłączanych przez port USB do komputera. I w tym momencie cały koncept Xeny na płycie głównej mija się z celem, bo prawdę powiedziawszy wolałbym eksperymentować z takim małym urządzeniem USB. Jeżeli się zepsuje – okej, trudno, mogę kupić nowe (albo też nie kupię, bo mi się odechce). Albo z czymś takim jak Raspberry Pi, który też kosztuje śmieszne pieniądze i pozwala ludziom eksperymentować, a ryzyko błędu nie jest dość drogie.
Ludzie kojarzą temat z filmiku z migającymi diodkami, a to był tylko pokaz, że wszystko działa. Powstała karta do debugowania, która zapisuje logi na karcie pamięci, ale to jedyny projekt. Niedawno szukałem informacji na temat tego układu XMOS, to jedyne zastosowanie tego czipu co wylądował w naszych amigach znalazłem w jakimś sprzęcie hi-fi, zdaje się że zaletą jest obsługa w czasie rzeczywistym.
Dokładnie, te układy cechują się między innymi tym, że mają bardzo szybką reakcję na zmianę stanów na portach I/O, więc z technikami programistycznymi można bardzo wiele na nich zdziałać. Dodatkowo można je łączyć w różne macierze komunikujące się między sobą, itd. Tak że ogólnie to rozwiązanie jest ciekawe, tylko że ograniczone technologicznie przede wszystkim do dosyć wąskiego zakresu zastosowań, no i niestety wydaje mi się że tutaj znowu amigowcy albo producenci sprzętu do amigi troszeczkę zawiedli. Tym bardziej, że na początku – nie wiem jak w tej chwili, dawno nie patrzyłem – na początku było tak, że pojawiała się cała masa różnych pogłosek, prawd, półprawd i wyobrażeń. Nie powiem kłamstw, bo informacje pochodziły od użytkowników, którzy podchodzili bardzo optymistycznie – to nie są kłamstwa, ktoś sobie po prostu coś źle wyobrażał. Ale na przykład ktoś tam zauważył, że Xena jest podłączona na zewnątrz do złącza PCI Express i automatycznie wyszedł z założenia, że skoro jest takie złącze, to na pewno jest wydajność taka jak PCI Express, czyli wiele gigabajtów na sekundę, „och jak fajnie!”. No i niestety żaden z producentów nie zdementował takich informacji, więc całe środowisko amigowe znowu żyło marzeniami, wyobrażeniami, a osoby które by mogły coś na ten temat powiedzieć nabierały wody w usta, co jest jak dla mnie karygodne.
Tam zdaje się najwięcej marzeń było odnośnie stworzenia karty która by odciążała emulację klasyka. Po prostu żeby ją wpiąć i ona robiła – nie wiem jak to nazwać – odpowiednik Vampire?
O wiele sensowniejszym rozwiązaniem w tym wypadku byłoby stworzenie emulacji czipsetu na szynie PCI albo PCI Express, która wtykałoby się w taką amigę. Ona by się przedstawiała jako 16 MB przestrzeni adresowej i zawierałaby w sobie cały wsad.
I to według ciebie jest realne do zrobienia? Na czym?
Na dowolnym układzie FPGA z firmy Xilinx chociażby, tam mamy całą serię Artix-7, która ma gotowe czteroportowe złącze PCI Express, które można wykorzystać. Sam układ FPGA tej klasy kosztuje mniej więcej 50 euro, myślę że całość zmieściła by się w 100-150 euro.
Można powiedzieć, że jak na amigowe warunki to taniocha.
Dokładnie. W tym momencie to jest takie tylko gdybanie, bo trzeba by było takie coś sensownie, realnie zaprojektować, żeby można było oszacować czy to ma sens i czy mieścimy się w ramach cenowych powiedzmy.
Bo widzisz, jedną z bolączek środowiska jest to, że osoby które mają wiedzę techniczną niekoniecznie czują potrzebę wypowiadania się na forach; stąd biorą się różne spekulacje, które później się zwielokrotniają i latami krążą, co by to nie można było zrobić. Tak jak ci co mają Vampire i mają takie powiedzonko „wrzuci się w FPGA” jakby to było z gumy.
Przez jakiś czas współpracowałem z grupą Apollo i marzenia o tym, co się wrzuci w FPGA, a co nie, często są bardzo brutalnie weryfikowane przez ilość wolnego miejsca na układzie. To nie jest aż takie proste.
Wróćmy do AROS-a, bo w ty jesteś ekspertem i współtwórcą tego systemu. Powiedz mi jak w obecnej chwili wygląda środowisko deweloperów robiących coś przy AROS-ie, to znaczy aktywność i współpraca?
W przypadku AROS-a tak było praktycznie od zawsze, że deweloperzy przychodzą i odchodzą, mają lepsze albo gorsze okresy aktywności. W tym momencie jest tak, że Nick Andrews, którego ludzie w internecie znają jako ‘Kalamatee’, dosyć intensywnie pracuje. On niestety boryka się z całą masą prywatnych problemów, o których nie chcę tutaj mówić, ale w tym momencie ma bardzo twórczy okres pracy nad AROS-em, W moim przypadku jest tak, że czasami bardziej intensywnie nad tym pracuje, czasami mniej. W tym momencie mam inne projekty na głowie, więc AROS-a używam jakbym był osobą trzecią, spoza drużyny. Jest jeszcze kilka osób, które robią testy, ewentualnie aktualizują tłumaczenia językowe itd, ale na dzień dzisiejszy AROS rozwija się dosyć powoli. Mam nadzieję, że to się zmieni w przyszłości.
Ja nie rozumiem, i większość osób nie rozumie: jeżeli jest kilka osób, które się zajmują AROS-em, no to skąd tyle tych dystrybucji? Może byś wytłumaczył to zamieszanie, kto którą dystrybucje rozwija i która jest przyszłościowa?
Z dystrybucji znam i używałem przez chwilę jednej, to jest Icaros. To jest najbardziej popularna dystrybucja, którą robi Paolo Besser, sympatyczny chłopak z Włoch. To jest mniej więcej tak: to są osoby, które nie zajmują się programowaniem. W przypadku AROS-a to jest tak, że mamy swoje repozytorium, mamy swoje Nightly Builds, czyli system który buduje AROS-a automatycznie co 24 godziny i udostępnia w sieci i to są rzeczy nietestowane. Nie da się po prostu tego permanentnie testować. Osoby, które tworzą dystrybucje, wybierają z tych Nightly Builds, które udostępniamy w sieci to, co u nich funkcjonuje najlepiej i z tego budują całą dystrybucję. To ma tę zaletę, że oni mogą się skoncentrować nie na tworzeniu systemu i programowaniu, tylko na złożeniu czegoś, co użytkownikowi na końcu udostępnia gotowy system, którego może używać. Dystrybucje można porównać chociażby z systemem MorphOS albo AmigaOS 4, które też są w sumie gotowym zestawem oprogramowania, programów dodatkowych, jest tam ewentualnie wrzucone parę gier itd, albo dystrybucji linuksowych. Bo żaden użytkownik Linuksa, albo prawie żaden, nie jest na tyle szalony żeby wziąć sam kernel i skompilować do tego wszystkie biblioteki GNU i tworzyć to wszystko samemu od zera.
Czyli osób, które rozwijają sam rdzeń systemu AROS jest bardzo niewiele?
Niestety w tej chwili tak.
Jakich używasz narzędzi, jaki jest twój warsztat pracy? Nie oczekuję, że powiesz że robisz na Amidze.
Nie, nie robię na Amidze. Wszystko co robię robię albo na mekintoszach albo na pecetach. Używam głównie systemu macOS. Mam do tego kilka wirtualnych maszyn: jedna z Windowsem, jedna z Linuksem; nie jestem pod tym względem jakimś fanatykiem, z tego już wyrosłem, to wszystko są dla mnie narzędzia. Porównując do świata nieprogramistycznego: jeżeli uwielbiam śrubokręty to nie będę wbijał gwoździa za ich pomocą, tylko powiem „okej, do tego lepszy jest młotek, wezmę młotek”. Jeżeli będę kopał dołek, to nie będę tego robił śrubokrętem albo młotkiem, tylko powiem: „łopata nadaje się dużo lepiej”. Dla mnie tym są mniej więcej systemy operacyjne, z fanbojstwa wyrosłem i jeżeli któreś narzędzie działa do danego zadania lepiej to biorę to narzędzie i nie narzekam. W przypadku programowania używam bardzo mało narzędzi, bo wszystko sprowadza się do edytora tekstów, kompilatora plus bardzo podstawowe sprzęty do debugowania; czyli np. port szeregowy z Raspberry albo mam też analizator stanów logicznych, którego używam jeżeli robię coś w FPGA. Mniej więcej to się do tego sprowadza.
Mógłbyś rzucić nazwami? Myślę, że to może być interesujące dla czytelników; bo to dosyć ogólne powiedziałeś jak programujesz. W czym piszesz kod na przykład?
Kod piszę w edytorze Microsoftu, on się nazywa Visual Studio Code. To jest edytor do wszystkiego i ja go używam do wszystkiego. On wyrósł kilka lat temu jako konkurencja dla edytora Atom. Oba bazują na podobnej technice i jak Microsoft zaczął, to wszyscy zastanawiali się „po co oni to robią?”. Ale dzięki temu, że upublicznili cały projekt to nie jest tajna technologia Microsoftu, która on szpieguje, tylko każdy może sprawdzić w kodzie źródłowym co tam się dzieje. Bazuje na technologii Electron i ma całą masę wtyczek. Ma wtyczki do programowania w C, C++, Pythonie, do różnych systemów wbudowania kodu. Nawet do Amigi istnieje jakaś wtyczka która pozwala na programowanie w asemblerze, kompilację, wysłanie gotowego programu do emulatora. To jest kobyła do wszystkiego no i tego przede wszystkim używam.
A co poza tym jeszcze? Wspomniałeś o testowaniu na Raspberry.
Jeżeli testuję na Raspberry to przede wszystkim patrzę się w konsolę szeregową. Mam do tego bardzo prosty konwerterek z RS-232 na USB. Nie pamiętam jaki to jest konkretnie model, ale praktycznie każdy którego można nabyć spełnia swoje zadanie. Podłączam to do komputera, uruchamiam terminal (nazywa się Minicom). I to jest wszystko naprawdę. To co jeszcze używam z narzędzi to własna głowa. Czasami jak coś napiszę, to jadąc samochodem do pracy albo z pracy mam powiedzmy 20-30 minut żeby sobie przemyśleć co napisałem i ewentualnie znaleźć w tym jakieś błędy; więc powiedzmy mam 40-60 minut w ciągu dnia, kiedy mogę programować bez komputera i bez klawiatury.
Skądinąd wiem, że nie boisz się lutownicy. O tym coś opowiedz.
Z lutownicą to jest tak, że zasłużył się w tym mój ojciec. Jak byłem małym dzieciakiem to on lubił sobie troszeczkę poeksperymentować, a ja lubiłem się przyglądać. No i jeszcze przed klasą podstawową sprezentował mi swoją lutownicę i zacząłem się bawić w lutowanie różnych kabelków. Nigdy to nie rozwijało się za mocno, bo budowałem jakieś bardzo proste multiwibratory, robiłem sobie urządzenia do elektrolizy wody; potem się okazało że się przeraziłem jak całą masę chloru wygenerowałem, bo wodę posoliłem żeby lepiej działało; ale to były takie dziecięce zabawy. Tak na poważnie zacząłem bawić się lutownicą 20 lat temu. Nie wiem co o tym mogę powiedzieć, po prostu bawiłem się, eksperymentowałem, starałem się rozwijać wiedzę, rozwijać warsztat; jednocześnie starałem się nie tylko lutować tak dla samego faktu lutowania, ale projektować obwody drukowane. Zacząłem od prostszych, robiłem coraz bardziej skomplikowane no i teraz jestem na takim etapie, że FPGA które mam zamiar w końcu dokończyć będzie karta PCI Express, która będzie można podłączyć do RaspberryPi albo innego, dowolnego komputera. Tak naprawdę nie wiem jeszcze, które zastosowanie będzie pierwsze w przypadku tej karty. Jedna z opcji jest wykorzystanie tej karty jako interfejsu zamieniającego 24-bitową szynę Amigi na urządzenie podłączone przez PCI Express do RaspberryPi, za pomocą którego można by było chociażby ten emulator od Claude’a Schwarza uprościć albo ulepszyć. To byłaby moja autorska płytka.
No i przy okazji pracy na uczelni czasami pojawiały się takie sytuacje, że zamiast szukać gotowych urządzeń lepiej było zaprojektować własne, to zajmowałem się tym. Bo rzeczy, za pomocą których można nauczyć się czegoś nowego, albo spróbować czegoś nowego, są dla mnie zawsze ciekawostkami albo wyzwaniami, które warto jest jakoś podejść od jednej albo drugiej strony.
do regulowanego oświetlenia schodów/korytarza
To jest ciekawy wątek, bo elektronika w ogóle jest ciekawa i jest tańszym hobby jak Amiga. Wystarczy zobaczyć na cenę Pi Zero na przykład. Jak oceniasz pozycję AROS-a i jak widzisz jego przyszłość?
Ogólnie to jest tak jak już wcześniej wspomniałem w tym moim czarnowidztwie, negatywnym spojrzeniu na świat; chyba już dawno z całym światem przegraliśmy i nie ma z czym konkurować. W przypadku amigowych systemów to jest tak: AROS jest na otwartej licencji i jest kod źródłowy dostępny dla każdego, kto tylko chce. W przypadku dwóch pozostałych amigowych systemów one się w tym momencie rozwijają lepiej i szybciej niż AROS, ale mają taką wadę, że mają zamknięte licencje i kod źródłowy nie jest dla nikogo dostępny. Nie wiem czy to się zmieni w przyszłości, ale wyobraźmy sobie taką sytuację, że w Hyperionie połowa albo 3/4 programistów odchodzi, bo mają inne plany życiowe, bo odechciało im się, bo cokolwiek. I co wtedy stałoby się z systemem? Żeby go tak otworzyć należałoby zdobyć kontakt ze wszystkimi, którzy go współtworzyli i otrzymać od wszystkich pozwolenie na taki krok. To jest dosyć trudne, zmiana licencji w takich projektach jest zawsze skomplikowana, bo bez zgody wszystkich twórców nie jesteś w stanie tego upublicznić. Nawet jeżeli oni wszyscy pracowali dla Hyperionu nie jest to takie łatwe. W przypadku MorphOS-a jest tak samo. Tam jest dosyć prężna drużyna, następują tam pewne zmiany wewnątrz, ale jest dosyć stała. Też jest pytanie: co się stanie z nimi w przyszłości? W tym momencie AROS jest troszeczkę na przegranej pozycji, bo mamy w tym momencie kilku deweloperów na krzyż, ale z drugiej strony mamy otwartą licencję. Więc nawet jeżeli wszyscy programiści z AROS-a by zniknęli albo zawiesili działalność na rok albo dwa lata, to system w kodzie źródłowym nadal istnieje. Cały czas jest możliwość, że ktoś po to sięgnie albo ktoś z tego skorzysta. Moim marzeniem przyszłościowym byłoby, żeby te wszystkie systemy się w jakiś sposób zunifikowały, ale to jest nierealne. To jest nierealne dlatego, że każdy musiałby coś ze swojej pracy porzucić na korzyść innych, a niestety biorąc pod uwagę ego wszystkich deweloperów, którzy biorą w tym udział to jest po prostu nie do zrobienia.
Czyli to, że AROS rozwija się na pececie od tylu lat nie jest jakąś istotną przewagą nad MorphOS-em, który się teraz przeniesie na procesory AMD, tylko ta jego otwartość, tak?
Otwartość jest przewagą, W przypadku MorphOS-a nie wiem na ile sprawnie im to wyjdzie.
Uściślę pytanie: czy według ciebie po tym jak MorphOS przeniesie się na AMD, czy ludzie będą w ogóle chcieli jeszcze korzystać z AROS-a?
Ci ludzie, którzy używają obecnie AROS-a, otrzymaliby możliwość używania też czegoś innego. Ale ci, którzy naprawdę używają AROS-a teraz, robią to dlatego, że im on się podoba, że jest dla nich lekki i działa już na ich platformach. W przypadku MorphOS-a jego deweloperzy nie chcą tego samego błędu popełnić co w AROS-ie, dlatego mocno koncentrują się na 1-3 platformach, na które zamierzają swój system zrobić. W tym momencie jeżeli chciałbyś używać nowego MorphOS-a, to będziesz musiał swój komputer wymienić, albo dobrać sobie nowe podzespoły. A ludzie, którzy już tego AROS-a używają obecnie, niekoniecznie będą chcieli to zrobić. Oni (jeżeli naprawdę AROS-a używali) mają już coś gotowego, coś co działa. Czy potrzebują teraz zmiany? Nie jestem pewien. Tym bardziej, że większość używa 32-bitowego AROS-a, bo w przypadku 64-bitowego nie ma żadnych oficjalnej dystrybucji od nikogo.
Programy na 64 bit trzeba by było kompilować od nowa?
Tak, i to jest jeszcze cała masa pracy. A w przypadku MorphOS-a to jest jeszcze tak, że oni pracują już nad wersja na intele, ale to jest długa droga, to jest zawsze długa droga. To jest zupełnie nowa architektura, cała masa zmian: zmiana Endiana, zmiana procesora, to wszystko jest bardzo skomplikowane. To nie jest tak, że jak 'bigfot’ zaczął nad tym pracować, to za tydzień albo dwa będzie już wszystko gotowe.
A myślisz że kiedy by to wyszło? MorphOS w jakiejś publicznej wersji, niech będzie beta, myślisz że za 2 lata możemy się spodziewać czegoś takiego?
Myślę, że tak. Myślę, że dwa lata powinno wystarczyć, tym bardziej że jeżeli się koncentrują wyłącznie na jednej albo dwóch platformach.
Tak z ciekawości, czy ty w ogóle współpracujesz z drużynami OS 4 i MorphOS-a?
W tym momencie nie istnieje taka potrzeba. Jestem otwarty na współpracę. Jeżeli ktoś coś ode mnie potrzebuje, albo chce mnie o coś zapytać, albo poprosić żebym w czymś pomógł – to jak najbardziej to robię. Z drużyną OS 4 miałem troszeczkę trudności w przeszłości, z pewnymi osobami, które były niejednoznaczne albo nieprzejrzyste. Taki chociażby Jörg Strohmayer, który robił system SFS/2 na AmigaOS. Wielokrotnie przez mejla ze mną się komunikował. Mówił mi w detalach, w mejlu, jakie zmiany w systemie SFS/2 wprowadził, a później publicznie na forum w którymś momencie wypowiedział się, że jeżeli otwartoźródłowe oprogramowanie w którymś momencie zacznie wspierać system SFS/2, który on tworzył dla AmigaOS, to on automatycznie rozpocznie sprawy sądowe; bo to będzie oznaczało, że ukradliśmy kod, analizowaliśmy coś, czego nam nie wolno było, itd. To są ludzie, którzy w tym momencie nie są ze mną szczerzy i szczerze powiedziawszy jeżeli np. od tego Jörga słyszę, że on swojego systemu SFS nie będzie upubliczniał, bo wredni morfosowcy zaraz mu to ukradną, a z drugiej strony ze strony drużyny MorphOS-a słyszę, że ten Jörg jest taki zły, niedobry i w ogóle, to chęć do współpracy opada.
To jest stygmatyzacja. To jak osoba pracująca nad rozwojem systemu nie może robić przy innym, bo jest posądzenie że korzysta z kodów źródłowych, tak?
Tak. Dlatego też jeżeli miałbym kiedykolwiek w jakikolwiek sposób współpracować to nad rzeczami, przy których nie muszę zaglądać w rzeczy, których widzieć nie powinienem.
Czyli następnym razem, jak zgłosi się jakiś „pan X” (odpowiednik pana Jörga Strohmayera) to mu napiszesz „nie pisz do mnie rzeczy, których nie mogę mówić publicznie”, tak?
Mnie się wydaje, że jeżeli ktokolwiek by coś ode mnie potrzebował, to ludzie zdają sobie sprawę, że większość rzeczy które robię są otwartoźródłowe i raczej tej filozofii się trzymam. Nie jestem osoba skrajną, taką która wszystko wrzuca na licencje GPL 2 albo 3, bo to jest w sumie taka wirusowa licencja, która się rozprzestrzenia na wszystko czego się dotknie. Ja używam innych licencji otwartoźródłowych, jak tylko mogę.
Intencja mojego pytania była taka, że ja się obawiam sytuacji, że ktoś może ci coś zablokować. To tak jakby jeden drugiemu powiedział że pisze książkę na jakiś temat i przez to że mu już zgłosił że będzie pisał taką książkę – już drugi nie może tego zrobić, bo by mu „wszedł na jego teren”. Tak można zablokować czyjeś działanie – ktoś ci napisze, że będzie robił to i to, no i ty już tego nie możesz dotknąć, bo on ci się zwierzył.
Taka sytuacja mogłaby się zdarzyć, jeżeli ktoś podesłał by mi coś z prośbą o przejrzenie, o poprawienie, o skomentowanie itd., a potem miałoby się okazać, że to jest jednak coś co nie powinno być upublicznione; no to w tym momencie sytuacja robi się skomplikowana.
I dlatego każdy woli robić sam?
Wydaje mi się, że większość osób tworzących dla amigowych systemów jest na tyle dumna, że raczej unikają szukania pomocy. Raczej jest tak jak na początku mówiłeś, że większość ludzi kisi wszystko dla siebie i albo projekty zostają zapomniane, albo ewentualnie kilka naraz się upublicznia i każdy ma swoje zalety, ale jednocześnie całą masę wad. I żaden z nich nie jest taki, jaki mógłby być, gdyby ludzie współpracowali.
Mam jeszcze pytanie, które niekoniecznie może ci się spodobać, ale dla mnie to zawsze była dziwność. Dla mnie AROS jako wirtualny system to był etap przejściowy. Czy używanie w wirtualnej maszynie uważasz za konieczność, czy też równoprawną wersję i natywny sprzęt jest zbędny?
To jest tak, że jeżeli ktoś chce na poważnie systemu używać do czegoś więcej jak to słynne amigowe przestawianie ikonek no to oczywiście wirtualna maszyna nie ma sensu. Bo szczerze powiedziawszy – po co?
No, bo dla mnie to jest dziwność, jeżeli system technicznie lepszy jest (np. Windows 10) i w nim używasz AROS-a, to taka „królicza nora”; wskakiwać tam – po co? Dla mnie to jest dziwne.
No to jest w tym momencie zabawa z sentymentu, dokładnie taka sama jak uruchamianie WinUAE pod Windowsem tylko po to, żeby w tym sobie otworzyć Final Writera i napisać list cioci. W tym momencie to jest sentyment, to jest troszeczkę takie poruszenie własnych wspomnień i w sumie nic więcej. Bo jednocześnie można otworzyć, nawet jeżeli nie ma się Microsoft Offica, można otworzyć Libre Office albo Wordpada na takim samym Windowsie i zrobić to samo dużo szybciej, lepiej, wygodniej. W przypadku AROS-a jest tak, że maszyna wirtualna bardzo pomaga w deweloperce, bo pracujesz na jednym komputerze i na tym samym komputerze jesteś w stanie bardzo szybko uruchomić wirtualny komputer do przeprowadzenia testów. Przy czym obecne wirtualne maszyny, np. VMware, bardzo wiernie odtwarzają zachowanie komputerów; na tyle wiernie, że wiele rzeczy, które odchodzą od specyfikacji i działały tylko przypadkiem w AROS-ie, można zweryfikować na takiej maszynie. Okazuje się np. że coś nie działało tak jak powinno – robiąc to zgodnie z prawdziwa szkołą, zgodnie z dokumentacją, zaczyna wszystko działać poprawnie. Tak że to jest bardzo doskonałe narzędzie do testów, ale nie wydaje mi się żeby to było dobre narzędzie do stałego używania. To jest coś, co przydaje się mi, to jest coś co przydaje się innym osobom, ale jakoś nie widziałbym siebie uruchamiającego wirtualną maszynę i pracującego na jakimś systemie na tym.
Czy według ciebie powinien się AROS rozwijać zgodnie z ideą pierwotną na wielu platformach, czy też dobrze byłoby mieć jedną platformę docelową? Może czas jest się określić na jakieś, np. AMD i Raspberry i koniec? Czy w ogóle ktoś rozwija inne wersje, np dla Motoroli?
Nick Andrews rozwija przede wszystkim platformę 64-bitowa na Intele i na tym się skupia. Wersja 32 bitowa stoi praktycznie w miejscu. Pojawiają się zmiany, które 'Deadwood’ wprowadza, do wersji z ABI v0, o tym jeszcze nie rozmawialiśmy, ale to już jest historia, i z tych zmian korzystają osoby które tworzą dystrybucje, Czy AROS powinien się na inne platformy jeszcze rozwijać? Prawda jest taka, że za każdym razem jak się rozwija na nowa platformę to było to albo podyktowane tym, jak było to w przypadku Efiki albo Samanthy że zgłasza się do nas producent który mówił „chcemy żeby na tym działał AROS” i wtedy na taką platformę AROS powstawał; albo dlatego, że ktoś miał taki komputer albo taką architekturę i po prostu stwierdzał, że to jest świetna zabawa, żeby spróbować. I mi się wydaje, że tak powinno być cały czas. Fajnie byłoby się określić, ale w przypadku AROS-a nie mamy żadnych struktur decyzyjnych. To jest to, co nam cała masa ludzi zarzucała, że AROS sam z siebie jako system nie ma konkretnego celu. Nie ma osoby która mówi „okej, naszym celem w wydaniu XY jest poprawienie tego, dopisanie tego itd.”. Tak jest w przypadku MorphOS-a, tak jest w przypadku OS 4, w przypadku AROS-a to jest powiedzmy zrzeszenie ludzi, z których każdy ma swój jakiś własny cel i każdy z tych celi pcha w jakiś sposób AROS-a do przodu.
Czyli nie ma lidera projektu?
Nie ma lidera projektu. Lidera projektu mieliśmy dawno temu, to była ta sama osoba, która cały projekt założyła – Aaron Digulla, ale on przestał być aktywny z 10-12 lat temu. Do tej pory czasami jeszcze się zgłasza, ale to są zgłoszenia raz na rok, raz na dwa lata; takie, że ktoś go poprosił o informacje, albo ktoś się do niego zgłosił i prosiłby żeby ktoś z drużyny jeszcze do niego napisał. Więcej tak naprawdę nie mamy z nim kontaktu. Więc – tak, AROS nie ma lidera i nie ma struktur zarządzających tym projektem. Wielu osobom w historii AROS-a się to bardzo podobało, ale jak dla mnie brak pionu decyzyjnego albo brak lidera w systemie jest straszną wadą, bo dzięki temu AROS nie rozwija się w takim tempie jakim mógł, miał szansę się rozwijać, albo w jakim mógłby się nadal rozwijać. I tego brakuje, tego brakowało już od dawna.
To są pytania, które miałem przygotowane. Czy chciałbyś coś rozwinąć jeszcze, co tu nie padło?
A o co chciałbyś ty zapytać?
Taka rzecz, co najbardziej interesowałaby osoby ze środowiska amigowców, to jest taka mniej więcej: „co będziesz kończył i kiedy?”. Bo masz kilka rzeczy rozpapranych, kiedy należy się spodziewać np. ukończonego Emu, karty na PCI Express o której wspominałeś itd.?
Emu68 jest w tym momencie na takim etapie, że niedługo będą budowane dystrybucje, przynajmniej samego emulatora. Nad AROS-em pracę zacząłem w grudniu. Jestem chaotyczny i niestabilny jeżeli chodzi o jakieś terminy. W miarę możliwości staram się teraz jak najszybciej popchnąć AROS-a działającego właśnie pod Emu68. Jeżeli chodzi o płytkę PCI Express – brakuje w niej fragmentu zasilania i wyprowadzenia całej masy portów na złącze, którym można by było bawić się dalej. Więc ona jest dosyć mocno zaawansowana, kiedy by to mogło powstać nie jestem w stanie powiedzieć.
Nie o to chodzi żeby cię naciskać, tylko mniej więcej nakreślić. Bo dużo rzeczy robisz, dużo czasu ci to zajmuje i owoce żeby zbierać… żeby to nie lądowało później gdzieś w kącie, rzucasz-nowa zabawka, rzucasz-nowa zabawka… o to mi chodzi.
To jest troszeczkę moja wadą, że…
..nudzisz się swoimi projektami?
Tak, szczerze powiedziawszy tak. To jest mniej więcej tak, że ja potrzebuję często zmian. Jeżeli zajmuje się jednym projektem i on zaczyna mnie nużyć, to po prostu muszę to zmienić. Muszę przeskoczyć na coś innego, żeby czymś nowym głowę zająć, bo inaczej jak zacznę się za bardzo nudzić, zaczyna mi spadać efektywność i w którymś momencie po prostu projekty stają w miejscu i nie toczą się dalej.
Wywiad zakończył się w tym miejscu. Tematy techniczne (typu ABIv0) jak i postępy w projektach być może uda się przedstawić w kolejnym numerze.
Patreon: www.patreon.com/michal_schulz
GitHub: github.com/michalsc
’truman burbank’ – Amiga NG (10) 1/2021
