A Linux from Scratch projekt vonakodva beismerte, hogy a jövő a systemd

Linux

A nagyobb mainstream Linux disztribútorok már rég eldöntötték a systemd vs. egyéb init rendszerek kérdést, de az olyan hardcore "disztribúciók", mint a Linux From Scratch (LFS) még kitartottak. Eddig. Ugyanis az LFS részéről Bruce Dubbs vonakodva bejelentette, hogy befejezik a System V-t tartalmazó dokumentumaik fejlesztését. Személyes véleményként megjegyezte, hogy nem szereti, de a karbantartási overhead és az upstream irányából érkező nyomás miatt meg kellett hozniuk a döntést:

With some regret, LFS/BLFS will no longer be developing the System V versions of the books.

There are two reasons for this decision. The first reason is workload. No one working on LFS is paid. We rely completely on volunteers. In LFS there are 88 packages. In BLFS there are over 1000. The volume of changes from upstream is overwhelming the editors. In this release cycle that started on the 1st of September until now, there have been 70 commits to LFS and 1155 commits to BLFS (and counting). When making package updates, many packages need to be checked for both System V and systemd. When preparing for release, all packages need to be checked for each init system. 

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V. This could potentially be worked around with another init system like OpenRC, but beyond the transition process it still does not address the ongoing workload problem. 

In the future, the LFS/BLFS 12.4 System V books will continue to be available. For the most part newer versions of packages in those books will be able to be built with the instructions from there, but will not be tested by the LFS editors. 

The next version of LFS/BLFS will be version 13.0 and is currently has a target release data of March 1st. 

As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important. 

However, the decision needs to be made.

-- Bruce Dubbs
linuxfromscratch.org

( htmm v | 2026. 02. 03., k – 10:09 )

Nekem ez nem ugy tunik, hogy beismerik, hogy a Systemd a jovo. Szerintem inkabb annak a beismerese, hogy ok is ra lettek kenyszeritve, hiaba nem akartak.

Csak tudod az munka. Amit nem csak elvégezni kell, hanem megszervezni is. De itt a többség csak kapni szeret. Mindent készen, és lehetőleg recent is legyen.
Ezt a munkát pedig bele lehet tenni hobbiból egy darabig. Egy ponton túl azonban már elkerülhetetlen egy működő üzleti modell. Annyit meg ezek szerint senkinek nem ér.  ¯\_(ツ)_/¯

Szerintem ezt visszacsinálni már nem lehet. A systemd nem csak egy init rendszer.
Menni kell bsd-re a magunk fajtának. Csak ott meg visszamész az időben húsz évet.

Nekem ez nem ugy tunik, hogy beismerik, hogy a Systemd a jovo.

Mert sehol nem is mondott ilyet. (A két világosan leírt indokban sem.) Az egyetlen hely, ahol a "jövő" szerepel, arról szól, hogy mi lesz a továbbiakban (=jövőben). Azon meg nyilván nem csodálkozunk, hogy egyesek szövegértés helyett a vágyaikat/vélemányüket vetítik ki. (Ami itt szerintem nem csak helytelen, de szükségtelen is, lévén, hogy a Systemd már jó ideje "piacvezető", tehát nem a jövő, hanem a jelen. De továbbra sem lepődünk meg, na.)

( FeriX v | 2026. 02. 03., k – 10:52 )

Nahát, amíg aludtam leálltak az AI szerverek? Már úgy hozzászoktam:

Allergének: A cikk nyomokban LLM-et tartalmazhat.

( Foltos | 2026. 02. 03., k – 11:12 )

Nem lehetne AI -jal pótolni a szükséges hiányzó erőforrást? Nem tudná a csomagok SysV -s részét mag a SysV specifikus CI -t karbantartani? Pont ez lehetne egy értelmes felhasználás, expertek keze alatt elvégezni a kuli munkát, nem? És nem is feltétlenül az AI -nak kell lenni az első vonalnak. Segíthetne kidolgozni requirementek -et a quality gatekeeping -hez, majd legyártani hozzá a automatizálást. Ez középtávon tehermentesíthetné a maintainereket. 

