Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[ermo]

That’s sad. It rather majorly restricts the usability of this particular distro by “normal” people.

AIUI, Devuan is not for "normal" people, it's for people who specifically want to use Debian but do not agree with Systemd's way of doing things and prefer sysvinit scripts for controlling their system.

They now have their own debian-derived distribution and get to keep the pieces if it breaks. Good on them and good for the rest of us who get along with systemd just fine. Sometimes it's just better for the majority and the dissenters to agree to disagree and go their separate ways and let the dissenters create a new tribe.

Freedom of Choice appears to lead to fragmentation over time. The tribal posturing associated with this fragmentation is incidental and of little consequence to most "normal" people (as you put it).

Personally, I'm not sure I understand the benefits of Devuan. But to each their own.

[bkor]

But while comendable the work Devuan developers had done, we will have to see how the project may be able to adapt in the future. There are already many software, including desktops relying on systemd.

Under Debian you can run GNOME using another init system, e.g. sysvinit. On Debian you can run both systemd and e.g. sysvinit. This due to Debian and Canonical doing the fairly difficult work in providing an alternative for e.g. logind and so on (systemd-shim). On Devuan anything with "systemd" in the name is removed, no matter if it makes sense or not (systemd-shim is not systemd.. it is a shim layer to not need systemd!).

Devuan is not about "init system choice", as shown above, better use e.g. Debian or Gentoo for that.

[oiaohm]

For me it's mostly: if it isn't broken don't fix it. Sysvinit always worked flawless for me. It does what it's supposed to. So why change? Just for the sake of change?

Problem is Sysvinit is broken. It depend on every system using the same /bin/sh at times. Like debian uses dash and other distributions use different versions of this. So your init scripts are not uniform. Some cases you many end up a init script per distribution under sysvinit and this is very stupid.

https://wiki.debian.org/LSBInitScripts

Notice here how sysvinit script have to be headed with comments so that auto tools altering boot orders can get them right. Of course a human manually altering is going have issues. So to manage you sysvinit script people had started using automated tools and then you sysvinit script many on may not have the header those tools require so making a mess of your init.

Then the elephant in the room using PID to track services was fine under sysv where you PID numbers just keep on increasing and when you hit max PID value system reset but under the Linux kernel where PID are recycled this is no longer a valid move.

This is just 3 I could keep on going. Like it or not sysvinit is busted.

systemd at long last gives .service files that in almost all cases are identical no matter the distribution they are being used on. Openrc provides sysvinit like scripts but then uses cgroups and namespaces to track services like systemd so avoiding the PID error.

So the PID fault is not justifiable even upstart when it was running sysvinit scripts was wrapping around the PID bug. Sysvinit need to die. Something sysvinit compatible might be able to live like openrc that is using methods that in fact work and it need to come bundled with a shell to avoid random mess of different solutions using different shells that we currently have.

[jacob]

I'm more wondering what excuse they are going to make when no one uses it, and who they are going to blame.

They had the freedom to make it. They had this freedom because of Free software. What they don't get, is their "Freedom" doesn't mean the rest of the world has to agree with their software preference. They don't seem to understand that.

Obviously it will be Poettering's fault. He has a mind control satellite in orbit and remotely reprograms everyone to use modern OSes rather than the VUA's cr*p. How else could you explain that people want to expect their computers to Just Work so that they can use them to, you know, actually do something useful?

BTW are the Devuan repos accessible over UUCP yet or are they temporarily sticking with that scandalously non-Unix thing called TCP/IP ? I would also be very interested in seeing what filesystem do they use by default. If it's anything other than ffs I call shenanigan!

[trek]

systemd is a system daemon
a daemon is created by a process forking a child process and then immediately exiting
but wait, systemd don't fork itself!
may be the author don't clearly understand the concept of a daemon at first?

[starshipeleven]

If it's all about init freedom, why doesn't it let you install systemd?

Come on it's a cheap shot. Those that want systemd will use Debian.

[starshipeleven]

I personally don't have time to port my customized init scripts in gentoo. Additionally, there is no immediate benefit in learning systemd. I have to reconfigure the kernel also. I will learn systemd when I felt the need. However, I can see systemd is the future.

Reconfigure the kernel?

[nomadewolf]

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

I am forced to agree with you. Mostly because i think they directed their efforts the wrong way...
Instead of pursuing a distro free from systemd (which is nice, i admit), but first it would also be nice to have a viable alternative.

Systemd is no where near good as it could be, but it still manages to be the best by far, and that's why we use it, IMO.

[nomadewolf]

If it's all about init freedom, why doesn't it let you install systemd?

Well pointed out!
Someone should fork Devuan and allow Systemd in-it. (pun-intendo...)

[quikee]

a daemon is created by a process forking a child process and then immediately exiting
but wait, systemd don't fork itself!

AFAIK That's the usual scenario, but not a condition that separates a daemon from non-daemon.