A Debian apt hamarosan Rust-függő lesz és ez alól egy port sem lesz kivétel

Debian

A Debian és Ubuntu fejlesztő Julian Andres Klode a debian-devel levelezési listán bejelentette, hogy az apt-nak 2026 májusától kemény (hard) Rust függősége lesz és abba Rust kódok fognak kerülni:

I plan to introduce hard Rust dependencies and Rust code into APT, no earlier than May 2026.

A lépés ellen annyira nincs apelláta, hogy a portokat karbantartók figyelmét is felhívta: 6 hónapjuk van a Rust követelmények (Rust toolchain) bedolgozására, vagy ha nem teszik, akkor szüntessék meg a portot. 

If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port.

A fejlesztő szerint erre azért van szükség, hogy haladjanak a korral:

It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.

Bejelentés itt.

( Caro | 2025. 11. 03., h – 10:16 )

Nem egészen értem a végét.

Nem úgy volt, hogy a rust amúgy relatíve hatékony kódot fordít? Vagy mégsem annyira?

Szerintem inkább a target platformok számosságáról van szó.

szerk, mondjuk a threadben egy dolog van még csak, ez nagyjából kihúzni látszik a dolog méregfogát (és egyben azt is mutatja, hogy emberünk nem annyira van feltétlen képben az állapotokkal):

Rust is already a hard requirement on all Debian release
architectures and ports except for alpha, hppa, m68k, and
sh4 (which do not provide sqv).

Ezt mondjuk nem értem, hogy miért. Legalább lehetne valamilyen fallback, hogy köpjön ki C-t, aztán C fordító meg van bármire.
Azért nincs, mert akkor egyből leesne még a fordítóprogramokban kevésbé jártasaknak is, hogy hullára felesleges a Rust, sok hűhó semmiért, hiszen C-ben is meg lehet csinálni mindent (igen, van memory safe C fordító is).
Ugyanakkor csomó mindent, amit C-ben meg lehet csinálni (pl. kettős láncolt lista vagy normális date) egyáltalán nem is lehet megcsinálni safe Rust-ban, de akkor meg eleve minek a Rust ugye.
Azt nem tudom mennyire használható már a Fil-C, mindenesetre érdemes észben tartani, hogy még csak pár hónapos projekt.
De lehetséges a memory safe C, és létezik is. Megjegyzem, a Ballard-féle TCC is rendelkezik beépített memory safetyvel, de nem annyira fejlett, mint ezé. Valamint a gcc, CLang is rendelkezik ilyen kapcsolókkal (ismét: jó, de nem annyira fejlett, mint ezé.)

Azon is érdemes elgondolkodni, hogy sem a Fil-C, sem a TCC, sem a gcc, sem a CLang nem igényel szintaktikai változtatást a nyelvben ahhoz, hogy memory safe kimenetet fordítson.

Szerintem én vagyok az egyik legnagyobb C-fan, de azért lássuk be: lehetne jobbat kitalálni.

Nekem a C-ből baromira hiányzik a C++ féle RAII.

Csak a C++ egyéb komplexitása meg nem hiányzik.

El tudnék képzelni egy nyelvet a kettő között, nem is feltétlenül 100% performance-ra kihegyezve, de egy kicsit kényelmesebb használatra.

azért lássuk be: lehetne jobbat kitalálni.
Ez általánosan igaz mindenre és bármire is.

A C nyelv legnagyobb előnye, hogy pofonegyszerű. Ha az utóbbi sztandardok agyhalott bővítményeit nem számítjuk és csak az alapnyelvet nézzük, akkor azt látjuk, végtelenségig le van egyszerűsítve, kb. egy tucat kulcsszó, párszáz sorban implementálható fordító és szabványos, betonszilárd ABI. (És persze ezek következményei: fénysebességű fordítás és portabilitás a köbön.)

Erre mondta Antoine de Saint-Exupéry:
Nem akkor alkottál tökéleteset, ha már nem tudsz mit hozzátenni, hanem ha már nem tudsz mit elvenni belőle.
Nekem a C-ből baromira hiányzik a C++ féle RAII.
Nekem egyáltalán nem, sőt, én kifejezetten hátránynak tartom a RAII-t. Ne akarja a gép eldönteni helyettem, hogy kié a buffer, tudom én azt jól (tisztában vagyok vele, hogy e téren kivételnek számítok, a legtöbb programozó nem így látja).

Amit én hiányolok, az nem is igazán C, hanem inkább a POSIX sara, hogy nincsen rendesen specifikálva a libc: egyrészt UB mentesnek kéne lennie már eleve a speckónak, másrészt nincs elkülönítve egyértelműen benne, mely függvények tartoznak a nyelvhez, és melyek az oprendszerhez (persze, van átfedés e kettő között, de akkor is). Ez nyilván csak bosszúság, amivel meg lehet tanulni együttélni, ez inkább a fordítót íróknak szopás (engem is emiatt bosszant a dolog, nem a nyelvet használóként).

A C egy Assembly, makrókkal.
Nekem teljesen jó volt, még az OO se hiányzik, hiszen van benne struct, meg függvénypointerek.

Amikor tanultam C-ben programozni, még kimondottan faszaságnak számított a pointer-aritmetika. Manapság meg pont azt irtják tűzzel-vassal a nyelvekből.

Azt is látom persze, egyesek hogyan fejlesztenek. Nem is csoda a sok overflow, underrun, memory leak. Összebasznak valamit, hogy lehessen mutatni valami működőnek tűnőt, amikor délután feljön a főnök. Aztán persze marad úgy a kód a picsába, hiszen működik. Lásd heartbleed.

