IT

Linus i Linus, niedługo bedzie jakis collab na youtubie LinusTechTips

#technologia #linustorvalds #linustechtips

https://zaufanatrzeciastrona.pl/post/kiedy-vibe-coding-i-vibe-hosting-wejda-za-mocno-studium-przypadku-z-naszego-podworka/

#informatyka#cyberbezpieczenstwo#zaufanatrzeciastrona

#systemyoperacyjne #linux #oesowo

Sterowniki urządzeń

Długo żem się zbierał do tego wpisu. Jak tu zrobić żeby nie było za nudno albo niezrozumiale, a pewnie i jedno o drugie, no nie da się.

Obsługa jakiegokolwiek urządzenia, czy to wewnątrz czy na zewnątrz kąkutera polega na wysyłaniu określonych w dokumentacji urządzenia komend pod adresy pod którymi te urządzenia nasłuchują. Procesory linii 8086 od Intela miały osobne rozkazy do pisania i czytania z komórek pamięci, a osobne do pisania i czytania z urządzeń. Trudno teraz odkopać faktyczny i oficjalny powód dlaczego Intel tak zrobił. Czyli napisanie czegoś do pamięci (mov) pod adres 0xb00b wypełniało komórkę pamięci, a wysłanie czegoś pod adres IO (out) wysyłało bajty na szynę w nadziei że pod PORTEM (bo adresy IO Intel nazywał portami) o tym adresie słucha jakieś urządzenie.

Szyna ISA o ile dobrze pamiętam była po prostu wystawieniem szyny systemowej. Urządzenia - jakieś soundblastery, sieciówki, modemy itp miały na płytach zworki do konfiguracji. Nie przewidywano, że to system czy bios będą się dogadywać z urządzeniami i ustalać pod jakimi adresami IO będą występować ani jakie numery przerwań trącać. To robił człowiek przed umieszczeniem karty w slocie, a potem musiał pamiętać.

Sound Blaster, na adresie IO 0x220, nr przerwania 7, kanał DMA 1. Chyba tak domyślnie układano zwory i rzadko kto to ruszał chyba że inna karta nie dała się ustawić tak, żeby nie kłóciła się z SB.

DOS umiał obsługiwać szereg urządzeń - kartę graficzną w trybie tekstowym, dyski i system plików FAT, dzięku czemu można było czytać plik c:\file.txt i wystarczyło wywołać ze swojego programu funkcję systemową. DOS z kolei wołał funkcję BIOSa do odczytu sektorów. Jak w wierszyku o rzepce - program do DOSa, DOS do BIOSa, BIOS do dysku. Po drodze w DOSie był jeszcze właśnie "sterownik" FAT umiejący przetłumaczyć żądanie o plik po nazwie na szereg odczytów z sektorów dysku.

DOS jednak nie umiał ani w karty muzyczne ani w sieciówki. W CD ROMa też nie umiał.

Co robili programiści - głównie gier, bo to one napędzały rynek mikrokomputerów IBMopochodnych? DOS całe szczęście był prymitywny aż do końca. Architektura już chyba od 286 pozwalała na rozgraniczenie co może robić program użytkownika a co (wszystko) system operacyjny. DOS miał to w pompie, wszystkim wolno wszystko, niech klawisz Reset ma nas w swojej opiece. I całe szczęście.

Sterowniki do kart muzycznych były częściami programów gier. Program install.exe albo częściej setup.exe pozwalał ustawić, przetestować i zapisać ustawienia karty muzycznej dla danej gry. Potem właściwa gra korzystała ze SWOJEGO sterownika. Biedny Gravis Ultrasound mimo że produktem był świetnym to spóźnił się na pociąg i niewiele gier go wspierało. To był ten minus. Można było mieć GUSa ale w ulubionej gierce być skazanym na pierdzenie z PC speakera.

Opcja druga - tak jak robiły to sieciówki. Chciało się pograć w Dooma z kolegami? Najpierw każdy musiał załadować w odpowiedniej kolejności pakiet sterowników dla swojej karty. lsl.exe, potem właściwy sterownik karty, zwykle nazywający się jak model karty - np ne2000.exe dla kart Novella czy 3c5x9x.exe dla 3COM, a na końcu stos protokołu, w Doomie był to IPX, czyli o ile pamiętam ipxodi.exe. Albo .com zamiast exe. Sterowniki były programami wykonywalnymi ale "kończąc" swoje działanie zamiast uruchamiać w dosie funkcję terminate wołały terminate and stay resident co powodowało że mimo że już formalnie skończyły, DOS po nich nie sprzątał. Ich kod zostawał dostępny w pamięci. I tak stawały się sterownikami, z których mógł skorzystać Doom, bo producenci kart umówili się na wspólny interfejs programowy.

