Skąd w ogóle wzięły się systemy operacyjne? Krótkie tło historyczne
Era „gołych” maszyn – kiedy komputer nie miał systemu
Pierwsze komputery nie znały pojęcia systemu operacyjnego. Były to ogromne maszyny, w których program wpisywało się bezpośrednio do pamięci za pomocą przełączników lub ładowało z kart perforowanych. Każde uruchomienie programu wymagało fizycznej ingerencji w maszynę i ręcznego przygotowania środowiska.
Programista musiał:
znać dokładną strukturę pamięci i rejestrów procesora,
samodzielnie zarządzać kolejnością zadań,
sam zadbać o obsługę błędów, wejścia/wyjścia, czasami nawet o „czyszczenie” pamięci po zakończeniu programu.
Nie było abstrakcji pliku, katalogu, użytkownika czy nawet procesu w dzisiejszym znaczeniu. Komputer wykonywał po prostu ciąg instrukcji maszynowych, bez żadnego „pośrednika” ułatwiającego życie użytkownikowi.
Zastanów się: gdy tworzysz dzisiaj program, masz nad sobą bibliotekę standardową, system plików, gotowe API. Jak wyglądałaby twoja praca, gdybyś musiał sam za każdym razem pisać kod do obsługi dysku, drukarki i pamięci?
Systemy wsadowe i pierwsze „monitory”
Wraz ze wzrostem mocy obliczeniowej i liczby użytkowników zaczęto szukać sposobu na bardziej efektywne wykorzystanie drogich komputerów mainframe. Pojawiły się systemy wsadowe (batch systems). Zamiast wpuszczać do maszyny jednego użytkownika, który blokował ją na godziny, zaczęto przygotowywać wsady – zbiory zadań uruchamiane jeden po drugim.
Tak narodziła się idea programu nadrzędnego, zwanego monitorem – praprzodka systemu operacyjnego. Monitor:
ładował kolejne programy do pamięci,
przypisywał im zasoby,
pilnował, by po zakończeniu zadania komputer przechodził płynnie do następnego.
Wciąż jednak nie było mowy o interakcji w czasie rzeczywistym, wielu użytkownikach jednocześnie ani o wygodzie. Liczyła się maksymalna przepustowość – ile zadań uda się „przepchnąć” przez komputer w jednostce czasu.
Współdzielenie czasu – krok w stronę człowieka
Kolejny przełom to tzw. systemy z podziałem czasu (time-sharing). Zamiast traktować komputer jak maszynę do kolejkowania zadań, zaczęto dzielić czas procesora na krótkie kwanty i „skakać” między użytkownikami. Dzięki temu kilku (lub kilkunastu) użytkowników mogło mieć wrażenie, że korzysta z komputera jednocześnie, każdy ze swojego terminala.
Pojawiły się wtedy pojęcia, które dla współczesnych systemów operacyjnych są kluczowe:
procesy i ich przełączanie,
mechanizmy ochrony pamięci,
konta użytkowników i uprawnienia,
planowanie zadań i priorytety.
System operacyjny zaczął pełnić rolę pośrednika między użytkownikiem a sprzętem – ds. zarządzania zasobami, bezpieczeństwa i wygody. Czy myślisz o systemie bardziej jak o narzędziu, czy jak o środowisku pracy, w którym spędzasz większość dnia?
System operacyjny jako warstwa abstrakcji
Z biegiem lat definicja systemu operacyjnego się krystalizowała. Można ją streścić w jednym zdaniu: system operacyjny to program, który zarządza sprzętem i udostępnia aplikacjom spójne, wygodne API. Ta warstwa abstrakcji kryje szczegóły działania procesora, pamięci i urządzeń, a w zamian daje:
Na tym tle UNIX, Windows i Linux nie są tylko trzema różnymi „systemami”. To trzy różne odpowiedzi na pytanie: jak pogodzić kontrolę nad sprzętem, wygodę użytkownika i potrzeby programistów.
Narodziny UNIX-a: mały zespół, wielka zmiana paradygmatu
Bell Labs, porzucony Multics i „domowy” projekt
Pod koniec lat 60. Bell Labs (laboratoria badawcze AT&T), MIT i General Electric pracowały nad ambitnym systemem Multics. Miał być bardzo zaawansowany: bezpieczny, współdzielony, z rozbudowanymi funkcjami. Ambicja jednak przygniotła projekt – rozwój był wolny, system skomplikowany i kosztowny.
Bell Labs wycofało się z Multics. Część zespołu – m.in. Ken Thompson i Dennis Ritchie – została bez dużego projektu, ale z głową pełną pomysłów. Thompson, korzystając z doświadczeń Multics, zaczął eksperymentować na mniejszej maszynie PDP-7. Jego celem było stworzenie prostego, eleganckiego systemu, który nada się do codziennej pracy programistów.
Tak rodził się UNIX – początkowo jako „domowy” projekt w laboratorium, nie jako produkt korporacyjny. Skromne zasoby wymuszały prostotę. To ograniczenie paradoksalnie okazało się największą siłą systemu.
UNIX na PDP-7: funkcjonalność zamiast fajerwerków
Pierwsza wersja UNIX-a powstała na małym komputerze PDP-7 z bardzo ograniczoną pamięcią. To wymuszało minimalizm: żadnych zbędnych funkcji, żadnego „przeinżynierowania”. System miał:
hierarchiczny system plików,
proste narzędzia tekstowe,
mechanizmy procesów i podstawowego bezpieczeństwa,
powłokę (shell) jako interaktywny interpreter poleceń.
UNIX szybko stał się środowiskiem do pracy dla badaczy: pisania i kompilowania kodu, przetwarzania tekstu, eksperymentów. Nie był „produktem końcowym” dla masowego użytkownika, tylko narzędziem dla inżynierów. To zadecydowało o jego kulturze – w centrum stanął tekst, skrypty, automatyzacja, a nie efektowna grafika.
Zadaj sobie pytanie: co dla ciebie jest ważniejsze – maksymalna wydajność i złożoność, czy prostota, którą da się ogarnąć i powtarzalnie automatyzować?
Język C i przenośność jako kluczowy przełom
Początkowo UNIX był napisany głównie w asemblerze. Dennis Ritchie pracował równolegle nad językiem C, który miał być „wysokopoziomowy”, ale wciąż bliski sprzętowi. Po połączeniu obu pomysłów wydarzyło się coś rewolucyjnego: znaczną część systemu operacyjnego przepisano w C.
Przyniosło to trzy potężne korzyści:
przenośność – system dało się stosunkowo łatwo przenieść na nowe maszyny,
czytelność – kod stał się zrozumiały dla większej liczby programistów,
łatwiejszy rozwój – dodawanie funkcji i poprawianie błędów przyspieszyło.
UNIX, w przeciwieństwie do wielu ówczesnych systemów, nie był już „przyspawany” do jednego typu komputera. To otworzyło drogę do jego rozprzestrzenienia się na uczelniach i w firmach, a później do powstania całej rodziny „uniksów” i systemów uniksopodobnych.
UNIX jako środowisko programistyczne
Jednym z celów twórców UNIX-a było stworzenie wygodnego środowiska pracy dla programistów. System zapewniał:
kompilator C,
narzędzia do obróbki tekstu (edytory, filtry),
możliwość łączenia narzędzi w potoki,
łatwą automatyzację zadań poprzez skrypty powłoki.
To nie był system dla osób, które chcą tylko „kliknąć ikonę i mieć efekt”. To był system dla tych, którzy chcą zrozumieć, co się dzieje, i zbudować własne narzędzia. Ta kultura przetrwała do dziś w różnych formach – od skryptów bash, przez DevOps, po kulturę „infrastructure as code”.
Filozofia UNIX-a: „rób jedną rzecz dobrze” i jej konsekwencje
Małe narzędzia, które można łączyć jak klocki
Jedną z najbardziej znanych zasad projektowania w świecie UNIX-a jest: program powinien robić jedną rzecz i robić ją dobrze. Zamiast budować ogromne, monolityczne aplikacje, twórcy UNIX-a preferowali zestaw małych narzędzi, które można łączyć za pomocą potoków.
Przykład: chcesz znaleźć wszystkie linie zawierające słowo „error” w pliku logu i posortować je alfabetycznie. W stylu uniksowym wykonasz:
grep "error" log.txt | sort | uniq
Trzy proste narzędzia, każde z osobna małe i wyspecjalizowane. Połączone w potokach tworzą nowe, złożone funkcje, bez potrzeby pisania nowego programu od zera.
Jaką masz skłonność w swojej pracy: wolisz jeden „kombajn”, który niby umie wszystko, czy zestaw prostych klocków, z których sam złożysz to, czego potrzebujesz?
„Wszystko jest plikiem” – uniwersalny interfejs
Druga kluczowa idea UNIX-a to koncepcja „wszystko jest plikiem”. W praktyce oznacza to, że wiele typów obiektów reprezentuje się jako pliki lub wpisy w systemie plików:
zwykłe pliki tekstowe i binarne,
katalogi,
urządzenia (np. dyski, terminale),
potoki nazwane i gniazda.
Dzięki temu aplikacje mogą komunikować się ze światem zewnętrznym poprzez te same operacje: otwieranie, czytanie, pisanie, zamykanie. API staje się prostsze, a programy bardziej uniwersalne. Ta decyzja projektowa silnie wpłynęła na całe późniejsze projektowanie API w systemach uniksowych i uniksopodobnych.
Dla programisty oznacza to mniej specjalnych przypadków, a dla administratora – możliwość „przeplatania” narzędzi w elastyczny sposób.
Kontrast wobec monolitycznych aplikacji z PC
W świecie komputerów osobistych, szczególnie na Windows, popularna stała się inna filozofia: aplikacje-kombajny. Program do obróbki tekstu miał wbudowany edytor, moduł mailowy, kreatory szablonów i wiele innych funkcji. Podobnie programy do grafiki, zarządzania projektami czy obróbki wideo.
Zaleta: użytkownik dostawał jedno „pudełko” do większości zadań. Wada: trudność w automatyzacji, słaba możliwość łączenia aplikacji między sobą, duża zależność od jednego dostawcy i formatu danych.
Filozofia UNIX-a, rozprzestrzeniona później przez Linuxa i różne BSD, popychała w innym kierunku: skrypty zamiast klikania, tekstowe formaty danych, możliwość łatwego klejenia narzędzi w nowe rozwiązania. Efekt widać do dziś w kulturze DevOps i SRE.
Shell i skrypty jako naturalne „kleje” systemu
Shell (powłoka) w UNIX-ie to nie tylko „terminal z poleceniami”. To pełnowartościowy język skryptowy. Każdą sekwencję poleceń można zapisać w pliku i uruchomić jak program. W praktyce oznacza to:
łatwą automatyzację zadań administracyjnych,
szybkie prototypowanie rozwiązań,
możliwość budowania własnych narzędzi bez kompilacji.
Administrator, który wczoraj ręcznie przeglądał logi, jutro może mieć skrypt, który:
grepem filtruje istotne wpisy,
sortem je porządkuje,
awk lub sedem wydobywa kluczowe fragmenty,
na końcu wysyła raport mailem.
Jeśli programujesz lub administrujesz systemami – jak często zatrzymujesz się na „ręcznym” wykonaniu zadania, zamiast zamienić je w powtarzalny skrypt?
Źródło: Pexels | Autor: Tima Miroshnichenko
Rozgałęzienie rodziny: od AT&T UNIX do BSD, System V i komercyjnych uniksów
Licencje AT&T i rozprzestrzenianie się kodu źródłowego
UNIX powstał w Bell Labs, które należały do telekomunikacyjnego giganta AT&T. Firma miała ograniczenia prawne – nie mogła swobodnie wchodzić na rynek komputerów. W praktyce UNIX był licencjonowany głównie uczelniom i instytucjom badawczym, z dostępem do kodu źródłowego, ale nie jako darmowe oprogramowanie w dzisiejszym sensie.
Uniwersytety korzystały z tej możliwości w pełni: modyfikowały kod, dodawały własne funkcje, uczyły na nim studentów systemów operacyjnych. Tak zaczęło się rozwarstwienie rodziny UNIX-a na różne „dialekty”.
BSD: akademicki UNIX z Berkeley
Na Uniwersytecie Kalifornijskim w Berkeley powstał projekt BSD (Berkeley Software Distribution). Początkowo był to zestaw rozszerzeń do UNIX-a z Bell Labs, później – w praktyce – osobna linia rozwoju. BSD wprowadził wiele innowacji, które do dziś kojarzą się z internetem i uniksami:
stos TCP/IP – fundament komunikacji sieciowej,
narzędzia sieciowe (telnet, ftp, rsh, później bardziej rozbudowane rozwiązania),
ulepszona powłoka (csh, później tcsh),
nowoczesne mechanizmy zarządzania procesami.
Wiele z tych elementów trafiło potem do innych systemów UNIX i uniksopodobnych, a także do implementacji wykorzystywanych przez routery, switche i serwery sieciowe.
System V: komercyjny porządek i standardyzacja
Równolegle do akademickiej linii BSD rozwijał się UNIX w wersji AT&T – coraz bardziej komercyjny, sprzedawany producentom sprzętu. Kulminacją tej linii był UNIX System V (często skracany do SysV). Stał się on fundamentem wielu późniejszych systemów od dużych vendorów.
System V kładł duży nacisk na stabilność, przewidywalność i zestandaryzowane mechanizmy administracyjne. Pojawiły się m.in.:
klasyczne skrypty startowe /etc/init.d oraz koncepcja runleveli,
interfejsy IPC (kolejki komunikatów, semafory, pamięć współdzielona) w formie „System V IPC”,
bardziej sformalizowane narzędzia administracyjne (print spoolery, narzędzia do backupu, zarządzanie użytkownikami).
Jeśli dziś trafiasz na skrypty w /etc/init.d/ albo widzisz odniesienia do „runlevel 3”, to są to echa decyzji projektowych z czasów System V.
Zadaj sobie pytanie: bliżej ci do świata eksperymentów i „hackowania” (BSD), czy raczej do stabilnego, przewidywalnego środowiska z jasno opisanymi procedurami (SysV)?
Wojny „dialektów” UNIX-a i narodziny standardów POSIX
Coraz więcej firm tworzyło własne warianty UNIX-a: Sun (SunOS, później Solaris), IBM (AIX), HP (HP-UX), Silicon Graphics (IRIX) i inni. Każdy z nich miał:
własne rozszerzenia do jądra,
własne narzędzia administracyjne,
czasem niekompatybilne biblioteki i API.
Dla programistów oznaczało to problem: aplikacja, która działała na jednym uniksie, często wymagała przeróbek, by skompilować się i poprawnie działać na innym. W reakcji pojawiły się próby ujednolicenia interfejsów:
POSIX (Portable Operating System Interface) – standardy definujące API systemowe i zachowanie narzędzi,
Single UNIX Specification – zestaw kryteriów, które system musiał spełnić, by móc używać marki „UNIX” jako zarejestrowanego znaku towarowego.
Gdy dziś kompilujesz program na Linuxie, a potem uruchamiasz go na macOS lub *BSD, w dużej mierze korzystasz z tego, że świat dogadał się co do zestawu wspólnych zachowań API i narzędzi. Bez POSIX-a chaos byłby znacznie większy.
Jeśli projektujesz własne narzędzia – jak dbasz o to, żeby inni mogli je łatwo przenieść i uruchomić w swoim środowisku?
Komercyjne uniksowe serwery: moc, niezawodność i wielkie żelazo
W latach 80. i 90. UNIX stał się podstawą „poważnych” systemów serwerowych. W dużych organizacjach królował tzw. big iron – ciężkie, drogie serwery RISC z dedykowanymi uniksami:
Solaris na maszynach Sun,
AIX na serwerach IBM,
HP-UX na sprzęcie HP.
Te systemy były projektowane z myślą o:
wysokiej dostępności (klastry, hot swap, rozbudowane mechanizmy odzyskiwania po awarii),
możliwości obsługi tysięcy użytkowników,
wydajnych systemach plików i macierzach dyskowych.
Dla wielu administratorów praca na takim uniksie była „sztuką”: znajomość narzędzi diagnostycznych, mechanizmów LVM, RAID, szczegółowych opcji jądra decydowała o tym, czy system utrzyma się pod obciążeniem.
Zastanów się: czy w twojej karierze bardziej potrzebujesz wiedzy o strukturze systemu (jak działa pod spodem), czy raczej o konkretnych narzędziach SaaS nadbudowanych nad infrastrukturą? Od odpowiedzi zależy, na ile „uniksowe korzenie” będą dla ciebie kluczowe.
Jak z tej gałęzi wyrósł świat dzisiejszych „uniksów”
Dzisiejszy krajobraz jest mieszaniną dziedzictwa BSD, System V i komercyjnych rozwiązań:
macOS i iOS opierają się na jądrze XNU z dużą domieszką kodu BSD i standardów POSIX,
nowoczesne dystrybucje Linuxa adaptowały wiele pomysłów zarówno z BSD, jak i z SysV (skrypty init, layout katalogów, narzędzia użytkowe),
wiele routerów, systemów wbudowanych i firewalli wciąż bazuje na *BSD (FreeBSD, OpenBSD, NetBSD).
Nawet jeśli formalnie „UNIX” jako marka dotyczy dziś relatywnie wąskiej grupy systemów certyfikowanych, to w praktyce ogromny fragment infrastruktury IT to systemy uniksopodobne. Filozofia, narzędzia, model pracy – wszystko to wywodzi się z decyzji podjętych dekady temu w Bell Labs i Berkeley.
Jakie systemy ty dziś faktycznie dotykasz: Linux na serwerze, macOS na laptopie, może OpenBSD na firewallu? Zobacz, jak często pod cienką warstwą GUI kryje się znajoma „uniksowa” struktura katalogów, narzędzia w terminalu i ta sama filozofia automatyzacji.
Jak UNIX napędził internet i kulturę inżynierską
UNIX jako naturalna platforma sieciowa
Kiedy w latach 80. i 90. powstawały fundamenty internetu (ARPANET, później TCP/IP), to właśnie systemy uniksowe były naturalnym wyborem dla węzłów sieciowych, serwerów i maszyn badawczych. Główne powody były proste:
BSD miało wysokiej jakości stos TCP/IP,
UNIX dawał bogaty zestaw narzędzi sieciowych,
system był przenośny i dobrze znany w środowisku akademickim.
W praktyce pierwsze serwery DNS, SMTP, FTP czy HTTP często działały właśnie na BSD lub innych uniksach. Narzędzia takie jak sendmail, bind, inetd stały się klasyką administracji systemów.
Zadaj sobie pytanie: jeśli budujesz coś, co ma przetrwać lata – chcesz oprzeć to na zamkniętej, słabo udokumentowanej platformie, czy na systemie, który setki tysięcy inżynierów rozumie od podszewki?
Serwery WWW i pierwsza fala usług internetowych
Gdy pojawił się protokół HTTP i pierwsze przeglądarki, serwerem numer jeden był Apache HTTP Server, rozwijany dla systemów uniksowych. Konfiguracja w plikach tekstowych, modułowa architektura, wysoka stabilność – to dobrze wpisywało się w filozofię UNIX-a.
Typowa ścieżka wyglądała tak: na uczelni ktoś stawiał serwer na BSD, potem przenosił know-how do firmy i tam również wybierał UNIX-a lub później Linuxa. W efekcie:
internetowe usługi backendowe wyrastały głównie na uniksach,
Do dziś większość dużych serwisów działa na Linuxie lub innym uniksopodobnym systemie. Nawet jeśli część elementów jest zamknięta, to fundamenty (kernel, narzędzia, standardowe biblioteki) wciąż mają uniksowe DNA.
Kultura „text-first”: od man-page do README.md
UNIX wprowadził zwyczaj dokumentowania wszystkiego w formie tekstowej – manuale (man), pliki README, CHANGES, skrypty instalacyjne. Dokumentacja była dostępna w terminalu, dało się ją przeszukiwać, filtrować, konwertować.
To podejście przeniosło się później do świata open source: repozytoria kodu z plikami README.md, INSTALL, instrukcjami w plain text lub lekkim markdownie. Łatwo je wersjonować, dystrybuować, generować z nich inne formaty.
Jak ty przechowujesz wiedzę w swoich projektach – w rozproszonych prezentacjach i notatkach, czy w jednym, tekstowym źródle prawdy podpiętym pod repozytorium?
SSH, automatyzacja i praca zdalna zanim to było modne
Zanim zdalna praca stała się codziennością, administratorzy i programiści łączyli się z maszynami uniksowymi za pomocą telnet, potem ssh. Terminal tekstowy był naturalnym interfejsem do serwera. Szczególnie SSH zmieniło zasady gry:
bezpieczne szyfrowane połączenia,
tunelowanie portów,
mechanizmy kluczy publicznych do autoryzacji.
W połączeniu ze skryptami powłoki i narzędziami typu rsync, scp powstał potężny arsenał do automatyzacji. Z jednego laptopa można było zarządzać dziesiątkami, a później setkami serwerów.
Zastanów się: ile twojej codziennej pracy dałoby się zamienić w prosty skrypt, który wykonasz po SSH na wielu maszynach jednocześnie, zamiast żmudnie powtarzać klikane czynności?
Open source i model współpracy wywodzący się z UNIX-a
Wokół UNIX-a narodziła się kultura dzielenia się kodem, łatek i narzędzi. Wiele projektów z lat 80. i 90. było dystrybuowanych w formie źródeł, które użytkownik sam kompilował. Typowy cykl wyglądał tak:
pobierz źródła (często jako tarball),
przeczytaj README oraz INSTALL,
uruchom ./configure && make && make install,
w przypadku problemów – podejrzyj kod, nanieś poprawki, wyślij maila do autora.
To była prosta, ale bardzo efektywna forma współpracy. Z czasem sformalizował ją ruch wolnego oprogramowania (FSF, GNU), a później open source jako model biznesowo-inżynierski. Linux, który pojawi się za chwilę w naszej historii, wyrósł dokładnie na tym gruncie.
Pomyśl: wolisz być tylko konsumentem oprogramowania, czy też czasem sięgnąć do kodu i zrozumieć, jak działa narzędzie, na którym się opierasz?
Styl pracy inżyniera: od „ręcznego” admina do DevOps
UNIX od zawsze zachęcał do myślenia w kategoriach procesów i przepływów danych, a nie pojedynczych kliknięć. Z tego naturalnie wyrosła kultura:
konfiguracji w plikach tekstowych (łatwych do wersjonowania),
skryptów automatyzujących nawet drobiazgi,
dzielenia się małymi narzędziami zamiast monolitów.
Dzisiejszy DevOps w dużej mierze jest kontynuacją tego podejścia: Infrastructure as Code, pipeline’y CI/CD, deklaratywne konfiguracje (Ansible, Terraform, Kubernetes YAML) – to wszystko jest rozszerzeniem starej, uniksowej idei „opisz stan w tekście, daj narzędziom zrobić resztę”.
Jak dziś zarządzasz swoim środowiskiem: ręcznie przez GUI, czy przez powtarzalne, opisane skrypty i konfiguracje? To jest często granica między chaosem a skalowalnością.
Microsoft Windows: droga od nakładki graficznej do dominacji na desktopach
Od DOS-a do pierwszych wersji Windows
Zanim pojawił się Windows, komputery osobiste z logo IBM PC i kompatybilne działały głównie na MS-DOS. Był to prosty, jednoużytkownikowy system bez wielozadaniowości i z bardzo ograniczonym zarządzaniem pamięcią. Interfejs – linia poleceń, brak grafiki.
Microsoft, widząc sukces graficznego interfejsu na Macintosha, zaczął rozwijać Windows jako nakładkę graficzną na DOS-a. Wersje 1.x i 2.x były raczej ciekawostką, ale Windows 3.x zaczął zdobywać popularność dzięki:
obsłudze trybu chronionego procesorów 386,
wielozadaniowości kooperatywnej (ograniczonej, ale istniejącej),
coraz większej liczbie aplikacji graficznych (edytory tekstu, arkusze kalkulacyjne, programy do DTP).
Czy twoje pierwsze zetknięcie z komputerem to był już Windows z ikonami i oknami, czy jeszcze „czarny ekran” DOS-a? To mocno kształtuje późniejsze przyzwyczajenia.
Windows 95: graficzny interfejs dla mas
Prawdziwy przełom na desktopach przyszedł z Windows 95. Ten system, choć wciąż miał wiele wspólnego z DOS-em, wprowadził ważne nowości z punktu widzenia użytkownika:
znany do dziś pasek zadań i menu Start,
zintegrowaną obsługę długich nazw plików,
bardziej zaawansowaną wielozadaniowość,
obsługę plug and play dla sprzętu.
Windows 95 był też mocno wspierany marketingowo, co przy spadających cenach PC sprawiło, że stał się „domyślnym” systemem dla użytkowników domowych i biurowych. Gdy ktoś kupował komputer, przychodził on z zainstalowanym Windowsem – i to właśnie on stawał się mentalnym punktem odniesienia.
Pomyśl: ile razy spotkałeś się z pytaniem „czy to działa na Windowsie?”, a jak rzadko ktoś pyta „czy to działa na UNIX-ie”? Siła domyślnego wyboru jest ogromna.
Windows NT: prawdziwy system wielozadaniowy pod spodem
Najważniejsze wnioski
Przejście od „gołych” maszyn do systemów operacyjnych było koniecznością: bez warstwy pośredniej programista musiał ręcznie obsługiwać pamięć, urządzenia i błędy, co dziś byłoby kompletnie nieefektywne – jak często zastanawiasz się, ile pracy OS zdejmuje ci z barków?
Systemy wsadowe i pierwsze „monitory” rozwiązywały problem przepustowości drogich mainframe’ów, ale kosztem wygody i interakcji – liczyło się „przepchnięcie” jak największej liczby zadań, nie komfort jednego użytkownika.
Systemy z podziałem czasu wprowadziły fundamenty współczesnych OS-ów: procesy, ochronę pamięci, konta użytkowników i planowanie zadań, dzięki czemu wielu użytkowników może korzystać z jednego komputera tak, jakby każdy miał własną maszynę – z jakich mechanizmów bezpieczeństwa realnie korzystasz na co dzień?
System operacyjny stał się warstwą abstrakcji nad sprzętem: udostępnia spójne API, system plików, komunikację między procesami i interfejs (shell lub GUI), dzięki czemu programista skupia się na logice biznesowej zamiast na sterowaniu dyskiem czy drukarką.
UNIX narodził się jako prosty, „domowy” projekt w Bell Labs, projektowany dla programistów, a nie masowego rynku – tekst, skrypty i automatyzacja były ważniejsze niż efektowna grafika; jaką część swojej pracy mógłbyś dziś zautomatyzować podobnym podejściem?
