Zaginione Dusze Sieci: Jak ratowałem (i traciłem) prototypy internetu z lat 90.

W piwnicy pełnej wspomnień i kurzu

Pamiętam ten zapach. Wilgoć, stęchlizna, ale przede wszystkim… ozon. Zapach ten nie był z niczym innym niż zasilaczami, które walczyły o życie w serwerach, pamiętających czasy, gdy internet nie był wszechobecnym potworem, a raczkującym jeszcze dzieckiem. W piwnicy opuszczonego biurowca na przedmieściach Warszawy, gdzieś pomiędzy starymi kartonami i porzuconymi meblami, znalazłem swoje pierwsze zagubione dusze sieci – prototypy, eksperymenty, zapomniane ścieżki, którymi mógł potoczyć się rozwój internetu. No, przynajmniej tak sobie to wtedy wyobrażałem. Dziś patrzę na to z większym dystansem, ale sentyment pozostał.

Ta piwnica to był mój Cyfrowy Egipt. Każdy z tych zakurzonych sprzętów był hieroglifem, który należało rozszyfrować, żeby zrozumieć, jak myśleli inżynierowie tamtych czasów. To była archeologia cyfrowa w czystej postaci. Z narzędziami w ręku, kawałek po kawałku, zaczynałem rekonstruować ten zapomniany świat.

Pierwsze ofiary: Modemy i protokół SLIP

Moim pierwszym celem były modemy. Och, modemy! US Robotics Sportster V.34 – legenda! Pamiętam, jak z wypiekami na twarzy próbowałem go uruchomić, by połączyć się z BBS-em mojego kumpla. To były czasy, gdy dźwięk wybieranego numeru był muzyką dla moich uszu, a każda dodatkowa kilobajt na sekundę – małym zwycięstwem. Ale szybko okazało się, że te urządzenia, mimo swojej legendy, są wyjątkowo kapryśne. Kondensatory wysychały, tranzystory odmawiały posłuszeństwa, a protokół SLIP, który próbowałem uruchomić, zdawał się być bardziej udręką niż rozwiązaniem. SLIP (Serial Line Internet Protocol) był protokołem, który, upraszczając, pozwalał na przesyłanie pakietów IP przez łącze szeregowe. Był prosty, ale toporny i podatny na błędy. Zapomnijcie o DHCP! Każdy adres IP trzeba było konfigurować ręcznie. Każda literówka to kolejne godziny frustracji.

Pierwszy modem, a właściwie trzy, spaliły się niemal natychmiast. Zbyt wysokie napięcie, starość materiałów… cóż, internetowy darwinizm. Ale to nie zniechęciło mnie do dalszych poszukiwań. Uparłem się, żeby zrozumieć, dlaczego SLIP był tak problematyczny. Zacząłem grzebać w starych dokumentacjach, czytać fora internetowe sprzed dekady (dzięki Wayback Machine!), rozmawiać z ludźmi, którzy pamiętali te czasy. Odkryłem, że SLIP był ofiarą swojej własnej prostoty. Brakowało mu mechanizmów korekcji błędów i kompresji, co w połączeniu z niską jakością łączy telefonicznych tamtych czasów, czyniło go praktycznie bezużytecznym. Potem przyszedł PPP (Point-to-Point Protocol), który był bardziej skomplikowany, ale znacznie bardziej niezawodny. Ale do tego momentu zdążyłem już spędzić dziesiątki godzin na bezowocnych próbach uruchomienia SLIP.

I pamiętam jeden szczególnie uparty modem. Zdobyłem go od znajomego elektronika, który mówił, że chyba jeszcze działa. Był to model Hayes Optima 288 V.FC. Prawdziwy dinozaur. Po podłączeniu wydawał dziwne odgłosy, coś jakby jęki i piski. Po wielu próbach, i wymianie kilku kondensatorów, w końcu udało mi się nawiązać połączenie z moim własnym, lokalnym serwerem. Przez chwilę, poczułem się jak pionier, przecierający szlaki w cyfrowej dżungli. Ale radość nie trwała długo. Po kilkunastu minutach modem zawiesił się, a po restarcie już nie wstał. Kolejna ofiara internetowej archeologii. Ale czegoś się nauczyłem. O cierpliwości i pokorze wobec technologii.

