Linux nie jest darmową kopią Windowsa. Systemy te różnią się nie tylko wizualnie, co widać, nie tylko funkcjonalnie, co się często wspomina i nie tylko prawnie, co podkreśla się na każdym kroku. Różnice między nimi są na tyle fundamentalne, że czasem w ogóle ciężko je porównywać. I jest ich tyle, że można by sporządzić całą długą listę.

Niniejsza tyczy się rozwiązań architektury systemu Windows, które są eufemistycznie mówiąc kłopotliwe, ale żyć z nimi trzeba. (Oj, trzeba.) Przez Windows rozumiem tutaj rodzinę NT/2k/XP/Vista, głównie jednak XP Professional. Wielokrotnie czytałem antymicrosoftowe „spisy” różnych autorów, którzy narzekali na wiersz poleceń (ubogi w Windowsie i bardzo bogaty w Linuksie), problematyczność tak instalacji jak i uaktualnień różnorakiego oprogramowania (tu padało zaraz porównania do Linuksowego apt-get, emerge lub rpm). Pisze się też o złych ustawieniach domyślnych uprawnień użytkownika i administratora i tak dalej, i tak dalej. Są to według mnie niedogodności duże, ba, ogromne, ale nie zmienia to faktu, że coś się z nimi zrobić da – lepiej bądź gorzej. Na przykład w Windows można przecież utworzyć konto zwykłego użytkownika, w Linuksie zaś odblokować sobie konto roota i pracować na nim do woli. Problem z głowy. Podkreślam: można coś z tym zrobić i nie wnikam tutaj, czy ktoś to robi, czy nie. Nie neguję zdania, że domyślna konfiguracja Windows jest „politycznie niepoprawna”. To zestawienie tyczy się jednak rozwiązań architektury, których tknąć ani rusz. Tak z powodu całkowitej niemożności, jak i z powodu „wykolejenia” założeń systemu.

W trakcie komentowania dopuszczam się z premedytacją pewnych, czasem drastycznych uproszczeń. Moim celem jest aby artykuł był zrozumiały dla każdego, kto ma podstawowe informacje o systemach operacyjnych i proszę aby Ci, którzy się na rzeczy znają nie dostawali od razu drgawek i o tym pamiętali.

Strefa Zero, czyli: Kolektywne administrowanie

W systemach operacyjnych występuje jak wiadomo pojęcie użytkownika. Na konto użytkownika można się zalogować i działać na komputerze ile dusza zapragnie. Z jednym „ale”. Pewna grupa funkcji, jest zastrzeżona dla użytkownika zwanego administratorem systemu. To fakt powszechnie znany. Może to być UNIXowy root, może to być NetWareowy supervisor czy jakiś inny admin. Cechą wspólną jest to, iż ten użytkownik to Pan i Władca, będący dla systemu tym, czym Zeus dla starożytnych Greków. Tak – o ile nie mówimy o Oknach Microsoftu, bo tutaj sprawa się komplikuje. Otóż flagowy produkt z Redmond jak niektórym wiadomo (a innym nie), posiada co najmniej dwóch administratorów. Jednym z nich jest użytkownik administrator, drugim użytkownik SYSTEM. Standardowe, wbudowane konto, jak gdyby „agent” z trylogii Matrix Wachowskich. Jeśli popatrzymy na listę procesów w Menadżerze zadań to prawdopodobnie większość z nich będzie własnością użytkownika SYSTEM. Jego własnością są także zbiory techniczne, takie jak np. katalog System Volume Information (SVI). Domyślnie jedynym właścicielem tegoż katalogu jest nasz elektroniczny przyjaciel i aby w ogóle sprawdzić jego zajętość należy dopisać użytkownika administrator do listy akceptowalnych użytkowników. (Można dopisywać również innych ale nie polecam.)

