Zniszczenie AmigaOS i Plan9 to średniowiecze ery informatycznej

[Jacek Marcin Jaworski]

Wstęp
To jest rozprawa na temat systemów operacyjnych. Mimo, że każdy system operacyjny ma pewne elementy wspólne z innymi to jednak niektóre jego cechy wpływają w zasadniczy sposób na jego możliwości. Na podstawie analizy unikalnych cech kilku systemów ustaliłem, że najważniejszą ich cechą jest to co można w prosty sposób oskryptować. W dalszej kolejności jest to jak łatwo można je programować.
Dalsza analiza ujawnia zastraszające fakty tkwienia programistów linuskowych w realiach lat 1970. Natomiast pozostali programiści (Windows i Android) dostają "po nowemu" zakręconymi COM-ami i Jawa-mi.
To prowadzi w prosty sposób do wniosku kto za to faktycznie odpowiada.

Podział systemów operacyjnych ze względu na przeznaczenie
Systemy serwerowe, stacje robocze (systemy plikowe):
+ Unix: BSD, Minix, Linuksa, Mac OSX. Cechy: monolit; bez COM, bez VM, bez AREXX, bez P9; Przestarzałe, przerośnięte, dobre do skryptowania, średnio trudne do programowania: wymagają internetu do programowania (książki nie wystarczą, ale można się obyć bez inż. wsparcia).
+ Plan9: Cechy: monolit; ma P9, bez COM, bez VM, bez AREXX; mały, superszybki, ogromne możliwości skryptowe (zwłaszcza sieciowe). Prawdopodobnie stworzony jako konkurent AmigaOS na stacjach roboczych. Trudno powiedzieć jak się w nim programuje prawdopodobnie łatwiej niż Unix.

Systemy użytkownika, rozrywkowe (systemy obiektowe):
+ AmigaOS: Cechy: mikrokernel (jednak bez trybu uprzywilejowanego); ma AREXX, bez COM, bez VM, bez P9; Mały, superszybki (najnowsza wersja 3.2 z 2021r. ruszy na CPU 7MHz i 2MB RAM, to jest mniej niż 1% tego co wymaga Android), bardzo elastyczny i podatny na zmiany i rozszerzanie (nawet przez entuzjastów), wielkie możliwości skryptowe (zwłaszcza w komunikacji między procesowej: AREXX). Łatwy w programowaniu: wymaga tylko książek (profesjonalne, multimedialne programy tworzono na Amigi przed erą Internetu, więc programując na AmigaOS na 100% można się obyć bez Internetu i bez inż. wsparcia).
- Windows: Cechy: Mikrokernel; Ma COM, ma VM, nie ma P9 ani AREXXa. Przestarzały, przerośnięty, bardzo wolny (przawdopodobnie przez mikorkernel); koszmar programistów (WinApi i COM). Do programowania wymaga: książek, internetu i inż. wsparcia z M$.
- Android: Cechy: monolit; Ma VM, nie ma COM, P9 ani AREXXa. Przestarzały, przerośnięty, powolny, skrypty może pisać programista ale tylko dla siebie - użytkownicy nie mogą tego robić; Dziwne Jawa API (całe szczęście dostępne z C++); wymaga książek i internetu do programowania (można się obyć bez inż. wsparcia).

Jak powyższe czytać?
Monolit vs Mikrokernel: Jądro monolityczne prezentuje "starą szkołę" tworzenia systemów operacyjnych. Natomiast w raz z pojawieniem się nowych, tanich procków 32 bit. (pocz. lat 1980.) zaczęto głosić herezję, że jądro powinno być modułowe którym ma zarządzać mikrokernel. Głównym celem było przerzucenie modułów jądra do przestrzeni użytkownika w celu maksymalnego wyparcia podejrzanego kodu z przestrzeni jądra. To miało skutktować dużo wyższą niezawodnością, bo mikrokernel mógł przetrwać krytyczną awarię jaka mogła się pojawić w module w przestrzeni użytkownika. Jednak w przypadku mikrokernela, gdy większość funkcji jądra została przerzucona do przestrzeni użytkownika, liczba przełączeń kontekstu między jądrem a kodem użytkownika jest tak ogromna, że całe jądro jest niewydajne. Wynika to z tego, że przełączeniom kontekstu towarzyszy kosztowne sprawdzanie uprawnień użytkownika oraz kopiowanie komunikatów.
Jak to możliwe, że mikrokernel AmigaOS jest wydajny? Po prostu tam nie ma trybu jądra (nie ma root-a) i jest tylko jedna wspólna przestrzeń adresowa. Dlatego nie zachodzi tam problem spr. uprawnień ani nie ma konieczności kopiowania komunikatów.

