…ciąg dalszy nastąpił.
W poprzedniej części Windows vs Linux: porównanie architektury po zwyczajowym, wstępnym, przynudnawym zagajeniu zostały omówione problemy z administratorami Windows, architekturą kernela, problematyką zabezpieczeń systemu oraz trybami kernela i użytkownika. Zapraszam na ciąg dalszy.

Jeśli dobrze liczę czas na punkt piąty, czyli:

Dokumentacja czyli Vendor Lock-In po raz pierwszy

Wszyscy zwolennicy wolnego oprogramowania opiewają zalety otwartości kodu. Że można go modyfikować, analizować i w ogóle, co tam komu przyjdzie do głowy. Mnie natomiast w Otwartych Systemach najbardziej podoba się otwartość dokumentacji. Sam Linux bywa wkurzający. No, nie czarujmy się. Psuje się – jak to każdy złożony program. Czasem zachowuje się dziwnie i zupełnie nie tak jak tego oczekujemy. Wypadki i wpadki na Linuksie zdarzają się tak, jak w środowisku Windows. Dlaczego? Ponieważ najbardziej zawodny jest czynnik ludzki. Dużo zależy od administratora a ten może rozłożyć na łopatki najstabilniejszy system uniksowy i prowadzić stabilnie Windows Server 2003.

Cóż – popsuliśmy, bądź nie zabezpieczyliśmy systemu i ktoś nam go unieruchomił a teraz trzeba naprawiać. Sięgamy więc do dokumentacji. W Linuksie, FreeBSD, Mac OS X (Darwin), czy innych systemach uniksowych z reguły nie ma problemu. Po dłuższym (częściej) bądź krótszym (rzadziej) czasie znajdujemy stronę z dokumentacją i po kilku (rzadziej) czy kilkunastu (częściej) próbach, wielu konsultacjach z różnorakimi guru, z reguły usuwamy błąd. W Windows jest trochę inaczej. Dokumentacja to niby jest, ale jej w sumie nie ma. Dział obsługi klienta niby jest, ale tak jakby go nie było. Inni użytkownicy pytani o radę też najczęściej wzruszają rękami. Pozostaje strona Microsoftu… Aby nie przedłużać, chętnie posłucham / poczytam o doświadczeniach towarzyszących próbom znalezienia na niej czegokolwiek sensownego. Patrząc więc przez pryzmat czasu, pozostaje sprawdzona metoda naprawy – zainstalować system od nowa. Zainstalowany system trzeba by skonfigurować. I tu problem wraca jak bumerang. Wiem, że możliwości konfiguracyjne Windows są tak naprawdę ogromne. Posiadając wiedzę na temat specjalistycznych ustawień rejestru można zdziałać cuda, tylko trzeba – drobny szczegół – tę wiedzę mieć. W Windowsowym „helpie” nic na ten temat nie wyczytamy a i treściwą książkę trudno znaleźć gdyż większość traktuje o jakże ważkim problemie zmiany domyślnej tapety i domyślnych dźwięków systemu. To samo można by napisać o informacjach dla programistów, ale nie to jest najgorsze…

Załóżmy, że kupujemy OEM-ową wersję Worda i piszemy książkę. („Wiedźmina” jakiegoś albo innego „Wołodyjowskiego”.) W „docu”. Potem kupujemy nowy komputer tyle, że bez Worda, bo instalujemy OpenOffice. I tu niespodzianka, bo nasz plik – nad którym przesiedzieliśmy kilkaset godzin – „milczy”. Plik jest efektem naszej pracy, ale nie skorzystamy z niego, bo nie wiedzieć czemu otwiera się tylko w Wordzie a Microsoft nie udostępnia specyfikacji do formatu plików tego procesora tekstu. (Pisząc to mam na myśli konkretną sytuację, jaka spotkała kiedyś mojego znajomego. Charakter jego pracy nie był niestety beletrystyczny i aby przeczytać stworzoną przez siebie dokumentację, był zmuszony przejechać o drugiej w nocy, około 70 kilometrów.) Większość osób podkreśla, iż należy używać OpenOffice dlatego, że jest to wolny, darmowy i wystarczający w większości przypadków pakiet biurowy. Błąd. Należy go używać, bo nawet za sto lat będzie wiadomo jaki jest format pliku zapisanego w jego podstawowym, formacie i jakimi algorytmami ten plik został zapisany. Potencjalnych oponentów odsyłam do niedawnego komunikatu Brytyjskiego Archiwum Narodowego.

