Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[darkcoder]

I actually don't care about stuff that doesn't concern me. The PID bug you tell about is a non-problem. You ever needed 32768 PID's? Well I don't. Systemd is way more complex. Which I find more of a problem then init scripts. I don't see how distro specific stuff would be "very stupid". You're saying 1 Linux distro is enough? Just because you find something stupid? There're also people with different opinions. Sysvinit is far from being busted. There are enough distro's still using it.
An init system needs to do one thing: boot your system. I know sysvinit it's been around like forever. But for systemd I'd need to learn how to use it. Because it's more complex. Which is a waste of time IMHO because I already have a working init system. Even for speed I don't need systemd. My box boots in under 15 seconds because these days people use SSD's.

p.s. Do you have a link to this PID bug? I can't find anything about it?

And if you work on computers and land on a job that uses Red Hat, then what you gonna do????? For sysvinit on them?

Learning new stuff is part of the job on computers... Learn, adapt (and recertify) to new standards, or let get behind.

[ldo17]

I actually don't care about stuff that doesn't concern me.

How wonderful for you.

*Yawn*

[starshipeleven]

You ever needed 32768 PID's? Well I don't.

On servers it can get there. Of course if you are on a home PC it's unlikely to matter.

Sysvinit is far from being busted. There are enough distro's still using it.

AFAIK it's Devuan the most prominent one, others all have something less stupid where they add a plethora of scripts on top of sysvinit to extend its functionality.

Even OpenWRT/LEDE uses procd that is a poor man's systemd for init and processs tracking.

An init system needs to do one thing: boot your system.

In modern days it's also about security and sandboxing, and good logging and decent process tracking. I mean, you might not care for your boxes, but that's what an init system must do in modern times.

But for systemd I'd need to learn how to use it. Because it's more complex.

Most end users should never need to interact with the init system, and even then it's not more complex than what sysvinit does. It's just new. Most people will learn how to operate it in like a weekend tops.

p.s. Do you have a link to this PID bug? I can't find anything about it?

https://bugzilla.redhat.com/show_bug.cgi?id=726596 this is one of the examples why scripts can fail hard when using PIDs. (script writes down PID, does not notice its own application segfaulted and died, PID is reused by other process, script is triggered to kill application, script kills wrong application)

[Zucca]

The worst choice among the ones you mentioned, Sysvinit.

To be fair, it's probably because they are noobs. Debian never supported other inits you mentioned and I guess they don't have the skills to at least use something that does not suck ass and is developed/maintained by a major distro, like say OpenRC.

Shame. I'd really like to have seen a distro to adapt Epoch or nosh as default. nosh would have been the easiest to adopt since it has tools to convert systemd services.

[unixfan2001]

I actually don't care about stuff that doesn't concern me. The PID bug you tell about is a non-problem. You ever needed 32768 PID's? Well I don't. Systemd is way more complex. Which I find more of a problem then init scripts. I don't see how distro specific stuff would be "very stupid". You're saying 1 Linux distro is enough? Just because you find something stupid? There're also people with different opinions. Sysvinit is far from being busted. There are enough distro's still using it.
An init system needs to do one thing: boot your system. I know sysvinit it's been around like forever. But for systemd I'd need to learn how to use it. Because it's more complex. Which is a waste of time IMHO because I already have a working init system. Even for speed I don't need systemd. My box boots in under 15 seconds because these days people use SSD's.

p.s. Do you have a link to this PID bug? I can't find anything about it?

If you ever actually checked your processes, you'd realise how easy it is to burn through a few thousand PIDs. Especially for people who develop system components and regularly have to restart a daemon or program, or work with hundreds of smaller server applications at a time.

Systemd PID1 only does one thing, booting your system. It does it commendably well and there's no need for you to hack into shell scripts.
Unless you're suffering from some sort of brain damage, there's no way you'd "waste" more than an hour learning how to write a unit, tops.

Lastly, I'd just like to mention that your entire post is a grand example of all the things wrong with humanity. An unwillingness to learn new skills and improve their knowledge. People sticking to archaic ideas and utter fallacies. This is exactly why the world is such a tremendously shitty place right now.

[oiaohm]

I actually don't care about stuff that doesn't concern me. The PID bug you tell about is a non-problem. You ever needed 32768 PID's? Well I don't. Systemd is way more complex. Which I find more of a problem then init scripts. I don't see how distro specific stuff would be "very stupid". You're saying 1 Linux distro is enough? Just because you find something stupid? There're also people with different opinions. Sysvinit is far from being busted. There are enough distro's still using it.
An init system needs to do one thing: boot your system. I know sysvinit it's been around like forever. But for systemd I'd need to learn how to use it. Because it's more complex. Which is a waste of time IMHO because I already have a working init system. Even for speed I don't need systemd. My box boots in under 15 seconds because these days people use SSD's.

p.s. Do you have a link to this PID bug? I can't find anything about it?

