Intially looked at Bazzite, which seemed great other than I wasn’t a fan of it immutability, I’ve had to remove the read-only property from my steam deck a few times.

Fwiw, Bazzite handles its ‘immutability’ vastly different.

Since you seem to know a lot about it let me ask you a couple of things:

😅. I’ll try my best 😜.

Bazzite is immutable, right? I’m sure I saw that somewhere and Fedora Atomic is also immutable IIRC

It is correct that the contents of / is immutable at runtime aside from /var and /etc. However, note that a lot of folders like /home and /opt are actually found in /var in response. This is later ‘fixed’ with symlinks and whatnot. In effect, only the contents of /usr (aside from /usr/share) is off-limits (or ‘actual’^[1] immutable).

How does the config changes not get overwritten?

I believe my previous paragraph already answers this. But, to be even more elaborate, Fedora Atomic makes use of libostree (read: git for your OS). With this, only the pristine images are ‘swapped’ in-between updates (or rebases^[2]). Your changes to the system are found in /var, /etc and in so-called ‘layers’ only and are not swapped out. Some of these changes are kept track of^[3], but most of them reside in /var and will not be touched by libostree.

The whole point of an immutable distro is to prevent changes to files to ensure things keep working

Kinda. The important part is that changes are prevented for the sake of a functioning system. But the entire system doesn’t have to be locked down in order to achieve this. This does mean that it’s actually not that hard to break your system. Just rm -rf /etc and your system will probably fail to boot into the very next deployment. But, as Fedora Atomic keeps at least two deployments, you will still be able to access the previous deployment in which you tried to delete /etc. So you’re protected from accidental mishaps as long as you’ve got at least one working deployment. Thankfully, you can even pin working deployments with the ostree admin pin command. And…, just like that, the distro has basically become dummy-proof. I’m sure it’s still possible to break the system, but you’d actually have to try 😉.

So, in short, Fedora Atomic definitely intends to be a more robust system and succeeds. But, it does so while giving the user agency (and some responsibility).

How are packages installed?

I think everything of importance is mentioned in the docs. What is it exactly you want to know?

The docs you sent recommend flatpak, which while very good in theory still has a small fleet of apps available.

But that’s just the first of seven “package formats” listed in the docs 😜. The other six will assure that your remaining needs are fulfilled.

Also they suggest using distrobox among other things, that’s definitely not beginner friendly, although an interesting concept for an advanced user to have your main machine be an immutable host to any system you want.

This is obviously anecdotal, but Fedora Silverblue was the first distro that I used. I was a complete Linux newb. My coding background was also just a Python-course on Uni. But, somehow, in the very newbie-hostile environment back then (read: April 2022), I managed with Toolbx. So…, yeah…, I can’t relate. Sorry*. You might be absolutely correct. But, as I said, I don’t recognize this from my own experience. I wish I had a video-tutorial back then, though. Honestly, with the amount of hand-holding Bazzite and its docs provide, I believe a newbie should be absolutely fine.

1. It is even possible to overwrite this. Both in containerfile (requires creating own image) and on device (very hacky, not recommended).

2. Rebasing is the process by which a different image is selected to boot and run your system from. For example, with this, one can switch from Silverblue (GNOME) to Kinoite (KDE) without reinstallation. This can even be used to switch from a Fedora image to a Aurora/Bazzite/Bluefin/secureblue image.

3. These include the software you’ve installed through rpm-ostree (or soon dnf). We call these layered packages, based on the analogy that the packages aren’t part of the image but are magically tacked on without you noticing anything finicky. It’s quite magical. Besides that, any and all changes made to /etc are also kept track of. The former you can see by invoking rpm-ostree status, the latter by invoking ostree admin config-diff.

Isn’t Bazzite an immutable OS with very limited package availability outside of gaming?

Nope. It’s basically Fedora Atomic with a lot of special sauce to make onboarding as pleasant as possible. Especially if you want to use it for gaming; be it as a HTPC/console or on desktop. Thus, like Fedora Atomic, you’ve got access to many different package managers to get your needs covered. Heck, Bazzite and its uBlue siblings actually improve upon Fedora Atomic in this regard (at least by default). Refer to this entry in its documentation for the finer details.

