Live data from Hacker News

Linux From Scratch ends SysVinit support

lists.linuxfromscratch.org

331–340 of 416 posts

Re: Linux From Scratch ends SysVinit support

#331
post #233

Earlier quoted context omitted.

I think if we're talking about "what everyone wants", Windows 11 obviously isn't it, so that's not necessarily the driving force here.

As I said, everyone wants Win32. What flavor is up to debate, everyone has their own incorrect opinions.

It would be much unlike Microsoft if they didn't bring Win32/Win64 compatibility along for the ride somehow, and very stupid also, because as you say that is the real core of Windows in a lot of ways.

I have no idea what they're planning or why, just guessing, as they seem to be bringing Linux and Windows closer together all the time.

Re: Linux From Scratch ends SysVinit support

#332
post #169

Earlier quoted context omitted.

> How do we determine that a specific instance of a filesystem mount is "remote", or even requires a "network"? Like systemd authors do! Hard-code the list of them in the kernel, including support for fuse and sshfs. Everything else is pure blasphemy and should be avoided. Me? I'd have an explicit setting in the mount unit file, with defaults inferred from the device type. I would also make sure to not just randomly…

Sounds like your admin, distro, or the systemd team could pay some attention to systemd-update-done.service The "can only be used in /etc/fstab" systemd settings are essentially workarounds to do those things via fstab (and workaround fstab related issues) rather than depend on other systemd facilities (c.f. systemd-gpt-auto-generator). From a "what can you do in /etc/fstab without knowing systemd is working behind t…

This service is the standard part of systemd. And my distro is a bog-standard Fedora, with only iSCSI as a complication.

Are you surprised that such a service exists? I certainly was. And doubly so because it has unusual dependency requirements that can easily lead to deadlocks. And yes, this is known, there are open issues, and they are ignored.

> From a "what can you do in /etc/fstab without knowing systemd is working behind the scenes" point of view, then yes, systemd units are vastly more configurable.

No, they are not. In my case, I had to use fstab to be able to specify a retry policy for mount units (SMB shares) because it's intentionally not exposed.

And yes, there's a bug: https://github.com/systemd/systemd/issues/4468 with the expected GTFO resolution: https://github.com/systemd/systemd/issues/4468#issuecomment-...

So there's literally functionality that has been requested by people and it's available only through fstab.

Re: Linux From Scratch ends SysVinit support

#333
post #186

Earlier quoted context omitted.

> Sure, and systemd would translate that directly into a dependency on network startup... You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable: In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown w…

It's so refreshing to discover that the "I found one bug in systemd which invalidates everything" pattern continues in the year of our lord 2026.

I saw many corner cases in systemd over the years. And to echo the other poster in this thread, they typically are known, have Github issues, and are either ignored or have a LOLNO resolution.

And I'm not a systemd hater. I very much prefer it to the sysv mess that existed before. The core systemd project is solid. But there is no overall vision, and the scope creep resulted in a Cthulhu-like mess that is crashing under its own weight.

Re: Linux From Scratch ends SysVinit support

#334
post #79

Earlier quoted context omitted.

Ohh... I have sooooo many issues with systemd. The core systemd is fine, and the ideas behind it are sound. But it lacks any consistency. It's not a cohesive project with a vision, it's a collection of tools without any overarching idea. This is reflected in its documentation, it's an OK reference manual, but go on and try to build a full picture of system startup. To give you concrete examples: 1. Systemd has mount…

I love systemd, but you've hit on one of my biggest complaints. The mounting promises a cohesive system and instead gives you a completely broken mess, with mounts being split across .mount unit files, fstab, and worst of all, .service unit files. It's a totally incoherent mess, and that's only _after_ you figure out why nothing is working right, and build a complex mental model of every single feature that does or d…

And don't forget automounts! They are so much fun!

Re: Linux From Scratch ends SysVinit support

#335
post #186

Earlier quoted context omitted.

> Sure, and systemd would translate that directly into a dependency on network startup... You'd think so, but the Github Issue linked by GP shows that the machinery is unreliable: In practice, adding `_netdev` does not always force systemd to [consider the mount unit a network mount], in some instances even showing *both* local and remote ordering. ... This can ultimately result in dependency cycles during shutdown w…

It's so refreshing to discover that the "I found one bug in systemd which invalidates everything" pattern continues in the year of our lord 2026.

> "I found one bug in systemd which invalidates everything"

I'll refer back to the story of Van Halen's "no brown M&Ms" contract term and the reason for the existence of that term and ones like it.

