Given the recent gripe that Bun/Anthropic indicated regarding compile times with Zig (i.e. that their vibe-coded 4x compilation speedup PR wasn't accepted), it appears to me as an "interesting" move to switch to a language that probably delivers 4x longer compilations than even vanilla Zig.
I am very sceptical zig actually compiles faster than rust.
I had similar code written in zig and c++ and cold compilation was many times faster in c++ and incremental compilation was instant in c++.
I think the reason most rust projects compile slow is because of excessive usage of dependencies and also the excessive use of metaprogramming in code.
Zig doesn’t have multiple compilation units so it doesn’t parallelize compilation
This is honestly the first thing I look for with anything new claiming "CAD".
Roughly every other week there is a new "The (programmable) CAD that fixes everything!" post on the front page, just for me to open them up excitedly and noticing that they use a mesh kernel and will thus never be able to provide fillets and chamfers painlessly (for the user). All while they are absolutely essential for a lot of designs, especially in 3D-printing, a well-placed fillet/chamfer can make the difference between an object that breaks upon looking at it funny and one that can bear significant load.
Yeah, it's a tough row to hoe --- I've been handling it quite differently in my own project, taking "Design for Manufacturing" to the ultimate conclusion and requiring that the part be designed by actually applying tooling:
Needs a full-on re-write to make the G-code export (and import) work well, but lately I've been focused on exporting to DXFs w/ colour/layer tagging which was just added as an import feature in the CAD tool my side-gig employer does.
G2 fillets are the next frontier. Even Fusion doesn't seem to handle them well. I mean they can be created without much drama, but geometry derived from them is very likely to fail with no real reason.
Just tried it out with GrapheneOS on my Pixel 7 and the eBay app works fine.
Generally I think the marketing of GraphenOS is interesting. They are usually positioned as the "Absolute security. No compromises." ROM, but in my personal experience, they are the "It must work. No compromises. Then make the rest as safe as possible"-option, given aspects like using the "real" Google Play Services (if desired), but sandboxed, instead of MicroG or unrestricted Google Play, which pretty much all other ROMs roll with.
I mean, GrapheneOS hits at least 2/3 of your demands pretty well.
The Play services are "regular" apps with permissions that you can take away.
For contacts and files you get "scopes", i.e. you decide what the app can see, while the app is left to believe that it can see everything there is.
That said, I think the marketing of GrapheneOS could be better. Every introduction of GrapheneOS I've seen paints the image of Graphene being "Absolute security, no compromises", whereas in reality GrapheneOS is the most "Things need to work, no compromises. Then make the rest as safe as possible" custom ROM that I've used thus far (in particular regarding them allowing you to install Google Play, rather than using MicroG).
I would certainly be using GrapheneOS if only I could get one to run on something else than a Pixel.
I have a perfectly good phone whose bootloader can be unlocked and I can install LineageOS or other AOSP installations there but all I'm aware of and I've researched come short on the sandboxing and permissions. I'd be willing to use GrapheneOS without support for specific security hardware (if only they supported that configuration) just for the features mentioned but Pixel phones are just too expensive. I've always been more than happy with a decent low-tier phone and I don't see a technical reason to change that. Nothing wrong with my phone.
> I would certainly be using GrapheneOS if only I could get one to run on something else than a Pixel.
But the whole idea of GrapheneOS is the reason why it (currently) only runs on Pixels. On other phones you can run anything based on LineageOS...
I don't want GrapheneOS to compromise on that: if I didn't care about it, I would use any other alternative. To me it's a bit like saying "I would be using Linux if it was a lot more like Windows" (that's something I often understand when Windows users explain what it would take for them to use Linux). But I, as a Linux user, really don't want Linux to look a lot more like Windows.
Pixel A's are quite affordable. GrapheneOS is open source so if there was a need, people could get it to run on insecure devices that aren't Pixels. Expecting that to be done by GrapheneOS developers who care about security just seems weird.
Doesn't help with the current situation though but I hope the partnering between Motorola and GrapheneOS is still up and going in a few years when I'll next have to replace my phone.
I'm personally happy with LineageOS on OnePlus stuff, but have you considered getting a Pixel that's 2 gens or so old from eBay? I find old flagships drop in price pretty quick and are often a better deal than a new low-end phone.
Mock Location exists but our Location Scopes feature will largely replace it for non-development use. Camera, Microphone and other scopes features will be provided too. We haven't fully fleshed out what the ones for other permission groups such as Phone will look like yet but it's planned.
There is the option to register the signing key of the ROM with the bootloader and then relocking it, thereby making those apps happy again.
The biggest issue is that there is a different way to do this for every device, so most custom ROMs don't bother. It's relatively simple and automatable for Pixel devices, so the GrapheneOS installer takes care of it. e/OS/, which is based on Lineage, allows this for some devices, iirc.
There is no legislation here. CUII is a private organization that generates lists of domains that contain copyright violations. ISPs voluntarily choose to block those.
Besides being a great project, this device reminds me a lot of the Technifant (https://technifant.de) which, under the hood, is similarly simple. The "hats" that you put on the Technifant contain a cheap USB thumb drive with the contacts soldered to a magnetic connector. All the audio is stored locally on the hat itself, and you can even add your own MP3 files with a cable provided by the manufacturer.
For me personally at least a few aspects about this are efficiency and control:
The number of CPU cycles my current android phone burns through just to boot and get ready to accept my "first useful input" is probably in the same order of magnitude as or higher than my old N900 would use for the entire day (600MHz single core vs. 8 cores at several GHz). Yet somehow the N900 could easily run quite a lot of things in parallel and would still react quickly to inputs, while I decided to get rid of my previous (still several times more powerful) phone because it would regularly hang for 10 more seconds without any good reason (also there were no more OS updates).
Also with the N900, I had control over every aspect of the system, I could easily script things in python without installing a huge app for it, which the OS would decide to randomly kill to save battery, etc.. Closest thing you can do on Android is root your phone and now every second app complains what a horrible person you are for wanting a bit more control over your own hardware.
That being said, I too eventually buckled to the fact that all the software you need to make a smartphone useful/entertaining is pretty much only available for Android and iOS. And the most realistic way to get "Android-compatibility" to a Linux phone is to just ship an entire Android build with it, due to how interwoven things are on Android.
Fully agreed as a former N900 and now Fairphone+LineageOS user.
Some more things to add: On the N900 updates were quick, easy and painless to a degree that no current phone OS matches: You just to "apt update && apt upgrade", reboot will only happen when really necessary, otherwise any small component (which are just .deb packages as in Debian or Ubuntu) will just be upgraded and restarted in place, without a big download, interruption and reboot. And most importantly, without waiting for a slow vendor to collect and package up all the tiny updates into a big 1GB package that can then be delivered weeks late...
Also, Backups. The only backup solution for a non-rooted phone nowadays is "use our cloud, trust us", and even then backups are always incomplete, because an increasing number of apps set the "no-backup" flags and do (or not do) their own thing, selling you yet one more cloud subscription just to get your own data into "safety". And even with a rooted LineageOS, backups are still a huge pain and incomplete. On the N900, you could just run any old normal Linux backup software, and be done. Imagine, your phone just sending its stuff to your company tape library, no hassle!
And (didn't try this, but should have worked): remote management. SSH into your users' phones to do stuff. Run ansible/puppet/..., manage them like any old Linux box. No tedious mobile device crap management that doesn't really do most of the useful shit, only works on half the hardware and in the end is just yet another cloud lock in by some vendor.
I have a OnePlus 6 becoming "free" soon and I will definitely give PostmarketOS a shot (I had a glance at their compatibility list and noticed the OP6 is on there). Thanks for bringing this to my attention!
reply