W następnych punktach postaram się krótko wytłumaczyć, że w tym szaleństwie jest metoda i że SYSTEM jest Windowsowi potrzebny dla zapewnienia pełnej funkcjonalności. Teraz jednak krótka refleksja, na temat jego istnienia w ogóle. W informatyce, jak wiadomo każdy problem można rozwiązać na kilka sposobów. Czy wszystkie są jednakowo proste? Zdecydowanie nie. Lepsze są te prostsze, co jest zasadą sprawdzoną życiowo. Jak pisałem na początku, w systemach operacyjnych, co do zasady, istnieje jeden administrator i to jest proste. Fakt istnienia drugiego, w dodatku automatu, może powodować pewne – delikatnie mówiąc – komplikacje. Taki prymitywny przykład: prawie żaden przeciętny użytkownik nie wie jak dostać się do katalogu SVI. Gdybym chciał napisać jakieś paskudztwo, które zbiera informacje o hasłach, projektach i rozkładzie dnia człowieka używającego Windows, to składowałbym te informacje właśnie tam. Przede wszystkim do SVI nikt nie zagląda. Ba, często zdarza się, że użytkownicy są nieświadomi jego istnienia. Po wtóre katalog ten ma wręcz magiczną własność zmiany zajętości miejsca na dysku i to w porywach do kilkuset megabajtów na plus bądź na minus. (Składowane są tam informacje dotyczące „przywracania stanu systemu”.) Idealne miejsce. Co ważniejsze, pisanie wirusa w ogóle jest tym efektywniejsze, jeśli uda się zainfekować pliki wykonywalne użytkownika o dużych uprawnieniach. No więc znów pada na użytkownika SYSTEM. Sam SYSTEM przecież nie zaprotestuje, bo to nie sztuczna inteligencja.

Analizując architekturę Okien zdawałoby się, że wprowadzenie tego „agenta” było niezbędnie konieczne… Czy na pewno? O tym za chwilę.

I Życie jest iluzją

…czyli start systemu.

Zróbmy głosowanie, który z systemów: Windows czy Linux uruchamia się szybciej. Jak znam życie większość zagłosuje za Windowsem. I to jest dowód dla tezy, że z demokracją trzeba ostrożnie. Proponuję przeprowadzić doświadczenie. Zmierzmy stoperem czasy ładowania obu systemów, przy czym proponuję zacząć od Windowsa – włączamy komputer, obserwujemy komunikaty POST lub obrazek producenta (jak kto lubi) i dochodzimy do chwili gdy na ekranie pojawia się manager ładowania systemów (GRUB, LILO, etc.) lub system zaczyna się po prostu ładować. Uruchamiamy stoper. Teraz nuda. I nuda. Nuda – system coś tam mieli, a my siedzimy i ziewamy. Jeszcze moment i pojawia się okienko logowania. No i błąd! Większość użytkowników właśnie wyłączyłaby stoper… a ładowanie trwa nadal. Podajemy hasło i obserwujemy jak uruchamia się środowisko graficzne. Przepraszam. Środowisko graficzne i system. Windows kończy ładowanie – w zależności od konfiguracji – kilkanaście do kilkudziesięciu sekund po zalogowaniu użytkownika.

Rys.1 Ładowanie Linuksa (źródło: Bootchart.org)

Aby przeanalizować powody dla których tak a nie inaczej rozwiązano tę sprawę należy zacząć od podstaw, czyli przyjrzeć się bliżej pojęciu kernela systemu. Śmieszna sprawa – wszyscy posługujemy się pojęciem System Operacyjny a tak dokładnie to nie wiadomo co to jest. Jeśli nie da się czegoś ściśle zdefiniować można podać katalog cech opisujących dane pojęcie. Jednakże specjaliści od systemów operacyjnych nie są zgodni nawet co do tego. Niby w większości cechy się pokrywają ale zawsze jest jakieś „ale”. Nawet biblia systemów operacyjnych – książka Silberschatza (por. A. Silberschatz, P. Galvin „Podstawy Systemów Operacyjnych”) podaje dwie definicje. Ogólnie, najczęściej, przyjmuje się, że system operacyjny jest to jeden program, który działa w komputerze nieustannie od momentu uruchomienia systemu aż do jego wyłączenia (bądź restartu). Wszystkie inne programy są programami użytkowymi. Jak pisze Silberschatz: „System operacyjny jest podobny do rządu. Dostarcza środków do właściwego użycia zasobów komputera. I podobnie jak rząd nie wykonuje sam żadnej użytecznej funkcji. Po prostu tworzy środowisko, w którym inne programy mogą wykonywać użyteczne funkcje.” W tym ujęciu system operacyjny, to pojęcie jednoznaczne z kernelem. Inaczej mówiąc, można postawić znak równości pomiędzy słowem kernel a technicznym pojęciem systemu operacyjnego. Powszechnie jednak określenia „System Operacyjny” używa się dla wszystkich programów dostarczanych przez producenta w odpowiedzi na zamówienie na środowisko pracy. Stąd też przyjęło się mówić Linux na całość systemu, choć nazwa ta oznacza w istocie sam kernel. Ja kiedy piszę o kernelu używam pełnej nazwy – system operacyjny, natomiast całość oprogramowania określam krótko jako system.