Oczywiście dokumentacja nie jest to część architektury w ścisłym tego słowa znaczeniu. Stanowi jednak integralną część produktu zwanego oprogramowaniem i dlatego nie sposób o niej nie wspomnieć, porównując konkretne systemy operacyjne. Zaryzykuję także tezę, że częstokroć lepszy jest kiepski funkcjonalnie ale udokumentowany program, niż kompleksowe rozwiązanie bez żadnego opisu. A w Windows uczciwa dokumentacja by się czasami przydała. Weźmy na przykład…

Rejestr Systemu… (a kiedyś było tak pięknie…)

No tutaj to po prostu ręce opadają. Nie wiem kto wpadł na pomysł umieszczenia niemal wszystkich danych konfiguracyjnych systemu i zainstalowanych aplikacji w jednej bazie. Należałoby przejrzeć wnioski patentowe – być może ta sama osoba zastrzegła kwadratowe koło, czy na przykład wodę w proszku. Rewelacyjny pomysł. Umieszczamy wszystkie dane w jednym miejscu, potem jakaś awaria i niespodzianka – przez jeden błąd na zbiorze danych, trzeba przeinstalować cały system. Często dałoby się go nawet naprawić, gdyby był rzetelnie udokumentowany i trochę prostszy. No właśnie – prostszy…

Przyjrzyjmy się temu wynalazkowi trochę bliżej. Rejestr Windowsa 2000 / XP / Visty umieszczony jest w katalogu C:\Windows\System32\Config (O ile oczywiście C:\Windows jest lokacją systemu.) Tworzą go pliki:

• Sam – HKEY_LOCAL_MACHINE\SAM,
• Security – HKEY_LOCAL_MACHINE\SECURITY,
• Software – HKEY_LOCAL_MACHINE\SOFTWARE,
• System – HKEY_LOCAL_MACHINE\SYSTEM,
• Default – HKEY_USERS\.DEFAULT,
• Userdiff.

Dodatkowo w każdym katalogu domowym użytkownika znajdują się:

• Ntuser.dat – HKEY_USERS\ (HKEY_CURRENT_USER),
• Ustawienia lokalne\Dane aplikacji\Microsoft\Windows\Usrclass.dat – HKEY_USERS\_Classes (HKEY_CURRENT_USER\Software\Classes).

Na „dzień dobry” konfiguracja systemu jest zapisana w pierwszych pięciu plikach. Stanowią one bazę danych konfiguracji systemu. Po zalogowaniu, dokładane są dane zawarte w plikach z katalogu domowego konkretnego użytkownika. Zwracam uwagę na fakt, iż baza ta nie jest najczęściej przychodzącą na myśl bazą relacyjną a tak zwaną bazą hierarchiczną. Głównymi gałęziami owej bazy są:

• HKEY_CLASSES_ROOT,
• HKEY_CURRENT_USER,
• HKEY_LOCAL_MACHINE,
• HKEY_USERS,
• HKEY_CURRENT_CONFIG.

Zauważmy również, że poszczególne gałęzie i klucze rejestru posiadają własny system uprawnień dostępu. Najgorsze jednak, że sam rejestr nie załatwia sprawy konfiguracji. Dochodzą jeszcze pliki konfiguracyjne poszczególnych aplikacji i samego systemu zapisane w plikach ini, niekiedy xml oraz innych formatach. (np. system.ini, win.ini…) W sumie proste – prawda?

Żeby było jasne – ja nie twierdzę, że Windows to zły system. Wspomniałem o tym zresztą tworząc komentarz do poprzedniej części artykułu, ale rejestr oceniam zdecydowanie negatywnie. Nie znajduje bowiem ani jednego argumentu przemawiającego za jego istnieniem. Argumentów przeciw jest natomiast co najmniej kilka. Zanim wymienię parę dla przykładu, przypomnijmy jak konfigurację rozwiązano w systemach rodziny UNIX: Pliki konfiguracyjne zebrane są w jednym miejscu czyli w katalogu /etc. Mamy więc porządek i oczywiście możliwość nadawania uprawnień. Ponieważ, co do zasady, są to pliki tekstowe – są one udokumentowane tak poprzez samą strukturę pliku jak i możliwość tworzenia czytelnych komentarzy. Awaria jednego pliku nie powoduje końca świata. Nawet jeśli system nie chce się uruchomić, da się jakoś do katalogu /etc dostać, wprowadzić potrzebne poprawki i wybrnąć z sytuacji, często nawet gdy nie posiadamy aktualnej kopii uszkodzonego zbioru. Generalnie, może nie ma aż takiej sielanki, ale jest o wiele prościej niż w Windows. W Windows bowiem:

1. Jak wspomniałem wyżej, awaria pojedynczego pliku rejestru z katalogu config „wycina” nam całą konfigurację systemu. To tak na początek.
2. Można oczywiście robić sobie kopię owej bazy (ręka w górę kto takową kopię robi), ale proszę zauważyć, że w sumie, w razie awarii, mamy jedynie możliwość podmiany całego Rejestru. Niezwykle trudno jest bowiem wyekstrahować z kopii potrzebną gałąź, czy klucz i ją podmienić. (Choć nie jest to niemożliwe, wymaga jedynie biegłej znajomości obsługi kilku narzędzi, w tym obsługi edytora rejestru z linii komend. Bez specjalistycznego edytora – ani rusz. Mamy do czynienia z tworem binarnym.)
3. O dokumentacji Okien wspominałem w poprzednim punkcie, ale przypominam i w tym miejscu. Konia z rzędem temu, kto w pełni rozumie konfiguracyjne wpisy Windowsa w rejestrze. Absolutnym guru jest zaś ten kto potrafi swobodnie zmieniać ustawienia systemu dodając nieistniejące domyślnie wpisy.
4. Awaria systemu pociąga za sobą awarię niemal wszystkich aplikacji. Gdyby tak pliki konfiguracyjne dla każdego programu trzymać osobno, pracy przy reinstalacji Okien nie byłoby aż tak dużo.
5. Na pierwszy rzut oka jednolita, spójna, binarna baza winna dawać nam szybkość działania. Czy tak jest w istocie? Rejestr Windowsa, na którym najczęściej pracuję, zajmuje ponad 50 MB, katalog /etc Linuksa na którym najczęściej pracuję i który – co podkreślam – zapewnia mi zbliżoną funkcjonalność zajmuje 30 MB. Zgoda, zgoda – ciężko to porównywać a dywagacje na temat wyższości przeszukiwania drzewa plików nad przeszukiwaniem drzewa bazy danych zapełniłyby spokojnie osobny artykuł, ale ja jak zwykle skłaniam się ku konkluzji iż cudów nie ma. Przeszukiwanie owej Windowsowej bazy na pewno nie jest szybsze a już na pewno nie oszczędza zasobów komputera. Obserwuję to już od wielu lat.

Ciekawe, że w Windows na początku nie było żadnego rejestru. System konfigurowało się w plikach ini umieszczonych z reguły w jego katalogu głównym. No ale teraz działa szybciej i lepiej… Tak jak…

Aplikacje Użytkowe, czyli Vendor Lock-In po raz drugi

Moja Pani-Od-Fizyki z ogólniaka (Uuuu! – Powiało grozą.) mawiała, że jeśli chodzi o (tu wstawić losowy temat), to wszyscy mamy wiadomości ale nikt z nas „tego nie czuje”. Aby coś „poczuć”, jak mawiała owa wytrawna pedagog, trzeba to przeżyć. (Czemu więc nie robiliśmy doświadczeń a tylko klepaliśmy teorię?) Proponuję więc prymitywne doświadczenie. Do doświadczenia potrzebny nam jeden komputer z Windows XP Professional (choć może być i 2000… byle nie Vista) z Internet Explorerem w wersji 6 (najlepiej aby była to jedyna przeglądarka systemu), prawa administratora na tym komputerze oraz jakieś 10 minut czasu. Zatem do dzieła. Aaa… Najważniejsze: Autor nie ponosi konsekwencji za skutki wynikłe z doświadczenia. Każdy wykonuje je na własne ryzyko.

Po pierwsze: Logujemy się na konto użytkownika z prawami administratora (może być po prostu administrator).

Po drugie: Na komputerze tworzymy konto zwykłego użytkownika. Ja nazwę go Bill (na cześć Williama Henryego III). Konto takie nazywa się w Windowsie „konto z ograniczeniami”.

Po trzecie: Wylogowujemy się z konta administracyjnego i logujemy na koncie Bill. W tym momencie tworzony jest podkatalog domowy użytkownika w katalogu Documents and Settings (chyba że określono inaczej), wraz z plikami konfiguracyjnymi. Dodatkowo, dobrze jest ustawić użycie „klasycznych folderów” w „Opcjach folderów”, w „Panelu sterowania”.

Po czwarte: Wylogowujemy się z konta Bill i na powrót logujemy na konto administracyjne. Na dysku systemowym (zwyczajowo C:) odnajdujemy katalog „Program Files” a następnie „Internet Explorer”. W katalogu owym znajduje się program iexplore.exe czyli słynne „Niebieskie E” we własnej osobie.

