Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Hymnu pochwalnego część kolejna (cz. 3)

Ten wpis jest komentarzem to tekstu pana Adama Golańskiego (eimi) o rz...

Wreszcie konkrety!

W dzisiejszym komentarzu zajmę się 3 zarzutami jakie autor stawia nowoczesnemu Linuksowi:
  • Brak zgodności z FHS (Filesystem Hierarchy Standard)
  • Programy *Kit, Udisk, nie przeznaczonych dla powłoki
  • Wykorzystywanie rozbudowanego programu systemd

Jedna hierarchia plików aby nimi wszystkimi zarządzać

Hierarchia systemów plików w systemach Uniksopodobnych to bardzo ciekawy temat.

W raz z rozwojem Uniksów narastała potrzeba rozwoju struktury podstawowych folderów. A mnogość samych systemów tylko się przyczyniała do mnogości własnych rozwiązań różnych producentów.

Problem nie ominą Linuksa. Ale został w miarę szybko dostrzeżony. W 3 lata po upublicznieniu pierwszej wersji (0.1) jądra Linux, powstał standard FHSND w wersji 1.0. Miał on za zadanie uporządkować hierarchię systemu plików w różnych dystrybucjach Linuksa.

Standard się przyjął, i był intensywnie rozwijany przez kolejne 4 lata, zdobywając dobrą opinię. W 97' wydana została nowa wersja standardu, tym razem przeznaczona dla wszystkich Uniksów. Jego ostatnia wersja 2.4 pochodzi z 2004 roku.

FHD jest też jedną z podstaw standardu LSB (Linux Standard Base) który określa podstawowe możliwości które powinny oferować wszystkie dystrybucje Linuksa.

FHD nie jest jednak doskonały. I jak autor zauważył, szczegółowość i drobiazgowość FHD przy rozróżnianiu na główne katalogi i te pod /usr/, są uznawane coraz częściej za zbędne. Oczywiście takie podejście jest CAŁKOWICIE zasadne! /usr/ powstał TYLKO dlatego, że zabrakło miejsca na dysku a można było wykorzystać drugi. (A /home/ powstało dlatego, że twórcy Uniksa dostali 3 dysk i łączna powierzchnia przekroczyła 3 MegaBajty!!!)

Jak to się stało, że ten podział przetrwał tyle lat? Tego pewnie nikt nie wie. Najprawdopodobniej nikt nie zadał sobie pytania, "Czy na ten problem mamy lepsze rozwiązania?".

FHD jak każdy standard ma też kilka drobniejszych problemów.

A więc czy to źle, że społeczność Linuksowa szuka nowych rozwiązań?

Jak najbardziej nie. FHD i kontrowersje z /usr/ to przykład na zdrową krytykę założeń na których obecnie się opieramy, i sensowy opór przed nadmiernymi komplikacjami.

Czy konsola jest przenośna?

Temat ważny przy omawianiu Console/PackageKitów i Udisk ale też i systemd.

I należy tutaj przytoczyć pewną anegdotę z książki pt. "Unix Sztuka Programowania" Erica S. Raymonda.

Mistrz Foo i dziesięć tysięcy linii
Mistrz Foo powiedział kiedyś do odwiedzającego go programisty: "W jednej linii skryptu powłoki znajdziesz więcej natury Uniksa niż w dziesięciu tysiącach linii kodu C"

Programista dumny ze swojej biegłości w języku C, odparł: "Jak to być może? Przecież to w języku C zaimplementowano jądro Uniksa!"
[... dalsze wymiany "W jednej linii skryptu.." i "Ależ..."]

Mistrz Foo odpowiedział: "To wszystko prawda. Niemniej jednak w jednej linii skryptu powłoki znajdziesz więcej natury Uniksa niż w dziesięciu tysiącach linii kodu C"

Programista zaśmiał się i wstał, aby odejść, ale Mistrz Foo skinął na swojego ucznia Nubiego, który napisał na tablicy jedną linię skryptu powłoki. I rzekł Mistrz do programisty: "Mistrzu programisto, spójrz na ten potok. Czyż jego implementacja w C nie zajęłaby dziesięciu tysięcy linii?

Programista mamrotał pod wąsem, analizując to, co napisał Nubi, aż w końcu musiał zgodzić się z Mistrzem.

"A ileż godzin spędziłbyś implementując i sprawdzając ten potok w C?"

"Wiele -- przyznał programista -- ale tylko głupiec poświęciłby czas na to, podczas gdy czeka na niego tyle wspaniałych zadań."

"Więc kto lepiej zna naturę Uniksa? -- spytał Mistrz Foo. -- Ten kto pisze dziesięć tysięcy linii, czy ten kto dostrzegając pustość zadania z pisania rezygnuje?"

