Live data from Hacker News

What to expect from Debian/Trixie

michael-prokop.at

111–120 of 211 posts

Re: What to expect from Debian/Trixie

#111

Earlier quoted context omitted.

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…

Sadly a NIC's permanent MAC is known to not always be unique: https://www.howtogeek.com/228286/how-is-the-uniqueness-of-ma...

As long as you only got NICs with different permanent MAC addresses installed that does not matter for getting actually long-term stable names.

And for the other case you can still fallback to the other policies, it still will be much more stable by default.

Please note that I don't say that MAC is perfect, but using something that is actually tied to a NIC itself would fare much better by default compared to the NICs position as determined by a bunch of volatile information, and what normally does not matter to me at all, as e.g., I will always use a 100G NIC as ceph private network while the 25G ones as public one, no matter where they are plugged in. That someone configures something by location is the excpection, not the norm.

Re: What to expect from Debian/Trixie

#112
post #73
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. :)

Yup.. use this default on all my systems. Did a bookworm->trixie upgrade today on my mailserver, and everything worked, as it still just has eth0 ;)

Re: What to expect from Debian/Trixie

#113
post #86
post #64

Earlier quoted context omitted.

An ivory tower answer. All those arguments would be useful if we somehow could avoid the fact that the system will use it as "emergency memory" and become unresponsive. The kernel's OOM killer is broken for this, and userland OOM daemons are unreliable. `vm.swappiness` is completely useless in the worst case, which is the only case that matters. With swap off, all the kernel needs to do is reserve a certain threshold…

the kernel requires swap (and its bugs) to be enabled for hibernation to work this one gets me irritated every time i think about it. i don't want to use swap, but i do want hibernation. why is there no way to disable swap without that? hmm, i suppose one could write a script that enables an inactive swap partition just before shutdown, and disables it again after boot.

I never want to use hibernation, since then I have to re-enter my disk encryption passphrase at resume time, have to wait longer for both suspend and resume because it needs to sync upto 48GB to/from disk (and I don't want to waste 48GB of diskspace for swapspace/hibernation). Suspend to ram is fine, I can keep the system suspended for a couple of days without issues, but it only needs to survive a long weekend at most. Resume from RAM is about instant, and then just needs a screensaver unlock to get back to work.

Re: What to expect from Debian/Trixie

#115
post #3

Earlier quoted context omitted.

That has never been supported: https://wiki.debian.org/SystemDowngrade

I said possible, not supported. Too many bits of 'advice' on Stack Overflow, etc. claiming it's possible as top Google results. I'm here to say unequivocally: it does not work, will not work, and will leave the system in an irreversibly broken state. Do not attempt.

Well... then it's always been possible, if you use LVM and create a snapshot before upgrading, then you can revert your snapshot in case it breaks.

But this isn't something that would be 'out of the box'... but that's why we make backups, but I can't remember an dist-upgrade ever significantly bricking my systems.

Re: What to expect from Debian/Trixie

#117

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.

devuan saved just enough of my sanity for me to function

Yes! I'm hoping for another Devuan release after this.

Re: What to expect from Debian/Trixie

#118

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

Just using KDE solves both your problems.

Ahahahaha!

The reply writes itself, doesn’t it? :-D

I like GNOME more though, in general. I just want GNOME without some of the unfathomable stuff, and with the progress KDE has made with Wayland.

Re: What to expect from Debian/Trixie

#119

Earlier quoted context omitted.

The page about upgrading [0] does have this warning: Back up your data Performing a release upgrade is never without risk. The upgrade may fail, leaving the system in a non-functioning state. USERS SHOULD BACKUP ALL DATA before attempting a release upgrade. DebianStability contains more information on these steps. [0] https://wiki.debian.org/DebianUpgrade

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.

Linux Mint offers rollbacks, I have snapshots going back a point release and a major version.

Re: What to expect from Debian/Trixie

#120
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…

i been running unstable since 2004 or so. i think it broke only once when I skipped year of updates
Post reply on HN