from the and-so-it-begins dept.
Devuan is spelled in Italian and it is pronounced just like "DevOne" in English.
[...]is it really a fork?
This is just the start of a process, as bold as it sounds to call it a fork of Debian.
[...]Devuan aims to be a base distribution whose mission is protect the freedom of its community of users and developers. Its priority is to enable diversity, interoperability and backward compatibility for existing Debian users and downstream distributions willing to preserve Init freedom.
Devuan will derive its own installer and package repositories from Debian, modifying them where necessary, with the first goal of removing systemd, still inheriting the Debian development workflow while continuing it on a different path: free from bloat as a minimalist base distro should be. Our objective for the spring of 2015 is that users will be able to switch from Debian 7 to Devuan 1 smoothly, as if they would dist-upgrade to Jessie, and start using our package repositories.
Devuan will make an effort to rebuild an infrastructure similar to Debian, but will also take the opportunity to innovate some of its practices. Devuan developers look at this project as a fresh new start for a community of interested people and do not intend to enforce the vexation hierarchy and bureaucracy beyond real cases of emergency. We are well conscious this is possible for us mostly because of starting small again; we will do our best to not repeat the same mistakes and we welcome all Debian Developers willing to join us on this route.
System adminsitrator Chris Siebenmann has found Modern versions of systemd can cause an unmount storm during shutdowns:
One of my discoveries about Ubuntu 20.04 is that my test machine can trigger the kernel's out of memory killing during shutdown. My test virtual machine has 4 GB of RAM and 1 GB of swap, but it also has 347 NFS[*] mounts, and after some investigation, what appears to be happening is that in the 20.04 version of systemd (systemd 245 plus whatever changes Ubuntu has made), systemd now seems to try to run umount for all of those filesystems all at once (which also starts a umount.nfs process for each one). On 20.04, this is apparently enough to OOM[**] my test machine.
[...] Unfortunately, so far I haven't found a way to control this in systemd. There appears to be no way to set limits on how many unmounts systemd will try to do at once (or in general how many units it will try to stop at once, even if that requires running programs). Nor can we readily modify the mount units, because all of our NFS mounts are done through shell scripts by directly calling
mount; they don't exist in
/etc/fstabor as actual
We've been here before and there is certainly more where that came from.
(2020) Linux Home Directory Management is About to Undergo Major Change
(2019) System Down: A systemd-journald Exploit
(2017) Savaged by Systemd
(2017) Linux systemd Gives Root Privileges to Invalid Usernames
(2016) Systemd Crashing Bug
(2015) tmux Coders Asked to Add Special Code for systemd
(2016) SystemD Mounts EFI pseudo-fs RW, Facilitates Permanently Bricking Laptops, Closes Bug Invalid
(2015) A Technical Critique of Systemd
(2014) Devuan Developers Can Be Reached Via firstname.lastname@example.org
(2014) Systemd-resolved Subject to Cache Poisoning