"Biztos vagyok benne, hogy a Devuan nem fog túlélni a Debian segítsége nélkül"

Címkék

A Debian projekt egy General Resolution (GR) szavazást tart arról, hogy milyen úton haladjanak tovább init rendszer szempontból. Maradjon-e az "init diversity" hozzáállás, vagyis támogasson-e a Debian több init rendszert, vagy tegyék le a voksukat kizárólag a systemd mellett és csak azzal foglalkozzanak? Esetleg a systemd fókusz mellett támogassák egyéb alternatívák keresését is?

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:

If Debian drops the support for any other init system but systemd, I believe we won’t be able to keep up with the legwork needed to support all other init systems. I say this because we do not have a comparable amount of people and resources to face the huge amount of work Debian will cease to do. Of course quality matters, but not that far.

If the Proposal D by Ian Jackson will not pass, Devuan will die.

Részletek itt.

Hozzászólások

Szerkesztve: 2019. 11. 26., k – 09:29

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.

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 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.

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?

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

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"

> 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.

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.

É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)

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"

È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?