COM: To technika osadzania dokumentów we wnątrz innych dokumentów. Np. w Word można wkleić arkusz Excel i go potem edytować bez potrzeby otwierania Excela. To technika wdrożona tylko na Windows. W szpargałach Commodore ktoś wygrzebał, że mieli coś podobnego w planach dla AmigaOS. Całe szczęście, że nic takiego nie wysmarzyli.
Co jest nie tak z COM? Każdy może się przekonać jak COM jest wolne. Nie wynika to z prędkości procka, tylko z jakichś ustawionych tam na sztywno sleep-ów, czyli uśpień na ileś mili sekund, by na coś zaczekać. Takie wstawianie sleep-ów to czysta amatorka jaką można zrozumieć w małych firmach, ale nie w korpo. To jedno. Druga sprawa, to fakt, że M$ (prawdopodobnie) by zemścić się na wszystkich programistach używa COM do wszystkich nowych interfejsów Windows. I to nawet nie mających nic wspólnego z dokumentami (ja np. parę lat temu walczyłem z nowym, COM-owskim API do skanerów). Te interfejsy są absurdalnie abstrakcyjne i rozbudowane, a to powoduje, że bez wsparcia inż. M$ nie można niczego zaprogramować.

VM: Jak wiadomo Jawa to programowy procesor tzw. maszyna wirtualna, czyli VM. Nie wiem po co wynajdywać wolne, programowe procki jak są szybkie krzemowe?!? Chyba tylko w celu testowania przyszłych procesorów. Bo przecież można programować w C, C++ i D w pełni przenośny kod. Kto zna C++ nie musi się przejmować VM do puki nie każą mu programować na Antka. Twierdzenie o przenośności kodu VM między różnymi sytstemami to fikcja na resorach, bo dotyczy to tylko tej wersji na którą kod Jawa został skompilowany. Czyli jak sobie napszesz program na JVM8 to już nie zadziała na JVM11. VM to bezsens i patologia. Na początku wieku M$ po przegraniu procesu o prawo do wprowadzania niekompatybilnych zmian w Jawa wprowadził własną VM jaką nazwał C#. Co jednak z C nie ma nic wspólnego, bo jest po przeciwnej stronie światopoglądowej. Bo jakieś if-y i for-y to nie wszystko czym jest C: C to język kompilowalny do kodu maszynowego w normalnych plikach wykonywalnych, które wymagają jedynie systemu operacyjnego do działania. Natomiast C# wymaga systemu operacyjnego i monstrum jakim jest jego VM.

P9: To protokół współdzielenia plików w systemie Plan9. Dzięki temu, że w Plan9 na prawdę wszystko jest plikiem (w brew propagandzie w Unix/Linuks tak nie jest, np. sokety internetowe i okna nie są dostępne z systemu plików), to można robić rzeczy nie wyobrażalne dla dzisiejszych użytkowników systemów Linuksa, Windows i MacOS, np.:
Współdzielenie procesorów (tak PROCESORÓW!): np. w sieci lokalnej jak ktoś musi przekompkować duży program, to może skorzystać z uprzejmości kolegów (i koleżanek) i użyć rdzeni jakimi oni dysponują; Manipulowanie oknami programów na innych komputerach (łacznie z rysowaniem na nich); Udostępnianie w sieci działających programów; Łatwe montowanie zdalnych kart sieciowych (odpowiedniki NAT, VPN) i łatwe filtrowanie dostępnych adresów sieciowych (odpowiednik Firewall). W Plan9 to wszystko robi się prostymi skryptami a nie monstrualnymi programami które tworzone są przez dr i prof. i które tylko oni są w stanie obsługiwać.

