ShiningWing

That’s not mentioned in this specific blog post, but that’s always been one of Vanilla OS’s defining features, it’s “apx” package manager to install those various types of packages

It’s even using Distrobox actually, but the point is to make it simpler to install packages for those contrainers, with the user not worrying as much about managing the individual containers, and not having to memorize the specific commands for each individual distro’s package manager

Basically, like the rest of Vanilla OS, the point isn’t that you can’t do this stuff elsewhere, it’s that it’s trying to make it easier to do it

I have a Steam Deck and I’m happy with it too, but my point is that the game compatibility would just get even worse if you add on having to emulate x86, because it’s not like x86 emulation would be perfect right away, and the amount of native ports will become even smaller than they already are

Even if the architecture is an improvement, in practice it wouldn’t make any sense right now, and I can’t see an ARM-based Steam Deck or whatever selling nearly as well as the existing x86 ones given the downsides it would present

1. Seems kinda hand-wavy to me, so I’ll boil this down to lower bloat (i.e. lower disk and mem usage by the OS)

They pretty clearly say what they mean by that though, unless you only read the headers and not the actual text

2. This is very much YMMV, and for Steam Deck specifically, it’s comparing a tuned the system to an OOTB experience; surely other handhelds tune their systems too

They absolutely don’t, is the thing, and the Windows ones largely can’t in the same way that the Deck can, because they can’t change how Windows works beyond the surface, meanwhile Valve is able to write software for Linux like Gamescope, an entire lightweight compositor that lets them have full control over how games are displayed and means they don’t need to have a full desktop environment running, and they directly contribute to and fund development for open source system components (like the KDE Plasma desktop environment that’s used in Desktop Mode) in a way that would be impossible for similar things on Windows

Valve even has their own custom patched version of the Linux kernel in SteamOS, you can’t do anything remotely like that on Windows

3. I’m pretty sure this is true for other handhelds, but I haven’t used them personally so I don’t know

You can’t avoid having using the desktop eventually on Windows on a handheld, and it’s always running the background, even if you boot into Big Picture

Even if you’re always running games from Big Picture or whatever, you still need to use the desktop for updates, as well as any settings and functionality that can’t be accessed from Big Picture on Windows (like dealing with Bluetooth devices), as opposed to SteamOS where all of it can be handled directly in gaming mode without a desktop even running

4. This seems very solvable, and not an inherent Windows issue; large enterprises manage drivers and whatnot centrally, surely a handheld can too

ASUS already has a solution, like the article mentions, but it can’t be nearly as seamless as SteamOS where they can just push a single system update image that includes everything, and it’s applied all in one go directly from gaming mode

There’s also additional benefits SteamOS can have with its update system that Windows can’t have, like how it has an A/B partition system similar to Android so that a broken update only breaks one partition and it can switch to the other one when that happens, which especially helps if something like a power interruption happens during an update and it doesn’t complete properly (meanwhile on Windows it can be pretty hard to recover from something like that)

5. Surely this is true for Windows devices, no? I’m guessing more people are comfortable customizing Windows handheld PCs vs the Steam Deck simply because more people are familiar with customizing Windows than Linux

You absolutely cannot modify Windows nearly as deeply as you can with Linux, and attempting to make any serious changes requires hacky solutions that Microsoft can just break in the next update anyway

Like, you can change almost every single component of a Linux distro, you can rewrite components directly since they’re open source, and there are usually multiple options to pick from for any given piece of system software, such as the entire desktop environment, or the audio system, or even the kernel itself

The idea would be that new games would be compiled natively.

They won’t even compile games for Linux as it is, and a lot of the ports we do get are awful ones that run significantly worse than the Windows versions do through Proton, so expecting publishers to start putting all their PC games on a different architecture entirely, just for the sake of handhelds like this, is completely unrealistic

Stuff like Proton (which isn’t emulation in the sense that this would be) has already struggled so much with compatibility over the years to get to where it is now, adding an entire x86 emulation layer on top of that would set things back so far and it would even more of an uphill battle to recover from

If the goal is to run enough current games well enough, then AMD chips are still doing fine at that, and upcoming generations will likely go a long way to improving that

None of those are official though, the Flatpak is the only officially supported Bottles version, and the sandboxing is one reason why they recommend using the Flatpak

The problem here is that for that purpose, Flatpak is better in nearly every way and is far more universal

I think Snap makes the most sense for something like Ubuntu Core, where it has the unique benefit of being able to provide lower level system components (as opposed to Flatpak which is more or less just for desktop GUI apps), but it doesn’t make sense for much else over other existing solutions

because the package build script isn’t available?

What are you talking about? Every Flatpak on Flathub has their build manifest available on GitHub, you can fork or download it for yourself and change it how you’d like, just like you can with an Arch PKGBUILD

And the problem still isn’t solved because now the people who can set bad defaults still exist, they’re just different people.

For one, unlike with distro packages, lots of Flatpaks are made by the developers of their apps, so bad defaults aren’t really going to be a thing for those since the developer would want to choose what’s best for their own app

And for packages maintained by a third party, bad defaults are less common because maintainers don’t need to account for each individual distro’s unique package situation or specific dependency versions, and only have to package it once for every distro