Pont az LFS lenne az a egyik bástyája a Linux világ sokszínűségének, hisz lehetővé teszi, hogy nulláról újra lehessen indulni. Ha ide is betolakodik a systemd az nem tesz jót a sokszínűségnek. Mondjuk, ha a GNOME és a KDE is elesett, akkor ez már csak sebtapasz a nyílt törésen. 

( chx | 2026. 02. 03., k – 13:10 )

Mi az értelme még egy windowsnak?
Valahol azért szomorú, hogy a forradalmakat úgy általában vagy leverik, vagy megveszik, vagy eladható bullshitté konvertálják.

echo crash > /dev/kmem

A tendencia sem kényszeríti őket sehova. Maradhattak volna a múltban. Az irrelevánssá válástól való félelmükben léptek, mert a kutyának nem kell egy idő után olyan "Hogyan csináljunk Linuxot SK" howto-gyűjtemény, ami egy elavult Linux disztró összekalapálásáról szól. 

trey @ gépház

Hmm? Hogy nem tudnak rajta a korszerű DE-k? Olvasd el az angol szöveget. 

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V.

Mi a szar point-ja lenne egy LFS jellegű projektnek, ha csak olyan rendszer készítését dokumentálná, ami az userek jelentéktelen részét érdekli? Így is egy niche projekt, miért akarna még azabbá válni?

trey @ gépház

imho: a KDE és a GNOME nem korszerűek. Kinézetben, stabilitásban, tempóban egy XFCE is laposra veri mindkét elkorcsosult mainstream-et. Nem is józanok ha desktop environment-ként systemd "képességeket" óhajtanak használni. Mégis mit? Ha nem működik a hangkártya, akkor nem lesz login a GDM-en?
Semmi sem indokolja a systemd függőséget. De hajrá binboz 2, aka binugz.

echo crash > /dev/kmem

Melóban XFCE-t, otthon Wayland Plasma KDE-t használok. Nem értem, hogy mit jelent az "elavult" és mit a "modern". Az XFCE a Trixie-n nekem speciel modern, viszont a KDE Plasma múlt heti állapota az Arch-on elavultnak tűnik a maihoz képest.

Leestem valahol a bicikliről? Röpködnek a definíciók körülöttem.

Nekem mindegy, hogy mit csinálnak. Ők így döntöttek, erre az útra léptek, ennyi. Mindenki maga alakítja a jövőjét. Viszont az nagyon nem csípem, ha valaki más megmondja, hogy mi az én jövőm... 

Tudod, nekem senki sem fogja beadni, hogy ahhoz, hogy írjak egy programot, vagy megnézzek egy filmet, vagy böngésszek a neten, ehhez nekem Systemd-t kell használnom. Miért??? 

Olyan ez, mintha valaki arra kötelezne, hogy cseréljem le a fogkefémet egy 3 kilós okosfogkefére, mert az mindent tud,vérnyomást is mér. Elhiszem, hogy ez valakinek bejön, de nekem nem, és nem kell. NEM KELL.

Nem is józanok ha desktop environment-ként systemd "képességeket" óhajtanak használni. Mégis mit? Ha nem működik a hangkártya, akkor nem lesz login a GDM-en?

Na, ezekből látszik gyönyörűen, hogy a hőbörgés, az nagyon megy, az, hogy esetleg az ember át is gondolja, az már kevésbé. A logind meg a user session támogatás ad normális user session és seat managementet. A systemd user unitok adnak normális háttérfolyamat kezelést. A D-BUS ad egy elérhető IPC busz-t. Lehet ezeket nem szeretni, lehet nem szeretni azt, hogy elég nagy fokú interop van ezekben, de úgy csinálni, mintha ne lenne egy alapvetően racionális alternatíva az, hogy a meglevő rendszer-eszközöket használják erre a DE-k, és ne pedig mindenki írjon és tartson karban sajátot... hát, végül is lehet úgy is csinálni, csak kissé szegényesnek tűnik.

