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

171–180 of 211 posts

Re: What to expect from Debian/Trixie

#171

Post by zbentley »

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…

I also have a hunch that socket activation allows for more predictability around what a not-running/listening-for-activation service's port is doing at the syscall/kernel level, which in turn makes power saving and/or sleep states a little more predictably efficient.

Total guess, mind you.

Re: What to expect from Debian/Trixie

#172

Post by gpderetta »

rurban wrote: post #156
abenga wrote: post #150

Earlier quoted context omitted.

Exactly where is Debian "not working"?

Almost daily at work. Always have to verify with my fedora machines that it is indeed debian/ubuntu and not upstream.

debian or ubuntu? I have had terrible experience in the past with ubuntu breaking randomly, but debian has been fairly stable for a desktop machine

Re: What to expect from Debian/Trixie

#173

Post by eklavya »

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…

Want to do that but there is no official nvidia driver and cuda installation support for testing. Only major releases.

Re: What to expect from Debian/Trixie

#174

Post by _fat_santa »

exiguus wrote: post #96
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.

> plan to update to Forky

Why do you want to switch to Ubuntu?

I'm sorry I had to, I'll show myself out

Re: What to expect from Debian/Trixie

#176

Post by [deleted] »

hsbauauvhabzb wrote: post #103
_mlbt wrote: post #13

Earlier quoted context omitted.

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

That seems like a bug with those applications which make use of the filesystem instead of performing in-memory operations or using named pipes.

[deleted]

Re: What to expect from Debian/Trixie

#177

Post by tpoindex »

yehoshuapw wrote: post #72
dijit wrote: post #63

Earlier quoted context omitted.

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

MX Linux for the win. Debian based, but defaults to 'init'. Booting with systemd is an option. Just enough systemd-* running to make things easy and seamless.

  $ ps agxf|grep 'systemd'
      607 ?        S      0:00 /lib/systemd/systemd-udevd
     2201 ?        S      0:00 /sbin/cgmanager --daemon -m name=systemd
     2726 ?        S      0:00 /lib/systemd/systemd-logind
Also can install Nvidia or AMD video drivers.

Re: What to expect from Debian/Trixie

#178

Post by seabrookmx »

tcdent wrote: post #93
doctoboggan wrote: post #54

Earlier quoted context omitted.

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.

Why use pyenv if you have uv?

Re: What to expect from Debian/Trixie

#179

Post by seabrookmx »

1oooqooq wrote: post #107

why even include Intel xeon cpu drm? are xeons still available?

Lol what?

Yes, every data center in the world still runs on Intel Xeon because AMD can't get a big enough allocation at TSMC to meet demand.

The reports of Intel's death are greatly exaggerated.

Re: What to expect from Debian/Trixie

#180

Post by tremon »

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.

  chattr +i /etc/resolv.conf
It's the only long-term solution to that problem that I endorse. Every attempt of working with the system, whether via systemd.network, resolved.conf or resolvconf, has always eventually bit me one way or another.
Post reply on HN