What SteamOS 3.0 won't do

[finest feck fips]

It made me smile to see Linus' excitement about the pending release of the next major version of SteamOS on a recent episode of The WAN Show. But it seems unlikely that the release of SteamOS 3.0 relates to the desktop Linux challenge Linus and Luke recently undertook in the way that the clip suggests.

(That said, I can't imagine Linus is that deluded about what SteamOS 3.0 is likely to achieve in terms of the non-Steam desktop experience. While he's a Linux newbie, Linus knows the gaming industry well, and understands Valve's goals and resources as they relate to SteamOS. He also just spent some time experimenting with the same desktop environment as SteamOS 3.0 will ship with, and after all, he's been following SteamOS for a very long time.)

Such expectations, more explicit in pieces like this, seem to misunderstand what kind of product Valve is aiming to create in the Steam Deck. The deck is almost out, and there's little evidence that Valve has invested anything in Linux desktop user interfaces.¹ None of Valve's interests with the Steam Deck really overlap with what were Linus' most substantive pain points during the Linux challenge as we've seen it so far, like poor-to-non-existent support from third-party vendors (namely NVIDIA and GoXLR).

What we actually know about SteamOS is that it's going to be based on Arch, which has fewer safeguards against self-destructive user activity than Debian-based distributions do, and that it will come with an immutable root filesystem, like Fedora Silverblue, openSUSE MicroOS, RHEL Atomic Host, and (recently) macOS. This means that without entering a special ‘developer mode’, users

• cannot install any new native packages,
• cannot update any installed native packages,
• cannot edit the configurations of any operating system components, and
• cannot install or update any drivers.

 

In other words, the new SteamOS will behave like a console firmware, not like a personal computing operating system. Worse, if the base image even includes pacman, once developer mode has been ‘unlocked’, users will be no more protected from themselves than on any other Linux desktop system, although some form of rollbacks may be available to them.

There are some interesting possibilities for homebrew software without unlocking developer mode on such a system, namely an old-fashioned ports system, with Linuxbrew as a likely ready-made candidate, and Flatpak as a more complex but increasingly popular option. But these are also available on other desktop Linux operating systems today, and any Unix-like system will be readily breakable by self-identified power users who are too new to Linux to even know whether they know what they are doing or what a Linux power user looks like.

In short: SteamOS isn't going to hold your hand through setting up a customizable desktop so much as present you with a system which is hard to break only because it is locked down by default (and maybe because it will come with some halfway decent soft reset mechanism). And there's naturally no reason to expect it to solve the problem of compatibility with hardware unrelated to the Steam Deck.

I expect that when SteamOS 3.0 is released, many users will be disappointed if they expect it to solve problems that it was not designed to solve. I expect that they will say either that (on the one hand) it is too difficult to customize or (on the other) that it is too easy to break once customization is unlocked, depending on the details of the immutable filesystem implementation.

—
¹: While Valve has contracted a developer to work on the KDE window manager at least once in the past few years, their concerns were clearly stability and performance rather than changes to the user interface

[gudvinr]

36 minutes ago, finest feck fips said:

• cannot install any new native packages,
• cannot update any installed native packages,
• cannot edit the configurations of any operating system components, and
• cannot install or update any drivers.

 

In other words, the new SteamOS will behave like a console firmware, not like a personal computing operating system.

That's not true. Immutable root doesn't restrict you from installing software so you aren't missing anything from PC experience.

User-local data is still available to modify as you with and you can install application through flatpak, appimage, etc. "Native package is a very questionable term". You could theoretically install APT on Arch. I'd argue that it makes APT packages native yet someone might disagree. Same with other ways of distributing software. Once you installed flatpak it isn't less native than application installed through whatever package manager you have. Only reason it isn't is weird religious belief.

 

Partial inability to move around files in /usr/ or touching configs in /etc doesn't make OS less customizable. You shouldn't touch anything outside of /home without really good reason in first place. At least if you want to have maintainable and reliable OS that would work for years without causing any major troubles.

[Bombastinator]

The word I home in on in that one is “native”.  Cannot install or update any packages would be bad. The phrase was “native packages” though. “Native” can be a fuzzy word.  What does it mean in this instance?  Could be very close to just packages.  Might not be though. 
 

