What to expect from Debian/Trixie • Hacker News Board

Re: What to expect from Debian/Trixie

#71

Post by RVuRnvbM2e » Wed, Jul 23, 2025, 8:01 PM UTC

LooseMarmoset wrote: post #31

sherr wrote: post #16

Looking forward to the release. I use Debian Stable on almost all the systems I use (one is stuck on 10/Buster due to MoinMoin). I installed Trixie in a container last week, using an LXC container downloaded from linuxcontainers.org [1]. Three things I noted on the basic install : 1) Ping didn't work due to changed security settings (iputils-ping) [2] 2) OpenSSH server was installed as systemd socket activated and so…

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.

I've been using this combination successfully for a long time with no issues. In fact it is the only way to handle complex DNS setup on Linux.

If you have specific issues, please file them over at systemds GitHub issue tracker.

Re: What to expect from Debian/Trixie

#72

Post by yehoshuapw » Wed, Jul 23, 2025, 8:06 PM UTC

dijit wrote: post #63

blueflow wrote: post #44

Earlier quoted context omitted.

Thank god you can enable and disable each of these components in complete isolation, so you don't suffer any kind of lock-in from systemd.

fighting your distro in practice is a total nightmare.

I ended up in gentoo mostly just to avoid systemd

(used it before, mostly to learn. went to debian for new laptop. gave up after fighting systemd. I'm aware of devuan and artix, but gentoo just worked (after all the time spent))

Re: What to expect from Debian/Trixie

#73

Post by foresto » Wed, Jul 23, 2025, 8:07 PM UTC

blueflow wrote: post #6

TIL there are 14 subtly different naming schemes for network interfaces[1]. "predictable" my ass. [1] https://manpages.debian.org/testing/systemd/systemd.net-nami...

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

Welcome back, eth0. :)

Re: What to expect from Debian/Trixie

#74

Post by olivierestsage » Wed, Jul 23, 2025, 8:10 PM UTC

Pumped for this. I was (and am) massively impressed with Debian 12. I've been an on-again off-again Linux user since around 2003, but this release was the one that finally got me to switch completely. The jank factor actually seems to be less than that of Windows and macOS at this point, which I never thought I'd say.

Re: What to expect from Debian/Trixie

#75

Post by nonameiguess » Wed, Jul 23, 2025, 8:13 PM UTC

o11c wrote: post #58

CamouflagedKiwi wrote: post #11

Earlier quoted context omitted.

A misbehaving program can cause out of memory errors already by filling up memory. It wouldn't persist past that program's death but the effect is pretty catastrophic on other programs regardless.

That actually is a pretty big difference. Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled), a program that tries to allocate all memory will quickly get OOM killed and the system will recover quickly. If /tmp/ fills up your RAM, the system will not recover automatically, and might not even be recoverable by hand without rebooting. That said, systemd-managed…

User paulv already posted this 3 hours ago in a comment currently lower than this one, but tmpfs by default can't use all of your RAM. /tmp can get filled up and be unavailable for anything else to write to, but you'll still have memory. It won't crash the entire system.

Re: What to expect from Debian/Trixie

#76

Post by foresto » Wed, Jul 23, 2025, 8:14 PM UTC

paulv wrote: post #9

api wrote: post #7

Earlier quoted context omitted.

Wait... that means a misbehaving program can cause out of memory errors easily by filling up /tmp? That's a very bad default.

The default configuration for tmpfs is to "only" use 50% of physical ram, which still isn't great, but it's something.

To be clear, that 50% (or whatever you configure) is a limit, not a constant.

Re: What to expect from Debian/Trixie

#77

Post by demetris » Wed, Jul 23, 2025, 8:20 PM UTC

Trixie is SUPER for desktop use!

I’ve been on sid for the last 10 months for my laptop (old T450s) and my secondary desktop, and it is really fun.

There are annoyances but they are not related to Debian itself.

FIRST

I decided it is time to switch to Wayland. Now my favorite run-or-raise app (Kupfer) cannot do run-or-raise. But there is a really nice extension to do run-or-raise on GNOME without the aggressive disruption of the Activities overview: Switcher. The other thing that is difficult on Wayland is text expansion. I have not found a solution for that part.

SECOND

The annoying to infuriating things that GNOME likes doing sometimes. But that is a constant. Nothing new.

Congrats and thanks to all the Debian people!

Re: What to expect from Debian/Trixie

#78

Post by b112 » Wed, Jul 23, 2025, 8:24 PM UTC

tlamponi wrote: post #12

blueflow wrote: post #6

TIL there are 14 subtly different naming schemes for network interfaces[1]. "predictable" my ass. [1] https://manpages.debian.org/testing/systemd/systemd.net-nami...

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 ag…

This worked brilliantly in Debian for more than a decade, had almost zero downside, and just did what asked. I went through 3+ dist-upgrades, for the first time in my life, without a NIC change.

It was deprecated for this nonsense in systemd.

Yes, there were edge cases in the Debian scheme. Yet it did work with VMs (as most VMs kept the same MAC in config files), and it was easy to maintain if you wanted 'fresh'. Just rm the pin file in the udev dir. Done.

Again it worked wonderful on every VM, every bare metal system I worked with.

One of the biggest problems with systemd, is it seems to be developed by people that have no real world, industrial scale admin experience. It's almost like a bunch of DEVs got together, couldn't understand why things were "so confusing", and just figured "Oh, it must be a mistake".

Nope.

It's called covering edge cases, ensuring things are stable for decades, because Linux and the init system are the bottom of the stack. The top of the stack changes like the wind in spring, but the bottom of the stack must be immensely stable, consensus driven, I repeat stable change.

Systemd just doesn't "get" that.

Re: What to expect from Debian/Trixie

#79

Post by Aachen » Wed, Jul 23, 2025, 8:25 PM UTC

chromakode wrote: post #14

josephscott wrote: post #5

"The temporary-files directory /tmp is now stored in a tmpfs" - https://www.debian.org/releases/trixie/release-notes/issues.... I am not a fan of that as a default. I'd rather default to cheaper disk space than more limited and expensive memory.

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

I have yet to hear of someone wearing out an SSD on a desktop/laptop system (not server, I'm sure there's heavy applications that can run 24/7 and legitimately get the job done), even considering bugs like the Spotify desktop client writing loads of data uselessly some years ago

Making such claims on HN attracts edge cases like nobody's business but let's see

Re: What to expect from Debian/Trixie

#80

Post by blueflow » Wed, Jul 23, 2025, 8:26 PM UTC

idoubtit wrote: post #47

e2le wrote: post #42

Earlier quoted context omitted.

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.

> Given that it comes with issues, I assume the benefits outweigh the downsides. Any change can introduce regressions or break habits. The move toward socket activation for sshd is part of a larger change in Debian. I don't think the Debian maintainers changed that just for the fun of it. I can think of two benefits: + A service can restart without interruption, since the socket will buffer the requests during the re…

> Dependencies are simpler and faster (waiting for a service to start and accept requests is costly)

Yeah, but requiring a service's response is why its a dependency in the first place, no?