Środowiska graficznego zacząłem na dobre używać niewiele ponad 10 lat temu.

Do tamtej pory, przez 20 lat zmagałem się jedynie z interfejsem znakowym i nieodzowną dlań linią poleceń. Myślę, że ten bagaż doświadczeń upoważnia mnie do konkluzji, iż interfejs graficzny bardziej sprzyja użytkownikowi, nawet jeśli jest nim administrator lub programista.

Pisząc polecenie systemu, musimy a priori znać jego składnię i skutki. W interfejsie graficznym mamy co potrzeba wyszczególnione czarno na białym (a raczej kolorowo na kolorowym), więc korzystając ze stosownych objaśnień można wybrać właściwą opcję. Niezbędna natomiast w obu przypadkach jest znajomość merytoryczna czynionych działań. Zestawienie wad i zalet tych dwóch stylów stanowi kamień węgielny pod animozje zwolenników różnych konwencji systemów operacyjnych. Chodzi oczywiście o kontrowersje między użytkownikami Linuxa i Windowsa. Hałas najczęściej podnoszą zwykli użytkownicy lub administratorzy. Programistom aplikacji jest to zapewne obojętne, gdyż system operacyjny stanowi jedynie konieczną warstwę, niezbędną do wytwarzania oprogramowania użytkowego. Dla nich raczej istotne jest otoczenie narzędziowe, jako bezpośredni warsztat pracy, służące do produkcji oprogramowania. I w zasadzie takie podejście jest słuszne, gdyż system operacyjny nie powinien wzbudzać emocji, natomiast powinien być (jeśli już musi istnieć) transparentnym składnikiem podstawowym komputera - bezszelestnie i bezkolizyjnie świadczącym swe usługi warstwie wyższej. Tak jak nie istnieją dziś szerokie fronty antagonistyczne zwolenników pewnych typów dysków twardych czy pamięci operacyjnych, tak też kiedyś zanikną spory dotyczące systemów, które drogą ewolucji dojdą do pewnego poziomu zgodności funkcjonalnej.

Zapewne za kilka lat pojawi się system operacyjny o zupełnie odmiennej filozofii, bowiem Microsoft już w tym względzie cośkolwiek przebąkuje. Jak z tym będzie, zobaczymy. Na chwilę dzisiejszą pragnę zauważyć, że o jakim systemie byśmy nie mówili, to ma on jedną podstawową wadę: jest zbyt skomplikowany w zarządzaniu. W związku z tym wymaga specjalistycznej kadry administratorów, którzy opatrzeni plikiem poważnych certyfikatów (ani tanich, ani też prostych do zdobycia) "walczą z materią" w mniejszych lub większych firmach. Co gorsza, specjalizacja ta zaczyna się mocno rozczapierzać i niedługo patrzeć, jak specjalista od DNS nie będzie specjalistą od DHCP. No może przesadziłem, ale w każdym razie uważam, że ta właśnie podstawowa warstwa techniczno-operacyjna powinna ulec uproszczeniu w zarządzaniu, bo na razie z technologią jest coś nie tak i wymaga ona zbyt wielu jałowych zabiegów na siebie samą.

Wracając do porównań między interfejsem znakowym i graficznym, przytoczę co następuje. W pewnej firmie administrator bardzo upodobał sobie systemy *niksowe. Administrował tam także bazą danych PostgreSQL. Administracja polegała na codziennym automatycznie uruchamianym poleceniu pgdump, służącym do archiwizacji bazy. Potrafił także bezwzrokowo wprowadzać różne skomplikowane polecenia systemu, jak też i polecenie pgdump z różnymi parametrami. Jednak o oczyszczaniu bazy (vacuum) jakoś nie pamiętał. Potem dodatkowo dostał pod opiekę bazy MS SQL. Przez rok w zasadzie nie musiał ingerować, bo wszystko działało na zaprogramowanych automatach. Po roku wykazał zdziwienie, że polecenia archiwizacji są tak skomplikowane i w różnych odmianach. Przy czym nie mógł dociec, czy pierwotnie były one wpisywane ręcznie, czy generowane automatem. A jaka różnica, pytam? Wszystko, co wygeneruje automat, można w razie potrzeby ręcznie skorygować. Jeśli tylko zna się meritum sprawy. Administrator ten do dziś nie wie jaka jest polityka archiwizacji baz MS SQL, jak odzyskuje się miejsce w logu transakcyjnym i co to za jedno ten log. Szeregu innych rzeczy także nie wie. Bo kwestia nie leży w interfejsie, ale w wiedzy, wnikliwości i otwartym umyśle.