AREXX: REXX w AmigaOS pojawił się w wyniku handelku Commodore z IBM: wymienili Workbench na REXX1. Workbench został użyty w OS2 v2.0. Natomiast REXX został użyty w AmigaOS v2.0 nie tylko jako jeszcze jeden język skryptowy, ale w zupełnie niestandardowy sposób: do kontroli programów okienkowych. Gdy amigowy program posiada coś takiego jak "port AREXXa" to można mu wydawać komendy w celu kontroli za pomocą skryptu. Po co tak się trudzić zamiast klikać? Np. jak mamy do przetworzenia tekstury w programie graficznym 2D, a następnie chcemy ich użyć do renderingu scenek 3D a potem jeszcze złożyć to w całość w programie do nieliniowego montarzu filmów. To (ZTCW) AREXX może to wszystko zrobić. W ciągu 35 lat jak się interesuję komputerami NIE SŁYSZAŁEM ABY JAKIKOLWIEK INNY SYSTEM OPERACYJNY TO UMOŻLIWIAŁ.

Trudności w programowniu na poszczególne systemy operacyjne:
Bez książek programować się nie da, to wiadaomo, więc to jest najniższy poziom jaki może być. Jeśli system wymaga tylko książek to jest superłatwy w programowaniu (jest to udowodniona cecha AmigaOS).
Kolejny poziom to książki + internert: tu jest Linuks i Antek.
Kolejny poziom to: książki, internet i inż. wsparcia: tego wymaga programowanie na Windows (mordęga i katorga za karę bycia programistą).

Wielkie korpo
Ja nie winię żadnych wielkich korpo za to że robią wodę z mózgów programistów. Bo takie wielkie korpo nigdy by nie zaistniało bez układu ze spec. służbami i rządami. Winić należy tych aktywistów którzy mieli na jakimś etapie życia wybór, za to że dokonali wtedy złego wyboru.

Osoby odpowiedzialne za średniowiecze ery informatycznej
Irving Gould: główny udziałowiec Commodore
Odpowiada za pogrzebanie Amigi przez doprowadzenie do bankructwa Commodore. Zrobił to w kilku krokach z czego najważniejsze były:
Usunięcie z firmy założyciela i wizjonera Commodore Idka Trzmiela (polskiego Żyda ocalałego z holokaustu). Stało się to gdy Idek zaprotestował przeciwko używaniu firmowych pieniędzy do prywatnych celów Irving-a (1985r.).
W tym samym 1985r. na miejsce Idka Irving chciał sprowadzić kogoś kto wykończy Commodore całkowicie. Dla nie poznaki zrobił to samo co Apple w 1983: usunął założyciela i zatrudnił Thomas Rattigan-a CEO International z Pepsico. Ku zdumieniu wszystkich Thomas zmienił kwartalną stratę przekraczającą 237M$ na 22M$ kwartalnego zysku. To Thomas wpadł na pomysł taniego komputerka A500 i stacji roboczej A2000. Jak o tym wszystkim dowiedział się Irving wpadł w szał i go zwolnił za co Thomas dostał odszkodowanie 9M$.
Zbrodnią Irving Gould-a przeciw ludzkości jest: wykończenie bardzo dobrej platformy multimedialnej dla młodych ludzi: Amigi z AmigaOS. W raz z pojawieniem się Amigi nastąpiła eksplozja kreatywności u młodych ludzi: w szczytowym okresie było ponad 1000 grup scenowych - tylu nie było na żadnej innej platformie w historii (ZTCW). Ten komputer był tani, miał bardzo dobry system operacyjny, miał wielkie możliwości multimedialne i można było go w miarę łatwo programować. W raz z pogrzebaniem tego komputera dla kreatywnych dzieciaków kolejne pokolenia zostały skazane na biurowy Windows i serwerowy Linuks. To zabiło elektroniczną kreatywność kolejnych pokoleń. KREATYWNA/ROZRYWKOWA PLATFORMA DOMOWA JEST NIEZBĘDNA DO NORMALNEGO ROZWOJU SPOŁECZEŃSTWA I ŻADEN BIUROWY ANI SERWEROWY SYSTEM JEJ NIE ZASTĄPI. Wmawianie czegoś innego to dalszy ciąg mokrej roboty Goulda.

