systemd, ha már

Figyelem, ez egy véleményposzt. Nem állítom, hogy mindenben objektíven igazam van, és nem csak technológiai érveim vannak. Elfogadom, ha szerinted nincs igazam - de a véleményem jó eséllyel nem fog változni.

A minap beszélgettünk egy Debian és SuSE fejlesztővel, hogy hogysmint mennek a dolgok a Linux világban. Szóba jött a systemd.

Mondtam, hogy nekem csak a következő bajaim vannak a systemd-vel:

  • nem init system, hanem eszköz a teljes kontrollra az userspace felett, és az "init system" csak a trójai faló volt, a név "systemd" viszont az első naptól mutatja, hogy mi is volt az eredeti cél...
  • viszont az init system részt sem tudja rendesen megoldani, minden rendszeremen gondok voltak az átállással és migrációval eddig, és azóta is rendszeres kisebb-nagyobb glitchek vannak
  • de a technikai problémákat mellőzve a legnagyobb bajom a systemd-vel politikai - minden kritikus szolgáltatást átirányít magára, én pedig sem a szoftverben/projektben magában (compile time Google DNS fallback, a legfrissebb root fallback bug, vagy az emlékezetes eset, hogy minden vacakba pl. a tmuxba próbáltak systemd supportot tolni, stb), sem a karbantartójában, sem a mögötte álló cégben (Red Hat) sem bízom kicsit sem...
  • mellékesen a nevezett karbantartó korábbi szoftvereit (Pulseaudio, köhm) is kellően hulladéknak tartom, és mivel magam is írtam audio kódot eleget, ezért ez esetben még megalapozottnak is tartom a véleményem
  • szóval minden rendszerem inkább Devuanra állítom át

Na itt elszakadt a csávónál a cérna, és elkezdett fröcsögni...

  • Lennart Poettering az ő közvetlen jó barátja én meg itt sározom - Madarat tolláról, mondom erre én...
  • a sysvinit egy karbantartás nélküli szar, amit senki sem akart bevállalni, szóval a systemd-t legalább karbantartják - well... a systemd karbantartását inkább hagyjuk... a sysvinit meg nem jó, de mindig van lejjebb.
  • amúgy is gyorsabb a boot - Szerveren pont leszarom, mondom erre én, ellenben amikor a VM alatt futó KVM-be kell rendszeresen beVNCzni hogy összekaparjam a gépet egy-egy systemd-s széthalás után, vagy force-olni kell egy rebootot, mert nem létező dolgokra vár perceket (félórákat), az nem annyira vicces.
  • és neki teljesen jól működik a systemd, semmi baja vele - A worksforme nem érv. Nekem meg doesnotwork, so what?
  • a Devuan Linux egy szemét, és a karbantartóinak fingjuk sincs arról hogy mit csinálnak - Ezt nem tudom megítélni, de eddig működik, elég jól és lényegesen kevesebb "ezt most megint miért kellett" macerával mint a systemd-s rendszereim.
  • az Apple is custom userlandet futtat, még sincs rinyálás - Az OS X-et egyrészt nem használom szervercélra, másrészt tíz év OS X használat alatt a custom Apple userlanddel és system services cuccokkal nagyságrenddel kevesebb problémám volt mint a systemd-vel az elmúlt év alatt, mióta az utolsó systemd nélküli LTS disztrókról is muszáj volt váltani...
  • ha most nem váltok systemd-s rendszerre, a jövőben rohadt nagy problémáim lesznek, mivel minden desktop és egyéb rendszer a systemd felé megy - Ez kb. klasszikus FUD, szóval nice try, azt meg majd a jövőben meglátjuk, hogy mi lesz akkor.
  • a systemd sokkal modernebb, és mindent kényelmesebb alatta bekonfigolni - Én meg azt látom hogy olyan gépeim, amik eddig gyakorlatilag évtizedeken át mentek gond nélkül és frissültek újabb verziókra, hirtelen heti szintű nyüsztetést igényelnek, mert valami nem megy, mint valami ócska tamagocsik, mert egy service restart vagy service leállítás is véletlenszerű problémákat okoz. Mindezt úgy, hogy a kutya sem kérte a tisztelt disztrógyártókat hogy tolják ezt a kacatot a gépeimre, sőt, opt out sem nagyon volt, ha már az a default.
  • az userek mindig csak ingyen szoftvert akarnak, de nem akarnak foglalkozni a karbantartással - Ez nekem nem érv. Egyrészt magam is Open Source hozzájáruló vagyok, másrészt userek nélkül a szoftver léte értelmetlen. Én konkrétan ott tartok, hogy fizetnék, csak ne tolják az arcomba ezt a vackot. Amúgy is, ha valami szolgáltatást ingyen kapsz te vagy a termék, szokták mondani...
  • tényleg úgy gondolom, hogy a sokezer Red Hat, IBM, Intel, SuSE, Debian, etc mérnök mind hülye, hogy a systemd-t tolják? - Őszintén? Nem. De a sokezer mérnök aki a Vistán dolgozott sem volt hülye - mégis, az userek többsége szempontjából egy rakás szar lett a végeredmény. Amúgy ez a klasszikus "egyél tehénszart, ötmilliárd légy nem tévedhet" érvrendszer. Ez nekem már a Windows 95-nél sem jött be, inkább OS/2-ztem vagy fél évtizedet.