Karty sieciowe i ISA: walka z kompatybilnością

Po modemach przyszła pora na karty sieciowe. A tu zaczyna się prawdziwa zabawa! ISA kontra PCI, konflikty IRQ, ręczne konfigurowanie sterowników… to była prawdziwa szkoła przetrwania. Pamiętam, jak próbowałem uruchomić starą kartę sieciową 3Com EtherLink III w moim archaicznym komputerze z procesorem Intel 486. Te karty, w przeciwieństwie do swoich nowszych kuzynów PCI, wymagały ręcznej konfiguracji adresu bazowego I/O, przerwania IRQ i kanału DMA. Jeśli którekolwiek z tych ustawień kolidowało z innymi urządzeniami w systemie, komputer odmawiał posłuszeństwa. To była loteria! Czasami udawało się za pierwszym razem, a czasami trzeba było spędzić całe dnie na grzebaniu w ustawieniach BIOS-u i konfiguracji Windows 3.11.

Zdobyłem nawet kilka kart sieciowych, które miały wbudowane gniazdo BNC do podłączenia grubego koncentrycznego kabla ethernetowego (10Base5). To były prawdziwe relikty! Wyobraźcie sobie: gruby, ciężki kabel, który trzeba było przeciągać przez całe pomieszczenie i podłączać do karty sieciowej za pomocą specjalnego złącza w kształcie litery T. A na końcach kabla musiały znajdować się terminatory o rezystancji 50 omów, żeby uniknąć odbić sygnału. Jeśli o tym zapomniałem, cała sieć przestawała działać. To były czasy! Dziś to brzmi jak jakiś prehistoryczny żart, ale wtedy to była standardowa technologia.

Niejednokrotnie kończyło się na tym, że dwie identyczne karty sieciowe zachowywały się zupełnie inaczej na różnych komputerach. Problemem były niedoskonałości w BIOS-ach płyt głównych, niekompatybilność sterowników, a czasem po prostu… zła karma. Zdarzało się, że po wielu godzinach prób, jedynym rozwiązaniem było wyjęcie karty z komputera i rzucenie nią o ścianę. Oczywiście, to nie naprawiało problemu, ale przynosiło chwilową ulgę.

Z perspektywy czasu, te problemy z kompatybilnością kart sieciowych ISA nauczyły mnie jednego: że technologia to nie tylko sucha specyfikacja, ale również skomplikowana interakcja różnych komponentów i oprogramowania. Że czasem, nawet najlepsze rozwiązania, mogą zawieść z powodu banalnego błędu w konfiguracji.

Serwery z odzysku i dystrybucje Unixa

Największym wyzwaniem było odzyskanie i uruchomienie serwerów. Zdobyłem kilka starych maszyn, które pamiętały czasy, gdy serwery nie były małymi, energooszczędnymi pudełkami, a potężnymi szafami, które hałasowały jak odrzutowce i zużywały prąd jak małe elektrownie. Jeden z nich, znaleziony w magazynie firmy, która bankrutowała, miał na pokładzie dwie procesory Intel Pentium Pro i 512 MB pamięci RAM – w tamtych czasach to był prawdziwy potwór! Ale uruchomienie go okazało się nie lada wyzwaniem.

Problemem nie był sam sprzęt, ale oprogramowanie. Większość serwerów tamtych czasów działała pod kontrolą różnych dystrybucji Unixa. Slackware, Debian, FreeBSD… każda z nich miała swoje specyficzne wymagania i idiosynkrazje. Próbowałem zainstalować Slackware na moim nowym/starym serwerze, ale utknąłem na etapie konfiguracji X Window System. Okazało się, że karta graficzna, którą miałem w serwerze, nie była obsługiwana przez Slackware. Spędziłem kilka dni na poszukiwaniu odpowiednich sterowników, ale bez skutku. W końcu, zrezygnowany, spróbowałem zainstalować Debiana. I ku mojemu zaskoczeniu, wszystko poszło gładko! Debian okazał się bardziej tolerancyjny na starzejący się sprzęt.