Można by zaryzykować stwierdzenie, że DOS był akurat tak prymitywny, że nie przeszkadzał w niezwykle gwałtownym rozwoju zarówno sprzętu jak i gier. Wobec braku internetu ciągłe aktualizacje systemu były w zasadzie niemożliwe, bardziej elegancki system operacyjny wykorzystujący ochronę pamięci i jądra mógł być poważną przeszkodą dla twórców gier. Ale był DOS - może nie najtaniej ale jako tako.

#systemyoperacyjne #linux #oesowo

MS DOS

No dobra. Dlaczego taguję #linux ? Dla zasięgu. Późno już, mało kto teraz czyta więc będzie odrobinkę o MS DOSie. Miałem napisać o sterownikach do urządzeń właśnie na przykładzie MS DOSa, bo z jednej strony miał jakieś sterowniki ale gwałtowny rozwój sprzętu zostawił DOSa daleko w tyle i producenci gier musieli kręcić niezłe fikołki żeby gry "multimedialne" działały w tym przestarzałym środowisku. Ale o tym w osobnym wpisie.

Bill Gates przez długie lata uważany był powszechnie za demiurga sceny technologii komputerowych. Faktycznie był trochę takim Bogusławem Łęciną IT, w myśl motta - Że co? Że niby ch***wo robię? A dobrze robisz? Nie no, tego nie powiedziałem.

Uniwersalnym systemem operacyjnym dostępnym na rynku przed 1981 był Unix oraz jego odmiana z Berkeley - BSD. Microsoft licencjonował nawet "swojego" Unixa - Xenix, do którego prawa kupił od AT&T (twórców Unixa). Dosłownie za chwilę, bo w 1982 Sun wypuścił SunOS, potem był HP-UX (HP) i AIX (IBM). Skąd więc popularność DOSa, gdy dostępne były dużo lepsze systemy?

Otóż sprzęt od takiego Suna był przeraźliwie drogi. Stacja robocza w 1982 kosztowała w okolicach 8000$, podczas gdy Apple II w okolicach 1000$. Apple miał bardzo prosty system operacyjny z wierszem poleceń i sprzedawał się jak ciepłe bułeczki już od debiutu w 1977r.

IBM przespał tę rewolucję domowych komputerów i ktoś tam podjął bardzo trudną decyzję, że opracowywany na podstawie CPU 8086 od Intela (versus znana z Amigi Motorola 68k obsługująca też Apple) IBM PC AT będzie miał otwartą architekturę sprzętową. Szyna ATA/IDE do dysków twardych, ISA do peryferiów, zewnętrzni producenci będą mogli dostarczać podzespoły bez błogosławieństwa IBMa. Dodatkowo IBM nie ścigał potencjalnych konkurentów robiących klony BIOSu.

BIOS był takim bootloaderem-monitorem. Obsługiwał wyświetlanie, klawiaturę, dyski. Dosłownie- zawierał sterowniki i można było go "wołać" żeby odczytał dane z dysku. Teoretycznie PC AT mógł spokojnie działać jak inne domowe komputery, czyli wystarczyło włożyć dysk z programem, który umiał wywoływać funkcje BIOSu, żeby na przykład uruchomić pełnowartościową grę. I gry na bootowalnych dyskietkach dostępne były jeszcze w latach '90 (PC booter). Żaden system operacyjny nie był potrzebny bo był BIOS.

Bill Gates nawet nie stworzył MS DOSa. Kupił go. Potem dogadał się z IBM i oto MS DOS stał się systemem operacyjnym komputerów PC AT od IBM. Po sklonowaniu BIOSa inni producenci zaczęli produkować klony PC AT i od razu pojawił się Bill oferując w pełni kompatybilny OS. Bill razem z Intelem popchnęli rozwój PC AT z MS DOSem na pokładzie. Pecet okazał się tak niesamowitym sukcesem, że niemal zmiótł z rynku swojego twórcę - IBMa i uczynił Billa najbogatszym człowiekiem na świecie, chociaż jak zerknięcie w publicznie dostępny kod DOSa to zauważycie, że w zasadzie opiera się on na funkcjach zaimplementowanych już w BIOSie od IBMa.