The PID issue is common on those running web-servers and terminal services. You can be cycling though 32768 PID in an hour. There is a reason why you can open pid_max up to 4 million. The number of PID that are consumed per connection processed by apache can be quite a few. So those running services want some thing better than sysvinit because they are wrapping around all the time and end up finding using check running status features in sysvinit scripts mostly not dependable.

Even at 4 million PID values you can be cycling though them every 5 days and with live kernel patching your kernel could be up for 90 + days so 18+ cycles. So this PID bug causes very random and hard to diagnose issues. That you not been on the receiving end means you have not had contracts with 99.999 uptime requirements.

==I don't see how distro specific stuff would be "very stupid"==
You have redhat, fedora, centos, scientific. Now that RPM package you just made should run on all 4 right because they are fairly binary compatible. That is true after they started using systemd not true when using sysvinit or upstart due to the every now and again /bin/sh accept features veneration. So sysvinit has been a cause for requiring more binary packages. Yes it stupid to have to require another package because the init systems scripting is not clearly defined.

==I actually don't care about stuff that doesn't concern me.==

So the fact that other people are having real problems with sysvinit where their pay check is on the line because of it does not worry you. A contractor with a SLA for 99.999 uptime failure to deliver is 1 don't get paid for you time and at times pay for the damage of the downtime. This line says you will shove sysvinit on those that is incompatible with. Reality is accept sysvinit is busted. Just because the way you use your system you don't hit it defects does not mean others don't.

Please note the first distributions to move to systemd prime market is server based solutions and server based solutions suffer from PID cycling issues making diagnosing of faults harder. Most of the server based distributions tried upstart with ptrace tracking first.

The server users normally have more voting power in distributions than general users. Why they pay or provide the developers. So if want you are pushing as an init system has issues in servers getting into the big distributions is not going to happen.

Reality here a lot of people say sysvinit is suitable they are not looking at the different usage cases to see that some groups are using systemd with all it bugs because systemd bugs are simpler to debug then the random bits of hell sysvinit can throw up.

PID cycling issues of sysvinit cause random hard to diagnose bugs. It is in fact a form of race condition. Service dies PID is freed another long term service is restarted it now uses that PID value so now a service that is no longer running is reporting as running by PID check done by a lot of sysvinit status option in sysvinit scripts. Now due to false information administrator takes longer to locate problem and possible cost themselves money.

.Please remember I would prefer to be using something lighter than systemd.

Systemd unit files require a lot less unique text to create one than a sysvinit equal. Less lines of text less human typing errors to turn up latter.

https://bugzilla.redhat.com/show_bug.cgi?id=726596

This example by starshipeleven you will find that there are equal bugs reported against debian and the other server base distributions where sysvinit script using PID due to PID loop go and terminate the wrong process so making issues worse. Reality like it or not sysvinit is busted. Sysvinit was busted as soon as it was used on top of the Linux kernel and system administrators have had to suffer with these issues.

We need a init system that works for all users effectively. I am not sure that systemd is that. Return to sysvinit that is busted instead of moving forwards with the likes of openrc that possible could come a workable solution is getting us no where. The anti-sysvinit crowd have a lot lists of reported bugs against it. They will never accept sysvinit because it makes their life harder and costs them money. Of course the anti systemd crowd might accept systemd one day as most of the complained about issues have been fixed over time. Or maybe the anti systemd crowd will wake up get the requirement the server world requires and give up on sysvinit and make something that works like openrc is attempting to-do. Openrc attempts to be syntax compatible with sysvinit yet avoiding the PID looping issues like false reporting or killing processes that don't own to the service.

[dungeon]

All hail the wasted efforts! Anyone, any ideas? How long will it take before they close down? 1 year, 2 years, maybe 5?

Maybe ever, maybe never Someone stated the same thing and asked the same thing on Ubuntu back in 2004.... that was you, isn't it.

Have no time to read whole thread, so should just comment that really Devuan distro is fine having it for about month installed here... it even boot faster than Jessie with systemd and is more responsive generally

That is funny as someone probably expect the opposite, nope without systemd distro really breath much better

[ldo17]

Lastly, I'd just like to mention that your entire post is a grand example of all the things wrong with humanity.

+1+1+1

[GDJacobs]

Or OpenRC. Or runit.

Devuan provides one init system which is shoved down your throat - sysvinit.

I've installed OpenRC on Devuan. I've installed Runit as well (both under classic init or Runit PID 1). I'm looking forward to using one of the newer generation PID 1 options like sinit or ninit once they are integrated.

[GreekGeek]

Hi Michael,

again thanks for the heads up. Must do a clean install later this week, as I have a wee holiday setup.

What would I like for Phoronix birthday? Better moderation of trolls.... Though if I were gonna run some statz, I rather imagine this website has long since been over-run by the afore said. Pity really, started off promising some time back. Now it is common online, to forgive trolls, as they up advertising revenue. But indecent materialism is hardly a new thing, for our species.

Well, there is always HHDL on youtube (the later delivery mechanism is also problematic....).

Greekgeek. :-)