Linux From Scratch ends SysVinit support
lists.linuxfromscratch.org
lists.linuxfromscratch.org
''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 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
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.
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.
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.
Some of these User Agents have to be fake. Android 6.0.1 with Chrome 144, really? lol
This fella would like to have a word with you:
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.
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.
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.
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.
I guess there are alternative "forks" like QtWebEngine that just try to bring in only the blink engine part.
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?
(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.
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)
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 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.
Doing it via systemd is like drawing a big black box, writing LINUX on the side, and calling it a day.
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.
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 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 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.
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.
Also Linux is trailing here Solaris, OS X, Aix,...
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.
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.
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.
> ...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!
I need my system to work!
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.
I have read the first couple pages of these results. Would like you like to highlight one of these in particular?
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.
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.
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.
If the project is even split in different parts that you need to understand... already makes the point.
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.
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:
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.
They still explain what an init system is for and how to use it.
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.
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.
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.
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
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.
I am very sorry to inform you but efivarfs is something coming from the Linux kernel. Being able to rm -rf it is squarely something that is entirely on the kernel implementation, WHICH THE AUTHOR OF EFIVARFS EVEN ADMITS[0]
#facepalm
It's more like Windows! /duck
The Win32 layer is the issue, not the underbelly.
I'd be open to the idea, if the kernel were open sourced (MIT licensed?) so I could play with it too.
We’ve already had NT + Linux userland; that was WSLv1.
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.
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!
Theoretical or aesthetic advantages are no guarantee that the software in question will actually be superior in practice.
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.
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.
Don't get me wrong, NT also has its share of questionable design decisions. However overall the technical design of the kernel is great.
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.
Though it seems to be sneaking in through application space on a WinNT foundation
We need both.
Both can devolve into empire building. We need both to be transparent and open.
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.
1970 Anno Domini no less
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.
I'm not a big corporation. I prefer MIT, or better yet, public domain.
I don't understand why people have such difficulties with the Golden Rule, sounds a simple and fair enough concept.
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.
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.
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.
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.
"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.
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.
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.
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.
Such as money from M$?
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.
I know there are strong opinions on this, but isn’t systemd part of the core of most Linux desktops nowadays?
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.
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.
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.)
Or the Linux distros used by NVidia.
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.
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.
So is UNIX design only great when it serves the message?
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.
Time flies fast, faster than recycled arguments. :)
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.)
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.
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.
Aside of that, plan9 wins on the theoretical side, it was a research OS, but in the practical one... it's opinionated.
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.
That's how vendor lock-in works, in which a myth is propagated that having it all come from under one roof is best. In fact, it is a guarantee that best-of-breed alternative solutions cannot be used. Interoperability is thwarted. This is why sensible Unix admins historically knew to keep options open for mixed-vendor sourcing as long as the bosses didn't get roped in to a single vendor or source.
Think about it, you can't obligate the systemd folks to maintain codebases that aren't theirs.. would be madness.
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.
Name two major distros that use 'systemd init system' but doesn't use the other parts.
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.
If the intention is to create a system that users can reason about, then sysvinit offers the worst of all possible worlds.
Run levels. That's it, sysvinit is about run levels. Each run level starts or kills off its own specific list of runnable things like applications, daemons, capabilities, etc.
Run levels were a desirable feature back in the day amongst System V Unix vendors, so each run level required its own kill and start scripts for each item. Run levels, for example, could take a running system from single user (root admin) mode to multi-user, multi-login, NFS sharing, full X11 mode in one command immediately as the scripts ran. This allowed rapid reconfiguration of a system, such as from a GIS workstation to a headless file server, etc. etc. as needed. Each system could be configured to boot to a specific run level. Rather than duplicate some or all such scripts across some or all run levels, symlinks were the solution.
For example, Solaris had run levels 0 through 6. Zero was a blunt force system halt; 1 was single root user admin mode; 2 was multi-user headless mode with NFS; 3 was multi-user X11 windows mode with NFS; 4 was unspecified and therefore kept for purely local configuration as desired; 5 was a planned, orderly system shutdown; and 6 was a planned, orderly system reboot. The root user could implement their choice of run level directly with the init command.
Each run level had its own run control directory (rc.d) under /etc/rc.d for its appropriate kill and start scripts, which were run in order of their K or S number, so dependencies had to be kept in mind when numbering, and curing a dependency failure was as simple as changing a script's number to rearrange the list. So, why copy S04blahblah from rc2.d to rc3.d when a symlink is far better?
Its not hard to understand when you get the big picture, and it wasn't hard to administer if you had the proper overview of it all. Admittedly, admins coming in cold would have to sort through it all, which is partly why it gained a reputation for murkiness when not properly documented by/for local admins. Keep in mind it was the era of administering sendmail macros and NIS tables by hand and you get the picture.
NOTE: edited for clarity
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'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.
Learning Linux or Unix from scratch shouldn’t include using crude hacks.
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 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.
I needed a way to avoid going to campus and fight for a DG/UX terminal.
It had nothing to do with FOSS fighting.
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!
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...
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.
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".
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.
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 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.
site: killthe.net
name: dave
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.
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?
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.
It apparently uses SysVInit
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.
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.
For example, not all distros ship and use systemd-resolved by default, to choose from your list.
But, who is counting?
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.)
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.
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.
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.
#!/sbin/openrc-run
command="/usr/bin/rsync"
command_args="--daemon ${RSYNC_OPTS}"
pidfile="/var/run/${SVCNAME}.pid"
depend() {
use net
}
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).
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
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
}
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.
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?
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...>
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;
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.
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
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.)
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>
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.
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
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.
The number one goal for the Xwayland / Xorg devs is stability. Breaking ABI compatibility is a pretty big problem if stability is your goal.
But of course that would destroy the narrative.
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.
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 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.
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.
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.
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 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.
"Sweet dreams are made of this..."
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?
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).
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.
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.
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.
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'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.
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."
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.
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.
I hate mounts in systemd.
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.
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 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.
> 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.
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.
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.
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.
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.
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.
If yes, that's yet another init system not made for application writers.
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.
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
Completely wrong and ignorant.
> 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 then they got systemd. LOL
Like Dr. Phil said, "How's that workin out for ya?" LOL
> And so when something new came up, they jumped on it with both feet.
You just did what your type always does: whatever you're told.
> It's instructive to read Debian CTTE discussion on init systems
No, it really isn't. lol
> the choices were either upstart and systemd. And between two of those, systemd is a clear win.
Well, it's too bad none of the other good options were considered, isn't it? When your only "options" are a giant douche or a turd sandwich, the outcome can't possibly be good.
See U.S. presidential elections for one of the best examples of this dynamic. Two complete fucking losers are presented every time, and 40% of the population are mesmerized by the spectacle and think there can be no other possible options at all. That's you.
The fact is, many of you noobs don't even know how to write a shell script, yet somehow feel qualified to comment on this subject, as if your opinion is worth anything at all.
How many daemons have you personally written? Hmm? Do you even know how to write any C at all? Daemonizing a process isn't rocket science. It's a double fork. So simple even you could do it, I bet.
The problem is you're too technically ignorant to understand that none of your "technical" arguments hold any water at all. It's just you repeating the bullshit you were told, as usual.
Every Big Lie being told relies on Useful Idiots like you to help support it.
Logging is not difficult. Double forking is not difficult. If you find any of that to be a challenge, you're not qualified to write a daemon. If you can't successfully set up and run something like runit or any of the many other good sysvinit alternatives, you're not qualified to administer a Linux system. Period.
You make all these appeals to authority ("highly technical people" saying this or that) like that means something. You forget that you're speaking to the guy who built his own operating system. I don't need any guidance from "highly technical people" on what init system to pick. Apparently you're the type who does.
That's what your entire argument basically boils down to--one giant appeal to authority.
If everyone else was jumping off a bridge, would you do it too? Of course you would, without a moment's hesitation. Because you're a God damned lemming.
Now get off my lawn.
Not at all, and I'm not sure why so many people have this perception. It's never been this way. LFS is the tutorial you follow to get a full GNU/Linux system. In LFS, not having a base that can theoretically support the latest desktop environments is considered a fatal bug. It's just a conventional distro but in document format.
This is good for its comprehensiveness and as a way of documenting what existing Linux distros are doing, but it limits its utility as a learning aid as well as for embedded development. Most people interested in barebones Linux should instead start with a kernel and busybox and ignore most GNU packages.
What a horrific thought.
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.
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.
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"
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.
Someone should probably save the required source package versions (and patches) before they disappear though
On a related note, X11 was never good and there's a whole chapter in the UNIX-HATERS Handbook explaining why.
When will Wayland earn the label "good"? I don't think it currently qualifies.
1. You're using X11 with hardware that is fantastically newer than anything available at the time the UNIX-HATERS Handbook was written.
2. Every graphics vendor that still supports X11 is shipping workarounds for bugs in Xorg.
I used to have a citation for that second one but it went away when Hector Martin dropped off the face of the Internet.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
I'm not a systemD fan but SysV is not without its quirks and weirdness and foot guns
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
But frankly if goal is to learn people about how Linux works, having SysV there is opposite to that goal
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.
The two projects are complete opposites except in one way, they replace older stuff.
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.
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.
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.
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.
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.
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.
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.
LFS should stick to academic pedagogy, instead of trying to compete in the Linux Distro space.
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.
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.
Do people who really uses LFS even want GNOME or KDE on their system ?
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.
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.
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).
https://github.com/openbsd/src/blob/master/etc/rc.d/watchdog...
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.
FreeBSD has a general utility that does this for you, daemon(8): https://man.freebsd.org/cgi/man.cgi?query=daemon&sektion=8
Even irony aside, there is no point in investing so much efforts in Rust slops without removal of the original tools.
Lots of pearl clutching in here about it, tho
It's not a perfect equivalence, of course, SystemD diverges more from other UNIXes than GNU does.
Red Hat defines what "Linux" is these days.
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
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?
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.
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.