Linus Torvalds: Autor i koordynator rozwoju systemu operacyjnego Linuksa
2 cytaty (z pamięci):
Nigdy nie widziałem powodów by zmieniać system plików Unix-a.
Nie planuję dalej niż na 6 miesięcy do przodu.
Czyli: Plan9 go kompletnie nie obchodzi - pewnie dla niego to jakiś nonsens. Ciekawe tylko jakim cudem system plików /proc trafił z Plan9 do Linuksa?!?
Jeśli na prawdę Linus był by geniuszem, jak twierdzili na PG (2003r.), to nad żadnym projektem nie siedział by dłużej niż 10 lat. To wystarczy by stwierdzić co jest grane w danym systemie. To wystarczy by się tym śmiertelnie znudzić. To wystarczy by wytyczyć nowe kierunki. Ja jestem świadomy, że Plan9 powinien być skopiowany i rozwinięty w latach 2000-2010 i że teraz powinniśmy mieć kolejną generację systemów operacyjnych (teraz powinna być era post Plan9). Piszę to mając na uwadze niechęć Unix-owców do jakiej kolwiek gadki na tematy związane z obiektowymi systemami operacyjnymi (takim jak AmigaOS). Piszę to, że Linus Torvalds jest odpowiedzialny za zastopowanie rozwoju stystemów serwerowych/plikowych. Jest za to odpowiedzialny dlatego, że miał jakiś wybór na jakimś etapie swojego życia, wtedy gdy mógł jeszcze coś zrobić byśmy programistycznie nie tkwili w realiach lat 1970.

Ryszard Stalman: założyciel i wieloletni dyrektor fundacji GNU
Tak się jakoś składa, że od początku lat 1990. do współczesności GNU się zafiksowało na ideii mikrokernela w projekcie Hurd. Podczas gdy już po 12-18 miesiącach prób powinno stać się jasne, że to nie może efektywnie działać. Tym samym forsowanie tej utopi stawia Ryszarda S. w gronie osób odpowiedzialnych za powstrzymywanie rozwoju ludzkości w kluczowym zakresie systemów operacyjnych. Jest za to odpowiedzialny dlatego, że miał jakiś wybór na jakimś etapie swojego życia, wtedy gdy mógł jeszcze coś zrobić byśmy programistycznie nie tkwili w realiach lat 1970.

Zarówno Linus Torvalds jak i Ryszard Stallman dają nam "darmowe i wolne oprogramowanie" z pełną świadomością i premedytacją, że jest ono przestarzałe i nic nie zamierzają z tym robić.

Podam tylko jeden przykład jak chore są te systemy z lat 1970. (Linuks i w.w. reszta):
"Jak stwierdzić, że nastąpiła utrata połączenia na na gnieździe IP/TCP synchronicznym lub asynchronicznym?!?"
To banalny temat godny rozprawy doktorskiej.

[heby]

On 05/12/2021 06:01, Jacek Marcin Jaworski wrote:
> To jest rozprawa na temat systemów operacyjnych.

Raczej zbiór przypadkowych haseł.

> że najważniejszą ich cechą jest to co można w prosty sposób oskryptować.

Najważniejsza w jakim kryterium?

> W dalszej kolejności jest to jak łatwo można je programować.

Czasy, kiedy były koncepcja by sekretarki programowały, minęły razem z
COBOLem.

