jhkaghjkga

> What I mean is that there are init systems that only require POSIX compliant APIs

Those are irrelevant as they can't even do basic tasks like shutting down the computer or restarting it. Feel free to find a POSIX API for Linux' reboot syscall.

Some systems also require mounting additional filesystems, again not possible in a world limited to POSIX interfaces.

Sandboxing, SELinux, ...? Not in POSIX.

And so on.

So changing an implementation detail how the support for sysvinit scripts for systemd works means they "removed everything they could"? That's a strange way to put it.

And if "apt-get install sysvinit-core" is not trivial for you, then yes, you might need a special distribution doing that for you.

The main driver behind the initial fork isn't even a sysadmin, but an art student who initiated Devuan as part of an art project and his PhD thesis: https://pearl.plymouth.ac.uk/handle/10026.1/11101

As a fun fact the thesis is released under a Creative Commons license, but states "no quotation from the thesis and no information derived from it may be published without the author's prior consent". Forbidding quotations and building further work on it is also an interesting approach to the idea of science.

That need is already fulfilled by Debian? Just install sysvinit. (edit:) Also consider that if Debian would stop supporting sysvinit, a distribution adding support for it again would be a real effort compared to just installing a different init system by default.

Some desktop environments might want systemd-logind+systemd-shim, but that's really not different from installing systemd-elogind in Devuan...

So they now officially recommend Debian to people who value true init freedom?

I'm looking forward to Devuan going stable in 2020.

But seriously, Devuan had some success with its core mission (drawing away the trolls and conspiracy theorists from Debian). They are now well integrated and discover most fascinating things (like that the vfat filesystem can be mounted in a way that non-root can write there! Wow! How did you discover this without reading the documentation?)

https://lists.dyne.org/lurker/message/20160426.180427.4d4815...

And at least OpenSuSE and Slackware just patched the warning out already -- probably after getting hit by it in the past.

See for example the patch in Slackware: https://slackbuilds.org/mirror/slackware/slackware-current/s...

Because any (possibly security-relevant) update to a library would mean that all software linking it statically has to be rebuilt.

In reality that of course doesn't happen, so programs linking statically or including their own versions of shared libraries never get security updates for the included libraries.

> lose a private key that they generated for me

Found your problem: you should never have someone generate a private key for you.

That's wrong. You can get more than 5 certs/domain: either you have to wait a week (it's 5 certs/domain/week), or you include multiple hostnames in a single certificate (up to 100 IIRC). The latter would allow 500 subdomains/week.

To quote the original post:

> Unix has a long tradition of doing a `rm -rf /` before reinstalling a system. I don't agree with the people saying "don't do that".

So, yes, "tradition".

So cargo-cult? Doing things out of "tradition" without understanding what they are for?

What's that supposed to be good for?

It certainly doesn't remove any file contents and to get a clean state, surely reformatting would be both easier and quicker?

Sane distributions don't include that alias by default. Because otherwise people will always use `rm -f` and lose the feature that `rm` asks before removing files marked as read-only.