but I’m not sure it would be a good experience for someone just getting into Linux, since most of the help he will get online

We’ve all been faulty of this (read: searching on the internet), but we should instead consolidate Bazzite’s documentation first. Only after it isn’t found there, should one consider going to their discussion platforms; be it their own forums or their Discord server. Searching on the internet is IMO a no-go, especially if one isn’t well-versed yet.

will direct him to edit config files which would get overwritten on update.

This doesn’t apply to Fedora Atomic. Perhaps you’re conflating this with SteamOS.

Aight, got it.

For now, I’m exclusively on Wayland. Though, hopefully Openbox (or something inspired by it) will make the jump so that I can see for myself what all this goodness is about.

Anyhow, it was a lovely conversation. I enjoyed it to bits. I wish ya tha best. Cya, out there. Bye!

Do you have a link for these instructions?

In addition to the template linked by dustyData, there’s also BlueBuild if you prefer YAML over containerfiles.

Very enlightening! Thank you so much!

mouse-centric

This is actually unfortunate for me. I seem to be prone to RSI related aches. Keyboard is fine~ish. But mouse can be pretty troublesome. Do you happen to know if it plays nice with trackballs and/or trackpads?

enabling a lot of the privacy features like resist fingerprinting often breaks login flows

True. Though, in this case, it’s only enabled on hardened. So, the default config doesn’t enable it.

and breaks dark mode detection on site

Yeah, that’s really unfortunate. I suppose there’s Dark Reader. But, I believe Arkenfox’ maintainers held the opinion that a bandaid solution as such did more harm then worth it. At least for those that enable RFP for the sake of fingerprint protection.

Thanks for sharing.

Thanks for the appreciation!

Our goal is to continue the legacy of Mull by providing a free and open source, privacy and security-oriented web browser for daily use.

Do you work on IronFox?

Do you think I could run secure blue from a USB drive?

I’m not sure if it’s exactly the same, but Jorge Castro (one of uBlue’s maintainers) showed how some uBlue projects (perhaps this also applies to secureblue) can be installed on an external drive. Perhaps it’s worth a look: https://www.youtube.com/watch?v=5DRaYQ6hKU0

Yeah, it seems that they even acknowledge that Tor and Mullvad are better for extreme threat models.

"The only browsers that can provide sophisticated fingerprinting protection against advanced scripts are Tor Browser & Mullvad Browser.

If you have an extreme threat model (Ex. Political dissident, journalist, or if you are in some other kind of high risk situation), please use one of those browsers."

I suppose we’d have to commend them for being fair.

Unfortunately, I’ve yet to experience Qubes OS myself. So I can’t help you with that. Wish ya the best of luck though!

I hope at least the earlier problems with distrobox have been solved.

Is your intention to go in the direction of Qubes OS with extra steps?

Yo OP, did it work out in the end?

Thanks a ton for the elaborate answer!

I’ve moved to cachy OS mainly because I needed to get certain things working that were only packaged in appimage

Hmm…, I’m aware that the AppImage situation is pretty dire since it requires FUSE 2 libs while everyone and their grandmothers have moved to FUSE 3; software that’s been almost out for a decade now. Thankfully, I’ve never actually experienced trouble getting it to work on any distro. Sure, installing some libs was often required, but nothing too fancy.

BUT I believe I could have worked it out in Aeon by fiddling around with distrobox

FWIW, I’m 100% positive that you could get it to work on Aeon. IIRC, I’ve also used AppImages through distrobox containers.

I think once there is a mature wayland-based Openbox replacement

Interesting. If it isn’t too much of a trouble, could you pitch Openbox :P for me? I’m not too familiar with it, but you did get me curious.

(eyes on labwc)

Put into my backlog of stuff I’ve got to checkout.

I was hoping that this reply wasn’t needed 😅. In all fairness, some of the replies found on ycombinator definitely offer legitimate criticism. However, secureblue’s dev team didn’t just ignore all of that as they can be found discussing on the very same thread. Since then, they’ve actually implemented changes addressing these concerns. For example:

Trading off possible kernel bugs against letting a whole LOT of userspace software run with real root privilege. And flatpak is a lot of attack surface no matter how you run it, and the packages have a bad security reputation.

This was raised as a good objection to some of its design choices. This eventually lead secureblue’s dev team to maintain twice as many images for the sake of offering images in which this was handled differently. And it didn’t stop there, it has continued to output a lot of work addressing concerns both found on that thread and outside of it. Consider looking into its commit history. Heck, even some of the GrapheneOS-people have provided feedback on the project.

Of course, no one dares to claim it comes close to Qubes OS’ security model. Nor is this within scope of the project. However, apart from that, I fail to name anything that’s better. Kicksecure is cool, but they’ve deprecated Hardened Malloc; a security feature found on GrapheneOS and that has been heavily inspired by OpenBSD’s malloc design. By contrast, secureblue hasn’t abandoned it. Heck, it elevated its use by allowing it to be used with Flatpak; something that hasn’t been done on any other distro yet. This is just one example in which the secureblue dev team and its various contributors have shown to be very competent when it comes to implementing changes that improve security beyond trivial checkboxes.

Peeps may name other hardening projects. But fact of the matter is that I’m unaware of another hardened Linux project that’s quite as feature-rich:

• Tails; cool project that does wonderful work against protecting one against forensics. But that’s literally it. It’s not even meant as a daily driver.
• Whonix; developed somewhat together with Kicksecure, so this one actually has put in substantial work into hardening. But, again, not meant to be used as a daily driver.
• Nix-mineral; cool project, but it’s still alpha software by its own admission.
• Spectrum OS; great idea, but it’s not even out yet.

Please feel free to inform me if I’ve forgotten anything. So, basically, if you want a hardened daily driver for general computing, then one simply has to choose between Kicksecure and secureblue. I wish for both projects to flourish, but I’ve stuck with the latter for now.

Do you run Steam inside gamescope as well ?

Nope I don’t. But that’s because running Steam isn’t really a thing for me to begin with. I don’t own my games through Steam aside from a couple that are only accessible through it. Whenever I need to play those, I access those through another system; be it another distro or (God forbid) M$. For the games I’ve played on secureblue, none of them were owned through Steam. Hence, running Steam inside gamescope has not been something I had to do yet. Unsure, if it even works as supposed.

Does your setup support casks ?

I actually don’t know. It probably doesn’t, though. EDIT: Found the following within Bluefin’s documentation: “Note that the cask functionality in homebrew is MacOS specific and non functional in Bluefin, flatpak is used instead.”

That was a great read. Wonderfully detailed. Thank you!

It’s a pity that it went down like that. Would you say that a properly matured openSUSE Kalpa would be your perfect setup? Out of curiosity, have you used projects related to Fedora Atomic for long periods of time? If so, how would you compare them?

I’m glad to find that the general perception on CachyOS has definitely changed for the better. I believe it was two or three years ago when I stumbled upon CachyOS for the very first time. I don’t think it did anything noticeably different back then compared to now. But as it was still relatively new, people didn’t quite jump on the bandwagon. As such, I actually received quite a bit of condemnation whenever I tried to recommend the distro to others. I’m glad to see that it’s currently flourishing. Congratz to the CachyOS team for sticking to their guns. Whenever a product is good, it will eventually receive recognition.

I put it on my partners computer after Aeon crapped itself and put the system in a boot loop until I switched the hard disk out.

It is only release candidate software. As such, I didn’t have high expectations. However what you’ve described here is pretty troublesome. And I’d imagine your partner didn’t do crazy stuff that would justify such a reaction by the OS.

I’m personally very interested in the future of openSUSE Aeon. So far, I’ve mostly seen positive reactions. Therefore, a negative experience as such really piques my interest. If possible, could you elaborate upon what had transpired before the system broke? Or perhaps your partners personal experience with the distro in hindsight.

Try invoking ujust distrobox-assemble first. This command is also found on the FAQ page. Enter the container created through this method.