> Dalsza analiza ujawnia zastraszające fakty tkwienia programistów linuskowych w realiach lat 1970. Natomiast pozostali programiści (Windows i Android) dostają "po nowemu" zakręconymi COM-ami i Jawa-mi.
> To prowadzi w prosty sposób do wniosku kto za to faktycznie odpowiada.

Jaszczuroludzie. Chić nie wiem co tam obecnie jest w modzie.

> + Unix: BSD, Minix, Linuksa, Mac OSX. Cechy: monolit; bez COM, bez VM, bez AREXX, bez P9; Przestarzałe, przerośnięte, dobre do skryptowania, średnio trudne do programowania: wymagają internetu do programowania

Ciekawe jak je programowali przed internetem.

> Systemy użytkownika, rozrywkowe (systemy obiektowe):

Rozrywkowe to obiektowe?

> + AmigaOS: Cechy: mikrokernel (jednak bez trybu uprzywilejowanego)

Jesli nie ma trybu uprzywilejowanego, to trudno mówić o mikrokernelu,
wszystkie zalety idą w pisdu. Na Amidze mikokernel był niemożliwy z
wielu powodów, ale najważniejszy to brak MMU w głównej lini komputerów.

> superszybki (najnowsza wersja 3.2 z 2021r. ruszy na CPU 7MHz i 2MB RAM, to jest mniej niż 1% tego co wymaga Android)

Superszybkość w tym wypadku polega głównie na małej ilości zagadnień do
obsługi, w tym wątków, operacji IO, obsługi VM, bezpieczeństwa itd.

Troche jak porównywanie koparki do łopaty. Łopata lżejsza, no i co z tego?

>, bardzo elastyczny

Nie nazwałbym go tak w całoci. Pewne detale były zaprojektowane do
modyfikacji, a pewne nie. Powszechne było patchowanie funkcji
bibitecznych w celu osiągnięcia jakiegoś efektu. Trudno ten workaround
nazwać elastycznym. Tym bardziej, że załozenie dwóch patchów na jedną
funkcje kończyło się najczęściej nagłym zejściem.

> i podatny na zmiany i rozszerzanie (nawet przez entuzjastów)

Niespecjalnie. Tych rozszerzeń było relatywnie mało.

>, wielkie możliwości skryptowe

Raczej brak takowych w gołym systemie.

> (zwłaszcza w komunikacji między procesowej: AREXX).

Tak, to nie był zły język, tylko że poza faktem implementacji go prawie
w każdym programie np. MUI, jednocześnie prawie nikt nie implementował
konkretów. W efekcie miałeś 100 aplikacji z Arexx i w każdej dało się
tylko ja zamknąć.

> Łatwy w programowaniu: wymaga tylko książek

Nie kojarzę uzytecznego programowania *wymagajacego* internetu.
Zaryzykuje, e nie ma w historii informatyki języka, który jest popularny
i jednocześnie nie ma manuala, zamiast tego oferuje copy paste ze
stackoverflow.

Nie, nie ma takiego.

> (profesjonalne, multimedialne programy tworzono na Amigi przed erą Internetu, więc programując na AmigaOS na 100% można się obyć bez Internetu i bez inż. wsparcia).

Multimedia mają się nijak do internetu.

Praktycznie wszystkie systemy operacyjne oferowały MM przed erą internetu.

Akurat MM, z uwagi na kiepski już hardware Amig w połowie lat 90, do MM
nadawały się badzo słabo. A jak ktoś wyciągał kartę Video do montowania
fimów, o często na pokładzie miała więcej elektroniki niż sama Amiga.

> - Windows: Cechy: Mikrokernel

Serio? O ile cały świat się nie myli, Windows nie widział na oczy
mikrokernela.

>; Ma COM, ma VM, nie ma P9 ani AREXXa.

Ale jest dużo innych narzędzi. przypominam, że taki Arexx w wersji
Windows nazywał się VBA. I działał, wręcz znakomicie, mogłem sterować
Corelem, Wordem i kilkoma innymi programami, w połowie lat 90.

