On Fri, Feb 24, 2023 at 9:31 AM John Mellor <john.mellor@xxxxxxxxx> wrote: > 1) When are we going to see removal of the EXT2 /boot partition? It is > no longer required, as the boot process has been able to use BTRFS for > years now. /boot is critical and using a well debugged file system for it to me seems like an excellent idea. But if you want yours on btrfs, by all means put yours there. > 2) When are we going to see timeshifting tools built into the desktop, > ala Solaris? That's incredibly useful for developers. What do you mean by "timeshifting"? Changing the time zone seen by the user? Or do you mean point-in-time snapshots? > 3) The existing Windows-like update mechanism is undesirable. It solves > a non-existent problem on filesystems with inodes. Like all Unix-like > systems, even Ubuntu does not require this. The ability to snapshot > means that the weird reasoning that requires 2 reboots to install > virtually all update packages is no longer required under any > circumstances. When is the software update mechanism getting a > fundamental redesign? I don't think I have ever had to reboot Fedora twice to install updates. As far as I am aware, with Fedora you don't have to reboot at all unless you want to activate a new kernel. Having said that, I find that it is easier to reboot than to try to restart everything that might be needed with an update. I don't find rebooting once-a-week after updating to be onerous - "your milsage may vary". Personally, I find most of the proposed or alternative update mechanisms to be worse than using yum/dnf. Again, *my* opinion, you are free to disagree. (And I will happily acknowledge that specific environments may need capabilities beyond standard dnf - i.e. immutable root, etc.) > 4) When is a standard backup mechanism that takes advantage of > snapshotting going to be in the distro? The published backup packages > do not seem to be aware of the better capabilities available in BTRFS. > Wrapping a few CLI tools in a GUI seems like it should be obvious, maybe > 200 lines of shellscript or less. I should think the Fedora project would be happy to examine your submission of the software to do this. If we are going to make a wishlist of backup capabilities, my top priority would be something that would have built-in de-duplication and work across multiple systems. > 6) Compression is not the default. Why not? SSDs are 10x slower and > disks are 100x slower than the processors of even 10 years ago, so this > omission is slowing the system down. This depends on the use case - for many people decompression of a compressed file system slows the system down, not its omission. > 7) Keep the last 3 update snapshots, not just the last 3 kernels. This > would keep backout scenarios a lot more consistent and functional. *Iff* you use /boot on btrfs (along with the rest of the OS) and use snapshots, this is reasonable. You can configure this on *your* system if you meet the requirements. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
