Devuan Beowulf 3.0.0 released

Posted Jun 3, 2020 18:36 UTC (Wed) by BirAdam (guest, #132170)
In reply to: Devuan Beowulf 3.0.0 released by HelloWorld
Parent article: Devuan Beowulf 3.0.0 released

I could similarly argue that no one NEEDS Debian, Ubuntu, Red Hat, Fedora, or openSUSE. Silly upstarts. We have Slackware! It was first and it is best, everything else is unneeded. Maybe Slackware was a bridge too far. We had the BSDs. Maybe this whole Linux effort is stupid and wasteful eh? This would be wrong of course. Need is subjective and largely based upon the goal a team or person has. If you’re coming in and telling a project that their efforts are wasted, you may want to check your premise, and you should definitely check your ego. No one can tell others what to need, what to want, or what to do. You cannot know the best for others and to assume you do is hubris.

Devuan Beowulf 3.0.0 released

Posted Jun 4, 2020 18:17 UTC (Thu) by amarao (guest, #87073) [Link] (4 responses)

As operator I can testify that Debian is really great disto, and we need it to make things smooth. Moreover, since systemd introduction into Debian, it become the Tool. There are so many really great solutions that are practically impossible to create with shell madness.

Moreover, I can finally trust unit scripts (units). Sysv scripts were massive applications with hundreds of bash lines. Who again love to write and debug asynchronous parallel applications in bash, I forgot?

The systemd replaced simple underlaying mechanism with fatty complex one. But at the same time it replaced typeless 'garbage in garbage out' with rich and robust interface where errors are errors (not UB), and well-defined state machine you can reason about without executing it.

Devuan Beowulf 3.0.0 released

Posted Jun 5, 2020 8:59 UTC (Fri) by bmorel (guest, #138892) [Link] (3 responses)

Got few things to say here.

* it is unfair to say the bourne bloat is sysVinit's fault. That mess is caused only by rc.d/init.d, which basically looks like some service manager built in a language that is prone to errors (yes, bourne shell). It is perfectly possible to have sysvinit running daemontools or runsvdir or other ones.
* it is unfair to compare systemd to an init system or a service manager, for all of those components: systemd is more like a framework, which have both pros and cons. As a dev, I've learned that when you use a framework, and when you find that this framework, for any reason, does not fit your current goals and constraints, you must restart from scratch. Libraries, or "unix-philosophy-tools" allows to reduce the pain when such event happen, at the cost of higher initial cost.
* systemd is not the first and only one to provide cleaner ways to have async daemon starts. Daemon-tools provided that long ago, and since then there are several init systems based that embed such facilities, including runit (which is default if not only init choice of at least one distro: voidlinux) or nosh (which can converts systemd units to it's own things, it seems).
* I can write runit scripts in less than 5 lines, including shebang and some empty lines, without having to learn a language or syntax specific. I could also avoid starting the binary if dependencies where not yet up, even if yes, it does imply that pre-requisites are checked every time units.
* I can read the the code behind runit-init without much pain. This is not true for systemd.

More on topic, I personally think it is sad that devuan sticks with the rc.d thing. Now, I understand that even Debian needed years to really switch toward systemd units, and with more manpower and more stuff worked on before by other distros.
I'm curious to see where devuan will go.

I'm also planning to give it a new try, now that Debian includes runit-init as an alternative init system (the debian 10's init meta-package depends on either systemd-init, sysvinit or runit-init), because I'm tired to have to manually fix the errors when I try to install components that have a kilometer-wide cascading dependency that ends on systemd (got some examples there).
Needless to say, my system works well and is fast to boot with my current debian setup, which is neither based on sysvinit nor systemd, while now relying on debian's packages for the actual init (a change I appreciate a lot thanks to debian 10).
Well, if that fixes even a tiny bit my situation, that would be nice. I guess I would still have to manually disable the Debian's automatic enabling of daemons after any upgrade though.

Devuan Beowulf 3.0.0 released

Posted Jun 5, 2020 12:26 UTC (Fri) by pizza (subscriber, #46) [Link]

> Needless to say, my system works well and is fast to boot with my current debian setup, which is neither based on sysvinit nor systemd, while now relying on debian's packages for the actual init (a change I appreciate a lot thanks to debian 10).

I should point out that for all Devuan's rhetoric about "init freedom", nearly all of the (significant!) work to enable and integrate that choice in Debian (and thus, Devuan) was done from within Debian itself.

IMO Devuan's only real accomplishment has been to siphon off Debian's more toxic users and developers, giving Debian the breathing room to improve and evolve, and Devuan's proponents their own sandbox to strut around in. Win-win, I'd say.

Devuan Beowulf 3.0.0 released

Posted Jun 19, 2020 13:37 UTC (Fri) by emorrp1 (guest, #99512) [Link] (1 responses)

> I guess I would still have to manually disable the Debian's automatic enabling of daemons after any upgrade though.

You just need to create a /usr/sbin/policy-rc.d script with `exit 101` if that's what you want (that's what docker uses too). It's only consulted by package management (see init-system-helpers) so won't interfere with whatever init enabling/starting config you have.

Devuan Beowulf 3.0.0 released

Posted Aug 4, 2020 4:08 UTC (Tue) by bmorel (guest, #138892) [Link]

> You just need to create a /usr/sbin/policy-rc.d script

Well, thanks for the pointer, it's *really* appreciated. Now to go rtfm and I'll get rid of that problem, nice!
Also, dunno if this is documented (or where), but I have since found that in runit-init based debian will prefer runit daemons *if* the name is exactly the same as a the rc.d's one. This might help someone, someday (and avoid the comment to only say thanks).