Support for Linux Distros Update

[richlander]

The .NET Team provides support for a broad set of Linux distros. That is not changing. We made some decisions that in the last year that deserve mention to ensure that everyone understands our approach. We expect that this posting won't matter for most users.

Key decisions:

• Ubuntu 24.04 container images will be the default for .NET 10
• Debian Trixie container images will not be provided
• .NET 11 will target 20.04 for the glibc build

The following sections go into more detail. The first two decisions collapse down to a single explanation.

Debian container support

Debian is an excellent Linux distribution and has been a great workhorse for .NET. It also remains supported and we encourage .NET developers to use it. The only change is that we will not produce Debian container images starting with Trixie.

We realized that Debian wasn't a good choice for our default container images because both it and .NET have a 3 year support schedule (for mainline support) and Debian ships first. For example, that means that Debian Bookworm will transition into its EOL phase before .NET 8 does. We have previously encouraged users to upgrade to the next Debian version in similar cases. We should have realized and resolved this problem a long time ago, in retrospect. Sorry about that.

Once we decided to make Ubuntu our default image style, we then concluded that there was not a pressing reason to produce Debian images, since Debian and Ubuntu are very similar. This thinking applied to all .NET versions. It is also the case that upgrading from Debian Bookworm to Trixie has about the same ccompatibilityconcern as upgrading to Ubuntu Noble. LTS -> LTS should not be considered a "safe in-place upgrade" for Linux distributions.

• Debian Trixie Release Notes
• Ubuntu Noble Release Notes

