What to expect from Debian/Trixie

This is exactly why I use Debian when I install Linux. I want something that will keep chugging along, yet may not have the most cutting edge software. I can take my time with the system, and know that it is solid.

If I need newer software that isn't in their package repository, I understand that I have the ability to compile what I need, or at least make an active decision to modify my system to run what I want. Basically, the possibility of instability is a conscious choice for me, which I do sometimes take.

This could be me. I do the same, and i already plan to update to Forky at the beginning of 2026.

i been running unstable since 2004 or so. i think it broke only once when I skipped year of updates

I suspect that systemd people are looking at this thread in perplexity, and probably doing their thing (that I've seen over the years) of regarding the world of Debian as being amazingly behind the times in places.

The SSH server being a socket unit with systemd doing all of the socket parallelism-limiting and accepting was one of the earliest examples of socket activation ever given in systemd. It was in one of Lennart Poettering's earliest writings on the subject back in 2011.

* https://0pointer.de/blog/projects/inetd.html

And even that wasn't the earliest discussion of this way of running SSH by a long shot, as this was old news even before systemd was invented. One can go back years earlier than even Barrett's, Silverman's, and Byrnes's SSH: The Secure Shell: The Definitive Guide published in 2005, which is one of many places explaining that lots of options in sshd_config get ignored when SSH is started by something else that does all of the socket stuff.

Like inetd.

This has been the case ever since it has been possible to put an SSH server together with inetd in "nowait" mode. Some enterprising computer historian might one day find out when the earliest mention of this was. It might even be in the original 1990s INSTALL file for SSH.

> 2) OpenSSH server was installed as systemd socket activated and so ignored /etc/ssh/sshd_config.

sshd still reads /etc/ssh/sshd_config at startup. As far as I know, this is hard-coded in the executable.

What Debian has changed happens before the daemon is launched: the service is socket activated. So, _if you change the default port of sshd_ in its config, then you have to change the activation:

- either enable the sshd@service without socket activation,

- or modify the sshd.socket file (`systemctl edit sshd.socket`) which has the port 22 by default.

Since Debian already have a environment file (/etc/default/ssh), which is loaded by this service, the port could be set in a variable there and loaded by the socket activation. But then it would conflict with OpenSSH's own files. This is why I've always disliked /etc/default/ as a second level of configuration in Debian.

systemd-resolved is an effing nightmare when combined with network-manager. these two packages consistently manage to stomp all over DNS resolution in their haste to be the one true source of name resolution. i tried enabling systemd-resolved as part of an effort to do dns over https and i end up with zero dns. i swear that /etc/resolv.conf plus helper scripts is more consistent and easy.

What is the rationale for changing OpenSSH into a socket activated service? Given that it comes with issues, I assume the benefits outweigh the downsides.

The OpenSSH change is madness if it's not a bug. I hope it's not intentional.

> 2) OpenSSH server was installed as systemd socket activated and so ignored /etc/ssh/sshd_config*. Maybe this is something specific to the container downloaded.

Doesn't the .socket unit point to a .service unit? Why would using a socket be connected to which config sshd reads?

14 different schemes multiplied by some acting slightly different in every version. Sure you can pin it, but that fixes only their internal back and forth, is only possible via the kernel cmdline and there is no guarantee for how long the old versions will stay available, as they deprecated much more invasive things in the past (e.g., cgroupv1) I'd expect them to also drop older versions here, breaking ones naming again.

And sure, one can pin interfaces to custom names, but why should anybody have to bother with such things?!

I like systemd a lot, but this is one of the thing they fumbled big time and seemingly still aren't done.

Pinning interfaces by their MAC to a short and usable name, would e.g. have been much more stable as doing that by PCI slot, which firmware updates, new hardware, newer kernel exposing newer features, ... changes rather often. This works well for all but virtual functions, but those are sub-devices of their parent interface anyway and can just get named with a suffix added to the parent name.

I dislike systemd's Predictable Network Interface Names, so I disable them with this kernel command line option: net.ifnames=0

Welcome back, eth0. :)

The best use of AI I've gotten so far is having it explain to me how to manage a Fedora Server's core infrastructure "the right way". Which files, commands, etc. to permanently or temporarily change network, firewall, DNS, NTP settings.

The "stable" interface naming scheme is a scam. And I have proof. Test upgraded a VM today, from bookworm to trixie. And guess what. Everything worked, except after reboot the network interface was unconfigured? Guess what. The name changed...

For users with SSDs, saving the write wear seems like a desirable default.

finally they're using a tmpfs. thank goodness <3

> You can return to /tmp being a regular directory by running systemctl mask tmp.mount as root and rebooting.

>The new filesystem defaults can also be overridden in /etc/fstab, so systems that already define a separate /tmp partition will be unaffected.

Seems like an easy change to revert from the release notes.

As far as the reasoning behind it, it is a performance optimization since most temporary files are small and short lived. That makes them an ideal candidate for being stored in memory and then paged out to disk when they are no longer being actively utilized to free up memory for other purposes.

Wait... that means a misbehaving program can cause out of memory errors easily by filling up /tmp?

That's a very bad default.

Probably still good practice to use venv and a python executable version maintainer (uv could be used for both).

The page about upgrading [0] does have this warning:

  Back up your data
  
  Performing a release upgrade is never without risk. The upgrade may fail, leaving the system in a non-functioning state. USERS SHOULD BACKUP ALL DATA before attempting a release upgrade. DebianStability contains more information on these steps.

That has never been supported: https://wiki.debian.org/SystemDowngrade

In all fairness... How would that work? Not even just on Debian; in the general case, I don't see how to avoid that other than full filesystem snapshots or backups of some sort. Even on, say, a NixOS system where rolling back all the software and config (basically, /, /usr, and /etc) to exactly its old config is as easy as rebooting and picking the old generation, databases will still have migrated their on-disk format.

> Ask me how I know.

What problems did you have that made you want to roll back the update?

You should be using an lvm snapshot. You are not even making a valid complaint.

Not only that: Dovecot 2.4 will also remove the functionalities of dsync, replicator and director [1]. This is frustrating and a big loss as these enabled e.g. very simple and reliable two-node (active-active) redundant setups, which will not be possible anymore with 2.4.

I use it for years to achieve HA for personal mail servers and will now have to look for alternatives -- until then will stick with Debian Bookworm and its Dovecot 2.3.

[1] https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2....

There is basically two different configurations. If your `sources.list` is explicitly on Trixie, it will stay there. If it is on testing, then you will get the next testing release in time.