Vegyük észre, hogy amire reagáltam, az kivette az LFS kontextusából az egészet, simán csak agyatlan systemd rant volt.

Egyébként pedig... valójában nem hiszem. Mármint az LFS imho még mindig inkább distró, arról szól, hogy hogyan kell egy olyat összerakni a nulláról, nem arról, hogy hogyan kell egyes komponenseit lefejleszteni. De tény, hogy nem áll olyan messze tőle, lásd a bejelentésben is, hogy igen, ez valójában tanulásnak van szánva.

KISS principle
"do one thing and do it well"

El nem tudom képzelni, hogy a "normális user session" élményhez vagy éppen használhatósághoz mit ad hozzá egy logind. A bináris logolást biztosan, kár hogy nem docx formátumban van, bedrótozva a copilottal támogatott onedrive-hoz. Reklámok is jöhetnének a /var/log/messages file-ba, megbírja.

echo crash > /dev/kmem

  1. A KISS nem ezt jelenti
  2. A do one thing and do it well nem olyan megkérdőjelezhetetlen alapvetése az univerzumnak, mint mondjuk az amcsi alkotmány második kiegészítése. Egyáltalán nem triviális, hogy az a jó stratégia. Az egész rendszernek mindenféleképpen lesz egy összes komplexitás igénye, azt mindenképp le kell fedni. Ha nagyon ezeket az a kicsi, one purpose, izolált elemeket használod, mert azok nem komplexek, akkor a maradék komplexitás árát meg fogod fizetni ezeknek a daraboknak az integrációjában. Bonyolultabb lesz, jó eséllyel kevésbé lesz a végeredmény robusztus, jó eséllyel szarabbak lesznek az edge-casek, nagyobb eséllyel lesznek duplikátumok, viszont "könnyebben" bele lehet nyúlni, ha kell, és lehet tényleg a lehet benne a dobozokat cserélgetni (ha van mire) (és persze ha hajlandó leszel megfizetni az árát). Ha egy integráltabb, szorosabban együtt működő rendszert csinálsz, az meg egy csomó kényelmetlenséget átvisz egy helyre, ahol van esély jobban kezelni, van esély arra, hogy a rendszer szükségletei szerint tervezzünk, valószínűleg kicsit egyszerűbb lesz, és valószínűleg egységesebb formája és minősége lesz. Igen, cserébe legózni nehezebb lesz (bár lehetne, imho a systemd táján sem az a fő oka ennek a hiánynak, hogy ne lehetne megoldani... meg lehetne. Csak valahogy senkinek nem nagyon akarózik megírni a funkcionális helyettesítő kockákat)
  3. A DE-k vicces módon pont azért húzzák be ezeket a függőségeket, mert igyekeznek arra az egy dologra fókuszálni, ami nekik a dolguk. Az meg a desktop environment. Nem a user sessionök karbantartása, nem a service supervisor készítése, vagy mondjuk a hálózati eszközök, meg tűzfal kezelése, meg az egyéb ilyen járulékos izék. És így most, hogy van olyan, ami ezt átveszi tőlük, szívesen odaadják. Ja kérem, hogy más nem csinál ilyet, csak a systemd?

Azt meg elhiszem, hogy nem tudod elképzelni, csak ez mondjuk téged minősít, nem a helyzetet. Ha néhány gondolatot inkább annak szánnál, hogy megértsd, ahelyett, hogy elmésnek tartott, de teljesen értelmetlen megmondásokat próbálj kitalálni, hogy megmutasd, te vagy a jani.

A do one thing and do it well nem olyan megkérdőjelezhetetlen alapvetése az univerzumnak

Olyannyira nem, hogy szerintem nagy átfedés van a systemd-ellenzők között, és azok között, akik a microservice-es "do one thing and do it well" világot is ellenzik.

Most akkor melyik? :)

XFCE -t nem vette be soha a gyomrom.... nem ertem, miert nez ki ugy, mint ha meg mindig 1995 lenne... KDE-t sem szeretem, mindig full osszecsapott erzetet keltett. Nekem mindig a Gnome volt az, ahol nem ereztem azt, hogy ez ilyen innen onnan osszehanyt rendszer.... Persze szigoruan a design-rol beszelek most.

