Notch’s Bugatti is far less likely to spontaneously combust (because it was made by professionals, not AI), and if it did, it wouldn’t affect as many people. Omarchy claims to be an easy version of Arch, when in reality, it’s just doing what every beginner would be doing, including all of the accidental security holes, and then adds some more weakpoints through the unchecked shell scripts.

Part of those 8 million do go into paying “the Hyprland guy” (Vaxry)'s salary, and he himself hasn’t been very politically correct. DHH also is quite open about choosing “anti-woke” projects (i.e. without a CoC).

If the parent was waiting on the child, it is notified of the exit status and the child dies immediately. ~ man exit(3)

USB-OTG should just have been named USB Power Bottom. That makes USB-Type-C the embodiment of a switch.

Linus has already chimed in, and wants Zstd to just use the standard way of checking for CPU features instead of rolling their own. Apparently, that would be even faster, compiling to a single jump instruction.

Very likely. Or, at least what the thread commenter meant. There’s other programs vulnerable to …/, but it’s mostly some kind of Application Firewall, one that inspects the message itself.

All hail the third temple OS!

Ahh, I found you, Toby Fox!

Mutter is made by GNOME, what do you expect?

snix (rest in piss)

Nix Lix Guix

Client-side decorations. In most DEs and WMs, the compositor or the shell is responsible for the window border, Close button etc. On GNOME, the client (application) is expected to do all of that. There is a mechanism for a WM to request an app whether to draw CSD, and for the app to request SSD, but they don’t need to be implemented.

Then the deal needs to be changed. Contracts are not above the law 🤷

The nixos-unstable channel actually does ensure a minimum set of required packages work: Those that would prevent you from booting. The compiling-from-source is because Hydra (the binary cache) only starts building once a package appears in nixpkgs-unstable, and if it immediately proceeds into nixos-unstable, or one of its dependencies is different there, that build won’t be finished yet. release- and versioned nixos- don’t have that problem, as they have a merge freeze, and are mostly fast-forwarded along unstable.

What would be good is a mechanism for Hydra to tell you “I tried to build this derivation, and it failed.” For this, Nix first needs to store build failure, and since store paths are input-addressed by default, you can also skip builds that will certainly still fail.

Btrbk if you use the right filesystem.

I have this iFixit guide as my source: https://www.ifixit.com/Guide/Choosing+the+Right+Screwdriver+Bit/93991#s176809 According to that, the JIS screws have orthogonal inner angles, while the Phillips’ are rounded, resulting in the slipping bits. However, some Phillips screwdrivers fill out that space, and thus won’t fully go into a JIS screw, and effectively be too small, stripping it.

JIS is only good for being cheap, and only works if you’re a precision robot. You lose the autocentering and overtorque protection of Phillips, without gaining any of the advantages of Torx. (Phillips has overtorque protection in the sense that your tool doesn’t break, the screw does; which doesn’t matter if you don’t need to unscrew it.)

It should be fine, as long as you’re not using one of these ancient bootloaders.

The volume recovery key for Linux is the LUKS key, yes. You should have that stored somewhere, you can’t view it iirc. The volume key for Windows is the BitLocker Recovery Key. If you’ve signed in with a Microsoft account, it’s stored in the cloud, otherwise you should have that printed out, too.

I know, that was a rhetorical question.