SteamOS 3.0 lacks certain features and functionalities compared to previous versions.
SteamOS 3.0 lacks certain features and functionalities compared to previous versions.
The focus is on the term “native” which seems ambiguous here. It might simply refer to standard packages rather than specialized ones. The hardware adaptation appears to be nearly complete, with some components already released elsewhere. Delays are affecting the Steam Deck’s performance, and the Nintendo Switch update initially seemed flawed but later appeared more reasonable given the extended wait times. The overall tone suggests frustration over competition and perceived shortcomings.
By ‘native’ we refer to being part of the same system as the core components—libraries, kernel, utilities, and applications that come bundled with the base OS. For SteamOS 3.0 this usually means using packages compatible with pacman. APT serves as a top-level package manager that supports various formats such as RPM, PCLinuxOS, and DEB. It’s not meaningful to discuss ‘APT packages’ in this context. Likewise, you can switch between several advanced package managers on RPM-based systems like openSUSE, where zypper can be replaced by dnf from Fedora. Changing the manager doesn’t alter which packages are installed, so it doesn’t truly affect their ‘native’ status. Flatpak behaves differently: it doesn’t grant the same system access as traditional package managers, either through filesystem or network permissions. Its sandbox rules limit its ability to provide plugins or libraries, and it often fails to recognize system themes or other essential properties. Every time you run pacman -Syu or update via zypper, dnf, or another manager, you’re interacting with /usr. If you work with drivers—especially those not included by default—you also touch /etc, which is a significant point. While manual tweaks are important for new users, Linus’s frustration shows how even basic needs can be ignored. He complained about Dolphin’s inability to handle .so files properly, despite trying to explain his situation to more experienced users. This highlights a broader issue: such restrictions can be frustrating for the intended audience, like Windows gamers. Even if Linus had limited changes to /usr, it wouldn’t have stopped him from trying to install Steam via Flatpak and disrupting his desktop. The real problem is whether an alternative package manager could exist that respects user boundaries, preventing destructive actions without forcing users into uncomfortable compromises. The fact that developers enable ‘developer mode’—a feature they already understand from other platforms—suggests it’s not a fundamental flaw, but rather a design choice that may undermine trust. If the OS requires enabling developer mode to perform certain tasks, it raises concerns about user caution and reliance on system warnings. The mere existence of such a setting feels trivial compared to the broader implications for user autonomy and system safety.
Replace that with dpkg or whatever. That's not the point at all. If you could install second package manager that is different from whatever you already have, that wouldn't make second one non-native. You could completely remove first package manager and suddenly you have another one first class package manager. You could completely remove package manager or don't use packages at all. Slackware has very loose concept of management in "package management". Plain old .tar.gz that contains just binary files can be native package in some ways. These packaging formats use same kernel features as other sandboxing/isolation solutions like docker/lxc/systemd containers or even chroot. You can make chroot from same base image which will use same packaging format as parent OS. It's not impossible to modify content of host os from chroot and you have same level of access. That should meet your criteria. You can create container that will have all the privileges and then disable them one by one. Where is this point when app inside this container become packaged non-natively? You aren't. Package manager does. If you never change files outside of /home manually, OS that implements atomic updates of root image will look and behave exactly the same from user perspective.
There are various methods to bypass an unchangeable root filesystem, allowing software installation without exposing the core system or making modifications (such as using a ports setup with limited LD_LIBRARY_PATH adjustments). On desktop Linux, containerization options for apps are still developing and not fully refined. The separation between the base OS and user applications has traditionally been unclear, making setup less intuitive compared to Windows experiences. Most available solutions lack strong support for gaming needs and often fall short in core software management features like dependency handling, repo control, or uninstallation. Existing tools are generally better suited for Linux distributions rather than desktop environments. While a dedicated community might create more robust options, pre-built versions would likely require starting from SteamOS itself. Given that SteamOS plans to integrate pacman under developer mode, it’s probable that similar limitations will emerge, centering around basic configuration changes like enabling developer mode and offering a reset option. This approach may ultimately result in a standard Linux reinstall, offering little real advantage beyond what users already expect. SteamOS may function adequately, but it’s unlikely to satisfy Windows users’ expectations as a desktop OS.
I believe the reality lies somewhere in between. SUSE is far less popular than it used to be, yet calling it the same as a console feels unrealistic. The idea that there would be almost no real restrictions seems unlikely too. Is Valve encouraging users to buy games only through Steam? Of course they do, but even without restrictions, most users would still be there, making their goal less compelling. We should wait for a release to get a clearer picture. Until then, it feels more like vaporware from a consumer standpoint. It’s clear that locking down a Linux system to act like a console is possible, though there are many methods. We’ll need to observe what happens next. Ordering one under the belief it can be used freely—even for things like building a Wolfram cluster—is probably too early. It’s safe to say it will remain more open than past consoles. How much detail do we need to know?
Standard openSUSE doesn't feature an immutable root filesystem. It relies on a copy-on-write filesystem like BTRFS, which allows snapshots, but the root is mounted for writing. Only openSUSE's 'MicroOS' and Kubic, which are container solutions built on openSUSE, offer immutable root filesystems. You can swap the entire operating system if needed, with the main obstacles being drivers, firmware issues, and hardware constraints. The Steam Deck appears promising in its intended role, but the actual OS won't deliver the anticipated Linux Desktop experience on personal computers.
Your comment suggests steamOS3 is tailored for Steam decks rather than everyday computing, and that using it solely on a desktop might lead to unforeseen restrictions. It implies the OS isn’t as versatile for general tasks as some believe. I still think it’s uncertain, but it seems like a possibility worth considering for my setup. People often find creative ways, which makes this more appealing than it appears. I’d probably pair it with another OS just in case certain functions aren’t supported, but it would likely work well over 90% of the time. For most users, it would be fully reliable, turning any perceived drawbacks into a selling point.
You can still add packages without affecting system stability, except for Pacman-based ones. That's the rule. For users who treat themselves as Windows power users, it might cause issues, but it will stop less experienced people from damaging the system. Over time, some problems stem from following poor advice. If your system is read-only, it's a positive sign. There should be alternatives instead of forcing a choice between options like flatpak or giving up. Everyone else might dive into developer mode, and while nothing is perfect, this approach isn't the worst.
You can't perform that action from the host system since it's already running. The only way to do this is through a boot loader. Most modern Linux setups are chrooted from initrd independently. It's hard to believe that once initrd switches to a new root, the root still lacks native package management. The kernel stays unchanged—it's just the base image that's altered. Why does an additional chroot layer make it even less native?