Comments inline in blue (sorry to any monocolour readers on this list):

On 2023-02-24 12:20 p.m., Go Canes wrote:
On Fri, Feb 24, 2023 at 9:31 AM John Mellor <john.mellor@gmail.com> 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.
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.
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?
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.
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.)

I assume that you do not use the Fedora-preferred update mechanism in the GUI software tool, but are instead using dnf or similar.  There are some scenarios where that is not a good idea at present (such as upgrades).

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.

The whole update process needs a fundamental rethink by some non-Windows people.

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.
I've done two of these in past lives, but no longer have the time now.  Its literally a ciouple of hundred lines, including command and option decoding.  Student term project?
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.
That also comes for free as a built-in part of both BTRFS and ZFS.
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.
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.
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.