Zmierzch amatorów

Liczba odsłon: 45

W numerze 12/1988 czasopisma Komputer ukazał się artykuł Andrzeja Kadlofa o identycznym tytule — „Zmierzch amatorów”. Autor przedstawiał w nim tezę, że oprogramowanie najwyższej jakości nie może zostać napisane przez amatorów, nawet nęconych wizją wygranych w konkursach, i że rosnący poziom skomplikowania intrefejsów użytkownika oraz zwiększająca się liczba konfiguracji sprzętowych, które oprogramowanie musi prawidłowo obslugiwać powodują, że jedynie duże koncerny, zdolne do inwestycji w sprzęt testowy oraz kadrę działu pomocy technicznej, są w stanie sprostać zadaniu tworzenia programów na poziomie, przydatnych szerokiemu gronu użytkowników.

Ośmieliłem się wtedy nie zgadzać z Autorem i czas pokazał, że w pewnym zakresie miałem rację. Najlepszym tego przykładem jest fakt, że słowa te czytacie dzięki oprogramowaniu rozwijanemu przez otwartą społeczność programistów, którego kod źródłowy jest szeroko dostępny, a praktycznie każdy może zgłosić poprawkę usuwającą zauważony błąd lub uzupełniającą program o dodatkowe funkcje. Problem braku środków na testowanie działania i obsługę programu został rozwiązany metodą skali: zamiast kilku, kilkunastu programistów w przedsięwzięciu biorą ich udział dziesiątki lub setki (jeśli nie tysiące), a obsługa techniczna jest oferowana użytkownikom przez grupy wolontariuszy niosących pomoc na grupach i forach dyskusyjnych.

Również wysokiej klasy programy czysto użytkowe, przeznaczone do codziennego wykorzystania przez nieobeznanych ze światem mikrokomputerów użytkowników są rozwijane w sposób amatorski, bez bezpośredniego wsparcia wielkich firm. Wiele mniejszych aplikacji powstaje wręcz w kilkuosobowych zespołach lub jest dziełem pojedynczych programistów, którym program rozwiązujący konkretny problem był potrzebny. Faktycznie, z jakością takich programów jest bardzo różnie, lecz wiele z nich nie ustępuje łatwością obsługi i niezawodnością produktom komercyjnym.

Jest jednak obszar rynku oprogramowania, w którym amatorom – a w szczególności niewielkim ich grupom – coraz trudniej jest rozwijać własne, niewielkie projekty. Obszar ten to systemy operacyjne.

System operacyjny to bardzo wdzięczny obiekt amatorskich eksperymentów. Czasem próba napisania własnego systemu to kolejny krok programisty doświadczonego już w tworzeniu oprogramowania aplikacyjnego, a wciąż dysponującego wystarczającą ilością wolnego czasu, by zmierzyć się ze skomplikowanym kodem, często tworzonym na poziomie asemblera. Trudno przecenić wartość edukacyjną takich praktycznych eksperymentów z „najważniejszym z programów”. Własny system daje też możliwość przetestowania oryginalnych pomysłów, zrozumienia problemów innych programistów systemowych oraz nabrania pokory wobec błędów szeroko rozpowszechnionych systemów operacyjnych, tak chętnie piętnowanych przez tych, co nigdy nie doznali radości z przełączenia na własną rękę mikroprocesora z trybu rzeczywistego w tryb chroniony.

Przez wiele lat ci odważni, którzy stawali w szranki ze sprzętem składającym się na komputer klasy PC mieli do pomocy kompendia w rodzaju Anatomii PC. Mogli w nich znaleźć wszystkie informacje potrzebne do własnoręcznego oprogramowania najpopularniejszych i najbardziej niezbędnych urządzeń peryferyjnych, dzięki czemu ich dzieło mogło zacząć reagować na sygnały z klawiatury i myszki oraz rysować obrazy w trybie graficznym karty VGA. Gdyby udało im się rozpowszechnić swój system, ich zadanie nie byłoby znacznie trudniejsze, gdyż do pełnej użyteczności wystarczyłoby oprogramowanie kilku rodzajów układów scalonych odpowiedzialnych za grafikę SVGA, kilku standardów sterowania pracą drukarki i dosłownie dwóch czy trzech rodzin układów dźwiękowych. Napisanie uniwersalnego, działającego z szerokim wachlarzem konfiguracji sprzętowych systemu operacyjnego było na wyciągnięcie ręki.

