King_of_Ooo
Proudly anti-facist, fuck bigotry everywhere!
IT Security and Privacy advocate.
Lover of Linux and all things FOSS.
If you need Linux help or advice find privacy respecting software, message me.
Check out https://privacyguides.org
Posts
Proudly anti-facist, fuck bigotry everywhere! IT Security and Privacy advocate. Lover of Linux and all things FOSS. If you need Linux help or advice find privacy respecting software, message me. Check out https://privacyguides.org
Proudly anti-facist, fuck bigotry everywhere! IT Security and Privacy advocate. Lover of Linux and all things FOSS. If you need Linux help or advice find privacy respecting software, message me. Check out https://privacyguides.org
Uutils is cool, but is intentionally striving for feature parity with gnutils. This means the same feature scope as gnutils which is rather large. Rust code is a definite advantage though.
Proudly anti-facist, fuck bigotry everywhere! IT Security and Privacy advocate. Lover of Linux and all things FOSS. If you need Linux help or advice find privacy respecting software, message me. Check out https://privacyguides.org
Proudly anti-facist, fuck bigotry everywhere! IT Security and Privacy advocate. Lover of Linux and all things FOSS. If you need Linux help or advice find privacy respecting software, message me. Check out https://privacyguides.org
1. What security features? I understand these init and service managers lack service sandboxing, but that is what sydbox can provide. systemd is do massive that it isnt reasonable for a small team to audit it (alongside all the other OS components) when considering whether to depend on it for critical systems. Lacking features are better than architectural problems because it is easier to refactor and extend a small projects than do the same for a massive project. Every project starts somewhere, why choose a project based on what it provides now (eg systemd) instead of what we can make another do tomorrow?
2. These may not be hardened memory allocs when compared to GOS' hardened_malloc, but they are definite imptovements over the default memory allocs of most Linux distros. I only mentioned mimalloc because hardened_malloc does not support other archs than amd64 or arm64, which could be useful to someone. Do you know of other hardened memory allocators? I heard of ISO Alloc but idk if is actively developed.
3. This doesn't really answer my question. If you look at my original comment I don't even think that GNOME, systemd, or GCC should be even considered for a developing a secure desktop OS. These projects have decades of technical baggage and would be near impossible to repurpose. My question was what happens if Google kills AOSP, separate from any consideration about trying to use Linux as a base.
None of the projects I mentioned are in a place to be used for a secure OS. None of them use any of the Linux sandboxing or security features in their code to limit access or enforce least privilege. Simpler projects is much easier to extend than trying to detangle and debloat the likes of GNOME, systemd, or GCC. If these projects die there are hundreds to replace them. None take security that seriously, which is an architectural problem with basically all Linux software, but a rival for Android isn't going to just pop out and surprise us without a decade of development. My question also "Is it even possible without a multibillion dollar company to develop a secure OS on par with an Android OS?"
So my question again: what do we do if Google kills AOSP. They aren't right now, they might not ever, but they are malicious and for profit. They will make (more) bad choices that harm the health of their admittedly useful/important projects.