[quoting is a bit improper here - I have tried to fix it where I noticed] On Fri, Feb 24, 2023 at 4:15 PM John Mellor <john.mellor@xxxxxxxxx> wrote: >> and Go Canes replied > At this point, I doubt that EXT2 is better debugged than BTRFS, and its use has a number of detrimental effects. For one, it requires that you use another of your valuable partitions unnecessarily. I'd also highly doubt that you can get a modern, damaged Fedora system back up to a useful status using only the /boot partition, and a reinstall/recover would seem to be much more useful. At a minimum, you need fully-functioning /etc and /var. most of /usr, probably all the /home dotfiles, and probably others for proprietary packages. In the last few years I have frequently seen people running into issues with btrfs and difficulties recovering from said issues requiring specialized assistance. I don't recall seeing similar issues reported on this list for ext*. I certainly have gotten the strong impression that btrfs is not yet ready for mission critical work, although I do get the impression it is getting better/closer all the time. > 2) When are we going to see timeshifting tools built into the desktop, > ala Solaris? That's incredibly useful for developers. > I mean point-in-time snapshots, along with the slider in the GUI and the tooling that goes with it. Solaris introduced it about 10 years ago, and it can be added to SUSE as well. If you need this then by all means go with btrfs. Personally if I required it I would probably use lvm snapshots, or use VMs and use the snapshot capability of the VM. But I am not yet ready to trust btrfs (my opinion, my choice). > I assume that you do not use the Fedora-preferred update mechanism in the GUI software tool, but are instead using dnf or similar. Correct. I have always used dnf (and before that yum). > There are some scenarios where that is not a good idea at present (such as upgrades). It isn't clear if by "that" you are referring to using dnf or a GUI tool. In the general case for most Fedora users I believe upgrading using dnf is probably the *best* idea for an upgrade. Personally I am not a fan of using a GUI tool for updates/upgrades, but whatever works best for *your* specific case is what *you* should use. > There are some machines that require in excess of an hour to safely reboot, due to specialized equipment usage. Think about a medical tape library machine in the middle of moving tapes 200ft to one of the readers, or a process control machine making polyethylene for instance. Interrupting will most probably mean loss of a lot of money, loss of critical data, or an explosion. Unfortunately, virtually all update packages require this highly undesirable double-reboot garbage. Even Windows only requires a single reboot. The only one that may legitiitimately require it would be FireFox, as it memory-maps some files and the devs do not manage their API properly. Changing the kernel is safe, as the one in use is not erased. There is even a userspace tool to detect what is running while not using the updated files, but Fedora does not use it for unclear reasons. Debian/Ubuntu have done this for years, so I have no idea why Fedora is incapable of also doing it. "specialized equipment usage" implies "specialized update/upgrade procedures". Having supported mission critical servers for over 30 years in the medical space I think I can safely say that I understand these issues rather well. > The whole update process needs a fundamental rethink by some non-Windows people. Your wish has been granted! Fedora and its update process were created by non-Windows people! (To be fair, for all I know all the Fedora developers now and in the past are former Microsoft Windows software engineers, but I doubt it.) I suppose if you want to blame the idea of having to reboot to apply updates to something, you could blame it on an OS that predates Microsoft such as VMS or Unix (System V or BSD). Not trying to exonerate Windows, just pointing out that if you want to do some Windows-bashing, there are probably better targets than its update mechanism. >> 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. [Above was mis-quoted - it was "said" by me, and I have corrected.] > That also comes for free as a built-in part of both BTRFS and ZFS. I will grant that I could backup multiple servers to a single server using zfs or any other system that provides deduplication to achieve this. > 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. >> > Given that there are extremely few machines that do not have a lot of excess CPU cycles available today, I'd like to see some proof. That may have been true 40 years ago, but not today. There was recently a situation with, IIRC, Ubuntu and either snap or flatpak where Firefox startup times were considered to be unacceptably slow. The reason was decompression. Single example and it may not apply to others. (And again, to be fair, my understanding is they addressed the performance issue by using a different compression algorithm that would decompress faster, so the end result is still a compressed software package.) > 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* L> system if you meet the requirements. > > I think that the point is that it should be the default, not a one-off for one of my systems. Otherwise, the next kernel update, being unaware of my custome hack, will mess up. I think the point is that this is a matter of opinion. I prefer the existing scheme, and do not want to keep snapshots. I believe I am in the majority, but I could be wrong. If Fedora were to decide to implement your snapshot idea as the default, I would either adapt, reconfigure to the current behavior, or switch to a distro that better fits my needs and desires. _______________________________________________ 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
