Forum Debian Users Gang

whiteman8 napisał(-a):

Są tu osoby, które wcześniej używały systemd zanim przesiadły się na dystrybucje bez systemd? Czy to prawda, że wiele rzeczy które powinien ogarniać porządny init openrc umie czy może się zdarzyć że openrc zacznie mnie ograniczać? Z tego co piszą na gentoo wiki openrc wspiera cgroups, user services itp rzeczy

Tak, korzystałem z openrc na Debianie Sidzie ale lat temu to było może z ~10. Miał swoje plusy i minusy, na pewno był szybszy niż sysv i zastępował sysv (i częściowo systemd).
Tyle, że jak mi w sidzie schrzanili dźwięk a nie chciało mi się bawić w cofanie paczek to poszedłem na Ubuntu LTS na okres chyba dwóch wydań, a potem finalnie na Debiana Stable z systemd i tak sobie korzystam już ładnych kilka lat.

whiteman8 napisał(-a):

Najbardziej absurdalnym przykładem jest run0, który próbuje nieudolnie naśladować sudo.

W Debianie -> aktualnie systemd z tym run0 jest w sidzie. Z ciekawości sprawdzę w ciągu kilku dni, jakoś cudem taka niespodzianka mi umknęła. Do stable jak nie wejdzie do 13 to na pewno do 14.
Nie da się tego wyłączyć? Lub skonfigurować jak sudo? XD

whiteman8 napisał(-a):

Inna rzecz, która mi się nie podoba to to, że systemd próbuje integrować zbyt wiele rzeczy naraz i wprowadza swoje niepotrzebne moim zdaniem funkcjonalnosci typu http server dla journala. Binarne logi też niezbyt mi się podobają. No i ogólnie wolę mieć chyba tradycyjnie crona, sysklogd itd. niż wszystko w jednej paczce.

No nie do końca tak jest. Według mnie, jeśli jesteś ogarniętem sysadminem to stawiasz system od zera. Tylko że czasami niektórych zależności nie da się uniknąć:
https://forum.dug.net.pl/viewtopic.php?pid=336020#p336020
Dwa systemy i dwa różne podejścia XD wydaje mi się że większość problemów pochodzi po prostu ze złej, domyślnej konfiguracji w Ubuntu pochodnych (bo samo LTS do 22.04 sprawdzało się ok).
Ja np z network managera korzystam bo u mnie się sprawdza, paczek z "systemd" w nazwie mam ze 3 (systemd, systemd-sysv i systemd-timesyncd) i nigdy problemów nie miałem. U mnie żadnych dodatków w postaci networkd, netplanów i innych bzdetów po prostu nie ma bo - jeszcze - się da. Raz czy dwa razy jakiś tam zgrzyt z montowaniem partycji miałem ale doszedłem o co chodzi i tyle.
Systemd ma swoje plusy bo zamiast pamiętać o konfiguracji 15 innych paczek to robisz wszystko w jednym. Dopóki w Debianie Stable, Archu i Gentoo będą mieli w miarę rozsądne podejście to nie ma czego się obawiać. Problem będzie jak systemd zacznie wymuszać ich własne narzędzia do np konfiguracji sieci itd. Jak tego systemd wprowadzali do użytku to było dużo płaczu, lamentu i zgrzytu i co, i taki zły wcale nie jest XD

morfik napisał(-a):

Nie tyle "jedynie słuszny" co wygodny — cała masa ludzi przestała pracować nad innymi projektami, które mają swoje ograniczenia, przez co przepaść między systemd a tymi projektami jeszcze bardziej się pogłębiła przez ostatnią dekadę. Czyli wszedł systemd ze swoimi rozwiązaniami, ludzie zobaczyli, że to w sumie użyteczne, więc po co tworzyć inne rozwiązania skoro są te.

Rozumiem że integracja, wygoda ale pomyśl, co jeśli dane rozwiązanie oferowane przez systemd okaże się albo niewystarczające, bądź będzie coś robić nie tak jak powinno i nic nie będzie się dało na to poradzić. Nie wszystko wyłączysz flagami na etapie kompilacji tak jak w Gentoo. Na dystrybucjach opartych na paczkach jesteś właściwie zdany na łaskę maintainerów. Co w takiej sytuacji? systemctl mask będziesz robić? Według mnie prościej postawić te usługi co trzeba niż wyłączać to co niepotrzebne w systemd. Można też postawić drugą usługę obok tej oferowanej przez systemd, tylko nawet jeśli uda ci się wyłączyć tę systemd to nadal marnujesz miejsce na dysku. Przy ograniczonych zasobach sprzętowych to może mieć znaczenie.

Skąd pewność że wszystkie projekty systemd-cośtam są dopracowane a nie zrobione na zasadzie że może się przyda? Czy pchanie wszystkiego do jednego wora jakim jest systemd nie doprowadzi do takiego podejścia? Mi się wydaje że każdy program w systemie powinien robić jedną rzecz a dobrze i oferować jakiś prosty input/output, niekoniecznie musi być to plajntekst, może to być też unix socket. Takie podejście według mnie bardziej sprzyja dobrym praktykom jeśli chodzi o rozwój oprogramowania.

Od konfiguracji całego systemu są takie narzędzia jak Chef, Salt, Ansible, tym nie powinien się zajmować init.

morfik napisał(-a):

Sudo miało problemy od początku swojego istnienia i każdy kto używał "su" (i kto dalej używa, np. ja. xD) nigdy tak naprawdę nie korzystał z sudo, bo po co?

Chyba kogoś ostro porąbało żeby run0, który ma pełnić podobną funkcję co sudo defaultował do gui i do tego zmieniał kolor terminala na czerwony. Kolejne traktowanie użytkowników linuksa jak debili, podobnie jak hostnamectl czy localectl jakby nie można było manualnie wyedytować /etc/hostname. Znowu, od takich rzeczy są dedykowane narzędzia do automatyzacji, zarządzania konfiguracją. Moje podejście do sysadminki jest takie że każdy serwis ma robić jedną rzecz a porządnie.

Co do sudo to przymierzam się do wypróbowania alternatywy w postaci narzędzia doas.

morfik napisał(-a):

Nie oznacza to, że na maszynie docelowej będziesz miał oprogramowanie pokroju apache, który będzie nasłuchiwał zapytań www.

Co gdy to oprogramowanie przestanie spełniać twoje wymagania? Jak wtedy wyeksportujesz journala po http nie tracąc funkcjonalności.

s/journal i http/cokolwiek z systemd zależne od rozwiązań oferowanych przez systemd/