Afaik yes, the token is keyed to a specific source in the case of verifying through a website, but from what I can tell, that doesn’t stop someone else from creating a separate malicious website (or git repo) that looks similar but contains malware, and publishing that as a verified app with a similar name as the real app to flathub (so there would be multiple versions of an app, with only 1 being the “real” one on flathub).

If a new user installs malware from flathub while trying out mint for the first time, they’ll probably blame mint instead of flathub. Nobody will say “damn, I should have listened to that warning” while their “discrod” app rm -rf’s their entire PC away, they’ll instead claim Linux is crap and go somewhere else. Doing this helps keep mint safe, and definitely encourages unverified FOSS apps to hurry up and get verified.

This is a great start, but tbh, I’m not fully sold on “verified” flathub apps. Verification requires a token to be placed into a source repo or a website, but there appears to be nothing on actually verifying that the source/site are the original creators. So, for example, if someone packaged a malicious version of librefox and established it under io.github.librewolf-community instead of the canonical io.gitlab.librewolf-community, I’m concerned it’ll still show as verified (though quickly removed). The process can be read about here.

The cheapest you’ll find that is still pretty good for HDDs is serverpartdeals. They have recertified Seagate Exos X22 20TB drives with 2 year warranties for $215. They also offer new drives with the full 5 years, ofc. Exos can be a little loud, as with other enterprise drives. You’ll still need a way to read from it in case you don’t have a spare drive bay, too.

Removed by mod

ostree is based on OCI images, the basis for containers and the like. “Rebasing” just refers to swapping out the OCI image containing your root with another.

I know ssh -X works fine in a rootless podman container, and so does waypipe. I’d be shocked if xpipe didn’t.

Not everything should be flatpak’d. In your case, xpipe (and in the future, waypipe) should always be installed in a docker container containing your normal “mutable” OS. It’s why Fedora is evaluating Ptyxis: when you open a terminal, instead of defaulting to your immutable root, it can be set up to go to a container which has your home mounted but a traditional, mounted root.

Don’t feed the trolls :)

I think a true arch linux experience can be done with immutable distros by modeling themselves after something like a nixos config or an rpm-ostree treefile. Like, during bootstrapping, you’d feed in a config file which would install everything into a future RO root. Would definitely be a lot of work, though, since pacman does (and probably will never) have the capability to manage multiple read-only roots.

You don’t have to install everything as a flatpak if you don’t want to. You can totally install most things in a rootless distrobox container, then use distrobox export (if you’re using distrobox instead of toolbx) to get a nice desktop entry. It’s how I run VSCode and Quartus Prime, for example.

There have been at least 1 PoCs for arch linux based on ostree: https://wiki.archlinux.org/title/User:M1cha/Install_Arch_Linux_inside_OSTree

In addition, VanillaOS’s ABRoot has been packaged through the AUR

SteamOS3 is immutable and arch-based. You can see a fan-recreation of the image builder here

Otherwise, you can use the alpine linux immutable root with atomic upgrades guide.

Generally speaking, though, pacman is really basic, and the majority of the atomic/immutable magic happens in the package manager. That’s why only existing, complex package managers such as rpm-ostree (which shares a code base with DNF) have full support for it.

I used to be a Kagi subscriber because I believed in their image for Orion. Their strong views on privacy, imo, directly conflict with their action to keep the product closed source “because it’d slow them down”, so I ended up unsubscribing. Good to see I unsubbed just in time.

Config files are still editable. Most of them (rpm-ostree, for example) have a mechanism for managing packages, and subsequently rolling back if anything goes wrong or completely resetting, and leave /usr/local writable. For stuff like development and working with compiler toolchains, you should be using a container. I use vscode exported in a distrobox running Fedora 40, for example.

I’ve heard good things about actual. Doesn’t sync with banks automatically, though. SimpleFIN support is in early stages, so it’ll come soon™.

I’d love to see a complete CAD package that feels more in line with Inventor. Ondsel is definitely getting there, but it’s PDM (like git, but for parametric CAD) is still closed source and not self-hostable. Their git repo is also a bit confusing. Apparently part of their patchset on the “flavor” branch they ship isn’t open to the public? Still, nice to see a (partially) FOSS solution.

Wasn’t this article posted 2 days ago?

It’s funny, because there was research done by UC Riverside which specifically figured out LTS branches receive patches for CVEs significantly later than vendor specific branches. Specifically:

Interestingly, we note that the picked CVE patches appear in distributions 74.2 days earlier than LTS on average;

They also conveniently left out the part of Greg KH’s opinion stating that he recommends the use of vendor kernels over stable/LTS branches, too.

I found this particularly funny:

It all comes down to a delicate balancing act between security and stability. Some top Linux kernel developers and CIQ are coming down on the side of security.

Now I know CIQ is “supposedly” different from rocky, but what is CIQ going to do, break bug-for-bug compat and use stable kernels in their supported version of Rocky? This entire article feels like it doesn’t fundamentally understand that not all bugs (especially ones that lead to potential low-ranking CVEs) aren’t worth patching.

Most tutorials I can find involve enabling the steam cli, then using steamdb to look up the “depots” of previous versions and downloading the old update in chunks, then unpacking and copying the old game files to your install location. Not exactly convenient.

In my particular case, I just didn’t know it was enabled (my modding guide mentioned a way to stop it, but I guess I did it incorrectly). The game hadn’t received updates in half a decade, and I don’t really use Steam for anything else. Apparently, I wasn’t the only one in that boat.