TPM is used for measured boot. Measured boot can check various parts of the system to ensure they are the expected values haven’t been tampered with. You don’t want a part of the system to be replaced with malware and not realize it.
If it detects something changed, it won’t release its secret. It may signal to you that something malicious was done or something benign that the OS updated didn’t account for.
TPM unlocking FDE is complicated for me. I fully understand measured boot and support it, but it seems less secure to me than manually unlocking the disk.
Once the disk is unlocked and you’re put onto the display manager, I feel like there are many more vulnerabilities that could be exploited to gain access to your data.
With manually entering the disk password, the data is locked. You either need to brute force it or use the XKCD wrench method.
So I feel TPM+Pin is the best for security. Unfortunately Aeon, which is based on OpenSUSE and implements TPM, doesn’t support TPM+Pin. I think it’s mainly due to how poor and widespread TPM support is. It could lock you out entirely.
Not any PiP window, only ones that use the protocol. Firefox should use it. Though I'd be surprised if there wasn't some Kwin extension to automatically make the PiP windows always on top like the extension you mentioned or the Gnome "PiP on top" extension
I didn't say people were forced to use snap, just that they're the default. But if they're to be made the default, they should be a good experience.
As for the sandboxing stuff. Ubuntu using AppArmor, a Mandatory Access Control (MAC) that is used to make the system more secure by creating profiles used to confine certain pieces of software. If they try to do something the profile doesn't allow them to do, it gets blocked.
Snap uses AppArmor to manage the sandbox of snaps. However, AppArmor isn't the only MAC around. Fedora and OpenSUSE use something else called SELinux, which has a similar purpose. But snap doesn't speak SELinux, it only speaks AppArmor. So none of the fancy AppArmor profiles used to contain snaps actually work on those distros, the sandbox it does have is so weak it's insignificant. Canonical could have addressed this by adding SELinux support to snap, but they haven't, they pretty much only care about Ubuntu and Debian. And as I mentioned before, Ubuntu patches AppArmor to add more functionality. But they have failed to upstream these patches, so only Ubuntu (and maybe Debian?) have access to the strongest sandboxing snap can offer.
On the other hand, flatpak uses bubblewrap to sandbox its applications. Bubblewrap uses standard Linux security features to sandbox apps rather than a specific MAC. That means the flatpak sandbox is strong regardless of which distro you are using. Although it does have some downsides. Flatpak doesn't speak to either MAC, which can be a problem since the MAC can confine the flatpak application more than is expected. For example, OpenSUSE ships some SELinux policies that allows Wine/Proton to function as expected. However, these policies don't get installed when you use Steam or any other launcher as a flatpak. It's something you have to do manually. Meanwhile if flatpak actually talked to the MAC (like snap does with AppArmor), then this wouldn't be a problem.
By far the worst part about Ubuntu is snap. Canonical has failed its community and the wider Linux community with it in so many ways.
For Ubuntu users
For wider community
There are other smaller controversies, like Mir, Unity, and Upstart, but none are as bad as snap.
There’s still plenty of inefficiencies to criticize.
Yup, just another hot fix update. There's been 4 of them so far this series. 1.21.1, 1.21.3, 1.21.7, and now 1.21.8.
A system that has updated from say Ubuntu 16.04 to 24.04 is different from a system that fresh installed Ubuntu 24.04.
The upgrade process is imperfect. It may keep older software around, old configuration files. Users may also make small tweaks and forget about them.
I remember like a year ago OpenSUSE Tumbleweed broke for users who had old installs. They were using the old networking stack, the upgrade system never migrated them to the newer networking stack. And since OpenSUSE’s test suite was only made up of new installs, the issue wasn’t caught until after it was released.
Fedora Atomic tries to solve this issue. When you update, the entire root filesystem is effectively replaced (the immutable parts anyway). Though it tries not to touch manual changes you make in places like /etc. It does something called a 3 way merge to preserve your changes and does keep better track of them than traditional distros.
I think I had this bug before where I had to change the tty to actually get into the graphical environment.
I used Aeon before, it wasn't bad. The default apps were better than Fedora Silverblue's (it had Tweaks preinstalled, didn't have Firefox installed as an RPM). It uses Distrobox rather than Toolbox, which is nice because Distrobox lets you specify a custom home for each box. Though Distrobox hasn't seen any development these past few months and their decision to use POSIX compliant shell script seems like a maintenance nightmare. Toolbox uses Go.
But my biggest problem with MicroOS is that I don't feel like the update mechanism is as robust as Fedora Atomic. At the end of the day, it's using zypper and btrfs snapshots. It doesn't have the same protections against configuration drift, you can only rollback to versions of the OS you've previously installed (with Fedora Atomic you can rollback to any specific commit, even ones you've never installed).
And Fedora Atomic's bootc is super nice for customizing your image.
Personally, I am not a fan of this proposal. I'm one of the few people who actually like Fedora Flatpaks. I like
Though they're not perfect. Perhaps the biggest issue is the lack of codec support. Personally, I think it would be better to rework this proposal to instead filter out the footguns in the Fedora Flatpaks, such as media players and browsers.
I also don't believe there's any plans in the proposal to allow the user to easily remove the filter in the GUI, even though there is a toggle to make Flathub available in the GUI. The two proposals would in effect make it more difficult to obtain software curated by Fedora.
A recovery code. I did a test install of Aeon and was given the code: dhnhlgc-fbndjbni-ufrkcfnk-nfebvtut-ftkkiiur-tijidtub-hujnucgu-erduhije
64 digits, but only alphabetical and a certain subset (16/26) due to weirdness of keyboard layouts.