A C egy Assembly, makrókkal.
Ezt láttam már mástól is, de nem igaz. Az Assembly gépfüggő és nincsenek benne vezérlési struktúrák, ellenben a C platformfüggetlen és strukturált.

Bizonyos assemblerek rendelkeznek olyan elképesztően fejlett makrórendszerrel, amivel elérhető a HLA, de az még mindig nem éri el a C strukturáltság szintjét (de legalább már leírhatod benne, hogy "for" meg "if") és továbbra sem fordítható bármilyen architektúrára, hanem csak egyetlen egyre.
Azt is látom persze, egyesek hogyan fejlesztenek.
Mindig mondtam, hogy aki azt állítja, "egy új nyelv majd helyettesíti a képzett programozót", az hazudik. Ennek ellenére minden új nyelv esetében megpróbálják ezt elsütni, aztán mindig kiderül, hogy a kellően balfasz bármilyen nyelven képes szar kódot írni.
Hogy a Rust-nál maradjunk, még a dátumkezelés is meghaladta egyesek képességeit, a safe memory nem oldotta meg helyettük.

Próbáld meg a terelést elengedni. Linux userek halmazán az Ubuntu és leszármazottai kb. a legnépszerűbb Linux disztribúció. Most tényleg beleálltok olyan fogyatékosságba, hogy az állításotok szerint telepíthetetlen, használhatatlan OS-nek sok milliós felhasználótábora van mert <ide jön a fals indoklásotok> valahogy feltelepült náluk csoda folytán és nem vették észre?

trey @ gépház

Szerintem a Distrowatch létezése óta az a konszenzus, hogy az ottani toplista semennyire nem korrelál a valós használattal. Most például a közismert CachyOS vezeti a tabellát, több mint másfélszer annyi ponttal, mint az ezüstérmes Mint. De ha jól rémlik, talán a bP is elért valami igen előkelő helyet valami hasonlóan objektív felmérésen.

Persze ha nem tükrözi a világnézetünket egy rangsor, toplista akkor minden lehet csak objektív nem. Ez a szép új szocmédia buborék-világa! 

Valamiért a Digitális Jólét Szoftver Alapcsomag is inkább Linux Mint-re épül és nem Ubuntura. Distrowatch-éknál ugye második helyen van a Mint most. 

Kicsit lentebb a nagy Ubuntu-advokációban Trey ezt is behallucinálta: "Nem beszélve, hogy a nagy cégek az Ubuntu-t támogatják elsősorban, így ha az Ubuntu-hoz értesz, akkor a nagy cégek szaraihoz is értesz."

Lehetséges, hogy neki a "nagy cég" valami teljesen mást jelent mint mindenki másnak. Nos én egy elég nagy cégnél dolgozok. Van is szerepe a Linuxnak, ami folyamatosan nyomja ki a megmaradt mainframe rendszereket. De itt a Linux a RHEL. Más Linux nem létezik, leszámítva természetesen azokat a speciális konferencia, vagy hálózati stb eszközöket ahol a gyártó egybegyógyítja a termékét egy saját Linux alapú rendszerrel és egyben vállal rá garanciát és supportot. Persze Ubuntu azokon sincs. 

Olyan fura helyzetek is vannak, hogy Orace-ön kívül semmi más szolgáltatás nem megy egy RHEL-on, mégis az van. Pedig lenne tök ingyen Oracle Linux is supporttal mindennel, mert úgyis fizetünk az Oracle db-ért jó sokat de nem, fizetünk a RHEL-ért is. Még az sem érv, hogy a team így egységesebben kezeli, hogy minden RHEL, mert a DB-khez külön team van. Ubuntu még csak fel sem merül mint server os alternatíva, mint desktop meg pláne nem. 

Persze na nem tükrözi a világnézetünket egy rangsor, toplista akkor minden lehet csak objektív nem

Nincs ilyen összefüggés. Ez a toplista akkor sem volt objektív, amikor véletlenül pont az én világnézetemet tükrözte.

De oké, ráharapok a csalira, magyarázd el nekem akkor, hogy mi ez a CachyOS, és hogyan, mikor lett a világ legnépszerűbb Linux disztribúciója, magasabb pontszámmal, mint az Ubuntu és RHEL együtt.

DistroWatch-ot sokan félreértik, te is. Az nem egy "objektív telepítési bázis" statisztika olyan nincs is Linuxon és nem is állítottam ilyet, hanem egy trend-mutató. Azt méri, mi iránt érdeklődnek most az emberek Linux világban és azon belül is hangsúlyosan desktop linux világban, mire kattintanak rá.

Hogy miért van elől a CachyOS? Pont azért, amiért az Ubuntu hátul. A CachyOS egy agresszívan teljesítményre optimalizált (x86-64-v3/v4, egyedi kernelek, stb.) Arch-alapú rendszer. A desktop felhasználók és gamerek, akik ugyebár a DistroWatch fő közönsége most éppen a maximális teljesítményt keresik, nem a biztonsági játékot. Ez egy tökéletes látlelet a jelenlegi desktop trendről. a linuxos népek éppen unják a "bloat"-ot, és sebességet akarnak.

Valve-nál nem a DistroWatch-ot nézegették, hanem a technológiai realitást. Miért dobták SteamOS-nál az Ubuntu vonalat az Arch-ért? Mert gamingre, friss driverekre és flexibilitásra az Arch és a rá épülő ökoszisztéma jobb választás. A DistroWatch-on az Arch és derivátumai (Endeavour, Manjaro, Cachy) összesítve is tarolnak. Akkor a Valve-ot is megtévesztette a DistroWatch trend? :) Vagy inkább csak ők is ugyanazt látták meg, amit a felhasználók és DistroWatch olvasók?  