Erre kiröhögött, és mondta, hogy menthetlen vagyok. Igazából csak mert én akarok dönteni, mit futtatok a gépemen és nem látom, hogy a systemd-vel csak a javamat akarja mindenki. Software freedom, corporate Linux módra. Szóval továbbra sem lettünk, én meg a systemd, jóbarátok. De igazából csak az érdekel, hogy nélküle egyelőre lényegesen alacsonyabb a vérnyomásom...

Poetteringről meg csak annyit, hogy minden projektben a rettentően produktív, de mérgező természetű emberekkel a legnehezebb kezdeni valamit. Duplán igaz ez nyílt forrású projektekre, ahol nincs egy "felettes" aki kirúghatná vagy megfegyelmezné őket. Vagy ha van, a céges céloknak még pozitív is, ahogy viselkednek (pl. lásd a Red Hat corporate policy-t, a projektek kötelező upstreambe tolásáról, hát így lett a systemd...). Poetteringnek legalább annyit a javára tudok írni, hogy - persze csak a saját egóját masszírozandó, de ez mellékes - a saját kacatjaival tolja magát, nem pedig takeoverel amúgy jól működő projekteket, mint sok más hasonszőrű szociálisan gyengén teljesítő teszi.

(És a Pulseaudio kapcsán még volt egy csörténk, megemlítve, hogy most már kötelező dependency a Firefoxhoz Linuxon - erre meg csak annyit tudok mondani, hogy miután bedőlt a Netscape 5 projekt és a korai Mozilla sem igazán haladt sehova, egyvalaki fogta a forrást, kitakarította, legallyazta, és aztán ebből lett a projekt zászlóshajója a Firefox (leánykori nevén Phoenix, első férjezett nevén Firebird) nagyon hamar. Én most is erre számítok - lévén a Mozillát közösségi "legyen mindenkinek jó" helyett ismét olyan corporate-style döntések hajtják, amik annó a Netscape és a korai Mozilla projekt vesztét ill. sehovanemhaladását okozták, miközben a piaci részesedés stabilan esik. Lásd még pl. a Rust, mint függőség erőltetését, ami lehet bármennyire jó (amúgy szvsz a koncepció az, de ez most mellékes), szintén a "kutya sem kérte", nagyjából, és sokkal inkább politikai mint technológiai okokból létezik mint függőség, ill. valamiféle felesleges előre menekülés, stb...)

Ha megváltozik a véleményem a jövőben a systemd-ről, frissítem ezt a postot. De addig is jó összefoglaló, amit linkelni fogok mint FAQ, ha már megint kérdeznek... :P

