Even if they have GrapheneOS, the lead developer of GrapheneOS publicly admitted struggling with mental health issues. People with mental health issues and severe personality disorders are very easy for nation state actors to manipulate and compromise. GrapheneOS is very strong on the technology specifics, but there's more to safe computing than just the technical part.
GrapheneOS, despite its human problems (as admitted by its project lead), does have at least near perfect if not perfect compatibility with the Google Pixel devices listed as release targets on the GrapheneOS website.
What exactly to do to benefit from the technology benefits of GrapheneOS, but protect the actual users, is still an open question.
Almost a year a go the lead developer of GrapheneOS, Daniel Micay, publicly admitted that he was experiencing mental health issues and announced he would step down from the project. As displayed by Micay's behavior, just in the last few days even, he is still dealing with those issues. Micay will jump to cry he is being "harassed" and melt down when he meets just the slightest amount of resistance in a discussion that hasn't deviated from technology. He will even do this simply due to the format or style one chooses to reply with, irrespective of content.
Today, we can see that Micay deleted off of GitHub his announcement that he stepped down, probably when he thought not a lot of people were looking. As evidenced by the writing style and choice of words on the project's social accounts, Micay is operating those social media accounts. The recent Git commit history shows he's active in the project again.
Micay does do great technical work. However he is very quick to jump to accuse others of "harassment" and "misinformation", dividing development efforts and excluding others from projects in what looks like an attempt to control others and reduce competition in the space.
As Louis Rossman pointed out, Micay bullies other people, some would even call it "harassment", then tries to hide it behind an excuse the he suffers some form of autism.
This quote below, is really fucking dumb. A GNU+Linux distribution should absolutely never ever do this. GNU+Linux is not only not Windows, it should not adopt the very stupid patterns native to the mind of a Windows user. The guy who wrote this article should fuck off back to Windows.
"
You ask me if it is possible to use popular tools like Chrome on Ubuntu. I say yes. Just download it from the official website and install it by double-clicking like you do it with exe files in Windows."
Spectre vulnerabilities are a huge problem. Problems in x86_64 never cease to emerge. Qubes Air is probably the most outstanding viable approach to not exactly mitigate CPU and chipset problems but avoid them or leave them moot.
Remember that this too ships a huge number of privileged binary blobs and kernel modules from companies like Qualcomm and Google in the vendor partition.
Whoever compiles these binary blobs, and the OS images themselves, and anyone capable of coercing them, has god access to your device.
I suggest getting to know someone before giving them that much power over your life.
A user should be able to load a cryptographic key to the bootloader and boot any OS of their choosing. I'm kind of more on the extreme "Free Market" way of thinking, but even I think that government should step in and force an iPhone to be like a Macbook in this way.
Nix is mostly reproducible but does not require maintainers to sign their packages or commits, and most do not, which is a bare minimum for any security sensitive environment.
In Guix signing is mandated and it is mostly reproducible, but the choice of scheme and lack of base container images make it unapproachable for many.
Debian lead the way on signing and reproducibility, but package versions of things like rust are too far behind to be useful to most orgs.
Arch in contrast to these is IMO easy to package for, has recent well maintained signed packages, has well maintained OCI images published, and is rapidly improving on reproducibility.
Having at least one glibc distro that can meet this criteria is a big win for many use cases.
Different tools for different projects and threat models.
With all due respect to Nix/Guix, to me they swim uphill against the current of "worse is better" than UNIX is built upon. They are trying to tame the complexity of the world by making it declarative. A lofty, and a little too idealistic goal.
I much prefer the immutable approach (rpm-ostree) or even an unsophisticated approach like a Dockerfile, which is worse but much closer to the status quo, than to create a perfect world from scratch and hope that everybody follows the Light. Software is too large, complex, hacky, buggy and nuanced to expect it to fit into neat preordained categories. Because unless you do very simple things, you'll soon find yourself out of the happy path and have to resort to doing the hacky way anyway.
This is what some believe killed Lisp machines vs UNIX. I guess, like Lisp, in decades there will a vocal contingent of people lamenting the fact that we all run immutable Microsoft Kubernetes Ubuntu (MSKU) instead of using the more refined NixOS approach.
>> in decades there will a vocal contingent of people lamenting the fact that we all run immutable Microsoft Kubernetes Ubuntu (MSKU) instead of using the more refined NixOS approach.
You are, unfortunately, correct. Some of us still run illumos Unix (SmartOS), but we are a tiny minority. I hope that things can work out so that something other than the lowest common denominator is accessible enough to also have a pervasive footprint.
A lot of very crummy ideas are popular in ways that would not have been imaginable 15 years ago.
>> or even an unsophisticated approach like a Dockerfile
In a handful of "higher end" on the salary side of DevOps/SRE roles I have done, I managed to quietly do things with flake.nix -- next time around I'll do them with Guix. I can get Guix container images going, that's not hard for me.
But yeah, doing things non-Docker isn't too hard for us DevOps ninjas (what DevOps was in 2012, not the watered down thing today).
After doing flake.nix, I managed to get written company policy ratified by our legal team that all container images must be binary reproducible. That probably fell apart since I left, unless the high quality CTO I was serving is still there.
I am not sure if this is a tongue-in-cheek comment that's above my comedic pay grade, but if it is not:
This sounds like a lot of words that would otherwise mean nothing to any Nix/Guix user. It works. It is not "too idealistic goal", Nix repositories already contain more packages than any distribution around.
It is too late to throw the occasional uninspiring "you are too ambitious." Because they have been doing this for years now successfully.
I think the question is about what kind of commitment the functional package management paradigm, especially as implemented by Nix and Guix, requires too much commitment or skill to really 'eat the world'.
That whole operating systems based on this model are workable by enthusiasts, experts, and adventurous hackers is, as you point out, well-proven by NixOS and (perhaps especially, by your reckoning) GuixSD.
Personally, while I think later, 'more pragmatic' takes on functional package management (e.g., Spack) get some things right for the first time in the space, I'm optimistic about how far projects like NixOS and Guix can go even without relaxing any 'purity' constraints. NixOS is blowing up with Linux hobbyists right now because there's already so much it can do without experienced administrator. The Guix package collection is growing incredibly quickly given its relative youth and smaller contributor base— I'd be shocked if it didn't outgrow some of the most popular Linux distros in the next few years.
Like you say, these projects aren't just proofs of concept in a lab or paper somewhere. They have users and contributors right here in the real world, already, and they're growing and improving all the time.
