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…
What to expect from Debian/Trixie
61–70 of 211 posts
Re: What to expect from Debian/Trixie
#62Earlier 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.
as much as I love Debian (been a faithful user since 25 years or so, no more Windows at home since then), that Windows ability is just really cool and Debian is still not on par I believe...
Re: What to expect from Debian/Trixie
#63Earlier quoted context omitted.
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.
fighting your distro in practice is a total nightmare.
Re: What to expect from Debian/Trixie
#64Earlier quoted context omitted.
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…
https://chrisdown.name/2018/01/02/in-defence-of-swap.html
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 for disk cache to avoid the thrashing problem. I don't know what the kernel actually does here (or what its tunables are), because systems with swap off have never caused problems for me the way systems with swap on inevitably do. The OOM killer works fine with swap off, because a system must always be resilient to unexpected process failure.
And worst of all - the kernel requires swap (and its bugs) to be enabled for hibernation to work.
It really wouldn't be hard to design a working swap system (just calculate how much to keep of different purposes of swap, and launch the OOM killer earlier), but apparently nobody in kernel-land understands the real-world problems enough to bother.
Re: What to expect from Debian/Trixie
#65TIL there are 14 subtly different naming schemes for network interfaces[1]. "predictable" my ass. [1] https://manpages.debian.org/testing/systemd/systemd.net-nami...
The "stable" interface naming scheme is a scam. And I have proof. Test upgraded a VM today, from bookworm to trixie. And guess what. Everything worked, except after reboot the network interface was unconfigured? Guess what. The name changed...
That can only happen if the emulated hardware layout presented to the VM changes. I'd look at that before calling anything a scam.
Re: What to expect from Debian/Trixie
#66Earlier quoted context omitted.
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.
[deleted]
Re: What to expect from Debian/Trixie
#67Earlier 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.
There are, unfortunately, some older devices (like some Sun systems) which use the same MAC address for every network interface on the device.
Re: What to expect from Debian/Trixie
#68Earlier 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…
The sane thing is to have swap enabled. Having swap "disabled" forces your system to swap out executables to disk, since these are likely the only memory-mapped files you have. So, if your memory fills up, you get catastrophic thrashing of the instruction cache. If you're lucky, you really go over available memory, and the OOMKiller kills some random process. But if you're not, your system will keep chugging along at a snail's pace.
Perhaps disabling overcommit as well as swap could be safer from this point of view. Unfortunately, you get other problems if you do so - as very little Linux software handles errors returned by malloc, since it's so uncommon to not have overcommit on a Linux system.
I'd also note that swap isn't even that slow for SSDs, as long as you don't use it for code.
Re: What to expect from Debian/Trixie
#69TIL there are 14 subtly different naming schemes for network interfaces[1]. "predictable" my ass. [1] https://manpages.debian.org/testing/systemd/systemd.net-nami...
The best use of AI I've gotten so far is having it explain to me how to manage a Fedora Server's core infrastructure "the right way". Which files, commands, etc. to permanently or temporarily change network, firewall, DNS, NTP settings.
Re: What to expect from Debian/Trixie
#70I'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 part everything has worked without the need to fix broken packages or utter magic apt incantations.
Debian has always been very impressive to me. They're certainly not perfect, but what they can do based on volunteers, donations, and sponsors, is amazing.