#systemyoperacyjne #linux #oesowo Rezydentny monitor

W poprzednim wpisie wspominałem że podstawową i najstarszą funkcją systemu operacyjnego jest kolejkowanie zadań. Pierwsze poważne komputery używały "interfejsu białkowego" do kolejkowania zadań, czyli jakiś człowiek ładował karty i taśmy do komputera i uruchamiał. Miał też za zadanie nadzorować pracę programu i przerywać jego działanie jeśli wykonanie programu zajmowało zbyt długo.

Przywykliśmy do tego, że na komputerach programy cały czas działają. Czekają na nas, a nie my na nie. Wtedy komputerów używano do obliczeń naukowych i finansowych. Naukowiec chcąc wyliczyć trajektorię lotu rakiety czy zanalizować dane statystyczne musiał odstać swoje w kolejce.

I to zostało wkrótce zautomatyzowane. Tak narodził się bardzo prymitywny system operacyjny, wtedy jeszcze znany jako "program monitora", niemający nic wspólnego z urządzeniem wyświetlającym.

Monitor startował jako pierwszy z jakiejś pamięci nieulotnej. Miał nawet w sobie kawałki kodu które dziś nazwalibyśmy sterownikami. Był w stanie uruchomić konsole robocze, uruchomić napęd taśmy, w końcu uruchomić program. Mógł też obsługiwać wyjątki i błędy, a także ustawić sobie "minutnik" i wyrzucić program który się ociąga ponad przeznaczony mu czas na wywołanie. Po zakończeniu jednego programu ładował kolejny aż do wyczerpania się "wsadu" (batch), czyli np wszystkich programów z taśmy.

Nadal programy wykonują się pojedynczo, nadal jeden po drugim, natomiast coś je już ogarnia, potrafi wysterować sprzęt i radzić sobie z problemami stwarzanymi przez same programy.

Na dołączonym obrazku program monitora z Atari, z powodu nagłówka zwany "self testem". Po zwolnieniu resetu w atarynce uruchamiał się z wewnętrznego ROMu monitor, najpierw próbował czytać kasetę ROM (kartridż) a potem magnetofon. Jak coś poszło nie tak, wyświetlał "self test" jako reakcję na wyjątek systemowy. Miał wbudowany interpreter języka basic i jeśli nie było katridża, kasety i wyjątku systemowego to wyświetlał "READY" czekając na komendy. Crash programu też wracał do monitora, przez co "self test" stał się znienawidzony przez użytkowników, zupełnie niezasłużenie.

Jeszcze ciekawiej wyglądało to na maszynach od Pana Trzmiela, czyli Commodore 64. Tam pamięć ROM zawierająca monitor mieściła w sobie 2 programy. Interpreter basic oraz "kernal", tak, z "e" w środku, czyli właściwy monitor, zwany już wtedy przez niektórych systemem operacyjnym.

Na katridżu do atarynki można było dostać trochę bardziej rozbudowany system operacyjny, on chyba się nawet nazywał DOS, nie mylić z MS DOS. Wtedy program monitora w zasadzie pełnił funkcję bootloadera albo czegoś w stylu BIOSu. Załadować, uruchomić, usunąć się w cień.