> Przestarzały, przerośnięty, bardzo wolny (przawdopodobnie przez mikorkernel

Mikrokernel ma z tym niewiele wspólnego.

Bardzo wolny? Bzdura.

>; koszmar programistów (WinApi i COM).

Widać nigdy nie programowałeś w AmigaDOS z jego API opartym o BCPL.
Można było zwymiotować.

> Do programowania wymaga: książek

Tak, na tym konieć *wymogów*.

> - Android: Cechy: monolit; Ma VM, nie ma COM, P9 ani AREXXa.> Przestarzały, przerośnięty, powolny, skrypty może pisać programista ale tylko dla siebie - użytkownicy nie mogą tego robić;

Bzdura. Istnieje bardzoduzo narzędzi do "pisania skryptów" z mozliwoscią
dzielenia się.

> Dziwne Jawa API

Nie jest "dziwne". W zasadzie jest całkiem normalne, jak do takich
zastosowań.

> Jak powyższe czytać?

Najlepiej nie czytać :)

> Monolit vs Mikrokernel: Jądro monolityczne prezentuje "starą szkołę" tworzenia systemów operacyjnych. Natomiast w raz z pojawieniem się nowych, tanich procków 32 bit. (pocz. lat 1980.) zaczęto głosić herezję, że jądro powinno być modułowe którym ma zarządzać mikrokernel.

Ta "herezja" ma bardzo poważne podstawy związane z bezpieczeństwem oraz
poważnymi tematami jak weryfikacja fromalna, która w niektórych
dziedzinach jest krytycznym parametrem o dopuszczeniu do używania.

> liczba przełączeń kontekstu między jądrem a kodem użytkownika jest tak ogromna

Ona jest ogromna w casach jednozdzeniowych CPU. Z każdym podwajaniem
ilosci rdzeni argument upada. Dodatkowo od lat 80 osiągleliśmy niejakie
postępy w przoblemach przełaczania watków.

> Jak to możliwe, że mikrokernel AmigaOS jest wydajny?

Bo ma bardzo mało do roboty. Dlatego jest wydajny.

> Po prostu tam nie ma trybu jądra (nie ma root-a) i jest tylko jedna wspólna przestrzeń adresowa. Dlatego nie zachodzi tam problem spr. uprawnień ani nie ma konieczności kopiowania komunikatów.

1) To wada we współczenym świecie, że kady proces widzi pamiec innego.

2) Nikt nie kopiuje komunikatów, MMU we współczesnych procesorach
pozwala na wstawienie w oba procesy fragmentu pamieci współdzielonej, co
inwaliduje ten argument.

> COM: To technika osadzania dokumentów we wnątrz innych dokumentów.

Nie. To tylko jej zastosowanie.

> Co jest nie tak z COM? Każdy może się przekonać jak COM jest wolne. Nie wynika to z prędkości procka, tylko z jakichś ustawionych tam na sztywno sleep-ów, czyli uśpień na ileś mili sekund, by na coś zaczekać.

Obawiam się, że nie wiesz czym jest COM.

> Takie wstawianie sleep-ów to czysta amatorka

Dlatego nikt jej nie stosuje.

> VM: Jak wiadomo Jawa to programowy procesor tzw. maszyna wirtualna, czyli VM. Nie wiem po co wynajdywać wolne, programowe procki jak są szybkie krzemowe?!?

Nie wiem po co rozmawia o teoretycznej VM Javy, zamiast zainteresowa
się, że od prawie samego początku były dostępne maszyny z rekompilacją
do kodu natywnego w tle. Argument o "interpretowanej Javie" jest
nieprawdziwy prawie od samego początku.

> Bo przecież można programować w C, C++ i D w pełni przenośny kod.

Ale Java ma inne zalety.

Ponadto kod w C++ wcale nie jest aż tak przenośny. Hint: szerokości
typów, brak wysokopoziomowych biblitek.

> wprowadził własną VM jaką nazwał C#.

Nie, nazwał ją .NET. C# to jedna z wielu implementacji języka na tą maszynę.

> Co jednak z C nie ma nic wspólnego