Usłyszawszy to, programista doznał oświecenia.

Ta anegdota oprócz małego odświeżenia wnosi do naszej dyskusji ważny wątek. Filozofia Uniksa dotyczy PRAKTYCZNOŚCI. Prosto bo tak jest praktycznie. Zwięźle bo tak jest praktycznie. Przenośnie bo tak jest praktycznie. Itd. Itp. Etc.

Pokazuje też, że filozofia Uniksa to tak na prawdę ocenianie, które rozwiązanie jest lepsze.

I tutaj dochodzimy do dzisiejszej bolączki konsoli/powłoki. Ta nie jest przenośna. Skrypty pisane pod jedną powłokę nie będą działały pod inną powłokę. Skrypty pisane pod jedną powłokę nie będą działały pod tą samą powłoką JEŚLI wszystkie zależności nie będą spełnione.

Skrypty powłoki to rozwiązanie takie samo jak inne. Ma swoje zady i walety.

Mając to na uwadze przejdźmy do kolejnych problemów podkreślanych przez naszego ukochanego autora.

A może by tak Kit na integrację innych Kitów z konsolą?

*Kit to próba odpowiedzi na niejednolitość rozwiązań jakie mogą zapewnić powłoki. Sterowanie procesami? Rozbudowane ale niejednolite!
Zarządzanie aplikacjami i ich zależnościami? (Mniej lub bardziej) Rozbudowane ale (totalnie) niejednolite!
Zarządzanie uprawnieniami? (Mniej) Rozbudowane ale niejednolite!

Skrypty powłoki nie oferują oczekiwanego rozwiązania. A jak zauważył Mistrz Programista, kto chce poświęcić czas na ponowne wynajdywanie koła?

Istnienie Kit'ów jest więc zasadne. Rozwiązują konkretne skomplikowane sposoby. Pozostaje jeszcze kwestia trudności obsługi owych z poziomu skryptów.

Ta jest iluzoryczna. Kity wykorzystują DBus. A ten jak najbardziej jest obsługiwany z konsoli np. przez dbus-send. Do tego jest potrzebna specyficzna wiedza, ale ta jest dostępna.

Tak więc obsługa Kit'ów z konsoli jest możliwa!

Dzięki takiemu podejściu rozwiązano też problem niejednolitości. Nie tylko pomiędzy różnymi systemami, ale też pomiędzy możliwościami konsoli a zwykłych języków programowania.

Z Udisk jest podobnie. Jednolite rozwiązanie, dostępne z konsoli (tylko nie bezpośrednio), obsługujące nawet najbardziej skomplikowane konfiguracje.

systemd arcy-przestępca desktopowego półświatka!

Z powyższego tekstu uważny czytelnik może się zorientować, że integrację systemd ze skryptami powłoki zapewniają te same narzędzia co z *Kit'ami.

Pozostaje jeszcze kwestia złożoności systemd i przydatności tego poza "desktopami".

systemd jest bardzo modułowy. Cała gama funkcji i rozwiązań może być włączania i wyłączana z systemd podczas kompilacji lub przez pliki konfiguracyjne. A dokumentacja dokładnie opisuje wszystkie funkcje.

Tak samo developerzy systemd starają się aby jego "twarde" wymagania (czyli takie bez których systemd nie będzie w ogóle działać) były minimalne (glibc, libcap, dbus).

Oczywiście największą zaletą systemd jest jednolitość. Skrypty dla Init.d często były specyficzne dla dystrybucji i mogły powodować problemy jeśli chciało się je przystosować do obsługi innych dystrybucji (skrypty uruchomienia dziedziczą wszystkie problemy konsoli).

Ale systemd to nie tylko jednolity desktop, ale też serwery. O ile tak uruchamianie systemu nie odbywa się zbyt często (a przynajmniej taki jest cel), to całkowity czas kiedy serwer nie działa powinien być jak najmniejszy. A systemd jest szybki. Szybki restart czy zimny start jak najbardziej przemawiają do administratorów.

Zupełnie inaczej sytuacja ma się w chmurze i przy masowej wirtualizacji. Możliwość szybkiego startu setek lub nawet tysięcy instancji może oznaczać konkretne oszczędności, lub większy zysk. Dlatego RedHat stara się wprowadzić systemd do swoich serwerowych produktów.

Podsumowanie

IT w miejscu nie stoi i ciągle się rozwija. Nowe technologie, nowe problemy, nowe wyzwania. Linux też ciągle rozwija się aby sprostać tym wymaganiom. Nie jest więc niczym szczególnie niepokojącym, że ciągle trwa zdrowa dyskusja nad założeniami przyjmowanymi w przeszłości, ani w tym, że ciągle powstają nowe odpowiedzi na stare pytania które nabrały nowych znaczeń.