Az Ubuntu a desktopon régóta saját maga ellensége. Snap erőltetése, vitatható UX döntések, stb. A Linux Mint megcsinálta az Ubuntut jól, klasszikus desktop élménnyel. Nem véletlen, hogy a magyar kormányzati csomag is inkább ehhez nyúlt alapként, amikor stabil, használható desktop kellett az átlagembernek és nem Ubuntuhoz. 

Ami a RHEL-t illeti,  az egy vállalati szerver OS. Semmi keresnivalója egy desktop népszerűségi lista élén, teljesen irreleváns itt emlegetni.

Szóval a lista lehet, hogy nem "objektív" a telepített darabszámra nézve, de tűpontos abban, hogy megmutassa: a desktop közösség fókusza elmozdult az Ubunturól a teljesítmény, Arch-világ és a klasszikus használhatóság, Linux Mint felé.

Steam Hardverfelmérés ami kemény adat, bár ott is vannak torzító tényezők. A gamerek között az Ubuntu már csak a futottak még kategória.

SteamOS (Arch alapú): ~27% (Messze az első)

Arch Linux (önmagában): ~10%

Ubuntu (LTS verzió): ~3.7% 

Tehát a Steam-en az Arch-család (SteamOS + natív Arch + Manjaro stb.) brutálisan, többszörösen veri az Ubuntut.
 

DistroWatch-ot sokan félreértik, te is. Az nem egy "objektív telepítési bázis" statisztika olyan nincs is Linuxon és nem is állítottam ilyet, hanem egy trend-mutató. Azt méri, mi iránt érdeklődnek most az emberek Linux világban és azon belül is hangsúlyosan desktop linux világban, mire kattintanak rá.

A distrowatch azt nézi, hogy mi iránt érdeklődik a linuxosoknak az a nagyon kicsi szeglete, akit az egész distrowatch és környéke nem hagy mélységesen hidegen. Teljességgel belterjes, nagy jóindulattal is csak maximum másodlagos trend indikátornak lehet nézni, hogy ami ott épp az arcán pörög, az esetleg lehet, talán, hogy máshol is.

Sajnos ma sem tart még ott a Desktop Linux részesedése, amin belül a Distrowatch csak egy kicsi szeglet tudna lenni. Talán még a Distrowatch portál tulajdonosai is örülnének annak, ha egyszer elérnénk ezt az állapotot, azaz olyan nagy lenne a desktop Linux, amin belül a DW látogatók csak egy niche szubkultúrát képviselnek. Itt Linuxon a deskop-ra használt GNU/Linux rendszereket értem. Természetesen nem Android mobil, tablet, Google okostévé, Chromecast, Xiaomi tv stick meg hasonló "desktop" linuxokra, amikből valóban ma már rengeteg van, és a userek többsége szerintem azt sem tudja, hogy az eszközében ott a mélyben Linux kernel dolgozik. 

A DW inkább a derivált függvény, ami valamennyire a jövő értékét jósolja meg. Ami iránt sokan érdeklődnek az potenciálisan szélesebb körben használt desktop Linux lesz. Csak hát az Ubuntu már abban a múltban is messze volt a dobogótól, aminek a jövője már a mi jelenünk. 

A Steam Hardverfelmérés adatai sem azt mutatják, hogy domináns lenne desktop linuxon az Ubuntu és ez már kemény adat, amit a Valve gyűjt ha megengedi a gamer aminek előfeltétele természetesen, hogy lássa az opt-in részvételi ablakot. Persze ők csak gamerek. De megint sajnos emlékeztetnem kell arra, hogy az irodai desktop GNU / Linuxok hatalmas tömegeiről nem beszélhetünk. Abban a szűk rétegben, aki desktopon Linuxozik, nem egy elhanyagolható kicsi szubkultúra az amelyik legalább próbál játszani is Linuxon. Egyébként aki próbálja a gaminget Linux-szon évek óta azt tapasztalja, hogy meglepően jól működnek a Win32/64 játékok Linux-on a Valve protonos beavatkozása előtti frusztrált időszaktól eltérően. 

Itt több különböző független forrást soroltam fel a korábbi hozzászólásaimban és egyik sem mutatja azt, hogy az Ubuntu desktop linux domináns pozícióban lenne. 

Niche szubkultúra a desktop Linux-felhasználók köre önmagában is. 

Továbbá, már unom ismételni önmagamat, de ott a 

Steam Hardverfelmérés (Linux-only nézet).

Ha ez sem elég, akkor még

ProtonDB (Linux Gaming jelentések) ami részben fedi át az előzőt.

GamingOnLinux (GOL) statisztikák

Reddit r/linux és r/linuxmasterrace éves felmérések.

Egyrészt vegyük észre, hogy ezt a desktop dolgot te rángattad ide, előtte linuxról volt szó. 

És lehet egyébként erőlködni, de valódi produktív környezetekben kb vagy ubuntu, vagy RH van (esetleg valami rokialma, de az ebből a szempontból egykutya). Honorable mention a SLESnek, mivel még léteznek, ezért gondolom valahol vannak cégek, akik azon tolják. Imho ubuntu is csak azért van ennyire, mert az RH elbaszta, nem lehetett RH alapú instancokat csinálni ingyér, ezért egy csomóan az ubira nyomták a dolgaikat. Konténer világban még előfordul az alpine, mint valamennyire jelentős szereplő, sztennyi.

