Transkrypcja
Geneza rozmowy i literatura
Cześć, Michał.
Cześć, Wojtek!
No to dzisiaj ciekawy system wpadł. Mam trochę flashbacków chyba z porannego wykładu z uczelni, bo widzę „Systemy peracyjne”
Tego co 20 lat temu… Tego porannego.
Dokładnie 20 lat temu.
To ja na niego nie zdążyłem.
Poranny wykład o 7:30, poniedziałek – „Podstawy systemów operacyjnych”.
Bardzo ciekawie to brzmi, ale no niestety w poniedziałek o 7:30 to się nie dało. Do tego musiałem tę książkę pierwszą przeczytać dwa razy.
Klasyk, zdaje się, tak?
Klasyk. Raz ją przeczytałem przed studiami jeszcze, tak się złożyło, a drugi raz już na studiach. Spóźniłem się na ten wykład. No i to są dwie takie książeczki, którymi będziemy się podpierać. Tutaj, jak widać, one nie dość, że fajnie leżą,
Są solidne, to się podeprzeć można też dobrze…
To są takie cegły porządne, mimo że no to nie jest branża ta właśnie budowlana. Ale są solidne i to, co w nich się zawiera, to jest właśnie taka solidna doza podstaw. Przy czym warto zauważyć, że ta książeczka ma tylko 800 stron treści, tutaj na papierze. Tamta ma 1000, bo jest tak bardziej jakoś tego… cieńsze ma kartki… Trzeba uważać. A tutaj dodatkowe 500 leży w internetach, dlatego całość ma 1300. No i tak, tamta pierwsza to może wyjątkowo zerknijmy do literatury, od razu przedstawię. To są „Podstawy systemów operacyjnych” Abrahama Silberschatza i Petera B. Galvina. (Dobrze przeczytałem? Dobrze.)
Dobrze. Tak.
To jest pozycja z roku 2000, więc zdawałoby się, że już muzealna, ale tak nie do końca,
Co tam się mogło zmienić…
Nic nam się właśnie nie zmieniło. Wszystko jest tak, jak tam napisali, z wydawnictwa WNT. A ta druga jest ciutkę świeższa, bo jest z Helion, 2018. I nazywa się „Systemy operacyjne: architektura, funkcjonowanie i projektowanie”. Autor: William Stallings. Czyli tutaj są rzeczy świeższe i tu będziemy zerkać, jak będziemy wspominać gdzieś tam kiedyś współczesne systemy – zarówno Windowsy, jak i podobne. Tylko chyba Amigi tutaj nie było, ale tam jest…
Kupujemy z innych źródeł, bo to też ciekawe pewnie tematy.
Zdecydowanie. No, a i tu jeszcze jest o Androidzie, zdziebuchno. Nie, nie było jeszcze tam. Tam („Podstawy systemów operacyjnych”) jest najświeższe coś to jest chyba w ogóle Linux jakiś taki… No wiadomo, też taki już skostniały lekko.
No tak, tak, tak.
Ale tam z kolei są historyczne rzeczy.
No to tutaj pojawia się pytanie: po co takiemu współczesnemu programiście w ogóle wiedzieć takie rzeczy? Czy warto wiedzieć?
Przecież to jest superfajne, nie?!
Nie no, pomijając oczywiście, że to jest super fajne. Rzecz dyskusyjna…
Zaraz to obdyskutujemy
Bo tutaj oczywiście wyjdzie w naszej dyskusji, że ja na przykład nie jestem jakimś wielkim fanem systemów operacyjnych.
Po dzisiejszym odcinku będziesz. A góra po następnym.
Po dzisiejszym może zostanę. Ty jesteś znanym fanem systemów… systemów na literę L. Kończących się na -inux.
W wąskich kręgach, wiadomo [śmiech].
Ale właśnie pytanie, czy taki programista, deweloper w dzisiejszych czasach, czy warto w ogóle takie podstawy wiedzieć? Czy to jest jeszcze do czegoś potrzebne?
Moim zdaniem zdecydowanie tak. Nie dość, że warto to wiedzieć, to właśnie jest to wręcz wymagane nieraz, żeby jakoś sensownie umieścić ten nasz kawałek kodu właśnie w tym czymś. Bo możemy sobie pisać w dowolnym języku i jakoś to tam też dowolnie uruchamiać, zależnie od platformy, na jaką piszemy. Czy to będzie jakieś interpretowane coś, czy kompilowane, czy jakaś wirtualizacja. Jest mnóstwo sposobów, jak możemy swój kawałek kodu przygotować i odpalić na sprzęcie. I teraz pytanie właśnie, jak to zrobić na określonym sprzęcie? I odpowiedzi można znaleźć w tych dwóch książkach, znaczy w każdej z osobna, a w dwóch to już w ogóle.
Aktualnie napisać w Javie i napisać raz i odpalić wszędzie.
Zgodnie z hasłem marketingowym. No, naprawdę, żeby poznać jednak kontekst tego, co robimy w jakimś takim szerszym otoczeniu, rzeczywiście pewnie, pewnie mimo wszystko warto gdzieś tam, gdzieś tam sobie takie podstawy też poznać.
Tak, my będziemy przez te wszystkie takie najbardziej podstawowe punkty dzisiaj przychodzić. Mam nadzieję, że zdążymy. Zobaczymy, jak to wyjdzie. Ale żeby naszkicować, co jest właśnie sednem tutaj zagadnienia, musimy to wszystko wypunktować. I wtedy właśnie wyjdzie, czy warto i jeżeli już to, że dlaczego w ogóle warto. No i to chyba warto sobie też powiedzieć, że no tutaj nie chcemy też robić kopii oczywiście z wykładu „Podstawy”, tylko bardziej poruszyć te tematy w kontekście naszej codziennej pracy. Więc, czy to rzeczy z pamięcią, czy to rzeczy z „input-output”, wszystko to gdzieś zaczepimy o nasze programistyczne, że tak powiem…
Mało tego, rozmawialiśmy o architekturach, rozmawialiśmy o „eventologii”, rozmawialiśmy o reaktywności. To wszystko się tutaj znajdzie. To wszystko jest taka…
I nawet o grach rozmawialiśmy i o ich architekturach, i ich „eventologii”, i sposobie w jakie… sposobach w jakie one sobie radzą ze sprzętem na przykład. I to też tutaj znajdzie potwierdzenie.
No tak, tak. Czyli wszystko to już było. Wszystko było, to było. I warto, warto może poznać, oczywiście, jak to jak to drzewiej bywało, jak to drzewiej i bywało.
Czym jest system operacyjny?
Ale najpierw to może co to w ogóle, co to w ogóle ten system? Co to ten system?
No właśnie, no to co to właściwie jest ten system? To system operacyjny to jest system, który wykonuje operacje. Operacja…
To jest bardzo taka prosta i jasna definicja. Tego. Przemyślana, wysmażona.
Mi bardzo spodobała się definicja z Silberschatz, który napisał, że system operacyjny jest troszkę jak rząd. Taka polityczna analogia. I tak jak rząd, system nie wykonuje żadnej pożytecznej funkcji.
To by się zgadzało.
Natomiast udostępnia pewne środowisko, żeby programy użytkownika mogły robić pożyteczne funkcje. Więc gdyby były jak rząd, to by było tak jak tutaj pan Silberschatz napisał. Czyli, że nasze są stemplowane, ale niektóre są na Androida. Właśnie, bo jeszcze punktem obowiązkowym będzie taka mała fala hejtu, która się przeleje przez to wszystko, ale takiego luźnego, takiego powiedzmy na poziomie wczesnego drwala. No więc on byłby jak, jak ten rząd, który wiadomo pożytecznego nie wnosi. Ale ja bym powiedział, że jednak ten system jest mniej jak rząd, a bardziej jak środowisko.
Nie? No bo to właściwie, czym właściwie taki system byłby? Możemy sobie wyciągnąć mnóstwo aspektów, których, które dotyczą systemów operacyjnych i na nich opierać jakąś tam definicję. Ale możemy też wybrać garstkę takich chyba najistotniejszych. I chyba najważniejszym aspektem jest w ogóle to, żeby to było w miarę wygodne albo nawet wygodne, tak jak tutaj definicja pada, środowisko do komunikacji użytkownika ze sprzętem z wykorzystaniem programów, na których ten użytkownik pracuje. Bo jakbyśmy mieli jakiś program, też właśnie w Javie napisany do odpalenia wszędzie, no to przechodzimy do pierwszego lepszego systemu operacyjnego. Załóżmy, że mamy tam już środowisko samej Javy, nie, że Java tam sobie poradzi, ale to jeszcze nie wystarczy, bo ta Java musi umieć się dogadać z tym, co jest pod spodem, nie? Bo i właśnie tutaj wchodzi system operacyjny i dostarcza nam tego środowiska i jeszcze wielu innych rzeczy potrzebnych do tego, żeby można było w ogóle takie… no można było swoje zadanie tam rzucić, nie?
Nie wiem, to dzisiaj mówimy, chociażby kawałka tego procesora, żeby tak, żeby i pamięci. To jest te dwa minimalne elementy, bo może nie potrzebować reszty, ale pamięć i tak…
Tak, no to się właśnie odkąd… od tego zaczynało gdzieś tam drzewiej i w jakiś tam takich zamierzchłych czasach, nie? Ale to jeszcze oprócz tego, że to jest to środowisko, to może z tego wynika już w ogóle, że to jest taki podstawowy program. Bo de facto system operacyjny jest… Mówienie o nim „program” to jest już trochę takie nadużycie, bo program to jest taka mniejsza rzecz, nie? To jest… przyjęło się, że program to jest coś, co wykonuje jakieś tam zadanie. Fajnie, jakby wykonywało jedno, a nie tak jak kiedyś tam… Nie wiem, kiedyś po internetach jeszcze albo po jakiś LAN-ach gdzieś w akademikach hulały takie cacka, gdzie ściągało się jednego exeka i tam był taki chaos ikon na nim i on potrafił odtwarzać MP3, wysyłać maile i miliard jeszcze innych rzeczy, totalnie niepotrzebnych. Kiedyś takie cacko ktoś gdzieś wrzucił chyba dla hecy. No to tutaj system operacyjny powinien pozwolić takiemu programowi, który ma jakieś określone zadanie, no jak na przykład ten nasz odtwarzacz muzyki, odtworzyć muzykę tak, żeby użytkownik usłyszał, co to się dzieje, nie? I do tego jest potrzebne ileś tam mniej lub bardziej złożonych rzeczy, współpracujących ze sobą. No i dopiero mamy przyjemność ze słuchania tej muzyki.
Jeszcze musi być muzyka odpowiednia, więc tu polecam soundtrack z „Wiedźmaka”.
Zastanawiałem się, jak nawiążesz w tym odcinku. Ale idealnie!
Ja już mam przygotowanych nawiązań 16. Ale to tak nie zawsze musi być i nie zawsze tak jest, bo dzisiaj wprawdzie królują pojęcia, że na wszystkim jest jakiś tam system operacyjny. Można się spotkać z tym, że no przede wszystkim na smartfonach mamy system operacyjny, na Androidy jakieś inne.
No właśnie, nowego rodzaju urządzeń, pojawiły się nowe rodzaju urządzeń.
I inne takie dziwactwa, których wcześniej nie było. I one też chodzą pod kontrolą tego, czy tamtego. A zaczęło się to może tak uwidaczniać gdzieś tam właśnie w czasach, jak te książki powstawały, jak właśnie oprogramowanie na przykład na urządzenia mobilne stawało się coraz bardziej skomplikowane i na początku nie było mowy o systemie operacyjnym na przykład na komórkę, tylko raczej mówiło się o „firmware”ze. Podobnie jakiś, nie wiem, dekoder telewizji, czy czy coś innego, mniejsze urządzenia, ale już o zaawansowanych funkcjach jeszcze niekoniecznie musiały mieć system operacyjny. Dzisiaj otwieramy pierwszy lepszy, odpalamy telewizor pierwszy lepszy i tam mamy system operacyjny, najczęściej Android TV. Chyba, że ktoś ma z jabłkiem, nie wiem, czy są, chyba nie ma. No ale są też Samsungowe, LG ma swój, wprowadza swoje własne. A niektóre są na tyle uproszczone jeszcze, że właśnie one byłyby tym „firmware”em. I ten „firmware” to w uproszczeniu byłby taki bardzo prosty system operacyjny, bo on by dawał właśnie tę warstwę abstrakcji pomiędzy aplikacjami a tym sprzętem, na którym to chodzi. W tym wypadku byłby to ten telewizor.
No i to taka podstawowa różnica między „firmware”em a systemem operacyjnym to chyba polega na tym, że to pierwsze jest bardzo proste, a to drugie już nie jest, nie, że jest bardzo zaawansowane.
„Firmware” być może można by było porównać do takich wczesnych wersji systemów operacyjnych, bardziej wsadowych, nie? Czyli, że mamy, mamy po prostu jakieś API i jakiś taki podstawowy, bazowy program, który pozwala nam uruchamiać kolejne zadania. To o tym będziemy mówić w dalszych punktach. Jak to tam wcześniej bywało.
Ewolucja systemów operacyjnych
Czyli tak, w dzisiejszych, że tak powiem nomenklaturze, możemy powiedzieć, że jeśli coś jest „smart”, tak jak mamy Smart TV, no to to już jest pewnie bardziej w stronę systemu operacyjnego. Na stare telewizory, które miały tylko zgłośnić…
System operacyjny, który pewnie nawet różnił się per model telewizora jednego u jednego dostawcy. I podobnie z komórkami, bo na przykład na Nokiach królowały i nie tylko na Nokiach w pewnym momencie Symbian OS-y i to było, to było uznawane za system operacyjny. To miało tam swoje wątki i w ogóle jak się na to programowało. A jak ktoś miał przyjemność, to polecam wrócić, bo to w C++ie się kodowało jeszcze dodatkowo. To tam naprawdę trzeba było też tam tego pokroju książkę lepiej przeczytać zanim się do tego siadło. A i tam było dość rozbudowane. No i faktycznie możliwości tego jako systemu operacyjnego to dawały złudzenie pracy na prawdziwym systemie. Natomiast jak się w tych samych czasach siadało do jakiegoś Sony Ericssona z jakimś… No, to można było wrzucić tę swoją apkę Javową, nie? I ona tam trafiała do tego swojego… to nie wiem, czy to była, no, musiała być jakaś JVM-ka, ale okrojona jak na ten sprzęcik, bo to miało i mało pamięci, i słaby procesor. No i tam się udało takie jedno coś podejrzewam odpalić za jednym zamachem. Jak to było odpalone, to cała reszta, z wyjątkiem oczywiście sprzętowego wsparcia dla tam odbierania rozmów czy czegoś, generalnie komunikacji, no bo to musiało być, nie?
Czyli po prostu zarówno „firmware”, jak i system operacyjny dają środowisko. Tylko różnią się poziomem komplikacji. No i to środowisko musi pozwalać uruchamiać jakieś tam programy. Pytanie, czy one są, czy to środowisko jest jednozadaniowe, czy wielozadaniowe. To tutaj też ciekawe wychodzą z tego wnioski. I co jeszcze? No właśnie, to jest zestaw usług, które pozwalają… usług czy też w ogóle API jakiegoś, żeby można było komunikować się z tym sprzętem. I to się wszystko składa na taki zbiorczy obraz pośrednika między nami, jako użytkownikiem, a tym właśnie sprzętem, który tam sobie pod spodem jest.
Nie ma to taka definicja. Jeżeli pomoże, 9 minut około. Szybki. Już na wykładzie najszybciej do tego się przesypiało te wykłady. No bo zaczął tu przeczytać, już było.
No właśnie. I poruszyliśmy kwestię: „Do czego to jest?”. A jak to, jak to bywało wcześniej? Jak to bywało, jak nie było, albo tak historycznie? No, tego z czego to się to wzięło? No bo pewnie te systemy też nie powstały tak od razu, jak…
Nie, one sobie wiadomo też systemy, w sensie komputery, zupełnie inaczej wyglądały. To były najpierw mózgi elektronowe, później jakieś maszyny liczące. A wszystko było bardziej analogowe, były taśmy perforowane. Więc jakby te systemy też inaczej wyglądały. Nawet ciężko pewnie powiedzieć, że to były systemy w rozumieniu takim obecnym tego słowa.
Pewnie bardziej tamte czasy to jak najbardziej systemy porządnego czegoś. Ale pewnie jest liczba, ilość funkcji, która w tamtych systemach była, no, jest rząd wielkości mniejsza, niż w naszej królowej apce, którą na co dzień żeśmy…
Więc to też jest takie ciekawe chyba, skok skomplikowania współczesnych systemów operacyjnych, na które chyba są jednym obecnie z najbardziej takich skomplikowanych… maszyny.
Tak, oczywiście. No, chyba, że ktoś zrobi jakiś bardzo skomplikowany system, ale to rzeczywiście chyba systemy operacyjne są takie najbardziej obecnie rozbudowane.
Tak. Wspomnieliśmy, że one są architektonicznie też arcydziełem, bo muszą… No, może Windowsa tutaj tak prawda, można mniej docenić. Chociaż Windows też tam ma coś takie, przynajmniej dwie takie książki to ja mam o podobnym rozmiarze na temat Windowsa. Bałem się jeszcze tam zajrzeć, szczerze powiedziawszy. Przeczytałem spis treści, ale przeczytam, jak babcię kocham, kiedyś tam. Także te systemy mogą się pochwalić bardzo zaawansowaną architekturą. Mogą się pochwalić zaawansowaną „eventologią”, algorytmiką nie najgorszą też, wręcz użyciem kilku architektów czasami w różnych miejscach. Różne, różne jakby sposoby. To nie jest tak, że system jest napisany w jednej architekturze, dwuwarstwowej, w której państwowej na przykład, albo w ogóle w jakimś chaotycznej.
Tak, no, zależnie od tego, co tam rozważamy, to poszczególne fragmenty tego systemu są, no, wiadomo, muszą być jakoś tam dopasowane do tych wymagań. I też już chyba można wywnioskować, że właśnie taki system to nie jest po prostu program, tylko to jest całe naręcze programów, które są uruchamiane. I jest ten jeden główny program, ten taki „main”, najgłówniejszy, od którego w ogóle wszystko się zaczyna, od którego Grid zaczyna pracę. To ten właśnie w „Tronie”, jak ziomek zrobił tego Grida, to tam właśnie to był ten „main”. Dopiero na nim tam zbudowano wszystko, budowano te drogi i budynki i tamte pojazdy fajne. No ale system, jak można z nazwy wywnioskować, to jest połączenie wielu elementów, które ze sobą współpracują. No i nie od samego początku tak było, że było tych wiele elementów. Na początku właśnie były pojedyncze elementy.
A żeby też najlepiej dowiedzieć się, jak to było na początku, to trzeba wrócić do lat 50. jeszcze, kiedy nie było systemów operacyjnych. No wtedy komputery to były wielkie pokoje wypełnione lampami elektronowymi, pełne okablowania i techników biegających i wymieniających te lampy. Bo ja gdzieś przeczytałem jakąś anegdotę, to w takim, jak on się nazywał ten ENIAC? Tak, taki duży. To ten to jeszcze pradziad tych, których już zaczynamy rozmawiać. Ale chyba ENIAC-a dotyczyła ta anegdota w latach 40. Chyba średnia średni czas wymiany jakiejś lampy, a było ich tam chyba z kilkanaście tysięcy, był liczony w minutach. W dziesiątkach minut, może w tak najlepszym wypadku od kilkunastu do kilkudziesięciu. Więc raz na jakiś czas to dość gęsto często taki technik z koszykiem lamp musiał się przechadzać. Jak któraś nie świeciła, to im wykręcać.
No tak, tak, oni musieli wtedy fiksować te „debugging”, no w sensie musieli faktycznie te robaczki zabijać.
One pewnie w sumie te lampy, no tak, dobra, lampy podgryzały karty na pewno.
Sterownik bramy i go tam usmażyło. No to co może, mogło się dziać w ENIAC-u, nie? Ślimaki, nietoperze, cokolwiek, pająki. Wszystko. Pająki. Wystarczy spojrzeć na dowolny pokój, który mamy w mieszkaniach. Nie instalować tam systemów operacyjnych.
Dobra, no więc jak mieliśmy ten w latach 50. te takie wielkie pokoje wypełnione lampami elektronowymi, to, no, to tworzyło to takie coś, co się później przekształciło w dźwięczną nazwę – komputer główny, mainframe. To były właśnie te takie wielkie komputery główne. To były bardzo kosztowne maszyny, bo to narzędziem to ciężko nazwać, obsługiwane przez tam sztab ludzi i wykonujące obliczenia. I te obliczenia przenoszono na kartach perforowanych. Najpierw takie właśnie tutaj w książeczce pierwszej jest, jest taka anegdota o szybkości czytnika takich kart. Najszybsze czytniki potrafiły przeprocesować 17 kart na sekundę, tak?
Co tam dawało, nie? To chyba jakoś inaczej. Tysiąc, 1200, no dobra, maksymalnie 1200 kart na minutę, czyli tak na sekundę to do 20. No i wiadomo, że te karty musiały być ułożone w odpowiedniej kolejności, bo to było nasz program, który był uruchamiany na czymś takim. I fajnie było, jak to miało jeszcze jakąś drukarkę wierzycką podczepioną, jako wyjście. Na wejściu dawało się te karty, to było jako zadanie ładowane do, albo jako wsad pojedynczy, który tam ten system przetwarzał i jak już przetworzył, to wypluwał właśnie na drukarkę, że błąd był, i jeszcze raz, albo już miał jakiś tam taki jednozadaniowy program uruchomieniowy, nie, który cały czas sobie tam chodził na tym czymś, ale był w stanie obsłużyć tylko to jedno zadanie. Czyli można było mu skolakcjonować zadania. I to się właśnie później zaczęło dziać, że żeby przyspieszyć pracę, zorientowano się szybko, że to jest dość niewydajna metoda, jeżeli człowiek zwany operatorem musi tam te karty najpierw przygotować, wsadzić do tego czytnika, one się muszą przewalić przez tę całą maszynę, on musi przejechać po tym zaczytać… to wszystkie te operacje wejścia-wyjścia trwały koszmarnie długo względem tego, co on sam w stanie był ten już prosty procesor, nawet taki podejrzewam lampowy na początku, chociaż to już i tak pewnie tranzystorowe były… To musiałbym sprawdzić, bo, bo nie sprawdzałem. ENIAC był lampowy, ale te nowsze to podejrzewam, że już na tranzystorach były, żeby to już no jakoś sensownie działało, nie?
A później weszły dopiero procesory w latach… Zapomniałem, kiedy procesory były. 86. Zrobiono w gdzieś chyba pod koniec siedemdziesiątych. Ale też, ale pojawiły się w pewnym momencie i już można było to uruchamiać. Niemniej jednak te konstrukcje tranzystorowe i tak działały dość długo i to właśnie na nich były te pierwsze programy. No i przy takim niewydajnym procesie wejścia trzeba było jakoś ogarnąć to, żeby wykorzystać moc tej maszyny. Jeżeli nawet to było traktowane kilohercami, potrafiło wykonywać tysiące operacji na sekundę. Dzisiaj to jest liczba… śmiesznie mała dla nas, nie? Ale to w tamtych czasach człowiek jak porównał swoje możliwości do tego, no to to taka maszyna to był szczyt techniki, nie? Tysiące razy szybciej od człowieka potrafiło coś zrobić. Ale musiało przez większość tego czasu czekać. To zresztą przy reaktywności omawialiśmy dokładnie to samo zagadnienie. Tutaj już, już zaobserwowano, że to może zaboleć, więc powstały pierwsze takie sprytniejsze cacka już na dyskach. I właśnie stąd mamy pojęcie dysku twardego, bo różne jej maści dyski pamięci produkowano już wtedy. Powstawały pierwsze takie koncepty. Przepraszam, jeszcze najpierw taśmowe w ogóle pamięci, nie? To, to taka pamięć miękka, można powiedzieć. I to widzieliśmy na tych takich filmach fajnych, właśnie z tamtych lat, że stoją takie wielkie szafy i tamte magnetofony cały czas kręcą w lewo, w prawo.
I anegdota z NASA, że jak wrócili z księżyca, to im się zgubiły te taśmy. Co, nie?
Przypadek. Przypadek. Nie, po prostu masz pokój z taśmami, nagle nie masz pokoju. Stać. Machić 14 tysięcy. No to każda, no, każdemu może zostawić.
O tym, że magnetofonów już nie mają, bo już jeden koleś powiedział, że nie mają.
No tak, bo tam przewijał taśmy tym ołówkiem cały czas, to magnetofony psuły, ciągle po paski trzeba było wymienić. Mieliśmy te dyski, to można było taki nawet czytnik kart perforowanych, ale podejrzewam, że czytnik taki taśmowy być może też połączyć… mniejszy sens, bo on sam już dawno tę pamięć… nie w sensie był źródłem. Można było podłączyć taki czytnik, zbuforować to, co z tych kart wyskakiwało na dysk i to mogło się dziać pewnie tak nazwijmy to w wielu wątkach, żeby to przyspieszyć. I wtedy procesor był cały czas obciążony tym, co lubi najbardziej, czyli przetwarzaniem. I nawet w takim systemie wsadowym dostawaliśmy po kolei wyniki każdego takiego wsadu. On tam sobie robił to zadanie, jakie dostał, tyle czasu, ile potrzebował. Wypluwał te swoje wyniki na drukarkę wierzykową albo może jakąś nawet fajniejszą, no a później już na ekrany albo też i później do pamięci dyskowej. Czemużby nie? No, a jak się coś spieprzyło, no to to też, no, dzisiaj mamy popularne pojęcie „stack trace”, a tam po prostu „dump” pamięci i poszło. Nie, bo, no bo taki programista musiał wiedzieć, jak następnym podejściu karty poukładać, żeby jednak tego nie było.
No bo chyba to trzeba powiedzieć, że właśnie ta wielozadaniowość, ten taki multitasking i automatyzacja tego procesu, no, była też kluczowa dla tych pierwszych lat i dla pierwszych systemów. No bo praca przy tamtych moich ramach wyglądała troszkę inaczej, niż teraz. To nie jest tak, że każdy zasiadał do własnego, tak jak my teraz sobie tu siedzimy z naszym, tylko no, każdy przychodzi, umiał swoją kolejkę, miał swój wydzielony kawałek. Trzeba się było zapisywać. Wyniki dostawało się po jakimś tam czasie, na początku to były nawet jakieś tam dni.
To jeszcze zależnie od zadania, bo jak były jakieś proste, no to to szybko przeleciało, nie? Ale też trzeba było poczekać.
Tak, sprawiało, że koszt przeliczenia czegokolwiek był olbrzymi. Jakby każdy postęp w takim przyspieszeniu tego procesu, czy to właśnie wsadu, czy, czy gdzieś tam sterowania tego wyniku, no, jest ogromną oszczędnością. Oszczędności i dalszy jakby rozwój i dalsze skomplikowanie też samych właśnie systemów, czy jakby tych programów, które nadzorowały pracą tego, tego naszego.
Wtedy czapki z głów dla naszych pradziadów, którzy tego pilnowali, nie? Bo myślę, że tak, no to po prostu kawał solidnej roboty i bez tego byśmy nie mieli tutaj tych naszych.
Statek linii prostej jest, jest owoc ich prac, można powiedzieć. Dzięki temu każdy teraz może sobie siedzieć z laptopem i tutaj klikać. Ale wtedy wyglądało to troszkę inaczej. Więc te pierwsze systemy też wyglądały zupełnie inaczej i miały też troszkę inne role. No, nie miała tylu zadań, bo tak naprawdę tej wielozadaniowości jako takiego w rozumieniu naszego tutaj okienkowego przełączania się pomiędzy aplikacjami to w ogóle nie było. Okno otworzyć, ryzyko. Trzeba było uważać na te pająki.
No dokładnie. I ciężko mówić, no, bo to jakieś tam urządzeniach wyjścia, jak jakieś głośniki, czy czy nawet ekrany, bo to też dopiero pojawiło się w dalszym, w dalszym, w dalszym etapie. Więc jakby te systemy na początku jeszcze były w miarę proste i pewnie do łatwo było tak z naszego punktu widzenia, łatwiej byłoby ogarnąć złożoność algorytmiczną tego, co tam już faktycznie na tym procesorze hulało, nawet jeżeli to był taki wielozadaniowy szeregowy wsadowiec, który zbierał te w kolejce zadania, które miał sobie przetwarzać, robił je po kolei i wypluwał albo wyniki pozytywne, albo negatywne. I tak sobie działo w nieskończoność. Nie, no i fajnie właśnie, jakby działał non stop pod pełnym obciążeniem, żeby to się faktycznie zwróciło.
No, ale to całe to otoczenie robiło ten, ten klimat znany z filmów, gdzie właśnie mamy niezliczone takie szafy z mrowiem jakieś świecidełek i wszystko robi „pik, pik, pik” i tam się te taśmy kręcą. I nawet jest taka fajna scena chyba „Czy leci z nami pilot?”, jak tam się przewija motyw taki urządzenia, który rządowego oczywiście, które tam im dostarczono. Tylko nie pamiętam, czy to ten film, chyba ten, nie? I tam w którymś momencie jeden z głównych szefów pyta: „I wiecie już, co to robi?”. „Jeszcze nie wiemy. To musi coś robić, bo kosztowało 7 miliardów!”. Więc tego typu zagadnienia tutaj mamy, nie?
Historia i migracja koncepcji
No i teraz jakbyśmy tutaj posiłkowali się tą książeczką, jeśli mogę o cegłę poprosić, to na stronie 16. Mamy fajną taką, takie podsumowanie właśnie historii. Ja sobie pozwolę stąd zacytować, bo to jest oczywiście taki ogólny schemat. Nie wiem, czy będziemy w stanie wrzucić to do tego, do nagranka. Ale tak do kamery nie da rady tego pokazać, ale to się właśnie zaczyna od roku 1950, gdzie jeszcze nie za dużo było czegokolwiek. W latach 60. już się podziały, pojawiły systemy z podziałem czasu. I tutaj się pojawia taki termin „Multics”, który następnie w latach 70. ewoluował w stronę Unixa. I w 80. już na początku, powiedzmy, przełom 80. i 90., to już jest wykłucie się z tego Unixa Linuksa. No i tutaj jeszcze przy, jeszcze w tamtych latach, przepraszam, powiedzmy gdzieś tak na początku lat 80., jak już to wszystko zaczęło schodzić z niebieskich i trafiać pod strzechy…
To już właśnie lata 70. to jest ten przełom mikroprocesorach. I tu musimy odnaleźć dokładną datę, kiedy faktycznie powstał procesor 86, czy tam jakieś może wcześniejsze prostsze. Ale już stały możliwości, żeby tak na tyle zminiaturyzować ten cały sprzęt, żeby trafił na biurko, bo dla zwykłego, szarego Kowalskiego i te pierwsze komputerki one niekoniecznie musiały mieć systemy, podczas gdy już te wielkie już od dawna miały, nie? W latach 80. więc mamy tutaj z kolei znowuż powrót do tak jakby taką migrację koncertu. Właśnie na tym diagramie to też jest to, to jest właśnie diagram pokazujący migracje konceptów. Jego użyłem do takiej trochę historii, ale migracje konceptu, gdzie poszczególne takie zagadnienie, jak brak systemu, proste systemy czy wielozadaniowe systemy, mikrokątowały sobie z tych wielkich sprzętów, z tych wielkich maszyn do poziomu takich najpierw komputerów, które faktycznie już mieściły się nie tyle w domu użytkownika, co na jego nawet stole. A teraz mieszczą się w kieszeni, nie? Bo na przykład pojęcie systemu operacyjnego na urządzenia mobilne zawitało do nas dopiero już w XXI wieku, tak na dobrym. Mimo, że tam 20. były takie początki, jakieś handheldy i inne takie dziwactwa. Te może Nokię pierwsze symbianowe, bo Symbian właśnie od Nokii pochodzi z tego, co pamiętam, i chyba Ericsson jeszcze tam maczał palce w nim.
Wtedy pewnie każdy tam było w ogóle całe konsorcjum, które ci twórca chcieli jakiegokolwiek powodu, tak to… też standaryzacja… Zupełnie w ogóle nastąpiła ta standaryzacja. No bo na początku jak rynek jest rozdrobniony, no to zresztą podobnie było widać nawet zanim jeszcze wykształcił się standard w ogóle PC, tak naprawdę. No bo wcześniej to nie było takie oczywiste, że to właśnie pecet jako standard zdominuje w ogóle tutaj rynek komputerowy. I tak samo w systemach.
Dobrze, że to przywołałeś, bo to właśnie jest jeden z czynników, który ubił nam Amigę. A Amiga, ale z drugiej strony, który upowszechnił jednak właśnie ten standard, sprawdził, że no, można było z różnych klocków składać te komputery i też wszystko dzięki temu poszło do przodu. Więc no to są… Lubię firmę Commodore i ja postać i Jacka Trzmiela zwanego Trumielem. Ale jakoś tak, jakoś to tak zrobili, że dali się podejść i dali się zastąpić po prostu, nie? No, chyba zawsze tak jest w historii, że pewne rozwiązania może pojawiają się za szybko, może nie wyczuwają wiatru zmian. Ważne jest to, żeby właśnie poczuć ten wiatr w żagle i wykorzystać, ale nie powiem to oczywiście o takiej korupcji, jak jak była w Microsofcie, gdzie tam wiadomo.
Wątki tak, korupcyjne, od taty.
Nie pamiętam. No, ale właśnie tu się znowu uwidoczni ten, to rozróżnienie między „firmware”em a systemem jako takim. Ponieważ te proste komputerki, które zeszły właśnie z tych takich akademickich, najpierw może jeszcze rządowych, na szczeblu rządowym, powiedzmy tym najwyższym. Takie działające maszyny pewnie gdzieś tam w jakiejś wojskowości i innym takim ciężkim czymś używanym zeszły. One najpierw zeszły na ten poziom akademicki, gdzie już na uczelniach można było zajmować się tymi rzeczami, właśnie kształcić kolejne pokolenia specjalistów, którzy będą w stanie nie dość, że te obsługiwać, to jeszcze w ogóle rozwijać. To oni nam to pchnęli do przodu. Kolejnym krokiem było wpuszczenie tego pewnie w sektor prywatny dla firm, bo to dalej były drogie narzędzia, drogie rzeczy w ogóle i bardzo skomplikowane wciąż. Ale z czasem doszło to właśnie, dotarło pod strzechy. Tylko że też tutaj nie od razu w takiej formie już zaawansowanego systemu, bo wystarczy spojrzeć na ZX Spectrum, Atari, te wczesne, w sensie małe 8-bitowce, nie? Commodore 64. To są przykłady takich prostych maszynek, na których wprawdzie da się odpalić system operacyjny, ale one chyba były pomyślane do czegoś innego, tak bardziej, bardziej rozrywkowo. Miały udostępnić nowy rodzaj rozrywki w domu. Nie. Dopiero później jak już ludzie się tą rozrywką nacieszyli i to, co było najpierw „firmware”em na tych maszynkach przestało wystarczać, to później zaczęto na nich instalować, tworzyć i instalować systemy operacyjne. Może nie tyle na tych najsłabszych pod względem mocy, tylko już na ich nieco młodszych kolegach i koleżankach. No tu koleżanką nie do pominięcia jest cała rodzina Amigi. Dużo koleżanek, dużo przyjaciółek.
Ewolucja systemu AmigaOS
I to też to pokazuje. Te komputerki jakkolwiek mają system operacyjny, on się nazywa AmigaOS, czasem zwany AmigaDOSem, a czasem Workbench’em, bo taka była jego nazwa kodowa, w różnych wersjach sobie powstawał. I od samego początku był pomyślany jako system wielozadaniowy. Czyli już taka w ogóle większa rzecz. Więc musiał być na jakieś mocniejsze cacko wrzucony, niż taki zwykły Commodore 64 albo Atari XE, nie wspomnę. Więc tam zaczęły się zabawy z systemami od procesorów 16-bitowych. Mamy Amigę 500, mamy 16-bitowca, w 1200, 3000 i 4000 32-bitowe, wiadomo, Motorolki. Atari i następcy podobnie, bo to ta sama rodzina procesorów, więc one tam robiły wyścig. No i mamy rodzinę 86, która tam od najpierw X86. 71. Nazywał w ogóle był pecet poniżej 286. Chyba nie było. To 286. No i to już był taki komputer faktycznie „personal computer”, czyli PC. Od niego to wszystko wypączkowało. Dzisiaj to IBM zdaje się w pełni taki standard tutaj wykopał dołek pod naszą ulubioną Amigą. Ale pecety od samego początku miały DOS-a, na samym początku DOS-a, nie?
Natomiast na Amidze dawało się odpalić gry w ogóle bez udziału systemu operacyjnego, czyli de facto wracamy tutaj tak jakby poziom wcześniej i już mówimy znowu o firmware. Taka gra miała do dyspozycji cały komputer, ale musiała sama rozeznać się we wszystkim. Więc każda to robiła w ten sposób – pisane gry, każda z nich robiła to na swój własny sposób, tak jak rozumiała ten, jak programiści rozumieli ten to API, które dostali, tak jak umieli wykorzystać. Jedni lepiej, drudzy gorzej. I stąd mamy rozbieżności w tym, mamy rozbieżności w interfejsach, nawet jeżeli były jakieś wzorowane na kształt okienkowo jakiegoś. Mamy rozbieżności w ogóle w dostępie czy w architekturze takiej gry, nie? Na przykład stare gry są znane z tego, amigowe, że na nowych Amigach działały zbyt szybko. To nie miały sprytnej pętli gry.
Ale to jeszcze pamiętam nawet w latach 90. czasami jak odpalało się jakąś grę, to trzeba było na początku wybrać na przykład kartę dźwiękową. I była ta lista do wyboru – zgodna z Sound Blaster tak i tak, i trzeba było po prostu wybrać konkretny model, bo gra no jednak miała się skomunikować w sensie ona miała w sobie jeszcze jakieś niskopoziomową komunikację z konkretnym motorem, czyli nie było tej warstwy abstrakcji czy to systemowej, czy może później już takiej bardziej DirectXowej na przykład, która już totalnie jakby ukrywa coraz więcej. Sterowników już tak. Ale dostawaliśmy nawet wtedy te gry no jeszcze dość mocno niskopoziomowo z tego sprzętu, czy wejścia-wyjścia w ogólności, musiały musiał mieć świadomość na temat tych wszystkich detali.
Rodzaje interfejsów i rozszerzalność systemów
Więc to jest jedna rzecz, a druga rzecz chyba też taka, którą warto rozróżnić w tych systemach operacyjnych, to jest właśnie chyba pojawienie się też graficznych i takich, no, mówimy teraz okienkowo systemy, no bo to zwykle ta grafika w postaci okienek się przejawia, ale przecież pierwsze systemy to były tylko i wyłącznie na taki „command line”owe naprawdę. I jakby ten DOS przykładowy, no to nikt sobie tam za bardzo nie wyobrażał, znaczy nikt… niektórzy wyobrażali, bo te systemy konsolowe powstały. A no, na początku wiadomo, terminal, linia poleceń i wszystko robiło się w ten sposób. Ten terminal to jest właśnie takie rozszerzenie tej drukarki wierszowej, bo on po prostu wierszami to wszystko…
Było też zdalnym terminalem czasami, więc ta nazwa w ogóle, że terminal. Nie ma, teraz mówimy, że terminal czy konsola. Odpalamy sobie, możemy to w dowolnym systemie odpalić. Nawet pod Androidem odpalamy konsolę zwaną bardzo często terminalem i to no nie jest do końca ten sam terminal, który był kiedyś. Bo wcześniej ten, ta jednostka to siedziała w gmachu tam gdzieś, czy skrzyżowania od nas, a my mieliśmy ten terminal, właśnie monitor i klawiaturę i tyle, nie? Tak. I trzeba się było tam zalogować. No ale to to wszystko teraz mamy w systemach współczesnych na już duże komputery, na duże własne, ale większe rozmiary od tamtych i mocą obliczeniową, w jaki sposób mamy to zaemulowane, nie? Bo to są takie koncepty, które okazały się trafne i na przykład wygodniej jest teraz podłączyć się do systemu takim naszym terminalem, taką konsolą, wklepać jakieś tam nasze polecenia. Bo to też dzisiaj na pewno nie zdążymy o tym, ale gdzieś tam kiedyś powiemy, że jak w ogóle kształtowała się filozofia interfejsu dla takiego, dla tego systemu, nie? To co właśnie powiedziałeś, najpierw „terminalowe”, tekstowe operowanie, później jakieś bogatsze struktury ekranowe, jeszcze nie okna, nie? Bo w DOS-ie, czy w jakimś tam, w jakiś narzędziach unixowych, też się pojawiały takie namiastki wczesnej okienkowatości. No i dopiero prawdziwe interfejsy graficzne, gdzie tutaj uwaga, znowu Amiga była jedną z pierwszych porządnie wyglądających i działających konstrukcji.
Chyba też wtedy dlatego robiło takie wrażenie, że że to rzeczywiście te okienka i te animacje, które płynnie się robiły, taka piłeczka była, piłeczka to podbiła świat.
Ale to ona wynikała, ona wynikała z doskonałej architektury sprzętowej tego cacka oraz architektury software’owej już właśnie AmigaOS-a tego wczesnego. To demo, które takie legendarne, ta właśnie piłeczka odpalona w oknie w systemie, tym oknem można sobie było pomachać, nic się nie zacinało. To wynikało z tych wielu połączonych ze sobą czynników, że raz, że to było bardzo dobrze zaprojektowane i zaimplementowane software, można było mieć tam wielozadaniowość. Amiga chyba nie miała wywłaszczania z tego co pamiętam, przepraszam, ale wielozadaniowość miała taką porządną. I dwa, że sprzęt był tak zaprojektowany, żeby dał się z niego wykrzesać te właśnie możliwości, że po prostu poszczególne komponenty nie tłamsiły się nawzajem. Nie, trzeba było tam czekać za dużo, nie było duże zrównoleglenie. No i w ogóle już nawet wczesna Amiga to były takie systemy wieloprocesorowe, bo można było do Amigi dołożyć kartę z dodatkowym procesorem i to świetnie się w systemie odnajdywało. I wtedy mieliśmy dwa procesory fizyczne i naprawdę można było działać. Dwa lub więcej, bo takie karty dawały jeszcze jako procesory matematyczne.
Także jak w chmurze prawie jak w chmurze, no to skalowanie, no, dostawaliśmy procesor dodatkowy i koprocesor matematyczny, który dzisiaj można porównać do takiej karty graficznej i tych procesorów wektorowych, które tam są. Tak, no to jest też obecne rozwinięcie ogólnie rozszerzenia i jakby z całej architektury PC. Czyli możemy sobie różne karty rozszerzeń wkładać i dzięki temu mieć nowe funkcjonalności czy pewne rzeczy szybciej zrobione. No to to jest też kwestia właśnie tego standardu, który mamy i który też system nam fajnie ukrywa, dzięki temu możemy sobie po prostu wetknąć tę naszą kartę graficzną świeżo zakupioną, czy jakąś tam zgodna z Sound Blaster.
Ale to wtedy działa i nie potrzebujemy przeinstalowywać systemu. Nie potrzebujemy najczęściej… czasami.
Już to teraz raczej się nie zdarza, ale tutaj raczej koncepcyjnie…
Już dawno nie widziałem już takiej okazji. Ale te brzdęknięcia to, to się śnią po nocach.
Ale trzeba sobie też jasno powiedzieć, no, że tutaj system, no dowolny system, to już nie będziemy wskazywać palcem, który lepiej, który gorzej. Ale te systemy sobie właśnie fajnie radzą z podmianą tych różnych komponentów. No bo jednak też muszą i to wykryć i sobie ten nowy komponent gdzieś tam obsłużyć. No tak, żeby się nie pogubić w tym. To nie jest tak, że to jest wszystko już zaklejone na amen i system raz w stanie już nigdy nie będzie mógł się zmienić. To jego elastyczność jest naprawdę dużą zaletą.
To właśnie trzeba oddać faktycznie to pecetom, że to właśnie od nich się ten standard zaczął rozwijać. Bo idąc do Amigi i takiej prostej, czy może Atari też miało jakieś karty rozszerzeń? Nigdy nie miałem przyjemności na Atari ST w ogóle dotknąć nawet tego, nie miałem okazji, nie mówiąc już o tym, żeby się pobawić czy popracować. Ale być może też obsługiwała jakąś kartę. To jednak nie były takie rozszerzalne rzeczy, nie? Bo mieliśmy płytę główną z jednym slotem w tej Amidze i właśnie tam tylko pasowała ta karta rozszerzeń i koniec. I kart rozszerzeń było dużo różnych, ale w danym momencie mogłeś mieć tylko jedną zainstalowaną i tyle, nie? Natomiast standard PC zrobił to, zrobił architekturę sprzętową rozszerzalną i ustandaryzowaną właśnie, bo ta standaryzacja jest tutaj ważna i teraz mamy jako skutek tego możliwości takiego bez… no powiedzmy w miarę wygodnego dokładania tego sprzętu i ważne jest tylko, żeby ten kawałek oprogramowania zwany sterownikiem znalazł się w odpowiednim miejscu i został uruchomiony wtedy, kiedy trzeba, żeby sobie można było z takim urządzeniem się komunikować.
Sterowniki i zarządzanie sprzętem
No właśnie, dla kontrastu możemy sobie przytoczyć na przykład nasz światek programistyczny i czy tak łatwo nasze własne aplikacje radzą sobie z dodawaniem nowego sprzętu? Właśnie takie proste skalowanie, no, czasami jest tak. OK, dodamy sobie pamięć. No to jeszcze zwykle jakoś to tam sobie poradzi. Ale często takie dodawanie nowych sprzętowych zasobów to nie zawsze to nasza aplikacja tak z miejsca potrafią to obsłużyć, bo gdzieś musimy tutaj dodać adres, gdzieś musimy wskazać, coś skonfigurować. Więc jakby widać, że te systemy robią to z automatu, wiadomo to jest troszkę inny, można powiedzieć, poziom jednak. I może powiedzieć, te miejsca rozszerzenia w pececie są dobrze wyznaczone, więc system można sobie łatwo z tym poradzić. W naszych aplikacjach tych takich „extension pointów” nie ma takich oczywistych, ale też pojawiają się. No i nawet frameworki już nam dają od pewnego czasu.
Właśnie, no właśnie, ale to musimy sobie jakby też trochę zawczasu przewidzieć i to nie jest tak oczywiste, że nasza aplikacja się bardzo łatwo skaluje na nowy sprzęt, tak jak to wygląda w tych systemach operacyjnych.
Pamięcią 20 lat do tyłu to wcale nie było tak różowo.
No tak, to wtedy to już w ogóle tak naprawdę dodanie do tego, no, uda czy coś, to, to, no to żadna aplikacja jakby na bieżąco to praktycznie nie dało się tego zrobić. Trzeba zawsze było zrobić, podłączyć coś. Dopiero od jakiegoś czasu działa w miarę także, że się potrafi rozeznać w tym, co dostaje. To no właśnie, tutaj zasługa jest po stronie dostawców tego sprzętu i oprogramowania, że potrafią wpinać się w ten standard, robią to coraz lepiej. No i tak się składa na przykład, że skanery na Windowsie są wciąż dalej lepiej obsługiwane niż na Linuksie. Bo nawet takiego mema ostatnio widziałem, jak siedzi taki zmarnowany człowiek, nie pamiętam kontekstu, to jakiś taki bardziej klasyczne dzieło, i podpisane, że on właśnie próbował instalować sterowniki do skanera na Linuksie.
No także to, a coś o tym wiem, bo ja też kiedyś próbowałem i prawie tak samo skończyłem. No tak dobrze. Widzę, dzisiaj działa. Kilkanaście lat temu to też pamiętam, że jak ktoś miał bardziej egzotyczną kartę graficzną, on to żeby ustawić jakiś sensor rzeczy w Linuksie, bo sam też się z tym męczyłem, no to trzeba było troszkę pokonfigurować. To nie było tak, że suwaczkiem sobie jak w Windowsie ustawiałem te moje, eee, wtedy pewnie 1024 na 768. Tylko trzeba było jednak coś tam pokonfigurować, bo nie do końca ówczesny Linux rozumiał. Połowa biedy, jak to było w jakimś pliku. Trzeba tego było robić jakimiś magicznymi zaklęciami.
Zaklęcia albo, albo coś takiego. Więc a tutaj chyba też właśnie ten podział też systemu na sterowniki takie wbudowane, można powiedzieć generyczne, i te, które producenci dostarczają. Bo warto wiedzieć, że systemy jakby mają w sobie już dużo takich generycznych sterowników. To czasami podłączamy nową kartę graficzną, czy myszkę, to widzimy, że mamy tam jakiś „General Display Driver” albo „USB Device” i to jest nasza myszka albo nasza karta, czy coś tam. I w tym momencie już system wie o podstawowych funkcjonalnościach podłączonego sprzętu. Ale możemy sobie zainstalować specyficzne sterowniki tego urządzenia i to też się wepnie w nasz system i dzięki temu rozszerzone funkcje, które to urządzenie będzie nam dodawać. Na przykład jakieś dodatkowe przyciski, czy inne tam manipulatory, nie? A dla karty graficznej jakieś po prostu wypasione nowe funkcjonalności, nowe „feature’y”, które w kolejnych wersjach czy to OpenGL-a, czy DirectX-a były dodawane. Nie, ale muszą to wszystko sobie ogarnąć, ale to ogarniają, bo one są, które przychodzi od kolejnej wersji, mają już po prostu wbudowane drivery te podstawowe dla tego sprzętu znanego już do tej pory, nie?
Więc jeżeli na przykład wypuszczamy naszą własną edycję systemu nowego, powiedzmy. To musieli gdybyśmy chcieli coś takiego zrobić, ten dość karkołomny zagadnienie, abstrahując od oprogramowania, którego by nie było na niego, to musielibyśmy właśnie zadbać o to, żeby z istniejącym sprzętem on zechciał współpracować. Bo gdyby to miało być cacko na taki komputer, no to jak podłączę pendrive’a, to musi mi tam brzdęknąć, nie? Jak, jak podłączę go sobie przez HDMI do telewizora, no to chciałbym zobaczyć ten obraz stąd tam, nie? Więc to wszystko musi być oprogramowane. I to nie są trywialne rzeczy. I teraz sam się zdziwiłem ostatnio jak zrobiłem ten „properties” na katalogu C: Windows. Skąd tam jest 20 giga dyrdymałów? Nie, no i tak, teraz można sobie by było zastanowić, ile jest sterowników do wszystkich możliwych kart graficznych, jakie się pojawiły. No to do tej pory generycznych, nie generycznych, jakichś specyficznych, nie? Bo nawet XP-a jak się włączyło na jakimś tam powiedzmy, do XP-ek się wtykało karty, które były wydawane przed wyjściem, przed pojawieniem się XP-a, to on pytał już w depnięciem swoim, czy zainstalować sterownik do tego tam, czy nie? Nie, albo wręcz nie pytał, tylko od razu wyświetlał co, co tam trzeba. Przepraszam. Czyli już wtedy on wiedział, że taka karta była, nie? A od tamtego czasu do dzisiaj tyle wody w rzekach upłynęło – karty, drukarki, wszystko, wszystkie możliwe urządzenia peryferyjne, tak zwane. Więc no tutaj system naprawdę dużo na głowie i rzeczywiście, no, musi być, musi taki być elastyczny i łatwo konfigurowalny i taka właśnie na szczęście jest. Standardy pomagają.
No właśnie, tak to jest chyba kluczowa sprawa – standaryzacja, czy to sprzętowa, czy właśnie software’owa poprzez warstwę sterowników, którą zapewnia system. No to chyba te teraz właśnie dobrnęliśmy do takiego podsumowania tych składowych systemu operacyjnego. To już się wszystko w tej naszej rozmowie przewijało jakoś tam. I żeby móc sformułować takie, żeby móc stworzyć takie środowisko uruchomieniowe dla aplikacji użytkownika, zapewnić im możliwość komunikacji ze sprzętem, z użytkownikiem, ze sobą nawzajem, bo przecież no bo nie odpalamy programów dla samych siebie, tylko często one właśnie muszą rozmawiać ze sobą nawzajem. To są aplikacje klient-serwer, które mogą na przykład być odpalone tutaj u nas, wymagają być może aplikacji, żeby się połączyć ze swoimi zdalnymi jakimiś tam końcówkami gdzieś na innych komputerach, nie? Więc tutaj warstwa sieciowa też jest potrzebna.
Procesy i wątki
Ale żeby na w ogóle można było mówić o jakimkolwiek odpalaniu, to na pewno są potrzebne zadania zwane procesami. To właśnie te zadania przekształciły się z tych zadań wsadowych. Procesy. Można połączyć dwa terminy: proces i procesor. Co tutaj połączenie jest dość oczywiste. Proces procesuje procesy.
Dokładnie, brzmi logicznie. Nic więcej nie trzeba dodawać.
Te procesy mogą być podzielone na wątki. O wątkach też już opowiadaliśmy wielokrotnie. Wątek to jest taki jakby podproces danego procesu, bo procesy to są te główne zadania systemu. Czyli po prostu programy, które odpalamy. To znaczy zadania to jest jeszcze coś innego. Program, który jeżeli postawimy tak równości między terminem zadanie i program, to ten program może być odpalony w jednym lub więcej procesach, nie? Czyli możemy ten kod jego na pewno w minimum jednym procesie zobaczyć, ale jeżeli on by chciał odpalić ileś tam procesów tych ciężkich systemowych, to to może, bo ma jakieś tam limit na to. Natomiast jeżeli by chciał odpalać, podzielić się na mniejsze cząstki, no to właśnie podzielić się na wątki. A jakbyśmy jeszcze dalej zeszli, to na te mikrowątki, o których rozmawialiśmy. Ale one już są poza najczęściej podejrzewam, bo być może znajdziemy, jesteśmy w stanie znaleźć jakiś system, który nam nawet do poziomu mikrowątków pozwoli się podzielić. Ale to raczej są już zadania takie bardziej… mogą sobie chcieć same wprowadzać jakiś swój własny framework, tak jak na przykład Project Loom omawiany tutaj, w którym możemy te mikrowątki sobie tworzyć, nie?
Czyli mamy zadania zwane procesami i wątki. Jakie mamy, to musimy je zaplanować, no bo wcześniej było prosto. Mieliśmy ten wsad i kolejkę. Zaplanowane było z góry, w takiej kolejności, w jakiej przyszły, leżały w tym buforze i w takiej były pobierane i można było z nimi coś robić. Jak się systemy rozszerzyły na wielozadaniowe, no to się okazało, że pewne zadania są może ważniejsze od innych, więc ich kolejność nie jest zawsze taka jak kolejność uruchamiania. Więc tutaj trzeba zarządzać planowaniem zadań i ich wykonaniem. Najpierw trzeba zaplanować, a później trzeba zarządzać ich wykonaniem, tak żeby faktycznie to złudzenie wielozadaniowości było wyczuwalne.
Tutaj przez planowanie rozumiemy przydzielanie kawałka czasu procesora, tak? Czy jednego z rdzeń procesora, jeśli mówimy już o współczesnych procesorach, dla danego właśnie zadania. Czyli także każde kawałek, każde zadanie, które jest tam w kolejce, jest gdzieś tam do uruchomienia, dostaje kawałek swojego czasu procesora. Liczy się szybciutko z tam swoje rzeczy i następuje przerwanie. Może tam jeszcze powiemy o tym, o tym później. I inny proces, inny wątek, inne zadanie, dostaje swój kawałek rdzenia procesora, czyli swój kawałek tortu.
Czyli chodzi właśnie, chodzi nam o to, żeby w miarę płynnie nastąpiło to przełączanie, tak żeby każde z zadań na naszym, naszym pececie mogło wykonywać płynnie i stwarzać właśnie płynność. No bo jak się zastanowimy właśnie nad dźwiękiem czy nad obrazem i tutaj złapiemy, coś jest nie halo, mamy przełączanie między wątkami. No to teraz można zastanowić się, no ale czemu mam ten dźwięk się nie rwie na przykład to co kilka milisekund? No bo przecież to nie jest tak…
Z kilku powodów. No właśnie, z kilku powodów i jednym z nich jest to, że on po prostu jest buforowany gdzie indziej i na przykład jest dedykowany, dedykowany układ dźwiękowy jako taki, traktowany jako taki układ peryferyjny względem procesora. Oczywiście, tu oczywiście w architekturze sprzętowej, ale jest mimo wszystko wewnątrz tego całego systemu komputerowego. I teraz to zadanie, w sensie ten bufor, w którym już są informacje o tym, jak wygenerować dźwięk, jest do niego tam cały czas wpychany i odświeżany. I jego zadaniem jest po prostu generować dźwięk w sposób nieprzerwany, nie? Wcześniej to mogło być robione na przykład w jakieś wcześniejszych komputerach, takich prostych, przez główny procesor. Ale już nawet te 8-bitowce miewały chyba takie układy. Gdyby jednak tego zabrakło, no to musielibyśmy skorzystać z multipleksowania. To, to akurat z tego korzystamy w generowaniu grafiki. Wcześniej właśnie też na głównym procesorze, a teraz już w procesorze karty graficznej. A multipleksowanie to jest zresztą ten sam termin leży u podstawy przełączania zadań, bo mamy jedno źródło ten pracy, ten ten właśnie nasz procesor fizyczny. Obojętnie, czy to będzie procesor, czy rdzeń tego procesora, dla uproszczenia traktujemy go jako procesor fizyczny. I to jest jedyna rzecz tutaj, która umożliwia wykonywanie tego kodu fizycznie, nie? Czyli, no, realizuje nasz program. I wiadomo, że jeżeli musimy przełączać się pomiędzy zadaniami, między programami, procesami ich, albo wątkami, no to każdy z kolejnym przełączany dostaje właśnie ten procesor na własność, na chwilę.
Na chwilę, tak. Wykonuje się na nim od momentu X do Y i oddaje go, nie? I to na przykład tutaj takie anegdoty można przytaczać z tego, systemów, które nie miały, nie obsługiwały wywłaszczania, ale wielozadaniowych. Jeżeli na przykład taki wątek czy proces nie chciał oddać władzy, to no to nikt nie mógł się wbić na ten procesor. Więc wymyślono wywłaszczanie, czyli że niezależnie od tego, czy wątek powie: „Spoko, dzięki za mój kwant czasu, niech ktoś inny teraz coś zrobi”, po prostu jest wykopywany z tego procesora. I tutaj przychodzi z pomocą, przychodzą struktury danych, które opisują ten, ten proces i wątek też, żeby zapamiętać adres jego ten, ostatni adres instrukcji wykonywanej, żeby można tam było płynnie powrócić. W związku z czym mamy ciągłość taką udawaną tego całego procesu z punktu widzenia wątku jako takiego. Ciągłość jest zachowana, nic tam się nie dzieje. On nawet nie wie, że został przerwany i wznowiony, chyba że sobie porówna licznik czasu zwany zegarem, co wtedy się może dowiedzieć, nie? Ale no właśnie, jeżeli by nie chciał oddać sterowania, to musiałby w takim systemie sobie siedzieć do końca, aż się wykona i odda. I na tym polega zawieszenie się takiego systemu bądź takiego programu.
Planowanie zadań i zagłodzone wątki
A jeszcze są takie przypadki związane z planowaniem zadań, też kolejna anegdota, i właśnie z tej książki pierwszej. Nie pamiętam, czy dotyczyła się pierwszych Linuksów czy jeszcze Multicsa. Że gdzieś tam po siedmiu latach operator zagłodzony wątek znalazł. Zagłodzony wątek, który nigdy się nie był w stanie dopchać i tam sobie siedział w pamięci 7 lat. Co pokazuje w ogóle klasę zagadnienia i czapki z głów znowu, bo utrzymalibyśmy Dockera, chociażby przez…
Że tak, to go tam odpalił, to po prostu zapomniał po tygodniu, że to jeszcze nie wróciło. A ona sobie siedziała gdzieś tam i priorytet innych był cały czas podbijany, a on był cały czas zagłodzony. Nie to i dzięki temu na przykład śmieszna rzecz, ale to pchnęło rozwój algorytmów zarządzania tymi wątkami, nie? Bo trzeba zaplanować, w jakim, w jakiej kolejności one będą uruchamiane, procesami jeszcze wtedy. No i następnie trzeba tę kolejność zachować uruchamiając je po prostu i ich poprzedników odłączając na moment. Nie wiem. Po pierwsze algorytmy takie zwykłe, czyli bierzemy po kolei i lecimy z każdym. Ale tak naprawdę no zadania mają różny stopień zużycia procesora, różny priorytet.
Tak, i operacje blokujące na przykład, o których mówiliśmy. Dokładnie. I też, też się okazuje, że na przykład we wczesnych, w systemach, wczesnych wersjach operacje blokujące też powodowały marnowanie, marnotrawienie czasu procesora. Więc wyeliminowano. Więc taki proces jest wywłaszczany, kiedy czeka na coś, nie? Tam się po prostu ustawia flagę, że on musi poczekać na przykład na to źródło danych. Jak źródło danych dostarcza to, co miało dostarczyć, to proces jest odblokowywany i w kolejnym cyklu tego algorytmu planisty może zostać wzięty i po prostu zrobić robotę.
I to jest właśnie dokładnie ta analogia, którą możemy nawiązać do poprzedniego odcinka, czyli tak jak system wywłaszcza zadania, które czekają synchronicznie na coś, tak samo w programowaniu reaktywnym my też możemy niejako wywłaszczać, czyli oddzielać wykonanie oczekiwania na jakiś, na jakiś „input/output”, na jakiś „network”. No bo my wtedy też marnujemy czas naszego procesora, czyli naszego wątku, więc raczej logiczne jest logicznej jednostki, więc stąd też jakby wynika no ten plus tego programowania reaktywnego i ogólnie takiego asynchronicznego. Bo właśnie wtedy nie czekamy, nie blokujemy w momencie długotrwałej operacji, tylko możemy lecieć z procesowaniem czegoś innego. No bo może w tym czasie możemy sobie zrobić innego „calla” do innego API albo pobrać z innej tabeli, bo akurat potrzebujemy odtworzyć coś w Winampie chociażby.
Dokładnie. Jeśli nasza aplikacja akurat się tym zajmuje. A to jest dokładnie ta sama analogia i to samo rozwiązanie, które już istnieje od dawna w systemach i tak naprawdę znając to rozwiązanie jaką możemy prościej odnaleźć pewne rozwiązania w naszych aplikacjach. A jeśli nie wiemy, że coś takiego jest, no to trzeba tę książkę przeczytać. To wtedy kodujemy robiąc wszystko synchronicznie, blokując i nawet nie wiedząc, że te problemy zostały już rozwiązane.
I to lata temu, bo ludzie się zetknęli z tym już tak z 20–30 lat temu. Wtedy właśnie… Unix to już ma bardzo długą historię. Od lat 60., w przełom 60. i 70. to jest taki, takie początki Unixa, ale no, niezaprzeczalnie jest to moim zdaniem najlepsza architektura, jaka powstała. Nie bez powodu tutaj Windows nie ma startu do tego, mimo że nadąż… próbuje nadążyć wciąż. Ale jakoś to nie wychodzi, nie? I ostatnio dodali Linuksa do siebie i koniec.
Najlepsze połączenie, no.
Na co to się stresować? Nie jeszcze kernela by musieli porządnego napisać. Nie robi „brzdęk”.
W Linuksie tak łatwo nie odpalisz Windowsa.
Oooodpalisz.
Tak łatwo? Tak, wiadomo, są emulatory i w ogóle.
Tak łatwo to nie.
Odpalały się na Linuksie natywne jakieś gry z Windowsa
No panie, ja Age’yka odpaliłem na Linuksie…
No dokładnie, ale to nie jest aż tak fajne.
…dźwięk mi nie działał, bo Sound Blastera nie było.
No właśnie, no właśnie, a w Windowsie działa.
Dobra, no to te… Myślę, że o składowych samych w sobie to jeszcze by nam tak dobrą chwilę zeszło, także zostało To dopiero zadrapaliśmy powierzchnię można powiedzieć tymi procesami. Także no, procesory to jest to sedno naszego wykonywania, ale one nie działają same, one potrzebują całej tej reszty swoich pobratymców, więc myślę, że ten odcinek moglibyśmy na tym zamknąć, a zacząć właśnie od składowych systemu i pojechać już po kilku takich najfajniejszych. Omówić je w następnym odcinku.
Brzmi ciekawie.
To tak zróbmy to.
Dzięki,Wojtek.
Dzięki, Michał.
Do następnego!