Nálad a network bridge emlegetése valamilyen végső érv mostanában?

Eddig se nagyon követtem az LFS-t, őszintén szólva eddig én azt gondoltam, hogy az LFS egy dokumentáció halmaz, hogy miként rakd össze, soha nem gondoltam rá disztibúcióként.

Amikor nekem szükségem van ilyesmire, akkor csinálok magamnak, na abban nagyon nem systemd van, hanem busybox :)

Nálad a network bridge emlegetése valamilyen végső érv mostanában?

Nem, a bro 1337 5p34|<83N ... 

Eddig se nagyon követtem az LFS-t, őszintén szólva eddig én azt gondoltam, hogy az LFS egy dokumentáció halmaz, hogy miként rakd össze, soha nem gondoltam rá disztibúcióként.

Bizony!

Amikor nekem szükségem van ilyesmire, akkor csinálok magamnak, na abban nagyon nem systemd van, hanem busybox :)

👍‍

trey @ gépház

Nem általában, hanem mindig, mert a negyedik verzió a sikeres forradalom meg oda vezet, hogy a fiatal demokrata forradalmárok megöregednek és despotává válnak, hogy legyen helye és oka egy újabb forradalomnak. A kör bezárult. Illetve ki sem nyílt, sosem. :-)

Form follows function.

( laysoft v | 2026. 02. 04., sze – 09:25 )

Azért bizonyos területeken mindig is lesz létjogosultsága a systemd alternatíváknak. Pl. Alpine linux, ahol pehelykönnyű megoldás kell, oda a systemd ágyúval verébre.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

( hory v | 2026. 02. 04., sze – 10:18 )

Amúgy nagyon jó és korrekt összefoglalása a helyzetnek.

A systemd kurva bonyi lett, ez tény. Senki se szereti, én se, pont azért, mert kurva bonyi.

Ugyanakkor a világ továbbment, és alapnak vesszük egy mai OS-től azokat a dolgokat, amiket a systemd csinál.

A systemd mint init rendszer nem annyira bonyi, egyáltalán. Sőt, egy csomó jó dolgot tud, ami akár embedded környezetben is jól jön, pl. service masking. A konfig fájlok megérthetők.

A proléma épp az, hogy a systemd jóval több akar lenni, mint egy init rendszer, én meg csak nézek, hogy pl. mi a halálért nem bírom elindítani a gpsd-t (hint: a systemd ráült a portjára...), mi a halálnak kellett a loggingot teljesen szétverni, beleintegrálni az udev / ntp / networking / minden szart is, de legalább a legtöbbet szigorúan opcionálisan, meg csonkán megvalósítva. 

( VincentV | 2026. 02. 04., sze – 18:28 )

Buildroot-tal továbbra is lehet tetszés szerinti rendszert készíteni akár systemd-vel akár nélküle (jelenlegi választási lehetőségek: BusyBox, systemV, OpenRC, systemd). Yocto gondolom ugyanez, de nem néztem/nem használom. Az tényleg elég szomorú jövő lenne a beágyazott rendszerekre nézve, ha nem lehetne ezt megoldani. Az LFS-t nem követem, az ennyire fejnehéz desktop irányra? Mert gondolom DE-nél nehéz kikerülni a systemd-t, de egyéb esetekben egyáltalán nem az, sőt, sokszor szükséges és elvárt.

( arpi_esp v | 2026. 02. 05., cs – 00:06 )

vajon a Slackware meddig tart ki?

Remélem sokáig! Nagyon fogyatkozóban vannak azon disztrók, ahol a régi, jól bevált alapelveket követik és nem ülnek fel a legújabb, legtrendibb corporate bullshit-nek.

Szar a Windows is, de a legtöbb disztró is abba az irányba tart sajnos.

Make it as simple as possible, but not simpler. - A. Einstein

