Though this doesn’t mean that the whole CERN IT infrastructure is being moved. The migration is specific to the accelerator control layer—the front-end computers that talk directly to the equipment running the beam.
Note that earlier reporting was wrong to suggest all of CERN was moving to Debian. People at CERN clarified that only a small part of CERN is switching.
They don’t. DHH is a rich guy with rich friends. This is just friends donating to a friend’s project to show support.
And that also means that the CEO of 1Password really has no problems with DHH as a person, those who talk about Omarchy being revolutionary/special or anything like that at best have rose-tinted glasses.
I agree in some respects. If you have something like Gnome with 6 month development cycles, you are kinda encouraged to push features even if they are not ready, otherwise you have to wait 6 months to try again. And as we’ve seen with stuff like triple buffering, it was painful. It was almost ready, missed the cycle, then other Gnome changes were made, then it had to be rebased, then go back to step 1.
With a shorter cycle, missing a cycle isn’t as big of a deal and in theory you can polish it more without it being the end of the world.
But Firefox already had a monthly release cycle. I don’t see how going from a monthly to fortnightly is really that different.
I like Fedora Atomic with bootc for this reason. While Nix language is quite confusing and gets even more confusing when you find online advice that has a different setup than you that introduces compatibilities, bootc is just an OCI containers that I can run bash commands in to get stuff set up.
It’s still not one-to-one. Generally, I find that using bash to set things up makes more things easier than harder compared to Nix. Though Nix does make some stuff simpler.
That being said, I haven’t tried NixOS in a while. I’m sure that with a decent LLMs, today its easier than ever to make a competent NixOS config. I’ve been meaning to try, but haven’t found the time.
Phoronix’s more real world testing didn’t have Gnome performing badly: https://www.phoronix.com/review/cachyos-desktops-july-2026
Doesn’t KDE kinda have that same refresh rate issue on Wayland? I remember seeing a bug that Qt has a limitation in this regard, In the video I saw the workspace transition ran at the lower refresh rate when multiple monitors were used.
Thankfully I stopped using multiple monitors so I can’t personally confirm.
Personally, I wouldn’t recommend Vanilla OS.
That’s a lot of churn and issues for such as young project that advertises itself to new users.
Personally, I wouldn’t recommend Vanilla OS.
That’s a lot of churn and issues for such as young project that advertises itself to new users.
Wonder how much of that is going towards Hyprland: https://omarchy.org/news/2026/08/omacom-foundation-to-be-exclusive-hyprland-sponsor/
You absolutely can sandbox using SELinux. Red Hat even has a tool called “sandbox” for just that: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-security-enhanced_linux-securing_programs_using_sandbox
Edit: and Android sandboxing is built heavily around SELinux: https://source.android.com/docs/security/features/selinux
I don’t believe the Steam flatpak is responsible for those issues
openSUSE recently added some more security policies. By default, Wine cannot run normally. There’s a package you can install that sets SELinux security policies to allow it to work. If you install the openSUSE Steam rpm, that security policy automatically gets installed too.
This is a downside of flatpak’s approach to sandboxing. It aims to work everywhere on every distro, using bubblewrap instead of something like SELinux or AppArmor. But it also does not interact with AppArmor or SELinux, so if they block something, flatpak can’t override that.
Meanwhile, snap uses AppArmor for sandboxing. So even if there was a policy like openSUSE’s that prevented Wine from working by default, since snap speaks AppArmor, it can give itself the necessary permissions to make Wine work.
Bazzite uses the Steam rpm, not flatpak.
Though I think other launchers like Heroic may be flatpaks. But that’s no different to SteamOS.
I don’t think so, this still would let them host it so long as don’t have a “competing fork”. I’ve heard of licenses like Server Side Public License (SSPL) that do you what you say. Basically, that license requires all the infrastructure around the software to be open source to. So something like AWS couldn’t host the software without first open sourcing all their infrastructure.
The main issue is that old Boxes is based on SPICE. It was/is a Red Hat project, but they stopped caring for it and deprecated it. So old Boxes is built on legacy tech that will pretty much just bit rot over time.
Something strange with the March 2026 results was that it had two new distro entries, “0 64 bit” at 17.60% and “64 bit” at 8%. In April, one of those entries disappeared and the other’s share dropped significantly. In May, both were gone entirely and Linux was back to a more reasonable marketshare of 4%.
Overall probably closer to the truth.
I wish people didn’t obsess over these large numbers as much. Like when Linux suddenly hit 5% on Steam when that was clearly just an outlier and was destined to fall right back down.
We’ve heard from a lot of developers working on lower level system components that on package-based systems they can easily install niche command line tools for developers.
…However, after some discussions with the Flatpak developers, we have a plan for how to approach the distribution of third-party tools and we’ve already began prototyping. We’ll share more about this soon in a dedicated post.
I hope this system at least shares runtimes with Flatpak or else I will be severely disappointed. I’d be giddy if it’s actually a case of flatpak offiically supporting CLI tools. It already does, and does it well, just missing a tiny bit of plumbing.
deleted by creator
Certainly an interesting vulnerability, but one you shouldn’t worry about.
If you do really care about sandbox security, the first thing I would recommend doing is globally blocking filesystem access to anywhere in your $HOME that runs script code, such as:
I have a script that I use to control flatpak overrides and I do something like this:
# paths to block
GLOBAL_RESTRICTION_PATHS=(
"~/.bash_logout"
"~/.bash_profile"
"~/.bashrc"
"~/.profile"
"~/.ssh"
"~/.zshenv"
"xdg-config/zsh"
"~/.local/bin"
"xdg-config/systemd"
)
# globally block these paths
for path in "${GLOBAL_RESTRICTION_PATHS[@]}"; do
flatpak --user override --nofilesystem="$path"
done
# but allow some apps like text editors to access them
for path in "${GLOBAL_RESTRICTION_PATHS[@]}"; do
flatpak --user override --filesystem="$path" org.gnome.TextEditor
done
It can get run automatically by things like Gnome Software.