Teraz zaczynają się schody. Zadania stawiane kernelowi są sformułowane bardzo nieprecyzyjnie. Nie wiadomo, czy zarządzanie oznacza tylko blokowanie bądź zezwalanie na korzystanie z zasobów (na przykład karty sieciowej), czy też ma dostarczyć program (choćby szczątkowy) ich obsługi. W praktyce nie jest to takie proste, gdyż aby jakimś zasobem w pełni zarządzać trzeba określić jego specyfikę. Innymi słowy – problem sprowadza się tu do pytania: Czy kernel ma być programem zawierającym w sobie podstawowe – kompletne rozwiązania, czy też może jego rola sprowadza się jedynie do administracji, całą resztę zaś rozwiązują wywoływane w razie potrzeby programy użytkowe. W pierwszym przypadku dostajemy duży program, który nazywany jest kernelem monolitycznym. W drugim mamy do czynienia z małym, szybkim, jednak jakby „niepełnowartościowym” mikrokernelem. Przykładem kernela monolitycznego jest Linux, natomiast mikrokernela Mach stosowany między innymi w systemach Mac OS X czy GNU/Hurd.

Jeszcze jedna ważna sprawa. System operacyjny, a właściwie każdy porządny program, swoją budową przypomina tort. W torcie jak wiadomo na spodzie mamy biszkopcik, potem leci masa, następny krążek ciasta, niech będzie powiedzmy – kawowy, jeszcze jedna warstwa masy i na wierzch galaretka. W programowaniu także używa się takich warstw i nazywa się je poziomami abstrakcji. I tak, jak w torcie mamy poziom biszkopta (który „leży na sprzęcie – czyli na stole”), tak w systemach operacyjnych mamy kernel (który zarządza sprzętem i bez którego wszystko się „zawali”). Dopiero „na” kernelu buduje się inne warstwy. Na przykład serwer X, na nim odpowiednio środowisko graficzne (np. KDE), na nim program zarządzający oknami (np. kWin) a na samym „wierzchu” działa przeglądarka Firefox, która wyświetla stronę. Ważne jest aby każdy z poziomów komunikował się tylko z bezpośrednimi sąsiadami. Jeśli galaretka spływa na stół, jest to wyraźny znak, że czas zmienić kucharza.

Rys.2 Architektura systemu operacyjnego (źródło: Wikimedia Commons)

Pamiętając o tym piętrowym modelu, wróćmy do ładowania Windowsa. Przede wszystkim należy zaznaczyć, że kernel systemu Windows jest zbliżony architektonicznie do mikrokernela. (Dokładnie jest tak zwanym kernelem hybrydowym – jest to coś pomiędzy kernelem monolitycznym a mikrokernelem. Tak czy siak – do działania potrzebuje wielu „pomocników”). Po prawidłowym starcie komputera najpierw ładowany jest oczywiście sam kernel (ntoskrnl.exe). Następnie jego „najlepszy przyjaciel”, czyli moduł HAL – Warstwa Abstrakcji Sprzętu, który „organizuje” sterowniki urządzeń potrzebnych do załadowania systemu. W tak przygotowanym środowisku uruchamiany jest Manager Sesji (smss.exe – Session Manager Subsystem), do którego zadań należy uruchomienie podprogramów identyfikacji i autentykacji czyli po ludzku mówiąc – wyświetlenie ekranu logowania. Użytkownik zadowolony, że Windows „jest gotowy” może podać hasło, po czym system ładuje uprawnienia (Group Policy) i uruchamia zadania określone we wszystkich kluczach Runonce i Run rejestru (np. HKLM\SOFTWARE\Microsoft\CurrentVersion\Runonce). Na zakończenie ładowane są aplikacje Autostartu z Menu Start.

