Ta książka nauczyła mnie 6 faktów o Linuksie, które musisz znać

Książka "Sztuka programowania w Unixie" Erica S. Raymonda zgłębia historię i filozofię Uniksa, podkreślając znaczenie otwartego oprogramowania oraz zasady prostoty i modułowości w programowaniu.

Sztuka programowania w Unixie (TAoUP), autorstwa Erica S. Raymonda, nie jest podręcznikiem ani książką typu „jak to zrobić”. Zamiast tego, jest to książka o historii i filozofii Unixa. Żadna inna książka nie miała większego wpływu na moje podejście do Linuksa i macOS, ani na moje codzienne jego użytkowanie. Oto tylko kilka rzeczy, których mnie nauczyła.

Unix jest nawet starszy niż myślisz

Nie musisz znać pełnej historii Unixa, aby go używać - ani Linuksa, ani macOS - dzisiaj. Ale znajomość trochę historii o tym, jak powstał Unix, nie zaszkodzi. Zrozumienie kontekstu systemu operacyjnego pomaga lepiej pojąć ekran, na który patrzysz, a historia może odpowiedzieć na wiele twoich początkowych pytań, jak „Dlaczego nazwy poleceń są takie krótkie?”

Drugi rozdział - „Historia: Opowieść o dwóch kulturach” - wyjaśnia, jak Unix powstał w 1969 roku, na teletype'ach, które wyglądały jak wytworne maszyny do pisania. Niesamowite jest myśleć, że te maszyny wciąż mają coś wspólnego z wieloma serwerami, które zasilają nasze życie w sieci.

Obecnie, można myśleć o Linuksie jako o klonie Uniksa, czym w zasadzie jest. Ale ta historia jest znacznie dłuższa i bogatsza, niż mogłoby się wydawać, a ja dumny jestem, że korzystam z systemu o pięćdziesięcioletnich korzeniach, nawet w obliczu każdego technologicznego postępu od tamtego czasu.

Otwarte oprogramowanie nie istniałoby bez Linuksa

TAoUP omawia dalej narodziny Linuksa i jak podejście Linusa Torvaldsa było kompromisem między zastrzeżonymi, zamkniętymi systemami, a ideologiczną wolnością, której przestrzegał rozkwitający ruch otwartego oprogramowania.

Ruch otwartego oprogramowania jest tak istotny dla historii Linuksa, że łatwo uznać je za jedno i to samo. Ale fascynujące jest dowiedzieć się więcej o historii otwartego oprogramowania i jak porównuje się to z podejściem zastrzeżonym czy alternatywą GNU („wolne oprogramowanie”).

Już w latach 50. inżynierowie dzielili się kodem źródłowym, czytali go i modyfikowali. Ale dopiero w latach 90., kiedy Linux pojawił się na scenie, oprogramowanie otwarte zaczęło być szeroko używane. Zbiegało się to z szerszą dostępnością internetu, mechanizmem dystrybucji, który umożliwił rozwój otwartego oprogramowania.

Linux przyjmuje prostotę (szczerze!)

Chociaż na początku może się wydawać skomplikowany, Linux opiera się na prostych zasadach podstawowych. Jeśli jest jedna lekcja, którą książka uczy bardziej niż jakakolwiek inna, to jest to. Cała sekcja dotycząca projektowania (rozdziały 4–13) wyjaśnia, dlaczego podstawowa etyka Uniksa jest tak korzystna.

Raymond bada ten koncept, dzieląc go na zestaw „reguł”, które „starszyzna” Uniksa (takie osobistości jak Rob Pike i Ken Thompson) wcześniej sformułowała mniej formalnie. Te 17 reguł to:

• Modułowość
• Kompozycja
• Prostota
• Przezroczystość
• Cisza

Te zasady w dużej mierze sprowadzają się do znanej zasady: KISS (Keep it simple, stupid!) Zachęcając do tworzenia małych programów, które wykonują podstawowe, konkretne zadania i komunikują się za pomocą prostego protokołu tekstowego, filozofia Uniksa prowadzi do powstawania narzędzi, które można ponownie wykorzystać i są niezawodne.

Dokładne, modułowe programy czynią wszystko efektywnym

Pierwsza reguła Raymonda to „Modułowość”, która jest opisana jako: „Pisz proste części połączone czystymi interfejsami.” Jak wiele innych reguł, tutaj także skupiamy się na kontroli złożoności. Wiele problemów z użytkowaniem komputerów wynika z skomplikowanych systemów, które są trudne do zrozumienia. Promując prostotę, ta zasada ma na celu zmniejszenie awarii i poprawę ogólnego zrozumienia.

Gdy po raz pierwszy spotykasz narzędzia Linuksa, takie jak ls lub grep, może być trudno traktować je jako pełnoprawne programy. Robią znacznie mniej niż twoja przeglądarka internetowa lub edytor tekstu, więc mogą wydawać się powierzchowne lub nieistotne. Ale to pomija wrodzoną moc modułowości: łączenie małych programów, aby osiągnąć więcej niż suma ich części.

