Devuan: Debian Without Systemd

[ryao]

So...you're suggesting the people who decide the technical direction of Debian, SUSE, Fedora, RHEL, Ubuntu, Mageia and multiple other distros are 'end users who are vulnerable to hype and less experienced developers'?

Ooooo...kay then.

I will say that the technical ability of most Debian developers is below that of kernel developers like Ted T'so or core component maintainers like Roger Leigh. The majority are people who touch things that sit on top of the base system and quite frankly, are not at the same level. Consequently, a vote is a skewed toward those who are less technical and are more vulnerable to hype. Having some kind of distribution where people vary in their levels of ability is unavoidable.

That said, twisting my words really does not do justice to any sort of dialogue and reflects poorly on both yourself and those associated with you. Please either confirm that you reject the idea that there are different levels of ability among developers or apologize for misunderstanding my point.

[omer666]

I don't get why everyone's still arguing on this point in the Phoronix forums, as this has long been forgotten in the many other places I visit on the internet. I still don't understand what's so bad about systemd compared to sysvinit, apart from its being "too monolithic". Isn't the Linux kernel very monolithic too?

Also, before everybody starts putting their resume in order to know who's the "better dev" (and therefore, know who's right), yes, I'm an end user, which, if I understand correctly, means that I'm an inexperienced moron.

[gutigen]

The best thing about systemd is how entertaining it is to watch all this drama where actors are often very smart people behaving like children after 8 years of fluoridising.

Priceless

[Aeder]

I never said "all systemd proponents are inexperienced". I said that from my perspective, they are mostly inexperienced. You cannot refute that because you are not in m

Oh my bad, I thought you were trying to make some sort of valid point instead of just writing an opinion.

I nver said that they were contributing.

You point? I was replying to your notion that it's somehow bad when rookie programmers like and promote a particular project. As if you get to decide that.

Or I could just not use it.

That's implied. But then again that would only prove you like complaining about things you don't use which is a pretty ridiculous attitude.

This attitude is a perfect example of peer pressure meant to prevent people from taking, modifying and redistributing F/OSS software for any purpose. It has no place in the community.

I'm sorry, I'm wasn't aware I had deleted your development programs, banned you from every FOSS project, physically destroyed your computer/s, removed your coding skills and/or physically restrained you.

Oh wait, I haven't. Guess what, you can make the best systemd alternative there has ever been (or improve existing ones) and there's not a single thing I can do to stop you. In fact, I would be glad if you did. But instead you're here complaining. About a program you don't use.

[valeriodean]

The best thing about systemd is how entertaining it is to watch all this drama where actors are often very smart people behaving like children after 8 years of fluoridising.

Priceless

Exactly! :-)
The init war is pretty over but the show is still on!
I'm just afraid that with the end of the display server war (Wayland vs X vs Mir) and the end of the init war, we will lose a lot of fun on the web. We need to find some good substitute...

[gutigen]

Exactly! :-)
The init war is pretty over but the show is still on!
I'm just afraid that with the end of the display server war (Wayland vs X vs Mir) and the end of the init war, we will lose a lot of fun on the web. We need to find some good substitute...

No worries, Canonical will fork kernel or something eventually. Show must go on!

[curaga]

Its the same idiotism that lets people use ancient hardware as a 24h/365d on printserver or somesuch because they got it for cheap or had it lying around, totally neglecting that the lesser powerconsumption of a modern embedded device doing the same job would prolly pay for itself inside a month or two with zero noise and smell emission. Its nostalgia plain and simple.

Too bad math disagrees with you

A Pentium uses ~20W. A rpi 5W. A saving of 15W, at a cost of 10 cents per kWh, would take 4.6 years to pay for itself. That long, coupled with the unreliability of the rpi, is not very favorable.

I used 60$ as the cost of rpi + sd card + good-quality power supply + shipping + taxes.

[nanonyme]

The funny part of all of this is that systemd in fact *does* have sysvinit/LSB script compatibility layer. If it didn't, no distro could really realistically have migrated to it

[ryao]

I don't get why everyone's still arguing on this point in the Phoronix forums, as this has long been forgotten in the many other places I visit on the internet. I still don't understand what's so bad about systemd compared to sysvinit, apart from its being "too monolithic". Isn't the Linux kernel very monolithic too?

Also, before everybody starts putting their resume in order to know who's the "better dev" (and therefore, know who's right), yes, I'm an end user, which, if I understand correctly, means that I'm an inexperienced moron.

While you might not be experienced, you are by no means a moron. An actual moron likely could not have asked the question that you asked.

To answer your question, the main issue is the harassment that people face for not running whatever one circle happens to like. From my perspective, this harassment is mainly from systemd proponents, who do not believe in co-existence. On the other hand, sysvinit proponents seem to believe in interoperability, but often feel a need to retaliate in response to abuse they face for not being on board. You will find systemd proponents saying things consistent with the idea that "alternatives to systemd should not be allowed to exist" whle sysvinit proponents are saying things consistent with "I do not want systemd on my systems".

