Avatar

Darorad

Darorad@lemmy.world
Joined
8 posts • 53 comments
Direct message

You’ve been hearing about it because there’s been a lot of pushback at all stages of them doing it. That doesn’t mean it won’t happen, they’ve kept pushing for it and there’s no indication they won’t go through with it.

permalink
report
parent
reply

I don’t see the gva anywhere in that article and the numbers in the CNN article are pretty close to the numbers NPR was able to verify

permalink
report
parent
reply

SteamOS is based on arch, but it has major differences. The steam deck’s update mechanism is completely different from normal arch Linux.

Arch normally immediately updates to the latest version of every program. This is usually fine, but when a big bug is missed by the developers, it can cause problems.

The steam deck updates a base image that includes all the programs installed by default, and by the time it releases a lot of them aren’t the absolute newest version. When valve updates SteamOS they definitely run a lot of tests on the base image to make sure it’s stable and won’t cause any issues.

SteamOS is also an immutible distro, meaning the important parts are read only. This also means updates are done to everything at once, and if something goes wrong, it can fall back to a known good version.

Not to say arch Linux is unstable (its been better for me than Ubuntu), but SteamOS is at a completely different level. It’s effectively a completely different distro if we’re talking about stability. I think what they’re hoping is this support would allow arch to build out testing infrastructure to catch more issues and prevent them from making it to users.

permalink
report
parent
reply

Yeah, imo the problems solved by using snaps for core system stuff are better solved with immutable distros, and I see very little reason to use snaps for anything else.

permalink
report
parent
reply

Yeah, sorry couldn’t resist.

snaps are very similar to flatpaks and, honestly, is technically better in a lot of ways.

Snap can be used for basically an entire system, while flatpak is limited to graphical apps. (Ubuntu core is built basically entirely off snaps.)

Snap is controlled by canonical, and the backend for the snap repo is entirely closed source. I’ve heard snaps are also easier for developers to work with, but I haven’t experienced that side of them.

Snaps automatically update by default where flatpaks don’t.

Snaps also get treated as loopback devices when they’re installed, which bloats a lot of utilities. (And they keep a few old versions around which makes it even worse). For example, you could run lsblk and if you’re using snaps like 90% of it will be snaps you’ve installed instead of actual devices.

Flatpaks are also noticeably faster to start up, which for desktop apps matters, but wouldn’t really matter for a server that’s aiming for a lot of uptime.

The loopback device issue is the main reason I don’t use snaps. I also like flatpak being completely open, but realistically that doesn’t matter for much. There used to be an open snap store, but that shut down because nobody used it.

permalink
report
parent
reply

The easiest way to think of it is flatpaks are AppImages with a repository and snaps are flatpaks but bad.

That has benefits and detriments. Appimages contain everything they need to run, flatpak’s mostly do, but can also use runtimes that are shared between flatpaks.

All flatpaks are sandboxed, which tends to make them more secure. AppImages can be sandboxed, but many aren’t.

Flatpaks tend to integrate with the host system better, you can (kinda) theme them, their updates are handled via the flatpak repo, and they register apps with the system.

AppImages are infinitely more portable. Everything’s in one file, so you can pretty much just copy that to any system and you have the app.

permalink
report
parent
reply

Yeah, but people installing GrapheneOS probably aren’t in the vast majority of users

permalink
report
parent
reply