Apparently the hardware thing to a degree has already happened though.  Stuff had to be written to make it go and that stuff got released elsewhere as well.  The steamdeck is starting to crinkle around the edges though with the delays.  The really lame update of the Nintendo switch looked like a mistake at first but the longer the steamdeck delays the more justified Nintendo appears to have been.  Why improve if no one can compete with you?

[finest feck fips]

5 hours ago, gudvinr said:

"Native package is a very questionable term"

By ‘native’ I mean: a first-class citizen in the same way as the libraries, kernel, utilities, and applications that come with the base system. In the case of SteamOS 3.0, this likely means packages in the format understood by pacman.
 

5 hours ago, gudvinr said:

You could theoretically install APT on Arch. I'd argue that it makes APT packages native yet someone might disagree.

APT is a high-level package management tool that has been used with multiple packaging formats (notably RPM, on PCLinuxOS, as well as of course DEB). It doesn't really make sense to talk about ‘APT packages’. Similarly, you can choose between multiple high-level package managers on some RPM-based distros, such as openSUSE, where one can replace the default zypper with dnf from Fedora. Doing so doesn't change which packages you're installing, so it can't make them any more or less ‘native’.

 

5 hours ago, gudvinr said:

Once you installed flatpak it isn't less native than application installed through whatever package manager you have.

Flatpak packages interact with your system differently from packages installed by the distro's package manager, in two key ways:

 

1. They don't have the same level of access to your filesystem or network, which is variously limited by their sandbox policies, and
2. the base system is mostly unaware of their presence and they can't be used to supply plugins, libraries, etc., to the base system.

 

(Because they also bundle their own libraries, they also may not properly inherit system themes or other properties that affect system integration.)

 

5 hours ago, gudvinr said:

You shouldn't touch anything outside of /home without really good reason in first place.

Every time you run pacman -Syu or apt upgrade or zypper update or dnf update, you're touching /usr. If you're doing anything related to drivers (i.e., not all of your hardware works out of the box), you're touching /etc at the very least.

You're right, of course, when it comes to manual changes by new users. But that didn't stop Linus from complaining about how Dolphin wouldn't help him (due to legitimately missing polkit integration, in defense of Linus' basic expectation) to drag and drop .so files around /usr/lib or /usr/share! It also did nothing to mitigate his indignity at the suggestion, when he tried to explain his use case to more knowledgeable members of the Linux community than himself, that what he was trying to do was a bad idea. So we've already seen that such limitations are disagreeable to the target audience (Windows gamers) to whatever extent Linus succeeds in representing them.

At any rate, an alternative package management system on top of the base system is a possibility I acknowledged here:

5 hours ago, finest feck fips said:

There are some interesting possibilities for homebrew software without unlocking developer mode on such a system, namely an old-fashioned ports system, with Linuxbrew as a likely ready-made candidate, and Flatpak as a more complex but increasingly popular option. But these are also available on other desktop Linux operating systems today...

and in fact if Linus had so limited himself to ‘not touching /usr’ in the same way as SteamOS might prevent him from doing, and installed Steam via Flatpak, it wouldn't have been possible for him to nuke his desktop environment.

But why should the Linuses of the world be satisfied to with an OS that tells them they must enable ‘developer mode’ in order to do the very same things that they now take offense at being advised against doing on existing Linux desktop OSes? And once they do enable ‘developer mode’, what is actually going to make them more cautious, more inclined to heed the system's warnings, more likely to doubt that they ‘know their way around’, or more likely to stop and read documentation? The mere fact that they enabled something called ‘developer mode’, which their experience on macOS, Android, and other platforms tells them is a trivial matter? Something fundamentally irrational but psychologically potent, like the fact that the Steam Deck is a ‘special’ device and looks like a game console? There's no compelling reason any of that should mean much to them if they're treating SteamOS as a typical desktop OS on their personal desktops.

If SteamOS is really going to protect them from themselves, it shouldn't even include pacman, so that there's no operation of the systemwide package manager even in developer mode. I can imagine what their complaints about a measure like that would sound like already. On the other hand, if it does anything less, it just leaves them one toggle away from running commands they don't understand in a potentially destructive way. Either way, it can't possibly be a silver bullet.

[gudvinr]

15 hours ago, finest feck fips said:

APT is a high-level package management tool that has been used with multiple packaging formats (notably RPM, on PCLinuxOS, as well as of course DEB).

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.