Ma wystarczająco dużo, aby taką nazwę obronić.

> C to język kompilowalny do kodu maszynowego

Możesz byc zszkowany faktem, że można go kompilować również do bytecode
Javy i .NET. A w Linuxie jest nawet jakiś interpretter dla shella...

> w normalnych plikach wykonywalnych, które wymagają jedynie systemu operacyjnego do działania. Natomiast C# wymaga systemu operacyjnego i monstrum jakim jest jego VM.

Bo to VM jest częscią tego systemu operacyjnego.

Podobnie: "Programy Arexx wymagają AmigaOS i monstrum jakim jest jego
interpreter".

> Współdzielenie procesorów (tak PROCESORÓW!):

Masa softwre na Linuxa pozwala zrobic cluster z komputerów walajacych
się pod stołem, oraz superkomputerów. Nie wiem co tutaj miało by być
rewolucyjnego, jest i działa w Linuxie.

> np. w sieci lokalnej jak ktoś musi przekompkować duży program, to może skorzystać z uprzejmości kolegów (i koleżanek) i użyć rdzeni jakimi oni dysponują;

Potrafi to zarówno WIndows (IncrediBuild) jak i Linux (distcc).

> Manipulowanie oknami programów na innych komputerach (łacznie z rysowaniem na nich);

Od samego początku potrafi to protokół X.

> Udostępnianie w sieci działających programów; Łatwe montowanie zdalnych kart sieciowych (odpowiedniki NAT, VPN) i łatwe filtrowanie dostępnych adresów sieciowych (odpowiednik Firewall).

Chyba ostatni komputer jaki widziałeś to była końcówka lat 80.

> W Plan9 to wszystko robi się prostymi skryptami a nie monstrualnymi programami które tworzone są przez dr i prof. i które tylko oni są w stanie obsługiwać.

Co oznacza, że 90% ludzi nie może z nich korzystać.

Pod Linuxem, wszystko co dotyczy firealla, można obsługiwać z konsoli z
użyciem iptables i jest wiele nakładek graficznych.

> Gdy amigowy program posiada coś takiego jak "port AREXXa" to można mu wydawać komendy w celu kontroli za pomocą skryptu.

Bardzo niewiele z programów potrafiło zrobic coś uzytecznego. Zazywczja
udostępniały domyślny iface za pomocą którego dało się zrobić bardzo
proste operacje.

> Po co tak się trudzić zamiast klikać? Np. jak mamy do przetworzenia tekstury w programie graficznym 2D, a następnie chcemy ich użyć do renderingu scenek 3D a potem jeszcze złożyć to w całość w programie do nieliniowego montarzu filmów. To (ZTCW) AREXX może to wszystko zrobić. W ciągu 35 lat jak się interesuję komputerami NIE SŁYSZAŁEM ABY JAKIKOLWIEK INNY SYSTEM OPERACYJNY TO UMOŻLIWIAŁ.

Wiec przespałeś VBA. Używałem właśnie w tym celu (Corel, Excel, Word,
PhotoPaint i kilaknaście inych których nie pomnę). Jesteś pewny, że masz
kwalifikacje do rozmowy na takie tematy?

Tak, mowa o sterowaniu programów z poza ich wewnątrznych mechanizmów. na
przykląd otwarciu Corela, naryzowaniu kółka i wklejeniu do worda, ze
skryptu.

> Ja nie winię żadnych wielkich korpo za to że robią wodę z mózgów programistów. Bo takie wielkie korpo nigdy by nie zaistniało bez układu ze spec. służbami i rządami.

Czyli jednak reptalianie.

> KREATYWNA/ROZRYWKOWA PLATFORMA DOMOWA JEST NIEZBĘDNA DO NORMALNEGO ROZWOJU SPOŁECZEŃSTWA I ŻADEN BIUROWY ANI SERWEROWY SYSTEM JEJ NIE ZASTĄPI.

Już zastapił. Ponadto prawdę mówiąc, Windwos stał się takim
rozrywkowo-multimedialnym systemem do zabawy, w którym praca jest coraz
bardziej upierdliwa.

