> 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.
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's boilerplate that Plymouth imposes, and not Denis Roio's choice. You'll find that this is fairly common, although the boilerplate varies from university to university. Here are some example rules from Durham, Brunel, Oxford, and Ulster, all with similar requirements to add such boilerplate.
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...
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?)
Oh wow, I didn't expect that from Slackware... I hadn't noticed that the message is gone, I guess. I can't help but to think it is kind of rude to keep using xscreensaver but not honor the request of its author. It's purely the principle of the thing because I agree that the message is ugly. That's not in true Slackware spirit imho (in the sense that this is a less-than-necessary patch). I am a little bit disappointed. :(
Yes, the nag text was removed, but at least xscreensaver gets updates, which was the whole point.
> patches/packages/xscreensaver-5.34-i486-1_slack14.1.txz: Upgraded.
I promised jwz that I'd keep this updated in -stable when I removed (against
his wishes) the nag screen that complains if a year has passed since that
version was released. So, here's the latest one.
Personally I don't get the point of screesavers at all, since we have monitors that can be sent sleep/standby mode when they're not used.
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.
If you want the perfect example of that problem, look to Windows.
A couple of years back Microsoft discovered some kind of issue with their redistributable dlls.
They patched Office etc, but could only offer a scanner that would check each and every dll to see if it was of a vulnerable version. And asked users to pester third party software providers for updates if the scanner found any.
I wouldn't move from a package system to an "everything has to be statically compiled" system. But it would be a nice option to have when most of the software in your distro it's ok but you want to run some app without upgrading your whole distro/OS.
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.
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.