Well, I'd love to be able to drop a bunch of 8GB (notably FAT doesn't support files this big) LiveDVD disk images on a bare file system and see them in the computer's built-in boot-menu immediately. I already enjoy the fact I don't need a traditional boot loader (like GRUB) to handle multi-OS as I can have 2 independent EFI boot partitions (one for Windows and one for Linux) and use the computer's boot menu too choose which to boot from.
Ideally the whole OS should be just a read-only boot image and a traditional partition should only be used for config/data files IMHO.
You don't need 2 EFI boot partitions for this -- you can have multiple boot loaders in the same EFI partition, each with its own entry in the boot menu. In fact, this is how I boot: the default entry boots the linux kernel directly from the EFI partition (some UEFI implementations require the kernel to have a .efi extension, others don't), and I have separate fallback entries for refind and shellx64 in case I need to boot with different kernel parameters.
Different systems have different constraints. For example, loading the firmware interface on my systems so it can present a boot menu is way, way slower than rEFInd or Grub. And presents an ugly menu in a non-native resolution for my monitors. And doesn't let me override kernel parameters adhocly at boot time if needed (thought it has been a number of years since I have, I'm reluctant to let go of the option).
Pop!Os uses systemd-boot (formerly gummi-boot) by default if you're on an UEFI system, and only falls back to GRUB for legacy bios.
Arch is also much easier to setup on systemd-boot.
The issue is that GRUB still has a very compelling support matrix - it'll work basically everywhere, and with most all configurations. So if you're already running a batteries included distro, where someone else is doing most of the configuration and the downstream systems are hugely variable (old consumer hardware) - then GRUB still makes the most sense.
ExFAT can support those. You could also use the UDF file system.
> I would rather use Ext4 everywhere for everything. Is the problem preventing wide adoption of Ext4 GPL?
The BSDs don't support ext{2,3,4} particularly well, and Linux doesn't support FFS/UFS particularly well. I mean, there's support for these things, but it's far from complete or perfect and it's taken a long time.
It's just a fair amount of effort to implement filesystems well, and there's very little tolerance for errors. Ext4 isn't spectacularly complicated, but it's not exactly a simple FS either. I think that has more to do with lack of support than anything else: lots of effort for not all that much practical benefit.
And ext has plenty of documentation and they haven't implemented that either.
So I think keeping down the software complexity is the more likely method. Down to
1. The limited software investment these companies make (often just buying and reskinning firmware from AMI)
2. The limited space available on the ROMs due to hardware cost savings (e.g. companies have had to drop GUIs or support for less popular APUs to add support for new generations of mainstream CPU in firmware updates)
Although very complex and very undocumented, NTFS has actually been adopted very widely and quite reliably. Most of the pre-smart TVs and set-top-boxes can read FAT and NTFS USB drives which makes NTFS the only choice if you want movies exceeding 4 GiBs.
Atomic updates and not getting corrupted if the power is pulled/lost while the filesystem is being written to.
So, not a problem, with the huge advantage FAT can be implemented/validated/etc in a few dozen lines of code.
KISS
LVM appears to solve this issue as well as the related issue of only supporting a limited number of partitions in BIOS.
The only snag is swap, which I don't believe can be on a subvolume.
vgchange is a struggle for me, from the first time I saw it in HP-UX.
Linux can make swap a regular file, even. It doesn't need to be a partition.
Google result shows: https://wiki.archlinux.org/title/swap#Swap_file
The problem is less about linux being capable of encrypting/protecting the swap file and more around being able to assure that is true. So like many Linux kernel issues recently its less technical, more political.
So, as I mentioned previously its entirely possible with off the shelf distro's to enable encrypted swap, the average user just has to choose between hibernate, assuring the swap is secure, and secure boot. Its a bit irritating, but seems to be low priority as the focus seems to be on suspend or hibernate without secure boot.
there's also some limitations, see https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#swapf...
So I'd rather use EXT3 or NTFS because of Journaling, and not FAT.
Right now at Aurora
- FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader that FAT doesn't support?
- Yeah in an ideal universe we wouldn't have to deal with PE binaries and we wouldn't have to deal with the Windows 64-bit calling convention for jumping into the firmware and also we've solved all of this shit and it just isn't a big deal any more. We can look at any platform and complain about the implementation details, but at least this one is better documented than the BIOS interface ever was.
In summary: Linux has to boot on computers that exist, and most computers that exist have UEFI. The Linux community has had the opportunity to make meaningful improvements to the UEFI spec in a way that wasn't true with BIOS. UEFI isn't ideal, but it's better than what came before in this respect.
[1] Partitions could be identified as "Linux", but that gave you no information about what they were or where they should be mounted. Current systemd-driven development has allowed us to define the partition mount point as part of the GPT data, which means they can be automatically mounted in the correct place without static configuration about partition layout