Then use openSUSE Aeon, I don’t remember when was the last time I needed to touch the terminal.
2 Likes
I do appreciate the recommendation although i am happy with Bazzite that i’ve been using for quite some months. It’s still nice to see more immutable systems popping up.
I understand not wanting to use the terminal, but I’m not sure what learning to code has to do with this. I use CLI and TUI applications more than GUI ones, but I’m not a programmer (unless you count Nix lol).
I’ve meant coding in a broader context of my life. I’ve tried it in past as at first i was curious about the subject, but it turns out it wasn’t what i thought or wanted.
This does require the terminal, but had you enabled Xwayland?
ujust toggle-xwayland
That and the toggle for CUPS so I could use my printer were the only things I explicitly needed to do with the terminal. (After the stuff you’re supposed to do in terminal after install of course)
Altho if you want access to unverified flathub packages, you’d need to do some terminal-fu as well.
Maybe one day they’ll GUI-ize the ujust quick functions, but yeah I think for now if you want a very hands-off GUI experience, the best options are Bazzite, Bluefin(Gnome)/Aurora(KDE), or Aeon. 
Something I’m wondering tho… For people who have tried both, what’s the draw to Aeon over Bluefin?
1 Like
I don’t think this is the case in practice (at this point in time).
“Most Normies” will want/need to install at least some software, much of that will be available as a flatpak, but if even one package you want isn’t available as a flatpak (and many aren’t) its highly likely they’ll need to use the terminal, and in those situations an atomic distro will often feel more–not less–complex than a traditional distro, particularly for less tech savvy users. Because choosing how to install software is a much more considered choice, with an order of preference, with pros/cons and limitations.
A very common example relevant to our community would be installing a VPN client like Mullvad or ProtonVPN.
Atomic distros aspire to be dead simple and rock solid, but that is a very aspirational goal, that is far from realized (in my experience).
The way I see it – Linux atomic distros as they are today, are simpler/harder to screw up for contexts where the inexperienced users are only users (e.g. a kids computer, library computer, school computer) but not in situations where the inexperienced user is also the admin.
Something I’m wondering tho… For people who have tried both, what’s the draw to Aeon over Bluefin?
Aeon = Simple / basic / quite minimal starting point. More of a focus on security from what I’ve seen. Also some cool early-boot security mechanisms like TPM-backed FDE & measured boot (if your system supports it, unfortunately many systems don’t (including my own, and even the developers own)). After Ubuntu, Aeon is the second distro I’m aware of to implement this. Closely related to OpenSUSE MicroOS and Tumbleweed. Uses btrfs and snapshots under the hood.
Bluefin = A more complete and refined out of the box experience with more pre-installed, a little less basic/minimal. The developer has a big interest in ‘cloud native’ concepts and tools. Closely related to Fedora Silverblue. Uses rpm-ostree under the hood. Because its based on rpm-ostree and silverblue you have the ability to ‘rebase’ between various cousin distros (other uBlue distros, silverblue, kinoite, etc).
I’ve used both (Aeon RC1|2|3 until it broke (on the first update after RC3) as well as Silverblue & BluefinDX (developer edition) and I liked both. Aeon and Bluefin are both opinionated but in differing ways. I wouldn’t call one objectively better than the other. There are aspects of each that I prefer over the other.
@RoyalOughtness could probably speak to the sub-surface technical differences better than I can (Assuming they are familiar with Aeon or MicroOS).
1 Like
I think this is generally true, but I will say that a great deal of the time you can get away with either Flatpaks, or rpm/deb getting auto-launched in BoxBuddy for installation, assuming you’ve setup debian and fedora distroboxes in it.
Also on the topic of VPN’s (Altho this doesn’t really have anything to do with your actual point, which is very valid), I feel like Gnome’s out-of-the-box experience for adding OpenVPN or Wireguard VPN’s directly thru the Network manager is pretty intuitive - and all GUI-based.
I would argue that specifically when referring to “Most Normies”, Flatpaks/RPMs/DEBs will be all they will ever need/run into. And in that context it seems to me Aeon(Once fully “Stable”) and any of the UniversalBlue(Except uCore of course) projects can be used terminal-less.
2 Likes
For basic functionality it is (or can be). But if you go that route–in my experience–you are much more limited in the features/capabilities available to you compared with the official client from your provider (if they have decent linux support).
Some things can be done manually (such as custom firewall rules to create a ‘killswitch’, but this requires some mildly to moderately complicated steps which surpass the complexity of just installing the client via the terminal). Edit: just remembered Aeon doesn’t ship with a firewall either.
In many cases features like split tunneling, multi hop, custom dns stuff, automatic switching of dns settings, “soft” killswitch, and various other features can be more difficult, or less easy/convenient when not using the official client also.
Ideally I’d prefer using just the native built-in OS tools for VPN connections, but as it stands right now, it feels I have to give up too many useful features, and ends up being more of a mental burden while still feeling more limited. That said, I think if all you want/need is a simple VPN connection to a single server or a small set of servers, with no frills, no killswitch, the built-in OS tools can be sufficient.
I would argue that specifically when referring to “Most Normies”, Flatpaks/RPMs/DEBs will be all they will ever need/run into.
I think that is ~95% true, but that last ~5% still represents a meaningful barrier. In the same way that a trail that is 95% passable without 4 wheel drive, still necessitates having 4wd.
In my eyes, the distros most suitable for beginners, and most likely to avoid terminal use (if that is the goal) are still traditional distros. They can use virtually all of the strategies for reliability used by atomic distros (flatpak-first, snapshot/rollback, distrobox, discourage user modification to base system). I believe with time atomic distros will most likely be the go-to recommendation for less-tech savvy and less experienced users, but I don’t think we are there quite yet.
2 Likes
I’m not the right person to talk about either, but I do know that they are not parallel projects.
Bluefin is a specific image of Fedora Silverblue, Aeon is a base project from openSUSE. so Aeon is more analagous to Silverblue or Kinoite than Bluefin.
arch lacks selinux support (outside the aur) and several other hardening initiatives Fedora has worked on and is currently working on. Fedora is a much better base on which to develop a secure system.
1 Like
I actually agree with this strongly. The terminal needs to be completely optional in order for the “year of the linux desktop” to come.
Unfortunately, that isn’t the case today. However, secureblue can do what we can to improve GUI tooling for our own features, which we have in the plans: ([FEAT] Provide GUI config management · Issue #381 · secureblue/secureblue · GitHub).
What @Ganther mentioned made me think it would also be valuable to make a GUI tool for rebasing, since we won’t be shipping ISOs.
We are already shipping images via ghcr. Repackaging and hosting them as ISOs would be redundant.
5 Likes
Yes, your reasoning is fair. Maybe this project will expand in the future to other popular distributions, including Arch.
How should secureblue users install Firefox, Mullvad Browser, Brave Browser, Tor Browser, etc., should users follow the steps here?
Not sure whether this is really a net-positive on desktop. Selinux is only used for a small amount of processes on Fedora, many of which are more relevant to server usage. It is much easier to write and maintain Apparmor profiles and it’s possible to use projects like apparmor.d with a lot more profiles on Arch.
Can you name a few significant ones?
Arch also has a few advantages, like not relying on backports, being closer to upstream versions, offering a hardened kernel and having better package availability. I have a hard time seeing Fedora’s security features weighing this up. I mean I can fully understand why you wouldn’t want to maintain a Arch-based distro, because it might be more work than a single maintainer can do, but I don’t see security as a good reason in this case.
not hardening related but F41 adds one-click usage of OPAL for HW-only or HW+LUKS for disk encryption: Changes/SelfEncryptingDrivesSupportInAnaconda - Fedora Project Wiki
hardening related however we do see movement like:
1 Like
Maybe this project will expand in the future to other popular distributions, including Arch.
Very unlikely. Not only is Arch behind Fedora as a base on which to build a hardened image, it lacks the breadth and depth of tooling and surrounding ecosystem for image building (ublue, blue-build, rpm-ostree, etc)
How should secureblue users install Firefox, Mullvad Browser, Brave Browser, Tor Browser, etc., should users follow the steps here ?
It’s not recommended that you use Firefox based browsers (for security reasons), but if you need them for some reason then yes the link you sent is correct (except for chromium based browsers like brave, which should never be installed via flatpak since flatpak interferes with the much more robust internal chromium sandboxing: Flatpak support | Vivaldi Forum)
2 Likes
Not sure whether this is really a net-positive on desktop. Selinux is only used for a small amount of processes on Fedora, many of which are more relevant to server usage.
It’s a significant net positive, and it’s not a “small amount of processes”. The stock policy confines all system processes. Userspace confinement is being worked on:
Security enthusiasts wanted: from beginners up to SELinux experts to make up the SELinux “Confined Users (SIG)” to foster Fedora’s security capabilities - Fedora Discussion (fedoraproject.org)
SIGs/ConfinedUsers - Fedora Project Wiki
It is much easier to write and maintain Apparmor profiles and it’s possible to use projects like apparmor.d with a lot more profiles on Arch.
I would question the “quantity of profiles” as a viable metric. Apparmoring everything is a huge endeavour, so much so that kicksecure has a dedicated project for it (GitHub - Kicksecure/apparmor-profile-everything: deprecated - maybe replaced by: apparmor.d). I very much doubt very many if any people are apparmoring their arch systems to a point that even compares to a stock fedora install.
Also, SELinux supports CIL policies now, so they’re much easier to write.
1 Like
Arch also has a few advantages, like not relying on backports, being closer to upstream versions, offering a hardened kernel and having better package availability.
None of these are really advantages. “being closer to upstream” isn’t always advantageous security wise. Have a look at xz for a recent example 
. Arch’s hardened kernel is just a brand name for a specific kernel configuration. The Fedora kernel used in secureblue is hardened as well. Better package availability is also questionable aside from not being a security advantage, especially given the existence of distrobox and brew.
1 Like
Ironically Arch was barely affected by the xz backdoor scare precisely because they are closest to upstream, among other reasons. Arch had no funny “extra” sshd patches found in the other major distros (cough cough) that the backdoor relied on.
Yes, I saw that post. Also in this thread it was discussed whether the flatpak package should be avoided for Firefox, like Chromium based browsers.
Anyway, I understand that installing Brave Browser by distrobox, homebrew or layering does not limit or reduce any of its functionality. I remember having trouble adding Brave’s official repository to Silverblue.
You will lose all namespace and chroot parts of FF’s sandbox, by using the Flatpak version.
This won’t happen anytime soon. I used Selinux Users on desktop and it was a major pain and only possible to use if you extend it with your own policies. I reported several Selinux issues and they are still open after a long time. Fedora’s Selinux refpolicy maintainers seem to be struggling to find the time to even keep up fixing bugs. So I don’t see Selinux Confined Users succeeding anytime soon, especially not for the average user.
Which has been replaced by apparmor.d . It’s an amazing project with a great maintainer. Surprisingly many users seem to be using it, reporting issues and even on the weekends the maintainer often fixed issues within a day or so. Can recommend using and contributing to it, for people who can report and deal with Apparmor issues.
Would recommend to try it in a VM. Barely anything runs unconfined.
What do you mean by now? CIL has been used for quite some time. That’s the first time I hear someone say that CIL is easier to write. Usually it’s quite the opposite and most users will only use CIL directly in some edge cases. I mean there is a reason why it’s called Common Intermediate Language:
2 Likes