Hozzászólások

itt jartam

--
Vortex Rikers NC114-85EKLS

az en wtf? ertetlenkedesem ott kezdodik, hogy milyen code review, tesztek es hasonlo nyalanksagok vannak a rathead-nel, ha ennyi szar dol ki a systemd-bol? Ha a poetteringhulye minden bug-nal, amit elkovet 1 cm-t none (sec. bug eseten 10 cm-et), akkor mar reg ulve kene nyalja a Holdat...

--
Allitsuk meg Andorrat!

"ha most nem váltok systemd-s rendszerre, a jövőben rohadt nagy problémáim lesznek, mivel minden desktop és egyéb rendszer a systemd felé megy"

Ezeknek a magas szintű dolgoknak egyébként mégis mi közük a systemd-hez? Miért nem valamilyen absztrakt, jól meghatározott interface-en keresztül kommunikálnak, amit mindenki azzal és úgy valósít meg, ahogy akar? Ekkor a systemd csak egy megvalósítás lenne a sok lehetséges közül.

"És a Pulseaudio kapcsán még volt egy csörténk, megemlítve, hogy most már kötelező dependency a Firefoxhoz Linuxon"

Ugyanaz a kérdés mint az előbb, a Firefoxot miért érdekli, hogy az általa használt API-t épp a Pulseaudio fogja implementálni? Persze az lehetséges, hogy az API-t a Pulseaudio project definiálja, de attól még lehet rá adni más implementációt is.

És a végkimenetelt tekintve teljesen mindegy is, mert:

A., nem lesznek problémáim, mert minden nyílt interfészekre épült, ergó könnyen fejleszthetők alternatívák - és fejlesztenek is, és akkor igazam volt, hogy elkerülhető a systemd, ergó a "nélküle rosszul jársz", csak FUD volt.

B., problémáim lesznek mert tényleg mindenhez systemd kell majd, ergó igazam volt, hogy az egész csak egy kurva nagy corporate vendor lock-in akció ami a Linux userspace-t illeti, és amiből nem kérek, se így, se úgy. Őszintén, ha már ígyis úgyis "userként" vagyok kezelve, nem egyenrangú partnerként a saját rendszeremben, akkor inkább macOS-t futtatok, az legalább működik és nem tolakszik az arcomba mindenféle hülyeséggel. (Saját választásom, de kinek mi. Amíg van választásunk, addig jó, asszem ebben egyetérthetünk.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

"Őszintén, ha már ígyis úgyis "userként" vagyok kezelve, nem egyenrangú partnerként a saját rendszeremben, akkor inkább macOS-t futtatok, az legalább működik és nem tolakszik az arcomba mindenféle hülyeséggel."

Salamoni gondolat... mondom úgy, hogy már az almás billentyűzetnél a 0-t súrolja a produktivitásom.

felesleges előre menekülés

hajbazer, te vagy az? :-)

egyébként jó a cikk.
pulseaudiot nem is tudtam h ő csinálta, nagyon nem mélyedtem bele ugyan. alsa-áztam mindig, csak az x11rdp miatt kellett foglalkoznom vele. de azon kívül hogy user módban a daemon idle timeout után leáll, nincs különösebb aggályom.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Ez a Pöttering lesz a Linux-világ Soros György-e.? ( ugye Trey )
Imádom a Devuan-t, az AntiX-ot, az MX Linux-okat és nem szeretem ha rám kényszerítik sem a systemd-t, sem a Unity-t, majd én eldöntöm, hogy akarom-e
--
God bless you, Captain Hindsight..

a sysvinit egy karbantartás nélküli szar, amit senki sem akart bevállalni, szóval a systemd-t legalább karbantartják - well... a systemd karbantartását inkább hagyjuk... a sysvinit meg nem jó, de mindig van lejjebb.

