`RuntimeInformation.OSDescription` is really `KernelDescription`

[richlander]

I have frequently used RuntimeInformation. It is a great type and I'm glad we have it. At some point, I stopped using RuntimeInformation.OSDescription on Linux since it returns values that are not very useful.

That's for two reasons:

• It reports kernel information.
• For containers, the kernel is the host kernel.

Let's run this program

using System.Runtime.InteropServices;

Console.WriteLine(RuntimeInformation.OSDescription);

Bare metal (Raspberry Pi OS):

$ dotnet run
Linux 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

WSL + Containers (Debian):

$ dotnet run
Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

Cloud (Azure + Ubuntu):

$ dotnet run
Linux 5.15.0-1034-azure #41-Ubuntu SMP Fri Feb 10 19:59:55 UTC 2023
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Ubuntu 22.04.2 LTS"

You can see which uname variant we use:

$ uname -srv
Linux 5.15.0-1034-azure #41-Ubuntu SMP Fri Feb 10 19:59:55 UTC 2023

Windows:

>dotnet run
Microsoft Windows 10.0.22621

macOS:

% dotnet run
Darwin 22.4.0 Darwin Kernel Version 22.4.0: Wed Feb 22 22:16:19 PST 2023; root:xnu-8796.100.763.505.1~1/RELEASE_ARM64_T8103

I'd argue that the Linux kernel information serves no general purpose since the kernel is not the most important data for programs to know. For example, if containers are logging information, the kernel version is likely not the most important datapoint. Userland is likely much more important.

I propose two changes:

• Change OSDescription to report information about the userland OS, which would mean rely on /etc/os-release on Linux (if present).
• Consider adding a KernelDescription property to report the currently provided kernel information.

The RuntimeInformation.OSDescription docs state the following:

Gets a string that describes the operating system on which the app is running.

I'd suggest that this is inaccurate. For containers, for example, Debian, Ubuntu, Alpine, and others all return the same value.

I made these changes quite some time ago, but they are telling:

https://github.com/dotnet/dotnet-docker/blob/9db972bdead45dd4b4b5ed108e030bea98abcdf9/samples/dotnetapp/Program.cs#L25-L44

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I have frequently used RuntimeInformation. It is a great type and I'm glad we have it. At some point, I stopped using RuntimeInformation.OSDescription on Linux since it returns values that are not very useful.

That's for two reasons:

• It reports kernel information.
• For containers, the kernel is the host kernel.

Let's run this program

using System.Runtime.InteropServices;

Console.WriteLine(RuntimeInformation.OSDescription);

Bare metal (Raspberry Pi OS):

$ dotnet run
Linux 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

WSL + Containers (Debian):

$ dotnet run
Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"

Cloud (Azure + Ubuntu):

$ dotnet run
Linux 5.15.0-1034-azure #41-Ubuntu SMP Fri Feb 10 19:59:55 UTC 2023
$ cat /etc/os-release | head -n 1
PRETTY_NAME="Ubuntu 22.04.2 LTS"

You can see which uname variant we use:

$ uname -srv
Linux 5.15.0-1034-azure #41-Ubuntu SMP Fri Feb 10 19:59:55 UTC 2023

Windows:

>dotnet run
Microsoft Windows 10.0.22621

macOS:

% dotnet run
Darwin 22.4.0 Darwin Kernel Version 22.4.0: Wed Feb 22 22:16:19 PST 2023; root:xnu-8796.100.763.505.1~1/RELEASE_ARM64_T8103

I'd argue that the Linux kernel information serves no general purpose since the kernel is not the most important data for programs to know. For example, if containers are logging information, the kernel version is likely not the most important datapoint. Userland is likely much more important.

I propose two changes:

• Change OSDescription to report information about the userland OS, which would mean rely on /etc/os-release on Linux (if present).
• Consider adding a KernelDescription property to report the currently provided kernel information.

The RuntimeInformation.OSDescription docs state the following:

Gets a string that describes the operating system on which the app is running.

I'd suggest that this is inaccurate. For containers, for example, Debian, Ubuntu, Alpine, and others all return the same value.

I made these changes quite some time ago, but they are telling:

https://github.com/dotnet/dotnet-docker/blob/9db972bdead45dd4b4b5ed108e030bea98abcdf9/samples/dotnetapp/Program.cs#L25-L44

Author:	richlander
Assignees:	-
Labels:	area-System.Runtime, untriaged
Milestone:	-

[jkotas]

Related / duplicate: #37923

[richlander]

It's not too late @am11! I'll still be your PM!

[richlander]

Upon a little more thought, it seems like there are two choices here:

• Update documentation to make it more accurate.
• Update API to return userland information.

[am11]

There is no standard way of describing an operating system and depending on the audience / use-case, any description will fall short.

Linux Standard Base (LSB) distros provide /etc/lsb-release ASCII file and a related utility that can be called as:
lsb_release --all
However, not all distros use LSB.

systemd introduced /etc/os-release ASCII file. Since not all distros embrace systemd, they may not provide this file. Those which do, values (of even the known keys) are unreliable across wider range of distros.

Here is a scary (and definitely incomplete) heuristic to identify a unix-y userland: https://github.com/offscale/osbuild/blob/4f8c3b02766cc3c163cd6b157a938931b89a24d1/src/distribution.c#L31-L116.

#37923 was proposing to include this name (renamed from PAL_UNIX_NAME):

runtime/src/libraries/System.Private.CoreLib/src/System/OperatingSystem.cs

Lines 12 to 42 in 8599161

	private const string OSPlatformName =
	#if TARGET_BROWSER
	"BROWSER"
	#elif TARGET_WASI
	"WASI"
	#elif TARGET_WINDOWS
	"WINDOWS"
	#elif TARGET_OSX
	"OSX"
	#elif TARGET_MACCATALYST
	"MACCATALYST"
	#elif TARGET_IOS
	"IOS"
	#elif TARGET_TVOS
	"TVOS"
	#elif TARGET_ANDROID
	"ANDROID"
	#elif TARGET_LINUX
	"LINUX"
	#elif TARGET_FREEBSD
	"FREEBSD"
	#elif TARGET_NETBSD
	"NETBSD"
	#elif TARGET_ILLUMOS
	"ILLUMOS"
	#elif TARGET_SOLARIS
	"SOLARIS"
	#else
	#error Unknown OS, add a corresponding TARGET_* constant to System.Private.CoreLib.Shared.projitems
	#endif
	;

in OSDescription in some manner (preferably structured string appended to OS description; PlatformName: {OSPlatformName}), since that's how .NET Runtime libraries identify the current platform.

[richlander]

One option is to prefer /etc/os-release and then fallback to uname. That's probably a bad idea, since it would be hard to know which one you got.

In retrospect, it isn't obvious to me that this API is all that useful, for the reasons that you describe. I almost wonder if we should deprecate this API. It isn't that the data isn't useful, but that it is misleading. For containers and VMs, it is a lie. It seems like the higher-level functionality (if people want it) should be moved to a NuGet package.

[danmoseley]

@tmds do you have thoughts here?

[tmds]

I think the intended use-case for this API is to provide a descriptive string for the OS.

On Linux, returning something like /etc/os-release PRETTY_NAME (with fallbacks) would be the most descriptive.

Changing the description may break someone who is trying to extract information from it.

The preferred API to find if the OS is Linux is OperatingSystem.IsLinux() (or RuntimeInformation.IsOSPlatform).
The preferred API to find the Linux kernel version is Environment.OSVersion.Version.

[MichalPetryka]

Maybe an api that is something like bool TryGetOsPrettyName(out string) should be exposed here? On linux it'd check the 2 files in etc and on Windows it could map the versions to names (ie 6.1 to 7 etc).

[tmds]

I prefer to change what the property returns, instead of adding something new.

[tmds]

I assume we're fine changing the description that is returned now?

Maybe we should make clear in the docs, this is a description and not meant for parsing.

In an earlier comment, I've mentioned the APIs to check for Linux and the Linux kernel version.

If you want to know the distro, RuntimeInformation.RuntimeIdentifier is what you can use.

[stephentoub]

I assume we're fine changing the description that is returned now?

Yes. Our delegation to another system to produce this means we're already subject to whatever changes the underlying system provides, as well.

we should make clear in the docs

Yes, that'd be good clarification to add. That's always been the case, but we should be explicit about it.