Devuan 1.0 Officially Released - Letting Debian Live Without Systemd

[quikee]

Someone should fork Devuan and allow Systemd in-it. (pun-intendo...)

And call the distro SystemDevuan

[starshipeleven]

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?

Or maybe it's you that ignore the meaning of "daemon".

"daemon" (in computing)= background process that runs without direct user interaction.

[Zucca]

What init system devuan then uses? Nosh? Sysvinit? OpenRC-init? Epoch? Finit? Runit?

[NicePics13]

It's not like the Devuan team just exorcised systemd, they forked quite a few packages:

[starshipeleven]

What init system devuan then uses? Nosh? Sysvinit? OpenRC-init? Epoch? Finit? Runit?

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.

[pmorph]

Reconfigure the kernel?

System probably won't boot, if you try to run it with a slimmed down custom kernel configured without systemd requirements.

[starshipeleven]

System probably won't boot, if you try to run it with a slimmed down custom kernel configured without systemd requirements.

Fair enough, I didn't think of "kernel configuration" being kernel build time configuration.

[keivan]

You can take a look at the kernel section of gentoo wiki

https://wiki.gentoo.org/wiki/Systemd

[SilverMachine]

https://wiki.debian.org/LSBInitScripts[/url]
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.

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?

[darkcoder]

People continue the rant about systemd, and mostly the issues can be summarized as:
1. people were burned by early systemd versions.
2. people were burned by bad transition to systemd (distro fault btw).
3. people are reluctant to change.

But the irony is that users, admins, and distributions blame systemd, but don't mind using other software that keeps getting bad security issues on a MONTHLY basis like Xorg, Bind, OpenSSL.

Give me a single recent security issue that affects systems using systemd?