Hi all, This idea came to me while I wrote an anti-merge rant a few minutes ago...
You know, times have changed. Today, a 256GB SSD can be had for less than $100, and can easily, trivially, hold the entire operating system. One excellent configuration is to have the root partition, hosted by a SSD, be root (/) and contain /usr/bin. The contents of /usr/bin almost never change, meaning that you get very little wear and tear on your SSD. Matter of fact, of the usual suspects, only /var and /tmp experience much churn. If / is formatted ext4, it can be mounted directly by a kernel with ext4 drivers, no initramfs needed. Then, using the /usr/bin and /usr/lib from that root partition, almost any configuration can be built up with calls to mount, the luks utilities, lvm stuff, btrfs utils, plus drivers, all of which are on the root, not on a separate partition. All that would be required is a shellscript, with stuff that can be commented in and out, capable of mounting everything else once / is mounted. After everything is mounted, the rest of the boot is accomplished in the usual way. You might ask why this is any different than just using initramfs, which is meant for the purpose. The answer is transparency: You can put /usr/bin/bash commands anywhere in there to periscope in and run the rest. You can comment out the line that execs the real PID1, and take a look around. You could even change your init system in that shellscript, instead of in the Grub config. You could even (this is getting far fetched) give the user a prompted choice of init systems. I could have used that when I was A/B-ing between Epoch and Runit during the Manjaro Experiments. This wouldn't be mandatory. It wouldn't be default. But it would provide one more attraction to the person who wants to be in control of his computer, rather than vice-versa. I think it would be a feather in Devuan's cap, and would further differentiate Devuan from Debian. SteveT Steve Litt November 2015 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng