Badabinski

For me, it’s Arch for desktop usage. When I first started using Arch it would not have been Arch, but now it’s Arch. The package manager has great ergonomics (not great discoverability, but great ergonomics), it’s always up to date, I can get a system from USB to sway in ~20 minutes (probably be faster if I used the installer), it’s fast because it doesn’t enable many things by default, and it’s honestly been the most reliable distro I’ve ever used. I used to use OpenSUSE ~10 years ago, and that broke more in one year than Arch has in ten.

I personally feel like Arch’s unreliable nature has been overstated. Arch will give you the rope to hang yourself if you ask for it, but if you just read the emails (or use a helper that displays breaking changes when updating like paru) and merge your pacnews then you’ll likely have a rock solid system.

Again, this is all just my opinion. It’s easy for me to overlook or forget all of the pain and suffering I likely went through when learning how to Arch. I won’t recommend it to you, but I’ll happily say how much I’ve come to enjoy using it.

Yeah, this is source-available, not open source. You have no rights whatsoever.

The tiered storage stuff is pretty cool. You can say “I want this data on this disk, so if I get a cache miss from a faster disk/RAM it’ll come from this other disk first.”

I believe it also has some interesting ways of handling redundancy like erasure coding, and I thiiiink it does some kind of byte-level deduplication? I don’t know if that’s implemented or is even still planned, but I remember being quite excited for it. It was supposed to be dedupe without all of the hideous drawbacks that things like ZFS dedupe have.

EDIT: deduplication is absolutely not a thing yet. I don’t know if it’s still on the roadmap.

EDIT: Erasure coding is deffo implemented, however.

What if you need to file a bug? What if you have a question on the config that’s not easily answered by the docs? If you never, ever find bugs and never, ever have questions, then sure, separate the two. There are genuinely people like that, but they’re not common. If you’re one of them, then I’m genuinely glad for you.

My opinion is this: You use software. You don’t use people, but you sure as hell rely on them.

Because Vaxry (the lead dev) got banned from contributing to wlroots or any other FDO projects.

As for why he was banned, this is the only thing I’ve read about the whole thing: https://drewdevault.com/2024/04/09/2024-04-09-FDO-conduct-enforcement.html

Basically, he violated the FDO Code of Conduct when being told that a particular thing he said/enabled in a Discord community would not be acceptable if it was seen in spaces covered by said CoC.

This appears to be his response.

Were you using the kernel module? We’re using Flatcar which doesn’t support their .ko, and we haven’t been getting panics on any of our machines (of which there are many).

Falcon uses eBPF on Linux nowadays. It’s still an irritating piece of software, but it no make your boxen fail to boot.

edit: well, this is a bad take. I should avoid commenting on shit when I’m sleep deprived and filled with meeting dread.

The other person may have responded with a fair amount of hostility, but they’re absolutely correct. I run Kubernetes clusters hosting millions of containers across hundreds of thousands of VMs at my job, and OOMKills are just a fact of life. Apps will leak memory, and you’re powerless to fix it unless you’re willing to debug the app and fix the leak. It’s better for the container to run out of memory and trigger a cgroup-scoped OOM kill. A system-wide OOM kill will murder the things you love, shit in your hat, and lick your face like David Tennant licked Krysten Ritter.

Ahhh, I’d love it if I could tie that in with a Bluetooth OBD dongle and Home Assistant. It’d be awesome if I could set up a BLE proxy in my carport to automatically update stuff. It’d be especially handy if I could get alerted about check engine codes.