This is the first time we have done a video review/overview of a project that was added to the website, we hope to continue this when other changes are made on the website.
Today, we’re exploring secureblue, a project aimed at addressing security concerns in traditional Linux distributions by significantly hardening existing components and systems.
Have you tried secureblue? What do you think of the project now that we’ve done a comprehensive overview of it?
Looking forward to hearing everyone’s thoughts on this new style of video!
about the title
I understand that secureblue isn’t technically a Linux distribution, but we’re using it in this case because it will help the video appeal to more people.
There have been Cryptpad and Onion Browser reviews, but this is the first video review.
It’s not hard to tell that I really like it! GrapheneOS has looked favorably on it, so I’m looking forward to see if secureblue will be an option for Linux VMs on GrapheneOS desktop mode!
I think these video reviews are a good way of concisely summarizing why something may be recommended. This kind of (shorter) video is also imo easier to share with many people than telling them to “go to Privacy Guides and read this article”.
I’ve been using fedora workstation for about four years now (i switched to Linux during the Covid-19 pandemic) for sector specific reasons I moved to using mainly Ubuntu desktop while retaining fedora for personal use cases. About a year ago i heard about Secureblue from the GrapheneOS community.
Since then i have on occasion taken Secureblue for a test run on a spare machine. Unfortunately, I cannot replace my existing Ubuntu install with secureblue without some overly complex distrobox configuration. On the upside there is nothing preventing me from installing Secureblue over my fedora workstation install (except time and comfort with my current setup).
I currently use Aurora which is one of the main projects coming out of the Universal Blue effort. UBlue is actually the source of Secureblue as they provide the base images that several other projects take and customize to their liking. I don’t know how dependent Secureblue still is on UBlue’s images, but that is where they got their start and all of their work is enabled by cloud native technologies and methodologies.
In all, its a cool project but it makes too many sacrifices for my use case. That’s why I’m in the middle with Aurora where I get a lot of the same benefits like the atomic image, Homebrew, emphasis on flatpaks, and community of users all using the same image, without as many tradeoffs.
Still super happy to see Secureblue is starting to get recognition!
I agree only because I have esoteric hardware (Asahi Linux user lol), which I hope atomic distros get better at supporting in the future.
Other than that I do strongly feel that they are no more of a hassle or complicated than regular distros, they are just a different hassle than people are used to, which makes switching difficult. It’s why I like to recommend Silverblue to new Linux users, who have to learn new paradigms anyways, more than existing ones.
I mean it took me years longer than it should’ve to understand and embrace Docker and Ansible, just because relearning how to do things you can already do sucks.
Question: how is secureblue (or any atomic distro) for gaming? I do play Guild Wars 2 on steam (currently on fedora WS) and it runs perfectly on any distro that I tried, from Ubuntu to Arch.
I just don’t know how the atomic system would handle that, is it just like any other Linux distro?
Staying with Workstation. Insecure but private.
SecureBlue is a little less insecure, private, and a hassle.
If SB was just as secure as Android, I would give it a try.
I don’t know how Secureblue would handle gaming, but Bluefin and Aurora should be mostly fine, and Bazzite is literally a gaming OS that started as a SteamOS clone. All are custom images of Fedora Atomic Desktops.
This video finally nudged me to try it on my laptop, and I’m really enjoying it so far!
Most things I need are working properly, and if not, they can be configured easily. Only complaint is how there is no straightforward way to allow specific container repositories in the container policy, but that’s easy enough to fix manually for now.
If you find something that is a manual fix for you, consider contributing with that fix upstream! The nice thing about atomic images is that everyone else is using the same OS as you. That means you’re fix will fix it for everyone else and it will become part of the image overall rather than just being something you maintain. The cloud native approach makes it much easier for users to contribute improvements because at its core all yours doing is editing a containerfile.
For this particular case, it’s not necessary, since it already has an open issue with suggestions for implementations. Also, fun fact, this particular issue was made by this forum’s own @dngray.
But for future issues, I will try to contribute, if possible.