Sajnos ma sem tart még ott a Desktop Linux részesedése, amin belül a Distrowatch csak egy kicsi szeglet tudna lenni.

Hát pedig, tök irreleváns. Biztos vannak ott valakik, aki nézelődnek, jellemzően az ilyen distrobuzik, akiknek ez a hobbijuk. Egyébként meg, nézd, én 25 éve tolom linuxokkal, olyan környezetben mozgok, ahol nem én vagyok a csodabogár ezzel, embert nem láttam még élőben, aki bármi miatt magától odament volna a distrowatchra. Nem néha, egyszer se, soha senkit. Azon kívül, hogy mutogatni szoktak rá fórumokon, meg az újságírók, mer yáy százalék, dejó, a döglött kutyát nem érdekli.

A valve és a környéke már kicsit jobb, de szerintem a játékosok arányát is felülértékeled. 

Szóval az van, hogy desktopon kb a következő szokott lenni: ubi/fedora/arch. Van néhány bogárka, aki valami éppen aktuális arch vagy ubi deriválttal baszódik, míg meg nem döglik érdeklődés hiányában (vagy ki nem derül, hogy jól csinálni kurvasok munka), múltkor láttam egy tagot gentooval, talán tudok 1-2 debianost, a neten szoktam olvasni, hogy emberek használnak manjarot. Szóval tolhatod azt, hogy az ubuntu sose volt élvonal, de hogy a valóságban meg erősen úgy tűnik, hogy de, baromi sokan azt tolják. Az én környezetemben biztosan az látszik, hogy ők a legnagyobb homogén csoport. Tippre az 50% felett is simán vannak.

Szerintem a trey féle #worksforme kinyilatkoztatás egyértelműen desktop felhasználásról szól. Ennek a szálnak az volt a kiindulópontja. 

"(esetleg valami rokialma, de az ebből a szempontból egykutya)."

Oracle Linuxot kifelejtetted. Bizonyos szempontok szerint a legnyerőbb a RHEL klón triumvirátusból. 

"embert nem láttam még élőben, aki bármi miatt magától odament volna a distrowatchra."

Én pedig az egyetemen egy hallgatótársat nem láttam, aki hallott volna a hup-ról. Pedig volt ott is pár linux csodabogár, aki például Linux-al szopatta magát a C++ laborokon:)
Néha én sem értem mit keresek itt a sok tata között:D

"A valve és a környéke már kicsit jobb, de szerintem a játékosok arányát is felülértékeled." 

Niche bázison minden számít. Sőt a Steam Deck miatt a desktop Linuxosok legnagyobb monolit tömbje lehet. Persze azt is elfogadom érvnek, ha nem tekinted desktop linuxnak azt a Steam Deck-et, amit kizárólag Game Mode-ban használnak. Mert így a Deck olyasmi Linux kategória mint az Android, meg Tizen és webOS, ahol a user azt sem tudja néha, hogy linuxot használ. 

"Szóval az van, hogy desktopon kb a következő szokott lenni: ubi/fedora/arch."

Valójában desktop linuxon a következő szokott lenni, ebben a sorrendben: Arch/Mint/Fedora. 

"Szóval tolhatod azt, hogy az ubuntu sose volt élvonal"

Régen, amikor még volt saját Unity desktopjuk miközben a Gnome3 éppen mintha gépfegyverrel irtotta volna a usereit népszerű volt az Ubuntu. Utána lejtmenetbe került a Canonical, a fejlesztői száma is megtizedelődött. Lassan a legkitartóbb ubuntu desktoposok is felismerték, hogy Cinnamon miatt és jobb drivertámogatás miatt a Linux Mint kényelmesebb választás. Majd utána jött fel az Arch mint a talajvíz. 

Az én környezeteben például senki nem használ Ubuntu desktopot. 

Debian = laggard Ubuntu rendes support nélkül

Itt a példa, hogy ami bekerül az Ubuntu-ba, az megy be a Debianba is (systemd, Rust stb.), plusz az Ubuntu Pro kurva sokat ad hozzá. Nem beszélve, hogy a nagy cégek az Ubuntu-t támogatják elsősorban, így ha az Ubuntu-hoz értesz, akkor a nagy cégek szaraihoz is értesz.

Pl. a HPE VM Essentials virtualizáció, amit a HPE most kalapál a piacra ... dobpergés ... Ubuntu alapú. 🤷‍♂️

trey @ gépház

Debian = laggard Ubuntu

Mondjuk mostanában ritkán látok Debiant, de úgy tűnik azért ez már nem annyira igaz

rendes support nélkül ... Ubuntu Pro ... nagy cégek

Ez igen, mondjuk a saját tapasztalataim az ubuntu supporttal azért nem a "rendes" szóval írnám le, bár tény, hogy nem sok volt, és azok nem tipikus support ügyek voltak

Itt a példa, hogy ami bekerül az Ubuntu-ba, az megy be a Debianba is (systemd

Hát az mondjuk pont fordítva volt, azért ment az upstart a levesbe az ubinál (és ettől mindenhol is, mivel az ugye saját lófasz volt), mert a debian systemdre váltott

Rust stb.)

Hát, ha jól értem, ezzel már a debianosok is megvannak, nem tudom ki volt előbb. Gyanús, hogy az apt rustosításával viszont így a debian lesz előbb.

Illetve azért az Ubuntura elég jellemző, hogy tesznek az egyik lóra, a világ meg megy a másikra (including debian), lásd az emlegetett systemd, mir, snap... szóval azért ez a laggard ubuntu nem teljesen állja meg a helyét, van ott még más is.

?

