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

121–130 of 211 posts

Re: What to expect from Debian/Trixie

#121

Post by imoverclocked »

hsbauauvhabzb wrote: post #101
tharos47 wrote: post #27

Earlier quoted context omitted.

It was done in Ubuntu a few versions ago. Afaik only the listening port config is ignored and instead is setup in systemd

Which is exactly the problem. It’s not obvious, is misleading and it’s cause is not easily determined just by looking at the config. What else is lurking that you and I aren’t aware of?

> What else is lurking that you and I aren’t aware of?

All of systemd... and network manager/modem manager/...

I grew up with static configuration files, init scripts, inetd, etc... then grew into Solaris smf, dtrace, zones ... and then Linux implemented systemd. I really miss smf and related tools but systemd is still just meh to me. The implementation feels like a somewhat half-in-each-world brainchild.

Re: What to expect from Debian/Trixie

#122

Post by em-bee »

homebrewer wrote: post #104
em-bee wrote: post #94

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…

thank you for that answer. yes oracle is well hmm :-o

alpine feels a bit to opinionated for my taste. i just found this though: https://mrgecko.org/blog/2024/add-btrfs-support-to-rocky-and... centos has a SIG that provides kernels with btrfs which can be used with alma and rocky. that sounds promising.

Re: What to expect from Debian/Trixie

#123

Post by progmetaldev »

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 is exactly why I use Debian when I install Linux. I want something that will keep chugging along, yet may not have the most cutting edge software. I can take my time with the system, and know that it is solid.

If I need newer software that isn't in their package repository, I understand that I have the ability to compile what I need, or at least make an active decision to modify my system to run what I want. Basically, the possibility of instability is a conscious choice for me, which I do sometimes take.

Re: What to expect from Debian/Trixie

#124

Post by chronid »

sigio wrote: post #113
em-bee wrote: post #86

Earlier quoted context omitted.

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

And i want to use hibernation, as I don't mind putting my disk encryption passphrase once a day as the price of not risking having my laptop with a completely drained battery on Monday morning due to 1% battery drain/h of s2idle in my 64GB RAM configuration.

You can use suspend+hibernate to accomplish that and it works well. Unless the gods of kernel lockdown decide you cannot for your own good (and it doesn't matter if your disk is fully encrypted, you're not worthy anyway) of course. It's their kernel running on your laptop after all.

Re: What to expect from Debian/Trixie

#125

Post by necheffa »

sugarpimpdorsey wrote: post #17
gilbertbw wrote: post #8

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.

This is what LVM/btrfs/ZFS snapshots were invented for.

Windows is using Volume Shadow Copies, which for the purposes of this discussion, you can think of as roughly equivalent.

Re: What to expect from Debian/Trixie

#126

Post by JdeBP »

yjftsjthsd-h wrote: post #98
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…

In all fairness... How would that work? Not even just on Debian; in the general case, I don't see how to avoid that other than full filesystem snapshots or backups of some sort. Even on, say, a NixOS system where rolling back all the software and config (basically, /, /usr, and /etc) to exactly its old config is as easy as rebooting and picking the old generation, databases will still have migrated their on-disk form…

Indeed. Snapshots. And they are a breeze on operating systems where ZFS for everything is available. It's not like the Windows feature of the same name, which I suspect is in part what makes people wary of the idea. That works rather differently. A ZFS snapshot completes in seconds.

Re: What to expect from Debian/Trixie

#127

Post by bigstrat2003 »

o11c wrote: post #58
CamouflagedKiwi wrote: post #11

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…

> Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled)

What the heck are you talking about? Swap is enabled on every Linux system I manage (servers, desktop etc) and it's perfectly stable.

Re: What to expect from Debian/Trixie

#128

Post by progmetaldev »

Aachen wrote: post #79
chromakode wrote: post #14

Earlier quoted context omitted.

For users with SSDs, saving the write wear seems like a desirable default.

I have yet to hear of someone wearing out an SSD on a desktop/laptop system (not server, I'm sure there's heavy applications that can run 24/7 and legitimately get the job done), even considering bugs like the Spotify desktop client writing loads of data uselessly some years ago Making such claims on HN attracts edge cases like nobody's business but let's see

I think you're 100% correct in that this isn't a normal event to occur. I believe it's probably one of those things where someone felt that setting it to memory is just more efficient in the general case, and they happened to be skilled in that part of development, and felt it added value.

Maybe the developer runs a standard desktop version, but also uses it personally as a server for some kind of personal itch or software, on actual desktop hardware? Maybe I'm overthinking it, or the developer that wrote this code has the ability to fix more important issues, but went with this instead. I've tackled optimization before where it wasn't needed at the time, but it happened to be something I was looking into, and I felt my time investment could pay off in cases where resources were being pushed to their limits. I work with a lot of small to mid-sized businesses that can actually gain from seemingly small improvements like this.

Re: What to expect from Debian/Trixie

#129

Post by JdeBP »

b112 wrote: post #85
yehoshuapw wrote: post #72

Earlier quoted context omitted.

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

Debian, at least until bookworm works perfectly without systemd. The easiest way to make this transition, is to installed Debian with nothing but 'standard system utilities' and 'SSH server' (if you want) during install: https://forum.qubes-os.org/uploads/db3820/original/2X/c/c774... Once install is done, login and save this file: /etc/apt/preferences.d/systemd # this is the only systemd package that is required, so…

It's important to remember that it has to be this aggressive in excluding systemd, too. There is quite a lot of strong coupling amongst the parts of systemd, so there are very few half-measure scenarios, where one can have only some systemd stuff, that will actually function correctly in toto.

Moreover, there are the odd one or two unrelated packages that just happen to have the string "systemd" in their names. (-:

Re: What to expect from Debian/Trixie

#130

Post by CoolCold »

o11c wrote: post #110
tsimionescu wrote: post #68

Earlier quoted context omitted.

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…

People keep saying this, yet infinite real-world experience shows that systems perform far better if the OOM Killer actually gets to kill something, which is only possible with swap disabled. In my experience, the OOM killer picks the right target first maybe 70% of the time, and the rest of the time it kills some other large process and allows enough progress for the blameworthy process to either complete or get OOM…

+1 from me for

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

It's usually enough to have couple of times when you need to get into distant DC / wait for some IPMI connected for couple of hours, to learn "let it fail fast and gimme ssh back" on practice vs theory on "you should have swap on"

Post reply on HN