Fedora 41 will unify bin and sbin(fedoraproject.org)
fedoraproject.org
Fedora 41 will unify bin and sbin
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
73 comments
your embedded system doesn't have to follow fedora, or any other major desktop distro.
Correct, but will Linux? Pottering?
Linux doesn't care; it covers Fedora and Gobo and Android and NixOS alike.
Pottering might do it, but... I dunno, does that affect embedded?
Pottering might do it, but... I dunno, does that affect embedded?
It only does if the embedded developer wants it to. You can include systemd tools in your embedded release, but you don't have to. Just like you don't have to include GNU tools in your embedded Linux release.
That's why I use Gentoo/Linux and portage.
Yocto or Buildroot are rather common for embedded Linux. They tend to be a bit easier for the mostly static embedded systems, where everything gets cross-compiled and distributed together. They also make it pretty simple to generate a manifest with all the licenses and attributions and source files needed for every package included in the build that's under an OSS license.
Linux will fade away, split into dozen forks, when all its founders are long gone, and the replacements aren't bound by the same ideals.
And a new generation of OSes that show some traces of UNIX influences will carry on.
Just like Windows still carries CP/M and MS-DOS traces on it.
And a new generation of OSes that show some traces of UNIX influences will carry on.
Just like Windows still carries CP/M and MS-DOS traces on it.
What world is that? The distinction has lacked meaning on linux for far longer than it has existed, as the subset in /bin /sbin and the /usr versions thereof don't form any useful subset of functionality.
In embedded, most of the time everything in a base image (/bin and /usr/bin stuff, not to mention /sbin) will be flashed to a single partition.
Secondly, Linux has something called overlayfs which you can use to build a sandwich any way you want. That is to say, the contents of your /usr/bin directory (and others) can simultaneously come from multiple partitions, some of which are writable, without the use of any symlinks. Overlayfs will merge things.
With overlayfs, you can create an image that appears mutable, but is assembled out of read-only partitions.
Secondly, Linux has something called overlayfs which you can use to build a sandwich any way you want. That is to say, the contents of your /usr/bin directory (and others) can simultaneously come from multiple partitions, some of which are writable, without the use of any symlinks. Overlayfs will merge things.
With overlayfs, you can create an image that appears mutable, but is assembled out of read-only partitions.
The first time I was able to rescue a Solaris system due to the immutable statically linked /bin was a life saver. Now I fear for our futures!
Absolute FUD nonsense. Actual greybeards know that the Linux kernel doesn't care if your binary is in /bin or /sbin, as long as you set up PATH accordingly. It's literally all you need to do.
I do not see what you are complaining about where no one is stopping you from installing binaries anywhere and on any mount you want.
When did greybeards expect to run user-friendly desktop distros on embedded devices, afraid of touching PATH? You are free to use anything else, or go LFS for ultimate customization, which is actually what I expect serious embedded devs to do.
I do not see what you are complaining about where no one is stopping you from installing binaries anywhere and on any mount you want.
When did greybeards expect to run user-friendly desktop distros on embedded devices, afraid of touching PATH? You are free to use anything else, or go LFS for ultimate customization, which is actually what I expect serious embedded devs to do.
A welcome change. The Linux directory hierarchy is in desperate need of a cleanup of old use-cases.
I thought all the distros already did this with the /bin and /usr/bin merge; it's like that on at least Void and Arch Linux anyway.
The whole reinterpreting of "static bin" to "system bin" never made sense to me.
The whole reinterpreting of "static bin" to "system bin" never made sense to me.
What about the reinterpreting of "usr" from "user" to "unix system resources" after Unix overflowed the original 1.5 MB OS drive on Thompson and Richie's PDP-7?
> "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented"
- http://lists.busybox.net/pipermail/busybox/2010-December/074...
> "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented"
- http://lists.busybox.net/pipermail/busybox/2010-December/074...
In the state of immutable distros that use a modern image format (so not Android), /usr is read only and managed by the system only anyway.
imho we should go the entire way and move /home to /var/home, so anything other than /etc and /var can be read-only, I already place /var on a separate partition with /var/home on RHEL installs.
imho we should go the entire way and move /home to /var/home, so anything other than /etc and /var can be read-only, I already place /var on a separate partition with /var/home on RHEL installs.
fun fact: you can already have almost everything except /var/ and /home/ read-only (there are still some legacy problems in /etc/, namely passwd, shadow, group... that I think userdbd can handle, but are there because of backwards compat). You can add to /etc/ by using systemd-confexts and overlaying files onto there (and systemd-sysext for /usr/). ~~Tho you have to choose the software you run somewhat carefully~~ Lets rather say, the infrastructure is already mostly there for this to be possible.
I'd love to have a way to have root really only be a read-only tmpfs that is only used for mount points (specifically /usr/, /var/ and /home/) and symlinks (for example /var/home/ to /home/ if no separate partition is wanted).
I'd love to have a way to have root really only be a read-only tmpfs that is only used for mount points (specifically /usr/, /var/ and /home/) and symlinks (for example /var/home/ to /home/ if no separate partition is wanted).
Impermanence is an interesting take on this using NixOS https://github.com/nix-community/impermanence
The term "UNIX System Resources" for /usr is documented no earlier than 2003. This is about 30 years after the events you refer to.
Debian is merging /bin and /usr/bin as well. The "static bin" makes sense, if you follow it very strictly, in that case it ensures that regardless of how much you damage libraries, everything in /bin (and /sbin) will still work.
If you merge /bin and /usr/bin it becomes unclear which binaries you can rely on in an emergency. There's simply no easy way to tell at a glance.
Merging bin and sbin makes a little more sense to me. It avoids the very common scenarios where you type "sudo mount" or "sudo ip addr", something like that, and our shell just return "command not found", simply because it's not in the users $PATH. It's a minor convenience factor, but I can't see it making anything worse.
If you merge /bin and /usr/bin it becomes unclear which binaries you can rely on in an emergency. There's simply no easy way to tell at a glance.
Merging bin and sbin makes a little more sense to me. It avoids the very common scenarios where you type "sudo mount" or "sudo ip addr", something like that, and our shell just return "command not found", simply because it's not in the users $PATH. It's a minor convenience factor, but I can't see it making anything worse.
In the event of an emergency, you rely on initramfs.
Completely agree.
That feels entirely wrong to me.
sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper cleanup.
sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper cleanup.
There are really quite few programs that can’t be invoked by regular-ish users in the brave new world of user namespaces. It’s also entirely unclear to me why trying to sort programs into these particular buckets is useful.
At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.
At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.
We should learn from the xz incident. It's little things like these that make compromise harder. Not saying the fact that sbin exists did anything, but that more layers of armor is always better.
We should learn from the xz incident by adding real security. For example, the ways programs use libraries could be restructured to prevent libraries, and especially libraries whose functions are not called, from having side effects.
Or packaging tools could learn to verify that a release is exactly a git commit and not some tarball that may or may not have any particular relationship to a commit.
Or we could make sure sshd is in /usr/sbin? I don’t get it. What does that accomplish? It’s not as if the stuff in a directory called “sbin” is inherently more “secure”.
Or packaging tools could learn to verify that a release is exactly a git commit and not some tarball that may or may not have any particular relationship to a commit.
Or we could make sure sshd is in /usr/sbin? I don’t get it. What does that accomplish? It’s not as if the stuff in a directory called “sbin” is inherently more “secure”.
If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries).
Look, I don't say this as the end all, be all. Just another piece of the puzzle.
Think of how chaotic Linux land is. It's true it can be thought as a liability, but distros' heterogeneous nature could also be a defense, and sbin itself can be thought as another defense. For example, in openSUSE Leap 15.6 at least, a lot of critical binaries are located in sbin. They are placed there not only as a static fallback for maintenance, but also as a means to minimize the attack surface of the OS. It is much more likely for your system to be compromised at a user level, and not at a superuser level.
I know the xz incident wasn't the best example, and of course there are better solutions than this.
Think of how chaotic Linux land is. It's true it can be thought as a liability, but distros' heterogeneous nature could also be a defense, and sbin itself can be thought as another defense. For example, in openSUSE Leap 15.6 at least, a lot of critical binaries are located in sbin. They are placed there not only as a static fallback for maintenance, but also as a means to minimize the attack surface of the OS. It is much more likely for your system to be compromised at a user level, and not at a superuser level.
I know the xz incident wasn't the best example, and of course there are better solutions than this.
> If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries).
I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have.
(Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)
I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have.
(Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)
sbin is not, and was never, a security barrier.
Aren't you advocating breaking scripts that reference executables in /sbin or /usr/sbin? sbins that could be invoked by users cannot just move to /bin, if scripts expect them to be in /sbin.
It looks like Fedora has decided that the sbin distinction is historic fluff. There is no need to put a program in a separate directory just because it makes system calls that require root and therefore fail for a regular user.
The article makes it clear that before this change, there is already no /bin directory, but rather /bin is a symlink to /usr/bin and /sbin is a symlink to /usr/sbin. I.e. they already decided that the the shortened /bin and /sbin paths are historic fluff; everything will be in /usr.
The symlinks are needed for compatibility. You know, like #!/bin/sh and whatnot.
Now they are getting rid of /usr/sbin. So that becomes a symlink to bin (I'm assuming relative, I.e. /usr/sbin -> bin).
Thus, all combinations of {/usr}?/{bin|sbin}/<program> become equivalent, and only /usr/bin is a real directory where all the system binaries live.
It looks like Fedora has decided that the sbin distinction is historic fluff. There is no need to put a program in a separate directory just because it makes system calls that require root and therefore fail for a regular user.
The article makes it clear that before this change, there is already no /bin directory, but rather /bin is a symlink to /usr/bin and /sbin is a symlink to /usr/sbin. I.e. they already decided that the the shortened /bin and /sbin paths are historic fluff; everything will be in /usr.
The symlinks are needed for compatibility. You know, like #!/bin/sh and whatnot.
Now they are getting rid of /usr/sbin. So that becomes a symlink to bin (I'm assuming relative, I.e. /usr/sbin -> bin).
Thus, all combinations of {/usr}?/{bin|sbin}/<program> become equivalent, and only /usr/bin is a real directory where all the system binaries live.
OpenSUSE did that; it was IMO marginally inconvenient because (IIRC) it broke tab completion of sbin binaries, even with sudo. Ex, "sudo pow<tab>" wouldn't give you poweroff.
Well, that would be trivial to fix by detecting the magic sudo, and add /usr/sbin to the completion searchpath
"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to usr/bin and usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH. The same change is also done to make /usr/local/sbin point to bin, effectively making /usr/local/bin/foo and /usr/local/sbin/foo point to the same place. The definition of %_sbindir will be changed to %_bindir, so packages will start using the new directory after a rebuild without any further action. Maintainers may stop using %_sbindir, but don't need to."
the summary is very unclear for new users, was it saying _everything_ is now symlinking to /usr/bin? and /usr/bin is the only real directory the rest is all symlinks? The way of saying "symlink to bin" is just plain wrong or at least ambiguous.
the summary is very unclear for new users, was it saying _everything_ is now symlinking to /usr/bin? and /usr/bin is the only real directory the rest is all symlinks? The way of saying "symlink to bin" is just plain wrong or at least ambiguous.
it's saying that anywhere that there was an sbin, it now is a symlink to it's sibling bin
it's also saying that because /bin and /sbin point to their /usr counterparts, /bin and /sbin will point to /usr/bin
So currently: /bin -> /usr/bin
which all makes sense, we'll have /usr/bin and /usr/local/bin, where the latter is for user-installed executables and the former for system installed executables.
it's also saying that because /bin and /sbin point to their /usr counterparts, /bin and /sbin will point to /usr/bin
So currently: /bin -> /usr/bin
/sbin -> /usr/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/sbin -> /usr/bin
/usr/bin
/usr/sbin -> /usr/bin
/usr/local/bin
/usr/local/sbin -> /usr/local/bin
which all makes sense, we'll have /usr/bin and /usr/local/bin, where the latter is for user-installed executables and the former for system installed executables.
Previously, these folders existed:
- /usr/bin, aka /bin
- /usr/sbin, aka /sbin
- /usr/local/bin
- /usr/local/sbin
Now, these folders exist:
- /usr/bin, aka /usr/sbin, aka /bin, aka /sbin
- /usr/local/bin, aka /usr/local/sbin
- /usr/bin, aka /bin
- /usr/sbin, aka /sbin
- /usr/local/bin
- /usr/local/sbin
Now, these folders exist:
- /usr/bin, aka /usr/sbin, aka /bin, aka /sbin
- /usr/local/bin, aka /usr/local/sbin
you are in a maze of twisty little passages, all alike.
I agree that “/usr/sbin directory becomes a symlink to bin” can be confusing for new users, but I don’t think it’s wrong: I interpret this statement as saying that /usr/sbin is going to be a relative symlink with target bin, which would indeed make it resolve to /usr/bin.
I read that as saying that /usr/local/sbin will point to /usr/local/bin which will still be separate from /usr/bin. But /bin, /sbin, and /usr/sbin would all point to /usr/bin.
Mini rant. I don’t know why people need to mess with stuff like this.
Like the change of ifcfg-files. [0]
Also, forcing nmcli to control network interfaces.
CentOS 7 is truly great. Sad day when it’s EOL.
Sometime it seems like stuff is changed for the hell of it rather than for good reasons.
[0] https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye...
Like the change of ifcfg-files. [0]
Also, forcing nmcli to control network interfaces.
CentOS 7 is truly great. Sad day when it’s EOL.
Sometime it seems like stuff is changed for the hell of it rather than for good reasons.
[0] https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye...
Finally, we only need /bin!
Except on Fedora where it’s /usr/bin.
That feels so wrong to me.
That feels so wrong to me.
The reason they are doing this is so that you can mount /usr as read-only or possibly on immutable storage.
I was curious why they are making the change now so I skipped right to the "benefit to fedora" section. They do not mention mounting /usr RO anywhere. Was this brought up in previous discussions? I do not understand why merging bin and sbin allows for mounting /usr RO.
The two issues seem totally unrelated to me. /usr/bin and /usr/sbin are directories under /usr. Why does making sbin a symlink allow for mounting /usr RO?
The two issues seem totally unrelated to me. /usr/bin and /usr/sbin are directories under /usr. Why does making sbin a symlink allow for mounting /usr RO?
I think GP was saying that it’s /usr/bin rather than /bin for mounting as readonly. Not that merging any particular sbin with bin serves the purpose of readonly mounting.
Disclaimer: I’m mostly just a Mac user/interested spectator. It’s possible I’m misunderstanding GP, and it’s not clear to me why the /usr distinction matters for readonly mounting either. But I couldn’t help jumping in to see if I could help clarify something, because there are just an astonishing number of ambiguities and confusions about those ambiguities throughout the comments on this post!
Disclaimer: I’m mostly just a Mac user/interested spectator. It’s possible I’m misunderstanding GP, and it’s not clear to me why the /usr distinction matters for readonly mounting either. But I couldn’t help jumping in to see if I could help clarify something, because there are just an astonishing number of ambiguities and confusions about those ambiguities throughout the comments on this post!
Because in this day and age on Fedora, there's practically zero difference between sbin and bin.
You could separate it I guess correctly between system-only bins again, but you'd break existing software that's hardcoded sbin and bin.
You could separate it I guess correctly between system-only bins again, but you'd break existing software that's hardcoded sbin and bin.
I think I am missing something obvious. I apologize for being dense.
What does the fact that "there's zero difference between sbin and bin" have to do with mounting /usr read only?
What does the fact that "there's zero difference between sbin and bin" have to do with mounting /usr read only?
This change has nothing to do with it. The entire thread here is more talking about the usr-merge specifically (I think).
Thank you. I think you are correct.
Why can't you do that with /bin?
Because /bin only contains binaries whereas /usr is self-contained. It will contain icons/libraries/shared resources/etc that the binaries actually need to function.
The idea is that /usr can be a snapshot of your whole system. (/etc violates this but there’s ongoing work on that side)
The idea is that /usr can be a snapshot of your whole system. (/etc violates this but there’s ongoing work on that side)
I don't see the benefit of shoving every directory in / under /usr. / can already be a "snapshot of your whole system". Just mount /home separately if you don't want it included in that.
Because it wouldn't contain the rest of the /usr
... and what's the problem with two RO mounts?
That its more that needs to be done for no benefit.
They aren't one.
That shouldn't be supported -- it should all be in one filesystem.
agree, so I think /usr/local should be kept
[deleted]
Who needs subdirectories? Everything in /.
Does this also come to the atomic versions, Kinoite and Silverblue?
[deleted]
Finally. The bin/sbin split was originally done as a hack for someone's weird setup, but it doesn't make sense for MOST Linux setups today (and if you respond with "I use this feature" then you're just falling for perception bias, for your elucidation).
Wasn't it a Solaris thing originally? That's where I first saw /usr/sbin.
Steam horrible bash (and not even sh) scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options).
The guys who wrote those are.. "geniuses"...
I moved my stuff to /bin a long time ago, but I had to cherry pick stuff in /sbin to please steam stuff.
Like you better have nothing in LD_LIBRARY_PATH and everything available via a stable output of /sbin/ldconfig (an abomination). All that to work around the abuse of gnu version names by the glibc devs (and gcc) via a super expensive user/mount namespace kernel mechanism.
All that is msft grade, namely mostly bad.
The guys who wrote those are.. "geniuses"...
I moved my stuff to /bin a long time ago, but I had to cherry pick stuff in /sbin to please steam stuff.
Like you better have nothing in LD_LIBRARY_PATH and everything available via a stable output of /sbin/ldconfig (an abomination). All that to work around the abuse of gnu version names by the glibc devs (and gcc) via a super expensive user/mount namespace kernel mechanism.
All that is msft grade, namely mostly bad.
Since they will keep a symlink, there is no reason to expect any breakage.
> Steam horrible bash scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options).
sbin is still there, just symlinked to bin.
(But, yes, hardcoded paths are deeply irritating. Also install scripts that pass a path variable unescaped to another command, meaning that you can't have spaces in your paths.)
sbin is still there, just symlinked to bin.
(But, yes, hardcoded paths are deeply irritating. Also install scripts that pass a path variable unescaped to another command, meaning that you can't have spaces in your paths.)
Two thoughts:
I agree most of the compatibility concerns mentioned are moot, but I guess it will cause small amounts of one minor ~forward-compatibility problem: people working on Fedora hardcode new paths that won't work on other distros unless/until they follow suit.
---
In late 2019 I started work on a tool for ~wrangling external shell script dependencies to help us package shell better in the nix ecosystem. (the tool itself is generic, but it's currently only packaged for nix.)
The main goal is to identify external dependencies in a ~source script, require them to be specified/present, and output a rewritten script with absolute paths.
It handles existing hardcoded paths by treating them as an error that the user has to address by either telling it to just resolve them as if they were bare, or to keep as-is.
I agree most of the compatibility concerns mentioned are moot, but I guess it will cause small amounts of one minor ~forward-compatibility problem: people working on Fedora hardcode new paths that won't work on other distros unless/until they follow suit.
---
In late 2019 I started work on a tool for ~wrangling external shell script dependencies to help us package shell better in the nix ecosystem. (the tool itself is generic, but it's currently only packaged for nix.)
The main goal is to identify external dependencies in a ~source script, require them to be specified/present, and output a rewritten script with absolute paths.
It handles existing hardcoded paths by treating them as an error that the user has to address by either telling it to just resolve them as if they were bare, or to keep as-is.
Well you definitely want to use hardcode paths in some scripts. For example those that call sudo.
> Well you definitely want to use hardcode paths in some scripts. For example those that call sudo.
I can agree that there are cases for hardcoded paths to executables, but I'd argue that (aside possibly from working around the bad behavior of other tools) there's almost never a need for hardcoded paths to install folders, and that there's absolutely never a reason to use un-escaped variables in a path name.
I can agree that there are cases for hardcoded paths to executables, but I'd argue that (aside possibly from working around the bad behavior of other tools) there's almost never a need for hardcoded paths to install folders, and that there's absolutely never a reason to use un-escaped variables in a path name.
It is even getting worse, valve, willingly on not, is using it's domination of this market to force into a specific configuration the elf/linux distros (you better have an "expected" output of the glibc /sbin/ldconfig, some libs and modules exactly at the right locations and with the right symlinks), and forces some significantly expensive technical components beyond video game core system interfaces (bash, user/mount linux kernel namespace, niche gnu-only options of commands,etc).
Yes, this is mostly bad (msft grade), they should fix all of this. The guys who did that clearly where not the right ones, evil or with an accute lack of perspective and/or experience. First they have to follow ELF specs and certainly not expected "only some ELF specs in some specific way". They should provide clean (10 years old version names, libdl-ing system interfaces, static libgcc, static libstdc++, leave as much as possible of ELF static TLS slots to the system) ELF binaries and depends only on video game core system interfaces: Expecting bash from the user system, certainly not, they could expect a simple SH interpreter and no more (debian dash, busybox ash, etc). They could distribute their statically linked bash interpreter, as they are already distribute a gigantic part of a full elf/linux distro now (their "runtimes"). And this legacy opengl 32bits code... come on, they removed it from macOS, why elf/linux user have to suffer from it (that's actually fishy).
Hope valve leaves msft grade mediocrity behind at some point, because for the moment it looks like 1 step forward and 10 steps backward.
Oh and video game core system interfaces are: - wayland (code is static in binaries), fallback to x11 (libdl-ing x11 xcb libs). - libxkbcommon-x11 if x11, libxkbcommon if wayland surfaces are using xkb. - vulkan (libdl-ed by design), fallback to opengl (libdl-ed) fallback to CPU rendering. - libasound (alsa-lib) for sound. - linux /dev/input/eventXX device nodes for joypad support.
More than that is too excessive and not reasonable.
Yes, this is mostly bad (msft grade), they should fix all of this. The guys who did that clearly where not the right ones, evil or with an accute lack of perspective and/or experience. First they have to follow ELF specs and certainly not expected "only some ELF specs in some specific way". They should provide clean (10 years old version names, libdl-ing system interfaces, static libgcc, static libstdc++, leave as much as possible of ELF static TLS slots to the system) ELF binaries and depends only on video game core system interfaces: Expecting bash from the user system, certainly not, they could expect a simple SH interpreter and no more (debian dash, busybox ash, etc). They could distribute their statically linked bash interpreter, as they are already distribute a gigantic part of a full elf/linux distro now (their "runtimes"). And this legacy opengl 32bits code... come on, they removed it from macOS, why elf/linux user have to suffer from it (that's actually fishy).
Hope valve leaves msft grade mediocrity behind at some point, because for the moment it looks like 1 step forward and 10 steps backward.
Oh and video game core system interfaces are: - wayland (code is static in binaries), fallback to x11 (libdl-ing x11 xcb libs). - libxkbcommon-x11 if x11, libxkbcommon if wayland surfaces are using xkb. - vulkan (libdl-ed by design), fallback to opengl (libdl-ed) fallback to CPU rendering. - libasound (alsa-lib) for sound. - linux /dev/input/eventXX device nodes for joypad support.
More than that is too excessive and not reasonable.
Why expect the worst? Everything should remain backwards-compatible.
Insulting the author of the change request, when it is you who failed to understand the request and how it maintains backwards compatibility is quite strange.
Too many developers wanting to mess with things is getting expoundingly worse; even worse, non-privileged developers still pushing to centralized things to a single point of failure.
We gray-beards lament the future and it is us.