Po piąte: Klikamy prawym klawiszem myszki na ów plik i wybieramy zakładkę „Zabezpieczenia”. U góry znajdują się „Nazwy grupy lub użytkownika” do których poprzez wybranie przycisku „Dodaj…” – dodajemy naszego testowego użytkownika Bill. Klikamy „na niego” i w dolnej części zakładki zaznaczamy wszystkie flagi w kolumnie „Odmów”. Dokładnie – wystarczy zaznaczyć odmów na fladze Pełna kontrola a pozostałe zaznaczą się automatycznie. Windows wyświetli komunikat: „Ustawiasz wpis odmawiania uprawnień. Wpisy odmawiania mają priorytet nad wpisami zezwalania. Oznacza to, że jeśli użytkownik jest członkiem dwóch grup, z których jednej zezwolono, a drugiej odmówiono tego samego uprawnienia, to dane uprawnienie zostanie użytkownikowi odmówione. Czy chcesz kontynuować?” Wybieramy tak. Uwaga – w żadnym wypadku nie należy manipulować uprawnieniami dla użytkowników z grup administracyjnych, zwłaszcza administrator i SYSTEM. Grozi to zablokowaniem systemu. Choć niekoniecznie. I niekoniecznie od razu.

Po szóste: Logujemy się na konto Bill. Klikając dwukrotnie na „Niebieskie E” otrzymujemy komunikat: „Odmowa”. Czyli, że możliwość użycia programu Internet Explorer dla dla użytkownika Bill jest zablokowana.

Po siódme: Klikamy dwukrotnie na „Mój komputer”. W pasku adresu w otwartym w ten sposób oknie (tam gdzie jest napisane „Mój komputer”) robimy sobie miejsce usuwając bieżący wpis i piszemy „http://jakilinux.org/”. Naciskamy enter. I jeśli wszystko poszło jak należy, możemy poczytać najnowsze Newsy. (Na niektórych komputerach może to nie zadziałać od razu i trzeba będzie coś jeszcze skonfigurować.)

Po ósme: Teraz najciekawsze. Każdy program Windowsowy posiada na końcu menu Pomoc. W Pomocy owej na samym dole znajduję się opcja „Cośtam-informacje”. Po wybraniu tej opcji w naszym okienku widzimy „Microsoft Internet Explorer. Wersja: 6. i tak dalej, i tak dalej”. No to w końcu mamy uprawnienia do Internet Explorera – czy nie? Ciekawe jest, że opcja „otwórz w nowym oknie” wybrana na losowym linku nie działa. Niby nie da się uruchomić Internet Explorera, chociaż de facto właśnie z niego korzystamy.

Pierwsze spostrzeżenie „na gorąco”, to fakt, iż pojęcie przeglądarki internetowej dość mocno się nam dewaluuje. Nie zapominajmy jednak, że w zasadzie każdy złożony program nie jest monolitem – składa się z modułów. W poprzedniej części artykułu pisałem o poziomach abstrakcji oprogramowania. To co tyczyło się systemu jako całości, aktualne jest także jeśli chodzi o każdy dobrze napisany program. Przeglądarka internetowa, nieważne czy chodzi o „Niebieskie E”, Mozillę Firefox, Safari czy Operę, składa się z owych wspomnianych wcześniej poziomów – warstw logicznych. Wiemy, że za składanie strony odpowiedzialny jest tak zwany silnik renderujący. Dla wymienionych wyżej przeglądarek są to odpowiednio: Trident, Gecko, Apple WebCore (por. KHTML) i Presto. Do wyświetlenia strony potrzeba nie tyle całej przeglądarki – „Niebieskiego E” co kilku komponentów, takich jak na przykład wspomniany silnik. Gdyby udało się zabronić dostępu do silnika IE – na przykład poprzez prymitywne zablokowanie biblioteki mshtml.dll – strona się nie wyświetli. (Tylko proszę tego nie próbować!) Sęk w tym, że w Windowsie jego rola nie ogranicza się jedynie do obsługi „Internetu” – jego działanie warunkuje funkcjonowanie całego interfejsu graficznego. Teraz jeszcze trzy refleksje wynikające z „doświadczenia”:

Po pierwsze – zostawmy na razie w spokoju Internet Explorer i zastanówmy się nad dość powszechnie powtarzanym zdaniem, iż „wolne oprogramowanie rzeczywiście jest wolne”. Znaczy to zazwyczaj, że wolno się uruchamia. Upraszczając sprawę, można powiedzieć, że oprogramowanie rodem z Redmond uruchamia się szybciej, gdyż w momencie kliknięcia na ikonkę programu już jest w jakimś stopniu „uruchomione”. Wspomniana przeglądarka, MS Office, Outlook Express mają fory już na samym starcie. Niekoniecznie oznacza to, że cały program jest domyślnie ładowany bez wiedzy użytkownika. Owo „uruchomienie” przed „uruchomieniem właściwym” jest w pewnym sensie przenośnią, może tu bowiem chodzić po prostu o to, że program korzysta ze wspólnych komponentów, bibliotek dynamicznych czy na przykład silnika Trident. Ponieważ…

