Comment by cf100clunk

SysVInit on Linux isn’t true Unix though as the way it abuses runlevels to start daemons was never intended by the original designers of init.

systemd is most certainly the most pragmatic service to learn, but if you're doing LFS to "learn" how a Linux system gets brought up, something lower-level may be a better idea to pick up.

A project which is intended to be a learning experience in building a Unix variant (in this case, Linux) is a kinda right place for sticking to the Unix philosophy and design, for illustrative purposes.

Mr Pike has indeed constructed a better OS than Unix; too bad AT&T neither knew how to achieve viral popularity, nor why Free Software (as in GPL) is going to dominate the world. By about 1995, it was already too late. (Something similar happened to Inferno vs Java.)

Still, the Unix principles of modularity, composability, doing one thing well, and unified interfaces are widely considered very sane, and adopted.

I think the main problem of Unix today is that it's not Unix-style enough. Too many namespaces with too many non-composable separate APIs on them instead of "everything is a file". Plan9 is more Unix than Unix and that's indeed better. Redox OS, too.

The Unix security model is mostly useless today, but it seems like something better is possible as an incremental change, and there are projects that do that, like RSBAC.

And we've all heard of the linux people, as opposed to whoever is pushing these post-Cassidy OS. Linux isn't where it is because of some imperial decree, it has been winning out in a slow, protracted war for what OS programmers choose when they want to get work done.

Pike is more than entitled to an opinion, but I think there is some cause-effect reversal at work here. The linux circles aren't people driving the UNIX-love. The UNIX-love is effective in practice - especially the blend of principle and pragmatism that the linux community settled on - so the linux circles happen to be bigger than the most similar alternatives. Better alternatives are going to have to fight through the same slog as linux if they want recognition.

This is not about mindless worship, but about the fact that the UNIX design has stood the test of time for this long, and is still a solid base compared to most other operating systems. Sure, there are more modern designs that improve on security and capability (seL4/Genode/Sculpt, Fuchsia), but none are as usable or accessible as UNIX.

So when it comes to projects that teach the fundamentals of GNU/Linux, such as LFS, overwhelming the user with a large amount of user space complexity is counterproductive to that goal. I would argue that having GNOME and KDE in BLFS is largely unnecessary and distracting as well, but systemd is core to this issue. There are many other simpler alternatives to all of this software that would be more conducive to learning. Users can continue their journey with any mainstream distro if they want to get familiar with other tooling. LFS is not the right framework for building a distribution, nor should it cover all software in the ecosystem.

Compared to plan9, past its sell-by date. Compared to redhat poetteringware, I will continue to attend services.

> We really are using a 1970s era

1970 Anno Domini no less

>"All other components under the systemd project are optional and not required"

Name two major distros that use 'systemd init system' but doesn't use the other parts.

Same with systemd.

Hackers design hacker-friendly systems, which are easy to learn and extend. Corporation$ design ops-friendly systems, which are cheap to operate.

We need both.

I have been saying for years that Microsoft would eventually deprecate WinNT and switch Windows over to a Linux foundation. Things seem to be slowly but continually moving in that direction.

> I will soon be releasing a distro that is free of systemd, wayland, dbus, and other troublesome software.

What makes you decide that these are troublesome software's? Systemd is usually argued that it is monolithic and breaks the Unix paradigm.

But then you are going for X over Wayland? X is a monolithic application that breaks the Unix paradigms.

Are you just picking things because they are old, or is there a reason you decided to go with this setup?

How did you get GTK3/4 to work without dbus?

So, devuan?

Learn about what stuff? Linux? System V UNIX?

I haven't done LFS since my tweens (and I'm almost 30 now), but I remember the sysvinit portion amounted to, past building and installing the init binary, downloading and extracting a bunch of shell scripts into the target directory and following some instructions for creating the right symlinks.