15 hours ago, finest feck fips said:

Flatpak packages interact with your system differently from packages installed by the distro's package manager, in two key ways:

 

1. They don't have the same level of access to your filesystem or network, which is variously limited by their sandbox policies, and
2. the base system is mostly unaware of their presence and they can't be used to supply plugins, libraries, etc., to the base system.

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?

15 hours ago, finest feck fips said:

Every time you run pacman -Syu or apt upgrade or zypper update or dnf update, you're touching /usr

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.

[finest feck fips]

1 hour ago, gudvinr said:

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.

If by ‘from user perspective’, you mean ‘from the perspective of someone who does things at least including what Linus has done in the LTT challenge videos’, this is untrue. Existing Linux systems with immutable rootfs images via OSTree require reboots for any updates at all to take effect, for example. 

Requiring users to unlock a ‘developer mode’ before they can run pacman or packages from pacman/ALPM repos via Pamac is not ‘exactly the same’ behavior as allowing them to do so without so unlocking a ‘developer mode’. Neither are system updates that automatically overwrite all user-made changes, which is what downloading new rootfs images will do.

If package management operations (and having to do things like unlock ‘developer mode’ before undertaking them) do not fall under behavior that is visible ‘from a user perspective’, that also explodes the idea that the LTT Linux challenge has been undertaken ‘from a user perspective’.

 

1 hour ago, gudvinr said:

If you could install second package manager that is different from whatever you already have, that wouldn't make second one non-native.

I have told you how I used the term ‘native’ in the OP. Now that I have, the fact that you would use the word differently can no longer confuse you about the substance of my post. I'm not interested in defending the choice of the term.

 

1 hour ago, gudvinr said:

These packaging formats use same kernel features as other sandboxing/isolation solutions like docker/lxc/systemd containers or even chroot.

Yes

 

1 hour ago, gudvinr said:

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't, from inside a chroot (or sandboxes of the other kinds so far mentioned), change the behavior of the kernel at boot time (e.g., with respect to loading drivers), which is very explicitly mentioned in the (very short) list of differences I mentioned. You also can't do things like supply the shared library for a Qt plugin to the host system from inside a chroot.

[finest feck fips]

Of course there are lots of ways to work around an immutable rootfs so that software can be installed without unlocking the root filesystem and writing to it (like a ports system with some ugly and brittle LD_LIBRARY_PATH hacking where you want to affect the underlying system) or that only require doing so in a very minimal way (like setting up an overlay filesystem). But on desktop Linux

• none of the desktop app containerization solutions are very mature or well-integrated yet,
• the boundary between the base system and ‘user software’ historically non-existent or ill-placed for desktop use cases,
• none of them are really ‘user-friendly’ to set up in the way Windows users seem to hope for SteamOS to be,
• and most of them are worse at core sofftware management functionality (like dependency resolution, repository management, or even basics like uninstallation) than the high-level package management tools used for the system on most Linux distributions,
• none of the ones that already exist and are usable are especially focused on or well-suited to gaming.

 

A determined community could develop some of them in a Linus-proof way, but pre-configuring them would mean setting up a downstream distribution from SteamOS. And since it's been confirmed that SteamOS will include pacman right there behind the ‘developer mode’ gate, it's more likely that guides of the same kind as Linus has complained about, which rely on tools which are not designed to babysit their users, will crop up and form the center of gravity for customizing SteamOS.

So Linus-proofing will likely extend only to

1. a single settings change (enabling developer mode), and
2. a shiny reset button, which is a comforting idea but whose behavior in practice will likely amount to little more than reinstalling a typical desktop Linux distribution,

which doesn't really add that much to prevent a user from shooting themselves in the foot.

SteamOS will probably be fine. I just doubt that, as a desktop OS, it'll meet the expectations of Windows users even if it's good.

[Bombastinator]

I suspect the truth of this one is somewhere in the middle.  SUSE is a much less popular distro than it once was, but calling it effectively the same as a console seems extreme to me.  Likewise that there would have next to no practical limitation is also a bit unlikely.  Does valve want the users of these things to only use steam to buy games?  Of course they do, but they would have the vast majority of users anyway even if there were no limitations at all, so their motivation wouldn’t be all that strong.  We will probably have to wait for a release for a more fine grained determination to be made.  Until things are released they are vaporware from a consumer perspective. That it is possible to lock down a Linux system to the point it is effectively a console is known.  There are lots of ways to do it though. We will have to see what occurs. I think ordering one of these things under the assumption that one can do anything at all with it including such things as turning a bunch of them into a wolfram cluster as was done with one console strikes me as premature. That it will be a lot more open than previous consoles is a near certainty.  How much is another question though.