#systemyoperacyjne #oesowo Co ma wspólnego widniejący na zdjęciu dalekopis z systemami operacyjnymi? Nie zadawałbym pytania gdyby odpowiedź była inna niż "bardzo wiele". Dalekopis to dość stary wynalazek. Jest to forma telegrafu, tyle że maszynowego. Zamiast sygnałów długich i krótkich jak w alfabecie Morse'a mamy zera i jedynki odpowiadające poziomom napięć na linii. Kodowanie opracował już pod koniec 19 wieku Emile Baudot i składało się z 5 bitów, by w końcu zostać ustandaryzowanym jako ITA-2 (International Telegraph Alphabet). Po jednej stronie przy maszynie do pisania, bo tym z grubsza w zasadzie był dalekopis, siadał nadawca i pisał wiadomość, która jak w przypadku zwykłej maszyny odciskała się na papierze. I ta wiadomość również odciskała się na perforowanej taśmie w postaci właśnie od 0 do 5 dziurek na znak. Następnie wiadomość z taśmy zamieniana była na poziomy napięć na linii zgodnie ze standardem. U odbiorcy wiadomość przychodząca odciskała takie same dziurki na taśmie a maszyna wystukiwała ją na papierze. No dobra, a jakby tak po jednej stronie linii posadzić komputer? Przy okazji alfabet telegraficzny ITA-2 ewoluował w ITA-5 czyli ASCII. Z 5 bitów zrobiło się 7. Koncepcyjnie i elektrycznie dalekopis to nic innego jak łącze szeregowe, jak znany nam z systemów komputerowych UART i RS-232. Nawet prędkość transmisji nadal podajemy przecież w baudach. Łącza dalekopisowe, czy jak potem się zwykło nazywać - telexy - nie były zwykle szeroko dostępne. W końcu pojawiły się modemy telefoniczne pozwalające zrobić telex przez telefon. Czyli stara dobra tepsa 0202122. Ale co to ma wspólnego z systemami operacyjnymi? Otóż od zarania Unixa funkcjonuje w architekturze systemu konstrukcją zwana tty. Sktót od teletype czyli dalekopis. Znajdziemy to również w rozmaitych BSD, MacOSie, Linuxie a przez co też w jego mutacjach typu Android czy OpenWRT. tty określa się czasem jako terminal bądź konsola, co nawiązuje do starych czasów kiedy to terminal (konsola) również wyglądał jak dalekopis. Dzisiaj tty to pseudoterminal, czyli monitor komputera plus jego klawiatura, natomiast urządzenia takie jak modemy (również te GSM czy LTE) pojawiają się jako urządzenia ttyACM. Podobnie z urządzeniami transmisji szeregowej po bluetooth i z adapterami usb2serial. Tty to taka zabawna skamielina która nie potrafi odejść w niepamięć. I mamy jeszcze jedną ciekawostkę, która była zmorą użytkowników wymieniających się plikami między macami, lunuxami a Windowsami. Końce linii. Dalekopis to maszyna do pisania, więc żeby zacząć pisać od nowej linii należy wysunąć linię papieru i cofnąć karetkę (carriage), niekoniecznie w tej kolejności. Windowsy okazały się najbardziej koszerne bo koniec linii w pliku tekstowym to CR LF czyli 'zawróć karetkę', 'wysuń linię'. Mac oryginalnie miał tylko 'zawróć karetkę', a unixy tylko 'wysuń linię'. Do unixów dołączył w końcu mac i tylko Windows nadal chce dodatkowo ganiać tę nieistniejącą już karetkę.

Jako bonus wrzucę ulotkę z lat 90 z osobnym numerem telexowym. Kilka razy dane mi było korzystać z telexu, tyle, że był to już normalny komputer z monitorem, numer wybierało się na ekranie a wiadomość można było pisać na bieżąco albo do pamięci. Dzisiaj mało kto pamięta o dalekopisach i ich związkach z systemami operacyjnymi przede wszystkim z rodziny unixów. tty to po prostu tty, mało kto wnika co się pod tym skrótem kryje. Dzisiaj mówimy po prostu 'wiersz poleceń' albo 'cmd' albo 'shell'.

#systemyoperacyjne Ponieważ interesuję się odrobinę architekturą systemów komputerowych i systemów operacyjnych pozwoliłem sobie otworzyć wątek #oesowo . Spróbuję opowiedzieć jak przez lata dotarliśmy do Linuxa, MacOSa i Windowsów i jak zmieniało się spojrzenie na systemy operacyjne na przestrzeni lat w związku z rozwojem architektur sprzętowych i oczekiwań użytkowników.

Jednym z głównych zadań systemu operacyjnego jest kolejkowanie zadań. Zadania to nic innego jak wykonywane programy i ich dane wejściowe. Przez lata 50 do nawet lat 80 ubiegłego wieku tę funkcję systemu operacyjnego wypełniali często operatorzy, przeważnie kobiety. Początkowo program i dane dostarczano plikami (słowo klucz) kart perforowanych, później w formie taśm perforowanych a potem taśm magnetycznych, aż do dysków magnetycznych. Programy wykonywały się jeden za drugim, w razie błędu (wyjątku) operator ładował kolejny program, a dane wyjściowe trafiały na karty, taśmy lub drukarkę. Kolejka zadań w starych maszynach typu mainframe była faktyczną kolejką, trzeba było swoje odstać.