Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux From Scratch ends SysVinit support

lists.linuxfromscratch.org

Post reply on HN
Print view View original

341–350 of 416 posts

Re: Linux From Scratch ends SysVinit support

#341

Post by ktm5j »

its_magic wrote: post #338
ktm5j wrote: post #126

Earlier quoted context omitted.

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

Linux is just a kernel, that does not ship with any sort of init system.. so I don't see how anything is being deprecated by Linux.

The LFS project is free to make any decisions that they want about what packages they're going to include in their docs. If anyone is truly that upset about this then they should volunteer their time to the project instead of commenting here about what they think the project should do IMO.

Re: Linux From Scratch ends SysVinit support

#342

Post by its_magic »

fragmede wrote: post #83
cf100clunk wrote: post #34

Earlier quoted context omitted.

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

I thought systemd was fairly straightforwards, even if it does too many different things for my tastes. What's an example of it doing a too much magic behind the curtain thing?

Here's an example:

When I was building the initial version of my distro starting from a Linux Mint computer, one time I accidentally double-mounted the virtual filesystems (/tmp, /run, /proc, etc), on the target volume as my script was too primitive and didn't check the mounts first.

Exactly 60 seconds later, the whole system crashed.

Later I accidentally did this again, except this time immediately caught the problem and undid it. No matter--systemd still crashed 60 seconds later anyhow.

Or like the bug that was revealed a while back where the firmware EEPROM was writable by default in /sys or wherever it was, resulting in somebody's firmware getting overwritten and the system bricked. lol

That's the systemd life for you, in a nutshell. That sort of thing times a thousand. Not all at once, mind you--it will just take a nibble out of you here and there on and off until the end of time. After a while it will straight up fuck you, guaranteed. Which is exactly what it was designed to do.

Same with anything "Linux Puttering" touches. The guy who is now officially a Microsoft employee, as people were saying he really was all along.

Re: Linux From Scratch ends SysVinit support

#343

Post by its_magic »

palata wrote: post #300
ondra wrote: post #289

Earlier quoted context omitted.

> Developers don't have to package their project for all distros Essentially nobody uses the sources we provide. Literally nobody packages them. A few people use our rpm and deb packages, but the vast majority uses a (slightly broken and outdated) docker image built by third party. You might not like it, and I certainly do not, but unfortunately containers seem to be the best alternative that just works, compared to…

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

Send me an email please if you haven't yet. You'll want to try this distro, and I'd like to get your feedback.

site: killthe.net

name: dave

Re: Linux From Scratch ends SysVinit support

#344

Post by its_magic »

BadBadJellyBean wrote: post #311
palata wrote: post #228

Earlier quoted context omitted.

> But there's a reason it's being adopted: it does it's job well My problem with systemd is that it's taking over more and more and locking in . It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative. My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in". We like to complain about lock-in across the boar…

I think you got it backwards. Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization. I somehow don't think your gripe is with systemd but with developers who prefer the easy route…

> Systemd is a standardization that is appealing to developers. They want to adopt it because it makes their life easier. It is just nice to know that all the tools you need for a system are there and work together. Pluggability is hard to maintain and is only done if there is no standardization.

That's the official story, but like most official stories, it doesn't really hold up to scrutiny.

I built an entire system from scratch with over 1,500 packages installed. Everything under the sun. Works just fine with sysvinit. Completely seamless.

If KDE/Gnome can't figure out how to fit in with the overall system design the same way thousands of other packages somehow manage to do, then their services are no longer required. Good riddance to their bloated asses. I prefer to invest my CPU cycles in better software.

Init scripts for services and such are properly handled by the distro maintainer (packager), not the developer, although it's always nice to see examples he's provided to help guide the development of my preferred version.

Re: Linux From Scratch ends SysVinit support

#345

Post by its_magic »

theamk wrote: post #323
palata wrote: post #228

Earlier quoted context omitted.

> But there's a reason it's being adopted: it does it's job well My problem with systemd is that it's taking over more and more and locking in . It is encouraging developers to have a hard dependency on it, and making it harder to have an alternative. My problem is not philosophical with "it's a monolith, it's not unixy". My problem is "it's on the way to lock me in". We like to complain about lock-in across the boar…

It's not a lock-in as much as making a much better product. For example, I never liked the idea of having my programs to manually daemonize, manage logs, set up permissions and all that boring, but security-critical stuff. And with systemd, I don't have to! Program reads from stdin/stdout, maybe gets socket from socket activation, and systemd does the rest. Is it lock-in? Only because other system suck. Like, serious…

The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.

Re: Linux From Scratch ends SysVinit support

#346

Post by its_magic »

simoncion wrote: post #158
nomel wrote: post #108

Earlier quoted context omitted.

> and the maintainers don't care. I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report. This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.

> I think better proof of this would be a rejected PR rather than a neglected bug report. I understand the sentiment you're expressing here, and it's often a reasonable one. However, when every sharp edge case I've encountered with SystemD (both professionally and personally) ends either in a open Github Issue whose discussion from the project maintainers ends up being "Wow. That's tricky. I'm not sure whether or not…

I've long been in the habit of reading accounts like yours, understanding the truth and wisdom that's being expressed, then noping the fuck out of the tech/product/situation in question. It has saved me a lot of trouble over the years. Even as others are completely mystified. Some people just like abuse, I guess.

"Sweet dreams are made of this..."

Re: Linux From Scratch ends SysVinit support

#347

Post by theamk »

its_magic wrote: post #345
theamk wrote: post #323

Earlier quoted context omitted.

It's not a lock-in as much as making a much better product. For example, I never liked the idea of having my programs to manually daemonize, manage logs, set up permissions and all that boring, but security-critical stuff. And with systemd, I don't have to! Program reads from stdin/stdout, maybe gets socket from socket activation, and systemd does the rest. Is it lock-in? Only because other system suck. Like, serious…

The problem with the word "sysvinit" here is it's sort of a red herring. BSD init is better, in my opinion. I don't like managing all those symlinks. Plus, sysvinit is an old 90s application and its code does have some cruft built up over the years that could be removed and simplified. I'm devising a new init for my system that's much simpler than sysvinit and much closer to BSD.

"BSD init", "much simpler"... So does this mean you still expect applications to manage their own logs, daemonization and security setup themselves?

If yes, that's yet another init system not made for application writers.

Re: Linux From Scratch ends SysVinit support

#348

Post by JCattheATM »

BadBadJellyBean wrote: post #320
JCattheATM wrote: post #21

> Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Systemd is basically the Windowsfication of Linux. I'm always surprised by the people that champion it who also used to shit on Windows with the registry or whatever. Cognitive dissonance is a hell of a thing.

It is not cognitive dissonance to learn from others. The pluggable nature of Linux makes developer lifes harder. They have to write wrappers and abstractions to use base functionality. Having a unified api surface is very attractive. Windows did something right because you can run very old binaries on a new system. Good luck doing that on Linux. In the end for most people Linux is not an intellectual exercise in free…

> It is not cognitive dissonance to learn from others.

I didn't say it was. I said it was to attack one binary blob abstraction while embracing another.

> Windows did something right because you can run very old binaries on a new system. Good luck doing that on Linux.

I agree, but that's entirely irrelevant.

> systemd ... works and brings a benefit it might be a good thing to start to depend on it.

We have very different philosophies, you and I.

Re: Linux From Scratch ends SysVinit support

#349

Post by lelanthran »

tapoxi wrote: post #24
smartmic wrote: post #8

It's a pity. It's also a step back from valuing the Unix philosophy, which has its merits, especially for those with a "learning the system from scratch" mindset. Sorry, but I have no sympathy for systemd.

I don't have a dog in this fight but I find it funny that the anti-systemd crowd hates it because it doesn't "follow the Unix philosophy", but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)

> but they tend to also hate Wayland which does and moves away from a clunky monolith (Xorg)

It's been 17 years and Wayland has yet to reach feature parity with X11/Xorg. There is doubt that it ever will.

Regardless of what you think the Unix "philosophy" is, actual features matter.

Re: Linux From Scratch ends SysVinit support

#350

Post by theamk »

palata wrote: post #325
theamk wrote: post #318

Earlier quoted context omitted.

Except for the main pid1 process, systemd is one of the most customizeable things, certainly much more than old shell-based things. Everything is documented, can be disabled or replaced, and in such a way that the rest of the system can keep functioning, and the system upgrades don't mess it up. A lot of people said you can edit /etc/init/ scripts, but this was pretty annoying, as the moment you upgrade the package,…

I am not sure if we are talking about the same thing. I am not saying that systemd is bad. I am saying that when a project has a hard dependency on systemd (which is not necessarily systemd's fault, to be fair), then it doesn't work with an alternative init system.

Right, but my point is that unlike earlier init systems, unless that dependency on pid 1 itself, there is nothing preventing alternative implementations, and in fact, there is all the support to make such implementations possible.

To give an example, let's say a package depends on systemd because it uses sd_journal protocol, presumably because it wants to send enriched logs. That protocol is fully described (in [0]), and is actually pretty trivial to implement, on both server and client side. It even have a build-in "upgrade" mechanism (via $JOURNAL_STREAM) to allow seamless switch between base/systemd-logs, although AFAIK sd_journal_* functions do not implement it by default.

So this brings us a question: if a program wants to provide rich logs, and it is is using a documented protocol to do so, but there is only one implementation of the receiver, is this a problem? Is the onus on the program's authors to support multiple log sending functions, or on the distributions to provide a log receiver that the program expects?

[0] https://systemd.io/JOURNAL_NATIVE_PROTOCOL/

Post reply on HN