Someone will have to take over Linus' role. There's no way that kernel development can work without a person in charge, at least not in anyway that is remotely similar to today.
FreeBSD? But there is nothing fundamentally different in open-source project management between a kernel and any other large open-source project. The linux code base is the largest, but not by a large margin. Chrome, GCC, OpenOffice, Android (excluding the linux part obvs.), and the various BSDs are all comparable in scope, complexity, lines of code, and number of contributors. Only linux is (in)famous for having a toxic and unproductive culture.
I assume we're only comparing to operating systems, as I would say that e.g. Chrome as an open-source project is just as impactful if not more so. But generally speaking the Linux support experience is decidedly worse than *BSD or any proprietary OS. It is much harder to get patches upstreamed, and many hardware have errata that never get fixed. (If you haven't experienced this, it might be because companies like canonical and red hat maintain their own patches to support their customers.)
Worse they require frequent logins on device to keep the with client working. Just making the account on device isn't enough. You have to maintain it as well.
Sometimes there's no choice. If it's between beans and rice or nothing at all, then it's going to be beans and rice. Soup kitchens, school lunches, etc are a great help too.
Not the parent and I will continue to use F-Droid but Obtanium is a popular alternative. It allows you to install apks directly from various supported sources (forges, F-Droid repos etc) so you typically use the apk that the app maintainer has produced in their CI pipeline rather than F-Droid's reproducible builds.
F-Droid would likely get APKs from the same place (if reproducible builds are on for the app in question). If this attack is implemented successfully, then that place was compromised as well, and Obtainium can’t do much here to detect that I’m afraid.
Edit: on second thought, they could pin certificate hashes like F-Droid does on the build server, but verify them client-side instead. If implemented correctly this could indeed work. However, I think F-Droid with reproducible builds is still a safer bet, as attacker would have to get write access to source repo as well and hide their malicious code so that F-Droid can build and verify it.
Okay, but sideloading is worse? AFAICT the problem we're discussing was in F-Droid doing extra verification (somewhat incorrectly, apparently) of an APK before handing it to Android to install. Regardless of F-Droid, Android will check signatures on updates against the installed version. So your response to F-Droid imperfectly checking signatures as an extra verification on first install... is to skip that entirely and do zero verification on first install? That's strictly worse for your security.
Sideloading sounds like a massively worse option than using F-Droid even with this flaw. Humans are way more likely in making mistakes, and you lose a lot of safeguards in between you and the APK when you sideload. Also, you don’t get updates as fast, which is a whole problem in itself.
So, IMO we should not fall into that trap of immediately removing apps that had a security flaw and falling back to a way worse alternative (which sideloading is) instead.
