This is unfortunate but not exactly surprising, I’ve quite liked bcachefs for its features but I swear every release has been accompanied by issues with Kent expecting exceptions to standard procedure be made for bcachefs. When you manage an open source project as big as Linux that’s just not sustainable, and it’s frustrating to see Kent not recognise why the onus is on him to make the necessary accommodations.

I just want a diversity of architecture styles to be common, I love areas that are an eclectic mix of styles; it makes me feel like so many different people care about the area.

C because it’s what is used for low-end linux & embedded work.

Shell scripts because they’re the caulk that holds a Linux distro together.

Rust when possible because it’s how I wish systems programming could be.

Seems like the more important take is that 68.5% do not want (or at least does not prefer) the most popular candidate, that’s a level of fractured that should be prompting some introspection from the party.

I was a “ironically” racist as a young teen, it took me till my early adulthood to realise that being ironically racist is just being racist, and the edgy “humour” that is made at others expense isn’t funny or clever, and is incompatible with the kind, empathetic person I wanted to be.

Cringing at my teen self pushes me further into deprogramming myself from that shit, but I’m encouraged by the adage “if you don’t look at yourself from a decade ago and cringe, you wasted that decade”.

I wish.

It was a bcachefs array with data replicas being a mix of 1,2 & 4 depending on what was most important, but thankfully I had the foresight to set metadata to be mirrored for all 4 drives.

I didn’t get the good fortune of only having to do a resilver, but all I really had to do was fsck to remove references to non-existent nodes until the system would mount read-only, then back it up and rebuild it.

NixOS did save my bacon re: being able to get back to work on the same system by morning.

A few months ago I accidentally dd’d ~3GiB to the beginning of one of the drives in a 4 drive array… That was fun to rebuild.

Kernel modules don’t have to be open source provided they follow certain rules like not using gpl only symbols. This is the same reason you can use an NVIDIA driver.

Its not enforced so much by law as what the fsf and Linux foundation can prove and are willing to pursue; going after a company that size is expensive, especially when they’re a Linux foundation partner. A lot of major Linux foundation partners are actively breaking the GPL.

Both Intel and AMD invest a lot into open source drivers, firmware and userspace applications, but also due to the nature of X86_64’s UEFI, a lot of the proprietary crap is loaded in ROM on the motherboard, and as microcode.

I work with SoC suppliers, including Qualcomm and can confirm; you need to sign an NDA to get a highly patched old orphaned kernel, often with drivers that are provided only as precompiled binaries, preventing you updating the kernel yourself.

If you want that source code, you need to also pay a lot of money yearly to be a Qualcomm partner and even then you still might not have access to the sources for all the binaries you use. Even when you do get the sources, don’t expect them to be updated for new kernel compatibility; you’ve gotta do that yourself.

Many other manufacturers do this as well, but few are as bad. The environment is getting better, but it seems to be a feature that many large manufacturers feel they can live without.

Based on your fans it’s more likely too much air + high initial temperature causing uneven cooling. I assume with those fans you’re trying to print really fast?

Given the user always has a deeper access to the client (i.e. hardware access) than the anticheat dev does, eliminating cheating is probably unsolvable.

Best bet is probably always going to be a decently funded team dedicated to find and ban cheaters, rather than attempting to prevent them all with a rootkit.