Obviously, you can go and check out the init scripts (or any other individual part of LFS) as closely as you wish, and it is easier to "see" than systemd. But I strongly protest that sysvinit is either "Linux" (in that it constitutes a critical part of "understanding Linux" nor that it's really that understandable.

But setting aside all of that, and even setting aside the practical reasons given (maintenance burden), when the majority of "Linux" in the wild is based on systemd, if one wanted to do "Linux From Scratch" and get an idea of how an OS like Debian or Fedora works, you would want to build and install systemd from source.

"best" meaning the best decision the LFS team can make given their limited, unpaid time and resources. They feel maintaining guides for two parallel init systems is unsustainable even though they would prefer not to have systemd as the only option.

Well to be fair, you don't need to understand how SystemD is built to know how to use it. Unit files are pretty easy to wrap your head around, it took me a while to adjust but I dig it now.

To make an analogy: another part of LFS is building a compiler toolchain. You don't need to understand GCC internals to know how to do that.

he is counting every c file in the systemd _repository_ which houses multiple projects, libraries and daemons. he equates that to the c file count for a single init. it's a disingenuous comparison. systemd-init is a small slice of the code in the systemd repository.

Or to put it another way, systemd has grown to become so large and complex it's like a kernel unto itself.

I can absolutely say that I've never had a showstopping problem with sysv. That is about 30 years as a unix & linux admin and developer.

The whole point of sysv is the components are too small and too simple to make it possible for "showstoppers". Each component, including init, does so little that there is no room for it to do something wrong that you as the end user at run-time don't have the final power to both diagnose and address. And to do so in a approximately infinite different ways that the original authors never had to try to think up and account for ahead of time.

You have god power to see into the workings, and modify them, 50 years later in some crazy new context that the original authors never imagined. Which is exactly why they did it that way, not by accident nor because it was cave man times and they would invent fancier wheels later.

You're tired of hearing complaints? People still complain because the problem did not go away. I'm tired of still having to live with the fact that all the major distros bought in to this crap and by now a lot of individual packages don't even pretend to support any other option, and my choices are now to eat this crap or go off and live in some totally unsupported hut in the wilderness.

You can just go on suffering the intolerable boring complaints as far as I'm concerned until you grow some consideration for anyone else to earn some for yourself.

Equally tiring is the “it works for me so stop complaining” replies, which do nothing to stop the complaints but do increase the probability of arguments. Want the complaint posts to stop? Suggesting that they’re in some way invalid is not the way.

Imagine that, people on the internet disagreeing. I've had both sysv and sysd crap in my cheerios. The thing I appreciated about sysv was that it stayed in its lane and didn't want to keep branching out into new parts of the system. Sysvinit never proposed something like homed.

My experience, and the common experience I’ve read, is the exact opposite. Run scripts worked. They always worked. They were simple. I’ve run into so many difficulties with systemd, on the other hand. I gave up managing my own server as a result.

I understand where you’re coming from but early systemd with both ubuntu and centos was a fucking mess. It’s good now but goddamn it was painful and the hate is 100% justified.

> Not once in my career have I experienced a showstopping issue with systemd.

Like clockwork, we'd have a SystemD edge case cause a production-down incident at a (single!) customer site once per year. Inevitably, we'd burn anywhere from a half day to a week attempting to figure out WTF, and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither.

The project is full of accidental complexity that its maintainers can't be bothered to fix when unplanned interactions cause problems and are brought to their attention. I certainly don't blame them; that sort of work is only interesting to a very specific sort of personality, and that sort of personality doesn't tend to thrive in a typical software company.

I can also absolutely say that I've never had a showstopping problem with OpenRC in the nearly twenty-five years I've been using it. It's remarkable how reliable it is.

> Not once in my career have I experienced a showstopping issue with systemd. I cannot say the same for sysV.

I have had both ruin days for me. In particular the "hold down" when it detects service flapping has caused issues in both.

I use runit now. It's been rock solid on dozens of systems for more than a decade.

OP here. I was hoping we could avoid the interminable, infernal discussion of systemd vis-a-vis emotional states.

What about Windows hate is so old and tiresome now?

I need my system to work!

From an education standpoint for those who really, really want to understand, the *BSD init and SysVinit systems require direct human administration. You break it, you fix it. Then, and only then, does learning systemd's ''then something happens behind the curtain'' type of automation make sense. If the student decides that one is more suitable than the other(s), they've done so from an enlightened vantage point.