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.