https://hup.hu/comment/3233317#comment-3233317:

"Rust is already a hard requirement on all Debian release
architectures and ports except for alpha, hppa, m68k, and
sh4 (which do not provide sqv)."

A szál egyetlen hozzászólása az, hogy egy másik deb fejlesztő szól, hogy FYI valójában már most is hard req néhány unofficial architektúrát leszámítva (amik az ubuntuban nincsenek is, amiga, meg ilyenek, érted) szóval alapvetően nyitott kapukat dönget, írhat kb nyugodtan rustban.

Nyilván az ubiban is már hard req, ha abban van a coreutils a releaselt verzióban. Nem tudom, hogy hol volt előbb rust, fingom sincs, hogy a syncben mennyire van kivételesen kezelve az ubuntuéknál a rust stack. Lehet, hogy ott előbb volt kész, mint mondtam. Az meg ez alapján gyanús, hogy az apt rusosítása meg a debben fog megkezdődni előbb, és majd szállingózik le downstream.

Mihez copeoltam, segíts.

Teljesen természetes, hogy az Ubuntu időről időre a 'laggard' Debian aktuális állapotát forkolja (SID vagy Testing, végül is mindegy), aztán a saját dolgaival összecsiszolja jobban vagy rosszabbul. Igaz, hogy ez így fából vaskarika, de ne akadjunk fenn ezen.

A support hangsúlyozása is tetszik. Emlékszem egy nagyon régi esetre, amikor webes levelezőservert kellett összeraknom (Imp+Horde) , és mivel az Ubuntu aktuális kiadása mindig frissebb csomagokat tartalmaz, az volt az alap, és valamelyik csomagnak függőségi problémája volt, az adott verziójú valamelyik PHP kiterjesztés hiányzott. Természetesen nem én voltam az egyetlen ezzel a problémával, megtaláltam a bugreportot, az adott válasz az volt, hogy az adott csomag nem a main tárolóban van, hanem a restrictedben (vagy a universe-ben, fene se emlékszik már rá), azzal nem foglalkoznak. Hoppá.

Nyilván közösségi support volt, de az adott csomag Debianban a mainben volt, ha ott jön egy ilyen bugreport, azt ilyesmivel nem zárják le. Természetesen ez nagyon régi eset, volt vagy húsz éves, azóta nyilván sokat változott az Ubuntu hozzáállása is, szóval kár lenne általánosítani, ez csak egy kis színes történet :)

Itt a példa, hogy ami bekerül az Ubuntu-ba, az megy be a Debianba is (systemd...

Ez leginkább arra példa, vagy inkább bizonyíték, hogy nem érted a belső összefüggéseket. 

Az a kijelentés, hogy a systemd Ubuntuból ment volna a Debianba, 100%-ban téves! Sőt, pont az ellenkezője igaz a befolyást tekintve.

A valós idővonal a mi Univerzumunkban a következő volt:

  1. A Kiindulópont: Az Ubuntu a saját Upstart init rendszerét fejlesztette. A Debian eközben a klasszikus SysVinit-et használta.
  2. A Kívülálló tényező: A systemd a Red Hat / Fedora ökoszisztémából, Lennart Poetteringtől, legyen átkozott a neve, érkezett, mint egy radikálisan új koncepció.
  3. A Harc, az Init Wars: a nagy csata valójában a Debian közösségében zajlott és végül sajnos engedtek a systemd erőszaknak.
  4. A Döntés: Debian hosszú, véres vita után végül systemd mellett döntött.
  5. A Következmény: Mivel az Ubuntu upstream-je a Debian, így a systemd-t választotta, mert az Ubuntunak nem maradt más választása, mint eldobni a saját fejlesztésű Upstart-ját és követve a Debiant szintén átállni systemd-re. Pedig az Upstart még jó is volt. 

Tehát a systemd nemhogy nem Ubuntuból ment a Debianba, hanem a Debian systemd-re váltása kényszerítette ki az Ubuntunál is a váltást, eltemetve ezzel az saját Upstart projektet.

Ez a váltás azért volt kényszerű, mert a tágabb Linux ökoszisztéma, élén a GNOME asztali környezettel, a systemd-t tette meg hard dependencynek. Aki nem systemd-t használt, az egy idő után nem tudta futtatni a legfontosabb szoftvereket.

Szerencsére ott volt az OpenRC a NetBSD projektből, amit Linux oldalon felkarolt először a Gentoo és Devuan, majd megoldották OpenRC-ban, hogy tudjon futni a Gnome3 vele, megszüntetve az erőltetett systemd függőséget. 

Mivel az Ubuntu upstream-je a Debian, így a systemd-t választotta, mert az Ubuntunak nem maradt más választása, mint eldobni a saját fejlesztésű Upstart-ját és követve a Debiant szintén átállni systemd-re.

Mondjuk ez a kényszer nemlétező volt, mivel előtte sem ugyanazt az init rendszert használták, mint a Debian, pont te írtad le, hogy eltértek tőle. Akkor miért is kellett volna átvenniük a systemd-t? Hiszen az is az ő választásuk volt, hogy sysvinit helyett upstartot használnak. Senki nem kényszerítette a Canonicalt arra, hogy átvegye a Debian initjét.

Jó, akkor rakjuk helyre a képet, mert itt alapvető félreértések vannak. A vita nem arról szól, hogy "béka vagy körte", hanem a kompatibilitásról és a fölérendeltségi viszonyokról.

Nem érted, mi az az "Upstream"!
Az, hogy az Ubuntu downstream eltért a Debian, az upstream SysVinit-jétől, pont az én álláspontomat bizonyítja. Az Ubuntu alárendelt szerepben van. Mivel a csomagbázisa 90%-át a Debiantól kapja, eleve úgy kellett megterveznie a saját Upstart-ját, hogy az 100%-ban kompatibilis legyen a Debian SysVinit szkriptjeivel. Ez egy "barátságos", kompatibilis eltérés volt, ami nem törte szét az ökoszisztémát.

Ezzel szemben a systemd ami a Red Hat-tól jött egy agresszív, inkompatibilis váltás volt.

Az Ubuntunál soha nem születhetett volna meg egy systemd-hez hasonló romboló projekt, mert azzal durván szembementek volna a felettesükkel, a Debiannal és azonnal eltörték volna a kompatibilitást, ami az egész disztribúciójuk alapja.

A "Király" itt a Red Hat! A systemd ármányt nem véletlenül a náluk fejlesztette Lennart Poettering, legyen átkozott a neve:) Ők a Linux-világ alfája, vagy inkább alfahímje. Nincs felettesük, nincs upstream a Red Hat felett. A Fedora az ő kísérleti telepük. kvázi a Debian Sid megfelelője, amit ők irányítanak. A Red Hat megtehette, hogy diktáljon, és az egész ökoszisztémát,élén a GNOME-mal systemd-függővé tegye.