A Slackware - úgy látom - épp a liio -> grub2-re való átállással küzd. /o\

nem szeretem a grubot, de ezt valahol megertem. a lilo ugye nem megy uefi-n ami ma mar (koszonhetoen a win11nek) alap mindenhol, de szervereken mar eleg regota az. az elilo igen, de az meg egy vicc. mar az is hogy par eve meg kellett patchelni hogy 8MB-nal nagyobb kernelt egyaltalan be tudjon tolteni...

( derWRK | 2026. 02. 05., cs – 06:16 )

"de az olyan hardcore "disztribúciók", mint a Linux From Scratch (LFS) még kitartottak. Eddig" ez azért elég félreérthetőre sikerült, mintha minden disztribúció feladta volna, amit így leírni olyan Pöttering-féle csúsztatás. Hova süllyedünk itt is :'(

( derWRK | 2026. 02. 05., cs – 06:23 )

Ja igen, ez meg egy nappal utána:

 

Following this announcement, I would like to announce that for the past couple days I've working on a community-maintained soft fork of the main LFS book to maintain compatibility with SysVinit ever since this was announced on the Discord server, which can be found in the following link: https://github.com/MymeType/sysvlfs&nbsp;

Support for SysVinit hasn't been removed or discontinued from the development branch yet, but the goal of this repository is to be a soft fork that will still maintain instructions on how to build LFS using SysV. There are no plans to maintain a fork of BLFS and other LFS books as of now, but that might change in the future once there's enough interest and contributors for it.

( uzsolt v | 2026. 02. 05., cs – 20:31 )

Szűk 20 éve, mikor LFS-em volt, a SysVInit-et initng-re cseréltem, gondolom, most se kötelező a dokumentációt követni, csak tudni kell, hogy hogyan kell másképp csinálni. Ha bizonyos programok igénylik a systemd-t, lehet a systemd-mentes disztrókból ötlet mellett patchet is meríteni (ha kellenek annyira azok a bizonyos programok).

( hajbazer v | 2026. 02. 07., szo – 00:50 )

Az LFS nem azt ismerte be, hogy a systemd = jövő™, hanem hogy a Pöttering-konformista babzsák kényelmesebb Bruce segge alatt, mint a KISS irányelvekhez való ragaszkodással járó esetleges pluszmunka. Amivel kapcsolatban egyébként számos más sysvinit-default disztróból (Devuan, MX, Void, Artix, Slackware stb.) bőven meríthetnének, átvehetnének dolgokat, de ők erre inkább nemet mondanak.

Kissé ideológia szaga van ennek a postnak, szóval akkor sem lennék meglepve, ha ezzel új corporate profitmulti támogatókat keresnének a projekthez, egy szimbolikus tyúklépést téve az enterprise-ready™ Linuxok felé. Avagy, milyen jó lenne, ha jönne egy profitmulti, aki a Linuxát holnaptól LFS alapokon képzeli el.

In-place dist. migrálás van már amúgy RHEL-éknél? Ami supportált is, nem okosba' mókolós.
Amúgy kedvelem az IBM termékeket, a PTF intézménye stabil ám :)
(Picit úgy érzem, hogy ez is csak egy bevásárlás volt. Gugi, Mici, Facebo, Alma, Nagykék, semmi innováció. Csak tőke és vásárlás. Nem jó út imho.)

echo crash > /dev/kmem

