A Devuan projekt, amely azért jött létre, hogy systemd-mentes Debiant adjon az ezt igénylők részére, aggódik. A projekt egyik alapítója szerint, ha számukra kedvezőtlen lesz a Debian GR szavazás kimenetele, az a projekt végét jelentheti. A Debianra építenek, így ha az úgy dönt, hogy kizárólag systemd-t támogat a jövőben, nekik nem sok esélyük lesz a fennmaradásra. Sem fejlesztői erőforrásuk, sem infrastruktúrájuk nem mérhető a Debianéhoz. Éppen ezért, számukra kizárólag Ian Jackson "D" jelű javaslata jelent reményt:
Részletek itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Majd akit érint, az átáll pl. MX Linuxra. Az is Debian alapú és systemd mentes és annak csak lesznek erőforrásai; már a jóég tudja, mióta az első a Distrowatch toplistáján (ki tudja miért). Sz*rk: Ja, hoppá, erre már nem, mert átálltak semi-rollingra.
Vagy lehet válogatni a Debian csomagkezelős és systemd mentes rendszerek között.
- A hozzászóláshoz be kell jelentkezni
Ezek közül kizárólag az fog tudni lépést tartani, amelyiknek komoly erőforrásai vannak. Ugyanis, ha a Debian elkezd olyan csomagokkal tele lenni, ami kizárólag systemd-vel fog működni, akkor nekik komoly munka lesz nem csak a csomagok válogatása, karbantartása, hanem a csak rájuk jellemző bugok javítása is. Ez pedig nem lesz egyszerű feladat. Ettől tart a Devuan is.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
A Debian már most tele van olyan csomagokkal, amik feleslegesen dependelnek a systemd-re, mert maguk a csomagolt szoftverek egyáltalán nem igénylik, közük nincs semmilyen init rendszerhez; a dependelő csomagok többsége csak azért függ a systemd-től, mert a Debian Team így csomagolta, ki tudja miért... Ennek megfelelően a csomagok többségét simán újra lehet csomagolni úgy, hogy ne függjön a systemd-től, pont úgy, ahogy eddig tették a Devuan Team tagjai. Itt akkor állhat elő igazi probléma, ha a program tényleg függ a systemd-től, de akkor meg a Debian Team se tud rajta segíteni, hiszen kell neki a systemd; olyan esetben alternatívát kell biztosítani. Ez a kérdés, hogy hány ilyen eset lesz, ahol az alternatívák biztosítását nem lehet a Debian Teamtől várni és a Devuan Teamnek kell karbantartania az alternatív csomagokat. Ha sok, akkor cumi van. Ha kevés, akkor azt bírni fogják ők is. Jelen pillanatban elenyészően kevés olyan program van a Debian csomagtárolóban, aminél ténylegesen maga a szoftver függ a systemd-től és nem pedig csak a csomag - feleslegesen.
- A hozzászóláshoz be kell jelentkezni
A fenti cikkben olvasható segélykiáltás illusztrálja, hogy baj van.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Baj van, csak nem biztos, hogy az, amit felvázolnak. Lehet, hogy ez megint politika...
- A hozzászóláshoz be kell jelentkezni
en csak picsogast hallok.
- A hozzászóláshoz be kell jelentkezni
Ja, ez vérmérséklet kérdése. Nekem az egész systemd haterkedés picsogás.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Egészen addig, amíg nem szívsz egy orbitálisat miatta.
- A hozzászóláshoz be kell jelentkezni
Állítólag hosszú évek óta használom, de hogy őszinte legyek, azt sem vettem észre, hogy bevezették.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Akkor mákod van. Vannak még páran ezzel így.
- A hozzászóláshoz be kell jelentkezni
Nagy máknak kell lennie, mert az elsődleges gépemen immár 20 éve Linux van, napi 12+ órát nyomkodom és nem futottam bele. Ráadásul desktopon, ami jóval több kihívást tesz a rendszer elé, mint adott esetben korlátozott szerepkörrel rendelkező szerver.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ez nem idő, vagy hozzáértés kérdése, hanem szerencséé, hogy mikor futsz bele egy systemd bugba, vagy marhaságba. Kinek a hibája, hogy a systemd nem ellenőrzi, hogy a pointerei mutatnak-e valahova? A júzeré, vagy a fejlesztőé? És elsősorban nem is az a baj, hogy volt benne egy dereferencing hiba, mert bárki hibázhat, hanem az attitűd, hogy ők ezt nem fogják kitesztelni, meg kijavítani, küldjön be patchet a júzer. Végül inkább bedrótozták, hogy cgroups nélküli kernel esetén be sem bootol. Ami egy dolog, mert a system-crasht így is megoldották, de hány ilyen lehet még benne?
- A hozzászóláshoz be kell jelentkezni
Bármikor belefuthatok bármilyen operációs rendszer alatt olyan bugba, hogy nem bootol be a rendszerem. Mint említettem, sosem futottam bele, pedig nem kizárólag LTS vonalat szoktam használni.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Mint mondtam, elsősorban nem maga a bug az, ami aggasztó, hanem a tendencia és az attitűd.
- A hozzászóláshoz be kell jelentkezni
Bevallom, nem szoktam aggódni a systemd miatt, attitűdről felhasználóként pedig kevés fogalmam van, mert nem találkozok a systemd fejlesztőivel. A téma is eléggé érdektelen számomra, most is csak azért írtam róla, mert jelentős lehet ennek a szavazásnak a végkimenetele. De, hogy éppen hogy áll a Poettering vs. haters fight, azt nem igazán követem. Számomra eléggé unalmas a téma.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Te eleg sok mindent annak hallasz minden letezo topikban :)
- A hozzászóláshoz be kell jelentkezni
jon egy senki projekt majd besir hogy ajjajjj hat nem fogjuk tulelni!!!!!1111
nekem ez a szintiszta picsogas. a fo kerdes, amit elfelejtettek feltenni mielott picsogtak: ki a halalt erdekel?
- A hozzászóláshoz be kell jelentkezni
Az a 3rd party programok fejlesztőin múlik, hogy dependelnek-e a systemd-re.
A probléma, ami miatt egyáltalán felmerült a Debian oldaláról a szavazás, hogy a különböző daemon-ok init szkriptjei legyenek egységesítve, ugyanis ha adott program fejlesztője vagy a csomag karbantartója úgy dönt, hogy nem törődik a többi init rendszerrel és csak egyre készíti fel a programját, akkor jön a sok hibajelentés a Debian-hoz, hogy ha másik init rendszert használ adott user, akkor nem megy a program/daemon.
Ezért merült fel, hogy ha már a systemd az alapértelmezett, akkor lehet értelmesebb lenne egységesen csak systemd-re karbantartani a csomagokat, így nem kell egy csomaggal kétszer-háromszor is "dolgozni".
Viszont ugye ennek negatív hatása, hogy azon fork-ok amik nem systemd-re épülnek csak veszíteni tudnak a helyzeten. Tehát vagy hagyni kellene a jelenlegi felállást, vagy a Debian-nak úgy kellene döntenie, hogy a systemd mellett még felkarolnak top tier-be még egy-két init rendszert és csak azok karbantartásával törődve meghagyni a lehetőséget a választásra.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
> Az a 3rd party programok fejlesztőin múlik, hogy dependelnek-e a systemd-re.
Az oké, de én a csomagokról beszéltem, nem a bennük lévő programokról.
> A probléma, ami miatt egyáltalán felmerült a Debian oldaláról a szavazás, hogy a különböző daemon-ok init szkriptjei legyenek egységesítve, ugyanis ha adott program fejlesztője vagy a csomag karbantartója úgy dönt, hogy nem törődik a többi init rendszerrel és csak egyre készíti fel a programját, akkor jön a sok hibajelentés a Debian-hoz, hogy ha másik init rendszert használ adott user, akkor nem megy a program/daemon.
> Ezért merült fel, hogy ha már a systemd az alapértelmezett, akkor lehet értelmesebb lenne egységesen csak systemd-re karbantartani a csomagokat, így nem kell egy csomaggal kétszer-háromszor is "dolgozni".
Igen, erről beszéltem, hogy ha tényleg maga a program (vagy daemon) függ tőle és ebből sok lesz, akkor megszívták. De eddig nem nagyon van ilyen.
> Viszont ugye ennek negatív hatása, hogy azon fork-ok amik nem systemd-re épülnek csak veszíteni tudnak a helyzeten. Tehát vagy hagyni kellene a jelenlegi felállást, vagy a Debian-nak úgy kellene döntenie, hogy a systemd mellett még felkarolnak top tier-be még egy-két init rendszert és csak azok karbantartásával törődve meghagyni a lehetőséget a választásra.
Az utóbbi jobb lenne (ha pl. bevennék az s6-ot, az OpenRC-t, vagy a runit-et), csak akkor megdől az egykori "magyarázatuk", hogy azért lett systemd, mert a SysVInit elavult és nincs karbantartva, hiszen akkor is válthattak volna a beemelt init rendszerek bármelyikére. Így szerintem vagy systemd-only lesz a karbantartás, vagy esetleg meghagyják a jelenlegi felállást...még egy darabig... De ne legyen igazam.
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy egyrészt nem használják eléggé az interfészen keresztüli függőséget avagy virtuális csomagokat (amikor több package is létezik, ami provide-ol valamit, és attól függnek mások, nem a konkrét csomagtól), és nincs init rendszertől független leíró formátum arra, hogyan kell egy szolgáltatást elindítani. Ha ez menne, a csomagok 99%-a minden további törődés nélkül is leszarná, hogy milyen init rendszer fut alatta.
Amúgy miért csak a D jó nekik? Én az A-t és E-t is úgy olvasom, hogy támogatják a systemd-től eltérő rendszereket.
A systemd se lenne olyan rossz, ha nem lenne olyan monolitikus. De amíg működik a linuxom, addig személyesen nem is nagyon érdekel, mi fut alatta.
- A hozzászóláshoz be kell jelentkezni
Ugyanitt: Distribution Release: Devuan 2.1 (2019.11.25.)
- A hozzászóláshoz be kell jelentkezni
Értelmetlen dolognak látszik a Devuan. Lehet ellenszenves a systemd, de a systemv init rendszer szarabb.
Lógok a szeren (K. Frigyes)
Lógok az ereszen (Sz. József)
- A hozzászóláshoz be kell jelentkezni
Egy érv a SysVInit ellen az nem érv a systemd mellett. Tonna egyéb initrendszer van rajtuk kívül...
- A hozzászóláshoz be kell jelentkezni
> Tonna egyéb initrendszer van rajtuk kívül...
De hát a Poettering is megmondta, hogy nincs alternatíva!!!!444!!!!4négy!
- A hozzászóláshoz be kell jelentkezni
Igen, mindenki tudja már hosszú-hosszú évek óta, hogy a SysVinit-nek vannak hátrányosságai, meg nincs annyi funkciója, mint a többinek, de valahogy soha senki nem vette a fáradtságot, hogy javítson rajta.
A probléma inkább az, hogy a Debian a SysVinit dobásakor nem a normális alternatívákból választott magának (runit, OpenRC), hanem egy olyan megoldást, ami már koncepciójában rossz és kb minden kiadáskor van benne olyan hiba, ami nagyon kezdő szintű, vagy olyan "feature"-t raknak bele, amit senki nem kért vagy olyan default beállításokkal érkezik, ami biztonságilag megkérdőjelezhető (lásd mikor a DNS feloldás szerver megadása nélkül alapértelmezetten a Google-re mutatott.)
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Èn azt tapasztalom, hogy a Devuan és MX Linux gyorsabb, mint a Debian. Nem a Systemd-vel van bajom egyébként, hanem az indokolatlan bloat-osodással, holott tudom, ez a világ rendje, minden bonyolódik és lassul. De miért is? Miért kell ennek egyébként törvényszerünek lenni?
- A hozzászóláshoz be kell jelentkezni
Mert ez "költséghatékony". A mammutok minél hamarabb és minél kevesebbért akarnak produktumot, az meg ezzel jár.
- A hozzászóláshoz be kell jelentkezni