That said, both sysvinit and systemd have their strengths and weaknesses. sysvinit is designed to be a minimal init that allows other things to live on top of it, often in the form of scripts, but binaries could also be used. systemd is more of an attempt to make a framework that contains a superset of sysvinit and sysvrc. It is essentially the Java of system boot. Constraining the discussion to just what sysvinit and various RC systems do versus systemd's equivalents. systemd's socket-based activation is a strength. systemd also has several other improvements over sysvrc that can be found in alternative RC implementations (e.g. named runlevels, fine grained dependencies, the elimination of sleep(), etcetera) that are often marketed as being things that systemd alone can achieve. At the same time, systemd does have some weaknesses. Abandoning scripts means that it is difficult to do makeshift changes when debugging as Ted T'so pointed out. Its attempt to be a framework means that it increases the opportunity for exploit vectors, which is undesirable on multiuser systems such as servers. A few of its core features are implemented by increasing the complexity of PID 1, which provides greater risk in terms of system panics caused by PID 1 crashing and is undesirable on servers. The default binary log format also poses problems for servers should the logs be even slightly corrupted.

On another level, systemd's developers are openly hostile to patches to support Linux distribution designs that deviate from their desired standardization. Support for other libcs such as uclibc is absent and older kernel support is dropped regularly, with patches to add compatibility shims rejected. This is despite pre-existing patches that were accepted in the past existing in the tree. Those patches were mainly for enterprise distributions. The core systemd developers' "my way or the highway" attitude causes them to reject alternative ways of writing patches that would have made all parties in disputes happy, which is one of the points Roger Leigh made. They are known to change working code and have broken working systems. One example involves the network device interface names, where fallback code was removed and system boot broke. A collegue of mine who is a major systemd fan and I had a discussion about systemd a few months ago. He had significant difficulty believing this was the case, but commit histories show that it was. In a similar vein, the core systemd developers have blamed others for bugs in software that they wrote because other software did not adapt to fix it. A prominent example involved the kernel syslog code. Their attitudes caused them to be banned from contributing to the Linux kernel. These things in general make trying to collaborate with them very unpleasant. I tried a few years ago and gave up. Linus Torvalds also tried and gave up. In Linus' case, him giving up meant that they were banned from contributing to the Linux kernel.

In contrast, sysvinit upstream is not actively annoying people because it is simply not involved. sysvinit sees no development. Its emphasis on minimalism means that the only development occurs in the RC systems that run on top of it. Consequently, sysvinit is essentially just the following files, plus man pages:

/etc/init.d/reboot.sh
/etc/init.d/shutdown.sh
/etc/inittab
/sbin/bootlogd
/sbin/fstab-decode
/sbin/halt
/sbin/init
/sbin/killall5
/sbin/poweroff -> halt
/sbin/reboot -> halt
/sbin/runlevel
/sbin/shutdown
/sbin/telinit -> init
/usr/include/initreq.h

It is configured through /etc/inittab. On a modern Gentoo system, it manages a few basic things like virtual consoles, serial consoles, the RC system and a hook for X windows that does nothing unless the RC system toggles it. The RC system handles the rest. Most criticisms directed at sysvinit are typically criticisms of the RC systems on top because all of the annoying scripts in /etc/rc?.d are part of sysvrc. sysvrc is only one possible design for the RC system. It does not exist on distributions that use OpenRC, such as Gentoo. That said, the minimalism means that there are very few ways that things can go wrong and sysvinit-based solutions is known to work. Instances where people find that the existing solutions work understandably have no need for changes and nothing any new init system can offer will make that init system more desirable.

Lastly, a word should be said about RC systems. It is theoretically possible to run sysvrc or any other RC system on top of systemd, but that would probably defeat the point of having it. Putting sysvrc on top of systemd in particular would give it most, if not all of the problems falsely associated with sysvinit. So far, no one has tried doing it to my knowledge. Such a demonstration has no benefit other than to say "I told you so". I suspect that most fans of sysvinit have better things to do with their time.

[ryao]

Oh wait, I haven't. Guess what, you can make the best systemd alternative there has ever been (or improve existing ones) and there's not a single thing I can do to stop you. In fact, I would be glad if you did. But instead you're here complaining. About a program you don't use.

You have certainly harassed me for my ideas, rather than agreeing to disagree or displaying any consideration that they might be valid points when considering alternative use cases. If you want to make a good case for systemd, stop harassing people who disagree and learn to agree to disagree. Failing to do that demonstrates my point that systemd proponents are harass those who decline to participate in the establishment of a systemd monoculture by wanting other things.