Csak így ehhez szólnék hozzá: még ha a sysvinitet valaki el is kezdi karban tartani, a tonnányi init scriptre még mindig keresni kellene maintainert. Mert ott azokat is annak kell tekinteni. Ráadásul ott vagy, hogy ahhoz, hogy N maintainer (per disztró!) K különböző scriptjén bármi következetességet elérj, N ember kell, K különböző forráskódba (mert lássuk be, az init script is aktívan futó kód) kell belenyúlni.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Viszont nem futó forráskódok.

pl.: valamelyik másik topicban említettem, hogy Jessie-n belefutottam, hogy a winbindd init scriptje gyakorlatilag egy killall winbindd-ot indít [start-stop-daemon-on keresztül, de a man page második bekezdése ezt írja le], amivel pl. egy LXC hoston újraindított winbindd az összes konténerben is lelövi, ha futott... A Stretch-ben már rendes unit fájl van hozzá (a Samba upstream unit fájlok, és a systemd ad PID-et hozzá - így rendesen működik.

Itt volt egy bug, amit a package maintainer tett a rendszerbe azzal, hogy egy új, aktív komponenst tett a csomagba.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egy systemd unit fájlnak olyan túlságosan nem kellene változnia, vagy ha változik, akkor valószínűleg a programban is volt valami változás (ill. időközben megjelent egy új feature a systemd-ben, amit a disztró használna, de szvsz. a vendor által szállított konfigok a konfig opciók ~10%-át használják ki, az adminra és drop-inekre bízzák)

Nézd meg, a samba service-k unit fájljai mennyit változtak a létrehozásaik óta: nmbd 4 változás, samba 3 változás, smb 4 változás, winbindd 5 változás. Ez 2011 okt 28 óta - az akkori verzióhoz képest a különbség a Type-ban van (kapott systemd integrációt 2014-ben), kaptak ExecReload-ot [egyébként a systemd ajánlással szembemenve...] és egy LimitCORE direktívát.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A sima init scriptek sem valtoznak tobbet szerintem.

Itt mondjuk a Samba kivétel, mert egyrészt egy mindent bele szemétdomb, másrészt volt egy nagyon nagy főverzió váltás közben, de wheezy és jessie között (pedig csak egy release különbség, két év különbséggel) gyakorlatilag a felismerhetetlenségig nulláról újra írták :)

Szerintem a kulonbseg es a lenyeg abban van v. kene, h legyen, h nem 1000 csillio fele lesz

A kaptafa is működik (gyakorlatilag minden disztrónak van kaptafája :) ), ami miatt _én_ személy szerint preferálom a systemd-t, az egyrészt az, hogy 3rd party-k sem tudják elbarmolni (disztón belül még egész konzisztensen tarthatók az init scriptek, a zárt forrású cuccoknál meg kb. a legbiztosabb írni sajátot :) ), másrészt hogy a függőség-kezelés sima konfigurációvá lép vissza (ill. sok minden más is).

Talán az egyik legjobb példa: a GlusterFS doksija javasolta, hogy ne az adat partíció gyökerében hozzuk létre a brickeket [vagy hogy hívják, régen játszottam vele], hanem azon belül egy külön mappában - mert így ha elindul a GlusterFS úgy, hogy nincs felcsatolva az adat partíció, akkor sincs gond, mert nem találja a mappáját és leáll; ami működik, de szvsz. egy nagyon csúnya hack; systemd-vel simán csinálsz egy dependency-t a megfelelő mount unit-ra és megoldottad, a glusterd el se akar majd indulni; ha ezt a javasolt megoldással, egy drop-in mappában csinálod, akkor a systemctl kapásból megmondja, hogy a disztró defaultoktól eltérsz, megmondja, hol vannak a saját konfig kiegészítések, és bele tudsz nézni a helyi sajátosságokba.

Init scriptnél sok más választásod nincs, ezt bele kell írnod az init scriptbe, aztán állandóan diffelned az rpmnew/dpkg-new fájlokkal :)

