Jak zacząć?

Byłem ostatnio na konferencji i spotkałem młodą osobę, która chciała zacząć używać wolnego i otwartego oprogramowania, ale nie wiedziała, od czego zacząć.

Osoba ta trochę programowała, potrafiła pisać proste programy w C, ale potrzebowała otwartego środowiska programistycznego (jest ich kilka) i „chciała nawet nauczyć się pracy w edytorach vim lub emacs, ale było to bardzo trudne”.

Od bardzo dawna należę do tych, którzy preferują Vima, głównie z powodu serii edytorów, które pojawiły się w czasach terminali zwracających fizyczne wydruki. Chociaż edytory te nie były napisane przez tych samych ludzi, każdy był zwykle na tyle kompatybilny z poprzednikami, że mogłem migrować na najświeższe oprogramowanie. Korzystałem z vi/ex (bardzo przydatne w terminalach z wydrukami), a potem przeniosłem się na vi/ex na terminalach piszących na ekran, które korzystały z biblioteki Termcap do tłumaczenia ciągów znaków na wyjściu, aby odpowiednio umieścić je na ekranie.

Zdaję sobie jednak sprawę z tego, że korzystanie z potężnych edytorów takich jak vim lub emacs może być początkowo zniechęcającym doświadczeniem. Dostępne są całe książki na temat tego, jak ich używać, a przecież w założeniu praca z nimi jest raczej prostą czynnością, polegającą na przenoszeniu i edycji tekstu.

Podobnie wygląda to w większości otwartego (wliczając w to darmowe) oprogramowania, a że dodatkowo deweloperzy pozwalają nam poznać to, co „pod maską”, sprawy jeszcze bardziej się komplikują. Łatwo jest poczuć się przytłoczonym.

Poradziłem tej młodej osobie, aby skoncentrowała się na małym zestawie poleceń Vima (to samo się odnosi do Eacsa, ale ja wybrałem Vima), które pozwolą jej otworzyć plik, zapisać go, przejść do trybu wprowadzania, wyjść z niego, poruszać się w trybie pełnoekranowym i tak dalej.

Z czasem warto się nauczyć wyszukiwania ciągów znaków czy przenoszenia kursora na koniec lub początek wiersza jednym skrótem klawiszowym, ale na początku tego nie potrzebujemy.

Czy powinniśmy próbować nauczyć się wszystkich poleceń? Nie, ale warto czasami pomyśleć: „Założę się, że vim posiada takie polecenie, spróbuję znaleźć je w funkcji pomocy”.

Podobnie to wygląda w przypadku samego GNU/Linuksa. Chociaż moc Linuksa w rzeczywistości leży pod graficznym interfejsem, czyli w miejscu, które większość ludzi określa jako „wiersz poleceń” lub „poziom powłoki”, wiele osób może robić to, czego potrzebuje bez poznawania tej części systemu.

Ludzie mogą tworzyć pliki za pomocą graficznych edytorów tekstu (w moim systemie jest to xed) uruchamianych z menu systemu, do którego dostaniemy się za pomocą myszki. W strukturze katalogów możemy poruszać się dzięki graficznemu menedżerowi plików. Wydruk pliku zrealizujemy, klikając na nim i wybierając funkcję „drukuj” za pomocą myszki. Wszystko ma swoje graficzne odpowiedniki i dostępnych jest wiele aplikacji, które działają tylko w taki sposób, bez potrzeby przechodzenia do wiersza poleceń.

Jednak, aby poznać prawdziwą moc GNU/Linuksa, musimy chcieć szukać, eksperymentować i się uczyć.

W 1977 roku zostałem administratorem systemów Unix w Bell Laboratories. Chociaż pracowałem z wieloma różnymi systemami operacyjnymi na wielu urządzeniach, nie zdarzyło mi się wcześniej pracować z Uniksem. Bell Labs (twórcy Uniksa) zatrudnili mnie, ponieważ pokazałem, że potrafię się uczyć i stosować to, czego się nauczyłem.

Wysłano mnie na tygodniowy kurs Uniksa i przydzielono dwóch starszych kolegów, którzy pomagali mi z pracą na samym początku.

Którejś nocy siedziałem nad (papierową) konsolą systemu Unix i miałem steki plików, które miały być zaktualizowane. W każdym z nich trzeba było przenieść elementy we wszystkich wierszach z jednego miejsca do drugiego. Cierpliwie (a ci, co mnie znają, wiedzą, że cierpliwość nie jest moją mocną stroną) edytowałem pliki jeden po drugim, wykonując zadanie w każdym wierszu. Oszacowałem, że zajmie mi to osiem godzin, a może nawet więcej.

Po godzinie czy dwóch przestałem. Powiedziałem sobie: „Nie wiem, czy Unix posiada polecenie, które to zrobi, ale założę się, że ma”. Przestałem więc edytować i zacząłem przeglądać podręcznik systemowy.

Dosyć szybko trafiłem na polecenie cut, które wydawało się tym, czego chciałem, ale potrzebowałem więcej. Na dole strony zobaczyłem słowa „Zobacz również paste”. Patrząc na te strony, stworzyłem plan wykorzystania cut i paste do realizacji mojego zadania. Dwadzieścia minut później wyszedłem z pokoju.

Nie zapamiętałem wszystkiego, co cut lub inne polecenia mogą robić, ale po tym wydarzeniu raz do roku spędzałem godzinę czy dwie na odświeżaniu mojej pamięci na temat różnych poleceń Uniksa.

Wiedziałem, że pozostałe polecenia będą robić to, czego chcę, wtedy kiedy będę tego potrzebował.

Jon „maddog” Hall jest autorem, wykładowcą, informatykiem i jednym z pionierów Wolnego Oprogramowania. Od 1994 roku, kiedy po raz pierwszy spotkał Linusa Torvaldsa i ułatwił przeniesienie jądra na systemy 64-bitowe, pozostaje orędownikiem Linuksa. Obecnie jest prezesem Linux International®.