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

31–40 of 211 posts

Re: What to expect from Debian/Trixie

#31

Post by LooseMarmoset »

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.

Re: What to expect from Debian/Trixie

#32

Post by juujian »

Have been using Trixie on my laptop for a year (?) now, it has been a very positive experience. I had brought a brand new, very recent ThinkPad, not considering that the relevant drivers would not be in Debian Stable yet. Now on Trixie, having a relatively recent version of everything KDE plasma is a blessing. Things have changed so much, for the better, particularly regarding Wayland. The experience with Trixie is already better than it ever was for me with Ubuntu (good riddance!), and I cannot believe that this is supposed to be an unstable release. I broke stuff once, and that was my own fault (forcing update when not all necessary packages were staged yet, learned my lesson on that!).

Re: What to expect from Debian/Trixie

#33

Post by pss314 »

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?

Introduction to Debian packaging https://www.debian.org/doc/devel-manuals#packaging-tutorial

Best Packaging Practices https://www.debian.org/doc/manuals/developers-reference/best...

Re: What to expect from Debian/Trixie

#35

Post by sugarpimpdorsey »

paulv wrote: post #10
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…

> Ask me how I know. What problems did you have that made you want to roll back the update?

I had some containerized application software break and start misbehaving in odd ways which was indicative of a deeper incompatibility issue. Possibly GPU related. No time to debug, had to roll it back.

This was complicated by the fact that the machine also hosted a MySQL database which could not be easily rolled back because the database was versioned up during the upgrade.

Re: What to expect from Debian/Trixie

#36

Post by tlamponi »

grantla wrote: post #29
tlamponi wrote: post #12

Earlier quoted context omitted.

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…

> 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 Note that the naming scheme is in control of systemd, not the kernel. Even if it is passed on the kernel commandline.

Yeah, I know, I spent more than a week into looking for options to reduce impact for all of our users.

And note that cgroupv1 also still works in the kernel just fine, only the part that systemd controlled was removed from systemd. You can still boot with cgroupv1 support on, e.g., Alpine Linux and OpenRC as init 1. So not sure if that will lessen my concerns about no guarantees for older naming-scheme versions, maintaining triple digits of them sure has its cost too.

And don't understand me wrong, sunsetting cgroupv1 was reasonable, but it was a lot of churn, it at least was a one time thing. The network interface naming situation is periodic churn, guaranteed to bite you every now and then just by using the defaults.

Re: What to expect from Debian/Trixie

#38

Post by wpm »

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.

It’s why I always say in the typical “systemd bad” threads that systemd the init system is great, it’s the systemd-* everything else’s that give it a bad name.

I want systemd nowhere fucking near my NTP or DNS config.

Re: What to expect from Debian/Trixie

#39

Post by woleium »

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…

I imagine they went against mac address because it is not immutable, some folks rotate mac addresses for privacy/security reasons.

Re: What to expect from Debian/Trixie

#40

Post by Scramblejams »

tlamponi wrote: post #36
grantla wrote: post #29

Earlier quoted context omitted.

> 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 Note that the naming scheme is in control of systemd, not the kernel. Even if it is passed on the kernel commandline.

Yeah, I know, I spent more than a week into looking for options to reduce impact for all of our users. And note that cgroupv1 also still works in the kernel just fine, only the part that systemd controlled was removed from systemd. You can still boot with cgroupv1 support on, e.g., Alpine Linux and OpenRC as init 1. So not sure if that will lessen my concerns about no guarantees for older naming-scheme versions, main…

Can you tell me why NamePolicy=keep doesn't do the trick?

Looking myself for options to keep a Debian bare metal server I admin from going deaf and mute the next time I upgrade it... It still uses an /etc/network/interfaces file that configures a bridge for VMs to use, and the bridge_ports parameter requires an interface name which, when I upgraded to Bookworm, changed.

At this rate maybe I'll write a script that runs on boot and fixes up that file with whatever interface it finds, then restarts the network.

Post reply on HN