A dzisiaj? Dzisiaj każdy producent sprzętu próbuje przeforsować własny standard programowania urządzenia, a ewentualne przejawy unifikacji widzi się tylko tam, gdzie kilku wytwórców podzieliło się rynkiem tłamsząc drobniejszą konkurencję. Drukarki, zamiast obsługiwać jednorodny język opisu strony, wymagają osobnego sterownika dla każdego modelu. Mostki SATA oferują różne dodatkowe możliwości tworzenia macierzy dyskowych, wymagające wsparcia ze strony oprogramowania (bo tak jest taniej). Nawet tak podstawowe urządzenia, jak zestawy układów sterujących pracą płyty głównej (ang. chipset) wymagają obecnie sterowników optymalizujących ich pracę. Miłym wyjątkiem są karty graficzne, lecz konieczność tworzenia dwóch tylko rodzin sterowników nie jest efektem standaryzacji sposobu programowania układów graficznych, lecz raczej monopolu dwóch koncernów na tym rynku.

Jeszcze większym problemem jest brak dokumentacji umożliwiającej oprogramowanie urządzeń. O ile kiedyś urządzenia należały do określonej grupy o ujednoliconym interfejsie programisty (na przykład karty graficzne) lub dostarczane były ze szczegółową instrukcją pozwalającą na samodzielne oprogramowanie wszystkich możliwości urządzenia (drukarki), teraz producenci skrzętnie skrywają wszelkie informacje, które mogłyby umożliwić stworzenie niezależnych, alternatywnych sterowników urządzeń. Powodów jest wiele, lecz jeden z nich wydają sie najbardziej prawdopodobny: producenci boją się, że znajomość metod programowania urządzenia umożliwiłaby konkurencji odgadnięcie sposobu w jaki dana funkcja jest zrealizowana sprzętowo. Nie dość, że mogłoby to dopomóc w stworzeniu konkurencyjnej implementacji, to jeszcze mogłoby się okazać, że dany fragment kodu sterowników lub sposób sprzętowej realizacji funkcji narusza patenty konkurencji, a to skończyłoby się długotrwałym procesem sądowym.

Brak dokumentacji uderza też w „wielkich” świata oprogramowania open-source. O ile systemy operacyjne takie jak Linux czy FreeBSD obsługują bez problemów większość mostków IDE, kart interfejsu SCSI czy interfejsów sieciowych, obsługa kart graficznych i bezprzewodowych kart sieciowych (oraz kilku innych kategorii urządzeń) daleka jest od doskonałości. Tu jednak wielkie, otwarte projekty mają przewagę nad amatorami: nie dość, że trudno jest producentowi sprzętu zignorować Linuksa i zazwyczaj zmuszony jest do udostępniania sterowników – choćby tylko w binarnej formie – to jeszcze zmasowany nacisk powoduje czasem publiczne udostępnienie dokumentacji, a stąd bardzo krótka już droga do pełnej implementacji obsługi danego typu urządzenia we wszystkich otwartych systemach operacyjnych.

Cóż zatem ma robić programista, który chciałby być autorem własnego systemu operacyjnego, jest jednak świadom ograniczeń, jakie nakłada na niego nowoczesna, pozbawiona centralnych ośrodków standaryzacyjnych elektronika? Najlepszym rozwiązaniem jest wykorzystanie pracy innych i zbudowanie systemu na bazie istniejącego, silnego rynkowo jądra. Idealnym kandydatem jest tu jądro systemu Linux, które zawiera sterowniki wielu urządzeń i jest na tyle wydajne i uniwersalne, by nie stawiać przeszkód na drodze ku budowie dowolnie skonstruowanego systemu operacyjnego. Tym więcej można osiągnąć, że obecne dystrybucje systemu Linux dalece odbiegają od oczekiwań użytkowników pod względem integracji interfejsu graficznego oraz łatwości obsługi. Zamiast zatem babrać się w kolejnym projekcie polegającym tylko na budowie jądra potrafiącego w kilku wątkach wyświetlać na ekranie kilka napisów, warto zrobić coś naprawdę pożytecznego tworząc nową jakość na rynku darmowego oprogramowania.

Oczywiście, nie chcę zupełnie zniechęcać do eksperymentów na niskim poziomie. Kilkaset wierszy kodu lepiej uczy programowania w trybie chronionym, zasad zarządzania pamięcią wirtualną i sposobów przełączania wątków niż najlepszy artykuł czy najgrubsza książka. Nie można jednak mieć złudzeń, że uda się w ten sposób napisać system liczący się na rynku, podczas gdy sława twórcy najlepszego środowiska graficznego jest w zasadzie dostępna wciąż dla każdego.


No niestety jest tendencja żeby wszystko było coraz bardziej skomplikowane... i żeby jednostka nie mogła zdziałać wiele. Systemy operacyjne są coraz większe przez niezliczoną ilość sterowników a w zasadzie coraz to nowsze konfiguracje sprzętowe nie są wyraźnie wydajniejszcze... można jednak jeszcze coś robić :) Dobry artykuł i gratuluję ciekawej i dobrze zrobionej strony (pierwszy 'blog' który się do czegoś nadaje ;)