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

41–50 of 211 posts

Re: What to expect from Debian/Trixie

#41

Post by esaym »

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…

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

Re: What to expect from Debian/Trixie

#42

Post by e2le »

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.

Re: What to expect from Debian/Trixie

#44

Post by blueflow »

wpm wrote: post #38
LooseMarmoset wrote: post #31

Earlier quoted context omitted.

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.

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.

Re: What to expect from Debian/Trixie

#45

Post by idoubtit »

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…

> 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.

Re: What to expect from Debian/Trixie

#46

Post by mikae1 »

BoredPositron wrote: post #25
sugarpimpdorsey wrote: post #17

Earlier quoted context omitted.

Yet Windows will let you roll back an upgrade with a single click within 10 days. Of course anyone can restore from backups. It's a pain and it's time consuming. My post serves more as a warning to those who may develop buyer's remorse.

You know imaging your machine is still an option...

But you can't do that on a live system as you can with Windows or macOS. Not a problem for pre release upgrade perhaps. But I'm so missing this feature from macOS.

Re: What to expect from Debian/Trixie

#47

Post by idoubtit »

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.

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 restart.

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

My experience is that these points largely outweigh the downsides (the only one I can think of is that the socket could be written in two places).

Re: What to expect from Debian/Trixie

#48

Post by elcapitan »

I've been running Trixie since I bought my Framework laptop last September, and it has been great. First Linux experience after 20 years of Mac, and everything has been incredibly stable.

Now I need to figure out what happens when my testing suddenly is stable, and how to get on the next testing, I guess.

Re: What to expect from Debian/Trixie

#49

Post by em-bee »

woleium wrote: post #39
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…

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

i thought about that, but couldn't you access the hardcoded address to identify the card?

but you also want to be able to change a card in a server without the device name changing. at least that used to be an issue in the past.

Re: What to expect from Debian/Trixie

#50

Post by tlamponi »

woleium wrote: post #39
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…

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

The original one is still there. Systemd knows even about that, it's differentiated as MAC vs PermanentMAC.
Post reply on HN