Być może dlatego, że wspominałem ostatnio 30 lat rozwoju jądra Linuksa, a może z powodu niedawnej dyskusji o tym, czy to projekt GNU, czy też jądro jest najważniejszą częścią systemu, który ludzie nazywają „Linuksem”, zacząłem zastanawiać się, jak wiele osób myśli o tworzeniu oprogramowania w dzisiejszych czasach, w przeciwieństwie do tego, jak było to robione 40 czy 50 (lub więcej) lat temu. Takie myślenie często sprawia, że tworzą się „legendy miejskie” o oprogramowaniu, które są przekazywane od osoby do osoby.
Weźmy na przykład teorię spiskową, jakoby firmy tworzące systemy operacyjne robią je tak różne, aby „ludzie nie mogli przenieść się na nic innego”. Jestem związany z komputerami od ponad 50 lat i uczestniczyłem w wielu spotkaniach inżynierów dotyczących nowych funkcjonalności. Ani razu nie słyszałem argumentu dla nowej funkcjonalności mówiącego, że klient pozostanie, bo nie będzie w stanie się zmigrować.
Pewnie pamiętacie (lub nie, a wtedy po prostu mi uwierzcie), że komputery miały kiedyś niewiele pamięci (nawet mainframe’y), która mierzona była w kilobajtach (nie gigabajtach ani nawet w megabajtach), oraz wolne procesory z pojedynczymi rdzeniami i powolne dyski twarde.
Normalnie komputery te były tak wolne i miały tak mało przestrzeni dyskowej, że trudno było stworzyć system operacyjny do przetwarzania wsadowego, współdzielenia procesora, pracy w czasie rzeczywistym i jednoczesnej bieżącej obsługi. Mieliśmy też różne pomysły na interfejsy pomagające w obsłudze kodu aplikacji w takich dziedzinach, jak medycyna, produkcja, edukacja i inne.
Jeśli jedynym zadaniem API i funkcjonalności dostarczanych przez DEC (Digital Equipment Corporation) byłoby „zablokowanie” użytkownika w ich systemie operacyjnym, potrzebowalibyśmy tylko jednego systemu na PDP-11 zamiast wielu (ponad 11) systemów, jakie oferował (oraz opracował i wspierał) DEC.
Wraz ze wzrostem szybkości oraz powiększaniem pamięci komputerów, pojawił się pomysł jednego systemu operacyjnego, który „potrafiłby wszystko”, chociaż nadal różniłby się pomiędzy zastosowaniem biznesowym (84% rynku) i naukowym (16% rynku).
Jednak dalej istniały różnice w interfejsie pomiędzy różnymi producentami, co przekładało się na duże różnice w API i szkoleniach użytkowników, które musiały już też obejmować aplikacje, gdyż te działały tylko na jednym lub dwóch systemach.
Z tego narodził się pomysł aplikacji przenośnych, które można uruchamiać na różnych systemach operacyjnych. Rozwój standardów, takich jak standardy w językach programowania i systemach uruchomieniowych, zaczął być pomocny w tworzeniu oprogramowania przenośnego. Wszystko to dzięki ciężkiej pracy ludzi z różnych firm tworzących i testujących standardy. Niektóre firmy stworzyły „rozszerzenia” dla tych standardów, a dobrzy programiści w większości przypadków trzymali się z dala od takich rozszerzeń.
Wraz ze zwiększającą się liczbą komputerów używanych przez coraz więcej ludzi pomysł przenośności oprogramowania pokazał, że lepiej i taniej jest posiadać ten sam interfejs na wielu urządzeniach niż system operacyjny idealnie dostosowany do rzeczywistego obciążenia.
Ponieważ Unix nie został stworzony przez dostawcę systemów, ale firmę trzecią, był przenoszony na wiele różnych urządzeń i miał ten sam interfejs programistyczny. Oczywiście od kiedy pojawiły się systemy operacyjne Microsoftu, to samo można powiedzieć o większości systemów domowych.
Pragnienie, aby mieć ten sam system operacyjny na każdej platformie, widziałem raz za razem, kiedy inżynierowie Uniksa w DEC-u dostarczali doskonałą funkcjonalność uwielbianą przez naszych klientów, ale pierwsze, co ci klienci mówili, to: „Kiedy będę mógł to mieć na moich systemach Suna?”. Czemu firmy zajmujące się Uniksem nie widziały, co się zbliża, kiedy tak wielu ich klientów uwielbiało korzystać z tych samych narzędzi na wszystkich swoich pecetach, kupionych w firmach takich jak IBM, Dell czy Compaq?
Wszystko to wróciło do mnie w czasie rozmowy o GNU i jądrze. Tak, Richard Stallman chciał zbudować kompletny system operacyjny zwany GNU. Jednak we wczesnych latach 80. XX w., kiedy sprzęt był bardzo drogi, nie było Internetu, a za to było wiele innych ograniczeń, zaczął od narzędzi deweloperskich, które były dostępne za darmo i można je było zmieniać, dzięki czemu programiści posiadali te same narzędzia na różnych systemach operacyjnych.
Jeśli Richard zacząłby najpierw prace nad jądrem, nie miałby niczego, co mógłby na nim uruchomić. Z kolei Linus Torvalds nie musiał się martwić o biblioteki, kompilatory, narzędzia, system okienek i tym podobne rzeczy, bo to wszystko już istniało.
Niektórzy mogą powiedzieć: „A co z BSD?”. Problemem BSD jest czas. Kiedy w 1994 roku wydana została wersja 1.0 jądra Linuksa, dystrybucje, takie jak SLS, Red Hat, Debian, Slackware i Yggdrasil (oraz inne) też zostały wydane, a sprawa sądowa BSD dalej się ciągnęła.
