Devuan Daedalus 5.0

Debian

Megjelent a systemd-mentesített Debian fork, a Devuan legújabb "stable", 5.0-s kiadása. Főbb jellemzői:

  • Based on Debian Bookworm (version 12) with Linux kernel 6.1
  • Rootless startx uses libseat1
  • Wayland GUI without elogind

Bejelentés itt.

( peterson v | 2023. 08. 17., cs – 08:20 )

Engem igazán nem vádolhat senki azzal, hogy szeretem a systemd-t, de a kigyomlálása sem megoldás. Ha már (sajnos) úgy alakult, hogy mindennek része ha kell, ha nem, akkor meg kell próbálni megszeretni. Nem könnyű mert zsákfos.

De ha külső csomagokból pakolsz fel dolgokat mert frissebb, jobb, vagy jobb a szaga, az biztosan systemd-re van építve, és elkezdenek törni a csomagok... :(

A Devuan jó, de csak addig amíg kizárólag Devuan repóból építkezel. Az pedig nem minden környezetben lehetséges. (Vagy forrásból fordítgatsz, de az meg önsanyargatás)

"A megoldásra kell koncentrálni nem a problémára."

Nem siránkoztam, és nem is látok benne világvégét.

Csak nem szeretem, mert:
- mindenbe belemászik 
- szűkszavúan, néha értemezhetetlenül logol, néha konkrétan nem mond igazat a logban
- szolgáltatás (újra)indításánál jellemzően csak visszaadja a promtot, mintha minden rendben lenne, de ha megnézem a  státuszt akkor látszik hogy nem tudta elindítani/megállítani. Így arra kényszerít, hogy start/restart/stop után mindig kérjek egy status-t is.
- több dolgot bonyolultabbá tesz

Amiért mégis el tudom fogadni:
- egységesen működnek a szolgáltatás indítások (bonyolult, néha bugos, de egységes)
- sok hozzá az elérhető közösségi info
- egy paranccsal átláthatóan közli, hogy melyik szolgáltatás fut, és melyik nem

De mégis jobban szeretem a sysvinit-et, mert:
- egyszerű
- nem dependel mindenre
- üzembiztos
- ha nem sikerül neki valami, azt vagy megmondja, vagy értelmezhetően logolja

Összességében jobban szeretem az "egytrükkös pónikat" (egyszerű mint a faék, csak egy dologra képes, de arra üzembiztosan), mint a nagy robosztus mindenbe belemászó alrendszereket, mert utóbbinak a soksok képessége sokok bug-fészket rejt.

Ez az én véleményem, nem kell vele egyetérteni. Nekem pedig nem kell szeretnem a systemd-t. De elfogadom a létezését. 

"A megoldásra kell koncentrálni nem a problémára."

persze, ezt nem ugy ertettem, hogy most te sirankozol, hanem hogy 'ment a sirankozas' generalisan miatta.

Amit irsz, az inkabb tunik bugnak. Az javitva lesz.

Ami miatt kell(ett) systemd, az a modern laptop-ok, kisebb mertekben desktop-ok. Mert a user elvarja, hogy amikor jon egy event, a szamitogep reagaljon korrekten. usb, halozat/wifi, sd kartya, bluetooth-os fules: ezeknek flottul mennie kell. sysvinit-tel is megoldhato, csak akkor kulon-kulon kell lekodolni es futtatni az ezeket az event-eket figyelo+lekezelo daemont, ami alapvetoen pazarlas.

szerveren, ahol kvazi minden statikus, nem latom tul sok hasznat a systemd-nek, de gondolom ha ugyis az van a laptopodon is, akkor egyszerubb rogton oda is azt tenni. meg gondolom a rendszergazda neha dugdos ezt-azt a szerverbe is, es akkor jo, hogy nem kell kezzel tokolni.

szerveren, ahol kvazi minden statikus, nem latom tul sok hasznat a systemd-nek, 

Hát én sem. 😆

meg gondolom a rendszergazda neha dugdos ezt-azt a szerverbe is,

Nem.

Különösen nem "ezt-azt" :)

"A megoldásra kell koncentrálni nem a problémára."

Mert a user elvarja, hogy amikor jon egy event, a szamitogep reagaljon korrekten. usb, halozat/wifi, sd kartya, bluetooth-os fules: ezeknek flottul mennie kell

Erre volt az udev. Már a systemd előtt létezett.

Pont ez a baj a systemd-vel, kisgömböcként viselkedik. Egy init rendszernek elsősorban az lenne a dolga, hogy a rendszer illetve a komponensek indítását, leállítását, újraindítását végezze. Az eseménykezelőnek (legyen az bármi) az eseményekre reagálást. A log alrendszernek a logkezelést. A DNS resolvernek a névfeloldást. Nem szerencsés dolog mindezeket - és még fene tudja, miket - egy rendszerbe összehozni. Akkor sem, ha jól működik mind, akkor meg még kevésbé, ha netán bugos.

Régebben ha volt egy tool, ami nem jól működött, viszonylag egyszerű volt lecserélni egy olyanra, ami jobb volt (klasszikus syslog vs. syslog-ng, vs. rsyslog, de ugyanúgy a DNS server, és lehetne sorolni). Ha mindent bekebelez a systemd, akkor ez a lehetőség megszűnik.

Nem ilyen egyszeru ez. Van udev, de mi van, ha bluetooth usb adapter bedugaskor el kellene inditani a blueman-t, es az ugye egy service, tehat valaminek utana felugyelnie kellene (stop/restart/log/...). Vagy a dns resolver esete: ahogy roam-ol a laptop-od kulobozo wifi-k, mobilinternet kozott, elvarod, hogy a dns mindig jol alljon be, de amig pl. a ceges halozatban dnsmasq-olni akarsz, addig mobilneten pl. nem.