Az "Init Wars" helyszíne, a Nagy Init Vita nem az Ubuntu székházában Canonicalnál dőlt el, hanem az ő felettesüknél a Debian projektben.

Amikor a Debian a kemény függőségek, mint a GNOME3 beadta a derekát és átállt systemd-re, az Ubuntu kényszerpályára került. Választhattak, követik az upstream Debiant és az ökoszisztémát, GNOME. 
Vagy elvégzik azt a gigantikus pluszmunkát, hogy az egész Debian csomagbázist és a GNOME-ot is foltozgatják a saját Upstart-jukhoz.
De erre a Canonical már képtelen volt.

Ez nem az első eset volt, hogy az Ubuntu alulmaradt. Évekig próbálták a saját Unity desktopjukat lenyomni a világ torkán, de sem az upstream Debian, sem a függetlenek nem vették át. Végül költség- és erőforráshiány miatt kénytelenek voltak feladni a saját fejlesztésüket, és visszatérni az "ellenséges" GNOME-hoz. Pedig saját Unity desktop mellett a systemd kényszer sem lett volna akkora. 

És itt jön a legkínosabb pont. Miközben a dollármilliókból gazdálkodó Canonical megfutamodott, a formális céges háttér nélküli Gentoo és a "szakadár" Devuan közössége valóban megoldotta a systemd függőség feloldását az elogind projekttel. A Canonicalnál ezzel még csak nem is próbálkoztak.

A systemd akkor azért tudott győzni, mert a systemd nem csak egy init volt, hanem polipként terjeszkedett, és bekebelezett egy csomó alapvető Linux alrendszert. A GNOME volt a fő és legfontosabb függőség, ami a systemd-logind session management miatt kellett. De a kényszer más irányból is jött:

udev: systemd projekt egy ponton bekebelezte az udev-et. Egy ideig úgy tűnt, aki a legfrissebb udev-et akarja, annak systemdt is kell használnia.
LXC / Docker: modern konténerizáció egyre szorosabban integrálódott a systemd-vel.
NetworkManager: szintén a Red Hat/GNOME ökoszisztéma része, ami egyre több systemd specifikus funkciót kezdett el használni.

Lényegében az egész modern desktop és cloud stack elkezdte megkövetelni a systemd API-jait. A Gentoosok megcsinálták eudev-et az udev forkjaként. NetworkManager-t patcheli a Devuan és Gentoo, hogy systemd mentesen működjön. Általában elogind-et használják a session-kezeléshez. Legkeményebb dió az LXC / Docker volt. A Gentoo-sok és lázadó Jedi lovag barátaik erre is létrehoztak workaround-okat. Például run-cgroups és egyéb scriptek, amik az OpenRC számára is lefordítják a cgroups v2 kezelését. Ez egy folyamatos, komplex munka, de megcsinálták, és működik.

ha ugyanarrol beszelunk, a "mindig"-rol ezt mondja a baratom: "A systemd-sysv-generator már a systemd nagyon korai verzióiban is benne volt, konkrétan a 38-as verziótól kezdve (2011 körül). Ez az időszak volt az, amikor a systemd-t elkezdték a nagyobb disztribúciókban (Fedora 15, később Debian 8, Ubuntu 15.04 stb.) alapértelmezett init rendszerként bevezetni."

feltetelezem azert kerult bele, mert enelkul nem terjedt eleg gyorsan.

most pedig (debian13) :

systemd-sysv-generator[2511349]: SysV service '/etc/init.d/xyz' lacks a native systemd unit file, automatically generating a unit file for compatibility. 
systemd-sysv-generator[2511349]: Please update package to include a native systemd unit file. 
systemd-sysv-generator[2511349]: ! This compatibility logic is deprecated, expect removal soon. !

 

neked aztan fura humorod van...

Már leírtam a választ a kérdésedre az előbb. Akkor leírom másként. 

Papíron volt benne egy SysVinit-kompatibilitási réteg, ami a régi /etc/init.d/ szkripteket lefordítja. Nem is erről szól ez az egész.

Az "agresszív, inkompatibilis váltás" nem a visszafelé kompatibilitás hiányát jelentette, hanem az oldalra és felfelé irányuló kényszer-függőségeket, amiket az ökoszisztémába hozott.

Az inkompatibilitás a következő volt:

1. Nem csak PID 1 lett: A systemd nem elégedett meg azzal, hogy egy init rendszer legyen mint az Upstart. Polipként bekebelezte az eszközkezelést udev, a logolást journald, a hálózatkezelést networkd, és a felhasználói bejelentkezéseket logind.

2. API-k mint Fegyver: A valódi agresszió az volt, amikor a Red Hat / GNOME ökoszisztéma kulcsfontosságú szoftverei, élükön a GNOME asztali környezettel elkezdték kemény, kikerülhetetlen függőségként használni ezeket az új, systemd-specifikus API-kat. 

3. A Valódi Inkompatibilitás: Hirtelen a probléma már nem az volt, hogy "hogyan indítsd el az Apache-ot". Hanem az, hogy ha a disztribúciód nem systemd-t használt, akkor nem tudtad futtatni a GNOME-ot, mert hiányzott belőle a logind API.
Ennek mentesítésére fejlesztették az elogind-t. 

Ez volt az inkompatibilis váltás! A systemd nem egy csereszabatos alkatrész volt, mint az Upstart, hanem egy komplett platform, ami ultimátumot adott az egész ökoszisztémának: Vagy engem használsz, vagy nem kapod meg a legújabb GNOME-ot, udev-et és NetworkManager-t.
A systemd, mint PID 1 egy GOD daemon, monolitikus rendszer, ami szöges ellentétben áll a klasszikus UNIX filozófiával: Minden program egy dolgot csináljon, de azt csinálja jól.

Na pont ezért nem szabad egy Google-keresés (vagy jelen esetben egy Gentoo Wiki link) után úgy beszállni egy vitába, hogy fogalmunk sincs a témáról!

Köszi, hogy belinkelted a Gentoo Wiki-t, mert pont a saját érvedet lőtted lábon vele.

Az a mondat, hogy "elogind is the systemd project's logind, extracted to a standalone package" (kivonatolt, önálló csomag), pont az én igazamat bizonyítja, csak te láthatóan nem érted, mit jelentenek ezek a szavak egy szoftveres monolit esetében.

Az "extracted" itt nem azt jelenti, hogy Ctrl+C, Ctrl+V, ahogy azt te elképzeled.

A systemd egy God daemon, egy monolit. A logind része szorosan össze van drótozva a systemd többi alrendszerével (journald, cgroups, dbus API-k). Onnan egy komponenst kivenni és önállóvá tenni nem fejlesztés, hanem sebészi műtét.

A Gentoo-s srácoknak ehhez:
1.  Forkolniuk kellett a kódot.
2.  Minden egyes belső systemd függőséget kézzel kellett kivágniuk és systemd-független helyettesítőkkel (shimekkel) pótolniuk.
3.  És ami a legfontosabb: ezt a "standalone" kódot folyamatosan karban kell tartaniuk. Valahányszor a systemd fő ága frissül, nekik újra és újra el kell végezniük ezt a sebészi munkát.

Szóval pont ez a "nem nagy fejlesztés" az, amit a dollármilliós Canonical nem volt hajlandó/képes megcsinálni az Upstart-ért, de a céges háttér nélküli Gentoo-s közösség igen.

Köszi, hogy segítettél alátámasztani. 

  1. Szálj le a magas lóról légyszives. Vagy ha már onnan osztod az áldást, linkeld hol állítottam a systemd-vel kapcsolatban bármit is.
  2. Arra reagáltam (de már megbántam), hogy azért az elogind nem egy új fejlesztés a systemd-logind kiváltására, hanem a systemd forrásából van kiszedve a logind és az van lefordítva külön. Nyilván vannak benne módosítások.

(github oldalon azt olvasom GNU Guix-os cucc, nem gentoos, de kb lényegtelen)

A Debian Wheezy tartalmazta először a systemd-t, akkor még mint technology preview https://www.debian.org/releases/wheezy/amd64/release-notes.en.txt (megjelenés 2013 május, nyilván a testing időszakban már benne volt) A Jessieben (2015. április) lett default init rendszer a systemd https://www.debian.org/releases/jessie/amd64/release-notes.en.txt 

Az Ubuntu a 15.04 release-ben vezette be a systemd-t https://wiki.ubuntu.com/VividVervet/ReleaseNotes#New_features_in_15.04

( hajbazer v | 2025. 11. 03., h – 11:18 )

Újabb, multinál dolgozó influenszerszerű babzsákfejlesztő, aki megérett rá, hogy eltiltsák a számítógéptől, de legalább a projektvezetéstől. Ha legalább technikai indokokat írt volna, de semmi mást nem sikerült kiszarnia magából, csak a szokásos fejlődésmániás divatbuziskodást és az eszközújravásárlást kötelezőnek feltételező szélsőséges idealizmust, amit "retrocomputing"-ellenességgel tálal fel.

( freeoli v | 2025. 11. 03., h – 15:14 )

Nem értettem sose ezeket a rinyálásokat. Én konzerv lunux user vagyok és teljes mértékben nem érdekel, hogy a disrto hogyan oldja meg a csomagkezelést. Ha szerintük így jó, hajrá, csak lenne már normális magyar ubuntu  forgalmazó. 

( x-daemon | 2025. 11. 03., h – 17:51 )

csak ennyi csomag kapott figyelmeztetest, hogy eltavolitjak a testingbol, ha nem lesz systemd unitja, hany eve nem sikerult mindegyik csomagnak megcsinalni? 

 

From: Luca Boccassi <bluca@debian.org>