Po instalacji systemu operacyjnego, musiałem skonfigurować serwer tak, żeby pełnił jakąś użyteczną funkcję. Postanowiłem zrobić z niego serwer WWW. Zainstalowałem Apache, skonfigurowałem wirtualne hosty, napisałem kilka prostych stron HTML. I ku mojemu zdziwieniu, wszystko zadziałało! Mój stary serwer, po latach zapomnienia, znowu ożył. Przez chwilę, poczułem się jak demiurg, który powołuje do życia nową cywilizację. Ale to uczucie szybko minęło. Serwer zaczął się przegrzewać, dyski twarde wydawały dziwne odgłosy, a połączenie z internetem było tak wolne, że przeglądanie stron WWW było torturą.

Co więcej, konfiguracja routingu na starych systemach wymagała znajomości komend, o których dzisiaj mało kto pamięta. route add default gw – to była mantra tamtych czasów. Zapomnijcie o GUI, wszystko konfigurowało się z linii komend. A jeśli popełniłem błąd, cała sieć przestawała działać. To była dobra lekcja pokory. Nauczyłem się, że nawet najpotężniejszy serwer, bez odpowiedniej konfiguracji, jest tylko bezużytecznym kawałkiem krzemu i metalu.

Ostatnie tchnienie: Utracone dane i akceptacja

Niestety, większość moich projektów zakończyła się fiaskiem. Stary sprzęt był zbyt awaryjny, oprogramowanie zbyt przestarzałe, a moja wiedza zbyt ograniczona. Wiele dysków twardych odmówiło posłuszeństwa, taśmy magnetyczne rozsypały się w pył, a układy scalone spaliły się bezpowrotnie. Straciłem wiele cennych danych – stare zdjęcia, dokumenty, programy, które pisałem w młodości. Próbowałem je odzyskać, ale bez skutku. Okazało się, że technologia odzyskiwania danych z lat 90. jest równie przestarzała, jak sam sprzęt.

Pamiętam jedną szczególną sytuację. Miałem starą taśmę DAT, na której znajdowały się kopie zapasowe z jednego z moich pierwszych serwerów. Taśma była w tragicznym stanie – pognieciona, popękana, pokryta pleśnią. Mimo to, postanowiłem spróbować odzyskać z niej dane. Znalazłem w internecie stary magnetofon DAT, podłączyłem go do komputera i zacząłem odczytywać taśmę. Proces trwał kilka dni. Co chwilę pojawiały się błędy odczytu. Ale nie poddawałem się. Kawałek po kawałku, odzyskiwałem dane. Aż w końcu, taśma pękła. Straciłem wszystko. To był jeden z najbardziej frustrujących momentów w mojej przygodzie z retro-technologią.

Z czasem nauczyłem się akceptować utratę. Zrozumiałem, że celem mojej pasji nie jest bezmyślne gromadzenie starych sprzętów, ale zrozumienie historii technologii, nauka na błędach przeszłości i docenianie postępu. Zrozumiałem, że niektóre rzeczy muszą odejść w zapomnienie, żeby zrobić miejsce dla nowych. Że internet to nie tylko technologia, ale również proces ciągłej zmiany i ewolucji. I że najważniejsze jest to, żeby pamiętać o tych, którzy tworzyli internet w jego początkach. O tych, którzy eksperymentowali, ryzykowali i przegrywali. O tych, którzy swoimi błędami i porażkami utorowali drogę dla dzisiejszego internetu.

Dziś, zamiast trzymać te relikty w piwnicy, skupiam się na dokumentowaniu ich historii. Tworzę strony internetowe, piszę artykuły, organizuję spotkania dla pasjonatów retro-technologii. Staram się przekazać swoją wiedzę i doświadczenie innym. Chcę, żeby pamięć o zagubionych duszach sieci przetrwała jak najdłużej. Bo w końcu, to one są fundamentem tego, co mamy dzisiaj. I to im zawdzięczamy to, że możemy teraz czytać ten artykuł.