Nowoczesny Linux nie zdradził też w żaden sposób filozofii Unixa. Ta w końcu jest na tyle uniwersalna i ponadczasowa, że przetrwa wszystko inne ;) 

linux oprogramowanie inne

Komentarze

0 nowych
tfl   8 #1 08.02.2013 15:32

Masz chlopie problem z tymi "ął". Zwracali uwage, warto by sie nauczyc w koncu.


omg drógi?!

a co do tresci... w koncu zdaje sie zawierac cos wiecej poza emocjonalnymi sentencjami

Autor edytował komentarz.
kwpolska   6 #2 08.02.2013 16:24

> Tak samo developerzy SystemD starają się aby jego "twarde" (czyli takie bez których SystemD nie będzie w ogóle działać) były minimalne (glibc, libcap, dbus).

twarde co?

a pisownia oficjalna jest “systemd”.

przemo_li   11 #3 08.02.2013 17:00

@tfl
Naprawione.
Naprawione.
Dziękuję.
@kwpolska
twarde wymagania
Poprawione. Dziękuję.

Ave5   8 #4 08.02.2013 20:21

@ tfl

Z kolei Ty zjadłeś cztery 'ę', dwa 'ć', dwa 'ń', dwa 'ś' i niewłaściwie użyłeś 'sentencjami' jakby znaczyło to, co angielskie 'sentences'.

  #5 08.02.2013 21:14

1. Teza: /usr na osobnej partycji dysku to bezpieczeństwo i szybkość dostępu oraz łatwość wykonywania kopi zapasowych wybranych danych.

Można się kłócić, że w dobie komputerów z 4TB dyskami, 4GHz procesorami i 64GB RAM po co dzielić dane. Połączyć je w całość z resztą partycji systemowych i zapisać na dysku SSD, który pomieści system i liczne programy zapewniając szybkość o której nawet dyski SCSI mogą pomażyć. Lecz tu dochodzi kwestia obciążalności dysku, którą częściowo omija tworzenie macierzy RAID oraz rozproszona alokacja danych wyrównując ilość cykli zapisu i odczytu.
Pomimo zmian technologi dyski twarde składają się z talerzy awaryjność pewnych sektorów jest statystycznie większa, prędkość odczytu i zapisu też jest podyktowana prawami fizyki więc taki nośnik można z mapować by zmaksymalizować bezpieczeństwo i prędkość zapisu i odczytu danych (do tego mogą służyć właśnie wydzielone partycje).
Dyski SSD to inny problem technologiczny. Kości pamięci stosowane w tych napędach są pomimo dużych prędkości odczytu i zapisu narażone na uszkodzenie ze względu na limit nadpisania komórek. Naukowcy opracowali wiele algorytmów optymalizacji równomiernego zużywania komórek lecz nadal występują problemy z przedwczesnym uszkodzeniem pamięci w tego typu dysków.

Wniosek:
Przez mądrą politykę podziału dysków na partycje można zwiększyć żywotność, prędkość odczytu i zapisu danych oraz wspomóc rozproszoną alokacje danych. Pewne katalogi w systemie są bardziej statyczne i dane w nich zmieniają się sporadycznie inne znów odwrotnie co owocuje koniecznością optymalizacji miejsca i zużycia powierzchni dysków (patrz założenia dla systemu plików zfs). Dlatego też partycje pomagają wykorzystać cały potencjał sprzętu. Problemem jest automatyzacja i optymalizacja procesów inicjujących system oraz mechanizmy nimi sterującymi (np. skopany udev).

2. Fakt programy Kit, Udisk, są nie przeznaczone dla powłoki. Nie da się prosto sterować tymi usługami (zasada KISS stosowana w UNIX) co podkreśliłeś w opisie. Automatyzacja dla zwykłych użytkowników psuje prostotę użytkowania i programowania usług zaawansowanym administratorom i programistom. Dla wielu starych użytkowników systemów UNIX wykrywania i montowania automatycznego mogło by nie być, wystarczy dobra dokumentacja, prosty mechanizm konfiguracji sprzętu i skrypt automatyzujący działanie czyli systemd.

3. Systemd ma swoje wady dlatego pewna grupa osób położyła nacisk na wykorzystanie udev w systemie Linux, lecz to nie znaczy że odchodzi on w zapomnienie. Nadal uważam, że wiele dystrybucji niekomercyjnych wróci do korzeni i prostoty systemów UNIX.

tfl   8 #6 08.02.2013 21:41

@Ave5