"Documented features should be reasonably well-documented, work as documented, and deviations from the documentation should either be fixed or documented in detail." is my "no brown M&Ms" for critical infrastructure software. In my professional experience, the managers of SystemD are often disinterested in either documenting or fixing subtle bugs like the one GP linked to. I find that to be unacceptable for critical infrastructure software, and its presence to be indicative of large, systemic problems with that software and how work on it is managed.

I really wish SystemD was well-managed, but it simply isn't. It's a huge project that doesn't get anywhere near the level of care and giveashit it requires.

Re: Linux From Scratch ends SysVinit support

#336

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

SysVInit is abusing runlevel scripts for starting daemons which has always been a hack to be able to resolve dependencies between daemons. Learning Linux or Unix from scratch shouldn’t include using crude hacks.

I'm with you on this. SysVinit is better than systemd, but far from perfect. I don't enjoy tediously maintaining all of those symlinks, and prefer the BSD approach myself.

One project on my distro is a new init that will be much, much simpler than SysV, more like BSD and without all the years of cruft.

Re: Linux From Scratch ends SysVinit support

#337

Earlier quoted context omitted.

Yes and much of it is sealed off and proprietary. The bsd oses got MacOS for all their hard work, a closed off system that they can't read or port back anything from. Someone would say linux or gpl projects also have been fucked over this way. I suppose if your house has been burgled, such a person would argue we must remove all protections rather than add more.

MIT et al are winning over GPL for a reason. I'm not a big corporation. I prefer MIT, or better yet, public domain.

Are they winning as in more people are picking the license or are they winning as in we are getting a overall more enriched foss community?

I don't understand why people have such difficulties with the Golden Rule, sounds a simple and fair enough concept.

Re: Linux From Scratch ends SysVinit support

#338
post #126

Earlier quoted context omitted.

No, its not the end of the world. And I agree, LFS isn't going to be the best resource for learning how a compiler works or cron or ntp. But the init process & systemd is so core to linux. I can certainly see the argument that they should be part of the "from scratch" parts.

You still build it from scratch (meaning you compile from source).. they don't dive into Linux code internals either. They still explain what an init system is for and how to use it.

The problem is ultimately that by choosing one, the other gets left out. So whatever is left out just has one more nail in its coffin. With LFS being the "more or less official how-to guide of building a Linux system", therefore sysvinit is now essentially "officially" deprecated by Linux. This is what is upsetting people here.

I'm OK with that in the end because my system is a better LFS anyhow. The only part that bothers me is that the change was made with reservations, rather than him saying no and putting his foot down, insisting that sysvinit stay in regardless of Gnome/KDE. But I do understand the desire to get away from having to maintain two separate versions of the book.

Ultimately I just have to part ways with LFS for good, sadly. I'm thankful for these people teaching me how to build a Linux system. It would have been 100x harder trying to do it without them.

Re: Linux From Scratch ends SysVinit support

#339

Earlier quoted context omitted.

> 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 fi…

> and end up in some Github Issue where Systemd Project heavyweights go "Wow. Yeah, that looks bad. Maybe we should document it. Or fix it? IDK." and they'd do neither. Do you have a reference? Not that I don't believe you, but I hated this behaviour from Poettering (although he seemed to more often blame the user) and we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges a…

I'm afraid I don't have a reference. The combination of the facts that the bugs are always damn obscure, there are so many Github Issues filed against systemd/systemd, $DAYJOB keeps me so busy with a huge variety of tasks, and the inappropriate lack of giveashit demonstrated by the project maintainers made me so angry means that the details just get blown out of my head.

> ...we should totally raise up issue like this. It's a mature product that shouldn't have sharp edges any more.

To whom would these issues be raised to? Based on my personal and professional experience, the SystemD maintainers (and -for those who are paid to work on the project- those who manage them) seem to disagree that "eliminating sharp edges" is a big priority!

Re: Linux From Scratch ends SysVinit support

#340
post #179

Earlier quoted context omitted.

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 di…

The original authors went on to design Plan 9 and Inferno, and did not in any means consider UNIX perfect. Also Linux is trailing here Solaris, OS X, Aix,...

Your points are well taken. Linux is far from perfect and people shouldn't worship it. sysvinit is inferior to BSD init in my view and there are other questionable design decisions.

The biggest problem is that people are being railroaded into one thing or the other by the strong arm of corporations instead of being given options. My system helps with that.

I won't support systemd/wayland/etc, but others easily can add that in to their version of the distro if they like and support it themselves without too much work, as it's designed to be forked by anyone.

Post reply on HN