🚀 go-pugleaf

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.