To: 1039225@bugs.debian.org, 1039125@bugs.debian.org, 1039424@bugs.debian.org, 1039363@bugs.debian.org, 1039407@bugs.debian.org, 1039120@bugs.debian.org, 1039121@bugs.debian.org, 1039122@bugs.debian.org, 1039124@bugs.debian.org, 1039129@bugs.debian.org, 1039132@bugs.debian.org, 1039133@bugs.debian.org, 1039138@bugs.debian.org, 1039139@bugs.debian.org, 1039141@bugs.debian.org, 1039144@bugs.debian.org, 1039145@bugs.debian.org, 1039146@bugs.debian.org, 1039151@bugs.debian.org, 1039153@bugs.debian.org, 1039154@bugs.debian.org, 1039155@bugs.debian.org, 1039160@bugs.debian.org, 1039165@bugs.debian.org, 1039167@bugs.debian.org, 1039174@bugs.debian.org, 1039176@bugs.debian.org, 1039177@bugs.debian.org, 1039180@bugs.debian.org, 1039182@bugs.debian.org, 1039186@bugs.debian.org, 1039187@bugs.debian.org, 1039188@bugs.debian.org, 1039192@bugs.debian.org, 1039198@bugs.debian.org, 1039199@bugs.debian.org, 1039201@bugs.debian.org, 1039204@bugs.debian.org, 1039206@bugs.debian.org, 1039210@bugs.debian.org, 1039211@bugs.debian.org, 1039213@bugs.debian.org, 1039215@bugs.debian.org, 1039218@bugs.debian.org, 1039220@bugs.debian.org, 1039221@bugs.debian.org, 1039222@bugs.debian.org, 1039223@bugs.debian.org, 1039224@bugs.debian.org, 1039226@bugs.debian.org, 1039227@bugs.debian.org, 1039229@bugs.debian.org, 1039232@bugs.debian.org, 1039234@bugs.debian.org, 1039238@bugs.debian.org, 1039241@bugs.debian.org, 1039244@bugs.debian.org, 1039245@bugs.debian.org, 1039246@bugs.debian.org, 1039247@bugs.debian.org, 1039251@bugs.debian.org, 1039254@bugs.debian.org, 1039255@bugs.debian.org, 1039256@bugs.debian.org, 1039258@bugs.debian.org, 1039259@bugs.debian.org, 1039268@bugs.debian.org, 1039272@bugs.debian.org, 1039276@bugs.debian.org, 1039277@bugs.debian.org, 1039278@bugs.debian.org, 1039279@bugs.debian.org, 1039281@bugs.debian.org, 1039283@bugs.debian.org, 1039284@bugs.debian.org, 1039286@bugs.debian.org, 1039288@bugs.debian.org, 1039294@bugs.debian.org, 1039295@bugs.debian.org, 1039296@bugs.debian.org, 1039298@bugs.debian.org, 1039303@bugs.debian.org, 1039305@bugs.debian.org, 1039311@bugs.debian.org, 1039312@bugs.debian.org, 1039314@bugs.debian.org, 1039315@bugs.debian.org, 1039316@bugs.debian.org, 1039319@bugs.debian.org, 1039327@bugs.debian.org, 1039329@bugs.debian.org, 1039332@bugs.debian.org, 1039333@bugs.debian.org, 1039334@bugs.debian.org, 1039335@bugs.debian.org, 1039336@bugs.debian.org, 1039338@bugs.debian.org, 1039339@bugs.debian.org, 1039345@bugs.debian.org, 1039349@bugs.debian.org, 1039351@bugs.debian.org, 1039352@bugs.debian.org, 1039354@bugs.debian.org, 1039355@bugs.debian.org, 1039356@bugs.debian.org, 1039361@bugs.debian.org, 1039364@bugs.debian.org, 1039367@bugs.debian.org, 1039368@bugs.debian.org, 1039372@bugs.debian.org, 1039374@bugs.debian.org, 1039376@bugs.debian.org, 1039377@bugs.debian.org, 1039378@bugs.debian.org, 1039379@bugs.debian.org, 1039382@bugs.debian.org, 1039384@bugs.debian.org, 1039385@bugs.debian.org, 1039386@bugs.debian.org, 1039388@bugs.debian.org, 1039391@bugs.debian.org, 1039392@bugs.debian.org, 1039395@bugs.debian.org, 1039396@bugs.debian.org, 1039398@bugs.debian.org, 1039401@bugs.debian.org, 1039402@bugs.debian.org, 1039403@bugs.debian.org, 1039404@bugs.debian.org, 1039409@bugs.debian.org, 1039410@bugs.debian.org, 1039412@bugs.debian.org, 1039417@bugs.debian.org, 1039419@bugs.debian.org, 1039431@bugs.debian.org, 1039434@bugs.debian.org, 1039436@bugs.debian.org, 1039237@bugs.debian.org, 1039123@bugs.debian.org, 1039171@bugs.debian.org, 1039380@bugs.debian.org

Subject: ships sysv-init script without systemd unit

Date: Wed, 15 Oct 2025 16:24:56 +0100

neked aztan fura humorod van...

tobb, mint 2 eve. mire lesz eleg 6 honap? :)

"Dear Maintainer(s) of affected packages, these bugs have been open for more than 2 years now. Policy was updated to make units mandatory for system services. The removal of compat with sysv-init scripts from systemd has been postponed from trixie to forky, but it is now approaching. In approximately a month's time, this should hit unstable, if everything goes well. [...]"

neked aztan fura humorod van...

( gyuri23 | 2025. 11. 03., h – 18:40 )

Az informatika első törvénye: az új az egyben jobb is, amíg ki nem derül, hogy mégse, de azt meg úgy is letagadjuk.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.