As in past releases, we will continue to publish .NET 8 on Debian Bookworm after Bookworm EOL. Doing anything different would be a massive breaking change. Users can move to our .NET 8 Ubuntu Noble images (which we've been publishing since 2024) or produce their own Debian Trixie images.

Over the past few years, we have worked closely with Canonical and have completed key projects with them (packages and chiseled images). This relationship and the long Ubuntu LTS duration were key factors in deciding to choose Ubuntu as our default image. An additional factor is supply chain security. Canonical delivers the base images we use directly to Azure, resulting in no break in custody between the two organizations. We think that is valuable.

See Platforms for .NET 10 container images for more information on .NET 10 plans.

glibc / Ubuntu targeting

We adopted a new Linux build methodology with .NET 8, where we build the native components of .NET using a modern distro, modern tools, and header files acquired from an old Ubuntu distro. Each release, we announce these combinations.

• .NET 8 build
• .NET 9 build
• .NET 10 build

Our plan is to bump the Ubuntu version we target to a newer Ubuntu LTS on average every two years. .NET 8 targets 16.04, .NET 9 targets 18.04, and .NET 10 targets 18.04. .NET 11 will target Ubuntu 20.04. .NET 12 will target 20.04 or 22.04.

This approach has a lot of benefits. Most of our build system is very modern, however, it enables users to run .NET apps on old deployments should they need to. Enablement is not the same as Support (capital "S" support). For example, .NET 10 is commercially supported on Ubuntu 22.04+, not on Ubuntu 18.04 or 20.04.

We recently had a conversation on whether we would drop OpenSSL 1.x support. OpenSSL 1.x to 3.x was an ecosystem-wide update and forms a sort of Linux compatibility epoch. We decided that we'd hold off until at least .NET 12 until making that change. Either way, we'll drop OpenSSL 1.x support (small "s" support) when we switch to targeting Ubuntu 22.04 in our build. We haven't decided that yet and won't entertain that discussion for another year.

[migig]

So every .NET container will now include extra cruft from Ubuntu.

Application containers are intentionally run on the minimally supported OS, possibly with extras baked in, before adding runtime tools (if necessary) and the application. Whenever possible, one wants to run scratch! Otherwise, Alpine. Otherwise, something heaver, etc., etc... In the extreme case, Debian.

Now by default every container will be Ubuntu. Unbelievable.

[richlander]

This is what I see in terms of uncompressed x64 image sizes:

rich@merritt:~$ docker images
REPOSITORY                              TAG                  IMAGE ID       CREATED        SIZE
alpine                                  latest               9234e8fb04c4   7 weeks ago    8.31MB
debian                                  latest               999ffdddc152   27 hours ago   120MB
ubuntu                                  latest               802541663949   2 weeks ago    78.1MB
mcr.microsoft.com/dotnet/runtime-deps   8.0-alpine           1eeb50cdd42c   4 weeks ago    10.8MB
mcr.microsoft.com/dotnet/runtime-deps   8.0-bookworm-slim    c1c04f4f46de   3 hours ago    121MB
mcr.microsoft.com/dotnet/runtime-deps   8.0-noble            2305d22833cb   2 weeks ago    120MB
mcr.microsoft.com/dotnet/runtime-deps   8.0-noble-chiseled   6f57bc2aeee1   4 weeks ago    14.3MB

[migig]

True. But the image size is not the issue.

Ubuntu (or even Debian) has more "stuff". In an Alpine (or other slim) container nothing extra is running and nothing extra is installed. The point of running an application in a Linux-based container is that it is as close to the OS as possible. The risk of weird stuff happening increases proportionally to the underlying OS' complexity.

Ubuntu Server is an excellent choice for many use cases, but not for application containers.

[richlander]

We are still publishing Alpine images. We plan to continue doing that. We've been publishing Alpine images since 2017. Sounds like that works for you.

It is not common for development platforms to publish Alpine as the default flavor. Users expect a glibc image as the default. Pi-Hole recently switched to Alpine as their default (or only option). Appliance images have more lattitude.

Debian has been the long-time default choice on Docker Hub, at least for official images. That's why we picked it to start with. A quick look suggests that hasn't changed. This quickly boils down to Debian or Ubuntu being the default choice since they are compatible. We've typically tried to align with the patterns chosen for the official images (and have asked for guidance from time to time from the fine folks at Docker to guide our decisions).

Here's our plan for .NET 10: dotnet/dotnet-docker#6539

[Viejon10-28]

The .NET Team provides support for a broad set of Linux distros. That is not changing. We made some decisions that in the last year that deserve mention to ensure that everyone understands our approach. We expect that this posting won't matter for most users.

Key decisions:

• Ubuntu 24.04 container images will be the default for .NET 10
• Debian Trixie container images will not be provided
• .NET 11 will target 20.04 for the glibc build

The following sections go into more detail. The first two decisions collapse down to a single explanation.

Debian container support

Debian is an excellent Linux distribution and has been a great workhorse for .NET. It also remains supported and we encourage .NET developers to use it. The only change is that we will not produce Debian container images starting with Trixie.

We realized that Debian wasn't a good choice for our default container images because both it and .NET have a 3 year support schedule (for mainline support) and Debian ships first. For example, that means that Debian Bookworm will transition into its EOL phase before .NET 8 does. We have previously encouraged users to upgrade to the next Debian version in similar cases. We should have realized and resolved this problem a long time ago, in retrospect. Sorry about that.

Once we decided to make Ubuntu our default image style, we then concluded that there was not a pressing reason to produce Debian images, since Debian and Ubuntu are very similar. This thinking applied to all .NET versions. It is also the case that upgrading from Debian Bookworm to Trixie has about the same ccompatibilityconcern as upgrading to Ubuntu Noble. LTS -> LTS should not be considered a "safe in-place upgrade" for Linux distributions.

• Debian Trixie Release Notes
• Ubuntu Noble Release Notes

As in past releases, we will continue to publish .NET 8 on Debian Bookworm after Bookworm EOL. Doing anything different would be a massive breaking change. Users can move to our .NET 8 Ubuntu Noble images (which we've been publishing since 2024) or produce their own Debian Trixie images.

Over the past few years, we have worked closely with Canonical and have completed key projects with them (packages and chiseled images). This relationship and the long Ubuntu LTS duration were key factors in deciding to choose Ubuntu as our default image. An additional factor is supply chain security. Canonical delivers the base images we use directly to Azure, resulting in no break in custody between the two organizations. We think that is valuable.

See Platforms for .NET 10 container images for more information on .NET 10 plans.

glibc / Ubuntu targeting

We adopted a new Linux build methodology with .NET 8, where we build the native components of .NET using a modern distro, modern tools, and header files acquired from an old Ubuntu distro. Each release, we announce these combinations.

• .NET 8 build
• .NET 9 build
• .NET 10 build

Our plan is to bump the Ubuntu version we target to a newer Ubuntu LTS on average every two years. .NET 8 targets 16.04, .NET 9 targets 18.04, and .NET 10 targets 18.04. .NET 11 will target Ubuntu 20.04. .NET 12 will target 20.04 or 22.04.

This approach has a lot of benefits. Most of our build system is very modern, however, it enables users to run .NET apps on old deployments should they need to. Enablement is not the same as Support (capital "S" support). For example, .NET 10 is commercially supported on Ubuntu 22.04+, not on Ubuntu 18.04 or 20.04.

We recently had a conversation on whether we would drop OpenSSL 1.x support. OpenSSL 1.x to 3.x was an ecosystem-wide update and forms a sort of Linux compatibility epoch. We decided that we'd hold off until at least .NET 12 until making that change. Either way, we'll drop OpenSSL 1.x support (small "s" support) when we switch to targeting Ubuntu 22.04 in our build. We haven't decided that yet and won't entertain that discussion for another year.