co do ę,ć,ń i innymi polskimi znakami diakrytycznymi - w komentarzach nie uzywam ich swiadomie. Nacisk na swiadomie. Co do sentencji... eeee ????? ze sie tak wyraze. Uzylem tego slowa w slownikowym znaczeniu. Od razu uprzadzam bystre uwagi - slownik jezyka polskiego. Podpierajac sie definicja zaczerpnieta z tego slownika smiem zauwazyc, ze uzylem go wlasciwie.

przemo_li   11 #7 08.02.2013 23:34

@X
Ani ja ani eimi nigdzie nie piszemy od "/usr na oddzielnych dyskach: stosować czy nie?".

Spór idzie o "/usr/" i "/usr/local". Taki podział jest po prostu nielogiczny. I nie chodzi o to gdzie te foldery się fizycznie znajdują (dysk, partycja, replika w rozproszonym systemie plików na 30 dyskach...), ale o podział na 2 części jednego folderu.

Podział, którego jedynym powodem był techniczny limit w 70 latach.

2.Kit i Udisk nie da się prosto sterować z powłoki ALE spokojnie można napisać programy wrappery które będą komunikowały się za nas (używając dbus-send lub całej gamy innych programów). Problem rozwiązany.

3. Trend idzie w drugą stronę. Adopcja systemd jest coraz lepsza. A dzięki obsłudze całego spektrum urządzeń (od embbeded do serwerów), systemd praktycznie zagwarantował sobie wygraną.

@tfl
"Świadomie" zakłada znajomość potencjalnych konsekwencji i/lub chęć osiągnięcia jakiegoś celu.
Ja braku polskich literek nie zauważyłem dopóki Ave5 o tym nie wspomniał :) Coś się nie udało... Ach zapewne to że ąę nie jest potrzebne do zrozumienia, a ludzki mózg radzi sobie bez ozdóbek.

Dobra ale to temat rzeka. Uciekaj z mojego bloga na swój jak chcesz o tym pisać.

  #8 09.02.2013 10:55

@przemo_li
Obecnie dąży się do konsolidacji partycji systemowych bo łatwiej jest pisać aplikacje automatyzujące pewne elementy systemu. Tak jak w Windows ;) Wszystko ma być w jednym miejscu a podział na /usr i /usr/local już dawno jest porzucany nawet w standardowych Uniksach nie tylko w Linuksie. FHS i nawet POSIX jest implementowany wybiórczo podyktowane jest to tym, że specyfikacja jest "OUT DATED" a niema komu usiąść i napisać uwspółcześnionej wersji bo każdy chce po swojemu :D Windows jest bardziej POSIX niż Linuksy obecnie co było kilka lat temu w jednym z raportów (zapewe nie wiele w tej sprawie się zmieniło pomimo wydania Windows 2012). Wracając do specyfikacji FHS można wysunąć wniosek, że ciągły rozwój nowych funkcjonalności zapomniał o planowaniu. Na razie to działa lecz pewnie padnie jak X Windows System i będzie zastępowany czymś nowszym np. Wayland pomimo słabszych podstaw.

tfl   8 #9 09.02.2013 11:38

@przemo_li

nie wiem co dla ciebie "swiadomie" zaklada, a co sciaga. Dla mnie "swiadomie" oznacza "zdawanie sobie z czegos sprawy". A ja zdaje sobie sprawe, ze piszac bez polskich znakow diakrytycznych popelniam blad. Niestety nie ogarniam co dalej napisales, poza ostatnim zdaniem. Skomentuje to tak - raczej mnie nie zmusisz...

przemo_li   11 #10 09.02.2013 12:28

@X
MS nie dostarcza warstwy kompatybilności POSIX we wszystkich odmianach "konsumenckiego" Windowsa. Chyba tylko najlepszy domowy i 2 biznesowe mają POSIX domyślnie, i wszystkie serwerowe (Win7, nie wiem jak stoi sprawa z Win8).

I dalej część zawartości /usr możesz mieć na dysku A i inną na dysku B (lub partycjach, replikach, whatever). To LOGICZNY PODZIAŁ odchodzi w niepamięć. Fizyczny dalej jest dowolny.

@tfl
Trolluj/oftopuj/marudź dalej. Who cares?

tfl   8 #11 09.02.2013 13:04

@przemo_li

a to nie bylo czasem tak, ze ty sie wtraciles w rozmowe, ktora ciebie nie dotyczyla? Wiec zastosuj swoje pozal sie boze rady sam.

przemo_li   11 #12 09.02.2013 13:22

3 zbędne komentarze pod moim wpisem. Idź machać szabelką gdzie indziej.

  #13 15.02.2013 22:15

Cichaj Liberkowski bo nam cała Mogielnica w ogniu stanie.