Aha. 6-7 elvileg már volt. Egy next-next-finish telepített VM-nél, amire semmit nem raktunk fel, szinte semmit nem reszeltünk rajta, nem tudta megugrani, már az előkészítés részét képező teszteken elbukott... (És de, igény az lenne rá, bár ahol mindent is például ansble alapon raknak össze, ott kevésbé kritikus az, hogy in-place lehessen felfelé menni... Pláne ~10 évente.. 

Aha. 6-7 elvileg már volt. Egy next-next-finish telepített VM-nél, amire semmit nem raktunk fel, szinte semmit nem reszeltünk rajta, nem tudta megugrani, már az előkészítés részét képező teszteken elbukott...

Ja, hát hogy mennyire volt jó, azt nem tudom, de tudom, hogy volt. Azt tudom, hogy volt, amikor lepróbáltuk, és nem volt gond. (Lehet az már 7ről volt, nem emlékszem)

(És de, igény az lenne rá, bár ahol mindent is például ansble alapon raknak össze, ott kevésbé kritikus az, hogy in-place lehessen felfelé menni... Pláne ~10 évente.. 

Nem mondtam, hogy nincs, ha nem lett volna, nem csinálja meg az RH. De pontosan arról van szó, hogy jellemzően eleve van valami fajta egyéb change management, meg ~10 évente lesz valami migrációs terv, nem igazán fog fájni, hogy egyébként az OSt is újra kell húzni, jellemzően olyankor úgyis meg van az egész stack mozgatva, általában egyszerűbb és kisebb kockázatú nulláról összerakni, mint megtervezni egy in-place upgradet.

Ez nem jelen-jövő, jobb-rosszabb init kérdése. Az LFS nem is disztró, csak egy dokumentáció. Eddig végig a sysvinitet alkalmazta, nem azért, hogy systemd-ellenes legyen, hanem mert a sysvinit szög egyszerű, kevesebb fordítani való van rajta, KISS elveknek, Unix-filozófiának megfelel. Ez nem egy corporate disztró, ahol kell a shim, systemd, SELinux, stb.. Meg különben is, akinek systemds rendszer kell, tegyen fel magának tetszőleges mainstream disztrót, ahhoz nem kell LFS. Nekem még azzal se lenne bajom, hogy a systemd-t támogatja az LFS, ha opcionális lenne, megmaradt volna a sysvinit támogatás (ahogy a Gentooban van), de itt is kötelezően rátolják mindenkire, ebbe az irányba haladunk, terelik be a nagy corporate monopóliumokba a birkákat, holott a Linux ez ellen jött létre anno.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Gentoo is all about choice. Imádtam mindig is.
Ők talán egyszerűbben teszik opcionálissá, hiszen a USE flag-ek mentén tudnak megfelelő módon fordulni a csomagok. Bináris disztrónál, ahol előre lefordított csomagokból kell dolgozni, gondolom ez nem ilyen egyszerű.
Az LFS-nél viszont pont annak kellene lennie. Hiszen ott is csomagokból fordítasz. Vajon mi lehet nekik a probléma?

Lamentálok így messziről ránézve, a részletekben nem elmerülve.

Az a baj, hogy ez olyan mint a biciklizés :) Lehet hogy a motor gyorsabb, modernebb, a bicikli elavult és általában csak egyszemélyes, tekerni is kell, de azért ne tiltsák ki őket az utakról...

A kérdésedre válaszolva, nagyon remélem, hogy nem jön el az az idő, mikor már egy dsiztró se lesz ami nem használ systemd-t. Mert akkor a kövezkező az, hogy jajj úgyis mindenki gnome-ot használ, meg minek ennyi de-t a waylandre portolni, és alig használja valaki a régi vackokat, vegyük ki a felesleges és nehezen karbantartható xorg emulációt is. Ilyen egységes bloatware dolgot már láttam valami MS nevű cégtől, mielőtt még 95-ben elkezdtem volna linuxot használni :P

;DD

Összegzés: Mit válassz?

MegoldásElőnyHátrány
JS gomb letiltásAzonnali, jó felhasználói élmény.Kikerülhető, ha a böngésző frissítve lesz.
Flood modulNem kell kódolni, stabil.Inkább darabszámot korlátoz, nem tartalmi egyezést.
Custom ValidationEz a legpontosabb.Fejlesztői tudást igényel.

Exportálás Táblázatok-fájlba

Szeretnéd, hogy segítsek megírni a pontos PHP kódot egy egyedi modulhoz, vagy inkább egy meglévő modul beállításaiban mélyedjünk el?

( Dwokfur v | 2026. 02. 07., szo – 22:36 )

Legjobb lenne, ha mihamarabb újraírná Poettering a systemd-t rust-ban!

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."