Po drugie – Projektując program trzeba sobie na początku odpowiedzieć na jedno bardzo ważne pytanie: Czy piszemy program na określoną platformę (na przykład Windows) czy też można go będzie docelowo używać na wielu platformach. Tutaj nie ma jednoznacznego wyboru. W pierwszym przypadku kosztem wspomnianej utraty przenośności uzyskujemy spójność oprogramowania, szybkość startu, czy działania w ogóle. Także samo projektowanie i implementacja są teoretycznie prostsze, korzystać można bowiem z gotowych rozwiązań. Program staje się jednak bardzo silnie związany z wybraną platformą i przeniesienie go na inną sprowadza się zazwyczaj do przepisania większości kodu od nowa. (Przykładem może tu być właśnie Internet Explorer w wersji na Mac OS X. W miejsce silnika Trident używa on silnika Tasman.) W przypadku drugim trzeba częstokroć „wyważać otwarte drzwi” i pisać funkcje, które być może już znajdują się w na przykład Windowsie. Dlaczego? Bo niekoniecznie są one zaimplementowane w Linuksie, a chcemy mieć produkt uniwersalny. Także same algorytmy wyglądają w takim przypadku trochę inaczej, ponieważ odnośnie stanu systemu nie można w nich niczego zakładać z góry.

Po trzecie – jak widać z przeprowadzonego doświadczenia, w przypadku silnego powiązania z platformą systemową może jednak pojawić się problem. Brak przejrzystości działania oprogramowania. Otóż proszę państwa – w czasie kiedy pojawił się Windows 2000 i nie wiele było informacji na jego temat, na własnej skórze przeżyłem koszmar związany z „zabezpieczaniem” systemu przed nieuprawnionym użyciem takich wynalazków jak Internet Explorer właśnie. Sposoby, które „na zdrowy rozum” powinny działać, działać nie chciały i zawsze pojawiała się jakaś luka a proszę mi wierzyć – chodziło o sprawy bardziej skomplikowane niż opisane wyżej, proste zablokowanie programu wykonywalnego.

Jaki z tego wszystkiego wniosek dla zwykłego śmiertelnika, który nie pisze oprogramowania? Powiem tak: W życiu nigdy nic nie wiadomo. Używanie na przykład OpenOffice.org w Windowsie być może naraża nas na niewielki dyskomfort związany z czasem oczekiwania na załadowanie pliku, ale zyskujemy jednocześnie możliwość w miarę bezbolesnego przejścia na Linux, Solaris czy FreeBSD dosłownie w każdej chwili. Odnajduję tutaj jeszcze jedno znaczenie wyrażenia „wolne oprogramowanie” – daje nam ono wolność wyboru. W przypadku korzystania z programów Microsoftu, silnie związanych z jednym tylko systemem, przestawić się będzie nam niestety bardzo trudno. Nie będą one raczej implementowane na inne platformy, a jeśli nawet, to komfort pracy nie będzie na nich odbiegał od tego z innych aplikacji. I choćby w pewnym momencie okazało się, że wolne oprogramowanie nie jest już takie powolne, przyzwyczajenia wezmą górę.

Jest to przejaw sprawdzonej techniki marketingowej polegającej na takim ukierunkowaniu klienta, żeby, czy mu się to podoba czy nie, wybierał określony produkt tylko dlatego, że używał do tej pory jego starszej wersji. Czyli Vendor Lock-In.

Co autor miał na myśli

W ostatnim słowie przypominam tylko, że artykuł ma charakter przede wszystkim rozrywkowy. Wspominałem już o tym na blogu we wpisie Refleksje, czyli: Windows vs. Linux… Po wtóre, przypominam, że celem (poza rozrywką) nie jest wykazywanie wyższości Linuksa nad świętami Wielkiej Nocy lecz porównanie cech systemów. Zgoda, że omawiając szczegóły równocześnie poddaję je wartościowaniu, lecz nijak się to ma do systemu jako całości. Kiepski szczegół nie musi rzutować na ogół (i na odwrót z resztą). Jeśli ktoś ma wrażenie, że preferuję Linuksa, to owszem – tak jest w istocie, ale na Windowsach spędzam mniej więcej tyle samo czasu i jeszcze żyję.
I to by było na tyle. Na razie…