101–110 of 211 posts
Earlier quoted context omitted.
The OpenSSH change is madness if it's not a bug. I hope it's not intentional.
It was done in Ubuntu a few versions ago. Afaik only the listening port config is ignored and instead is setup in systemd
What else is lurking that you and I aren’t aware of?
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...
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...
"The temporary-files directory /tmp is now stored in a tmpfs" - https://www.debian.org/releases/trixie/release-notes/issues.... I am not a fan of that as a default. I'd rather default to cheaper disk space than more limited and expensive memory.
> 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…
Earlier quoted context omitted.
The native Debian package tooling is very far from sane, even compared to other distros - and they actively refuse to make it saner (instead just adding layers of cruft without addressing the core problems). You're probably best off using `checkinstall` or similar, and adding dependencies by hand.
is RPM that much saner? which RPM based distribution comes with long term support suitable for servers that also includes btrfs? (i used to use centos, but since red hat removed btrfs from the kernel, refusing to support it, i had to switch to debian, because i depend on btrfs support)
I don't think there are many alternatives. OpenSUSE isn't supported for very long, and there really isn't anything else if you want btrfs, no Debian or its derivatives, and fire & forget kind of distribution.
Edit: Also look at Alpine Linux, if supports btrfs and has one of the best package formats that is an absolute joy to write (way easier than rpm or deb).
It's pretty different in some areas (no systemd and musl being two examples), check if that's fine for you.
Earlier quoted context omitted.
is RPM that much saner? which RPM based distribution comes with long term support suitable for servers that also includes btrfs? (i used to use centos, but since red hat removed btrfs from the kernel, refusing to support it, i had to switch to debian, because i depend on btrfs support)
Oracle Linux (gasp). They employ some of the main developers of btrfs, "their" distribution is just a RHEL rebuild with some patches (including btrfs), and it is very quick at delivering updates (they're usually several hours behind RHEL, while the next best — AlmaLinux — takes a day or two. Other rebuilds, very much including the somehow heavily hyped Rocky, are much slower). I don't think there are many alternative…
Earlier quoted context omitted.
The native Debian package tooling is very far from sane, even compared to other distros - and they actively refuse to make it saner (instead just adding layers of cruft without addressing the core problems). You're probably best off using `checkinstall` or similar, and adding dependencies by hand.
is RPM that much saner? which RPM based distribution comes with long term support suitable for servers that also includes btrfs? (i used to use centos, but since red hat removed btrfs from the kernel, refusing to support it, i had to switch to debian, because i depend on btrfs support)
But yes, RPM itself is better than Deb if only because there's a single .spec file rather than a sea of embedded nonsense. It's still not as nice as many "port" packaging systems (e.g. the BSDs, but also Gentoo), but most of those cheat by not having to deal with arbitrary binary packages. Still, binary packages are hardly an excuse for the ludicrous contortions the standard deb-building tools choose to require.
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?
Earlier quoted context omitted.
Ah, ok, I didn't think of systemd version changes. Thanks. Regarding your rhetorical question about "the same NIC", I think the problem is in determining whether the NIC is the same, and it is not an easy one to solve. I remember that older Suse Linux versions used to pin the interface name to the NIC's MAC address in an udev rule file that got autogenerated when a NIC with a given MAC first appeared on the system, b…
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…
Earlier 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…
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…
With swap enabled, it is very, very, VERY common for the system to become completely unresponsive - no magic-sysrq, no ctrl-alt-f2 to login as root, no ssh'ing in ...
You also have some misunderstandings a bout overcommit. If you aren't checking `malloc` failure you have UB, but hopefully you will just crash (killing processes is a good thing when the system fundamentally can't fulfill everything you're asking of it!), and there's a pretty good chance the process that gets killed is blameworthy. The real problems are large processes that call `fork` instead of `vfork` (which is admittedly hard to use) or `posix_spawn` (which is admittedly limited and full of bugs), and processes that try to be "clever" and cache things in RAM (for which there's admittedly no good kernel interface).
===
"Swap isn't even that slow for SSDs" is part of the problem. All developers should be required to use an HDD with full-disk encryption, so that they stop papering over their performance bugs.