> Zarówno Linus Torvalds jak i Ryszard Stallman dają nam "darmowe i wolne oprogramowanie" z pełną świadomością i premedytacją, że jest ono przestarzałe i nic nie zamierzają z tym robić.

Zabawne, że działa bardzo dobrze. Na tyle, że w zasadzie cały świat na
tym bazuje.

> Podam tylko jeden przykład jak chore są te systemy z lat 1970. (Linuks i w.w. reszta):
> "Jak stwierdzić, że nastąpiła utrata połączenia na na gnieździe IP/TCP synchronicznym lub asynchronicznym?!?"
> To banalny temat godny rozprawy doktorskiej.

Super, zainteresuj się więc jak odpiąc po AmigaOS process (przez niego
samego) aby stał się autonomiczny. Tutaj, bez habilitacji, nie da się
podejść.

PS. Programowałem Amigę w hardware/asm i AmigaOS. Na wszystkich etapach
i wielu językach programowania. Podobnie z Linuxem, podobnie z
Widnowsem. Większosć rzeczy która padłą w tym mailu to ignorancja.
Uwielbiam Amigę, ale mówienie o niej w taki sposób i używanie kłamstw i
niedomówień, nie pomaga w obiektywnej dyskusji. AmigaOS miałą wiele
zalet i wiele wad. Wydawało mi się, że czasy kiedy ludzie przekrzykiwali
się przez czasopisma półfaktami mineły razem z takimi pozycjami jak
Amigowiec czy Bajtek. A tu proszę, usenet i na nowo.

[xxxx]

W dniu 05.12.2021 o 06:01, Jacek Marcin Jaworski pisze:
> Wstęp [...]

Kolega to pisarz jakiś? Tyle tekstu na news rzadko się zdarza. Z tekstu
wynika pewna fiksacja na punkcie Plan9, ale braki merytoryczne spore.
Lepiej nie wypowiadać się na tematy, o których nie ma się pojęcia.
AmigaOS bez ochrony pamięci (powód brak MMU) nie wytrzymałby
konkurencji. Musiałyby za tym pójść drastyczne zmiany. ARexx jest fajny
i ciągle żyje ale jest cała masa podobnych w działaniu języków
skryptowych. Co do Linuksa i Java to, sorry, bzdety jakieś.

Amigę zabiły problemy finansowe C= i brak softu. Gdyby C= było
zarządzane w tamtych czasach inaczej dziś świat byłby inny. Byłaby kasa
pojawiły by się firmy robiące dobry soft na Amigę, zaczątki były: Był
Pagestream, Lightwave, Wordworth... brakowało przeglądarki z prawdziwego
zdarzenia i do dziś to jest problemem. Mamy AmigaOS 3.2, fajnie ale 30
lat za późno, dziś powinna być wersja 32 ze wsparciem 64bit, wielu
rdzeni, powinno dać się uruchomić java, pythona a obsługa 3D w 4k na
wielu monitorach nie powinna być problemem.

Fajnie że coś się jeszcze tli w świecie amigowym. Sporo ludzi z
sentymentu wraca do tej platformy i powstają cuda, choćby takie RGB2HDMI
na RaspberryPi, które ułatwia podłączenie Amigi do czegokolwiek w
dzisiejszych czasach i załatwia definitywnie problem migotania obrazu w
trybach interlace, czy taki PiStorm, który załatwia problem karty turbo
do Amigi (koszmarnie drogie lub nie do dostania) dając dodatkowe
możliwości w postaci pamięci RAM, obsługi dysków wirtualnych, klawiatury
i myszy USB, karty graficznej. Sceptycy powiedzą że to już nie Amiga...
fakt emulowany jest procesor, ale reszta to Amiga i skoro AmigaOS na tym
działa i daje dodatkowe możliwości to czemu nie?

Pozdrawiam, wszystkich Amigowców, którzy jeszcze mają sprzęt i go
uruchamiają od czasu do czasu, aby sobie przypomnieć stare lata :)