- A hozzászóláshoz be kell jelentkezni
- 461 megtekintés
Hozzászólások
Én sima hétköznapi Linux felhasználó vagyok, és a témához értőktől kérdezem, hogy mi az a nagy baj a systemd-vel, ami miatt megéri külön disztrót fanntartani? Ez nem flame kérdés, tényleg nem tudom.
Nekem a systemd bevezetés annyi volt, hogy meg kellett szokni, hogy nem init.d meg rc rendszer van, és ha saját szolgáltatást szeretnék indítani, kezelni, akkor máshová és más formátumú konfigot kell hozzá írni. Meg persze belefutottam pár dologba (tájékozatlanságom miatt), amikor is a systemd által futtatott szolgáltatás ütötte az általam használni kívántat default konfig mellett (NTP kliens, helyi DNS). De ezen felül az utóbbi pár évben semmi olyanba nem futottam sima üzemeltetőként bele, ami miatt folyamatosan átkoznám a systemd-t.
Ezért kérdezem itt meg, hogy mit is nem tudok róla, ami miatt alapvető bajai vannak vele sokaknak.
- A hozzászóláshoz be kell jelentkezni
Én sima hétköznapi Linux felhasználó vagyok, és a témához értőktől kérdezem, [...] Nekem a systemd bevezetés annyi volt, hogy meg kellett szokni, hogy nem init.d meg rc rendszer van, és ha saját szolgáltatást szeretnék indítani, kezelni, akkor máshová és más formátumú konfigot kell hozzá írni. Meg persze belefutottam pár dologba (tájékozatlanságom miatt), amikor is a systemd által futtatott szolgáltatás ütötte az általam használni kívántat default konfig mellett (NTP kliens, helyi DNS).
Ha te ilyeneket csinálsz, akkor ne hétköznapi Linux felhasználó vagy 2021-ben. Egy mai hétköznapi Linux felhasználónak nem kell a gépháztető alá néznie ilyen szinten.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Semmi sem állandó csak a változás örök.
Jött valami új amit a legnagyobb terjesztések simán bevezettek. Van aki hajlandó megtanulni és van aki nem akarja megszokni ezt az újat. Nekik való pl. ez a Debián fork, hogy legyen hova megszökni.
Ez egy jó dolog, bár a Linux üzemeltetésben szerintem hasznosabb a fősodorban maradni. Persze lehetnek kivételt jelentő eseti körülmények.
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
- A hozzászóláshoz be kell jelentkezni
Én már összeszámolni sem tudom, hogy hányezerszer lett már megcáfolva ez a "nem ismerik és nem hajlandóak megtanulni" felütésű degradálása a systemd-elleneseknek, de újra-és-újra előkerül...
- A hozzászóláshoz be kell jelentkezni
A "Csak azert sem" ketegoria az jobb ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
"Nem ismerik és nem hajlandóak megtanulni" -> 68000x megcáfolva = "csak azért sem"? Ez hogy jött ki?
- A hozzászóláshoz be kell jelentkezni
Troll on.
"Doesn't work for me" ami a gyerekes "Worksforme"-vel ellentétben egy valós és alapos ok arra, hogy valamit egyértelműen rossz-nak ítéljünk meg.
Troll off.
:wq
- A hozzászóláshoz be kell jelentkezni
A baj nem magával a systemd-vel van, mert az önmagában lehet szeretni, nem szeretni, egyetérteni vele, vagy bírálni, ízlés- és felhasználásfüggő. A gond azzal van, hogy a systemd-re minden félkegyelmű fejlesztő rádependeli a cuccát, ha kell, ha nem, mert az cool, meg hype, és emiatt ott kell legyen az összes disztrón, nem tudsz tőle szabadulni. Erről még csak nem is P5stering tehet, mert ő nem kötelez senkit a használatára, ez a fejlesztők hibája, hogy egy konkrét szoftverre dependelnek mindent. Mert ugyebár a Linuxnak, ahogy a többi unixlike rendszernek is az lenne a lényege, hogy moduláris, szabadon te állíthatod össze a rendszert, ha nem tetszik a bootloader, fájlrendszer, init, logolás, libc, shell, SSL, NTP, loginmanager, grafikus felület, hangrendszer, stb., akkor szabadon kicserélhesd másikra (vagy csak eltávolíthasd), bármit bármilyen POSIX kompatibilis vagy más nyílt szabványon alapuló toollal tudjál helyettesíteni, ezáltal teljes szabadságot megvalósítva.
Mert a systemd-re ennyire erősen építő linuxos világ ebben a Windowsra, MAC-re kezd hasonlítani, ott szokott olyan lenni, hogy a rendszer egyes részeihez nem nyúlhatsz hozzá, nem cserélheted ki, csak azt az egy megoldás használatod, amit eléd raktak, amit egy multi megálmodott. Sajnos ezek a systemd-mentes disztrók ott buknak el a gyakorlatban, hogy hiába is nem a systemd az inited, ahogy az első systemd-re dependelő szoftvert feltelepíted, már hozza is magával a háttérben futó elogind, udev, shitd, whateverd részimplementációit a systemd-nek, így meg az ember csak áltatja magát, hogy ő klasszik sysv initet, meg OpenRC-t, meg S6-ot, stb. használ, mert valójában épp úgy nem kerülted ki a systemd-t. Ennek ellenére fejlesztők azért próbálkoznak, hogy karban legyen tartva egy teljesen systemd-mentes ökoszisztéma, hogy aki elvi okból el akarná kerülni, a régi teljes szabadságot akarná vissza, az elviekben megtehesse, legyen rendszer, amit használhat, és az ilyen usereknek ne kelljen BSD-re váltani.
“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.”
- A hozzászóláshoz be kell jelentkezni
Adtam rá egy lájkot. Éppen OpenBMC-vel szívok. Amit meg lehetett volna oldani egyszerűen dbus-on, vagy bárhogy másképp, azt rendszerint bonyolultan oldották meg systemd service-eken meg target-eken keresztül, követhetetlen módon.
- A hozzászóláshoz be kell jelentkezni
Igen, ez az, és tengernyi ilyen szoftver van, ráadásul a legnépszerűbbek szinte mindegyike ilyen, Gnome, Wine, Steam, stb.. És itt a disztrók is kényszerpályán vannak, nem szórakozásból adoptálták a systemd-t, vagy azért, mert annyira rajonganának érte. Ha ellenállnak, egy csomó szoftver eltörik függőség miatt, a userek szívnak miatta, és akkor az lesz, hogy xaralinux, nemleszdesktopéve, bezzeg Windowson megyen, és akkor nem értek el semmit, csak a felhasználókat szopatták meg a semmit, elűzték, ezt nem akarták. Nem véletlen, hogy még olyan ultrakonzervatív disztrók is gyorsan megtörtek, és adoptálták a systemd-t, mint a Debian, Slackware, CentOS, stb.. Ráadásul ez egy ördögi kör, mert minél elterjedtebb, minél univerzálisabb, annál több minden dependel rá, egyre megtörhetetlenebb lesz az uralma, már túl késő megállítani.
Ami még a systemd-ben aggasztó, hogy egyre inkább mindenes. Már nem csak egy init, már nem csak egy naplózó, hanem mindenféle eseményt, hálózatot, bootot, jogosultságot, usert, stb. az kezel már le, ezzel már-már átveszi a kernel feladatait is, és ha ez így megy tovább, akkor a Linuxot lassan már nem is Torvalds kernel fogja hajtani, hanem átmegy az egész Systemdix-be, RedHatOS-be, ami lényegében egy teljesen másik OS lesz.
“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.”
- A hozzászóláshoz be kell jelentkezni
Debian a 2015-ben megjelenő 8-as verzióban használta a systemd-t alapértelmezettként. A systemd 2010-ben jelent meg. Ez nem túl gyors megtörés azért.
Slackware nem használ systemd-t ma sem.
CentOS RedHat-et csomagolta mindig is újra, most meg már RH homokozó. Poettering meg a RH-nak dolgozik. Jól megtört a CentOS :D
Megtudnád mondani melyek azok a kernel feladatok, amiket a systemd átvett?
- A hozzászóláshoz be kell jelentkezni
Pl coredump kezelês
- A hozzászóláshoz be kell jelentkezni
systemd előtt mi kezelte a core dumpot?
- A hozzászóláshoz be kell jelentkezni
A kernel.
- A hozzászóláshoz be kell jelentkezni
Jó, akkor systemd alatt is. A systemd csak megkapja további feldolgozásra.
- A hozzászóláshoz be kell jelentkezni
Ebben vszleg vastagon benne van az is, hogy projektek kaptak azon, hogy van egy "standard" init rendszer amit ha támogatsz akkor letudod a disztrók nagy részét. Mi is csak systemd-t támogatjuk alapból mert vért izzadva próbáljuk lecsökkenteni a kompatibilitási mátrixunkat a különböző disztrókkal kapcsolatban, egyszerűen nincs kapacitás arra, hogy támogassuk az összes szoftver összes létező verzióját. Szóval aki nem systemd-t használ az büytkölhet magának init integrációt ahhoz amit akar használni, de supportot nem kap hozzá.
:wq
- A hozzászóláshoz be kell jelentkezni
Szóval aki nem systemd-t használ az büytkölhet magának init integrációt ahhoz amit akar használni, de supportot nem kap hozzá.
Ez a karbantartók szégyene és nem a systemd érdeme.
- A hozzászóláshoz be kell jelentkezni
Szerintem meg semmi szégyen nincs ebben. Aki valami niche disztrót/init rendszert használ az ne várja el, hogy mindenki buildelje, tesztelje és csomagolja rá a termékeit, ez egyszerűen nem életképes. Nem véletlen, hogy kereskedelmi szoftverek általában a 2 legnépszerűbb disztróhoz vannak becsomagolva (Ubuntu és Fedora), mindenki más újracsomagolt kendácsolt csomagokat használ.
:wq
- A hozzászóláshoz be kell jelentkezni
Én nem a programfejlesztőkről beszéltem, hanem a karbantartókról. Nem a programfejlesztő feladata lenne, hogy adott disztró minden initjéhez is megcsinálja a támogatást, hanem az adott disztró karbantartóié. Az ő szégyenük ez, nem azé, aki a programot írta.
- A hozzászóláshoz be kell jelentkezni
A lényeg az alternatívák / konkurenciák fenntartása, ami nélkül minden bénaság lesz -- idővel.
Manapság talán egyedül a konténerizációnál zavaró a systemd: ha nem őt teszed pid1-be, akkor nem tudod service managementre használni. Ilyen limitációja initd/runit/openrc egyiknek sincs (persze van más). Nem véletlen, hogy a legnépszerűbb "docker disztró" alpine is openrc-t használ.
+ Átlagembernek nem, de technológiailag érdeklődő embereknek érdemes néha kidugniuk a fejüket a homokból, és megismerni mást is mint a mainstream és a tucatcuccok.
- A hozzászóláshoz be kell jelentkezni
systemd podman -el megy, ha jol tudom.
alpine containerek sem szoktak rc vel indulni, a containerezesdi nem abba az iranyba ment hogy egy teljes linux rendszer lakik a containerben.
A legtobb container aminek kell egy "igazi" pid1, az tipukusan csak szimpla zombie vadasz program,
tehat nemhogy systemd meg rc sem.
A Devuan sysvinit -re defaultol nem openrc -re, meg inkabb kokori.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni