Ooh, I've never heard of bcachefs, sounds exciting! I see it supports encryption natively, which btrfs doesn't. Pretty cool!

Personally I've never had any issues with btrfs, but I did start using it only a couple years ago, when it was already stable. Makes sense that you'd stick with zfs tho, if that's what you're used to.

I find myself inventing new curses for those who screwed things up with these overblown, over complex, minimally functional abominations

Gosh, tell me about it. I once tried writing a custom wifi signal strength indicator app that got its information from network-manager. Apparently the only way to programmatically communicate with network-manager is through dbus, which is just terrible. Scarce to no documentation, poor support for any language other than C/C++, and once you do get it working, it's the most disgusting and overly verbose code you've ever seen, just to query the status of the wifi card. Could've exposed the API through raw unix sockets or something, but nope, they had to reinvent the wheel on that one as well.

Just give me vi and the basic configuration files and let me get on with it!

I'll take this opportunity to shill for Void Linux, it sounds like exactly what you're describing. I've been a happy user for like 5 years now. I particularly like how nothing ever breaks, because there's not much to break on such a minimal system.

...well, actually, a few things did break over the years, but most of those were due to user error haha.

I can think of a single instance where a Redhat-ism is better

I don't know if it would be accurate to call it a redhat-ism, but btrfs is pretty amazing. Transparent compression? Copy-on-write? Yes please! I've been using it for so long now that it's spoiled me lol. Whenever I'm on an ext4 system I have to keep reminding myself that copying a huge file or directory will... you know... actually copy it instead of just making reflinks

I'd do away with network-manager on a stationary system too, but I'm on a laptop, and unless there's some trick I don't know about, configuring wifi by hand for every new network I come across sounds like a bit of a pain. Especially for corporate/institution network that use fancy things like PEAP

idk man ipv4 NAT sounds like the "complicated bloat" to me.

Thanks, will take a look when I have time

No, it's an edit. I linked the original in the post text. If you can't access it for some reason, here's a transcript:

Government of the Netherlands

Home > Topics > Coronavirus COVID-19 > Travelling to the Netherlands from abroad

Checklist for travel to the Netherlands

Do not travel to the Netherlands.

Agreed. Though I wonder if ipv6 will ever displace ipv4 in things like virtual networks (docker, vpn, etc.) where there's no need for a bigger address space

So switching to a slower wifi AP causes packets destined for outside of your network to not be dropped? That sounds like one of those cursed issues that's a complete nightmare to track down lol. Maybe the faster speed of the 5.8ghz network is causing your router to get overwhelmed or something? Does the same issue happen if you connect via ethernet? I don't really know what else can cause this, I hope you can get it fixed!

Flatpak is awesome, I love it so much. It lets users pick a distro based on the unique features that distro provides, without having to worry about whether their favourite apps are packaged. Since you're considering switching to debian+flatpak, here is a list of pitfalls I've run into in flatpak so far, maybe this can save you some troubleshooting:

• You need to have a thing called an "xdg dekstop portal" installed. Otherwise filepickers will be broken. On Debian this should be a dependency of flatpak, so it should be installed by default tho.
• If you're manually restarting Xorg without using a display manager, make sure the xdg desktop portal process doesn't get started twice. Otherwise it will be broken
• As far as I understand, there's no way to use xdg desktop portal to forward an entire directory through to a flatpak'd app, unless the app itself asks specifically for a directory. So stuff like opening a .html file that references a .css file in the same directory with a flatpak'd browser will be broken, unless you manually make an exception using Flatseal or flatpak override.
• Make sure your root filesystem is mounted with "shared" propagation, otherwise umount commands won't propagate into flatpak's sandbox, and drives will get stuck in a weird state where they're mounted in some namespaces, but not others. This should be the default in Debian tho.
• If flatpak'd Firefox has ugly bitmap fonts, follow this workaround

Anyway, this is just my experience running Flatapk in Void, hopefully it works smoother for you on Debian.