Systemd domyślnym init dla linuksowych architektur
Domyślną implementacją init dla linuksowych architektur Debiana Jessie będzie systemd. Dyskusja na temat wyboru trwała długo i była kontrowersyjna, ostateczną decyzję podjął Komitet Techniczny.Do wydania 7.0 Wheezy włącznie domyślnym demonem init w Debianie jest sysvinit — stary, sekwencyjny model uruchamiania systemu w stylu System V. Od jakiegoś czasu świat Linuksa wkracza w nowy model, oparty na zdarzeniach (zob. publikację sprzed 4,5 roku Przyszłość mechanizmu startowego w Debianie). Wśród obecnie najpopularniejszych implementacji init wykorzystujących ten właśnie model są upstart oraz systemd.
Od kilku miesięcy wśród Deweloperów Debiana trwała gorąca — nierzadko zbyt gorąca — dyskusja, który projekt powinien zastąpić wysłużony sysvinit oraz kiedy — czy już w Debianie 8.0 Jessie, czy później. Ostatecznie ciężar rozstrzygnięcia sporu przejąć musiał Komitet Techniczny, specjalne ciało Projektu Debian powołane do podejmowania ostatecznych decyzji. Po nie mniej gorącej dyskusji, Bdale Garbee, przewodniczący komitetu, po kolejnym remisie między upstartem a systemd skorzystał z prawa do decydującego głosu by rozstrzygnąć głosowanie na rzecz tego drugiego: dla linuksowych architektur w Debianie 8.0 Jessie domyślną implementacją init będzie systemd.
Skąd kontrowersje wokół wyboru?
Systemd, nowa domyślna implementacja init Debiana GNU/Linux, nie przez wszystkich jest pochwalany. Jakkolwiek posiada on wiele zalet — jest szybki, obsługuje zależności podczas uruchamiania, posiada wsteczną kompatybilność, jest aktywnie rozwijany — wiele osób zwraca też uwagę na jego wady:
- skomplikowanie demona — pełni on nie tylko funkcję init, ale zajmuje się również innymi zadaniami, co rodzi obawy o bezpieczeństwo i stabilność,
- jest skoncentrowany wyłącznie na Linuksie — wykorzystuje pewne funkcje obecne tylko w tym systemie operacyjnym, deweloperów nawet nie interesuje uruchomienie systemd na innych systemach uniksowych (stąd decyzja o zmianie nie dotyczy nielinuksowych architektur Debiana),
- powiązanie z innymi projektami, m.in. udev, GNOME (poprzez logind) — legitymizacja systemd, zwłaszcza przez tak wpływową dystrybucję jaką jest Debian, może skończyć się dla świata GNU/Linux swoistym vendor lock-in.
Zatwardziali przeciwnicy systemd nie muszą się jednak przesadnie martwić: pozostałe implementacje init nadal będą dostępne w Debianie i będzie można z nich korzystać podobnie jak obecnie.
Dodany: 12 lut 2014 o 13:06
przez: azhag
Komentarze (RSS):
Szkoda. Wszystko idzie w kierunku tego, że systemd ma powoli stać się jedyną, słuszną opcją (one true way). To nigdy nie wróży zbyt dobrze.
Lennart Poettering jest autorem pulseaudio. Udało mu się dokonać czegoś co nikt jeszcze nie dokonał, czyli zepsuć dźwięk pod systemem Linux. O czym wielu użytkowników się przekonało. W końcu wpadł na genialny pomysł stworzenia własnego inita, który ma być kombajnem do wszystkiego, praktycznie jak pulseaudio. A że historia lubi się powtarzać, więc…
Dziwne, że nie wpadł jeszcze na stworzenie własnego systemu operacyjnego.
td;dr
Systemd ssie, bo czego się jego autor nie czepi to i tak spier...
Dziwne, że nie wpadł jeszcze na stworzenie własnego systemu operacyjnego.
td;dr
Systemd ssie, bo czego się jego autor nie czepi to i tak spier...
A jaka jest alternatywa? Upstart z CLA i fochami pewnego bufona?
Inne projekty raczej nie wchodziły w grę.
Inne projekty raczej nie wchodziły w grę.
OpenRC jest naprawdę świetne i co najważniejsze stanowi ewolucje a nie rewolucje.
Też miałem nadzieje że wybiorą OpenRC ( chociażby dla utrzymania zgodności z nielinuksowymi architekturami).
@Mati75 Masz rację. "Po owocach ich poznacie" z tym, że pulseaudio to pierwszej jakości zgniłek.
PS. systemd SSIE ( logi w postaci binarnej.. it's not a bug it's a feature)
@Mati75 Masz rację. "Po owocach ich poznacie" z tym, że pulseaudio to pierwszej jakości zgniłek.
PS. systemd SSIE ( logi w postaci binarnej.. it's not a bug it's a feature)
Cóż, żyję trzeci tydzień z systemd na Jessie, do tej pory jeszcze nic się nie wywaliło, ale mam serdecznie dość radosnej pełnej losowości w kolejności startu usług i montowania systemów plików. Nawet z readahead wstaje dłużej niż na sysvinit.
Panie Poettering, weź sobie może do serca starą UNIX'ową zasadę: "Make each program do one thing well."
[w tym miejscu wyobraź sobie zdjęcie smutnego kociaka]
Panie Poettering, weź sobie może do serca starą UNIX'ową zasadę: "Make each program do one thing well."
[w tym miejscu wyobraź sobie zdjęcie smutnego kociaka]
Tu trochę na ochłodę:
http://www.vitavonni.de/blog/201402/2014021101-debian-chooses-systemd-as-default-init.html
tl;dr:
Systemd to ma być domyślny init, a nie jedyny. Sysvinit i openrc nie muszą wylecieć i pewnie nie wylecą. Może Gnome będzie wymagać systemd, ale reszta powinna działać normalnie z innymi.
Z tym końcem świata trzeba jeszcze poczekać.
http://www.vitavonni.de/blog/201402/2014021101-debian-chooses-systemd-as-default-init.html
tl;dr:
Systemd to ma być domyślny init, a nie jedyny. Sysvinit i openrc nie muszą wylecieć i pewnie nie wylecą. Może Gnome będzie wymagać systemd, ale reszta powinna działać normalnie z innymi.
Z tym końcem świata trzeba jeszcze poczekać.
Ależ oczywiście, że inne inity nie wylecą (nawet nie mogą, przecież Debian to nie tylko Linux). Zresztą napisałem o tym.
> Może Gnome będzie wymagać systemd
Już wymaga pakietu systemd, ale nie systemd-init, w którym jest -- tu niespodzianka -- init.
> Może Gnome będzie wymagać systemd
Już wymaga pakietu systemd, ale nie systemd-init, w którym jest -- tu niespodzianka -- init.
Ale komentujący wpadli w jakieś dekadenckie nastroje ;)
@yossarian
Jednym z podstawowych problemów związanych z tą decyzją, była kwestia do jakiego/jakich "systemów rozruchu" będą domyślnie dodawane/wymagane pliki w pakietach.
Wsparcie dla "sysvinit" nie zależnie od wyboru będzie utrzymane na kolejną wersje Debiana.
Tak jak teraz mogłeś sobie we własnym zakresie produkować pliki .service, tak możesz sobie tworzyć pliki dla openrc, jednak szybko utrzymywanie tego stanie się jednym z głównych Twoich zajęć.
Jednym z podstawowych problemów związanych z tą decyzją, była kwestia do jakiego/jakich "systemów rozruchu" będą domyślnie dodawane/wymagane pliki w pakietach.
Wsparcie dla "sysvinit" nie zależnie od wyboru będzie utrzymane na kolejną wersje Debiana.
Tak jak teraz mogłeś sobie we własnym zakresie produkować pliki .service, tak możesz sobie tworzyć pliki dla openrc, jednak szybko utrzymywanie tego stanie się jednym z głównych Twoich zajęć.
@azhag: Ale już do prawidłowego działania np. suspendu przy zamknięciu klapki laptopa sam zainstalowany pakiet systemd nie wystarczy, system musi być uruchomiony na tym inicie.
Chyba się po raz trzeci spróbuję przeprosić z KDE.
Chyba się po raz trzeci spróbuję przeprosić z KDE.
Rany, serio?
Poważnie, przydałoby się, żeby tak wszystkie główne dystrybucje powiedziały deweloperom GNOME, że spartolili i w efekcie usuwają środowisko do czasu, aż ci pójdą po rozum do głowy.
Poważnie, przydałoby się, żeby tak wszystkie główne dystrybucje powiedziały deweloperom GNOME, że spartolili i w efekcie usuwają środowisko do czasu, aż ci pójdą po rozum do głowy.
No i jedną z poruszanych wad systemd, jest to, że "usługa" wcale nie musi się odpalić z konsoli, po prostym skopiowaniu komendy, do basha, z pliku .service.
Poza tym dość szybko, systemd ze swoim limitem "komendy tylko w jednej linii" będzie po prostu paskudny, jak ludzie zaczną produkować jakieś potworki, z 50 linowym skryptem, tylko że bez użycia entera
Poza tym dość szybko, systemd ze swoim limitem "komendy tylko w jednej linii" będzie po prostu paskudny, jak ludzie zaczną produkować jakieś potworki, z 50 linowym skryptem, tylko że bez użycia entera
azhag: Ale co dokładnie spartolili deweloperzy GNOME?
GNOME do zarządza sesją (w skład czego wchodzi obsługa wydarzeń związanych z zarządzaniem energią, słusznie lub nie) wykorzystywało ConsoleKit. ConsoleKit to taki zamiennik utmp (czy rzeczywiście potrzebny, to inna kwestia). ConsoleKit przestało być rozwijane na początku 2012 roku, niemal dwa lata temu (http://cgit.freedesktop.org/ConsoleKit/log/). Funkcjonalnym zamiennikiem ConsoleKit jest logind, który jest częścią systemd i jest aktywnie rozwijany. Deweloperzy GNOME podjęli decyzję, że zamiast używać przestarzałej biblioteki, wolą używać współczesnej biblioteki. Brzmi raczej rozsądnie. Dość jasno przy tym powiedzieli, że GNOME nie wymaga do działania systemd, a określonych interfejsów, które mogą być zapewnione przez dowolny inny system w dowolny inny sposób (https://mail.gnome.org/archives/distributor-list/2012-January/msg00002.html).
Tyle GNOME. Im zależy tylko na konkretnych interfejsach. Można więc było ConsoleKit sforkować; można było nad ConsoleKit przejąć opiekę; można było ConsoleKit aktywnie rozwijać. Można było, ale nikt tego nie zrobił. Nikt, poza logind rozwijanym w ramach systemd. Tak więc logind stało się zamiennikiem ConsoleKit, być moze przede wszystkim z powodu braku konkurencji.
logind do działania wykorzystuje cgroups. cgroups pozwala zarządzać zasobami (np. ograniczać ilość pamięci wykorzystywanej przez grupę procesów), a logind zarządza sesjami użytkowników. Połączenie wydaje się całkiem mądre i pozwala w prosty sposób ograniczać zasoby konkretnym użytkownikom.
systemd również do działania wykorzystuje cgroups. Umożliwia mu to ograniczenie zasobów konkretnym daemonom oraz śledzenie relacji pomiędzy różnymi ich procesami.
Wszystko było dobrze, dopóki nie pojawiły się plany modyfikacji architektury cgroups po stronie kernela. Rzekomo związane z problemami, których nie da się rozwiązać w dotychczasowej architekturze; nie mnie oceniać, czy to prawda. Jedną z najbardziej istotnych zmian jest to, że w nowej architekturze, strukturą cgroups może zarządzać TYLKO JEDEN PROCES. Tak więc nie możemy już mieć systemd zarządzającego cgroups daemonów oraz logind zarządzającego cgroups użytkowników. Ponieważ oba programy są częścią jednego pakietu, ich programiści uznali, że najlepiej aby cgroups były kontrolowane przez systemd, który pełni funkcje init i jest przodkiem wszystkich innych procesów w systemie.
I w ten sposób, w wyniku niefortunnych zbiegów okoliczności, bierności ze strony społeczności oraz nieskoordynowania wysiłków opiekunów różnych elementów połączonego systemu, GNOME do usypiania systemu po zamknięciu pokrywy laptopa wymaga systemd jako PID1.
Warto przy tym dodać, że problem ten (na razie) nie dotyczy Debiana, który — nawet w Sidzie — ma zbyt stare wersje GNOME oraz systemd.
GNOME do zarządza sesją (w skład czego wchodzi obsługa wydarzeń związanych z zarządzaniem energią, słusznie lub nie) wykorzystywało ConsoleKit. ConsoleKit to taki zamiennik utmp (czy rzeczywiście potrzebny, to inna kwestia). ConsoleKit przestało być rozwijane na początku 2012 roku, niemal dwa lata temu (http://cgit.freedesktop.org/ConsoleKit/log/). Funkcjonalnym zamiennikiem ConsoleKit jest logind, który jest częścią systemd i jest aktywnie rozwijany. Deweloperzy GNOME podjęli decyzję, że zamiast używać przestarzałej biblioteki, wolą używać współczesnej biblioteki. Brzmi raczej rozsądnie. Dość jasno przy tym powiedzieli, że GNOME nie wymaga do działania systemd, a określonych interfejsów, które mogą być zapewnione przez dowolny inny system w dowolny inny sposób (https://mail.gnome.org/archives/distributor-list/2012-January/msg00002.html).
Tyle GNOME. Im zależy tylko na konkretnych interfejsach. Można więc było ConsoleKit sforkować; można było nad ConsoleKit przejąć opiekę; można było ConsoleKit aktywnie rozwijać. Można było, ale nikt tego nie zrobił. Nikt, poza logind rozwijanym w ramach systemd. Tak więc logind stało się zamiennikiem ConsoleKit, być moze przede wszystkim z powodu braku konkurencji.
logind do działania wykorzystuje cgroups. cgroups pozwala zarządzać zasobami (np. ograniczać ilość pamięci wykorzystywanej przez grupę procesów), a logind zarządza sesjami użytkowników. Połączenie wydaje się całkiem mądre i pozwala w prosty sposób ograniczać zasoby konkretnym użytkownikom.
systemd również do działania wykorzystuje cgroups. Umożliwia mu to ograniczenie zasobów konkretnym daemonom oraz śledzenie relacji pomiędzy różnymi ich procesami.
Wszystko było dobrze, dopóki nie pojawiły się plany modyfikacji architektury cgroups po stronie kernela. Rzekomo związane z problemami, których nie da się rozwiązać w dotychczasowej architekturze; nie mnie oceniać, czy to prawda. Jedną z najbardziej istotnych zmian jest to, że w nowej architekturze, strukturą cgroups może zarządzać TYLKO JEDEN PROCES. Tak więc nie możemy już mieć systemd zarządzającego cgroups daemonów oraz logind zarządzającego cgroups użytkowników. Ponieważ oba programy są częścią jednego pakietu, ich programiści uznali, że najlepiej aby cgroups były kontrolowane przez systemd, który pełni funkcje init i jest przodkiem wszystkich innych procesów w systemie.
I w ten sposób, w wyniku niefortunnych zbiegów okoliczności, bierności ze strony społeczności oraz nieskoordynowania wysiłków opiekunów różnych elementów połączonego systemu, GNOME do usypiania systemu po zamknięciu pokrywy laptopa wymaga systemd jako PID1.
Warto przy tym dodać, że problem ten (na razie) nie dotyczy Debiana, który — nawet w Sidzie — ma zbyt stare wersje GNOME oraz systemd.
@Minio: Dzięki za wyczerpujące wyjaśnienie, ale śmiem się nie zgodzić z Twoim stwierdzeniem że ten problem nie dotyczy jeszcze Debiana, gdyż owszem, wersja GNOME w Jessie na dzień dzisiejszy już tego wymaga. Jak zaznaczyłem w założonym przez siebie wątku o systemd, GNOME 3.8 nie chciał za żadne skarby bez systemd jako PID 1 wykonać uśpienia systemu na akcję zamknięcia pokrywy laptopa ani też na sygnał otrzymany przez ThinkPadową kombinację klawiszy FN+F4, co stało się dla mnie jedynym powodem dla którego postanowiłem temu potworkowi dać jeszcze jedną szansę.
Minio: OK, najwyraźniej sytuacja nie wynikła z ich winy. Niemniej przydałoby się coś z tym zrobić.
(inna sprawa, że ekipa GNOME miewa dziwne pomysły z usuwaniem, dodawaniem i zmienianiem różnych rzeczy)
(inna sprawa, że ekipa GNOME miewa dziwne pomysły z usuwaniem, dodawaniem i zmienianiem różnych rzeczy)
azhag: przydałoby się. Tylko co, i kto to zrobi?
systemd działa i rozwiązuje określone problemy (zarówno z punktu widzenia administratorów, jak i programistów środowisk graficznych). Tylko tyle i aż tyle. Dodatkowo jego opiekunowie są otwarci na współpracę i całkiem rozsądni; tak, mają dość precyzyjnie określoną wizję swojego projektu, dzięki czemu/przez co niektóre propozycje zmian spotykają się z odpowiedzią odmowną. Ale ostatecznie wszystko sprowadza się do tego, że ludzie, którzy wykonują rzeczywistą pracę są zadowoleni z systemd i włączają go do swoich projektów. Ludzie, którzy narzekają na systemd, jedynie wyrażają swoje opinie na forach/listach dyskusyjnych/w komentarzach.
systemd działa i rozwiązuje określone problemy (zarówno z punktu widzenia administratorów, jak i programistów środowisk graficznych). Tylko tyle i aż tyle. Dodatkowo jego opiekunowie są otwarci na współpracę i całkiem rozsądni; tak, mają dość precyzyjnie określoną wizję swojego projektu, dzięki czemu/przez co niektóre propozycje zmian spotykają się z odpowiedzią odmowną. Ale ostatecznie wszystko sprowadza się do tego, że ludzie, którzy wykonują rzeczywistą pracę są zadowoleni z systemd i włączają go do swoich projektów. Ludzie, którzy narzekają na systemd, jedynie wyrażają swoje opinie na forach/listach dyskusyjnych/w komentarzach.
inna sprawa ze to gnome smierdzi majkrosoftowa mysla "intelektualna"
@Minio: Dzięki za naświetlenie sprawy... szkoda, że nikt tego wcześniej nie zrobił, nie omówił... bo mimo wszystko systemd napawa mnie pewnym niepokojem, a jego ewolucja w kombajn od wielu rzeczy powoduje, że z czasem może stać się godnym następcą X-ów, czyli kluczowym(Xy co prawda nie wszędzie są kluczowe), a zarazem wadliwym, pełnym bugów oraz praktycznie niemożliwym do naprawienia elementem systemu... nie znam się co prawda na tym, ale Lennart miał już 2 piękne projekty w swojej karierze które są kombajnami i raczą nas swoją obecnością bardzo często na forum, rzecz jasna mam na myśli NetworkManager i PulseAudio i patrząc na całokształt mimo wszystko nie napawa mnie to optymizmem... Osobiście wolałbym, by Debian (a tym samym pewnie Ubuntu z przyległościami też) przeszedł na OpenRC, wtedy deweloperzy Debiana, Gentoo i Ubuntu stworzyli by całkiem sensowną alternatywę wobec Systemd, a tak pewnie OpenRC dalej będzie rozwijane, ale raczej zostanie w podziemiach, a my możemy zostać z tykającą w rękach bombą zegarową...
Obym się mylił/moje niepokoje były bezpodstawne
Obym się mylił/moje niepokoje były bezpodstawne
//teraz sprawdziłem i jednak się myliłem - NetworManager to jednak nie jest dzieło Lennarta
Jeśli chodzi o OpenRC to raczej przeważała opinia, że projekt jest zbyt niedojrzały na domyślny init dla Jessie (zresztą dopiero co wszedł tylko do experimental). Ale kto wie, może dla Jessie+1?
Ostatnio nawet PA działa całkiem znośnie. Poczekajmy jak systemd będzie sprawdzał się w praktyce na większą skalę.
Może to jeszcze nie koniec świata i „jakoś to będzie”.
Może to jeszcze nie koniec świata i „jakoś to będzie”.
http://www.dobreprogramy.pl/systemd-209-czyli-najpotezniejszy-demon-inicjalizacji-Linuksa-zastepuje-co-moze,News,52407.html
@Minio:
Systemd wymaga rozwalenia ("przystosowania") wielu elementów systemu - co oznacza nowe dziury w zakresie bezpieczeństwa. W zamian nie daje NIC. Ani nie jest szybszy, ani też nie rozwiązuje "problemu" sysvinit, czyli konieczności używania "niezrozumiałych i trudnych" skryptów w init. (Zapewne były "trudne" dla autora systemd). Częściowo zastępuje funkcjonalność skryptów w postaci gotowych do użycia opcji - tyle że jak w którymś momencie, w kolejnej wersji implementacja opcji się zmieni, to nic nie da się z tym zrobić (bez patchowania) - trzeba i tak napisać skrypt.
Binarne logi to nie tylko jakiś kiepski żart - do zdiagnozowania padniętego systemu mamy używać MS.events.asp? - to jest debilny pomysł, wbrew wszystkim przyjętym zasadom.
OpenRC czy nawet runit są tak samo szybke jak (albo szybsze niż) systemd, ale nie rozwalają istniejącego systemu i są gotowe do użycia teraz. systemd będzie miał jeszcze setki problemów i dziur - przez lata.
Już pomijam, że Debian tym samym powinien zrezygnować z nazwy Universal Operating System - bo już nie jest (BSD i HURD nie hula z systemd).
Po co to wszystko? Jak nie wiadomo o co chodzi, to wiadomo o co chodzi - o pieniądze. Z czasem (już niedługo) nie da się użyć innego systemu init bez rekompilacji kernela i masy ważnych bibliotek - systemd stanie się jedynym słusznym, a autor zarobi fortunę na supporcie. Niech by tam sobie zarabiał mam to gdzieś - ale dzięki poparciu RedHata i z powodu GNOME mamy kibel na jednym z najniższych poziomów systemu operacyjnego.
pozdrawiam.
tomazzi
Systemd wymaga rozwalenia ("przystosowania") wielu elementów systemu - co oznacza nowe dziury w zakresie bezpieczeństwa. W zamian nie daje NIC. Ani nie jest szybszy, ani też nie rozwiązuje "problemu" sysvinit, czyli konieczności używania "niezrozumiałych i trudnych" skryptów w init. (Zapewne były "trudne" dla autora systemd). Częściowo zastępuje funkcjonalność skryptów w postaci gotowych do użycia opcji - tyle że jak w którymś momencie, w kolejnej wersji implementacja opcji się zmieni, to nic nie da się z tym zrobić (bez patchowania) - trzeba i tak napisać skrypt.
Binarne logi to nie tylko jakiś kiepski żart - do zdiagnozowania padniętego systemu mamy używać MS.events.asp? - to jest debilny pomysł, wbrew wszystkim przyjętym zasadom.
OpenRC czy nawet runit są tak samo szybke jak (albo szybsze niż) systemd, ale nie rozwalają istniejącego systemu i są gotowe do użycia teraz. systemd będzie miał jeszcze setki problemów i dziur - przez lata.
Już pomijam, że Debian tym samym powinien zrezygnować z nazwy Universal Operating System - bo już nie jest (BSD i HURD nie hula z systemd).
Po co to wszystko? Jak nie wiadomo o co chodzi, to wiadomo o co chodzi - o pieniądze. Z czasem (już niedługo) nie da się użyć innego systemu init bez rekompilacji kernela i masy ważnych bibliotek - systemd stanie się jedynym słusznym, a autor zarobi fortunę na supporcie. Niech by tam sobie zarabiał mam to gdzieś - ale dzięki poparciu RedHata i z powodu GNOME mamy kibel na jednym z najniższych poziomów systemu operacyjnego.
pozdrawiam.
tomazzi
>Gość (0d8f2466ef)
Po co to wszystko? Jak nie wiadomo o co chodzi, to wiadomo o co chodzi - o pieniądze. Z czasem (już niedługo) nie da się użyć innego systemu init bez rekompilacji kernela i masy ważnych bibliotek - systemd stanie się jedynym słusznym, a autor zarobi fortunę na supporcie. Niech by tam sobie zarabiał mam to gdzieś - ale dzięki poparciu RedHata i z powodu GNOME mamy kibel na jednym z najniższych poziomów systemu operacyjnego.
I to jest jedyny, rzeczywisty powód dla którego systemd został przeforsowany. Dla większości użytkowników oznacza to mniejsze lub większe problemy na ich stacjach roboczych itp. zabawkach. Dla administratora dużego systemu np. pocztowego oznacza to konieczność zaufania produktowi, którego poziom bezpieczeństwa zostanie obniżony lub pożegnanie z Debianem. Do świadomości zwolenników systemd ten argument nigdy nie trafi. Ci na dole będą bydlęcymi oczkami wpatrywali się w nowinkę i powtarzali że trzeba iść z duchem czasu, a CI na górze będą potakiwać i przy okazji zgarniać kasę. ;)
Cała impreza cuchnie komerchą z daleka. ;)
Po co to wszystko? Jak nie wiadomo o co chodzi, to wiadomo o co chodzi - o pieniądze. Z czasem (już niedługo) nie da się użyć innego systemu init bez rekompilacji kernela i masy ważnych bibliotek - systemd stanie się jedynym słusznym, a autor zarobi fortunę na supporcie. Niech by tam sobie zarabiał mam to gdzieś - ale dzięki poparciu RedHata i z powodu GNOME mamy kibel na jednym z najniższych poziomów systemu operacyjnego.
I to jest jedyny, rzeczywisty powód dla którego systemd został przeforsowany. Dla większości użytkowników oznacza to mniejsze lub większe problemy na ich stacjach roboczych itp. zabawkach. Dla administratora dużego systemu np. pocztowego oznacza to konieczność zaufania produktowi, którego poziom bezpieczeństwa zostanie obniżony lub pożegnanie z Debianem. Do świadomości zwolenników systemd ten argument nigdy nie trafi. Ci na dole będą bydlęcymi oczkami wpatrywali się w nowinkę i powtarzali że trzeba iść z duchem czasu, a CI na górze będą potakiwać i przy okazji zgarniać kasę. ;)
Cała impreza cuchnie komerchą z daleka. ;)
Dzięki za komentarz (Gość (77575fa313))
Jako że stabilność Debiana decyduje w istotnym zakesie o przydatności tego systemu dla moich potrzeb, jakiś czas temu zdecydowałem się zgłosić kilka błędów krytycznych w systemd, ([systemd-devel] BUG: several bugs in core/main.c (v218)) które niestety nie mają dobrego polskiego tłumaczenia, np:
1. non-reentrant signal handler == crash (Lennart jest kretynem, któty nie potrafi zajarzyć dlaczego handler sygnałów systemowych musi być "re-entrant" & async-signal-safe (nieprzatłumaczlane afain)
2. systemd nieprawidłowo instaluje handlery sygnałów - nie sparawdza czy operacja wogóle się powiodła - możliwy totalny crash bez żadnego ostrzeżenia :)
...i to tylko "między innymi" - takich bugów są setki w tym gównianym sofcie.
pozdrawiam.
tomazzi
Jako że stabilność Debiana decyduje w istotnym zakesie o przydatności tego systemu dla moich potrzeb, jakiś czas temu zdecydowałem się zgłosić kilka błędów krytycznych w systemd, ([systemd-devel] BUG: several bugs in core/main.c (v218)) które niestety nie mają dobrego polskiego tłumaczenia, np:
1. non-reentrant signal handler == crash (Lennart jest kretynem, któty nie potrafi zajarzyć dlaczego handler sygnałów systemowych musi być "re-entrant" & async-signal-safe (nieprzatłumaczlane afain)
2. systemd nieprawidłowo instaluje handlery sygnałów - nie sparawdza czy operacja wogóle się powiodła - możliwy totalny crash bez żadnego ostrzeżenia :)
...i to tylko "między innymi" - takich bugów są setki w tym gównianym sofcie.
pozdrawiam.
tomazzi