''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.
I don't mind the inevitable death of System V. It's an archaic relic of the Linux era.
Going systemd-only is not necessarily a good choice (though I do understand it from a practical point of view). There are other, better alternatives for System V that are smaller and more modular so you still get the Unix "feel" without the absurd complexity of interlinked shell scripts that System V relies on.
I'd like to see OpenRC getting adopted in System V's place. Upstart seems to be dead (outside of ChromeOS) but it would also have sufficed. Alas, I'm not someone with the time or knowledge to maintain these tools for LFS, and unless someone else steps up to do all the hard work, we'll probably see LFS go systemd-only.
That said, there's no reason to go full-fat systemd, of course.
I think systemd is the one to learn now if you want to learn Linux. Maybe someone can make a Unix from Scratch for people more interested in the Unix philosophy than Linux per se.
Yeah, people forget the degree to which sysvinit was hated at the time - "why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?!?".
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
systemd is most certainly the most pragmatic service to learn, but if you're doing LFS to "learn" how a Linux system gets brought up, something lower-level may be a better idea to pick up.
Runit is 5474 SLOCs. Most source files are shorter than 100 lines. Works like a charm. Implements an init system; does not replace DNS, syslog, inetd, or anything else.
Systemd, by construction, is a set of Unix-replacing daemons. An ideal embedded system setup is kernel, systemd, and the containers it runs (even without podman). This makes sense, especially given the Red Hat's line of business, but it has little relation to the Unix design, or to learning how to do things from scratch.
I love how people worship UNIX design in Linux circles, especially when complaining about decisions where Linux is catching up with commercial UNIXes, as in the init systems replacements.
UNIX design was so great that its authors did two other operating systems trying to make UNIX done right.
One of the few times I agree with Rob Pike,
> We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
A project which is intended to be a learning experience in building a Unix variant (in this case, Linux) is a kinda right place for sticking to the Unix philosophy and design, for illustrative purposes.
Mr Pike has indeed constructed a better OS than Unix; too bad AT&T neither knew how to achieve viral popularity, nor why Free Software (as in GPL) is going to dominate the world. By about 1995, it was already too late. (Something similar happened to Inferno vs Java.)
Still, the Unix principles of modularity, composability, doing one thing well, and unified interfaces are widely considered very sane, and adopted.
Not as much as people in Linux community think, especially those that never used commercial UNIX offerings.
GPL is on its way out, a good example is that all Linux competitors in the embedded space, including Linux Foundation's Zephyr, none of them has adopted GPL.
GPL based software is now a minority, almost everything uses licenses that businesses rather reach for.
I suspect that GPL2 was instrumental in guaranteeing that the work sacrificed into the common pot of Linux kernel is not going to be taken by a competitor when it's still unpolished, closed, and used to achieve market domination.
FreeBSD came before Linux (as 386BSD), and is also active used by the industry. How much code did Sony or Raytheon shared back to FreeBSD? (LLVM is not FreeBSD proper.)
I find Zephyr to be a somewhat poor example. It's typically used on MMUless microcontrollers where the application is linked into the same binary as the OS. I'm sure you'll point out that it's not strictly necessary to use it in that manner, but that's how most people use it and that's how they expect it to work. Licensing it as GPL would mean that basically nobody would use it because it would require releasing your entire firmware source code, especially when there's other permissively licensed alternatives in that space like RTEMS, ThreadX, and FreeRTOS.
I will be honest mentioning Zephyr in a situation when talking about how outdated the Unix design philosophy is, is a bit funny to me since Zephyr (like ecos kinda did once) tries to be Posix-like in its APIs (but ends up not really improving things over the other embedded OSes TBH).
I think the main problem of Unix today is that it's not Unix-style enough. Too many namespaces with too many non-composable separate APIs on them instead of "everything is a file". Plan9 is more Unix than Unix and that's indeed better. Redox OS, too.
The Unix security model is mostly useless today, but it seems like something better is possible as an incremental change, and there are projects that do that, like RSBAC.
And we've all heard of the linux people, as opposed to whoever is pushing these post-Cassidy OS. Linux isn't where it is because of some imperial decree, it has been winning out in a slow, protracted war for what OS programmers choose when they want to get work done.
Pike is more than entitled to an opinion, but I think there is some cause-effect reversal at work here. The linux circles aren't people driving the UNIX-love. The UNIX-love is effective in practice - especially the blend of principle and pragmatism that the linux community settled on - so the linux circles happen to be bigger than the most similar alternatives. Better alternatives are going to have to fight through the same slog as linux if they want recognition.
This is not about mindless worship, but about the fact that the UNIX design has stood the test of time for this long, and is still a solid base compared to most other operating systems. Sure, there are more modern designs that improve on security and capability (seL4/Genode/Sculpt, Fuchsia), but none are as usable or accessible as UNIX.
So when it comes to projects that teach the fundamentals of GNU/Linux, such as LFS, overwhelming the user with a large amount of user space complexity is counterproductive to that goal. I would argue that having GNOME and KDE in BLFS is largely unnecessary and distracting as well, but systemd is core to this issue. There are many other simpler alternatives to all of this software that would be more conducive to learning. Users can continue their journey with any mainstream distro if they want to get familiar with other tooling. LFS is not the right framework for building a distribution, nor should it cover all software in the ecosystem.
The first version of UNIX was released in 1971 and the first version of Windows NT in 1993. So UNIX is only about 60% older than NT. Both OSes have "stood the test of time", though one passed it with a dominant market share, whereas the other didn't. And systemd is heavily inspired by NT.
Time flies fast, faster than recycled arguments. :)
I'm confused as to which OS is the one that passed the other with dominant market share. Last I checked, Linux is everywhere, and Windows just keeps getting worse with every iteration.
I'm not sure I'd be smugly pronouncing anything about the superiority of Windows if I were a Microsoft guy today.
It's not surprising that systemd was heavily inspired by NT. That's exactly what Poettering was paid to create, by his employer Microsoft. (Oh, sorry--RedHat, and then "later" Microsoft.)
Respectfully, that's nonsense. Linux is directly inspired by Unix (note: lowercase) and Minix, shares many of their traits (process and user model, system calls, shells, filesystem, small tools that do "one thing well", etc.), and closely follows the POSIX standard. The fact that it's not a direct descendant of commercial Unices is irrelevant.
In fact, what you're saying here contradicts that Rob Pike quote you agree with, since Linux is from the 1990s.
But all of this is irrelevant to the main topic, which is whether systemd should be part of a project that teaches the fundamentals of GNU/Linux. I'll reiterate that it's only a distraction to this goal.
I'm not familiar with what UNIX or its modern descendants have or have not implemented. But why should Linux mimic them? Linux is a Unix-like, and a standalone implementation of the POSIX standard. The init system is implementation-specific, just like other features. There has been some cross-system influence, in all directions (similar implementations of FUSE, eBPF, containers, etc.), but there's no requirement that Linux must follow what other Unices do.
If you're going to argue that Linux implementing systemd is a good idea because it's following the trend in "proper" UNIX descendants, then the same argument can be made for it following the trend of BSD-style init systems. It ultimately boils down to which direction you think is better. I'm of the opinion that simple init systems, of which there are plenty to choose from, are a better fit for the Linux ecosystem than a suite of tightly coupled components that take over the entire system. If we disagree on that, then we'll never be on the same page.
The article is not about UNIX, what's good and bad, but what's better for understanding Linux. And replacing SysVInit with systemd is, objectively, bad for understand the core of Linux. And this is the core of LFS.
Discussing whether UNIX is good or bad seems narrow-minded, as there is no solution to that. It's like discussing whether iOS is better than Android. We can always isolate some specific parts and discuss that, but just slashing the whole concept doesn't help anyone and rarely yields any meaningful results.
All of my Debian out of the box has systemd. On Gentoo it's OpenRC, which I find easier. But! There are some work-around packages that implement some stubs of systemd things because other packages are designed for systemd only world (one such stub is elogind)
It's "problem" unfortunately is that it happens to be the only major foss os. If there were other foss oses with good support and "better" models I'd gladly try them out. I know I personally would never switch to any non foss os after the user friendliness I have experienced. I would say that's the main reason many stick to it, including game theoretic arguments for commercial players also. Not because people like to stick to ancient models. It's not a ideal system obviously but going back to locked down crap is a no go for me and perhaps many others. BSDs are ok too but the suicidal licensing makes me less inclined.
Yes and much of it is sealed off and proprietary. The bsd oses got MacOS for all their hard work, a closed off system that they can't read or port back anything from. Someone would say linux or gpl projects also have been fucked over this way. I suppose if your house has been burgled, such a person would argue we must remove all protections rather than add more.
Why are you acting so strange and making up misinterpretations of what I wrote?
You depend on lawyers either way, whichever license you use, I fail to see how copyright law can be implemented and defended without lawyers.
The golden rule is simple, anyone can look it up, I really don't understand what difficulty you have that made you make up such a strange "not even wrong" theory about it. "do to others what you would have them do to you" , here it means you have benefited from countless man hours of work by other people, so you too should pass on any improvements you made to it just like they did to you.
Regarding freedoms, let us take this scenario. Your small company depend on a complex bsd library thats hard to replicate. It gets the attention of a much larger company, they fork it make various changes to make it much better and keep it closed, their product kills yours. While, if it was GPL (or AGPL as its needed today), the company either has to redevelop it inhouse if they wish to serve it as product to the public without releasing its sources, or they do the same thing as in the bsd case, they make a much improved version...and you have equal access to the same sources, you can take that and pivot upon it instead of your company dying. Its very simple, more or less mathematical game theory. Nobody can force anyone to choose a license, its your choice. Again, Mac OS is not a very encouraging example of the overall outcome of BSD licensing. No freebsd/openbsd/whatever person is permitted to read or use Apple's "fork" now. Apple took the hard work of others and instead of paying it back in like, it doesn't take a single cent of money, "paying" back here simply means doing the same the others did, they generously provided you their work as foss, you pass back your delta to it as foss. Thus raising the high water mark of the entire ecosystem. Think academic research. Its usually released in open, so any improvements made by one team are available for others to use and further improve upon. That's it. Nothing more. Nothing less. How does GPL "force" anyone to do anything? They can either choose to follow the license, or choose another library or home grown an alternative if they dislike the terms.
> You depend on lawyers either way, whichever license you use
No, in fact I don't. Indeed, I go far out of my way to avoid these parasites entirely, and anyone who depends on them. I don't give a damn what anyone does with my software. I don't need the attorneys to do anything.
For accusing me of "misinterpreting" what you wrote, you seem to be quite confused yourself. What part of "public domain" don't you understand? The means I don't give a shit what you do with the code. You can decide for yourself. You know, the mature, unselfish approach. Busybodies and control freaks hate this one simple trick.
> Regarding freedoms, let us take this scenario.
Here we go, lol. We're headed down the rabbit hole straight to the juicy caramel center of your flawed thinking.
> Your small company depend on a complex bsd library thats hard to replicate. It gets the attention of a much larger company, they fork it make various changes to make it much better and keep it closed, their product kills yours.
Sounds like you had a very poor business model. Probably because you have no idea what you're doing. Your monetization strategy failed. Pick yourself back up and try again.
The solution is not Big Brother and his machine guns to force others to comply with your dictates. (i.e. the lawyers and legal system, if I have to spell it out for you.)
> While, if it was GPL (or AGPL as its needed today)
AGPL is strongly avoided by almost everyone, for good reason. It's even more of a cancer than the GPL.
> the company either has to redevelop it inhouse if they wish to serve it as product to the public without releasing its sources, or they do the same thing as in the bsd case, they make a much improved version...and you have equal access to the same sources, you can take that and pivot upon it instead of your company dying.
...or they just decide to develop their own version from scratch instead, keep it closed source from day one, and you get nothing at all. Happens all the time.
If you were truly a shit-hot developer you would not be concerned about anyone ripping you off. You'd know you're so creative and putting out so much quality effort on a consistent basis that you'd never worry about being surpassed by anyone.
Big company thought of a good idea to add to your big pile of good ideas? No problem. Copy that and come out with another good idea or two for him to steal. If they're always imitating you, then that means you're the industry leader, doesn't it?
If you're not the industry leader however, because you really only had one good idea and Big Company has more, then what right do you have to try and Stop Progress just for your own selfish ends? That's what this all boils down to: selfishness, due to insecurity.
Your mentality is completely foreign to a true winner, but oh-so-common among the insecure midwits. They're always deathly afraid that their One Thing will get ripped off and they will be left with nothing.
It's a scarcity mentality. That's the problem. It's all in your head.
You're a squirrel with one little nut that you cling to desperately, in hopes that nobody else will grab it. You make all your life about protecting that nut at all costs. You're so glad that Big Brother offers you his machine guns to help you protect it. You don't care about the harm that comes from bringing thugs with guns into the picture to push people around. You're just desperate to protect Your Thing, so you will accept anything that you believe will help this end. It's the same broken mentality that manifests itself everywhere else besides software also. Nothing new under the sun.
Do not pretend that I don't understand you far better than you know yourself, or that I am misinterpreting you in some way. I've seen ten thousand of your type if I've seen one. You're everywhere, especially on HN. I'm well aware of what your mentality is. The root of the problem is your insecurity.
> Its very simple, more or less mathematical game theory.
You don't have a clue about how economics actually works--which is typical for those of your loudly expressed opinions. But you think of yourself as some enlightened game theorist. Not quite.
The bottom line is, you can't FORCE people to behave how you want through your favorite legal fiction or any other, and you damn sure should never try, as it's a fool's errand that only leads to tears. One of the basic laws of the universe.
The people who created GPL knew this from day 1. That's exactly why they created it to be the way it is. Irt was an act of sabotage. This knowledge is currently far above your level however, and is likely to remain so for a long time to come; probably forever.
The world is not falling and BSD is winning the license war for good reason. End of discussion. It's all over but your crying.
>If you're not the industry leader however, because you really only had one good idea and Big Company has more, then what right do you have to try and Stop Progress just for your own selfish ends? That's what this all boils down to: selfishness, due to insecurity.
How the fuck is a GPL library stopping progress? Why does Big Company feel tied up due to a library being GPL? You said it yourself, they could redo it inhouse? If they were such hot shit they'd do it and continue the march of progress anyways.
Its very simple, its so simple I am not even sure I am talking to a functional level of iq: do you think more progress is made from less eyes on an idea? If the changes made by Big Co were available to the public, that's a much larger pool of engineers to take it in all sorts of directions. You are so fucking dumb its beyond words.
>...or they just decide to develop their own version from scratch instead, keep it closed source from day one, and you get nothing at all. Happens all the time.
You again seem very confused. Its exactly the same as they closing up a bsd fork. So how is the outcome or incentive any different? With bsd they can do that without any effort, with gpl at least they have the friction and may deem it too much of a friction. Google's fuchsia attempt failed despite its behemoth size, Android is still linux.
How exactly is it a sabotage? You are again making up utter absolute fucking crap out of thin air and acting retarded making up an entire fantasy universe in your head.
Since you are such a smartass wanker, tell me this, how is the other company being forced to release their changes making the market less competitive? On contrary, this makes it more competitive, since everyone is forced to compete to this level now, they themselves will have to keep developing something better, and again paying the inhouse cost if they wanna be jealous.
AGPL is strongly avoided by...yes companies who live off of turning existing libraries into websites...who'd have thought, hardly a surprise why and who avoids it.
Big company can add a good idea, but big company has big resources. I am telling you that you can now pivot on their changes and putting them under the pressure cooker again: more competition. Competition is nice.
How the fuck is a simple license that nobody is forced to use a "sabotage", are you really even thinking? How much fucked in the head can someone be to think a completely legal and simple license is a "sabotage"? A "sabotage" against what or whom? If its a sabotage, then protest whatever legal framework allowed it. Do you disagree with copyright, is that what you are saying?
If you disagree with copyright, then I hope you have no problem with taking the source code of competitors by any means. After all, if licenses are bad, and government enforcement of copyright is bad, why should copying and releasing a company's internal sources be bad?
If this is a "scarcity" mentality, then the entire history of Mathematics for the past few centuries is a scarcity mentality. If you are man enough to follow through, then say it out right in the reply that you believe Mathematics is a scarcity mentality.
I mean if I wanted to win at all costs, why shouldn't I steal your code and release it and make life harder for you. Or if I wanted to be a real winner, why don't I go and shoot you.
Tell me again moron, how the fuck does a license "force" you, who the fuck is "forcing" you to use gpl if you dislike gpl? I don't even know how deep a level of mental illness one can have to imagine someone with guns is coming out to kill you and rape you and force you to use GPL programs and libraries. Are you even thinking man? This is literal violent paranoid psychosis level of insanity. You are fucked in the head beyond repair.
You seem to be unaware of the basic fact that government--laws and legal systems--is men with guns.
"Government is not reason, it is not eloquence, it is force! Like fire, it is a dangerous servant and a fearful master." - George Washington
It's difficult to have a conversation with someone so profoundly ignorant of reality. Do some research and stop wasting our time with your angry rantings.
You are the one who chimped out with a long rant to a perfectly calm explanation man. You are still acting mentally ill. Yeah duh, govt is men with guns. And where in all this are you seeing this supposed "sabotage" of you being forced to use GPL? If you don't like GPL, don't use GPL software. Very simple. Nobody pressured you to. Since government enforcement of copyright is not something you like, I think it's a perfectly fine sentiment to have. I hope you don't mind people releasing all the materials of competitors to the public then. Tell me again , I am not sure its any point trying to reach the skull of someone this mentally ill but I'll still try. If I release something as GPL, whos coming in to your house with guns blazing forcing you to use my library? You choose to not use it, its simple. The government will use violent force to enforce any law, but in this case its easy since you already dislike GPL, just don't use it, government will have no interest in killing you. What a fucking brain dead moron, man.
My point was, that there’s plenty of ancient things we plod along with, even though they’re not perfect. Many have tried to improve upon them but few have stuck.
You are so vague in your attack on Unix approach that it's borderline trolling. What are your problems with it? Modularity and minimalism have been working perfectly and that systemd does not follow them is a bad thing.
But that book is a waste. It is just MIT dunning-krugerites who were salty that LISP machines never took off. When it comes to real life, the bell labs approach won, and for several good reasons. Not "worse is better" (another dunning-krugerite cope), but "less is more."
From your perspective, what would be an "OS done right"? I have a running list of things I would change in Unix, but replacing sysvinit with systemd's one-ring-to-rule-them-all would not be on it.
But your comment is a waste. It is just HN dunning-krugerites who were salty that the UNIX way never took off. When it comes to real life, the Poettering approach won, and for several good reasons.
The UNIX way is still doing fine on OpenBSD, NetBSD, FreeBSD, Alpine, Gentoo... Poetteringware only won on the distros selling support contracts. "Fixing" what wasn't broken is great for those businesses.
Except for all those who've accidentally blown their legs off with it, of course.
Just ask the guy who bricked his motherboard due to a systemd bug where his firmware wasn't write protected and got destroyed by a 'rm -rf' command. lol
No software is perfect. Not sysvinit (and it's bash scripts from different vendors), nor systemd. Errors happen. At least for me systemd is a net positive.
Especially when it's a giant blob of buggy C code written by a known hack who has multiple decades' worth of history of foisting shit code upon a less than enthused public.
> At least for me systemd is a net positive
For the moment. Just wait until it finds a way to fuck you. It's plotting and scheming behind your back to do so as we speak.
Systemd for some reason seems to uniquely be the epicenter of giant facepalm bugs like LEAVING THE SYSTEM FIRMWARE VULNERABLE TO AN RM -RF COMMAND, a situation which causes alarm to none of the systemd crowd. They just shrug if off. "What's the big deal? I don't get it," they say.
I used to see the same mentality from Microsoft people back in the day. "Why would you use Linux? I don't get it. Windows is fine."
It's because you lack standards. You're completely used to being surrounded by software and hardware that is Fucking Garbage. Everything is like that in your world. You're happier than a pig in shit, oblivious.
> Implements an init system; does not replace DNS, syslog, inetd, or anything else
Neither does systemd its init.
Unknowledgeable people keep confusing systemd the init and systemd the daemon / utility suite. You can use just the init system without pulling in resolved or networkd or whatever.
Systemd is the Unix philosophy of lots of modularity. But because all the systemd daemons come from the same shop, you get a lot of creature comforts if you use them together. Nothing bad about that.
What we need is actual, proper, mass-education about how computers work, with the goal of increasing their freedom of interaction. Not towards creating more working class peasants using a tool for work, but creating chaotically creative tinkerers using a tool to create whatever they want, more tools included.
Kids and their Parents learned it in the 80s and they had nothing but a manual. Either these people were massively more intelligent, or the same approach, using modern methods, would work again and again and again.
Considering the 1% rule of the internet (it's about the ratios, not the numbers!), shifting more people from the 90% to, at least, the 9%, seems to be one of the better courses of actions to take.
What we, MY FELLOW HUMANS [1], absolutely do not need is more people being optimized towards using a computer solely as a tool for someone else ... especially because AI can replace 99%+ of them anyway.
Yes, this times a thousand. If we treat people like slaves, they become slaves. Treat them as if they are smart, and they will become smart. It's as simple as that.
I have been saying for years that Microsoft would eventually deprecate WinNT and switch Windows over to a Linux foundation. Things seem to be slowly but continually moving in that direction.
The windows NT kernel is in many ways a better design. However they allow third party device drivers, and run on all kinds of really terrible hardware. Both of them will cause the system to be unstable through no fault of the system.
Don't get me wrong, NT also has its share of questionable design decisions. However overall the technical design of the kernel is great.
My favorite example of this is how Windows NT has had async IO forever, while also being notorious for having slower storage performance than Linux. And when Linux finally got an async API worth using, Microsoft immediately set about cloning it for Windows.
Theoretical or aesthetic advantages are no guarantee that the software in question will actually be superior in practice.
ASync I/O isn't limited to just storage, though. It's /all/ I/O.
And yes, the layered storage stack does have a performance penalty to it. But it's also infinitely more flexible, if that is what you need. Linux still lacks IOCP (which io_uring is not a replacement for).
Windows' VMM and OOM is also generally much better.
Pretty much what I was thinking of. My understanding from reading some commentary in this area is the Linux implementation is yet a little botched due to how it handles waiting threads.
It would be much unlike Microsoft if they didn't bring Win32/Win64 compatibility along for the ride somehow, and very stupid also, because as you say that is the real core of Windows in a lot of ways.
I have no idea what they're planning or why, just guessing, as they seem to be bringing Linux and Windows closer together all the time.
> It would be much unlike Microsoft if they didn't bring Win32/Win64 compatibility along for the ride somehow, and very stupid also, because as you say that is the real core of Windows in a lot of ways.
This requires NT API compatibility due to applications using NT API. Despite Microsoft telling devs don't use the NT API, devs use the NT API and Microsoft makes adjustments to ensure compatibility.
> I have no idea what they're planning or why
Clearly, because the whole idea not only makes no engineering sense, it makes no financial sense. They need to build the NT kernel anyway -- it runs the entirety of Azure services!
> Makes no sense to dump a superior kernel and executive for Linux.
At this point in time, having programmed deep in the internals of both Linux and Windows, I think it is probably incorrect to call either kernel an inferior or superior one.
I mean, it was true for both of them at some point (Overlapped IO was great on Windows and missing on Linux, for example) but today, in 2026, the only differentiating factor is the userland experience.
With limited resources, sometimes practicality needs to win. Kudos to Bruce for putting aside his (valid) feelings on the subject and doing what is best for the team and community overall.
I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. It is built starting from LFS in 2019, and now consists of over 1,500 packages, cross compiling to x86-32/64, powerpc32/64, and others if I had hardware to test. It's built entirely from shell scripts which are clean, organized, and easy to read.
I need help to get the system ready for release in 60-90 days. In particular, I need a fast build system, as my current 12+ year old workstation is too slow. Alpha/beta testers are welcome too. Anyone who wants to help in some way or hear more details, please get in touch:
The difference is that the people who designed X11 were honest in their intentions. The authors of systemd, wayland, etc are not. I'll just leave it at that.
(I recommend staying far away from "X11libre" also, for the same reason, with no further comment.)
Monolithic stuff is OK too, where it makes sense. The kernel is monolithic. ZFS is monolithic.
(Yes, this system has ZFS support. The module is built in to the kernel. In time it will support booting from ZFS also, when I finish the initrd code.)
There is a clear, solid reason for everything this system is or does. I'm not a contrarian or a purist, just someone with opinions gained from long experience who is not happy with the direction mainstream Linux is headed. My system is a zen garden of bliss compared to buggy garbage like Ubuntu.
Really, it's like someone added a turbo button. Ubuntu and friends are so bloated, laggy, and slow. I regularly use this system on 15-20+ year old hardware. The default window manager is Enlightenment e16. It's snappy and responsive everywhere.
KDE, Xfce, etc are supported also and are noticeably peppier than on mainstream distros, just due to the lack of bloat, gazillions of daemons running in the background, etc. Out of the box, nothing runs by default. You enable only what you want.
Another inviolable principle is that no application is allowed to originate or receive network traffic unless the user specifically requests it. There is ZERO network activity going on in the background. None of this steady stream of who knows what contacting who knows where that goes on with other systems. No auto update etc. No internet required or used during the system build. Python module installs do not consult the central repository or download anything. Meson or cmake does not download anything. Etc. All that's patched out and disabled.
It's a distro that is meant to be forked. It's very easily done. It's a blank slate, a vanilla Linux system with subtle and tasteful improvements that is the ideal starting point to customize to your exact specifications. If you want to add in systemd and wayland, fine, I don't care, it's your system and you can build it according to your desires. People can use this platform to build their own custom OS and save themselves a ton of work vs. starting completely from scratch.
It's a system that can be audited. Everything is built with shell scripts, starting with source archives and patches that are applied during the build process. It's all inspectable and the process can be understood step by step.
It's a way to hit the ground running with a full featured, working system, while learning in the process. This distro will teach you what LFS would teach you, but with less of a "sheer cliff face" learning curve, letting you focus more on higher aspects of building the system while still learning the low level details in time.
The build is actually overall simpler than LFS despite being way more featured, with things like Ada support. (Yes, it has GNAT.) I just found a way to do it better, and kept iterating countless times to simplify and improve to the max.
Existing systems did not satisfy my requirements or standards of quality, so I just had to create a new one.
> The difference is that the people who designed X11 were honest in their intentions. The authors of systemd, wayland, etc are not. I'll just leave it at that.
Leave it at what? How is Wayland not honest about it's intentions? It is completely transparent about the motivation behind the project. Whether you agree with the motivations is different, and thats fine to disagree with a project.
However there hasn't been a scenario where Wayland haven't been honest.
Yes, I am ignoring your side comments about systemd because I was asking about Wayland, and mixing the two together implies that you are just complaining about the new, rather than technical/architectural reasons.
(Plus I have to ask as "killthe.net" doesn't come up with anything)
Send me an email and I'll be happy to explain further, to whoever asks. I don't want to clutter up this thread with a bunch of arguing that will surely result, as the focus here is just on "going our separate ways" rather than throwing barbs at anyone, or causing more hard feelings.
People who like software that I don't personally like may continue to use it of course, with this system also even, it's just that it won't be in the official repository is all. But as the whole thing is designed and encouraged to be forked, that shouldn't be too much of a burden if someone likes other aspects of the system and wants to maintain their own 'systemd/wayland' version.
I got rid of dbus in GTK3 by patching the code so that the "accessibility bridge" (to ATK) can be disabled. GTK4 is beneath contempt and will not be supported.
The system uses GTK2 wherever possible, or GTK3 when not. I will either port everything to GTK2 later or create some kind of shim library. Help wanted here. Porting back to GTK2 isn't hard, I just don't have time to work on any of that at the moment.
Note that GTK 3.24.43 is the last version of GTK3.
My system is full of patches like this to tweak, improve, and adjust things. The point is to get off the "upgrade" treadmill and focus on making things work right.
Just to be clear, I did not write these patches, but have collected many like this via scouring the net. I think I did make the ATK one though.
If you'd like to be an alpha/beta/release tester of this system, hit me up via email please. I'll start with an initial closed alpha release here in a month or so, if there's interest.
Now for the donation drive: I have plenty of time and a stable situation to work on this system, but the one drawback is I have little funds--and unfortunately my workstation is getting pretty long in the tooth. (AMD FX. It's been a good system, but I'm getting Left Behind here.) The main thing holding me back is compile speed, especially doing work on Chromium and WebKit. It's 12+ hour compile times for either of those, with the latest C++ standards they're using. The system as a whole builds in about 48 hours on my computer.
So I'm hoping to bump into an "angel investor" who either has some old Xeon (Broadwell or newer?) hardware laying around they would donate, something with lots of cores and memory, or who can make a cash donation for me to buy the gear I'm looking at on Ebay. $400-500 is enough for a nice 5x upgrade. It amazes me how cheap this stuff is. We're talking $5000+ hardware when it was new, for peanuts. Still quite powerful.
(A better video card would be great too, if you're feeling generous. Mine is a GTX570. I'd love to have a GTX7xx or newer, or equivalent AMD. That's more of a want than a need however.)
I'm very interested in ppc64 gear too. I want this system to have first-class PPC support. Anyone got an old POWER8 or POWER9 system laying around, or 32-bit stuff? I've got this system building OK in Qemu for ppc64le but it is SLOW, as you can imagine. Like 5 seconds per line in configure scripts, lol.
If anyone out there is in a position where they can help this project in some way, email me please! Thank you.
By the way--I did not want to disable ATK to get rid of dbus, but only did so temporarily. Ultimately a better solution is to create a UNIX socket just for the ATK<>GTK bridge.
Accessibility should be something that the system fully supports. There is speech synthesis and other useful bits installed so far. Maybe someone would like to work on this project. Email me if interested.
I'm sorry to tell you, but I'm not really interested in a new distribution. I appreciate the effort of what you are trying to do, but I think you are wasting time maintaining a distribution instead of maintaining patches (or a fork). If you have the know-how to patch those cancers out, then do only that and let other people do the packaging. Just make them known and available - a github repo maybe?
So, I'm not going to test your distro or switch from my Gentoo. I like Gentoo a lot, most of all because it's so very-very easy to patch any official package. Just put the patch in /etc/portage/patches/<package> and that's it. It gets automatically applied on the next install.
I'm using a Phenom II x6 1100 on a Gigabyte 880G. Firefox compiles in about 3-4 hours I think, not really sure. I do all Gentoo updates over night and it's usually ready in the morning. I can't say about Chromium or webkit - never used them - but 12h seems waaay too long.
Sorry dude, it's about 7 years too late to tell me to stop.
If you like Gentoo, more power to you! It's not for me.
This isn't just another run of the mill distro. It's like nothing else that's out there.
I forgot to mention that I have PaleMoon on the system also, and it compiles in a much more reasonable time. Like two hours or so, I think.
Chromium and WebKit are ginormous, and worse, they are compiled with the latest C++ standards which are slow as hell to compile. Nothing wrong with my system, it just takes forever to compile this giant bloated crap. I need more CPU cores, to blast my way through the pile of work that needs to be done.
Look of the size of the Chromium source code archives these days. It's fucking outrageous. 15 compressed gb (and growing rapidly!) of third party code vendored inside third party code vendored inside third party code, three or possibly even four levels deep! ("Yo Dawg...") Let's just have 5 complete copies of the LLVM suite in random places in there, because why not? Google has lost its marbles.
Yeah, I'm working to fix Chromium's little red wagon too. I'm on version 3 of my custom Chromium build. The binary of version 2 was slimmed down to 186 mb in size (compare to Google's version), with a 300 mb source tree (same) when I quit on it to start version 3. There was plenty more to take out. This latest version is going to be the best yet.
Who's the guy with Firefox 147 32-bit x86 who downloaded a patch? Nice to see there's still at least a few 32-bit users left out there. My system cross compiles to i686, and builds as multilib (both 32-bit and 64-bit libraries) for x86-64 as well, FYI.
Some of these User Agents have to be fake. Android 6.0.1 with Chrome 144, really? lol
No, not even close. Totally different projects. This one is for experts only, or those who want to become experts. The type of person who has been toying with the idea of building a LFS system but doesn't really want to go through all the work and headache (and it's a ton, to build a full system.) It also supports cross compiling to other architectures, which LFS does not.
This system has many powerful features like built in ccache/distcc support for the build, support for building in QEMU, etc. Eventually it will be fully sandboxed.
There is a heavy emphasis on Doing Things Right according to an old school way of thinking. Everything is kept as simple as possible, yet as full featured as is practical. A major goal is to have everything documented and explained, starting with the shell scripts which build the system step by step in an easy to follow manner.
No package manager currently, though a simple one is in the works which is integrated into the build scripts. It's not really needed. You just build a complete system with all packages you want installed in a single run, with your own configuration pre-loaded. This gets compressed to a tarball. Then to install, create a partition, extract the tarball, edit a few files, install the bootloader, set passwords, and go.
I haven't done LFS since my tweens (and I'm almost 30 now), but I remember the sysvinit portion amounted to, past building and installing the init binary, downloading and extracting a bunch of shell scripts into the target directory and following some instructions for creating the right symlinks.
Obviously, you can go and check out the init scripts (or any other individual part of LFS) as closely as you wish, and it is easier to "see" than systemd. But I strongly protest that sysvinit is either "Linux" (in that it constitutes a critical part of "understanding Linux" nor that it's really that understandable.
But setting aside all of that, and even setting aside the practical reasons given (maintenance burden), when the majority of "Linux" in the wild is based on systemd, if one wanted to do "Linux From Scratch" and get an idea of how an OS like Debian or Fedora works, you would want to build and install systemd from source.
For me, Linux From Scratch is not about compiling linux from scratch, but on building up an entire Linux distro from the ground up, understanding how every piece fits together.
Doing it via systemd is like drawing a big black box, writing LINUX on the side, and calling it a day.
You are necessarily working with very big blocks when you're doing this, anyway. You don't do a deep dive on a whole bunch of other topics in LFS, because otherwise the scope would become too big.
That's what I was trying to get at -- yes, you can say that sysvinit is easier to understand than systemd, and less of a black box. But, even still, a "real Linux distribution" is full of these black boxes, especially the closer you get to being able to run "real applications". I'd argue that once you get into full desktop seat management, you add so much complexity on top of sysvinit that the difference narrows...
Which is why I asked "learn about what stuff". I think if the goal is to learn about "Unix" or OS design/ideas, you're better off with a leaner, "pedagogical" OS, like xv6. If the goal is to piece together an OS and really understand each piece, I don't think you really want sysvinit. You want something closer to an /etc/rc.local that just kicks off a few daemons and hopes for the best.
You can argue that sysvinit makes a better "compromise" between usability and clarity, and I'd entertain that idea, but then I think dinit is far easier to understand than sysvinit. And of course, at that point you can shave yaks till you fill the bike shed with wool.
Realistically, as much as people may hate it, if you have to pick a single init to standardize on for clarity and "building an entire Linux distro from the ground up, understanding how every piece fits together", systemd is the most rational choice. It's the most representative of the ecosystem, and requires the least "extra layers" to make the "desktop layer" work.
"best" meaning the best decision the LFS team can make given their limited, unpaid time and resources. They feel maintaining guides for two parallel init systems is unsustainable even though they would prefer not to have systemd as the only option.
The actual best decision would be to stick with his principles and make LFS be sysvinit-only instead, with zero fucks given about Gnome/KDE if they refuse to play ball.
I for one will not be strong armed into systemd or any other tech. If KDE makes it impossible for me to run without systemd, it goes into the trash bin. I will just install Trinity (KDE3) and be done with it. (Gnome deserves no consideration whatsoever.)
Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one.
I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.
The problem is ultimately that by choosing one, the other gets left out. So whatever is left out just has one more nail in its coffin. With LFS being the "more or less official how-to guide of building a Linux system", therefore sysvinit is now essentially "officially" deprecated by Linux. This is what is upsetting people here.
I'm OK with that in the end because my system is a better LFS anyhow. The only part that bothers me is that the change was made with reservations, rather than him saying no and putting his foot down, insisting that sysvinit stay in regardless of Gnome/KDE. But I do understand the desire to get away from having to maintain two separate versions of the book.
Ultimately I just have to part ways with LFS for good, sadly. I'm thankful for these people teaching me how to build a Linux system. It would have been 100x harder trying to do it without them.
Linux is just a kernel, that does not ship with any sort of init system.. so I don't see how anything is being deprecated by Linux.
The LFS project is free to make any decisions that they want about what packages they're going to include in their docs. If anyone is truly that upset about this then they should volunteer their time to the project instead of commenting here about what they think the project should do IMO.
he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison. systemd-init is a small slice of the code in the systemd repository.
I'm guessing he shares my belief that systemd-init cannot exist in the wild on its own, correct? When you want a teacup, you have to get the whole 12 place dinner set.
IIRC the mandatory components are the init system, udev, dbus, and journald. Journald is probably the most otherwise-optional feeling one (udev and dbus are both pretty critical for anything linux regardless), though you can put it into a passthrough mode so you don't have to deal with its log format if you don't want. Everything else is optional.
> he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison.
See, this is why when I refer to the Systemd Project, I spell it as "SystemD", and when I'm referring to systemd(1), I spell it "systemd". I understand that some folks who only wish to shit on the Systemd Project also spell it that way, but I ain't one of them.
> systemd-init is a small slice of the code in the systemd repository.
Given the context:
Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.
I'd say that the topic of discussion was SystemD, rather than systemd. systemd doesn't provide you with all that many capabilities; it's really not much more than what you get with OpenRC + a supervisor (either supervise-daemon or s6).
I'm with you on this. SysVinit is better than systemd, but far from perfect. I don't enjoy tediously maintaining all of those symlinks, and prefer the BSD approach myself.
One project on my distro is a new init that will be much, much simpler than SysV, more like BSD and without all the years of cruft.
Linux is literally 62k C files. The amount of time you'll spend understanding how Linux works will dwarf systemd. At least when studying systemd you will be learning a more modern approach of init systems.
I'd just like to interject for a moment. What you're referring to as Linux, is in fact, Linux plus systemd, or as I've recently taken to calling it, Linux/systemd.
Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, systemd daemons, and vital systemd components comprising a full OS as defined by Poettering.
I am looking forward to UnixFromScratch and Year of Unix on the desktop as Linux more and more sells itself out to the overstuffed software virus that is System D.
I can absolutely say that I've never had a showstopping problem with sysv. That is about 30 years as a unix & linux admin and developer.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
Your points are well taken. Linux is far from perfect and people shouldn't worship it. sysvinit is inferior to BSD init in my view and there are other questionable design decisions.
The biggest problem is that people are being railroaded into one thing or the other by the strong arm of corporations instead of being given options. My system helps with that.
I won't support systemd/wayland/etc, but others easily can add that in to their version of the distro if they like and support it themselves without too much work, as it's designed to be forked by anyone.
Equally tiring is the “it works for me so stop complaining” replies, which do nothing to stop the complaints but do increase the probability of arguments. Want the complaint posts to stop? Suggesting that they’re in some way invalid is not the way.
Yeah, it’s so tiresome that other people have a philosophy different from mine which seems to have prevailed for now. Like ok so sorry. Systemd on linux is the worst of both worlds imho which apparently according to GP to which I’m progressively less entitled. I like NetBSD and its rc init and config system. Oh no systemd sore winners incoming!
Imagine that, people on the internet disagreeing. I've had both sysv and sysd crap in my cheerios. The thing I appreciated about sysv was that it stayed in its lane and didn't want to keep branching out into new parts of the system. Sysvinit never proposed something like homed.
My experience, and the common experience I’ve read, is the exact opposite. Run scripts worked. They always worked. They were simple. I’ve run into so many difficulties with systemd, on the other hand. I gave up managing my own server as a result.
I understand where you’re coming from but early systemd with both ubuntu and centos was a fucking mess. It’s good now but goddamn it was painful and the hate is 100% justified.
> Not once in my career have I experienced a showstopping issue with systemd.
Like clockwork, we'd have a SystemD edge case cause a production-down incident at a (single!) customer site once per year. Inevitably, we'd burn anywhere from a half day to a week attempting to figure out WTF, and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
The project is full of accidental complexity that its maintainers can't be bothered to fix when unplanned interactions cause problems and are brought to their attention. I certainly don't blame them; that sort of work is only interesting to a very specific sort of personality, and that sort of personality doesn't tend to thrive in a typical software company.
I can also absolutely say that I've never had a showstopping problem with OpenRC in the nearly twenty-five years I've been using it. It's remarkable how reliable it is.
> and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
Do you have a reference? Not that I don't believe you, but I hated this behaviour from Poettering (although he seemed to more often blame the user) and we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
I'm afraid I don't have a reference. The combination of the facts that the bugs are always damn obscure, there are so many Github Issues filed against systemd/systemd, $DAYJOB keeps me so busy with a huge variety of tasks, and the inappropriate lack of giveashit demonstrated by the project maintainers made me so angry means that the details just get blown out of my head.
> ...we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
To whom would these issues be raised to? Based on my personal and professional experience, the SystemD maintainers (and -for those who are paid to work on the project- those who manage them) seem to disagree that "eliminating sharp edges" is a big priority!
While I'll ignore the System D hyperbole, your point about Unix has merit.
I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.
From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.
I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?
When I was building the initial version of my distro starting from a Linux Mint computer, one time I accidentally double-mounted the virtual filesystems (/tmp, /run, /proc, etc), on the target volume as my script was too primitive and didn't check the mounts first.
Exactly 60 seconds later, the whole system crashed.
Later I accidentally did this again, except this time immediately caught the problem and undid it. No matter--systemd still crashed 60 seconds later anyhow.
Or like the bug that was revealed a while back where the firmware EEPROM was writable by default in /sys or wherever it was, resulting in somebody's firmware getting overwritten and the system bricked. lol
That's the systemd life for you, in a nutshell. That sort of thing times a thousand. Not all at once, mind you--it will just take a nibble out of you here and there on and off until the end of time. After a while it will straight up fuck you, guaranteed. Which is exactly what it was designed to do.
Same with anything "Linux Puttering" touches. The guy who is now officially a Microsoft employee, as people were saying he really was all along.
Bear in mind that the entire purpose of systemd is to replace a huge amount of previous system administration solutions in a fashion that is centralized and automated, and not in need of as much human intervention as previous init systems. For copious examples, look through these comments and the huge number of previous HN threads on this huge topic. That is my answer.
I can do gainsaying too: surely you didn't look through these comments and the huge number of previous HN threads on this huge topic. Do your own work.
Sadly is Linux is no longer what is used to be for my generation that cut their teeth having to patch kernels for basic hardware support.
Linux is now effectively systemd/linux, and is attempting to become flatpak/systemd/linux through various corporate sponsored initiatives. The only thing worse, in my eyes, are people who distribute things as docker containers.
The Linux distro as such is becoming an anachronism. There’s no real place to innovate without the inertia of choices made by external projects being enforced on you.
I think it’s a generational change. My generation had Microsoft to contend with, and so sought certain freedoms, but this generation has walled gardens and AI to contend with, so freedom à la Microsoft seems okay and so Linux is being Windows-ified, while Windows itself becomes its own abomination.
This is my issue with systemd. I wanted Linux because I wanted to have a choice. The philosophy was that users should have a choice. Systemd goes against that: it's taking over everything and more and more projects require systemd. Flatpak as well: if a project only supports flatpak, chances are that it won't be easy to package normally. So if I don't use Flatpak, I'm screwed.
People who don't see the problem with systemd "because it works" miss the point, IMO. It's like those devs who proudly ship their project in a docker container, because they are not capable of making it properly available to package maintainers. "It works", but I can't package it for my distro because it's a big mess. Developers don't have to package their project for all distros, they just have to properly provide the sources. But more often than not, they don't know how to do that, and instead see Flatpak/docker as "good alternatives that just work".
> Developers don't have to package their project for all distros
Essentially nobody uses the sources we provide. Literally nobody packages them. A few people use our rpm and deb packages, but the vast majority uses a (slightly broken and outdated) docker image built by third party.
You might not like it, and I certainly do not, but unfortunately containers seem to be the best alternative that just works, compared to everything else.
> but unfortunately containers seem to be the best alternative that just works, compared to everything else.
I think it's actually the worst alternative that works. If it didn't work, people wouldn't do it. And the better alternatives require more effort.
I think it unfortunately goes with popularity: when programming becomes more accessible, the average quality of code gets worse. When Linux becomes more accessible, the average level of its users gets worse.
What made Linux desirable for me risks getting worse the more popular it gets. I went from Debian to Arch, to Gentoo, and eventually I may have to move to a *BSD. Because apparently what I want disappears when a system gets massively popular.
I've been using Gentoo for 20+ years, it hasn't changed much. I have changed different logger, cron, ntp, login and probably other daemons over time. Stability has gotten better over time, making me not switch to anything else.
I absolutely love Gentoo, and I actually wonder why I haven't moved there earlier (probably I was scared, and the availability of binary packages gave me a reason to try).
I really didn't want to mean that systemd/flatpak are impacting Gentoo and that I am considering moving away.
My hope is that some distros like Gentoo will keep the "old" spirit of Linux forever, while others try to please those who want Windows-but-without-ads.
Except for the main pid1 process, systemd is one of the most customizeable things, certainly much more than old shell-based things. Everything is documented, can be disabled or replaced, and in such a way that the rest of the system can keep functioning, and the system upgrades don't mess it up.
A lot of people said you can edit /etc/init/ scripts, but this was pretty annoying, as the moment you upgrade the package, your package manager throws a conflict at you. It was certainly non-scaleable if you have many machines with automated upgrades. Compare to systemd overrides, where there is both drop-ins and wholesale service replacement, and system upgrades never mess with that.
Heck, even something as simple as "disable distribution-provided service" was a pain! I can't remember how many times I've added "exit 0" to /etc/default/something file, just because the sysvinit did not respect user decisions during upgrades or reinstalls! Compare to systemd, where I can "mask" the service even before it's installed.
And for deeper changes? Pre-systemd ubuntu had this this stupid "system is online" idea, and I once needed to customize this.. this was lots of undocumented reading and hacking on the script, and let's hope we did not need to upgrade. Or something like "my service X should start after NFS, but ssh should start before NFS" - this was pretty hard as well, and would cause upgrade conflicts.
Systemd has lots of problems, but the customizeability is one of their best parts. It is the only thing that I know which clearly delimits "user" vs "distribution", and gives all the power to user.
I am not sure if we are talking about the same thing. I am not saying that systemd is bad. I am saying that when a project has a hard dependency on systemd (which is not necessarily systemd's fault, to be fair), then it doesn't work with an alternative init system.
Right, but my point is that unlike earlier init systems, unless that dependency on pid 1 itself, there is nothing preventing alternative implementations, and in fact, there is all the support to make such implementations possible.
To give an example, let's say a package depends on systemd because it uses sd_journal protocol, presumably because it wants to send enriched logs. That protocol is fully described (in [0]), and is actually pretty trivial to implement, on both server and client side. It even have a build-in "upgrade" mechanism (via $JOURNAL_STREAM) to allow seamless switch between base/systemd-logs, although AFAIK sd_journal_* functions do not implement it by default.
So this brings us a question: if a program wants to provide rich logs, and it is is using a documented protocol to do so, but there is only one implementation of the receiver, is this a problem? Is the onus on the program's authors to support multiple log sending functions, or on the distributions to provide a log receiver that the program expects?
The American government added some obscure law that forced POSIX compatibility on operating systems for certain grants, so Microsoft made their business OS POSIX-compliant.
In theory, nothing stopped you from downloading and installing up-to-date versions of common UNIX tools. Had Microsoft had the necessary foresight, they could've killed deverlopers' dependency on tools like Cygwin and Git Bash and Linux entirely for many pieces of software, but they were too busy trying to make Win32 the standard ABI.
Funnily enough, Win32 became the standard for proprietary software on Linux (thanks to Wine+Proton) while many Unix/Linux-based tools became the norm for development, even on Windows (git, Qt). How different things could've been!
> Win32 became the standard for proprietary software on Linux
This isn't even possible at all. You have software and standards. There's no single set of software nor a single set of standards. Saying something or somesuch is "the" standard is plain false.
All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future, or at least a linux distro from the list here https://nosystemd.org/ - probably Gentoo. Nothing to stop me, absolutely nothing at all. I just need a few days free to backup/wipe/reinstall/reconfigure/restore_data and I'll be good. Better make that a few weeks. Maybe on my next machine build. It's not easy, but I build machines for long term use.
As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.
What practical problems do you run into with systemd?
All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".
But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.
People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.
Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.
Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
> But there's a reason it's being adopted: it does it's job well
My problem with systemd is that it's taking over more and more and locking in. It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative.
My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in".
We like to complain about lock-in across the board. I don't see why it would be different with systemd.
I think you got it backwards. Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
I somehow don't think your gripe is with systemd but with developers who prefer the easy route. To be honest though you get something for free. If you want it differently then you have to do it yourself.
I don't think it's backwards; it's not incompatible with what you said.
> It is just nice to know that all the tools you need for a system are there and work together.
It is indeed! Just like everybody uses WhatsApp for a reason. But because everybody uses WhatsApp, it is very difficult to get traction with an alternative. That's the lock-in part.
It is easier for developers to only care about systemd. It's often worse: many times I have seen projects that only work with Ubuntu. Of course I understand how it was easier for the developers of those projects to not learn how to "be nice" and "do it right". That does not mean I should be happy about it.
> If you want it differently then you have to do it yourself.
Or I should support alternatives, which I do. I am not saying you are not allowed to use systemd, I am just explaining why I support alternatives. Even though systemd works.
I'd argue that "do it right" and "be nice" are incredibly subjective. I'd say they were already nice enough to write open source software. And I don't think it is wrong to to write what you want to write.
The comparison with WhatsApp has a a huge flaw: WhatsApp is not LGPL licensed software. No one can really take systemd away. There is very little risk in depending on it apart from less choice. But I already argued that the expectation of choice in free software is a big ask.
And there is no one stopping anyone from implementing systemd's api surface.
The reason why I say you got it backwards is that you are against systemd making available all their tools when in reality it is the distro maintainers choice to use them and the developers choice to depend on them. Most of systemd is optional and nothing prevents developers from writing abstractions. But the simple truth is that systemd is offering a compelling value that people are just accepting.
> Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
That's the official story, but like most official stories, it doesn't really hold up to scrutiny.
I built an entire system from scratch with over 1,500 packages installed. Everything under the sun. Works just fine with sysvinit. Completely seamless.
If KDE/Gnome can't figure out how to fit in with the overall system design the same way thousands of other packages somehow manage to do, then their services are no longer required. Good riddance to their bloated asses. I prefer to invest my CPU cycles in better software.
Init scripts for services and such are properly handled by the distro maintainer (packager), not the developer, although it's always nice to see examples he's provided to help guide the development of my preferred version.
I am honestly happy for you that you made your system the way you want it. That is a good thing and please keep doing what you are doing.
This is not relevant to the average user. The average PC user doesn't use Linux and the average Linux user uses an off the shelve distro. For these distros it is very attractive to have a bunch of core services ready that work together because they are released as one. It can be done but why the hassle? What is the upside for the maintainer apart from maybe the moral high ground?
Software projects can also benefit from standardization. They can concentrate on writing functionality instead of maintaining abstraction layers. And I believe the more mainstream distros choose the SystemD stack the more it becomes the default or at least the initial implementation for their software.
We also have to keep in mind that this kind of standardization is nothing new. Pretty much every distro depends on the GNU coreutils. Maybe not on the binaries themselves but at least on their API. That is not very different from SystemD. We have a POSIX standard.
Final word regarding sysvinit: I worked with sysvinit, upstart and systemd and having an opinionated config format for services is so much better, in my opinion. Not having to read a whole shell script to know how a service works is such an improvement and the easy overrides for units (for example distro packaged ones) is amazing.
Note: In my post I counted distro maintainers as developers.
You lost me when you started talking about the average user. I don't care about that guy or his desires. At all.
I miss the days when computing was about the above average guy--not the simpleton who needs his hand held, so everything has to be dumbed down to the lowest level to suit him.
Heard it all before, and I'm not interested in anything systemd has to "offer." Especially all the bugs and security issues.
This distro isn't for you. That's OK. systemd, and wayland, etc that some are so excited about isn't for me or a number of others, and it will never be. We are going our separate way. Just look at all the comments below. Lots of upvotes too.
It's not a lock-in as much as making a much better product.
For example, I never liked the idea of having my programs to manually daemonize, manage logs, set up permissions and all that boring, but security-critical stuff. And with systemd, I don't have to! Program reads from stdin/stdout, maybe gets socket from socket activation, and systemd does the rest.
Is it lock-in? Only because other system suck. Like, seriously, what stopped xinetd from having rudimentary volatile "on/off" control, so I could disable misbehaving service? Or why is start-stop-daemon so _stupid_, discarding all startup error messages? And don't get me started on all the different init file dialects for each system.
Maybe if the sysvinit programmers actually cared about providing nicer services to app developers, we would never end up with systemd.
The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.
.. and that opinion is a great explanation of why systemd won.
Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet.
It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people dismissed the sysvinit early on because it had no features (example [0]), which means the choices were either upstart and systemd. And between two of those, systemd is a clear win.
Read the thread and look at how many highly technical people with no relation to Fedora or Poettering is ready to choose _anything else_ just to get away from "it's been done for decades".
Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)
FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.
Systemd usually only modifies the state if is somehow configured to do so. Socket activations, timers, depwndencies. They all tell systemd what to do and can usually be modified if needed.
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.
But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.
To give you concrete examples:
1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.
2. Except that you can, but only if you use the /etc/fstab compat.
3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.
4. Systemd has separate behaviors for network and local filesystems.
5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!
6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.
7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.
I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report.
This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
> I think better proof of this would be a rejected PR rather than a neglected bug report.
I understand the sentiment you're expressing here, and it's often a reasonable one.
However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not that behavior is correct. Maybe we should do something about this or document this so other folks know about it." (and then nothing happens, not even the documentation) or a closed Github Issue with "Sorry, your usecase is <strike>inconvenient to implement</strike> unsupported. E_NOTABUG", expecting PRs is expecting way too much.
I've long been in the habit of reading accounts like yours, understanding the truth and wisdom that's being expressed, then noping the fuck out of the tech/product/situation in question. It has saved me a lot of trouble over the years. Even as others are completely mystified. Some people just like abuse, I guess.
Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because."
I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy.
I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local").
I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms.
I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this?
It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing.
Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo.
I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote").
systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you, as the administrator, describe the network dependency for that specific instance.
But what if all we have is the filesystem type (e.g. if someone used mount or /etc/fstab)?
Linux doesn't tell us that the filesystem type is a network filesystem. Linux doesn't tell us that the specific mount request for that filesystem type will depend on the "network". Linux doesn't tell us that the specific mount request for that filesystem type will require true network connectivity beyond the machine itself.
So, before/without investing in a long-winded and potentially controversial improvement to Linux, we're stuck with heuristics. And systemd's chosen heuristic is pretty reasonable - match against a list of filesystem types that probably require network connectivity.
If you think that's stupid, how would you solve it?
> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?
Like systemd authors do! Hard-code the list of them in the kernel, including support for fuse and sshfs. Everything else is pure blasphemy and should be avoided.
Me? I'd have an explicit setting in the mount unit file, with defaults inferred from the device type. I would also make sure to not just randomly add landmines, like systemd-update-done.service. It has an unusual dependency requirements, it runs before the network filesystems but after the local filesystems.
I bet you didn't know about it? It's a service that runs _once_ after a system update. So the effect is that your system _sometimes_ fails to boot.
> systemd has .mount units which are way more configurable than /etc/fstab lines
It's literally the inverse. As in, /etc/fstab has _more_ options than native mount units. No, I'm not joking.
Sounds like your admin, distro, or the systemd team could pay some attention to systemd-update-done.service
The "can only be used in /etc/fstab" systemd settings are essentially workarounds to do those things via fstab (and workaround fstab related issues) rather than depend on other systemd facilities (c.f. systemd-gpt-auto-generator). From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
This service is the standard part of systemd. And my distro is a bog-standard Fedora, with only iSCSI as a complication.
Are you surprised that such a service exists? I certainly was. And doubly so because it has unusual dependency requirements that can easily lead to deadlocks. And yes, this is known, there are open issues, and they are ignored.
> From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
No, they are not. In my case, I had to use fstab to be able to specify a retry policy for mount units (SMB shares) because it's intentionally not exposed.
> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?
The '_netdev' option works a treat on sane systems. From mount(8):
_netdev
The filesystem resides on a device that requires network access
(used to prevent the system from attempting to mount these
filesystems until the network has been enabled on the system).
It should work on SystemD and is documented to in systemd.mount
Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case _netdev may be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.
but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.
Sure, and systemd would translate that directly into a dependency on network startup, which is precisely equivalent to the approach I mentioned that depends on operator knowledge. It's configuration, not "just works" inference.
> Sure, and systemd would translate that directly into a dependency on network startup...
You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable:
In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown which should not have been there - and were not there - when the units were first loaded.
> ...not "just works" inference.
Given that SystemD can't reliably handle explicit use of _netdev, I'd say it has no hope of reliably doing any sort of "just works" inference.
I saw many corner cases in systemd over the years. And to echo the other poster in this thread, they typically are known, have Github issues, and are either ignored or have a LOLNO resolution.
And I'm not a systemd hater. I very much prefer it to the sysv mess that existed before. The core systemd project is solid. But there is no overall vision, and the scope creep resulted in a Cthulhu-like mess that is crashing under its own weight.
> "I found one bug in systemd which invalidates everything"
I'll refer back to the story of Van Halen's "no brown M&Ms" contract term and the reason for the existence of that term and ones like it.
"Documented features should be reasonably well-documented, work as documented, and deviations from the documentation should either be fixed or documented in detail." is my "no brown M&Ms" for critical infrastructure software. In my professional experience, the managers of SystemD are often disinterested in either documenting or fixing subtle bugs like the one GP linked to. I find that to be unacceptable for critical infrastructure software, and its presence to be indicative of large, systemic problems with that software and how work on it is managed.
I really wish SystemD was well-managed, but it simply isn't. It's a huge project that doesn't get anywhere near the level of care and giveashit it requires.
That is one of my problems with systemd: it has way to much "magic" built in. SysVinit/OpenRC and related are easy to understand and debug: they only do what's in the scripts.
I love systemd, but you've hit on one of my biggest complaints. The mounting promises a cohesive system and instead gives you a completely broken mess, with mounts being split across .mount unit files, fstab, and worst of all, .service unit files. It's a totally incoherent mess, and that's only _after_ you figure out why nothing is working right, and build a complex mental model of every single feature that does or doesn't work in which scenario. Knowledge you only gain after screaming and tearing your hair out for a weekend. Your reward? A totally incoherent, inconsistend mess.
OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on.
OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.
To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]:
#!/sbin/openrc-run
command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"
depend() {
use net
}
Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs.
Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]
[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.
[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).
> As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does)
Depending on what you want to do, a generator might be appropriate:
> Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins
Well, here are the relevant parts of the service file:
get_config() {
[ -f "${PGDATA%/}/postgresql.conf" ] || return 1
eval echo $(sed -e 's:#.*::' "${PGDATA%/}/postgresql.conf" \
| awk '$1 == "'$1'" { print ($2 == "=" ? $3 : $2) }')
}
depend() {
use net
provide postgresql
if [ "$(get_config log_destination)" = "syslog" ]; then
use logger
fi
}
If PostgreSQL has been configured, this reads its config file, looks to see if it's configured to use 'syslog' as its log destination, and -if so- adds a dependency on the 'logger' "meta-service". [0]
What would this look like with a systemd service file generator?
[0] What's a "meta-service"? 'provide postgresql' makes the service started by this service file provide the 'postgresql' "meta-service". This is useful for PostgreSQL because you can install multiple versions of the software simultaneously... so the service files are named like postgresql-17, and postgresql-18. The 'logger' "meta-service" is useful because who cares which syslog software you have installed... you only care that it speaks syslog.
Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations etc is… not a great idea in my opinion.
But of course in this particular case, because systemd makes the /dev/log journal/syslog socket a dependency of every unit by default, there is no need to encode this dependency at all.
Anyway if you really wanted to you could write this script as a generator and have it put a drop-in in /run/systemd/system/postgres.service.d. But… why?
Okay, I'll rephrase the question a bit and ask it again.
Imagine that you have a service that has a configuration-dependent dependency on rsyslog. For whatever reason, journald's not an option... maybe it's simply not installed, or this service depends on rsyslog-specific behaviors that journald simply doesn't replicate. It doesn't matter why this configuration-dependent dependency exists, it simply exists and there's no workaround.
Assuming that the rsyslog service is named 'rsyslog', the service with the dependency is named 'stupid-service', the configuration file is named '/etc/stupid-service/stupid-service.conf', and the configuration option to search that config file for is 'logging = syslog', what would the systemd service file generator look like to make 'stupid-service' depend on 'rsyslog' if and only if that config file contains 'logging = syslog'?
You appear to have worked with these service file generators, which is why I'm asking. I expect you'd know what the generator to accomplish this trivial task would look like, or if it was even possible with generators.
Also:
> Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations
Nah, this is substring matching and column-cutting. The only use of regexes ("#.*") is to remove comments. Go check out the format docs for the PostgreSQL config file. [0] It's pretty basic and straightforward.
Put a script in /etc/systemd/system-generators/ that does something like
if grep "logging = syslog" /etc/stupid-service/stupid-service.conf >/dev/null; then
printf "[Unit]\nAfter=rsyslogd.service\n" > "$1/stupid-service.d/10-syslog-dep.conf";
fi;
> It's pretty basic and straightforward
Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; it could potentially match a file just because some other option contained a multi-line value that had the string "log_destination = syslog" in it.
The whole philosophy of systemd is to move away from these kinds of "simple" and "mostly working" pile-of-shell-script systems to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.
> Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; ...
Where's that documented?
I tried the obvious things followed by a config reload. Here are the results (the 'log_destination' parameter is on line 482 of the config file):
log_destination = \
'stderr'
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "\"
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'stderr'"
LOG: configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
log_destination = 'std
err'
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
LOG: configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
log_destination = 'std\
err'
LOG: received SIGHUP, reloading configuration files
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 482, near token "'"
LOG: syntax error in file "/etc/postgresql-18/postgresql.conf" line 483, near token "'"
LOG: configuration file "/etc/postgresql-18/postgresql.conf" contains errors; no changes were applied
log_destination = 'stderr'
LOG: received SIGHUP, reloading configuration files
<No additional output is produced because 'stderr' is the default>
#log_destination = 'stderr'
LOG: received SIGHUP, reloading configuration files
LOG: parameter "log_destination" removed from configuration file, reset to default
What's the line continuation character for 'postgresql.conf'? Are you certain that you're not getting 'postgresql.conf' confused with 'pg_hba.conf'? That file is documented to support line continuations: [0]
The general format of the pg_hba.conf file is a set of records, one per line. Blank lines are ignored, as is any text after the # comment character. A record can be continued onto the next line by ending the line with a backslash. (Backslashes are not special except at the end of a line.)
> The whole philosophy of systemd is to move ... to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.
That's truly a lovely and laudable goal. In this system, how does you propose one processes a flat text config file with a mix of 'K = V' and 'K V' settings without doing ordinary, boring text processing? Do you propose that one waits until "systemd-configd" gets created and every daemon of any importance is updated to put its config in there instead of in flat files? If so, has there been any notable progress on this in the last ~fifteen years?
> Put a script in /etc/systemd/system-generators/...
Thanks for finally answering my question. Is the way to conditionally update service dependencies really to dump text files in magic locations? Is there no 'systemctl' (or similar) command that allows one to manipulate dependencies for a specific service that one can call from a generator?
I wonder if the impetus behind the (terrible) monolithic design of systemd was to force standardization across distros. The choice was more political than technical.
If different choices were available for init, DNS resolver, service control manager, volume manager, etc... we would adversely contribute to the schizo distro landscape the people holding the money bags are actively trying to get away from.
With systemd it's an all-or-nothing deal. You get the good with the bad, but all distros shit the bed in the same, deterministic way.
Not even Windows does this. There is no "systemd" equivalent. Yes, Windows ships as a single OS—as do the BSDs—but all the components were developed separately.
If all they wanted was a service control manager, there were many (better) options already in existence they could have used.
Outside of Arch(-derived) enthusiast circles, I haven't seen systemd-boot used anywhere.
It has some really nice tools and features that Grub lacks (i.e. it has tooling for checking the state of things like secure boot and analysing the security risks of your boot configuration), but every mainstream Linux OS I've used still relies on tools like Grub to boot.
I have some gripes with systemd-boot's limitations (notably, the insistence on an unthemed, white-on-black menu system that's not exactly enticing to Linux newcomers) but it's hard to deny its merits. Grub is tied together with a spider web of scripts calling each other, loading modules, generating code that is then executed again, and one mistake in one script can cause the bootloader config four scripts down the line to fail, leaving the system unbootable; the concise configuration file for systemd-boot makes for a much better bootloader configuration system in my opinion.
OpenSUSE uses systemd-boot for its GRUB2 BLS implementation (<https://news.opensuse.org/2024/10/08/grub2-bls/>). It's really awesome because it lets me boot from Btrfs snapshots on a fully LUKS2 argon2id encrypted system.
The argon2id issue remains an annoying problem (AFAIK Grub still doesn't support argon2id), but for tools like Timeshift there are Grub scripts to also boot BTRFS snapshots.
and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
I'm tired of grub too. That's one of the packages on my shitlist. Currently it is broken on my system, as it has been in the past from time to time. I'm tired of the unreliability and have decided to write my own bootloader instead. It will be simple and bulletproof.
I already laid the basic foundation and have the kernel loading into memory and booting. Next step is to get the memory map and pass that along. It's BIOS only for the moment; EFI support will come later, along with other architectures. (PowerPC is next.)
The thing is not just about distros and big developers it is about every developer out there who wants to write system software. Instead of doing the work to support multiple different APIs they can concentrate on the software. Its just easier. You don't have to track the compatability of different tools.
For many people Linux is not an academic exercise. It is a tool they want to use. The don't care to use a different network manager or resolver.
And that is exactly the same as Windows. There is one solution across the whole system and it works together because it is written by the same people and tested together.
Try Alpine? It's not designed to be a "desktop" OS but it functions well as one. I find it easy enough to wrap my head around the whole thing, and it uses OpenRC by default.
Almost wonder if this kind of thing will be an impetus for GNU Hurd to get more momentum. I saw an update recently that they're now finally properly supporting 64bit and sounds like there's active dev going on there again.
Others have been reminding us of the *BSD init systems, and I remind that SysVinit is not going away from Linux while projects like Devuan and others continue. GNU Hurd is another other-than-systemd learning opportunity.
hurd init is a lot like systemd architecturally, it just gets to use kernel provided ipc rather than having to manage its own. if your objection to systemd is its architecture you don't want anything to do with hurd.
I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel.
Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.
> All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future
Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency).
Gnome 50 plans to obsolete X11 completely.
If you want that simple, bright future of yours, you’ll have to fight/work for it.
There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.
You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.
If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.
Phoenix looks pretty cool too.
KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.
> Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?
I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility.
He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal.
So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN.
We don't have to guess, the PRs & history are still there. You could easily go through them and find examples of the project members being unreasonable about ABI compatibility.
SysV init was the overengineered cousin to BSD init and I never liked it. Easily my least favorite of all init systems I've worked with over the last 30 years. On the flip side, daemontools or maybe runit were my favorites. Lots of good options for init/supervision tooling over the years and SysV was not among them.
If we look on LFS for its academic merit, I'm saddened that key historical elements of Unix/Linux design are being left behind, much like closing down a wing of a laboratory or museum and telling students that they'll need to whip up their own material to fill in those gaps.
If the students have been well trained, they should be trusted to experiment. If the course curriculum demands that they produce something themselves yet does not educate them on doing so, that's horrific.
Back in the day, system run levels were seen as desirable. SysVinit went in on that concept to the max. So, if the concept of run levels isn't clear to the student beforehand, the init system for making it happen would therefore be mystifying and maybe even inscrutible.
Runlevels may be an interesting idea (e.g. the single-user maintenance level). But a bunch of shell scripts, each complex enough to support different commands, sort-of-declare dependencies, etc, is not such a great idea. A Makefile describing runlevels and service dependencies would be a cleaner design (not necessarily a nicer implementation).
On the contrary, I much prefer a full Turing complete language rather than trying to shoehorn my ideas into someone else's limited system.
The scripts don't have to be complicated, and it doesn't have to be shell scripts. You can use any script or executable that the Linux kernel can load and run. But shell scripts work great and have all the power needed.
Systemd is a giant, flaming heap of buggy ass code. Good riddance to it.
> 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.
However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.
Read the article: "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"
Maybe they're KDE users. I was under the impression that gnome requires it. FTA it sounds like KDE will soon too. Gentoo doesn't come with a desktop by default either, you have to emerge it, which might install systemd..
FTA: "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"
> I was under the impression that gnome requires it.
It doesn't seem to require it at this moment. I have "-systemd" in my USE flags, and have neither sys-apps/systemd nor gnome-base/gnome currently installed. After enabling several USE flags that have nothing to do with systemd [0], emerge was quite happy to offer to install gnome-base/gnome and its dependencies, and absolutely did not offer to install systemd.
Honestly, I don't even know if GNOME has a hard dependency on Wayland... I see many of the dependent packages in the 'gnome-*' categories have an "X" USE flag. I CBA to investigate, though.
Is KDE Plasma building in hard systemd requirements, or is it just building in hard Wayland requirements? I'd known about the latter [1] and -because I'd thought it was important to the KDE folks that KDE runs on BSD- would be surprised if they irreversibly tethered themselves to systemd.
[1] Though do note that the same blog post that announced the change in policy for Plasma also announced that no other KDE software was going to have a hard dependency on Wayland for the foreseeable future.
LFS never had academic, educational, or pedagogical merit. It was always sheer faith that by doing enough busywork (except the truly difficult stuff), something might rub off. Maybe you learn some names of component parts. Components change.
Could you expand on this comment please? (I don't think your viewpoint should be so rudely dismissed through downvoting and moving on.) What do you mean?
SysV was this weird blind spot for many years. I remember installing daemontools on the OpenBSD server my office ran on because it was nicer to work with, and thinking that the Linux world would switch to avoid losing that particular feature war with Windows.
Gentoo Linux has been using OpenRC for at least as long as I've been using it (~25 years). It's unfortunate that OpenRC was unable to summon the manpower to do the spot-additions required for it to win the political war way back when Debian was looking to move from straight SysV init.
It would have never happened. Systemd wasn't chosen because "we the people" chose it. Things don't work like that anymore, regardless of what the marketing brochure might say.
It's always a little amusing when the Open Source Tea Party bemoans the lack of "the UNIX way" and someone else with actual historical experience (and not misguided nostalgia) brings perspective.
On a related note, X11 was never good and there's a whole chapter in the UNIX-HATERS Handbook explaining why.
The proof in the end that SystemD is a cancer in the Linux ecosystem.
Officially it is just a stack and you can decide to use another one if you don't like it. Unofficially RedHat money ensured that other critical stacks will depend heavily on it so that you can't easily swap without replacing the whole ecosystem.
I've personally run Gentoo with OpenRC+glibc and OpenRC+musl on my laptop. I assure you ditching systemd was easier than ditching glibc. The OpenRC system mostly just works (tbh thanks to a lot of great work by Gentoo devs). The musl system required probably a couple dozen patches to various packages to get a basic fully working desktop (most of which were relatively straightforward, but still needed manual intervention).
On my system I forked dash to create 'bolderdash.' Right now it's pretty basic, I have changed little (just did some cleanup), but I did add in a couple tweaks to enhance bash compatibility. The goal is a complete refactor, more compatibility with bash, and much better command line editing etc, while still remaining sleek and lightweight.
I'm also forking musl to create 'powrlibc.' It will have a lot better glibc compatibility, as well as better optimizations and some other improvements.
Where did you get that sweet RedHat money? I feel like I'm missing out, I'm happily using systemd, where are my RedHatBucks!
Seriously, I would not ever go back to a house of cards of bash and shell scripts of an init system. systemd solves actual problems and gets shit done, with a level of consistency that cannot be achieved by LEGO-like wet-dreams of UNIX worshippers. My favorite example is systemd-resolve and systemd-network that actually communicate together to indicate which DNS server is available on which network interface and with which search domains, to gasp do proper DNS routing.
Am I happy with all of systemd? Not always, it has a tendency to break networking after an upgrade with reexec. I'm still not convinced about homed. But oh my, you don't have to look further than actually solving problems to explain its success.
It's like the good old time of Windows. You asked users, they would say that Windows is great, they don't have problems, works better than Linux. Oh do I get some error popups and crashes sometimes? Indeed just I forgot, I'm so used to close them without reading the message...
Systemd and co broke so many many things and so often that it is hard to count. A lot of things possible before are not anymore because of this giant ball of mud. It is just like the Windows monolith now.
Is it totally bad, no, for sure there are some advantages , but nowadays you will have issues, like network issues such as the one you describe and people will not know it comes from that.
Actually, before you almost never had to reboot or reinstall for anything. In case of boot issues and co, you would just need a console to be able to fix it. Systemd got even advanced users to be used to reboot and reinstall in case of problem as deep issues are often unfixables.
> 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.
Systemd is basically the Windowsfication of Linux. I'm always surprised by the people that champion it who also used to shit on Windows with the registry or whatever.
LFS seems to be for people who are interested in how things work. The systemd proponents come off as people who would question why you would want to to drive a manual transmission and say of course you should choose an automatic or better yet, a robot; self driving car.
It would be interesting to see how those opinions line up with the uses of AI
I have owned many manual cars, but I'm fine with systemd on all my machines. Being a nerd about one thing doesn't require me to be a nerd about other things.
It is not cognitive dissonance to learn from others. The pluggable nature of Linux makes developer lifes harder. They have to write wrappers and abstractions to use base functionality. Having a unified api surface is very attractive.
Windows did something right because you can run very old binaries on a new system. Good luck doing that on Linux.
In the end for most people Linux is not an intellectual exercise in freedom but a tool to get work done and systemd is pretty good at that and is getting better.
And another important point: systemd is still lgpl licensed software. There is literally no legal way for someone to rug pull it. So if it works and brings a benefit it might be a good thing to start to depend on it. Just like we depend on the GNU tools.
> I said it was to attack one binary blob abstraction while embracing another.
You didn't say that but even if you meant that systemd is an open source project and it has multiple components. It is not just a binary blob. It is a coherent framework for basic system services. It is pick and choose for the most part. Most distro choose to use all of it.
I still disagree that liking systemd and disliking windows is incompatible. Windows is a closed source project, developed without much external input that has a clear monetary incentives that are often user hostile. The way it's system api works is rarely the reason for criticizing it.
Pedantic but systemd is inspired by MacOS launchd, not by Windows services. It has nothing akin to the registry, which even microsoft admits is a pain on windows.
Oh, and usually people shit on windows for many reasons, but some of the very core features of the OS are robust and the Linux crowd could take a hint. Like, you know, the notion of service at the OS-level and not some random bash script that nohup'd a binary. Oh wait, that's what does Windows, MacOS and Linux with systemd.
I didn't say it was inspired by the registry, I just drew a comparison. In both cases you have a huge binary thing that you have to interact with through secondhand tools rather than directly.
We generally aren't in the habit of using "random" scripts to do anything. They're usually carefully developed to do exactly what we need them to do, precisely, and nothing more. Not the giant pile of buggy ass code and security nightmare that is systemd.
By the way, you don't seem to be aware that you can use any language you want to create startup "scripts" including compiled binaries, if you hate shell scripting so much.
Do you even know any shell script? Serious question. Many 'bash' haters know nothing about the language--starting with calling it 'bash' instead of 'shell script.' There are several different flavors just of shell scripting languages, and bash is only one.
It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.
SysVinit has been seen by some people in the post-systemd world as some sort of mystifying mashup concocted by sadists, yet I've found that when it is explained well, it is clear and human-friendly, with easy uptake by newcomers. I echo that this decision is a pity.
It’s not just explaining but whether you have to support it on more than one distribution/version or handle edge cases. For a simple learning exercise, it can be easier to start with but even in the 90s it was notably behind, say, Windows NT 3 in a lot of ways which matter.
sysv is garbage tho. If unix philosophy is "make it do one thing and do it well", it doesn't do the one thing it is supposed to do well.
I dislike overloading systemd with tools that are not related to running services but systemd does the "run services" (and auxiliary stuff like "make sure mount service uses is up before it is started" or "restart it if it dies" and hundred other things that are very service or use-case specific) very, very well and I used maybe 4 different alternatives across last 20 years
Clearly there are lots of people who don't want something that does what you say systemd does. Bravo that choice is out there, but what a pity that LFS does not seem to have the resources to test future versions for SysVinit.
I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)
While Xorg itself (which isn't a monolith, BTW) provides more than the bare minimum, so does the Linux kernel - or even the Unix/BSD kernels of old - yet programs that did follow to the Unix philosophy were built on top of them.
In X11/Xorg's case, a common example would be environments built off different window managers, panels, launchers, etc. In theory nothing prevents Wayland to have something similar but in practice 17 years after its initial release, there isn't anything like that (or at least nothing that people do use).
At least in my mind, the Unix philosophy isn't some sort of dogma, just something to try and strive for and a base (like X11) that enables others to do that doesn't go against it from the perspective of the system as a whole.
I'm in the same boat. Systemd is an unpricipled mess and ships some quite shoddy replacements for pre-existing components. Wayland is super clean, it just takes for-everrr to add the features that users (and developers) expect. It could seriously have been done over 10 years ago not by heroic development effort, but by not being pathologically obstructive about features.
The two projects are complete opposites except in one way, they replace older stuff.
If you want to learn the system from scratch, the best way will be writing your own little init system from scratch, so you can understand how the boot sequence works. And as you make use of more and more of the advanced features of Linux, your init system will get more and more complex, and will start to resemble systemd.
If you only learn about sysvinit and stop there, you are missing large parts of how a modern Linux distro boots and manages services.
That's the point on which people differ. Even if we take as given that rc/svinit/runit/etc is not good enough (and I don't think that's been established), there are lots of directions you can go from there, with systemd just one of them.
And on the other hand, I have no sympathy for the Unix philosophy. I value results, not dogma, and managing servers with systemd is far more pleasant than managing servers with sysvinit was. When a tool improves my sysadmin life as much as systemd has, I couldn't care less if it violates some purity rule to do so.
> packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd
So drop them. There are other desktops that are faster, simpler, more stable, and aren't hard-coded to make Linux worse. Has everyone forgotten the design principles that made Linux good in the first place? Tightly coupling your software into other software is simply bad design. At some point you need to eat the cost of a looser abstraction to make your system less fragile, easier to reason about, and more compatible.
That's funny, I did LFS a few years ago and specifically chose the systemd version so I could better understand it. I don't think this is a huge deal, I believe the older versions of the document that include SysVinit will still be available for a long time to come, and people who want it will figure out how to muddle through. If at some point in the future things diverge to such a point where that that becomes untenable, someone will step up and document how it is to be accomplished.
Didn't you find though that systemd was just a black box? I was hoping to learn more about it as well- and I did manage to get a fully baked LFS CLI system up and running, and it was just like "ok install systemd..." and now... it just goes.
Sysv at least gave you a peak under the covers when you used it, and while it may have given people headaches and lacked some functionality, was IMHO simple to understand. Of course the entire spaghetti of scripts was hard to understand in terms of making sense of all the dependencies, but it felt a lot less like magic than systemd does.
> "ok install systemd..." and now... it just goes.
I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`
To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).
It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.
In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.
This decision means that no testing of SysVinit will be done in future LFS and BLFS versions. The onus will be on the experimenter each time, but my hope is that a body of advice and best practices will accumulate online in lieu of having a ''works out of the book'' SysVinit solution.
Modern mechanical engineers, to this day, learn the thermodynamics of steam engines. Not because they are living in the past, but because they are building foundation knowledge that will permeate everything they'll be doing in the future.
LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.
The world is vast, and I doubt that every mechanical engineer has studied steam engines, and that it makes a difference in the end.
Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students.
I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
I was considering forking the base book and maintaining it, as I have kept an eye and occassionally built the project over the years (I use it a lot for package management/bootstrapping/cross compilation experiments), but it appears there already is one: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2026-02...
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
It's funny I did an LFS system of my own a couple of years ago which I coined "Head Rat" Linux.
I used the SVR4 packaging system from heirloom-pkgtools (using this of a Claude port of V4 unix to x86_64 as well at the moment) for fun, and compiled up CDE on top of this to boot. I wanted to see what Linux would look like if you dressed it up as much like SVR4 as possible. I liked the result actually. It was kind of like what Sun might have done if they dumped their own kernel and switched to Linux instead.
Originally it used SysVinit, and I started working getting systemd to work with it (because after several years I've come to appreciate it) - but that's the point I stopped working on Headrat - I realised if I wasn't adding SVR4 stuff and was removing it instead, it wouldn't be SVR4 enough.
I don't know how I feel about it - after all I could do an LFS straight out of my head these days without referring to the LFS docs - but I do feel there is something lost when as a Linux community, we try to shove the baggage under the rug and pretend that things like SysV init didn't play a massive part in Linux's rise throughout the 90's and 00's.
History is important, even if we don't like the code today and have more capable tools. But I guess SysV init is deader than dead at this point.
The saddest part of this isn't the technical debate. It's that a project whose entire reason for existence is to teach you how things work has concluded that one of the most fundamental components of the system is now too entangled with everything else to offer a choice. That's not a vindication of systemd or an indictment of it. It's an honest admission about what happened to the Linux ecosystem's composability over the last decade.
Man. I'd really rather they did the inverse: drop systemd and only maintain the SysV versions of the materials, even if that means dropping GNOME/etc., because I think understanding the Linux init process is far more important than making any specific desktop environment available.
From a completely technical standpoint, is systemd really better than SysVInit? I ask this question in good faith. I have used both and had no problems with either, although for personal preference, I am more traditional and favor SysVInit.
I always dreaded trying to create a service with bash-based init scripts. Not only did it involve rolling a heck of a lot yourself (the thing you were running was generally expected to do the double-fork hack itself and otherwise do 'well behaved daemon' things), it varied significantly from distro to distro, and I was never confident I actually got it right (and indeed, I often saw cases where it had most definitely gone wrong). Whereas systemd has a pretty trivial interface for running most anything and having some confidence it'll actually work right (in part because it can actually enforce things, like actually killing every process that's part of a service instead of kind of hoping that killing whats in the PIDfile is sufficient).
Your link is irrelevant.
It points to OpenBSD which uses rc, not sysv.
The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.
Init and run control aren't the same thing. Which is part of what's nice about sysv (which, yes, OpenBSD's init is based on). OpenBSD's run control system is particularly nice, and it's the sort of thing you can use with an init system that isn't constantly eating everything.
It's probably straightforward for someone who works with it. For a newb like me, it needs effort to understand. I think unit files are self-documenting and straightforward to understand the first time you see them.
I hate it when a website assumes the language I'm speaking based on my IP. There is no apparent way to change it as well. It's just lazy and hostile design in my opinion.
>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
Do people who really uses LFS even want GNOME or KDE on their system ?
Maybe? When I did LFS/BLFS I opted for an i3-gaps setup with a compositor and some other eye candy, and had a lot of fun tinkering. I suppose some folks might want the experience of building an entire DE from source, but that seems like a bit much.
This seems good? LFS isn't about building Linux the way Linux was built 40 years ago. It's about learning how to do today's Linux, from scratch. Steps that lead to a radically different build from most Linux distros are therefore off the mark, and not really educational to show how a modern Linux is built.
"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."
I remember LFS from way back in the day.
What do we all think the overlap between LFS users and Gnome or KDE users is? I think it's pretty small.
Wow this is sad. If any distro keeps the old ways around it should be LFS or Slackware I would think. And maybe Gentoo.
I'm honestly worried about the forces pushing systemd in Linux spoiling the BSD ecosystem. And I'm worried that the BSDs do not have enough people to forge alternatives and will have to go along with the systemdification of everything. sigh
*Note, I ended up on Cachy, which is systemd, so I'm not some pure virtue signaler. I'm a dirty hypocrite :P
I ended linux from scratch support a long time ago. Well I did the right thing. Everything is systemd free on my side, for my own sake. This systemd is so much a "microsoft grade bad idea".
There is still interesting code patches here and there, and interesting info on brain damaged SDKs (gcc, glibc, etc).
Most of the time I remove the SDK itself, basically I write a linear and brutal shell script with fine grained control on the compiler/linker. I do push down to nearly remove completely the compiler driver (a spectacular failure) namely CPP->C->ASM->O.
I would like to move away from ELF too for a modern file format for dynamic libs and executable, but the "geniuses" using complex computer languages (mostly c++) for critical open source components make that a massive pain (runtime, ELF relocation requiring obsolete infrastructure, etc).
You joke, but it's a decent comparison. Both GNU and SystemD are projects with a bunch of miscellaneous tools with excessively strong coupling. In GNU's case that's the various userland tools relying on glibc. Both are used in the majority of Linux distros, and while there are distros without them they're not particularly mainstream. Many tools expect their options & custom ways of working, e.g. huge numbers of shell scripts are BASH-specific and need GNU coreutils instead of being portable POSIX shell scripts. Both make developers' lives easier compared to the lowest-common-denominator required by POSIX, which makes sense because POSIX is intended to be a common subset of functionality found across different UNIX OSes.
It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.
Just call it the Red Hat Linux Platform. Both GNU (glibc, binutils, GNU utils, GCC, etc) and Systemd are primarily maintainted by them. Same with Wayland and GNOME.
I had stopped using linux at the start of the systemd takeover (it was not because of systemd).
What I don't understand is how this has happened. I didn't care either way but everybody who did seemed to really fucking hate systemd. Then how come it became the default in so many distributions, with so much opposition from the community?
Because most maintainers love it compared to Sys V scripts.
In the end, users might complain about purity of things or something but the mainteners are the ones doing the work maintaining all that and end up deciding what gets used.
Honestly, I'm rather outside of all that stuff and I had my share of problems with systemd issues but that's mostly because I've been using pretty old systems anyway with thus older and buggier versions of the code. And I also remember the pain it was before unit files to get those sys V scripts working correctly. From my perspective, both systems had weird bugs I had to track but systemd clearly wins on the "creating a new service" part.
Commercial interests. Linux has benefited greatly from companies adopting it and paying developers but at the same time there has been a price to pay and this kind of thing is it.
Since it's all open source, I think we're reasonably ok because we don't HAVE to do what the commercial distros chose to do.
The problem is if we let it become too difficult. Personally I think a thing like DBUS is needed but dbus itself is undesirable as it adds another IPC type and has no connection to the filesystem or the BSD socket interface or any of the other standard ways that interfaces can be discovered and used. It has a network effect that is not easy to avoid without accepting degradation in the UI.
The more crap we end up accepting the more difficult it becomes to be a lone developer and the more the whole system will turn towards commercial interests and away from what it started out as.
This is a mindblower. To quote Bruce Dubbs:
''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.''
I don't mind the inevitable death of System V. It's an archaic relic of the Linux era.
Going systemd-only is not necessarily a good choice (though I do understand it from a practical point of view). There are other, better alternatives for System V that are smaller and more modular so you still get the Unix "feel" without the absurd complexity of interlinked shell scripts that System V relies on.
I'd like to see OpenRC getting adopted in System V's place. Upstart seems to be dead (outside of ChromeOS) but it would also have sufficed. Alas, I'm not someone with the time or knowledge to maintain these tools for LFS, and unless someone else steps up to do all the hard work, we'll probably see LFS go systemd-only.
That said, there's no reason to go full-fat systemd, of course.
It's an archaic relic of the Unix era.
The reason it is being removed is precisely because now we are in the Linux era, no longer in the Unix era.
Have another vote in favour of OpenRC, and even Upstart, if it somehow revives.
I think systemd is the one to learn now if you want to learn Linux. Maybe someone can make a Unix from Scratch for people more interested in the Unix philosophy than Linux per se.
SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.
Yeah, people forget the degree to which sysvinit was hated at the time - "why are you forcing me to deal with an impenetrable forest of symlinks rather than simply hand-edit a couple of basic rc scripts?!?".
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
systemd is most certainly the most pragmatic service to learn, but if you're doing LFS to "learn" how a Linux system gets brought up, something lower-level may be a better idea to pick up.
All this stuff is versioned anyway so if the point is learning youe can still read an old version of the book and use old versions of the repos.
Runit is 5474 SLOCs. Most source files are shorter than 100 lines. Works like a charm. Implements an init system; does not replace DNS, syslog, inetd, or anything else.
Systemd, by construction, is a set of Unix-replacing daemons. An ideal embedded system setup is kernel, systemd, and the containers it runs (even without podman). This makes sense, especially given the Red Hat's line of business, but it has little relation to the Unix design, or to learning how to do things from scratch.
I love how people worship UNIX design in Linux circles, especially when complaining about decisions where Linux is catching up with commercial UNIXes, as in the init systems replacements.
UNIX design was so great that its authors did two other operating systems trying to make UNIX done right.
One of the few times I agree with Rob Pike,
> We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
A project which is intended to be a learning experience in building a Unix variant (in this case, Linux) is a kinda right place for sticking to the Unix philosophy and design, for illustrative purposes.
Mr Pike has indeed constructed a better OS than Unix; too bad AT&T neither knew how to achieve viral popularity, nor why Free Software (as in GPL) is going to dominate the world. By about 1995, it was already too late. (Something similar happened to Inferno vs Java.)
Still, the Unix principles of modularity, composability, doing one thing well, and unified interfaces are widely considered very sane, and adopted.
Not as much as people in Linux community think, especially those that never used commercial UNIX offerings.
GPL is on its way out, a good example is that all Linux competitors in the embedded space, including Linux Foundation's Zephyr, none of them has adopted GPL.
GPL based software is now a minority, almost everything uses licenses that businesses rather reach for.
I suspect that GPL2 was instrumental in guaranteeing that the work sacrificed into the common pot of Linux kernel is not going to be taken by a competitor when it's still unpolished, closed, and used to achieve market domination.
FreeBSD came before Linux (as 386BSD), and is also active used by the industry. How much code did Sony or Raytheon shared back to FreeBSD? (LLVM is not FreeBSD proper.)
See Android for how much that is working in practice, outside the kernel.
Or the Linux distros used by NVidia.
I find Zephyr to be a somewhat poor example. It's typically used on MMUless microcontrollers where the application is linked into the same binary as the OS. I'm sure you'll point out that it's not strictly necessary to use it in that manner, but that's how most people use it and that's how they expect it to work. Licensing it as GPL would mean that basically nobody would use it because it would require releasing your entire firmware source code, especially when there's other permissively licensed alternatives in that space like RTEMS, ThreadX, and FreeRTOS.
Exactly, there are no other FOSS kernels using GPL nowadays, the Linux kernel was the first and last one with commercial success.
I will be honest mentioning Zephyr in a situation when talking about how outdated the Unix design philosophy is, is a bit funny to me since Zephyr (like ecos kinda did once) tries to be Posix-like in its APIs (but ends up not really improving things over the other embedded OSes TBH).
I am talking about Zephyr in the context of GPL, nothing else.
I think the main problem of Unix today is that it's not Unix-style enough. Too many namespaces with too many non-composable separate APIs on them instead of "everything is a file". Plan9 is more Unix than Unix and that's indeed better. Redox OS, too.
The Unix security model is mostly useless today, but it seems like something better is possible as an incremental change, and there are projects that do that, like RSBAC.
And we've all heard of the linux people, as opposed to whoever is pushing these post-Cassidy OS. Linux isn't where it is because of some imperial decree, it has been winning out in a slow, protracted war for what OS programmers choose when they want to get work done.
Pike is more than entitled to an opinion, but I think there is some cause-effect reversal at work here. The linux circles aren't people driving the UNIX-love. The UNIX-love is effective in practice - especially the blend of principle and pragmatism that the linux community settled on - so the linux circles happen to be bigger than the most similar alternatives. Better alternatives are going to have to fight through the same slog as linux if they want recognition.
This is not about mindless worship, but about the fact that the UNIX design has stood the test of time for this long, and is still a solid base compared to most other operating systems. Sure, there are more modern designs that improve on security and capability (seL4/Genode/Sculpt, Fuchsia), but none are as usable or accessible as UNIX.
So when it comes to projects that teach the fundamentals of GNU/Linux, such as LFS, overwhelming the user with a large amount of user space complexity is counterproductive to that goal. I would argue that having GNOME and KDE in BLFS is largely unnecessary and distracting as well, but systemd is core to this issue. There are many other simpler alternatives to all of this software that would be more conducive to learning. Users can continue their journey with any mainstream distro if they want to get familiar with other tooling. LFS is not the right framework for building a distribution, nor should it cover all software in the ecosystem.
The first version of UNIX was released in 1971 and the first version of Windows NT in 1993. So UNIX is only about 60% older than NT. Both OSes have "stood the test of time", though one passed it with a dominant market share, whereas the other didn't. And systemd is heavily inspired by NT.
Time flies fast, faster than recycled arguments. :)
I'm confused as to which OS is the one that passed the other with dominant market share. Last I checked, Linux is everywhere, and Windows just keeps getting worse with every iteration.
I'm not sure I'd be smugly pronouncing anything about the superiority of Windows if I were a Microsoft guy today.
It's not surprising that systemd was heavily inspired by NT. That's exactly what Poettering was paid to create, by his employer Microsoft. (Oh, sorry--RedHat, and then "later" Microsoft.)
Linux is "everywhere" only if you count Android, which is not very Unix-like.
Except that it didn't, Linux has nothing to do with UNIX design, it isn't a UNIX System V in 2026.
> Linux has nothing to do with UNIX design
Respectfully, that's nonsense. Linux is directly inspired by Unix (note: lowercase) and Minix, shares many of their traits (process and user model, system calls, shells, filesystem, small tools that do "one thing well", etc.), and closely follows the POSIX standard. The fact that it's not a direct descendant of commercial Unices is irrelevant.
In fact, what you're saying here contradicts that Rob Pike quote you agree with, since Linux is from the 1990s.
But all of this is irrelevant to the main topic, which is whether systemd should be part of a project that teaches the fundamentals of GNU/Linux. I'll reiterate that it's only a distraction to this goal.
Yet, UNIX or Unix proper descendents, have replaced, or complemented their init systems, with systemd like approaches, before systemd came to be.
So is UNIX design only great when it serves the message?
I'm not familiar with what UNIX or its modern descendants have or have not implemented. But why should Linux mimic them? Linux is a Unix-like, and a standalone implementation of the POSIX standard. The init system is implementation-specific, just like other features. There has been some cross-system influence, in all directions (similar implementations of FUSE, eBPF, containers, etc.), but there's no requirement that Linux must follow what other Unices do.
If you're going to argue that Linux implementing systemd is a good idea because it's following the trend in "proper" UNIX descendants, then the same argument can be made for it following the trend of BSD-style init systems. It ultimately boils down to which direction you think is better. I'm of the opinion that simple init systems, of which there are plenty to choose from, are a better fit for the Linux ecosystem than a suite of tightly coupled components that take over the entire system. If we disagree on that, then we'll never be on the same page.
Compared to plan9, past its sell-by date. Compared to redhat poetteringware, I will continue to attend services.
> We really are using a 1970s era
1970 Anno Domini no less
Making it even more so of a religion.
UNIX is only an OS with some good ideas, and also plenty of bad ones.
No reason to stick with it ad eternum as some kind of holy scriptures.
The article is not about UNIX, what's good and bad, but what's better for understanding Linux. And replacing SysVInit with systemd is, objectively, bad for understand the core of Linux. And this is the core of LFS.
Discussing whether UNIX is good or bad seems narrow-minded, as there is no solution to that. It's like discussing whether iOS is better than Android. We can always isolate some specific parts and discuss that, but just slashing the whole concept doesn't help anyone and rarely yields any meaningful results.
> And replacing SysVInit with systemd is, objectively, bad for understand the core of Linux.
I know there are strong opinions on this, but isn’t systemd part of the core of most Linux desktops nowadays?
All of my Debian out of the box has systemd. On Gentoo it's OpenRC, which I find easier. But! There are some work-around packages that implement some stubs of systemd things because other packages are designed for systemd only world (one such stub is elogind)
Unfortunately yes
It's "problem" unfortunately is that it happens to be the only major foss os. If there were other foss oses with good support and "better" models I'd gladly try them out. I know I personally would never switch to any non foss os after the user friendliness I have experienced. I would say that's the main reason many stick to it, including game theoretic arguments for commercial players also. Not because people like to stick to ancient models. It's not a ideal system obviously but going back to locked down crap is a no go for me and perhaps many others. BSDs are ok too but the suicidal licensing makes me less inclined.
What’s suicidal about the BSD license? BSD code is everywhere
Yes and much of it is sealed off and proprietary. The bsd oses got MacOS for all their hard work, a closed off system that they can't read or port back anything from. Someone would say linux or gpl projects also have been fucked over this way. I suppose if your house has been burgled, such a person would argue we must remove all protections rather than add more.
MIT et al are winning over GPL for a reason.
I'm not a big corporation. I prefer MIT, or better yet, public domain.
Are they winning as in more people are picking the license or are they winning as in we are getting a overall more enriched foss community?
I don't understand why people have such difficulties with the Golden Rule, sounds a simple and fair enough concept.
We are winning as in "we have more freedom to do as we like without a bunch of lawyers breathing down our necks."
Freedom and liberty are what I value. There is no harm occurring to software as a result of more freedom or more liberty. Quite to the contrary.
Is your Golden Rule "you will use 'my' software exactly how I dictate, or else I'll call my dogs to attack you"? That's not the one I was taught.
I release all my code in the public domain.
Why are you acting so strange and making up misinterpretations of what I wrote? You depend on lawyers either way, whichever license you use, I fail to see how copyright law can be implemented and defended without lawyers. The golden rule is simple, anyone can look it up, I really don't understand what difficulty you have that made you make up such a strange "not even wrong" theory about it. "do to others what you would have them do to you" , here it means you have benefited from countless man hours of work by other people, so you too should pass on any improvements you made to it just like they did to you.
Regarding freedoms, let us take this scenario. Your small company depend on a complex bsd library thats hard to replicate. It gets the attention of a much larger company, they fork it make various changes to make it much better and keep it closed, their product kills yours. While, if it was GPL (or AGPL as its needed today), the company either has to redevelop it inhouse if they wish to serve it as product to the public without releasing its sources, or they do the same thing as in the bsd case, they make a much improved version...and you have equal access to the same sources, you can take that and pivot upon it instead of your company dying. Its very simple, more or less mathematical game theory. Nobody can force anyone to choose a license, its your choice. Again, Mac OS is not a very encouraging example of the overall outcome of BSD licensing. No freebsd/openbsd/whatever person is permitted to read or use Apple's "fork" now. Apple took the hard work of others and instead of paying it back in like, it doesn't take a single cent of money, "paying" back here simply means doing the same the others did, they generously provided you their work as foss, you pass back your delta to it as foss. Thus raising the high water mark of the entire ecosystem. Think academic research. Its usually released in open, so any improvements made by one team are available for others to use and further improve upon. That's it. Nothing more. Nothing less. How does GPL "force" anyone to do anything? They can either choose to follow the license, or choose another library or home grown an alternative if they dislike the terms.
> You depend on lawyers either way, whichever license you use
No, in fact I don't. Indeed, I go far out of my way to avoid these parasites entirely, and anyone who depends on them. I don't give a damn what anyone does with my software. I don't need the attorneys to do anything.
For accusing me of "misinterpreting" what you wrote, you seem to be quite confused yourself. What part of "public domain" don't you understand? The means I don't give a shit what you do with the code. You can decide for yourself. You know, the mature, unselfish approach. Busybodies and control freaks hate this one simple trick.
> Regarding freedoms, let us take this scenario.
Here we go, lol. We're headed down the rabbit hole straight to the juicy caramel center of your flawed thinking.
> Your small company depend on a complex bsd library thats hard to replicate. It gets the attention of a much larger company, they fork it make various changes to make it much better and keep it closed, their product kills yours.
Sounds like you had a very poor business model. Probably because you have no idea what you're doing. Your monetization strategy failed. Pick yourself back up and try again.
The solution is not Big Brother and his machine guns to force others to comply with your dictates. (i.e. the lawyers and legal system, if I have to spell it out for you.)
> While, if it was GPL (or AGPL as its needed today)
AGPL is strongly avoided by almost everyone, for good reason. It's even more of a cancer than the GPL.
> the company either has to redevelop it inhouse if they wish to serve it as product to the public without releasing its sources, or they do the same thing as in the bsd case, they make a much improved version...and you have equal access to the same sources, you can take that and pivot upon it instead of your company dying.
...or they just decide to develop their own version from scratch instead, keep it closed source from day one, and you get nothing at all. Happens all the time.
If you were truly a shit-hot developer you would not be concerned about anyone ripping you off. You'd know you're so creative and putting out so much quality effort on a consistent basis that you'd never worry about being surpassed by anyone.
Big company thought of a good idea to add to your big pile of good ideas? No problem. Copy that and come out with another good idea or two for him to steal. If they're always imitating you, then that means you're the industry leader, doesn't it?
If you're not the industry leader however, because you really only had one good idea and Big Company has more, then what right do you have to try and Stop Progress just for your own selfish ends? That's what this all boils down to: selfishness, due to insecurity.
Your mentality is completely foreign to a true winner, but oh-so-common among the insecure midwits. They're always deathly afraid that their One Thing will get ripped off and they will be left with nothing.
It's a scarcity mentality. That's the problem. It's all in your head.
You're a squirrel with one little nut that you cling to desperately, in hopes that nobody else will grab it. You make all your life about protecting that nut at all costs. You're so glad that Big Brother offers you his machine guns to help you protect it. You don't care about the harm that comes from bringing thugs with guns into the picture to push people around. You're just desperate to protect Your Thing, so you will accept anything that you believe will help this end. It's the same broken mentality that manifests itself everywhere else besides software also. Nothing new under the sun.
Do not pretend that I don't understand you far better than you know yourself, or that I am misinterpreting you in some way. I've seen ten thousand of your type if I've seen one. You're everywhere, especially on HN. I'm well aware of what your mentality is. The root of the problem is your insecurity.
> Its very simple, more or less mathematical game theory.
You don't have a clue about how economics actually works--which is typical for those of your loudly expressed opinions. But you think of yourself as some enlightened game theorist. Not quite.
The bottom line is, you can't FORCE people to behave how you want through your favorite legal fiction or any other, and you damn sure should never try, as it's a fool's errand that only leads to tears. One of the basic laws of the universe.
The people who created GPL knew this from day 1. That's exactly why they created it to be the way it is. Irt was an act of sabotage. This knowledge is currently far above your level however, and is likely to remain so for a long time to come; probably forever.
The world is not falling and BSD is winning the license war for good reason. End of discussion. It's all over but your crying.
>If you're not the industry leader however, because you really only had one good idea and Big Company has more, then what right do you have to try and Stop Progress just for your own selfish ends? That's what this all boils down to: selfishness, due to insecurity.
How the fuck is a GPL library stopping progress? Why does Big Company feel tied up due to a library being GPL? You said it yourself, they could redo it inhouse? If they were such hot shit they'd do it and continue the march of progress anyways.
Its very simple, its so simple I am not even sure I am talking to a functional level of iq: do you think more progress is made from less eyes on an idea? If the changes made by Big Co were available to the public, that's a much larger pool of engineers to take it in all sorts of directions. You are so fucking dumb its beyond words.
>...or they just decide to develop their own version from scratch instead, keep it closed source from day one, and you get nothing at all. Happens all the time.
You again seem very confused. Its exactly the same as they closing up a bsd fork. So how is the outcome or incentive any different? With bsd they can do that without any effort, with gpl at least they have the friction and may deem it too much of a friction. Google's fuchsia attempt failed despite its behemoth size, Android is still linux.
How exactly is it a sabotage? You are again making up utter absolute fucking crap out of thin air and acting retarded making up an entire fantasy universe in your head.
Since you are such a smartass wanker, tell me this, how is the other company being forced to release their changes making the market less competitive? On contrary, this makes it more competitive, since everyone is forced to compete to this level now, they themselves will have to keep developing something better, and again paying the inhouse cost if they wanna be jealous.
AGPL is strongly avoided by...yes companies who live off of turning existing libraries into websites...who'd have thought, hardly a surprise why and who avoids it.
Big company can add a good idea, but big company has big resources. I am telling you that you can now pivot on their changes and putting them under the pressure cooker again: more competition. Competition is nice.
How the fuck is a simple license that nobody is forced to use a "sabotage", are you really even thinking? How much fucked in the head can someone be to think a completely legal and simple license is a "sabotage"? A "sabotage" against what or whom? If its a sabotage, then protest whatever legal framework allowed it. Do you disagree with copyright, is that what you are saying?
If you disagree with copyright, then I hope you have no problem with taking the source code of competitors by any means. After all, if licenses are bad, and government enforcement of copyright is bad, why should copying and releasing a company's internal sources be bad?
If this is a "scarcity" mentality, then the entire history of Mathematics for the past few centuries is a scarcity mentality. If you are man enough to follow through, then say it out right in the reply that you believe Mathematics is a scarcity mentality.
I mean if I wanted to win at all costs, why shouldn't I steal your code and release it and make life harder for you. Or if I wanted to be a real winner, why don't I go and shoot you.
Tell me again moron, how the fuck does a license "force" you, who the fuck is "forcing" you to use gpl if you dislike gpl? I don't even know how deep a level of mental illness one can have to imagine someone with guns is coming out to kill you and rape you and force you to use GPL programs and libraries. Are you even thinking man? This is literal violent paranoid psychosis level of insanity. You are fucked in the head beyond repair.
You seem to be unaware of the basic fact that government--laws and legal systems--is men with guns.
"Government is not reason, it is not eloquence, it is force! Like fire, it is a dangerous servant and a fearful master." - George Washington
It's difficult to have a conversation with someone so profoundly ignorant of reality. Do some research and stop wasting our time with your angry rantings.
I had a feeling you'd be too fucking stupid to be able to respond to any of the points and duly vanish just as I expected from your sackless kind.
You also still failed to have the balls to say out loud you think Mathematics is a scarcity mentality. Be a man.
You are the one who chimped out with a long rant to a perfectly calm explanation man. You are still acting mentally ill. Yeah duh, govt is men with guns. And where in all this are you seeing this supposed "sabotage" of you being forced to use GPL? If you don't like GPL, don't use GPL software. Very simple. Nobody pressured you to. Since government enforcement of copyright is not something you like, I think it's a perfectly fine sentiment to have. I hope you don't mind people releasing all the materials of competitors to the public then. Tell me again , I am not sure its any point trying to reach the skull of someone this mentally ill but I'll still try. If I release something as GPL, whos coming in to your house with guns blazing forcing you to use my library? You choose to not use it, its simple. The government will use violent force to enforce any law, but in this case its easy since you already dislike GPL, just don't use it, government will have no interest in killing you. What a fucking brain dead moron, man.
That's true, but some of the arguably worst ideas are the ones which makes it the most approachable, hackable and understandable.
Hindsight is an interesting thing. Makes mistakes more visible while making Chesterton's Fences invisible.
We shouldn't forget these. These fences are there for the reasons. Yes, fences can be revised, but shall not be ignored.
My point was, that there’s plenty of ancient things we plod along with, even though they’re not perfect. Many have tried to improve upon them but few have stuck.
You are so vague in your attack on Unix approach that it's borderline trolling. What are your problems with it? Modularity and minimalism have been working perfectly and that systemd does not follow them is a bad thing.
There is a book on that, gets posted every now and then on HN.
In case you never read it, https://web.mit.edu/~simsong/www/ugh.pdf
Hardly the piece of OS beauty that gets praised about FOSS circles.
I love that book but isn’t it nearly 30 years old?
And yet many of the pain points are still kind of relevant, go figure.
I'm not talking about the OS though but about the approach.
Goes to both, otherwise UNIX authors would not have tried to improve their creations, working on successors to both UNIX and C.
But that book is a waste. It is just MIT dunning-krugerites who were salty that LISP machines never took off. When it comes to real life, the bell labs approach won, and for several good reasons. Not "worse is better" (another dunning-krugerite cope), but "less is more."
Turns out free beer is great, even when it is warm.
The only good beer is warm beer. If the beer tastes like shit when it's warm, it's not good beer.
From your perspective, what would be an "OS done right"? I have a running list of things I would change in Unix, but replacing sysvinit with systemd's one-ring-to-rule-them-all would not be on it.
But your comment is a waste. It is just HN dunning-krugerites who were salty that the UNIX way never took off. When it comes to real life, the Poettering approach won, and for several good reasons.
> for several good reasons
Such as money from M$?
The UNIX way is still doing fine on OpenBSD, NetBSD, FreeBSD, Alpine, Gentoo... Poetteringware only won on the distros selling support contracts. "Fixing" what wasn't broken is great for those businesses.
> Implements an init system; does not replace DNS, syslog, inetd, or anything else.
You're confusing systemd the init manager and systemd the project. systemd as an init system only "replaces" initd, syslog and udev.
All other components under the systemd project are optional and not required, nor is there any push to make them required.
>"All other components under the systemd project are optional and not required"
Name two major distros that use 'systemd init system' but doesn't use the other parts.
I use runit on my production workstation and don't think about it; it just works.
Same with systemd.
Except for all those who've accidentally blown their legs off with it, of course.
Just ask the guy who bricked his motherboard due to a systemd bug where his firmware wasn't write protected and got destroyed by a 'rm -rf' command. lol
No software is perfect. Not sysvinit (and it's bash scripts from different vendors), nor systemd. Errors happen. At least for me systemd is a net positive.
> No software is perfect
Especially when it's a giant blob of buggy C code written by a known hack who has multiple decades' worth of history of foisting shit code upon a less than enthused public.
> At least for me systemd is a net positive
For the moment. Just wait until it finds a way to fuck you. It's plotting and scheming behind your back to do so as we speak.
Systemd for some reason seems to uniquely be the epicenter of giant facepalm bugs like LEAVING THE SYSTEM FIRMWARE VULNERABLE TO AN RM -RF COMMAND, a situation which causes alarm to none of the systemd crowd. They just shrug if off. "What's the big deal? I don't get it," they say.
I used to see the same mentality from Microsoft people back in the day. "Why would you use Linux? I don't get it. Windows is fine."
It's because you lack standards. You're completely used to being surrounded by software and hardware that is Fucking Garbage. Everything is like that in your world. You're happier than a pig in shit, oblivious.
> Implements an init system; does not replace DNS, syslog, inetd, or anything else
Neither does systemd its init.
Unknowledgeable people keep confusing systemd the init and systemd the daemon / utility suite. You can use just the init system without pulling in resolved or networkd or whatever.
Systemd is the Unix philosophy of lots of modularity. But because all the systemd daemons come from the same shop, you get a lot of creature comforts if you use them together. Nothing bad about that.
> but it has little relation to the Unix design
It's more like Windows! /duck
Hackers design hacker-friendly systems, which are easy to learn and extend. Corporation$ design ops-friendly systems, which are cheap to operate.
We need both.
> We need both
Both can devolve into empire building. We need both to be transparent and open.
What we need is actual, proper, mass-education about how computers work, with the goal of increasing their freedom of interaction. Not towards creating more working class peasants using a tool for work, but creating chaotically creative tinkerers using a tool to create whatever they want, more tools included.
Kids and their Parents learned it in the 80s and they had nothing but a manual. Either these people were massively more intelligent, or the same approach, using modern methods, would work again and again and again.
Considering the 1% rule of the internet (it's about the ratios, not the numbers!), shifting more people from the 90% to, at least, the 9%, seems to be one of the better courses of actions to take.
What we, MY FELLOW HUMANS [1], absolutely do not need is more people being optimized towards using a computer solely as a tool for someone else ... especially because AI can replace 99%+ of them anyway.
[1] https://old.reddit.com/r/totallynotrobots/
Yes, this times a thousand. If we treat people like slaves, they become slaves. Treat them as if they are smart, and they will become smart. It's as simple as that.
I have been saying for years that Microsoft would eventually deprecate WinNT and switch Windows over to a Linux foundation. Things seem to be slowly but continually moving in that direction.
Makes no sense to dump a superior kernel and executive for Linux.
The Win32 layer is the issue, not the underbelly.
I’ve had more hard crashes and BSODs on Windows than any other OS. And I use Linux & Mac more than Windows. Not sure how it’s superior.
The windows NT kernel is in many ways a better design. However they allow third party device drivers, and run on all kinds of really terrible hardware. Both of them will cause the system to be unstable through no fault of the system.
Don't get me wrong, NT also has its share of questionable design decisions. However overall the technical design of the kernel is great.
More advanced APIs which allow more fine-grained interaction between system and application IF you can figure out how to use them
My favorite example of this is how Windows NT has had async IO forever, while also being notorious for having slower storage performance than Linux. And when Linux finally got an async API worth using, Microsoft immediately set about cloning it for Windows.
Theoretical or aesthetic advantages are no guarantee that the software in question will actually be superior in practice.
ASync I/O isn't limited to just storage, though. It's /all/ I/O.
And yes, the layered storage stack does have a performance penalty to it. But it's also infinitely more flexible, if that is what you need. Linux still lacks IOCP (which io_uring is not a replacement for).
Windows' VMM and OOM is also generally much better.
> this is how Windows NT has had async IO
Pretty much what I was thinking of. My understanding from reading some commentary in this area is the Linux implementation is yet a little botched due to how it handles waiting threads.
They might use the NT kernel and their own version of the Linux userland.
I'd be open to the idea, if the kernel were open sourced (MIT licensed?) so I could play with it too.
Why do that when Win32 is what everyone wants?
We’ve already had NT + Linux userland; that was WSLv1.
I think if we're talking about "what everyone wants", Windows 11 obviously isn't it, so that's not necessarily the driving force here.
As I said, everyone wants Win32. What flavor is up to debate, everyone has their own incorrect opinions.
It would be much unlike Microsoft if they didn't bring Win32/Win64 compatibility along for the ride somehow, and very stupid also, because as you say that is the real core of Windows in a lot of ways.
I have no idea what they're planning or why, just guessing, as they seem to be bringing Linux and Windows closer together all the time.
> It would be much unlike Microsoft if they didn't bring Win32/Win64 compatibility along for the ride somehow, and very stupid also, because as you say that is the real core of Windows in a lot of ways.
This requires NT API compatibility due to applications using NT API. Despite Microsoft telling devs don't use the NT API, devs use the NT API and Microsoft makes adjustments to ensure compatibility.
> I have no idea what they're planning or why
Clearly, because the whole idea not only makes no engineering sense, it makes no financial sense. They need to build the NT kernel anyway -- it runs the entirety of Azure services!
> Makes no sense to dump a superior kernel and executive for Linux.
At this point in time, having programmed deep in the internals of both Linux and Windows, I think it is probably incorrect to call either kernel an inferior or superior one.
I mean, it was true for both of them at some point (Overlapped IO was great on Windows and missing on Linux, for example) but today, in 2026, the only differentiating factor is the userland experience.
For me, Windows loses this hands down.
> switch Windows over to a Linux foundation.
Though it seems to be sneaking in through application space on a WinNT foundation
One might almost say a Hird of Unix-Replacing Daemons.
With limited resources, sometimes practicality needs to win. Kudos to Bruce for putting aside his (valid) feelings on the subject and doing what is best for the team and community overall.
I disagree.
I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software. It is built starting from LFS in 2019, and now consists of over 1,500 packages, cross compiling to x86-32/64, powerpc32/64, and others if I had hardware to test. It's built entirely from shell scripts which are clean, organized, and easy to read.
I need help to get the system ready for release in 60-90 days. In particular, I need a fast build system, as my current 12+ year old workstation is too slow. Alpha/beta testers are welcome too. Anyone who wants to help in some way or hear more details, please get in touch:
domain: killthe.net
user: dave
> I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software.
What makes you decide that these are troublesome software's? Systemd is usually argued that it is monolithic and breaks the Unix paradigm.
But then you are going for X over Wayland? X is a monolithic application that breaks the Unix paradigms.
Are you just picking things because they are old, or is there a reason you decided to go with this setup?
The difference is that the people who designed X11 were honest in their intentions. The authors of systemd, wayland, etc are not. I'll just leave it at that.
(I recommend staying far away from "X11libre" also, for the same reason, with no further comment.)
Monolithic stuff is OK too, where it makes sense. The kernel is monolithic. ZFS is monolithic.
(Yes, this system has ZFS support. The module is built in to the kernel. In time it will support booting from ZFS also, when I finish the initrd code.)
There is a clear, solid reason for everything this system is or does. I'm not a contrarian or a purist, just someone with opinions gained from long experience who is not happy with the direction mainstream Linux is headed. My system is a zen garden of bliss compared to buggy garbage like Ubuntu.
Really, it's like someone added a turbo button. Ubuntu and friends are so bloated, laggy, and slow. I regularly use this system on 15-20+ year old hardware. The default window manager is Enlightenment e16. It's snappy and responsive everywhere.
KDE, Xfce, etc are supported also and are noticeably peppier than on mainstream distros, just due to the lack of bloat, gazillions of daemons running in the background, etc. Out of the box, nothing runs by default. You enable only what you want.
Another inviolable principle is that no application is allowed to originate or receive network traffic unless the user specifically requests it. There is ZERO network activity going on in the background. None of this steady stream of who knows what contacting who knows where that goes on with other systems. No auto update etc. No internet required or used during the system build. Python module installs do not consult the central repository or download anything. Meson or cmake does not download anything. Etc. All that's patched out and disabled.
It's a distro that is meant to be forked. It's very easily done. It's a blank slate, a vanilla Linux system with subtle and tasteful improvements that is the ideal starting point to customize to your exact specifications. If you want to add in systemd and wayland, fine, I don't care, it's your system and you can build it according to your desires. People can use this platform to build their own custom OS and save themselves a ton of work vs. starting completely from scratch.
It's a system that can be audited. Everything is built with shell scripts, starting with source archives and patches that are applied during the build process. It's all inspectable and the process can be understood step by step.
It's a way to hit the ground running with a full featured, working system, while learning in the process. This distro will teach you what LFS would teach you, but with less of a "sheer cliff face" learning curve, letting you focus more on higher aspects of building the system while still learning the low level details in time.
The build is actually overall simpler than LFS despite being way more featured, with things like Ada support. (Yes, it has GNAT.) I just found a way to do it better, and kept iterating countless times to simplify and improve to the max.
Existing systems did not satisfy my requirements or standards of quality, so I just had to create a new one.
> The difference is that the people who designed X11 were honest in their intentions. The authors of systemd, wayland, etc are not. I'll just leave it at that.
Leave it at what? How is Wayland not honest about it's intentions? It is completely transparent about the motivation behind the project. Whether you agree with the motivations is different, and thats fine to disagree with a project.
However there hasn't been a scenario where Wayland haven't been honest.
Yes, I am ignoring your side comments about systemd because I was asking about Wayland, and mixing the two together implies that you are just complaining about the new, rather than technical/architectural reasons.
(Plus I have to ask as "killthe.net" doesn't come up with anything)
Send me an email and I'll be happy to explain further, to whoever asks. I don't want to clutter up this thread with a bunch of arguing that will surely result, as the focus here is just on "going our separate ways" rather than throwing barbs at anyone, or causing more hard feelings.
People who like software that I don't personally like may continue to use it of course, with this system also even, it's just that it won't be in the official repository is all. But as the whole thing is designed and encouraged to be forked, that shouldn't be too much of a burden if someone likes other aspects of the system and wants to maintain their own 'systemd/wayland' version.
How did you get GTK3/4 to work without dbus?
I got rid of dbus in GTK3 by patching the code so that the "accessibility bridge" (to ATK) can be disabled. GTK4 is beneath contempt and will not be supported.
The system uses GTK2 wherever possible, or GTK3 when not. I will either port everything to GTK2 later or create some kind of shim library. Help wanted here. Porting back to GTK2 isn't hard, I just don't have time to work on any of that at the moment.
I'm running Gentoo without dbus and I'm stuck at gtk 3.24.34. I would love to see those patches. Your site appears to be down.
It's just HTTP only (no SSL) and there's nothing there. ... until now!
Here's some nice GTK3 patches for you:
http://killthe.net/patches/gtk-3.24.43-allow-disabling-atk-b...
http://killthe.net/patches/gtk-3.24.43-allow-transparent-win...
http://killthe.net/patches/gtk-3.24.43-allow-wheel-scrolling...
http://killthe.net/patches/gtk-3.24.43-appearance-tweaks-and...
http://killthe.net/patches/gtk-3.24.43-disable-mnemonics-del...
http://killthe.net/patches/gtk-3.24.43-file-chooser-tweaks.p...
http://killthe.net/patches/gtk-3.24.43-remove-dead-key-under...
http://killthe.net/patches/gtk-3.24.43-restore-old-context-m...
http://killthe.net/patches/gtk-3.24.43-set-default-settings....
http://killthe.net/patches/gtk-3.24.43-show-alternating-row-...
Note that GTK 3.24.43 is the last version of GTK3.
My system is full of patches like this to tweak, improve, and adjust things. The point is to get off the "upgrade" treadmill and focus on making things work right.
Thanks for your work! Getting off the "upgrade" treadmill really resonates with me.
Just to be clear, I did not write these patches, but have collected many like this via scouring the net. I think I did make the ATK one though.
If you'd like to be an alpha/beta/release tester of this system, hit me up via email please. I'll start with an initial closed alpha release here in a month or so, if there's interest.
Now for the donation drive: I have plenty of time and a stable situation to work on this system, but the one drawback is I have little funds--and unfortunately my workstation is getting pretty long in the tooth. (AMD FX. It's been a good system, but I'm getting Left Behind here.) The main thing holding me back is compile speed, especially doing work on Chromium and WebKit. It's 12+ hour compile times for either of those, with the latest C++ standards they're using. The system as a whole builds in about 48 hours on my computer.
So I'm hoping to bump into an "angel investor" who either has some old Xeon (Broadwell or newer?) hardware laying around they would donate, something with lots of cores and memory, or who can make a cash donation for me to buy the gear I'm looking at on Ebay. $400-500 is enough for a nice 5x upgrade. It amazes me how cheap this stuff is. We're talking $5000+ hardware when it was new, for peanuts. Still quite powerful.
(A better video card would be great too, if you're feeling generous. Mine is a GTX570. I'd love to have a GTX7xx or newer, or equivalent AMD. That's more of a want than a need however.)
I'm very interested in ppc64 gear too. I want this system to have first-class PPC support. Anyone got an old POWER8 or POWER9 system laying around, or 32-bit stuff? I've got this system building OK in Qemu for ppc64le but it is SLOW, as you can imagine. Like 5 seconds per line in configure scripts, lol.
If anyone out there is in a position where they can help this project in some way, email me please! Thank you.
By the way--I did not want to disable ATK to get rid of dbus, but only did so temporarily. Ultimately a better solution is to create a UNIX socket just for the ATK<>GTK bridge.
Accessibility should be something that the system fully supports. There is speech synthesis and other useful bits installed so far. Maybe someone would like to work on this project. Email me if interested.
I'm sorry to tell you, but I'm not really interested in a new distribution. I appreciate the effort of what you are trying to do, but I think you are wasting time maintaining a distribution instead of maintaining patches (or a fork). If you have the know-how to patch those cancers out, then do only that and let other people do the packaging. Just make them known and available - a github repo maybe?
So, I'm not going to test your distro or switch from my Gentoo. I like Gentoo a lot, most of all because it's so very-very easy to patch any official package. Just put the patch in /etc/portage/patches/<package> and that's it. It gets automatically applied on the next install.
I'm using a Phenom II x6 1100 on a Gigabyte 880G. Firefox compiles in about 3-4 hours I think, not really sure. I do all Gentoo updates over night and it's usually ready in the morning. I can't say about Chromium or webkit - never used them - but 12h seems waaay too long.
Sorry dude, it's about 7 years too late to tell me to stop.
If you like Gentoo, more power to you! It's not for me.
This isn't just another run of the mill distro. It's like nothing else that's out there.
I forgot to mention that I have PaleMoon on the system also, and it compiles in a much more reasonable time. Like two hours or so, I think.
Chromium and WebKit are ginormous, and worse, they are compiled with the latest C++ standards which are slow as hell to compile. Nothing wrong with my system, it just takes forever to compile this giant bloated crap. I need more CPU cores, to blast my way through the pile of work that needs to be done.
Look of the size of the Chromium source code archives these days. It's fucking outrageous. 15 compressed gb (and growing rapidly!) of third party code vendored inside third party code vendored inside third party code, three or possibly even four levels deep! ("Yo Dawg...") Let's just have 5 complete copies of the LLVM suite in random places in there, because why not? Google has lost its marbles.
Yeah, I'm working to fix Chromium's little red wagon too. I'm on version 3 of my custom Chromium build. The binary of version 2 was slimmed down to 186 mb in size (compare to Google's version), with a 300 mb source tree (same) when I quit on it to start version 3. There was plenty more to take out. This latest version is going to be the best yet.
Personally I've been boycotting all chromium forks for about a decade now. Could consider dropping chromium altogether :P
I guess there are alternative "forks" like QtWebEngine that just try to bring in only the blink engine part.
Who's the guy with Firefox 147 32-bit x86 who downloaded a patch? Nice to see there's still at least a few 32-bit users left out there. My system cross compiles to i686, and builds as multilib (both 32-bit and 64-bit libraries) for x86-64 as well, FYI.
Some of these User Agents have to be fake. Android 6.0.1 with Chrome 144, really? lol
Some wise guy has a "Linux/SystemD" user agent. lol
This fella would like to have a word with you:
https://www.youtube.com/watch?v=XfELJU1mRMg
https://m.youtube.com/watch?v=atcqMWqB3hw
So, devuan?
No, not even close. Totally different projects. This one is for experts only, or those who want to become experts. The type of person who has been toying with the idea of building a LFS system but doesn't really want to go through all the work and headache (and it's a ton, to build a full system.) It also supports cross compiling to other architectures, which LFS does not.
This system has many powerful features like built in ccache/distcc support for the build, support for building in QEMU, etc. Eventually it will be fully sandboxed.
There is a heavy emphasis on Doing Things Right according to an old school way of thinking. Everything is kept as simple as possible, yet as full featured as is practical. A major goal is to have everything documented and explained, starting with the shell scripts which build the system step by step in an easy to follow manner.
No package manager currently, though a simple one is in the works which is integrated into the build scripts. It's not really needed. You just build a complete system with all packages you want installed in a single run, with your own configuration pre-loaded. This gets compressed to a tarball. Then to install, create a partition, extract the tarball, edit a few files, install the bootloader, set passwords, and go.
How is this best? It defeats the whole point. I’m going to stop recommending LFS to people wanting to learn about this stuff.
Learn about what stuff? Linux? System V UNIX?
I haven't done LFS since my tweens (and I'm almost 30 now), but I remember the sysvinit portion amounted to, past building and installing the init binary, downloading and extracting a bunch of shell scripts into the target directory and following some instructions for creating the right symlinks.
Obviously, you can go and check out the init scripts (or any other individual part of LFS) as closely as you wish, and it is easier to "see" than systemd. But I strongly protest that sysvinit is either "Linux" (in that it constitutes a critical part of "understanding Linux" nor that it's really that understandable.
But setting aside all of that, and even setting aside the practical reasons given (maintenance burden), when the majority of "Linux" in the wild is based on systemd, if one wanted to do "Linux From Scratch" and get an idea of how an OS like Debian or Fedora works, you would want to build and install systemd from source.
For me, Linux From Scratch is not about compiling linux from scratch, but on building up an entire Linux distro from the ground up, understanding how every piece fits together.
Doing it via systemd is like drawing a big black box, writing LINUX on the side, and calling it a day.
You are necessarily working with very big blocks when you're doing this, anyway. You don't do a deep dive on a whole bunch of other topics in LFS, because otherwise the scope would become too big.
That's what I was trying to get at -- yes, you can say that sysvinit is easier to understand than systemd, and less of a black box. But, even still, a "real Linux distribution" is full of these black boxes, especially the closer you get to being able to run "real applications". I'd argue that once you get into full desktop seat management, you add so much complexity on top of sysvinit that the difference narrows...
Which is why I asked "learn about what stuff". I think if the goal is to learn about "Unix" or OS design/ideas, you're better off with a leaner, "pedagogical" OS, like xv6. If the goal is to piece together an OS and really understand each piece, I don't think you really want sysvinit. You want something closer to an /etc/rc.local that just kicks off a few daemons and hopes for the best.
You can argue that sysvinit makes a better "compromise" between usability and clarity, and I'd entertain that idea, but then I think dinit is far easier to understand than sysvinit. And of course, at that point you can shave yaks till you fill the bike shed with wool.
Realistically, as much as people may hate it, if you have to pick a single init to standardize on for clarity and "building an entire Linux distro from the ground up, understanding how every piece fits together", systemd is the most rational choice. It's the most representative of the ecosystem, and requires the least "extra layers" to make the "desktop layer" work.
"best" meaning the best decision the LFS team can make given their limited, unpaid time and resources. They feel maintaining guides for two parallel init systems is unsustainable even though they would prefer not to have systemd as the only option.
The actual best decision would be to stick with his principles and make LFS be sysvinit-only instead, with zero fucks given about Gnome/KDE if they refuse to play ball.
I for one will not be strong armed into systemd or any other tech. If KDE makes it impossible for me to run without systemd, it goes into the trash bin. I will just install Trinity (KDE3) and be done with it. (Gnome deserves no consideration whatsoever.)
https://github.com/systemd/systemd/tree/main/src/core doesn't look like 1678 C files to me.
Github says 2.8k files when selecting c (including headers...) https://github.com/search?q=repo%3Asystemd%2Fsystemd++langua...
If the project is even split in different parts that you need to understand... already makes the point.
Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.
To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.
> Well to be fair, you don't need to understand how SystemD is built to know how to use it.
The attitude that you don't need to learn what is inside the magic black box is exactly the kind of thing LFS is pushing against. UNIX traditionally was a "worse is better" system, where its seen as better design to have a simple system that you can understand the internals of even if that simplicity leads to bugs. Simple systems that fit the needs of the users can evolve into complex systems that fit the needs of users. But you (arguably) can't start with a complex system that people don't use and get users.
If anyone hasn't read the full Worse Is Better article before, its your lucky day:
https://www.dreamsongs.com/RiseOfWorseIsBetter.html
LFS is full of packages that fit your description of a black box. It shows you how to compile and configure packages, but I don't remember them diving into the code internals of a single one.
I understand not wanting to shift from something that is wholly explainable to something that isn't, but it's not the end of the world.
No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.
You still build it from scratch (meaning you compile from source).. they don't dive into Linux code internals either.
They still explain what an init system is for and how to use it.
The problem is ultimately that by choosing one, the other gets left out. So whatever is left out just has one more nail in its coffin. With LFS being the "more or less official how-to guide of building a Linux system", therefore sysvinit is now essentially "officially" deprecated by Linux. This is what is upsetting people here.
I'm OK with that in the end because my system is a better LFS anyhow. The only part that bothers me is that the change was made with reservations, rather than him saying no and putting his foot down, insisting that sysvinit stay in regardless of Gnome/KDE. But I do understand the desire to get away from having to maintain two separate versions of the book.
Ultimately I just have to part ways with LFS for good, sadly. I'm thankful for these people teaching me how to build a Linux system. It would have been 100x harder trying to do it without them.
Linux is just a kernel, that does not ship with any sort of init system.. so I don't see how anything is being deprecated by Linux.
The LFS project is free to make any decisions that they want about what packages they're going to include in their docs. If anyone is truly that upset about this then they should volunteer their time to the project instead of commenting here about what they think the project should do IMO.
The whole point of LFS is to understand how the thing works.
In what way was Bruce incorrect, your one link excepted?
he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison. systemd-init is a small slice of the code in the systemd repository.
I'm guessing he shares my belief that systemd-init cannot exist in the wild on its own, correct? When you want a teacup, you have to get the whole 12 place dinner set.
IIRC the mandatory components are the init system, udev, dbus, and journald. Journald is probably the most otherwise-optional feeling one (udev and dbus are both pretty critical for anything linux regardless), though you can put it into a passthrough mode so you don't have to deal with its log format if you don't want. Everything else is optional.
> ... dbus [is] pretty critical for anything linux regardless
Weird. If I weren't a sicko and had OBS Studio installed on my multipurpose box [0] I'd not have dbus installed on it.
dbus is generally optional; not that many packages require it. [1]
[0] Two of its several purposes are video transcoding and file serving.
[1] This is another area where Gentoo Linux is (sadly) one of the absolute best Linux distros out there.
> he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison.
See, this is why when I refer to the Systemd Project, I spell it as "SystemD", and when I'm referring to systemd(1), I spell it "systemd". I understand that some folks who only wish to shit on the Systemd Project also spell it that way, but I ain't one of them.
> systemd-init is a small slice of the code in the systemd repository.
Given the context:
I'd say that the topic of discussion was SystemD, rather than systemd. systemd doesn't provide you with all that many capabilities; it's really not much more than what you get with OpenRC + a supervisor (either supervise-daemon or s6).SysVInit is abusing runlevel scripts for starting daemons which has always been a hack to be able to resolve dependencies between daemons.
Learning Linux or Unix from scratch shouldn’t include using crude hacks.
I'm with you on this. SysVinit is better than systemd, but far from perfect. I don't enjoy tediously maintaining all of those symlinks, and prefer the BSD approach myself.
One project on my distro is a new init that will be much, much simpler than SysV, more like BSD and without all the years of cruft.
Linux is literally 62k C files. The amount of time you'll spend understanding how Linux works will dwarf systemd. At least when studying systemd you will be learning a more modern approach of init systems.
Most of those files are device/fs/network drivers and various arch support. The core you need to comprehend is not that much larger than systemd.
Or to put it another way, systemd has grown to become so large and complex it's like a kernel unto itself.
> To me LFS is about learning how a system works.
I'd just like to interject for a moment. What you're referring to as Linux, is in fact, Linux plus systemd, or as I've recently taken to calling it, Linux/systemd.
Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd corelibs, systemd daemons, and vital systemd components comprising a full OS as defined by Poettering.
-- https://mastodon.social/@fribbledom/116002799114521341
8/10
This, of course, is a tongue in cheek.
I am looking forward to UnixFromScratch and Year of Unix on the desktop as Linux more and more sells itself out to the overstuffed software virus that is System D.
I know this is a bit tongue in cheek, but the systemd hate is so old and tiresome at this point.
I need my systems to work. Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.
I can absolutely say that I've never had a showstopping problem with sysv. That is about 30 years as a unix & linux admin and developer.
The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.
You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.
You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.
You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.
The original authors went on to design Plan 9 and Inferno, and did not in any means consider UNIX perfect.
Also Linux is trailing here Solaris, OS X, Aix,...
Your points are well taken. Linux is far from perfect and people shouldn't worship it. sysvinit is inferior to BSD init in my view and there are other questionable design decisions.
The biggest problem is that people are being railroaded into one thing or the other by the strong arm of corporations instead of being given options. My system helps with that.
I won't support systemd/wayland/etc, but others easily can add that in to their version of the distro if they like and support it themselves without too much work, as it's designed to be forked by anyone.
Equally tiring is the “it works for me so stop complaining” replies, which do nothing to stop the complaints but do increase the probability of arguments. Want the complaint posts to stop? Suggesting that they’re in some way invalid is not the way.
Yeah, it’s so tiresome that other people have a philosophy different from mine which seems to have prevailed for now. Like ok so sorry. Systemd on linux is the worst of both worlds imho which apparently according to GP to which I’m progressively less entitled. I like NetBSD and its rc init and config system. Oh no systemd sore winners incoming!
Imagine that, people on the internet disagreeing. I've had both sysv and sysd crap in my cheerios. The thing I appreciated about sysv was that it stayed in its lane and didn't want to keep branching out into new parts of the system. Sysvinit never proposed something like homed.
My experience, and the common experience I’ve read, is the exact opposite. Run scripts worked. They always worked. They were simple. I’ve run into so many difficulties with systemd, on the other hand. I gave up managing my own server as a result.
I understand where you’re coming from but early systemd with both ubuntu and centos was a fucking mess. It’s good now but goddamn it was painful and the hate is 100% justified.
Might be good for some, I'm still having issues!
Funny you should mention CentOS, which it outlived.
> Not once in my career have I experienced a showstopping issue with systemd.
Like clockwork, we'd have a SystemD edge case cause a production-down incident at a (single!) customer site once per year. Inevitably, we'd burn anywhere from a half day to a week attempting to figure out WTF, and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
The project is full of accidental complexity that its maintainers can't be bothered to fix when unplanned interactions cause problems and are brought to their attention. I certainly don't blame them; that sort of work is only interesting to a very specific sort of personality, and that sort of personality doesn't tend to thrive in a typical software company.
I can also absolutely say that I've never had a showstopping problem with OpenRC in the nearly twenty-five years I've been using it. It's remarkable how reliable it is.
> and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.
Do you have a reference? Not that I don't believe you, but I hated this behaviour from Poettering (although he seemed to more often blame the user) and we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
I'm afraid I don't have a reference. The combination of the facts that the bugs are always damn obscure, there are so many Github Issues filed against systemd/systemd, $DAYJOB keeps me so busy with a huge variety of tasks, and the inappropriate lack of giveashit demonstrated by the project maintainers made me so angry means that the details just get blown out of my head.
> ...we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.
To whom would these issues be raised to? Based on my personal and professional experience, the SystemD maintainers (and -for those who are paid to work on the project- those who manage them) seem to disagree that "eliminating sharp edges" is a big priority!
> Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.
I have had both ruin days for me. In particular the "hold down" when it detects service flapping has caused issues in both.
I use runit now. It's been rock solid on dozens of systems for more than a decade.
OP here. I was hoping we could avoid the interminable, infernal discussion of systemd vis-a-vis emotional states.
What about Windows hate is so old and tiresome now?
I need my system to work!
While I'll ignore the System D hyperbole, your point about Unix has merit.
I think the *BSD are also good, at least from an educational standpoint, with their relative simplicity and low system requirements. Since there is a lot of integration making a from scratch distro might take less material, but it could be supplemented with more in depth/sysadmin exploration.
From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.
I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?
Here's an example:
When I was building the initial version of my distro starting from a Linux Mint computer, one time I accidentally double-mounted the virtual filesystems (/tmp, /run, /proc, etc), on the target volume as my script was too primitive and didn't check the mounts first.
Exactly 60 seconds later, the whole system crashed.
Later I accidentally did this again, except this time immediately caught the problem and undid it. No matter--systemd still crashed 60 seconds later anyhow.
Or like the bug that was revealed a while back where the firmware EEPROM was writable by default in /sys or wherever it was, resulting in somebody's firmware getting overwritten and the system bricked. lol
That's the systemd life for you, in a nutshell. That sort of thing times a thousand. Not all at once, mind you--it will just take a nibble out of you here and there on and off until the end of time. After a while it will straight up fuck you, guaranteed. Which is exactly what it was designed to do.
Same with anything "Linux Puttering" touches. The guy who is now officially a Microsoft employee, as people were saying he really was all along.
Bear in mind that the entire purpose of systemd is to replace a huge amount of previous system administration solutions in a fashion that is centralized and automated, and not in need of as much human intervention as previous init systems. For copious examples, look through these comments and the huge number of previous HN threads on this huge topic. That is my answer.
If there are so many such instances, surely you must have one that comes readily to mind, then.
I can do gainsaying too: surely you didn't look through these comments and the huge number of previous HN threads on this huge topic. Do your own work.
Sadly is Linux is no longer what is used to be for my generation that cut their teeth having to patch kernels for basic hardware support.
Linux is now effectively systemd/linux, and is attempting to become flatpak/systemd/linux through various corporate sponsored initiatives. The only thing worse, in my eyes, are people who distribute things as docker containers.
The Linux distro as such is becoming an anachronism. There’s no real place to innovate without the inertia of choices made by external projects being enforced on you.
I think it’s a generational change. My generation had Microsoft to contend with, and so sought certain freedoms, but this generation has walled gardens and AI to contend with, so freedom à la Microsoft seems okay and so Linux is being Windows-ified, while Windows itself becomes its own abomination.
> Linux is now effectively systemd/linux
This is my issue with systemd. I wanted Linux because I wanted to have a choice. The philosophy was that users should have a choice. Systemd goes against that: it's taking over everything and more and more projects require systemd. Flatpak as well: if a project only supports flatpak, chances are that it won't be easy to package normally. So if I don't use Flatpak, I'm screwed.
People who don't see the problem with systemd "because it works" miss the point, IMO. It's like those devs who proudly ship their project in a docker container, because they are not capable of making it properly available to package maintainers. "It works", but I can't package it for my distro because it's a big mess. Developers don't have to package their project for all distros, they just have to properly provide the sources. But more often than not, they don't know how to do that, and instead see Flatpak/docker as "good alternatives that just work".
> Developers don't have to package their project for all distros
Essentially nobody uses the sources we provide. Literally nobody packages them. A few people use our rpm and deb packages, but the vast majority uses a (slightly broken and outdated) docker image built by third party.
You might not like it, and I certainly do not, but unfortunately containers seem to be the best alternative that just works, compared to everything else.
> but unfortunately containers seem to be the best alternative that just works, compared to everything else.
I think it's actually the worst alternative that works. If it didn't work, people wouldn't do it. And the better alternatives require more effort.
I think it unfortunately goes with popularity: when programming becomes more accessible, the average quality of code gets worse. When Linux becomes more accessible, the average level of its users gets worse.
What made Linux desirable for me risks getting worse the more popular it gets. I went from Debian to Arch, to Gentoo, and eventually I may have to move to a *BSD. Because apparently what I want disappears when a system gets massively popular.
Send me an email please if you haven't yet. You'll want to try this distro, and I'd like to get your feedback.
site: killthe.net
name: dave
I've been using Gentoo for 20+ years, it hasn't changed much. I have changed different logger, cron, ntp, login and probably other daemons over time. Stability has gotten better over time, making me not switch to anything else.
I absolutely love Gentoo, and I actually wonder why I haven't moved there earlier (probably I was scared, and the availability of binary packages gave me a reason to try).
I really didn't want to mean that systemd/flatpak are impacting Gentoo and that I am considering moving away.
My hope is that some distros like Gentoo will keep the "old" spirit of Linux forever, while others try to please those who want Windows-but-without-ads.
Except for the main pid1 process, systemd is one of the most customizeable things, certainly much more than old shell-based things. Everything is documented, can be disabled or replaced, and in such a way that the rest of the system can keep functioning, and the system upgrades don't mess it up.
A lot of people said you can edit /etc/init/ scripts, but this was pretty annoying, as the moment you upgrade the package, your package manager throws a conflict at you. It was certainly non-scaleable if you have many machines with automated upgrades. Compare to systemd overrides, where there is both drop-ins and wholesale service replacement, and system upgrades never mess with that.
Heck, even something as simple as "disable distribution-provided service" was a pain! I can't remember how many times I've added "exit 0" to /etc/default/something file, just because the sysvinit did not respect user decisions during upgrades or reinstalls! Compare to systemd, where I can "mask" the service even before it's installed.
And for deeper changes? Pre-systemd ubuntu had this this stupid "system is online" idea, and I once needed to customize this.. this was lots of undocumented reading and hacking on the script, and let's hope we did not need to upgrade. Or something like "my service X should start after NFS, but ssh should start before NFS" - this was pretty hard as well, and would cause upgrade conflicts.
Systemd has lots of problems, but the customizeability is one of their best parts. It is the only thing that I know which clearly delimits "user" vs "distribution", and gives all the power to user.
I am not sure if we are talking about the same thing. I am not saying that systemd is bad. I am saying that when a project has a hard dependency on systemd (which is not necessarily systemd's fault, to be fair), then it doesn't work with an alternative init system.
Right, but my point is that unlike earlier init systems, unless that dependency on pid 1 itself, there is nothing preventing alternative implementations, and in fact, there is all the support to make such implementations possible.
To give an example, let's say a package depends on systemd because it uses sd_journal protocol, presumably because it wants to send enriched logs. That protocol is fully described (in [0]), and is actually pretty trivial to implement, on both server and client side. It even have a build-in "upgrade" mechanism (via $JOURNAL_STREAM) to allow seamless switch between base/systemd-logs, although AFAIK sd_journal_* functions do not implement it by default.
So this brings us a question: if a program wants to provide rich logs, and it is is using a documented protocol to do so, but there is only one implementation of the receiver, is this a problem? Is the onus on the program's authors to support multiple log sending functions, or on the distributions to provide a log receiver that the program expects?
[0] https://systemd.io/JOURNAL_NATIVE_PROTOCOL/
I would have not bothered with Linux if Windows NT had a proper UNIX subsystem.
I needed a way to avoid going to campus and fight for a DG/UX terminal.
It had nothing to do with FOSS fighting.
> if Windows NT had a proper UNIX subsystem
They actually did, but they made the mistake of packaging only the bare basics with it, and hiding it away as much as they could: https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
The American government added some obscure law that forced POSIX compatibility on operating systems for certain grants, so Microsoft made their business OS POSIX-compliant.
In theory, nothing stopped you from downloading and installing up-to-date versions of common UNIX tools. Had Microsoft had the necessary foresight, they could've killed deverlopers' dependency on tools like Cygwin and Git Bash and Linux entirely for many pieces of software, but they were too busy trying to make Win32 the standard ABI.
Funnily enough, Win32 became the standard for proprietary software on Linux (thanks to Wine+Proton) while many Unix/Linux-based tools became the norm for development, even on Windows (git, Qt). How different things could've been!
Not really, Windows Services for UNIX was released in 1999, I am talking about Windows NT 3.51, released in 1995, which only supported POSIX.1, badly.
https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
When Windows Services for UNIX came to be, it was already too late to matter, it wasn't really from Microsoft, and came with its own set of problems.
I am speaking from when Linux was still in baby steps, and basic stuff like ELF had just been added with the kernel version 1.0.9, in 1995.
Things could be even more different, had Microsoft kept Xenix, which was my introduction to UNIX, and one of Bill Gates darlings, actually.
https://www.theregister.com/2002/03/20/bills_vision_for_the_...
"The Future of Xenix"
https://archive.org/details/Unix_World_Vol02_10.pdf/page/n21...
> Win32 became the standard for proprietary software on Linux
This isn't even possible at all. You have software and standards. There's no single set of software nor a single set of standards. Saying something or somesuch is "the" standard is plain false.
All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future, or at least a linux distro from the list here https://nosystemd.org/ - probably Gentoo. Nothing to stop me, absolutely nothing at all. I just need a few days free to backup/wipe/reinstall/reconfigure/restore_data and I'll be good. Better make that a few weeks. Maybe on my next machine build. It's not easy, but I build machines for long term use.
As for Linux from Scratch - This is something that's been on my radar, but without the part I'm truly interested in (learning more about SysV) then I'm less inclined to bother. I don't buy the reason of Gnome/KDE - isn't LfS all about the basics of the distro than building a fully fledged system? If it's the foundation for the other courses, but it still feels weak that it's so guided by a future GUI requirement for systemd when it's talking about building web servers and the like in a 500Mb or less as the motivation.
What practical problems do you run into with systemd?
All the compliants I see tend to be philisophical criticism of systemd being "not unixy" or "monolithic".
But there's a reason it's being adopted: it does it's job well. It's a pleasure being able to manage timers, socket activations, sandboxing, and resource slices, all of which suck to configure on script based init systems.
People complain in website comment sections how "bloated" systemd is, while typing into reddit webpage that loads megabytes of JS crap.
Meanwhile a default systemd build with libraries is about 1.8MB. That's peanuts.
Systemd is leaps and bounds in front of other init systems, with robust tooling and documentation, and despite misconceptions it actually quite modular, with almost all features gated with options. It gives a consistent interface for linux across distributions, and provides a familar predictible tools for administators.
> But there's a reason it's being adopted: it does it's job well
My problem with systemd is that it's taking over more and more and locking in. It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative.
My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in".
We like to complain about lock-in across the board. I don't see why it would be different with systemd.
I think you got it backwards. Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
I somehow don't think your gripe is with systemd but with developers who prefer the easy route. To be honest though you get something for free. If you want it differently then you have to do it yourself.
I don't think it's backwards; it's not incompatible with what you said.
> It is just nice to know that all the tools you need for a system are there and work together.
It is indeed! Just like everybody uses WhatsApp for a reason. But because everybody uses WhatsApp, it is very difficult to get traction with an alternative. That's the lock-in part.
It is easier for developers to only care about systemd. It's often worse: many times I have seen projects that only work with Ubuntu. Of course I understand how it was easier for the developers of those projects to not learn how to "be nice" and "do it right". That does not mean I should be happy about it.
> If you want it differently then you have to do it yourself.
Or I should support alternatives, which I do. I am not saying you are not allowed to use systemd, I am just explaining why I support alternatives. Even though systemd works.
I'd argue that "do it right" and "be nice" are incredibly subjective. I'd say they were already nice enough to write open source software. And I don't think it is wrong to to write what you want to write.
The comparison with WhatsApp has a a huge flaw: WhatsApp is not LGPL licensed software. No one can really take systemd away. There is very little risk in depending on it apart from less choice. But I already argued that the expectation of choice in free software is a big ask.
And there is no one stopping anyone from implementing systemd's api surface.
The reason why I say you got it backwards is that you are against systemd making available all their tools when in reality it is the distro maintainers choice to use them and the developers choice to depend on them. Most of systemd is optional and nothing prevents developers from writing abstractions. But the simple truth is that systemd is offering a compelling value that people are just accepting.
> Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.
That's the official story, but like most official stories, it doesn't really hold up to scrutiny.
I built an entire system from scratch with over 1,500 packages installed. Everything under the sun. Works just fine with sysvinit. Completely seamless.
If KDE/Gnome can't figure out how to fit in with the overall system design the same way thousands of other packages somehow manage to do, then their services are no longer required. Good riddance to their bloated asses. I prefer to invest my CPU cycles in better software.
Init scripts for services and such are properly handled by the distro maintainer (packager), not the developer, although it's always nice to see examples he's provided to help guide the development of my preferred version.
I am honestly happy for you that you made your system the way you want it. That is a good thing and please keep doing what you are doing.
This is not relevant to the average user. The average PC user doesn't use Linux and the average Linux user uses an off the shelve distro. For these distros it is very attractive to have a bunch of core services ready that work together because they are released as one. It can be done but why the hassle? What is the upside for the maintainer apart from maybe the moral high ground?
Software projects can also benefit from standardization. They can concentrate on writing functionality instead of maintaining abstraction layers. And I believe the more mainstream distros choose the SystemD stack the more it becomes the default or at least the initial implementation for their software.
We also have to keep in mind that this kind of standardization is nothing new. Pretty much every distro depends on the GNU coreutils. Maybe not on the binaries themselves but at least on their API. That is not very different from SystemD. We have a POSIX standard.
Final word regarding sysvinit: I worked with sysvinit, upstart and systemd and having an opinionated config format for services is so much better, in my opinion. Not having to read a whole shell script to know how a service works is such an improvement and the easy overrides for units (for example distro packaged ones) is amazing.
Note: In my post I counted distro maintainers as developers.
You lost me when you started talking about the average user. I don't care about that guy or his desires. At all.
I miss the days when computing was about the above average guy--not the simpleton who needs his hand held, so everything has to be dumbed down to the lowest level to suit him.
Heard it all before, and I'm not interested in anything systemd has to "offer." Especially all the bugs and security issues.
This distro isn't for you. That's OK. systemd, and wayland, etc that some are so excited about isn't for me or a number of others, and it will never be. We are going our separate way. Just look at all the comments below. Lots of upvotes too.
It's not a lock-in as much as making a much better product.
For example, I never liked the idea of having my programs to manually daemonize, manage logs, set up permissions and all that boring, but security-critical stuff. And with systemd, I don't have to! Program reads from stdin/stdout, maybe gets socket from socket activation, and systemd does the rest.
Is it lock-in? Only because other system suck. Like, seriously, what stopped xinetd from having rudimentary volatile "on/off" control, so I could disable misbehaving service? Or why is start-stop-daemon so _stupid_, discarding all startup error messages? And don't get me started on all the different init file dialects for each system.
Maybe if the sysvinit programmers actually cared about providing nicer services to app developers, we would never end up with systemd.
The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.
"BSD init", "much simpler"... So does this mean you still expect applications to manage their own logs, daemonization and security setup themselves?
If yes, that's yet another init system not made for application writers.
Manage their own logs, daemonization, and security? The humanity! How will they ever manage all of that?
Come on man. It's been done for decades.
It doesn't take a giant bloated infrastructure to manage most people's needs, which are quite basic in most cases.
.. and that opinion is a great explanation of why systemd won.
Turns out, a lot of people are not happy with "Come on man. It's been done for decades." attitude, and they wanted something new and much better. And so when something new came up, they jumped on it with both feet.
It's instructive to read Debian CTTE discussion on init systems (btw I think it's best tech drama of 2013, highly recommend) - a lot of people dismissed the sysvinit early on because it had no features (example [0]), which means the choices were either upstart and systemd. And between two of those, systemd is a clear win.
Read the thread and look at how many highly technical people with no relation to Fedora or Poettering is ready to choose _anything else_ just to get away from "it's been done for decades".
[0] https://lists.debian.org/debian-ctte/2013/12/msg00234.html
I wrote up some issues with service reliability here https://github.com/andrewbaxter/puteron/?tab=readme-ov-file#...
Design-wise, I think having users modify service on/off state *and* systemd itself modify those states is a terrible design, which leads to stuff turning back on when you turn it off, or things turning off despite you wanting them on, etc. (also mentioned higher up)
FWIW after making puteron I found dinit https://github.com/davmac314/dinit which has a very similar design, so presumably they hit similar issues.
Systemd usually only modifies the state if is somehow configured to do so. Socket activations, timers, depwndencies. They all tell systemd what to do and can usually be modified if needed.
Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound.
But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup.
To give you concrete examples:
1. Systemd has mount units, that you would expect to behave like regular units but for mounts. Except that they don't. You can specify the service retry/restart policy for regular units, including start/stop timeouts, but not for mounts.
2. Except that you can, but only if you use the /etc/fstab compat.
3. Except that you can not, if systemd thinks that your mounts are "local". How does it determine if mounts are local? By checking its mount device.
4. Systemd has separate behaviors for network and local filesystems.
5. One fun example of above, there's a unit that fires up after each system update. It inserts itself _before_ the network startup. Except that in my case, the /dev/sda is actually an iSCSI device and so it's remote. So systemd deadlocks, but only after a system update. FUN!!!
6. How does systemd recognize network filesystems? Why, it has a pre-configured list of them: https://github.com/systemd/systemd/blob/4c6afaab193fcdcb1f5a... Yes, you read it correctly. A low-level mount code has special case for sshfs, that it detects by string-matching.
7. But you can override it, right? Nope. This list is complete and authoritative. Nobody would ever need fuse.s3fs . And if you do, see figure 1.
I can go on for a looooong time.
5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.
They're already reported. And ignored. Have you _seen_ the systemd issue backlog?
The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored.
The remote FS detection also came up multiple times, and the maintainers don't care.
> and the maintainers don't care.
I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report.
This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.
> I think better proof of this would be a rejected PR rather than a neglected bug report.
I understand the sentiment you're expressing here, and it's often a reasonable one.
However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not that behavior is correct. Maybe we should do something about this or document this so other folks know about it." (and then nothing happens, not even the documentation) or a closed Github Issue with "Sorry, your usecase is <strike>inconvenient to implement</strike> unsupported. E_NOTABUG", expecting PRs is expecting way too much.
I've long been in the habit of reading accounts like yours, understanding the truth and wisdom that's being expressed, then noping the fuck out of the tech/product/situation in question. It has saved me a lot of trouble over the years. Even as others are completely mystified. Some people just like abuse, I guess.
"Sweet dreams are made of this..."
The problem here is more fundamental.
Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because."
I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy.
I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local").
I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.
This is one example of a more general complaint about systemd and related projects: they force policy, rather than simply providing mechanisms.
I recently did a deep dive on my laptop because I was curious about an oddity - the /sys file to change my screen backlight (aside, why /sys and not /dev anyway?) was writable only by root - yet any desktop shell running as my user had no problem reacting to brightness hotkeys. I wondered, how did this privilege escalation work? Where was the policy, and what property of my user account granted it the right to do this?
It turns out the answer is that the desktop shells are firing off a dbus request to org.freedesktop.login1, which is caught by systemd-logind - or elogind in my case, since I do not care for systemd. A login manager seemed an odd place for screen brightness privilege escalation, but hey if it works whatever - it seemed like logind functioned as a sort of miscellaneous grab bag of vaguely console-related stuff. Generally speaking, it consults polkit rules to determine whether a user is allowed to do a thing.
Not screen brightness, though. No polkit rules. Nothing in pkaction. logind was unilaterally consenting to change the brightness on my behalf. And on what grounds? It wasn't documented anywhere so I had to check the source code, where I found a slew of hardcoded criteria that mostly revolve around physical presence at the machine. Want to change screen brightness over ssh? Oh but why would you ever want to do that? Hope you have root access, you weirdo.
I removed elogind. A few odds and ends broke. But nobody tells me what to do with my machine.
OK, think it through...
How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Consider that the network endpoint might be localhost, a netlink/unix/other socket, or, say, an IP address of the virtual host (practically guaranteed to be there and not truly "remote").
systemd has .mount units which are way more configurable than /etc/fstab lines, so they'd let you, as the administrator, describe the network dependency for that specific instance.
But what if all we have is the filesystem type (e.g. if someone used mount or /etc/fstab)?
Linux doesn't tell us that the filesystem type is a network filesystem. Linux doesn't tell us that the specific mount request for that filesystem type will depend on the "network". Linux doesn't tell us that the specific mount request for that filesystem type will require true network connectivity beyond the machine itself.
So, before/without investing in a long-winded and potentially controversial improvement to Linux, we're stuck with heuristics. And systemd's chosen heuristic is pretty reasonable - match against a list of filesystem types that probably require network connectivity.
If you think that's stupid, how would you solve it?
> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?
Like systemd authors do! Hard-code the list of them in the kernel, including support for fuse and sshfs. Everything else is pure blasphemy and should be avoided.
Me? I'd have an explicit setting in the mount unit file, with defaults inferred from the device type. I would also make sure to not just randomly add landmines, like systemd-update-done.service. It has an unusual dependency requirements, it runs before the network filesystems but after the local filesystems.
I bet you didn't know about it? It's a service that runs _once_ after a system update. So the effect is that your system _sometimes_ fails to boot.
> systemd has .mount units which are way more configurable than /etc/fstab lines
It's literally the inverse. As in, /etc/fstab has _more_ options than native mount units. No, I'm not joking.
Look at this man page: https://www.freedesktop.org/software/systemd/man/latest/syst... The options with "x-systemd." prefix are available for fstab.
Look for the string: "Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file."
Sounds like your admin, distro, or the systemd team could pay some attention to systemd-update-done.service
The "can only be used in /etc/fstab" systemd settings are essentially workarounds to do those things via fstab (and workaround fstab related issues) rather than depend on other systemd facilities (c.f. systemd-gpt-auto-generator). From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
This service is the standard part of systemd. And my distro is a bog-standard Fedora, with only iSCSI as a complication.
Are you surprised that such a service exists? I certainly was. And doubly so because it has unusual dependency requirements that can easily lead to deadlocks. And yes, this is known, there are open issues, and they are ignored.
> From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.
No, they are not. In my case, I had to use fstab to be able to specify a retry policy for mount units (SMB shares) because it's intentionally not exposed.
And yes, there's a bug: https://github.com/systemd/systemd/issues/4468 with the expected GTFO resolution: https://github.com/systemd/systemd/issues/4468#issuecomment-...
So there's literally functionality that has been requested by people and it's available only through fstab.
> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"?
The '_netdev' option works a treat on sane systems. From mount(8):
It should work on SystemD and is documented to in systemd.mount but -surprise surprise- it doesn't reliably work as documented because SystemD is full of accidental complexity.Sure, and systemd would translate that directly into a dependency on network startup, which is precisely equivalent to the approach I mentioned that depends on operator knowledge. It's configuration, not "just works" inference.
> Sure, and systemd would translate that directly into a dependency on network startup...
You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable:
> ...not "just works" inference.Given that SystemD can't reliably handle explicit use of _netdev, I'd say it has no hope of reliably doing any sort of "just works" inference.
It's so refreshing to discover that the "I found one bug in systemd which invalidates everything" pattern continues in the year of our lord 2026.
Just one bug? No, there's way more than that.
I saw many corner cases in systemd over the years. And to echo the other poster in this thread, they typically are known, have Github issues, and are either ignored or have a LOLNO resolution.
And I'm not a systemd hater. I very much prefer it to the sysv mess that existed before. The core systemd project is solid. But there is no overall vision, and the scope creep resulted in a Cthulhu-like mess that is crashing under its own weight.
> "I found one bug in systemd which invalidates everything"
I'll refer back to the story of Van Halen's "no brown M&Ms" contract term and the reason for the existence of that term and ones like it.
"Documented features should be reasonably well-documented, work as documented, and deviations from the documentation should either be fixed or documented in detail." is my "no brown M&Ms" for critical infrastructure software. In my professional experience, the managers of SystemD are often disinterested in either documenting or fixing subtle bugs like the one GP linked to. I find that to be unacceptable for critical infrastructure software, and its presence to be indicative of large, systemic problems with that software and how work on it is managed.
I really wish SystemD was well-managed, but it simply isn't. It's a huge project that doesn't get anywhere near the level of care and giveashit it requires.
That is one of my problems with systemd: it has way to much "magic" built in. SysVinit/OpenRC and related are easy to understand and debug: they only do what's in the scripts.
I love systemd, but you've hit on one of my biggest complaints. The mounting promises a cohesive system and instead gives you a completely broken mess, with mounts being split across .mount unit files, fstab, and worst of all, .service unit files. It's a totally incoherent mess, and that's only _after_ you figure out why nothing is working right, and build a complex mental model of every single feature that does or doesn't work in which scenario. Knowledge you only gain after screaming and tearing your hair out for a weekend. Your reward? A totally incoherent, inconsistend mess.
I hate mounts in systemd.
And don't forget automounts! They are so much fun!
OpenRC on Gentoo works great. I have a full bleeding edge Wayland KDE Plasma with Pipewire setup that I game on.
OpenRC recently added user "units" aka services running as a user after a session start. Something that many new GUI user space applications rely on for various things.
There are growing pains. https://bugs.gentoo.org/936123
Especially when upstream hard requires systemd. More annoying when there's no real reason for it.
But there is a way forward and I highly recommend people try to build software to work without systemd before assuming it's always there.
To pile on, a minimal OpenRC service file is just as complicated as a minimal SystemD service file; that is, they're both almost-exclusively composed of key-value pairs. For instance, this is the service file for the 'rsyncd' service [0]:
Like SystemD, OpenRC provides pre/post start/stop hooks that you can use to call out to other programs.Unlike SystemD if you need to make nontrivial decisions at service-status-management time, you have the option of putting your scripts or calls to other programs inline, rather than hoping that SystemD gives you the hooks you need in the places you need them and passes in the data you require. [1]
[0] And if 'rsyncd' was supervised with 'supervise-daemon', you wouldn't need to specify the location of the pidfile.
[1] As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does). As a less-trivial example, you can check for and warn the administrator about common service misconfigurations with the same mechanism that provides service startup and status information (as several services do).
> As a trivial example, you can dynamically depend on other services depending on system configuration (as PostgreSQL does)
Depending on what you want to do, a generator might be appropriate:
> Their main purpose is to convert configuration and execution context parameters that are not native to the service manager into dynamically generated unit files, symlinks or unit file drop-ins
Well, here are the relevant parts of the service file:
If PostgreSQL has been configured, this reads its config file, looks to see if it's configured to use 'syslog' as its log destination, and -if so- adds a dependency on the 'logger' "meta-service". [0]What would this look like with a systemd service file generator?
[0] What's a "meta-service"? 'provide postgresql' makes the service started by this service file provide the 'postgresql' "meta-service". This is useful for PostgreSQL because you can install multiple versions of the software simultaneously... so the service files are named like postgresql-17, and postgresql-18. The 'logger' "meta-service" is useful because who cares which syslog software you have installed... you only care that it speaks syslog.
Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations etc is… not a great idea in my opinion.
But of course in this particular case, because systemd makes the /dev/log journal/syslog socket a dependency of every unit by default, there is no need to encode this dependency at all.
Anyway if you really wanted to you could write this script as a generator and have it put a drop-in in /run/systemd/system/postgres.service.d. But… why?
Okay, I'll rephrase the question a bit and ask it again.
Imagine that you have a service that has a configuration-dependent dependency on rsyslog. For whatever reason, journald's not an option... maybe it's simply not installed, or this service depends on rsyslog-specific behaviors that journald simply doesn't replicate. It doesn't matter why this configuration-dependent dependency exists, it simply exists and there's no workaround.
Assuming that the rsyslog service is named 'rsyslog', the service with the dependency is named 'stupid-service', the configuration file is named '/etc/stupid-service/stupid-service.conf', and the configuration option to search that config file for is 'logging = syslog', what would the systemd service file generator look like to make 'stupid-service' depend on 'rsyslog' if and only if that config file contains 'logging = syslog'?
You appear to have worked with these service file generators, which is why I'm asking. I expect you'd know what the generator to accomplish this trivial task would look like, or if it was even possible with generators.
Also:
> Yeah parsing config files with regular expressions that may or may not properly handle quoting or line continuations
Nah, this is substring matching and column-cutting. The only use of regexes ("#.*") is to remove comments. Go check out the format docs for the PostgreSQL config file. [0] It's pretty basic and straightforward.
[0] <https://www.postgresql.org/docs/17/config-setting.html#CONFI...>
Put a script in /etc/systemd/system-generators/ that does something like
> It's pretty basic and straightforwardPostgres config supports line continuations, so the OpenRC service file you quoted is buggy; it could potentially match a file just because some other option contained a multi-line value that had the string "log_destination = syslog" in it.
The whole philosophy of systemd is to move away from these kinds of "simple" and "mostly working" pile-of-shell-script systems to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.
> Postgres config supports line continuations, so the OpenRC service file you quoted is buggy; ...
Where's that documented?
I tried the obvious things followed by a config reload. Here are the results (the 'log_destination' parameter is on line 482 of the config file):
What's the line continuation character for 'postgresql.conf'? Are you certain that you're not getting 'postgresql.conf' confused with 'pg_hba.conf'? That file is documented to support line continuations: [0] > The whole philosophy of systemd is to move ... to actually-unconditionally-correct configuration that doesn't come with bonus text processing surprises.That's truly a lovely and laudable goal. In this system, how does you propose one processes a flat text config file with a mix of 'K = V' and 'K V' settings without doing ordinary, boring text processing? Do you propose that one waits until "systemd-configd" gets created and every daemon of any importance is updated to put its config in there instead of in flat files? If so, has there been any notable progress on this in the last ~fifteen years?
> Put a script in /etc/systemd/system-generators/...
Thanks for finally answering my question. Is the way to conditionally update service dependencies really to dump text files in magic locations? Is there no 'systemctl' (or similar) command that allows one to manipulate dependencies for a specific service that one can call from a generator?
[0] <https://www.postgresql.org/docs/17/auth-pg-hba-conf.html>
I wonder if the impetus behind the (terrible) monolithic design of systemd was to force standardization across distros. The choice was more political than technical.
If different choices were available for init, DNS resolver, service control manager, volume manager, etc... we would adversely contribute to the schizo distro landscape the people holding the money bags are actively trying to get away from.
With systemd it's an all-or-nothing deal. You get the good with the bad, but all distros shit the bed in the same, deterministic way.
Not even Windows does this. There is no "systemd" equivalent. Yes, Windows ships as a single OS—as do the BSDs—but all the components were developed separately.
If all they wanted was a service control manager, there were many (better) options already in existence they could have used.
systemd is not a monolith, and distros make different choices on what portions of systemd they which to ship and enable by default.
For example, not all distros ship and use systemd-resolved by default, to choose from your list.
systemd-boot competes with grub
Outside of Arch(-derived) enthusiast circles, I haven't seen systemd-boot used anywhere.
It has some really nice tools and features that Grub lacks (i.e. it has tooling for checking the state of things like secure boot and analysing the security risks of your boot configuration), but every mainstream Linux OS I've used still relies on tools like Grub to boot.
I have some gripes with systemd-boot's limitations (notably, the insistence on an unthemed, white-on-black menu system that's not exactly enticing to Linux newcomers) but it's hard to deny its merits. Grub is tied together with a spider web of scripts calling each other, loading modules, generating code that is then executed again, and one mistake in one script can cause the bootloader config four scripts down the line to fail, leaving the system unbootable; the concise configuration file for systemd-boot makes for a much better bootloader configuration system in my opinion.
OpenSUSE uses systemd-boot for its GRUB2 BLS implementation (<https://news.opensuse.org/2024/10/08/grub2-bls/>). It's really awesome because it lets me boot from Btrfs snapshots on a fully LUKS2 argon2id encrypted system.
The argon2id issue remains an annoying problem (AFAIK Grub still doesn't support argon2id), but for tools like Timeshift there are Grub scripts to also boot BTRFS snapshots.
NixOS uses it by default
and grub is a rotting pile while systemd-boot is a simple boot entry multiplexer that rides off the kernel's capability of being run as an EFI executable, it just happens to live in systemd's tree. not a good example
It's a pretty good example of why people think systemd is bloated and does too much. It's a simple boot entry multiplexer. Does it need to live in systemd's tree?
Nobody complains about a very wide variety of only vaguely related utilities being in the Gnu coreutils tree.
Nor the 20 or so odd reimplementations of various filesystem drivers and LUKS encryption in the grub2 tree.
But, who is counting?
I'm tired of grub too. That's one of the packages on my shitlist. Currently it is broken on my system, as it has been in the past from time to time. I'm tired of the unreliability and have decided to write my own bootloader instead. It will be simple and bulletproof.
I already laid the basic foundation and have the kernel loading into memory and booting. Next step is to get the memory map and pass that along. It's BIOS only for the moment; EFI support will come later, along with other architectures. (PowerPC is next.)
so its a marketing problem, irregardless of whether it's in systemd's tree because the systemd maintainers want to maintain it in-tree
Even better example, I don't think systemd-boot is broadly adopted yet although there are certainly some distributions that use it.
The thing is not just about distros and big developers it is about every developer out there who wants to write system software. Instead of doing the work to support multiple different APIs they can concentrate on the software. Its just easier. You don't have to track the compatability of different tools.
For many people Linux is not an academic exercise. It is a tool they want to use. The don't care to use a different network manager or resolver.
And that is exactly the same as Windows. There is one solution across the whole system and it works together because it is written by the same people and tested together.
Try Alpine? It's not designed to be a "desktop" OS but it functions well as one. I find it easy enough to wrap my head around the whole thing, and it uses OpenRC by default.
Almost wonder if this kind of thing will be an impetus for GNU Hurd to get more momentum. I saw an update recently that they're now finally properly supporting 64bit and sounds like there's active dev going on there again.
It apparently uses SysVInit
Others have been reminding us of the *BSD init systems, and I remind that SysVinit is not going away from Linux while projects like Devuan and others continue. GNU Hurd is another other-than-systemd learning opportunity.
I've heard of Hurd, but never felt tempted to try it. That could be an interesting option.
hurd init is a lot like systemd architecturally, it just gets to use kernel provided ipc rather than having to manage its own. if your objection to systemd is its architecture you don't want anything to do with hurd.
Did they finally add USB support?
I would somewhat doubt it; the negative aspects of Mach’s design are a technical albatross around the neck of any kernel.
Apple has had to invest reams of engineering effort in mitigating Mach’s performance and security issues in XNU; systemd dissatisfaction alone seems unlikely to shift the needle towards Hurd.
> All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future
Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency).
Gnome 50 plans to obsolete X11 completely.
If you want that simple, bright future of yours, you’ll have to fight/work for it.
> Freedesktop wants to kill X11
There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.
You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.
If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.
Phoenix looks pretty cool too.
KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.
> Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?
[0]: see discussion & linked issues in the announcement https://news.ycombinator.com/item?id=44199502
I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility.
He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal.
So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN.
Also Gnome killing X11 support is real.
So is KDE backing down on BSD-support.
These are facts, not opinions.
> I’m sure there’s more to the story than just ABI compatibility
The number one goal for the Xwayland / Xorg devs is stability. Breaking ABI compatibility is a pretty big problem if stability is your goal.
We don't have to guess, the PRs & history are still there. You could easily go through them and find examples of the project members being unreasonable about ABI compatibility.
But of course that would destroy the narrative.
SysV init was the overengineered cousin to BSD init and I never liked it. Easily my least favorite of all init systems I've worked with over the last 30 years. On the flip side, daemontools or maybe runit were my favorites. Lots of good options for init/supervision tooling over the years and SysV was not among them.
If we look on LFS for its academic merit, I'm saddened that key historical elements of Unix/Linux design are being left behind, much like closing down a wing of a laboratory or museum and telling students that they'll need to whip up their own material to fill in those gaps.
Yes, it's like asking students to actually produce something themselves.
What a horrific thought.
If the students have been well trained, they should be trusted to experiment. If the course curriculum demands that they produce something themselves yet does not educate them on doing so, that's horrific.
Certain things should only be taught as a warning. SysV init is one of them.
Back in the day, system run levels were seen as desirable. SysVinit went in on that concept to the max. So, if the concept of run levels isn't clear to the student beforehand, the init system for making it happen would therefore be mystifying and maybe even inscrutible.
Runlevels may be an interesting idea (e.g. the single-user maintenance level). But a bunch of shell scripts, each complex enough to support different commands, sort-of-declare dependencies, etc, is not such a great idea. A Makefile describing runlevels and service dependencies would be a cleaner design (not necessarily a nicer implementation).
On the contrary, I much prefer a full Turing complete language rather than trying to shoehorn my ideas into someone else's limited system.
The scripts don't have to be complicated, and it doesn't have to be shell scripts. You can use any script or executable that the Linux kernel can load and run. But shell scripts work great and have all the power needed.
Systemd is a giant, flaming heap of buggy ass code. Good riddance to it.
The old versions of LFS are still available to satisfy your curiosity.
Someone should probably save the required source package versions (and patches) before they disappear though
From the announcement, it saddens them too:
> 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.
However the reasoning they provide makes sense.. It's hard to build a Linux system with a desktop these days without Sysd.
Is it? What's the connection between systemd and having a desktop?
Read the article: "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"
> It's hard to build a Linux system with a desktop these days without Sysd.
Most Gentoo Linux desktop users disagree. In fact, OpenRC is the default in that distro.
Having said that, I do expect that Gentoo has more manpower available than LFS.
Maybe they're KDE users. I was under the impression that gnome requires it. FTA it sounds like KDE will soon too. Gentoo doesn't come with a desktop by default either, you have to emerge it, which might install systemd..
FTA: "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"
> I was under the impression that gnome requires it.
It doesn't seem to require it at this moment. I have "-systemd" in my USE flags, and have neither sys-apps/systemd nor gnome-base/gnome currently installed. After enabling several USE flags that have nothing to do with systemd [0], emerge was quite happy to offer to install gnome-base/gnome and its dependencies, and absolutely did not offer to install systemd.
Honestly, I don't even know if GNOME has a hard dependency on Wayland... I see many of the dependent packages in the 'gnome-*' categories have an "X" USE flag. I CBA to investigate, though.
Is KDE Plasma building in hard systemd requirements, or is it just building in hard Wayland requirements? I'd known about the latter [1] and -because I'd thought it was important to the KDE folks that KDE runs on BSD- would be surprised if they irreversibly tethered themselves to systemd.
[0] introspection pulseaudio vala server screencast wayland theora eds egl gles2
[1] Though do note that the same blog post that announced the change in policy for Plasma also announced that no other KDE software was going to have a hard dependency on Wayland for the foreseeable future.
LFS never had academic, educational, or pedagogical merit. It was always sheer faith that by doing enough busywork (except the truly difficult stuff), something might rub off. Maybe you learn some names of component parts. Components change.
Could you expand on this comment please? (I don't think your viewpoint should be so rudely dismissed through downvoting and moving on.) What do you mean?
SysV was this weird blind spot for many years. I remember installing daemontools on the OpenBSD server my office ran on because it was nicer to work with, and thinking that the Linux world would switch to avoid losing that particular feature war with Windows.
Gentoo Linux has been using OpenRC for at least as long as I've been using it (~25 years). It's unfortunate that OpenRC was unable to summon the manpower to do the spot-additions required for it to win the political war way back when Debian was looking to move from straight SysV init.
It would have never happened. Systemd wasn't chosen because "we the people" chose it. Things don't work like that anymore, regardless of what the marketing brochure might say.
It's always a little amusing when the Open Source Tea Party bemoans the lack of "the UNIX way" and someone else with actual historical experience (and not misguided nostalgia) brings perspective.
On a related note, X11 was never good and there's a whole chapter in the UNIX-HATERS Handbook explaining why.
It was never good? Weird. Works fine for me.
When will Wayland earn the label "good"? I don't think it currently qualifies.
The proof in the end that SystemD is a cancer in the Linux ecosystem. Officially it is just a stack and you can decide to use another one if you don't like it. Unofficially RedHat money ensured that other critical stacks will depend heavily on it so that you can't easily swap without replacing the whole ecosystem.
The whole GNU / Red Hat platform is this way. Try switching out Glibc. You get the same "you have to use all our stuff" dependencies.
Switching out glibc is pretty easy compared to systemd. That's the thing peoplle don't get. systemd is seriously insidius, like a virus.
I've personally run Gentoo with OpenRC+glibc and OpenRC+musl on my laptop. I assure you ditching systemd was easier than ditching glibc. The OpenRC system mostly just works (tbh thanks to a lot of great work by Gentoo devs). The musl system required probably a couple dozen patches to various packages to get a basic fully working desktop (most of which were relatively straightforward, but still needed manual intervention).
Musl mostly works. I had more trouble taking out bash, because of all the random bashisms.
On my system I forked dash to create 'bolderdash.' Right now it's pretty basic, I have changed little (just did some cleanup), but I did add in a couple tweaks to enhance bash compatibility. The goal is a complete refactor, more compatibility with bash, and much better command line editing etc, while still remaining sleek and lightweight.
I'm also forking musl to create 'powrlibc.' It will have a lot better glibc compatibility, as well as better optimizations and some other improvements.
Where did you get that sweet RedHat money? I feel like I'm missing out, I'm happily using systemd, where are my RedHatBucks!
Seriously, I would not ever go back to a house of cards of bash and shell scripts of an init system. systemd solves actual problems and gets shit done, with a level of consistency that cannot be achieved by LEGO-like wet-dreams of UNIX worshippers. My favorite example is systemd-resolve and systemd-network that actually communicate together to indicate which DNS server is available on which network interface and with which search domains, to gasp do proper DNS routing.
Am I happy with all of systemd? Not always, it has a tendency to break networking after an upgrade with reexec. I'm still not convinced about homed. But oh my, you don't have to look further than actually solving problems to explain its success.
It's like the good old time of Windows. You asked users, they would say that Windows is great, they don't have problems, works better than Linux. Oh do I get some error popups and crashes sometimes? Indeed just I forgot, I'm so used to close them without reading the message...
Systemd and co broke so many many things and so often that it is hard to count. A lot of things possible before are not anymore because of this giant ball of mud. It is just like the Windows monolith now.
Is it totally bad, no, for sure there are some advantages , but nowadays you will have issues, like network issues such as the one you describe and people will not know it comes from that.
Actually, before you almost never had to reboot or reinstall for anything. In case of boot issues and co, you would just need a console to be able to fix it. Systemd got even advanced users to be used to reboot and reinstall in case of problem as deep issues are often unfixables.
+1. Some people just have zero standards. They apparently WANT to be abused.
Systemd is a giant pile of bugs. It's shitware.
systemd not SystemD idk why people got that in their head.
Because the name is a play on the French term Système D: https://en.wikipedia.org/wiki/System_D
> 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.
Systemd is basically the Windowsfication of Linux. I'm always surprised by the people that champion it who also used to shit on Windows with the registry or whatever.
Cognitive dissonance is a hell of a thing.
LFS seems to be for people who are interested in how things work. The systemd proponents come off as people who would question why you would want to to drive a manual transmission and say of course you should choose an automatic or better yet, a robot; self driving car. It would be interesting to see how those opinions line up with the uses of AI
I have owned many manual cars, but I'm fine with systemd on all my machines. Being a nerd about one thing doesn't require me to be a nerd about other things.
It is not cognitive dissonance to learn from others. The pluggable nature of Linux makes developer lifes harder. They have to write wrappers and abstractions to use base functionality. Having a unified api surface is very attractive.
Windows did something right because you can run very old binaries on a new system. Good luck doing that on Linux.
In the end for most people Linux is not an intellectual exercise in freedom but a tool to get work done and systemd is pretty good at that and is getting better.
And another important point: systemd is still lgpl licensed software. There is literally no legal way for someone to rug pull it. So if it works and brings a benefit it might be a good thing to start to depend on it. Just like we depend on the GNU tools.
> It is not cognitive dissonance to learn from others.
I didn't say it was. I said it was to attack one binary blob abstraction while embracing another.
> Windows did something right because you can run very old binaries on a new system. Good luck doing that on Linux.
I agree, but that's entirely irrelevant.
> systemd ... works and brings a benefit it might be a good thing to start to depend on it.
We have very different philosophies, you and I.
> I said it was to attack one binary blob abstraction while embracing another.
You didn't say that but even if you meant that systemd is an open source project and it has multiple components. It is not just a binary blob. It is a coherent framework for basic system services. It is pick and choose for the most part. Most distro choose to use all of it.
I still disagree that liking systemd and disliking windows is incompatible. Windows is a closed source project, developed without much external input that has a clear monetary incentives that are often user hostile. The way it's system api works is rarely the reason for criticizing it.
> You didn't say that
I didn't spell it out but it was the clear point I was making.
> systemd is an open source project and it has multiple components. It is not just a binary blob.
Missing the forest for the trees. It being open source is irrelivant here.
> I still disagree that liking systemd and disliking windows is incompatible.
I never said it was.
> The way it's system api works is rarely the reason for criticizing it.
I never said it was. You seem to be having an entirely different discussion.
If that is not what you are arguing than I honestly have no idea what your point is.
And I'm fine with that. Let's just leave it here. Cheers.
Pedantic but systemd is inspired by MacOS launchd, not by Windows services. It has nothing akin to the registry, which even microsoft admits is a pain on windows.
Oh, and usually people shit on windows for many reasons, but some of the very core features of the OS are robust and the Linux crowd could take a hint. Like, you know, the notion of service at the OS-level and not some random bash script that nohup'd a binary. Oh wait, that's what does Windows, MacOS and Linux with systemd.
I didn't say it was inspired by the registry, I just drew a comparison. In both cases you have a huge binary thing that you have to interact with through secondhand tools rather than directly.
systend units are plain text.
We generally aren't in the habit of using "random" scripts to do anything. They're usually carefully developed to do exactly what we need them to do, precisely, and nothing more. Not the giant pile of buggy ass code and security nightmare that is systemd.
By the way, you don't seem to be aware that you can use any language you want to create startup "scripts" including compiled binaries, if you hate shell scripting so much.
Do you even know any shell script? Serious question. Many 'bash' haters know nothing about the language--starting with calling it 'bash' instead of 'shell script.' There are several different flavors just of shell scripting languages, and bash is only one.
It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.
SysVinit has been seen by some people in the post-systemd world as some sort of mystifying mashup concocted by sadists, yet I've found that when it is explained well, it is clear and human-friendly, with easy uptake by newcomers. I echo that this decision is a pity.
It’s not just explaining but whether you have to support it on more than one distribution/version or handle edge cases. For a simple learning exercise, it can be easier to start with but even in the 90s it was notably behind, say, Windows NT 3 in a lot of ways which matter.
"When it's explained well" is the keyword
I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns
sysv is garbage tho. If unix philosophy is "make it do one thing and do it well", it doesn't do the one thing it is supposed to do well.
I dislike overloading systemd with tools that are not related to running services but systemd does the "run services" (and auxiliary stuff like "make sure mount service uses is up before it is started" or "restart it if it dies" and hundred other things that are very service or use-case specific) very, very well and I used maybe 4 different alternatives across last 20 years
I don't see how this relates to removing SysVinit support from LFS. Choice is good.
Are you entitled to the LFS developers time? They build the system they get to make into what they want.
That "choice" still has to be maintained. And why spend effort when you can do the same things + more with systemd?
Clearly there are lots of people who don't want something that does what you say systemd does. Bravo that choice is out there, but what a pity that LFS does not seem to have the resources to test future versions for SysVinit.
you can fork it and do it.
But frankly if goal is to learn people about how Linux works, having SysV there is opposite to that goal
I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)
While Xorg itself (which isn't a monolith, BTW) provides more than the bare minimum, so does the Linux kernel - or even the Unix/BSD kernels of old - yet programs that did follow to the Unix philosophy were built on top of them.
In X11/Xorg's case, a common example would be environments built off different window managers, panels, launchers, etc. In theory nothing prevents Wayland to have something similar but in practice 17 years after its initial release, there isn't anything like that (or at least nothing that people do use).
At least in my mind, the Unix philosophy isn't some sort of dogma, just something to try and strive for and a base (like X11) that enables others to do that doesn't go against it from the perspective of the system as a whole.
This one bothers me too.
Systemd and Xorg are very similar in many ways. I do not know how you hate Systemd and love Xorg unless your real problem is just change.
And, while I like Wayland, I think that liking the Wayland architecture should have you disliking Systemd. But that is just me.
I'm in the same boat. Systemd is an unpricipled mess and ships some quite shoddy replacements for pre-existing components. Wayland is super clean, it just takes for-everrr to add the features that users (and developers) expect. It could seriously have been done over 10 years ago not by heroic development effort, but by not being pathologically obstructive about features.
The two projects are complete opposites except in one way, they replace older stuff.
> but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)
It's been 17 years and Wayland has yet to reach feature parity with X11/Xorg. There is doubt that it ever will.
Regardless of what you think the Unix "philosophy" is, actual features matter.
But Wayland is a protocol suite, you're comparing it against Xorg, an implementation that shipped 16 years after X was created.
If you want to learn the system from scratch, the best way will be writing your own little init system from scratch, so you can understand how the boot sequence works. And as you make use of more and more of the advanced features of Linux, your init system will get more and more complex, and will start to resemble systemd.
If you only learn about sysvinit and stop there, you are missing large parts of how a modern Linux distro boots and manages services.
> and will start to resemble systemd
That's the point on which people differ. Even if we take as given that rc/svinit/runit/etc is not good enough (and I don't think that's been established), there are lots of directions you can go from there, with systemd just one of them.
And on the other hand, I have no sympathy for the Unix philosophy. I value results, not dogma, and managing servers with systemd is far more pleasant than managing servers with sysvinit was. When a tool improves my sysadmin life as much as systemd has, I couldn't care less if it violates some purity rule to do so.
> packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd
So drop them. There are other desktops that are faster, simpler, more stable, and aren't hard-coded to make Linux worse. Has everyone forgotten the design principles that made Linux good in the first place? Tightly coupling your software into other software is simply bad design. At some point you need to eat the cost of a looser abstraction to make your system less fragile, easier to reason about, and more compatible.
That's funny, I did LFS a few years ago and specifically chose the systemd version so I could better understand it. I don't think this is a huge deal, I believe the older versions of the document that include SysVinit will still be available for a long time to come, and people who want it will figure out how to muddle through. If at some point in the future things diverge to such a point where that that becomes untenable, someone will step up and document how it is to be accomplished.
Didn't you find though that systemd was just a black box? I was hoping to learn more about it as well- and I did manage to get a fully baked LFS CLI system up and running, and it was just like "ok install systemd..." and now... it just goes.
Sysv at least gave you a peak under the covers when you used it, and while it may have given people headaches and lacked some functionality, was IMHO simple to understand. Of course the entire spaghetti of scripts was hard to understand in terms of making sense of all the dependencies, but it felt a lot less like magic than systemd does.
> "ok install systemd..." and now... it just goes.
I believe it's `systemctl list-unit-files` to see all the config that's executed, included by the distro, and then if you want to see the whole hierarchy `systemd-analyze dot | dot -Tpng -o stuff.png`
To me, seems much easier to understand what's actually going on, and one of the benefits of config as data rather than config as scripts.
Yeah- but LFS didn't really expose you to that or really teach you much about Systemd internals. Here is the page on it: https://www.linuxfromscratch.org/lfs/view/systemd/chapter09/...
The only other page that covers it is how to compile it and it install it (make configure, make, make install essentially- with a bunch of flags).
It kind of touches upon a few commands that will let you know what its doing and how to get it started, but from this page you don't learn much about how it works.
In fact, one of my takeaways from LFS was that I already kind of knew how a linux system starts... and what I really wanted to learn was how the devices are discovered and configured upon startup to be used, and that is pretty much all done in the black box that is SystemD.
This decision means that no testing of SysVinit will be done in future LFS and BLFS versions. The onus will be on the experimenter each time, but my hope is that a body of advice and best practices will accumulate online in lieu of having a ''works out of the book'' SysVinit solution.
Modern mechanical engineers, to this day, learn the thermodynamics of steam engines. Not because they are living in the past, but because they are building foundation knowledge that will permeate everything they'll be doing in the future.
LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.
The world is vast, and I doubt that every mechanical engineer has studied steam engines, and that it makes a difference in the end.
Most modern programmers don't learn COBOL60 or Commodore BASIC. Modern mathematician very rarely study writings of Euler or Gauss; even 50 years old math books may be hard to grasp for modern students.
I agree that using a simpler tool for educational purpose is useful, but since SysVinit is obsoleted almost everywhere, it made sense to drop it. LFS could have chosen a simpler init than the domain standard, like runit or s6-init.
"Obsolete"? Apparently you aren't paying close attention.
See this GIANT argument with hundreds of comments? It seems some people believe that SysVinit is, in fact, not even close to obsolete.
If Gnome/KDE can't support the init system I choose to use, then I don't choose to use their garbage software anymore.
I was considering forking the base book and maintaining it, as I have kept an eye and occassionally built the project over the years (I use it a lot for package management/bootstrapping/cross compilation experiments), but it appears there already is one: https://lists.linuxfromscratch.org/sympa/arc/lfs-dev/2026-02...
I believe maintaining the base book is the most important part, BLFS has some really good hints but a very significant amount of packages have few differences, collecting these in a separate hints file or similar would help a bit, at least for things that don't hard-depend on systemd like gnome.
It's funny I did an LFS system of my own a couple of years ago which I coined "Head Rat" Linux.
I used the SVR4 packaging system from heirloom-pkgtools (using this of a Claude port of V4 unix to x86_64 as well at the moment) for fun, and compiled up CDE on top of this to boot. I wanted to see what Linux would look like if you dressed it up as much like SVR4 as possible. I liked the result actually. It was kind of like what Sun might have done if they dumped their own kernel and switched to Linux instead.
Originally it used SysVinit, and I started working getting systemd to work with it (because after several years I've come to appreciate it) - but that's the point I stopped working on Headrat - I realised if I wasn't adding SVR4 stuff and was removing it instead, it wouldn't be SVR4 enough.
I don't know how I feel about it - after all I could do an LFS straight out of my head these days without referring to the LFS docs - but I do feel there is something lost when as a Linux community, we try to shove the baggage under the rug and pretend that things like SysV init didn't play a massive part in Linux's rise throughout the 90's and 00's.
History is important, even if we don't like the code today and have more capable tools. But I guess SysV init is deader than dead at this point.
The saddest part of this isn't the technical debate. It's that a project whose entire reason for existence is to teach you how things work has concluded that one of the most fundamental components of the system is now too entangled with everything else to offer a choice. That's not a vindication of systemd or an indictment of it. It's an honest admission about what happened to the Linux ecosystem's composability over the last decade.
Exactly. Now, remember how everyone gaslit us into saying we'd always have a choice? We told you so.
LFS. Brings back so many painful memories. But then, learned so much.
Man. I'd really rather they did the inverse: drop systemd and only maintain the SysV versions of the materials, even if that means dropping GNOME/etc., because I think understanding the Linux init process is far more important than making any specific desktop environment available.
From a completely technical standpoint, is systemd really better than SysVInit? I ask this question in good faith. I have used both and had no problems with either, although for personal preference, I am more traditional and favor SysVInit.
I always dreaded trying to create a service with bash-based init scripts. Not only did it involve rolling a heck of a lot yourself (the thing you were running was generally expected to do the double-fork hack itself and otherwise do 'well behaved daemon' things), it varied significantly from distro to distro, and I was never confident I actually got it right (and indeed, I often saw cases where it had most definitely gone wrong). Whereas systemd has a pretty trivial interface for running most anything and having some confidence it'll actually work right (in part because it can actually enforce things, like actually killing every process that's part of a service instead of kind of hoping that killing whats in the PIDfile is sufficient).
> the thing you were running was generally expected to do the double-fork hack itself and otherwise do 'well behaved daemon' things
FreeBSD has a general utility that does this for you, daemon(8): https://man.freebsd.org/cgi/man.cgi?query=daemon&sektion=8
I also use it every time I need a service which should be restarted on crash. It's a very handy utility.
Is this really that hard to type?
https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
> Is this really that hard to type?
Your link is irrelevant. It points to OpenBSD which uses rc, not sysv. The 3 lines of this rc startup script use a file of 400 lines of shell with commands that don't exist in SysVinit.
With sysv, the difficulty depended on the local tools because the launching scripts could not be shared across Linux distributions. Debian used the compiled helper `start-stop-daemon` while Redhat did not.
With sysv, some sysadmin tasks require external tools. Try to write a launching script with a smart autorestart in case of crash. Make it work even when the daemon forks. Do not assume that the daemon writes its initial PID anywhere. IIRC, to get this feature, we had to drop sysv for runit, two decades ago. Now it's just 2 lines in a systemd unit.
Init and run control aren't the same thing. Which is part of what's nice about sysv (which, yes, OpenBSD's init is based on). OpenBSD's run control system is particularly nice, and it's the sort of thing you can use with an init system that isn't constantly eating everything.
Probably not, but it looks a hell of a lot harder to understand than a unit file.
Huh? Not even remotely
It's probably straightforward for someone who works with it. For a newb like me, it needs effort to understand. I think unit files are self-documenting and straightforward to understand the first time you see them.
One is not better than the other because they exist to solve different problems. Are sandals technically better than snowshoes?
Yes, much better. The original intro blog post goes into detail: https://0pointer.de/blog/projects/systemd.html
I hate it when a website assumes the language I'm speaking based on my IP. There is no apparent way to change it as well. It's just lazy and hostile design in my opinion.
Kind of related: The Great Debian Init Debate <https://aaonline.fr/search.php?search&criteria[sequenceId-is...>
So this will be the final SysVinit version https://www.linuxfromscratch.org/lfs/downloads/12.4/
>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
Do people who really uses LFS even want GNOME or KDE on their system ?
I would think people who use LFS are doing it for the learning experience and not necessarily for a daily driver OS.
Maybe? When I did LFS/BLFS I opted for an i3-gaps setup with a compositor and some other eye candy, and had a lot of fun tinkering. I suppose some folks might want the experience of building an entire DE from source, but that seems like a bit much.
I use Sway window manager and am more than happy to avoid those huge bloated Guiwares
Why not discontinue original coreutils and original sudo while we're at it?
I think you're joking but they will. Eventually stystemd will consume everything and that work has already begun, quite literally.
They absolutely will.
Even irony aside, there is no point in investing so much efforts in Rust slops without removal of the original tools.
This seems good? LFS isn't about building Linux the way Linux was built 40 years ago. It's about learning how to do today's Linux, from scratch. Steps that lead to a radically different build from most Linux distros are therefore off the mark, and not really educational to show how a modern Linux is built.
Lots of pearl clutching in here about it, tho
"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."
I remember LFS from way back in the day.
What do we all think the overlap between LFS users and Gnome or KDE users is? I think it's pretty small.
Has the entire industry converged on Systemd then
Almost. Not Alpine and a few others.
The UNIX cancer that is systemd has spread to LFS and kiled SysVinit.Sad
What does "support" mean
On 01 March 2026 the next versions of LFS and BLFS will not include SysVinit instructions a.k.a. ''support''.
Wow this is sad. If any distro keeps the old ways around it should be LFS or Slackware I would think. And maybe Gentoo.
I'm honestly worried about the forces pushing systemd in Linux spoiling the BSD ecosystem. And I'm worried that the BSDs do not have enough people to forge alternatives and will have to go along with the systemdification of everything. sigh
*Note, I ended up on Cachy, which is systemd, so I'm not some pure virtue signaler. I'm a dirty hypocrite :P
I ended linux from scratch support a long time ago. Well I did the right thing. Everything is systemd free on my side, for my own sake. This systemd is so much a "microsoft grade bad idea".
There is still interesting code patches here and there, and interesting info on brain damaged SDKs (gcc, glibc, etc).
Most of the time I remove the SDK itself, basically I write a linear and brutal shell script with fine grained control on the compiler/linker. I do push down to nearly remove completely the compiler driver (a spectacular failure) namely CPP->C->ASM->O.
I would like to move away from ELF too for a modern file format for dynamic libs and executable, but the "geniuses" using complex computer languages (mostly c++) for critical open source components make that a massive pain (runtime, ELF relocation requiring obsolete infrastructure, etc).
Just rename Linux to SystemD OS at this point..
Excuse me, that's GNU/SystemD/Linux.
You joke, but it's a decent comparison. Both GNU and SystemD are projects with a bunch of miscellaneous tools with excessively strong coupling. In GNU's case that's the various userland tools relying on glibc. Both are used in the majority of Linux distros, and while there are distros without them they're not particularly mainstream. Many tools expect their options & custom ways of working, e.g. huge numbers of shell scripts are BASH-specific and need GNU coreutils instead of being portable POSIX shell scripts. Both make developers' lives easier compared to the lowest-common-denominator required by POSIX, which makes sense because POSIX is intended to be a common subset of functionality found across different UNIX OSes.
It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.
Just call it the Red Hat Linux Platform. Both GNU (glibc, binutils, GNU utils, GCC, etc) and Systemd are primarily maintainted by them. Same with Wayland and GNOME.
Red Hat defines what "Linux" is these days.
systemd not SystemD
systemdick
I had stopped using linux at the start of the systemd takeover (it was not because of systemd).
What I don't understand is how this has happened. I didn't care either way but everybody who did seemed to really fucking hate systemd. Then how come it became the default in so many distributions, with so much opposition from the community?
Because most maintainers love it compared to Sys V scripts.
In the end, users might complain about purity of things or something but the mainteners are the ones doing the work maintaining all that and end up deciding what gets used.
Honestly, I'm rather outside of all that stuff and I had my share of problems with systemd issues but that's mostly because I've been using pretty old systems anyway with thus older and buggier versions of the code. And I also remember the pain it was before unit files to get those sys V scripts working correctly. From my perspective, both systems had weird bugs I had to track but systemd clearly wins on the "creating a new service" part.
M$ is pushing hard and not pushing alone
Commercial interests. Linux has benefited greatly from companies adopting it and paying developers but at the same time there has been a price to pay and this kind of thing is it.
Since it's all open source, I think we're reasonably ok because we don't HAVE to do what the commercial distros chose to do.
The problem is if we let it become too difficult. Personally I think a thing like DBUS is needed but dbus itself is undesirable as it adds another IPC type and has no connection to the filesystem or the BSD socket interface or any of the other standard ways that interfaces can be discovered and used. It has a network effect that is not easy to avoid without accepting degradation in the UI.
The more crap we end up accepting the more difficult it becomes to be a lone developer and the more the whole system will turn towards commercial interests and away from what it started out as.