This is a fork of the evaluator/language implementation/daemon/builder/whatever you want to call it. The other one (Auxolotl) is a fork of Nixpkgs, the repository of build scripts and all the NixOS misc pieces.

Or put into other terms, this is a fork of APT/RPM as well as their associated builder tools, while Aux is a fork of Debian/Fedora/whatever. The Nix evaluator is a much more complex piece of software than most other package managers so it does benefit from having a dedicated team working on it.

I think they'll give it a genuine shot. These stalking services pop up like weeds and every time it gets some media attention they end up with significant problems not much later. dis.cool was the last well-known entry but there's been more.

These things are always easy to say in hindsight, but I do believe that a closer review of the build system shenanigans used to install the backdoor would have at least raised some questions.

Nobody noticed it because nobody is reviewing autotools spaghetti and especially not autotools spaghetti that only exists as shipped in a tarball. Minor differences in those files are perfectly normal as the contents of them are copied in from the shared autoconf-archive project, but every distro ships a different version of that, so what any given thing looks like will depend on the maintainer's computer. And nearly nobody has a good understanding of what any given line in a .m4 file is going to ultimately lead to the execution of regardless, so why bother investigating any differences? The maintainer of Meson has a good take on this.

Shipping tarballs without any form of generated files and having a process to validate release tarballs against the repo would be a good step, but is much easier said than done for a variety of reasons. Same thing can be said for shipping without any form of binary files in the repo, there's quite high value in integration tests and xz's README for the test blobs has correctly included this paragraph for 16 years:

Many of the files have been created by hand with a hex editor, thus there is no better "source code" than the files themselves.

This is a shot in the dark, but since the permissions look fine to me, the only other thing that comes to mind is that the SELinux contexts might not have been copied. Fedora is one of the few distros that enables SELinux in enforcing mode right out of the box. That can be very complex to understand if it breaks.

There is a Fedora documentation page about SELinux. The /var/log/audit/audit.log log file should be full of errors relating to your /home if it broke. I believe that stat /home and stat /new_home should display the SELinux context if SELinux is active, and they should be identical.

Also possible I'm totally off the mark, though, it's just a possibility.

It's difficult because you have a 50/50 of having a manager that doesn't respect mistakes and will immediately get you fired for it (to the best of their abilities), versus one that considers such a mistake to be very expensive training.

I simply can't blame people for self-defense. I interned at a 'non-profit' where there had apparently been a revolving door of employees being fired for making entirely reasonable mistakes and looking back at it a dozen years later, it's no surprise that nobody was getting anything done in that environment.

Technically always has, ROCm comes with a "backported" amdgpu module and that's the one they supposedly test/officially validate with. It mostly exists for the ancient kernels shipped with old long-time support distros.

Of course, ROCM being ROCM, nobody is running an officially supported configuration anyway and the thing is never going to work to an suitably acceptable level. This won't change that, since it's still built on top of it.

DMA-BUF being marked as "unstable" for a decade was a fucking joke. It's a protocol that's required to get any kind of meaningful hardware accel going, which nearly every app does nowadays. Within Wayland circles, it's been understood it's not going to change for years, as doing so would break nearly every single existing app, yet all kinds of bikeshedding prevented it from being moved to stable.

Hopefully this marks a turning point for many other similarly important protocols stuck in unstable/staging hell too, like pointer constraints and text input. If devs can't rely on basic functionality to be present and it takes more than say three years to commit to it, it's time to admit that either the process or the protocol is broken.

Everything was forked and should eventually end up on F-Droid, but most things haven't had a release yet. My understanding is that they're hoping to do everything right immediately, including having proper new branding and all the shared functionality from Simple Thank You.

The F-Droid versions of SMT apps are perfectly safe and shouldn't be going anywhere. (But if you have Google Play versions, I wouldn't trust those anymore, those are owned by ZipoApps now.)

Memes used to be funny

"Open source" has more or less always meant something very specific as defined by the Open Source Definition. Adding restrictions on top like no commercial use or no lawsuits turns it into "source available".

OpenSSH's server login component (the authorized_keys checking) can't properly respect XDG_CONFIG_HOME because it won't be set at the time it's reading the authorized_keys file. The user's home directory is stored in /etc/passwd but the XDG variables have a million different ways to set them, none of which are truly standardized. Best you could really do is hardcoding .config or the like, which you can do by changing the AuthorizedKeysFile in sshd_config.

I can't speak for Apple but Google does. It falls under their user-generated content policy which requires you to "Provides an in-app system for blocking UGC and users". Google is generally the more lenient of the two when it comes to policies, so I'd be highly surprised if Apple didn't have it...