(én pl. már a cron-t is ahol csak lehet, kiváltom systemd service és timer unitokkal, nagyon kényelmes, hogy tudsz egy systemctl start backup-ot írni és mindig garantáltan ugyanazzal a környezettel fog lefutni. Ami ugyanaz a környezet lesz, mint amikor a timer miatt indul. És bárhogy is indítod, a journalból ki tudod kérni a teljes kimenetét. Egy systemctl status backup-pal le tudod kérni, sikeres volt-e az utolsó futtatás [esetleg még mindig fut-e] stb.)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Gyakorlatilag mindenben egyetértünk, de hát ez már csak így van velünk, hazaárulókkal. :D

Engem elsősorban az zavar benne, hogy a választás szabadságát veszi el, amiről nagyrész a szabad szoftverek szólnának. Említetted a politikai vonalat, gyenge párhuzamot tudnék fölvonni azzal, hogy a szólásszabadság korlátozása is igencsak irritál, bármilyen politikai szereplőtől is érkezzen az "igény" erre (de többnyire a PC/mainstream szokta ezt erőltetni).

Szomorú látni, hogy a Linux userlanddel ez történik, de mivel a történelem mindig ciklikus, ezért lesz ez még így se.

És mint fölöttem valaki megjegyezte, van másik n+1 választható init-rendszer. BSD-ken is van rc.d, Solarison az SMF, macOS-en a launchd - biztos, hogy mindegyiknek vannak hiányosságai, de egyik sem egy akkora katasztrófa, mint a systemd. Pöttering valahogy nem tud jó helyről és igényesen kódot lopni.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Köszi a post-ért Chain-Q & subscribe.

> van másik n+1 választható init-rendszer.
Nálunk is hörögnek systemd-re rendesen, de nagyvállalati környezetben sajnos nem úgy megy hogy pl. RHEL7 lesz systemd nélkül :(

> BSD-ken is van rc.d
Nem is volt vele bajom sose, fene vinné el ezeket a régi, kiforrott, működő dolgokat ;) /Nagyvállalati környezeten kívüli maszek világ, bent nincsenek BSD-k./
____________________
echo crash > /dev/kmem

Nagyvállalati környezetben nem érdekel, hogy mit kell használnom, amíg tudok vele dolgozni ÉS megfizetik. Cold, hard cash. :) No meg azért se, mert ha valami nem megy, akkor úgyis lehet a supporttal üvöltözni, hogy működjön a szarjuk, ha már egy vagon pénzt fizetünk. :D

Mondjuk perpillanat nem zavar a Redhat ámokfutása, mert leginkább Solarist tologatok.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

+1
Annyit tennék, hozzá, hogy amit Pötyibácsi nem ért, hogy az egységesítés és az egybeépítés nem ugyanaz. A systemd gőzerővel gyúr egybe, egymáshoz nem tartozó szolgáltatásokat, saját függőségi rendszert alakítva ki. Azt már megtanulhattuk volna, hogy a agyonintegrált megoldások, mindig is retkes nagy szívásokhoz vezetnek, mert ha kiesik egy komponens összeomlik az egész. Ugyancsak az egylábon álló rendszerek hibája, hogyha kirúgjuk a lábat, akkor összeomlik az egész.
Az init rendszereknél nem volt ilyen probléma, mert minden egyes script a maga önálló kis világa volt.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

+1

megtanulhattuk volna, hogy a agyonintegrált megoldások, mindig is retkes nagy szívásokhoz vezetnek

Hát ez az, épp ez volt a Linux erőssége. Olyan volt, mint egy szerszámosláda, így igen nagy volt az ember szabadsági foka abban, mit milyen eszközökkel, hogyan valósítson meg. Lennart ennek tesz keresztbe. Mondom ezt úgy, hogy nekem nincs bajom a systemd-vel, már-már tetszik. Ennek részint az is oka lehet, hogy Fedora mindig a legfrissebbet, vagy közel legfrissebbet szállítja, így azok a gyermekbetegségek, amelyek korábban voltak benne, már nincsenek. Viszont az nem tetszik, hogy már minden bele van lapátolva. DNS kliens mit keres benne? És NTP? Ha ez így megy tovább, lesz desktop környezet meg böngésző is a systemd-ben...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A timesyncd-t meg semtaláltam, pedig grep-pel is kerestem. A másikat meg nehezemre esik értelmezni.

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: disabled)
   Active: inactive (dead)