Elvarod, hogy low battery eseten governor-t kapcsoljon, meg feldobjon pop-up-ot az arcodba.

Persze lehet ezt kulon-kulon service-ben csinalni, de akkor meg az szemetelne ossze a processzlistad. :)

Az udev nem rossz, sot. En is imadtam, mert olyan egyszeru, felhasznalobarat volt, amennyire kellett. De vegyuk eszre, limitaltak a lehetosegei, mind megfigyelt event-ek, mind erre reakciokent adhato action-ok tekinteteben. A systemd tobbmindenre tud reagalni, es sokkal szerteagazobban.

En is utalom a systemd-t, mert imho ahhoz kepest, amire az atlagember hasznalna, tulbonyolitott. Avagy az emberek 90%-a a feature-ei 10%-t hasznalja, de sajnos nem figyeltek oda, hogy ez a 10% faek egyszeruseggel elerheto, kezelheto legyen. Ha mar pl. csinaltak volna egy /etc/init.d virtualis filerendszert, benne minden service-nek egy automatikusan generalt good-old start/stop/restart/reload/... init script, becslesem szerint tizedennyi ellenallas lenne systemd ellen.

szoval tl;dr, kell a systemd, de lehetett volna ezt baratiabban is csinalni.

 

update: btw ha azt hiszed, a systemd gaz, latnod kene macos-en a launchctl -t... :P

udev tud külső parancsot futtatni. (A FreeBSD-féle devd - ami kb. az udev megfelelője - csont nélkül meghívja a "service bluetooth onestart ubt0" parancsot, és systemd előtti / mentes környezetben ezt csinálta/ja a legtöbb Linux terjesztés is.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Tud az udev parancsot futtatni mindenfele eventre. Faek egyszeruen. Szoval biztos meg lehet ezt csinalni bonyolultabban is, de jo kerdes hogy minek :)

Kicsit azt erzem ezekkel az event dispatcher szeru dolgokkal mint az audio alrendszereknel: baromi keves eroforras kell neki mar, ezert meg egy szar/fos implementacio sem lesz feltunoen szar/fos elsore. Igy megjelenik kismillio fork meg valtozat meg tokomsetudja mi mondvan hogy "ja, irjunk egyet, mert miert ne". Node abbol hogy nem kell eroforras-szempontbol jonak lennie, nem feltetlen kovetkezik hogy mas (pl. stabilitas) szempontjabol lehet szar - es akkor sok osszetakolt herkelmeny olyan lesz, amilyen. 

Egyetértek. Nekem is ez a fő gondom vele, hogy sok minden dependel rá, emiatt hiába is cseréli le az ember az initrendszert másikra, attól még egyes alkalmazások továbbra is igénylik, hogy elogind, udevd, stb. fusson (és akkor felesleges volt azért váltani, hogy két külön initrendszer is fusson), és erről nem a systemd tehet, hanem a devek, akik a programjukat akkor is dependellik rá, ha nem muszáj.

A Devuan nem rossz, de ugye a csomagverziók régiek. Viszont ez érthető, mert Debian stable az alapja, ami eleve nem valami friss általában, és még ezután is kullognak verziókkal, mivel a systemd-s függőségeket ki kell kézileg gyomlálniuk minden érintett csomagból, ez meg idő, plusz kevés fejlesztő van rá, túl kicsi disztró szindróma.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Devuan nem rossz, de ugye a csomagverziók régiek.

Homokozónak lehet, produktívnak épphogy túl friss. Hogy valami kommersz LAMP-izmust mondjak, MariaDB 10.11 és PHP 8.2 van benne. A legnépszerűbb webes alkalmazások nagy része még nem támogatja, vagy épp pár napja támogatja csak...

és még ezután is kullognak verziókkal, mivel a systemd-s függőségeket ki kell kézileg gyomlálniuk minden érintett csomagból

Kemény 2 hónappal jöttek ki a Debian 12 release után. (Mondjuk, én amikor megcsináltam az első homokozó gép frissítését Debian 12-re, fogtam a Daedalus akkori (béta) csomagjait, és pont tökéletesek voltak.)

Egyetértek. Nekem is ez a fő gondom vele, hogy sok minden dependel rá, emiatt hiába is cseréli le az ember az initrendszert másikra, attól még egyes alkalmazások továbbra is igénylik, hogy elogind, udevd, stb. fusson (és akkor felesleges volt azért váltani, hogy két külön initrendszer is fusson), és erről nem a systemd tehet, hanem a devek, akik a programjukat akkor is dependellik rá, ha nem muszáj.

A devek azért csinálják ezt, mert meg vannak benne írva olyan dolgok, amikre szükségük van, de nincs kedvük / erőforrásuk megírni. A distrok is azért szeretik, mert featureok vannak benne, amivel könnyebb distrót csinálni. Csak ezt nem szokás megérteni, hanem helyette megy konteózás/fujjogás.

Debian stable kiadások:

1996, 1997, 1998, 1999, 2000, 2002, 2005, 2007, 2009, 2011, 2013, 2015, 2017, 2019, 2021, 2023.

EGYSZER előfordult, hogy HÁROM év is eltelt két kiadás kötött (woody és sarge). 2005 óta kétévente van release, ennek ellenére a debiannal kapcsolatban azóta is tartja magát a myth, hogy régiek a csomagok.

Windowsból 2000 óta hány verzió jött ki?

Frissességben sokat fejlődött a Debian, az utóbbi kb. 5 évben főleg. Windows az más ökoszisztéma, ott a verzió nem annyira számít.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”