Jednym z najbardziej praktycznych przykładów mocy modułowości jest potok:

ls | grep "foo" 

Oto przykład bardzo powszechnego wzorca, po który sięgam raz za razem:

du -sk * | sort -rn | head 

Ten potok uruchamia trzy programy: du do zgłaszania całkowitego rozmiaru pasujących plików/katalogów, sort do ich uporządkowania numerycznie oraz head do zwrócenia pierwszych dziesięciu wyników. Wynik to mały zbiór katalogów, które zajmują najwięcej miejsca na dysku, które mogę później przejrzeć w celu oczyszczenia.

Bez pipe'ów alternatywą byłby jeden program zwany na przykład "get-biggest-ten-folders". Taki program mógłby być nawet bardziej wygodny, ale jest znacznie bardziej ograniczony niż ogólne narzędzia dostępne tutaj. Potrzebowałbyś ogromnej liczby źle nazwanych programów, aby poradzić sobie bez pipe'ów, a ich złożoność byłaby z pewnością straszna do obsługi.

Tekst podstawa wszystkiego

Rozdział 5 książki poświęcony jest tekstualności, zarówno w kontekście formatów plików, jak i sposobu komunikacji programów Unix. To było jedno z rzeczy, które najbardziej mnie uderzyły w Unixie, zwłaszcza jeśli chodzi o konfigurację. Przechodząc z Windows, byłem przyzwyczajony do rejestru, tego niechlubnego, nieprzejrzystego, monolitycznego bazy danych, która przechowuje ustawienia programów.

Narzędzia Linuksa, w przeciwieństwie do tego, mają tendencję do posiadania plików konfiguracyjnych opartych na tekście, rozrzuconych po twoim systemie plików (w standardowych miejscach, jeśli tak wybierzesz). Możesz edytować te pliki za pomocą standardowego edytora tekstu i zapytywać je za pomocą powszechnie dostępnych narzędzi linii poleceń. Oznacza to, że nie ma potrzeby korzystania z niestandardowych narzędzi GUI do zmiany ustawień, chociaż takie mogą być nadal tworzone na bazie tradycyjnego formatu plików tekstowych.

Ta filozofia dotyczy także tego, jak programy komunikują się. Kiedy używasz potoku, przekazujesz tekst z jednego programu do drugiego. W każdej chwili możesz przerwać potok, aby go debugować. Weź ten potok jako przykład:

ls | grep "txt" 

Wstawiając polecenie tee, możesz uchwycić wynik w określonym momencie i zapisać go do pliku w celach debugowania:

ls | tee debug-ls-output.txt | grep "txt" 

To odnosi się do zasady przezroczystości Raymonda:

“Projektuj z myślą o widoczności, aby ułatwić inspekcję i debugowanie”

Używanie tekstu jako formatu komunikacji i danych oznacza, że programy działają w otwarty sposób, z mniejszą liczbą ukrytych części. Ułatwia to naprawę programów, naukę z nich i ich użycie.

Linux jest uporczywie tradycyjny, na lepsze lub gorsze

Linux — a jeszcze bardziej Unix — jest często oceniany jako "starej daty", system będący ulubieńcem "szarych brodaczy" i fanatyków. Chociaż może w tym być ziarno prawdy, to pomija fakt, że dojrzałe, ewoluowane technologie niekoniecznie są złe.

W rozdziale 14, Raymond omawia użycie C, które miało istotne znaczenie dla rozwoju Linuksa. Mimo że sytuacja ewoluuje, wiele standardowych narzędzi wiersza poleceń jest nadal pisanych w C. Książka zauważa, jak C się proliferowało, częściowo dzięki doskonałemu wsparciu narzędzi, które przetrwały próbę czasu.

Raymond nie jest absolutystą; wyjaśnia, że Python, stosunkowo nowoczesny język, jest lepszym wyborem dla nowych projektów. Ale bada także zalety i wady programowania w powłoce oraz argumentuje, że programowanie obiektowe nie jest doskonałe. Jak w wielu częściach książki, ten fragment sprzeciwia się rozwiązaniom "jedno pasuje do wszystkiego" i podkreśla, jak kontekst zawsze ma znaczenie.

Sztuka programowania w Unixie jest dostępna online za darmo oraz w wersji papierowej. Jestem dużym fanem obu, ponieważ pierwsza jest świetna jako materiał referencyjny, ale książka jest na tyle dobra, że miło jest usiąść i przeczytać ją od deski do deski.

Jeśli ciekawią Cię artykuły podobne do Ta książka nauczyła mnie 6 faktów o Linuksie, które musisz znać, zajrzyj do kategorii Linux i odkryj jeszcze więcej interesujących treści.