Értem, hogy eredendően tiltott, ugyanakkor nem emlékszem arra, hogy én engedélyeztem volna. Talán valaminek a függőségeként? Aztán, noha engedélyezett, de mégis inaktív. Pedig nem mondtam neki stop-ot. Most akkor mi van?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Passz, Süsü fel se teszi [lehet, hogy valami a D-Bus felületén kérdezett tőle] :)
De azon túl, hogy futtatod a resolved-t, még az nsswitch-be fel kell vinned a hozzá tartozó modult (nss-resolve) vagy meg kell adnod 127.0.0.53-at a resolv.conf-ban.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egyre jobban tetszik a Slackware, vagy Devuan. No meg persze a FreeBSD.

Én mostanában vagyok úgy a FreeBSD-val, mint tizen-huszon éve a Linux-szal. Feltelepítem, használom, valamit rohadtul nem tudok megoldani, szenvedek vele, megunom, telepítek helyette Debiant (vagyis mostanában Devuant). Aztán megint elkap a gépszíj, és kezdődik minden elölről...

a rettentően produktív, de mérgező természetű emberekkel a legnehezebb kezdeni valamit

"Az a legrosszabb, amikor a hülyeség a kitartással párosul."

"tényleg úgy gondolom, hogy a sokezer Red Hat, IBM, Intel, SuSE, Debian, etc mérnök mind hülye, hogy a systemd-t tolják?"

A többiről nem tudok mit mondani, de nem biztos hogy itt azzal az IBM-mel érvelnék, amelyik 15 éve féltéglákkal fejelget és csodálkozik, hogy valamiért, valahonnan a szemébe csorog a vér.

su
Ha már Devuan, feltelepítettem próbából, és másik gépbe áttéve nem akar csatlakozni a hálózathoz, pedig a megfelelő modulok be vannak töltve
Nincs ilyen eszköz, írja
eth0, eth1

Az udev intézi a device rename-et. Lásd pl. ezt a szösszenetet egy Ubuntu 16.04 dmesgből:

[ 1.491649] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:5a:55:c1
[ 1.491655] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
[ 1.491681] ahci 0000:00:0d.0: version 3.0
[ 1.492143] ahci 0000:00:0d.0: SSS flag set, parallel bus scan disabled
[ 1.492293] ahci 0000:00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
[ 1.492296] ahci 0000:00:0d.0: flags: 64bit ncq stag only ccc
[ 1.493623] e1000 0000:00:03.0 enp0s3: renamed from eth0

Ez a rename az udev része ami most ugye alapból a systemd része, és ha nincsen persistent rule egy interfészre, akkor az ún. "predictable interface names" stratégiát használja az átnevezésre. Mindenféle gusztustalan részletek itt, plusz még ezeken kívül a distro specifikus defaultok is változhatnak... Szóval fasza. :)

De korábban is az udev nevezgette át az interfészeket, csak akkor a stratégia az volt, hogyha egyszer meglátott egy eszközt, akkor eltárolta mint persistent rule, és ha kicserélted másikra, akkor az új ethX-ként jelent meg, amíg a korábbi rule-t nem törölted. Szerintem ez utóbbi jelenség van most Devuanon, de most nem tudom fejből és leellenőrizni sem.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Chain-Q te melyik verziót használod?
A stable 1-et?
Ráfrissítettem a ASCII-re, a régi kernel miatt. és a libpolkit-agent-1-0 policykit-1 vissza van tartva.
Kézzel kell mountolni pl
Not authorized to perform operation.

kösz