Trying to read more theory
I love technology, FOSS, learning languages, history, and philosophy
I agree but in terms of the features, momentum, and community around rust I think it’s the most promising option for memory safe language. But you’re right that it’s not the only option, I should say that they should be more welcoming to mixed language development with memory safe languages in general
Hey one thing I noticed in your safe mobile operating systems section is that you recommend divestOS as an alternative to graphene. I have made the same recommendation for years, but if you aren’t aware that project actually shut down in December so it’s just gone now. A good recommendation that is still maintained is CalyxOS, which also supports bootloader locking after install (at least on pixels, they have caveats for fairphone devices). I haven’t had a chance to read all of your guide yet though, but other than this I’ve enjoyed the parts I’ve gotten to. Thanks for making it!
Rust is the future for this sort of systems programming work, and by failing to see that and accommodate its use both Linus and Hellwig are sabotaging the long term viability of the kernel imo. New devs are keen to jump on rust because of how much it does better than C/++ and how much easier it is to make safe and secure systems with it, but shit like this just demotivates that crowd and thins the pool of people who are willing to contribute going forward. We need memory safety by default, the task of kernel stability is only going to get more complex and unsustainable without it. Stop holding onto tradition and purity for the sake of it
This is not true. You may be thinking of the Secure Enclave, which Apple processors have had for a while and acts as a dedicated piece of silicon to protect encryption keys. But pixels have this too, idk about phones with Qualcomm or exynos SOCs but they likely have something similar. Either way it has no impact on battery life and all major smartphones have been capable of encryption for many years
Yes it’s proprietary idk why I phrased it like that. I should’ve said I fall back to proprietary services like iMessage, then if that’s not possible I go to unencrypted proprietary services like discord etc. My b
I keep my options open. I default to signal or matrix if that’s available, then my fall back is iMessage which I run on a macOS vm, and finally id relent to proprietary services like discord, groupme, etc. I minimize my communications on unencrypted and non-private channels, and only talk about benign things there if I have to use them. But I don’t let my commitment to privacy completely isolate me, I know my threat model and change behaviors depending on the environment.
My banking and money transfer apps all work under grapheneos in a user account with Google play services installed. I mostly manage these things on my computer though to minimize tracking and remove the need for safetycheck compatibility before it ever comes up.
I never use these services but pretty sure they also work on Graphene with sandboxed Google play services installed
Other users have posted programs to convert these coordinates on the fly, I have never needed those personally. When I need GPS I usually go for Organic Maps but thinking of switching to OSMAnd+ soon
Yes and this is an area where I need to improve my privacy more. I just use the garmin connect app with a garmin fitness tracker I got for cheap. I think it partially supports gadgetbridge so I might look into that but haven’t had the time to investigate.
Pixel+Graphene is really the gold standard for privacy, security, and compatibility. I’ve heard ok stuff about CalyxOS so that’s worth checking out. Also FairPhone devices tend to have good support for custom ROMs like Calyx and /e/os which are degoogled, but I don’t have personal experience with those so definitely research those topics before making any decisions
Audile should do the trick
I agree. I think Hector Martin should not have endorsed that sort of behavior to whatever extent he did. But I also think long term that the sorts of behavior that’s keeping these rust patches out of the code base will kill the future of the project. The reasons given aren’t even applicable since the patches are in their own branch of the tree. But I agree brigading is not the way to address these sorts of organizational issues