Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to expect from Debian/Trixie

michael-prokop.at

Post reply on HN
Print view View original

91–100 of 211 posts

Re: What to expect from Debian/Trixie

#91

Post by TacticalCoder »

e2le wrote: post #42
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…

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.

I think it doesn't outweight the downside. Let's not forget this:

"OpenSSH normally does not load liblzma, but a common third-party patch used by several Linux distributions causes it to load libsystemd, which in turn loads lzma."

The "XZ utils backdoor" nearly backdoored every single distro running systemd.

People (including those who tried to plant this backdoor) are going to say: "systemd has nothing to do with the backdoor" but I respectfully disagree.

systemd is one heck of a Rube-Goldberg piece of machinery: the attack surface is gigantic seen that systemd's tentacles reaches everywhere.

With a tinfoil hat on one could think the goal of systemd was, precisely, to make sure the most complicated backdoors could be inserted here and there: "Let's have openssh use a lib it doesn't need at all because somehow we'll call libsystemd from openssh".

Genius idea if you ask me.

What could possibly go wrong with systemd "now just opening a port for openssh" uh? Nothing I'm sure.

Now that said I'm very happy that we've now got stuff like the Talos Linux distribution (ultra minimal, immutable, distro meant to run Kubernetes with as few executables as possible and of course no systemd) and then containers using Alpine Linux or, even if Debian based, minimal system with (supposedly) only one process running (and, once again, no systemd).

Containerization is one way out of systemd.

I can't wait for a good systemd-less hypervisor: then I can kiss Microsoft goodbye (systemd is a Microsoft technology, based on Microsoftism, by a now Microsoft employee).

Thanks but no thanks.

Talos distro, systemd-less containers: I want more of this kind of mindset.

The future looks very nice.

systemd lovers should just throw the towel in and switch to Windows: that's what they actually really want and it's probably no better than they deserve.

Re: What to expect from Debian/Trixie

#92

Post by tlamponi »

pferde wrote: post #89
tlamponi wrote: post #87

Earlier quoted context omitted.

Scam is probably the wrong word, and it's choice might be a bit feeling fueled, but it's really not true that this only depends on the HW. systemd also changes behavior in what naming policies are the default and what it considered as input, it did that since ever but started to version that since v238 [0]. Due to that the HW can stay exactly the same but names still change. I see this in VMs that stay exactly the sa…

Ah, ok, I didn't think of systemd version changes. Thanks. Regarding your rhetorical question about "the same NIC", I think the problem is in determining whether the NIC is the same, and it is not an easy one to solve. I remember that older Suse Linux versions used to pin the interface name to the NIC's MAC address in an udev rule file that got autogenerated when a NIC with a given MAC first appeared on the system, b…

Yeah, the permanent MAC address (i.e., the one the card actually reports to the system not the one dynamic one it can use) would be the safest bet, as that is the most stable thing there is, and more importantly, it is very relevant for switches and firewalls in enterprise settings, so if it changes it's often likely that network access will be broken any way, so one basically can only win with using the MAC as main identifier IMO, at least compared to the current status quo.

Re: What to expect from Debian/Trixie

#93

Post by tcdent »

doctoboggan wrote: post #54
tcdent wrote: post #19

Woah Python 3.13 in stable?! (I love Debian) It's going to take a bit for me to get used to having a current version of Python on the system by default.

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

Obvs uv, but I'm not going to install a dupe version of python with pyenv if the system version matches my target.

Re: What to expect from Debian/Trixie

#94

Post by em-bee »

o11c wrote: post #60
ducktective wrote: post #15

Can anyone experienced with debian package development, point me to some valid, recent and Best Practice™ guides or blog posts explaining how to package stuff for Debian?

The native Debian package tooling is very far from sane, even compared to other distros - and they actively refuse to make it saner (instead just adding layers of cruft without addressing the core problems). You're probably best off using `checkinstall` or similar, and adding dependencies by hand.

is RPM that much saner? which RPM based distribution comes with long term support suitable for servers that also includes btrfs? (i used to use centos, but since red hat removed btrfs from the kernel, refusing to support it, i had to switch to debian, because i depend on btrfs support)

Re: What to expect from Debian/Trixie

#95

Post by layer8 »

tok1 wrote: post #81
willemlaurentz wrote: post #37

Warning for those running Debian and Dovecot under stable. In this new stable release, an update to Dovecot will break your configuration: https://willem.com/blog/2025-06-04_breaking-changes/

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…

You might be interested in https://codeberg.org/errror/dovecot-replication.

Re: What to expect from Debian/Trixie

#96

Post by exiguus »

kelnos wrote: post #70

I've been running testing/trixie since the end of 2023 or so. (I generally always run testing, but stick with stable for ~6 months after stabilization, in order to avoid lots of package churn in new-testing.) It's been what I expect from Debian: boring and functional. I've never run into an issue where the system wouldn't boot after an update (I usually update once every 2-4 weeks when on testing), and for the most p…

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

Re: What to expect from Debian/Trixie

#97

Post by pmontra »

tok1 wrote: post #81
willemlaurentz wrote: post #37

Warning for those running Debian and Dovecot under stable. In this new stable release, an update to Dovecot will break your configuration: https://willem.com/blog/2025-06-04_breaking-changes/

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…

I usually fix those kind of problems by running the offending software in a docker container, with the correct version. Sometimes the boundaries of the container create their own problems. Dovecot 2.3 is at https://hub.docker.com/r/dovecot/dovecot/tags?name=2.3

Re: What to expect from Debian/Trixie

#98

Post by yjftsjthsd-h »

sugarpimpdorsey wrote: post #2

Fair warning: the Trixie update does not allow you to roll back. It is in theory possible but practically it not only fails every single time, but leaves the system in an inconsistent and broken state. (Code for 'soon to be unbootable'). What this means is when you find out stuff breaks, like drivers and application software, and decide the upgrade was a bad idea, you are fucked. More notably, some of the upgrade is…

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.

Re: What to expect from Debian/Trixie

#99

Post by yjftsjthsd-h »

em-bee wrote: post #94
o11c wrote: post #60

Earlier quoted context omitted.

The native Debian package tooling is very far from sane, even compared to other distros - and they actively refuse to make it saner (instead just adding layers of cruft without addressing the core problems). You're probably best off using `checkinstall` or similar, and adding dependencies by hand.

is RPM that much saner? which RPM based distribution comes with long term support suitable for servers that also includes btrfs? (i used to use centos, but since red hat removed btrfs from the kernel, refusing to support it, i had to switch to debian, because i depend on btrfs support)

> which RPM based distribution comes with long term support suitable for servers that also includes btrfs?

Sounds like OpenSUSE to me. I tend to favor the fast-updating versions, but I'm pretty sure openSUSE Leap is exactly what you're asking for.

Re: What to expect from Debian/Trixie

#100

Post by NekkoDroid »

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…

> If /tmp/ fills up your RAM

tmpfs by default only uses up to half your available RAM unless specified otherwise. So this isn't really a consideration unless you configure it to be a consideration you need to take into account.

(Systemd also really recently (v258) added quotas to tmpfs and IIRC its set by default to 80% of the tmpfs, so it is even less of a problem)

Post reply on HN