Linux prezentuje odmienny sposób podejścia do problemu. Po załadowaniu monolitycznego kernela, rozpoczyna się proces init, który dzieląc samego siebie powołuje do życia inne procesy. (Proponuję użyć w konsoli polecenie pstree.) Podczas startu powoływane do życia są praktycznie wszystkie procesy systemu i kiedy użytkownik widzi ekran logowania, pozostaje jedynie obsłużyć ładowanie środowiska KDE czy GNOME, wszystko inne jest bowiem gotowe. (Drużyna Ubuntu pracuje obecnie nad zastąpieniem procesu init procesem upstart. Nie wpływa to jednak na ogólne rozumowanie.)

Pytanie, które rozwiązanie jest lepsze, pozostaje tak naprawdę bez odpowiedzi. Jednakże… taka krótka uwaga na koniec. Microsoft notorycznie stosuje tego typu sztuczki. Psychologia uczy, że najbardziej frustrująca dla człowieka jest niemożność podjęcia działania i brak wpływu na sytuację, dlatego przesunięcie logowania niejako na środek sekwencji startu systemu, daje operatorowi komputera komfort psychiczny i jest lepiej odbierane. Mimo, że nawet kiedy na monitorze ukaże się słynny pasek zadań i ikony, nie da się jeszcze załadować złożonego arkusza kalkulacyjnego czy gry. Większość użytkowników jest świadoma, że musi jeszcze chwilę poczekać. Jest to rozwiązanie lepsze marketingowo, ale czasem odbija się na stabilności i bezpieczeństwie systemu.

Biorąc pod uwagę całą sekwencję startu – z reguły Linux nie ładuje się wolniej niż Windows. Podstawy systemów operacyjnych a co za tym idzie tego, co maszyna musi policzyć są znane od kilkudziesięciu lat. Cudów nie ma.

II Gdzie się podziała ochrona?

Rys.3 OS jako tort
(źródło: Wikimedia Commons)

Dlaczego panuje opinia, że Linux jest systemem bezpieczniejszym od Windows. Może dlatego, że to prawda. Tylko dlaczego? Wróćmy na chwilę do poprzedniego punktu. Jak napisałem system komputerowy przypomina tort. Na spodzie znajduje się kernel a na wierzchu aplikacje użytkownika. Zgodnie ze „schematem tortu” Kernel wraz z bezpośrednimi programami pomocniczymi tworzy tak zwaną warstwę kernela. Reszta zadań tworzy tak zwaną warstwę użytkownika. Czyli warstwa kernela tworzy środowisko, w którym działa warstwa użytkownika. System jest podzielony jakby na dwie części: dół i górę.

O Linuksie, Machu (kernel Mac OS X), Solarisie czy BSD, upraszczając sprawę, wystarczy napisać krótko. Ochrona działa w warstwie kernela. W zasadzie w kernelu. W systemie Mach poza elementami, które zawiera sam kernel, istnieją dodatkowe moduły bezpieczeństwa lecz działają w warstwie kernela jako jego programy pomocnicze. Ochrona w UNIXach działa zawsze i ciągle, ponad to jest prosta, w sensie koncepcji i przez to statystycznie trudniejsza do złamania.

