''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.
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:
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 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.
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
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. I'm getting Left Behind here.) The main thing holding me back is compile speed, especially doing work on Chromium and WebKit.
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. (Amazing how cheap this stuff is.)
A better video card would be nice 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.
EDIT: Very interested in ppc64 gear too. Anyone got an old POWER8 or POWER9 system laying around? 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.
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.)
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.
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.
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.
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.
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.
> 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.
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?
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.
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).
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.
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 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.
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)
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.
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.
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.
>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.
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.
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.
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.
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).
> 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.
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.
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'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.
> 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
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.
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.
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.
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 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.
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.
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?
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).
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.
> 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 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.
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.
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.
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%.
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.
> 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.
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"?
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.
> 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.
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.
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.
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.
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).
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.
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
"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.
> 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.
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.
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.
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.
[OP] cf100clunk | 12 hours ago
''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.''
clintfred | 11 hours ago
its_magic | 10 hours ago
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
ripdog | 9 hours ago
its_magic | 9 hours ago
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.
M95D | 9 hours ago
its_magic | 9 hours ago
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.
M95D | 9 hours ago
its_magic | 9 hours ago
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.
its_magic | 5 hours ago
Some of these User Agents have to be fake. Android 6.0.1 with Chrome 144, really? lol
its_magic | 3 hours ago
This fella would like to have a word with you:
https://www.youtube.com/watch?v=XfELJU1mRMg
fouc | 2 hours ago
its_magic | an hour ago
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. I'm getting Left Behind here.) The main thing holding me back is compile speed, especially doing work on Chromium and WebKit.
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. (Amazing how cheap this stuff is.)
A better video card would be nice 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.
EDIT: Very interested in ppc64 gear too. Anyone got an old POWER8 or POWER9 system laying around? 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.
adastra22 | 9 hours ago
spijdar | 9 hours ago
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.
adastra22 | 8 hours ago
Doing it via systemd is like drawing a big black box, writing LINUX on the side, and calling it a day.
rcxdude | 4 hours ago
spijdar | 3 hours ago
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.
csb6 | 8 hours ago
its_magic | 5 hours ago
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.)
soldoutcold | 11 hours ago
procone | 11 hours ago
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.
themafia | 11 hours ago
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] cf100clunk | 11 hours ago
mirashii | 11 hours ago
user3939382 | 10 hours ago
lagniappe | 11 hours ago
chucky_z | 10 hours ago
fragmede | 10 hours ago
Brian_K_White | 10 hours ago
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.
adastra22 | 9 hours ago
simoncion | 2 hours ago
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.
BrouteMinou | 2 hours ago
I need my system to work!
molticrystal | 11 hours ago
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.
[OP] cf100clunk | 11 hours ago
fragmede | 10 hours ago
[OP] cf100clunk | 7 hours ago
raggi | 11 hours ago
[OP] cf100clunk | 11 hours ago
raggi | 11 hours ago
[OP] cf100clunk | 10 hours ago
rcxdude | 4 hours ago
simoncion | 2 hours ago
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.
simoncion | 3 hours ago
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).cientifico | 11 hours ago
If the project is even split in different parts that you need to understand... already makes the point.
ktm5j | 10 hours ago
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.
josephg | 9 hours ago
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
ktm5j | 9 hours ago
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.
josephg | 7 hours ago
ktm5j | 7 hours ago
They still explain what an init system is for and how to use it.
adastra22 | 9 hours ago
nine_k | 10 hours ago
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.
binkHN | 9 hours ago
p_ing | 9 hours ago
It's more like Windows! /duck
its_magic | 9 hours ago
p_ing | 9 hours ago
The Win32 layer is the issue, not the underbelly.
its_magic | 3 hours ago
I'd be open to the idea, if the kernel were open sourced (MIT licensed?) so I could play with it too.
p_ing | 2 hours ago
We’ve already had NT + Linux userland; that was WSLv1.
its_magic | an hour ago
anon7000 | 2 hours ago
1vuio0pswjnm7 | 12 hours ago
[OP] cf100clunk | 12 hours ago
smartmic | 11 hours ago
[OP] cf100clunk | 11 hours ago
raverbashing | 11 hours ago
I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns
acdha | 10 hours ago
PunchyHamster | 11 hours ago
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
[OP] cf100clunk | 11 hours ago
preisschild | 11 hours ago
[OP] cf100clunk | 10 hours ago
PunchyHamster | 10 hours ago
But frankly if goal is to learn people about how Linux works, having SysV there is opposite to that goal
reppap | 10 hours ago
tapoxi | 11 hours ago
LeFantome | 3 hours ago
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.
ahartmetz | an hour ago
The two projects are complete opposites except in one way, they replace older stuff.
bigstrat2003 | 11 hours ago
nialv7 | 10 hours ago
If you only learn about sysvinit and stop there, you are missing large parts of how a modern Linux distro boots and manages services.
wiml | 10 hours ago
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.
jmclnx | 11 hours ago
Do people who really uses LFS even want GNOME or KDE on their system ?
[OP] cf100clunk | 11 hours ago
spudlyo | 11 hours ago
spudlyo | 11 hours ago
[OP] cf100clunk | 11 hours ago
kevstev | 11 hours ago
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.
nomel | 9 hours ago
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.
kevstev | 6 hours ago
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.
abhisek | 11 hours ago
eikenberry | 11 hours ago
[OP] cf100clunk | 11 hours ago
onraglanroad | 10 hours ago
What a horrific thought.
[OP] cf100clunk | 10 hours ago
nine_k | 10 hours ago
[OP] cf100clunk | 10 hours ago
nine_k | 10 hours ago
ktm5j | 10 hours ago
> 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.
dTal | 5 hours ago
simoncion | 2 hours ago
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.
jdub | 2 hours ago
acdha | 10 hours ago
simoncion | 2 hours ago
kmeisthax | 2 hours ago
On a related note, X11 was never good and there's a whole chapter in the UNIX-HATERS Handbook explaining why.
JCattheATM | 11 hours ago
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.
um1 | 3 hours ago
haunter | 11 hours ago
antonyh | 11 hours ago
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.
cmrdporcupine | 11 hours ago
It apparently uses SysVInit
antonyh | 11 hours ago
raggi | 11 hours ago
[OP] cf100clunk | 11 hours ago
frumplestlatz | 11 hours ago
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.
tokyobreakfast | 11 hours ago
tokyobreakfast | 11 hours ago
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.
bryanlarsen | 10 hours ago
For example, not all distros ship and use systemd-resolved by default, to choose from your list.
bsimpson | 10 hours ago
5G_activated | 10 hours ago
fragmede | 10 hours ago
bryanlarsen | 8 hours ago
Foxboron | 8 hours ago
But, who is counting?
5G_activated | 8 hours ago
bryanlarsen | 7 hours ago
hparadiz | 11 hours ago
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.
simoncion | 2 hours ago
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).
Fwirt | 10 hours ago
josteink | 10 hours ago
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.
Timon3 | 9 hours ago
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
josteink | 8 hours ago
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.
LeFantome | 3 hours ago
The number one goal for the Xwayland / Xorg devs is stability. Breaking ABI compatibility is a pretty big problem if stability is your goal.
LeFantome | 3 hours ago
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.
razighter777 | 10 hours ago
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.
cyberax | 10 hours ago
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.
nomel | 10 hours ago
cyberax | 9 hours ago
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.
nomel | 9 hours ago
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%.
cyberax | 8 hours ago
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.
dTal | 5 hours ago
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.
simoncion | an hour ago
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.
jdub | 2 hours ago
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?
simoncion | an hour ago
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.cyberax | an hour ago
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."
jdub | 8 minutes ago
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.
rendaw | an hour ago
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.
SockThief | 11 hours ago
WhereIsTheTruth | 11 hours ago
mhurron | 9 hours ago
SAI_Peregrinus | 8 hours ago
It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.
LeFantome | 3 hours ago
Red Hat defines what "Linux" is these days.
jvreeland | an hour ago
byte_0 | 11 hours ago
rcxdude | 10 hours ago
bandrami | an hour ago
https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
IshKebab | 10 hours ago
0xbadcafebee | 9 hours ago
mid-kid | 10 hours ago
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.
wormius | 10 hours ago
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
ErroneousBosh | 10 hours ago
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.
0xbadcafebee | 9 hours ago
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.
greatgib | 9 hours ago
LeFantome | 3 hours ago
jvreeland | an hour ago
tmtvl | 9 hours ago
cjk | 6 hours ago
sxzygz | 2 hours ago
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.