[finest feck fips]

41 minutes ago, Bombastinator said:

SUSE is a much less popular distro than it once was, but calling it effectively the same as a console seems extreme to me.

Regular old openSUSE doesn't have an immutable root filesystem. It uses a copy-on-write filesystem (BTRFS) which supports snapshots, but the root filesystem is mounted read-write. Only openSUSE's ‘MicroOS’ and openSUSE Kubic, which are container platforms based on openSUSE, have immutable root filesystems.

 

46 minutes ago, Bombastinator said:

I think ordering one of these things under the assumption that one can do anything at all with it including such things as turning a bunch of them into a wolfram cluster as was done with one console strikes me as premature.

You can replace the whole OS if you want to, so the only things to stand in your way for doing whatever you want with it are drivers, maybe firmware blobs, and the hardware limitations.

The Steam Deck seems like it'll be great at what it aims to be. But the OS it runs isn't gonna bring us the Year of the Linux Desktop™ when people start installing it on their PCs

[Bombastinator]

2 hours ago, finest feck fips said:

Regular old openSUSE doesn't have an immutable root filesystem. It uses a copy-on-write filesystem (BTRFS) which supports snapshots, but the root filesystem is mounted read-write. Only openSUSE's ‘MicroOS’ and openSUSE Kubic, which are container platforms based on openSUSE, have immutable root filesystems.

 

You can replace the whole OS if you want to, so the only things to stand in your way for doing whatever you want with it are drivers, maybe firmware blobs, and the hardware limitations.

The Steam Deck seems like it'll be great at what it aims to be. But the OS it runs isn't gonna bring us the Year of the Linux Desktop™ when people start installing it on their PCs

So your statement seems to me to be that steamOS3 is built for steamdecks not general use systems, and that trying to run it on a desktop as your only OS may result in unexpected limitations and will not be as useful a general use OS as some people apparently (haven’t seen such myself) are claiming it will.  Still a “maybe” from me.  People are filled with ingenuity.  This is actually starting to sound like something I might want to load on my current machine. I’d likely want to dual boot it with something else, just in case there is something I need to do on the machine that I can’t with steamOS, but it would likely run 90+% of the time even if all it was capable of was running steam stuff. I could see it as being an argument for not selling steamdecks as a loss leader on a long term basis, but that’s about it.  There most likely won’t be more than a few percent of people who do even that much. For 90+% of users it will be 100% of the time, and the fact that they “can” even if they don’t want to or ever even do it is a marketing advantage rather than disadvantage.

Edited December 2, 2021 by Bombastinator

[gudvinr]

4 hours ago, finest feck fips said:

If package management operations (and having to do things like unlock ‘developer mode’ before undertaking them) do not fall under behavior that is visible ‘from a user perspective’, that also explodes the idea that the LTT Linux challenge has been undertaken ‘from a user perspective’.

You still can install packages without interfering with system immutability, Just not pacman packages. That's it.

 

If we are talking about users that consider themselves windows powerusers then yes, inevitably they'll break something. But it'll definitely prevent not-so-tech-savvy users from breaking system and there's a chance that former ones will break something later than sooner because of this.

Basically, every issue in L&LLC were because they followed some shitty guide. If you can't follow shitty advice because your system is read only it's a good thing.

Of course, there should be a choice and not like "use flatpak or give up" but for many users it'll be enough. And everyone else could go developer mode rabbit hole.

Nothing is perfect and there's room for improvements but it is not a worst way of doing things.

[gudvinr]

4 hours ago, finest feck fips said:

You can't, from inside a chroot (or sandboxes of the other kinds so far mentioned), change the behavior of the kernel at boot time (e.g., with respect to loading drivers)

You can't do that from host system either because you know, it's already booted at that point. Only place that is able to do so is boot loader.

Basically every Linux installation nowadays is chrooted from initrd on its own. But nobody in their sanity would say that after initrd switched to new root that this root doesn't have native package management solution. Kernel remains the same it's just base image that was changed. So why another level of chroot makes it any less native?