W Windows jest to o wiele bardziej złożone i duża część modułów ochrony działa w warstwie użytkownika. Logika jest taka. Sam system operacyjny jest ślepy i głuchy. Tworzy środowisko. Programy, które mogą nawiązać kontakt z otoczeniem, są uruchamiane w warstwie użytkownika więc ochrona, która również działa w warstwie użytkownika będzie skuteczna. Na papierze jest to prawda, ale w życiu jest oczywiście mniej różowo. Przede wszystkim program działający w warstwie użytkownika – a ochrona to także program – jest na prawdę o wiele prościej „rozbroić”, niż ochronę działającą w warstwie kernela. Po drugie, częścią powszechnie rozumianej ochrony komputera jest na przykład zapora sieciowa – firewall. Ponieważ firewalle windowsowe działają w warstwie użytkownika, przy projektowaniu takiej ochrony trzeba uważać, żeby przez pomyłkę nie powstała sytuacja, że podczas startu systemu w ogóle nam ona nie zadziała. W końcu to program, a program w przeciwieństwie do kernela działać nie musi. I tutaj dygresja. Wcześniej pisałem o użytkowniku SYSTEM. Otóż użytkownik ów jest Windowsowi potrzebny między innymi do uruchomienia niektórych programów umieszczonych w warstwie użytkownika. No, w końcu nie można czekać z „odpaleniem” firewalla, dopóki jakiś Kowalski się zaloguje (po kilku godzinach pracy komputera), używa się więc użytkownika systemowego. A wystarczyłoby, jak w systemie Mach, umieścić ochronę w warstwie niższej i problem z głowy.

III Problemy z mapowaniem

Jest taka sytuacja. Pracuję na koncie zwykłego użytkownika w Windows. Jako zwykły użytkownik mam podłączone – inaczej mówiąc zmapowane, dyski sieciowe z dwóch serwerów. Na komputerze pracuje kilka programów (lokalnych, oraz z jednego i drugiego serwera), które korzystają z kilkunastu plików (także z obu serwerów). W pewnym momencie chcę skorzystać z pliku, którego właścicielem jest administrator serwera (czyli akurat ja). O bogowie! Jak ja bym wtedy chciał pracować na jakimkolwiek Uniksie! Próba podłączenia zasobów administratora w takiej sytuacji kończy się komunikatem „Wielokrotne połączenia z serwerem lub udostępnionym zasobem przez tego samego użytkownika przy użyciu więcej niż jednej nazwy użytkownika są niedozwolone. Rozłącz wszystkie poprzednie połączenia z serwerem lub udostępnionym zasobem i spróbuj ponownie.” Rewelacja!

Gdybym pracował np. W Linuksie albo w OS X mógłbym bez problemu, używając miłego, prostego programu smbmount zamontować potrzebny zasób i skorzystać z pliku. Program ten traktuje połączenia indywidualnie i nie „obchodzi” go, że jakaś inna jego kopia podłączała mi przed chwilą zasób na prawach innego użytkownika. Jest to kolejna konsekwencja wprowadzenia tak złożonej koncepcyjnie warstwy użytkownika, o czym pisałem wcześniej. Skomentować to można tylko w jeden sposób: kolejny dowód na przewagę prostoty nad złożonością.

jeśli będzie zainteresowanie… ciąg dalszy nastąpi… za jakiś czas…

Co autor miał na myśli

Intencją autora nie jest wywoływane kolejnej wojny między linuksiarzami i windziarzami. Autor prosi i jednych, i drugich o daleko posuniętą wstrzemięźliwość. Jeśli komukolwiek przyjdzie ochota na komentarze niech napisze, że artykuł jest do bani, bądź nie, czy też, że pewne punkty wymagają poszerzenia. Nie chodzi tu jednak o wykazywanie wyższości jednego systemu nad drugim. Jest to sprawa subiektywna i o ile mogę napisać, że ja uważam architekturę Windowsa za gorszą nie oznacza to, że jest gorsza. Jest różna. Napisanie systemu operacyjnego w ogóle jest sprawą niezwykle skomplikowaną i zazwyczaj wybrane rozwiązanie jest tak zwanym wyborem mniejszego zła. O Linuksie można napisać podobną „listę”, a przede wszystkim nie przekłada się to na fakt działania bądź nie działania Photoshopa na każdym z systemów.