Control: tag 1103476 +pending I'm dropping kibi from CC of this big feature thread since he's ultra busy.
Tyler Riddle <cardboardaardv...@gmail.com> writes: >> >> Possible yes, desirable unsure. > > Others might disagree > > > First, I absolutely do not want perfection to be the enemy of good here and > I'm interested in seeing the quick and easy fix slide in before freezes > prevent it so please interpret the following as an explanation of my > expectations and not a desire for immediate outcome for a resolution in my > bug report. (att. Pascal) Yup, and that's why I cloned this bug. The one I split off is for the cases that we definitely should support, and not any of the ones that will unnecessarily amplify the maintenance burden. I'm currently updating my d-i build tree to build and test an image. Thank you *very* much Pascal for the d-i expertise! This bug seems to have become the primary site of discussion (as I suspected it would), and src:rescue might not even be the place where most of the logic is (or should be) implemented. For example: suppose we provide a package that installs a grub plugin that generates a menu item for each bootable rootfs subvolume (the ZFS equivalent is "boot environment" and Windows has had snapshots like this for, what 30 years now?), and filters the list according to sysadmin/user-defined criteria. Then, if the bootloader is uninstalled or corrupted, just boot Debian Rescue, let it chroot into the default rootfs subvol, reinstall and/or update the bootloader, umount, reboot. On next boot grub presents the menu of alternatives to @rootfs. If users/sysadmins want to see a thousand grub menu entries for all their snapshots in grub, they can get it this way. How does that sound? [snip] > Debian is "The Universal Operating System" by its own definition. Universal > has an implicit definition of flexible. I'm surprised to see that offering > the user choices is not a widely agreed upon fundamental principle. My > expectation from the entire Debian ecosystem is that it will let me make > choices when possible even if those choices perhaps are wrong or may lead > to unwanted outcomes. This is a critical part of being "universal." The rescue system let's you get a shell, and do whatever you want, which is maximum flexibility. I think everyone will agree that having all the knobs on all of the screens is confusing and stressful UI/UX. Universal Operating System also means not inducing information overload in our users, eg: Linus Torvalds famously believes that our installer has too many knobs and is too hard to use. The "alternative rootfs" menu would be hidden at least one level deep, so one wouldn't see the list every time the system reboots. > I'd also like to point out that derivatives of Debian that are "on rails" > already exist, such as Ubuntu, and I believe also Mint, and if I was > interested in a system that was not "universal" I would be using one of > them instead. The very thing that makes Debian what it is, at least to me, > is the flexibility and that is absolutely my expectation for its behavior > from every part of it. So I really don't understand how asking the user > what subvolume to mount could be undesirable aside from the level of extra > effort involved in the implementation itself. The support burden is not possible to fulfill. Do you see how long this thread already is? People have described btrfs' flexibility as "insane" and use that same word when referring to supporting various subsets of its features. And even thought it goes against best practices, plenty of users have thousands of subvolumes; it's not reasonable to dump them all to the screen. Many users also have bootable non-Debian subvolumes. As discussed in the block above, src:rescue might not be the place for this. The concern I had in one of my replies to one of these recent btrfs issues is that there shouldn't be a separate subvol-candidate-rootfs implementation for each of rescue, os-prober, and/or whatever grub plugin we use for menu generation. > As always I greatly appreciate the work everyone puts into Debian. I'm > quite grateful to have such an excellent operating system I can rely on and > it has well earned its place as my default choice for Linux distributions > and a tool I can rely on when I'm in situations where I need a reliable > base to help me conquer possibly unreliable larger systems it is the base > of. > > Cheers to all and thank you again. Thanks for the discussion and kind words! :) Cheers, Nicholas
signature.asc
Description: PGP signature