[finest feck fips]

1 hour ago, gudvinr said:

You can't do that from host system either because you know, it's already booted at that point. Only place that is able to do so is boot loader.

To change things like what drivers get loaded automatically (including but not necessarily in your initial ramdisk), you may need to write to (on a typical distro):

• /boot
• /boot/efi
• /etc/default
• /lib/modules

if any of those are mounted read-only, you can't do that without breaking out of the default configuration (remounting read-write, entering ‘developer mode’, etc.).

 

1 hour ago, gudvinr said:

So why another level of chroot makes it any less native?

5 hours ago, finest feck fips said:

I have told you how I used the term ‘native’ in the OP. Now that I have, the fact that you would use the word differently can no longer confuse you about the substance of my post. I'm not interested in defending the choice of the term.

You basically seem to get it here:

1 hour ago, gudvinr said:

You still can install packages without interfering with system immutability, Just not pacman packages.

Right. The only reason I used more vague and general language in the OP rather than simply saying something like ‘pacman packages’ was because at the time I wrote it, it wasn't yet clear to me that SteamOS 3.0 would actually ship with pacman on it.

Have you ever used Homebrew on macOS, or pkgsrc anywhere but on NetBSD, or Gentoo Prefix?
 

 

1 hour ago, Bombastinator said:

So your statement seems to me to be that steamOS3 is built for steamdecks not general use systems, and that trying to run it on a desktop as your only OS may result in unexpected limitations and will not be as useful a general use OS

Kinda. It'll have a basic desktop environment and a web browser, and probably a few basic apps, and they'll all be real desktop software. Using it won't be like trying to browse the web on an unmodded Wii back in the day, or something like that. But unless you enable developer mode

• there'll be a little more separation between the ‘base system’ and stuff you might add yourself;
• upgrades of the preinstalled software will be largely limited to whatever Valve chooses to give you;
• package management tools available will probably be (some combination of) more brittle, more limited in selection, or more complex than a typical Linux distro's system package manager, including pacman;

and most guides (way too many, at any rate) are going just ask you to enable developer mode and unlock the root filesystem.

 

2 hours ago, Bombastinator said:

This is actually starting to sound like something I might want to load on my current machine.

This is very similar to how contemporary macOS works, and in spirit it's also so similar to typical desktop BSD usage, where the base system comes as a single unit with its own, separate upgrade mechanisms and end-user applications don't really touch the base system and just try to get by on top of it. (The main difference between these two cases, other than that macOS actually enforces this separation with an immutable root filesystem, is that on BSD, the entire GUI is considered a user application. That's less Linus-proof than the macOS way. ☺)

 

That kind of arrangement works well for many people, and if a bunch of SteamOS addon/mod projects developed around the Steam Deck to make it easier to install software with few or no modifications to the base system (so very selectively turning on developer mode, or not turning it on at all), that would actually be really cool. But it's not gonna be there on launch day, except maybe having a Flatpak store enabled.
 

2 hours ago, gudvinr said:

If we are talking about users that consider themselves windows powerusers then yes, inevitably they'll break something.

Agreed!

 

2 hours ago, gudvinr said:

But it'll definitely prevent not-so-tech-savvy users from breaking system and there's a chance that former ones will break something later than sooner because of this.

Basically, every issue in L&LLC were because they followed some shitty guide. If you can't follow shitty advice because your system is read only it's a good thing.

Maybe I'm underestimating the value of this kind of barrier as opposed to others we've watched Linus hastily cross in L&LLC. Maybe I'm underestimating the value of having a kind of soft reset option, because it'll feel safer than reinstalling even though what it does will be functionally the same. But yeah, I think I'm just more pessimistic about how much this will protect users from themselves.

I agree about the shitty guides, but what I anticipate is that we'll just have a lot of shitty guides that start with ‘first, enable developer mode’. I'd much prefer if the most popular guides were based around Flatpaks, AppImages, and ports install to /opt or whatever. That would be kickass.

 

I agree that an immutable filesystem is good for users coming from Windows, especially those who consider themselves power users, but it may not be what they want. And I think it would be hypocritical and/or confused for Linus to bitch and moan when a human tells him ‘don't modify /usr by hand, ya ding-dong’ but to then see a piece of software that essentially does the same thing as a praiseworthy and novel solution a few months later.