Or go old-school with multiple users and chroots? You could even install from (and host) a trusted repository, where the source and binaries are vetted (and you can pay people to do this for you).
One could ask why AOSP was created when there was an existing userland on linux that could be used (and was, by Nokia).
More seriously, I think the reason people want to do this is threefold:
1. Android vendors almost universally seem to make it hard to run stock AOSP (and do the Windows bloatware thing that Windows vendors were known for), so a "linux phone" lets people run what they want and remove what they do not
2. AOSP, while open source, is not developed in any way like a community open source project, so their ability to change anything, especially anything Google does not want to change, is limited and means constant rebasing
3. AOSP doesn't really solve the "run a modern/non-buggy kernel" issue on existing vendor hardware (as far as I know), so if you're going to spend time on getting the kernel to work, you probably want to have a userland that is amenable for getting the kernel working, so AOSP isn't helpful there, and by the time you've done all this, you can probably just run the rest of the standard setup with a distro and tooling you are already familiar with
I think the interesting thing would be if the modern kernel work from (3) could be used by an AOSP build and get the best of both worlds, or if by the time you do all this AOSP is too resource intensive to run on the device, and so running the alternative is the only option.
I'm not sure show Fedora is derived from Debian...
If I recall correctly, the backdoor was set up to only activate on rpm and deb based systems, so it wouldn't have been trigged on Arch, Gentoo or NixOS, even if they linked systemd to ssh.
unzip 6.0 is from 2009 (see the manpage or https://infozip.sourceforge.net/UnZip.html). I suspect there are patches floating around (so YMMV as to which patches are applied), or someone has aliases/symlinked some other implementation as "unzip" (like Apple has done here, though unlike unzip rsync is maintained).
Try using atool (which wraps the various options for different archives and should hopefully fix your problem) or the tools provided by https://libzip.org/documentation/.
Practically, what you're hitting is the problem when upstream is dead, and there is no coordination between different distros to centrally take over maintenance.
But why do you care that the set is empty (in the abstract, obviously if there was a reason you'd expect the set to be non-empty, that's a different thing)?
The trick is to think about invariants and state, which if you frame it that way, the empty set case implies there is only a single state.
Big systems have big surfaces, no matter what quality they are.
Dependency chains may be more of an issue. I think several of the last few big exploits have been compromises in fairly small packages, that were incorporated into larger ones.
Then, there's the "Bro Coefficient." Who wrote the package should count for a lot.
I'd trust a package written by "linus.torvalds," a lot more than one written by "L33tCoder420LOL," even if the Web site is super-sexy, and it has a gazillion GH stars.
It's good they know they need to be cautious about it (a year seems a bit optimistic though), but "haven’t had many issues" kinda sounds concerning if it means I cannot boot (or given sudo-rs lacks sudoedit currently, locking me out the system)...
reply