Debian Moves Closer To Voting On Proposals Over Init System Diversity

[F.Ultra]

In my experience I find that systemd still has lots of room for improvement.

Just last night I was experimenting with the installation of various lightweight Linux distributions on an older mini PC that uses 4GB of RAM and an Intel D2550 CPU.

The intent is to load up to a simple windowed desktop state. My preference for lightweight desktop environments is LXDE & LxQt over XFCE based solely on my own past experiences. The ultimate use of these mini PC machines will be a fully automated (no human intervention necessary) display system that runs in a web browser interface.

The distributions that used systemd had the slowest boot times on this hardware compared to distributions that used sysvinit. systemd would take 60 to 70 seconds to load to a LXDE desktop login.

And I'm not vaping here. The boot time results for the systemd versions come straight from the "systemd-analyze blame" command and point straight to a systemd service loading & failing.

Every systemd-based distribution experienced issues loading a service "systemd-random-seed" or something worded like that it. That service never loaded; always showed "failed" when I typed the "systemctl" command by itself. That hanging service also caused the SSH service to "take forever" to load.

The sysvinit-based distributions would load to a LxQt desktop login prompt in 15 seconds. SSH was available by the time the login prompt was displayed.

So which style of init do you think I would choose for this older mini PC? I'll give you 2 guesses...

Remember that you are comparing distributions now and not just systemd. Googling for this service +failed gives some hint that certain distributions fail to set /var/lib/systemd/random-seed as writeable on some configurations but not sure if that is the same problem that you have encountered.

[starshipeleven]

And I'm not vaping here. The boot time results for the systemd versions come straight from the "systemd-analyze blame" command and point straight to a systemd service loading & failing.

Yes you are vaping.

systemd services are created by the distro, not by systemd upstream.

"systemd-analyze blame" is a diagnostic tool to find what service file is wrong, because upstream knows full well that someone somewhere will write bs in their service config file, and has made a tool that allows you to find the culprit in seconds.

And you, evil genius, not only you don't use it to fix the issue, but somehow think that using it makes your point more valid. Of course it's a systemd service that blocks boot, every system service is using systemd in that distro.

The sysvinit-based distributions would load to a LxQt desktop login prompt in 15 seconds.

Yeah, but when something breaks there is no sysvinit-analyze blame that points to the culprit, isn't it?

[danmcgrew]

Systemd - Progress Through Complexity
OCS-Mag; Updated October 19, 2016

http://www.ocsmag.com/2016/10/19/systemd-progress-through-complexity/

[Delgarde]

That's my main gripe with it - that it defies the concept of modularity. They should've focused on standardizing a set of interfaces, so that different services could be swapped out for various duties.

They did — the interfaces are all well documented, and they're amenable to making changes to help others provide alternative implementations.

Only problem is, nobody seems to want to... many people complain about the lack of alternative implementations, but there have been very few attempts to create one, and even fewer that have gone anywhere. Turns out that while complaining is easy, committing to build and maintain code is much harder...

[trek]

Bingo, I admit to not knowing the details, but at the same time I would think that a lot of systemd functionality could simply be ignored which would make the implementation easier. E.g. for most things slices (cgroups) that takes care of memory constraints and resource limits, i bet it could be mostly ignored and things would work just fine for most programs anyway.

that was the unfortunate way elogind people hoped to reimplement stuff, without slices, but then it turned out that libsystemd don't like to work without slices even if logind can... what an incoherent design

[coder]

Not a blob, but a bunch of daemons, see below for list

That's not a list of daemons - that's a list of where they felt like defining interfaces.

And when I said "blob", I didn't mean like literally a single daemon, I meant that it's encompassing more and more functionality. Like those old Blob That Ate ... movies, where some giant, gelatinous blob devours everything.

Sorry what? You can mix and match every daemon.

Even they don't say that! There are plenty of "no"s and "maybe"s in their "Reimplementable Independently" column. And since most lack specific examples, even most that claim "yes" can't be trusted.

pretty much all your post is sugar-coated bullshit, there is no other plausible explanation.

Yours is deep-fried. But pretty much nobody here expects anything else from you, by now. If I didn't know you such a troll, I might actually be offended.

To change the system architecture you must control the core system components, duh.

Obviously not.

There are loads of technical standards where people come together and agree on a standard interface or data format. You don't have to conquer userspace and mold it as you please, and then expose a few interfaces where you find it convenient to do so. That sort of fascist thinking doesn't fit well, in an open source ecosystem.

[coder]

As a disclaimer, a warning to others.

Nice try, contrary canary. I know you're neither stupid nor ignorant enough to believe that such a disclaimer or warning is necessary or warranted.

Troll harder.

[coder]

An init system isn't something that users care about.

systemd is not an init system. That was just the camel's nose under the tent.

whatever cherry picked part in the toolchain having absolutely no impact on my work.

Sounds like you could probably also just use Windows or MacOS and be just as happy. Good for you.

[profoundWHALE]

I'm sure that I'm late to the party but I think that they should keep systemd as is for now.

[coder]

Actually, the end-user benefit of choice is a common fallacy. Consumers always claim to want choice, true. But it's been shown that consumers are actually less satisfied as the number of choices grows.

You're missing the point. It's not about consumer preference, but the ability to customize system software to suit a particular set of needs. As you'll know, Linux is being used in a vast array of devices and environments, to suit applications with an even greater set of needs and requirements. To think that one userspace blob of services can adequately satisfy them all is beyond hubris - it's insanity.

BTW, even when you're saying people are less happy with more choices, that doesn't mean they're always happiest with zero choices.

Linux is not about choice.

Maybe not for you, what one thing I always found appealing was its openness and flexibility. I think those have been virtues, and I hate to see ever-increasing parts of the userspace get absorbed by the sytemd borg (maybe that analogy will make more sense to certain individuals of a more interstellar predisposition), eroding away at some of that flexibility as is does.

I just wonder how long it'll be, before systemd starts to infect the kernel.