I think that’s a very idealistic view of FOSS that is detached from reality. In the late 90s and early 00s we were fighting the crypto wars, making DeCSS illegal, DMCA, EUCD. There was a lot of infighting between free software and open source proponents. Many FSF campaigns were very political. I got bashed by some other FOSS people I knew in ~2006 for using and contributing to CentOS because it was Red Hat-based (evil empire or whatever).
The difference is that social media is amplifying things a lot more and there is a culture of destroying people in public (made easier by social media amplification).
It’s really the same issue as outside FOSS, social media creates stronger bubbles, more extremes, more grifters, and more amplification of crap.
I can understand that in some social contexts it is possible. For me personally it would be very hard. E.g. most school-related stuff of our daughter is coordinated through WhatsApp, same with birthday parties, playdates, etc.
This shadow device would have it's own keys to read messages sent to your iCloud account. To my knowledge, there's nothing in the security model to prevent this.
Matthew Green has some great posts about iMessage security. This one describes the key lookup issue:
Ignoring the arguments one could make about this making it "more secure" it's clearly disrespectful to the power user that doesn't want to beg Apple's permission to use their computer. I'll grant them their security claims are sound,
I wouldn't say they are sound. First, macOS provides the freedom to install your own applications (ok, they need to be signed and notarized if the quarantine attribute is set) and it's not the case that the Mac has mass malware infestations. Second, the App Store is full of scams, so App Store - safe, external - unsafe is a false dichotomy.
Apple uses these arguments, but of course the real reason is that they want to continue to keep 30% of every transaction made on an iPhone or iPad. This is why they have responded to the DMA with a lot of malicious compliance that makes it nearly impossible to run an alt-store financially.
(Despite my qualms about not being able to install apps outside the app store, I do think they are doing a lot of good work of making the platform more secure.)
This approach was already done by GoboLinux in 2005. And even GoboLinux was by far not the first - versioned AppDirs existed for a long time before; even perl stow enabled that. NixOS just uses a modified variant e. g. via hashed directory names. But I already adopted a similar scheme as GoboLinux did soon after I switched to Linux in 2005 (well 2004 but mostly 2005 as I was still a big noob in 2004 really).
Nix already existed in 2003. Besides that Nix store directories are more ingenious than versioned application directories (or hashed directories), the hash in the output path is the hash of the normalized derivation used to build the output path (well, in most cases, let's keep it simple). Derivations work similarly (also using hashes). Moreover, since a derivation can contain other derivations as an input, the Nix store represents hash/Merkle trees.
This makes it very powerful, because you can see which parts of the tree need to be rebuilt as a result of one derivation changing.
But with all its pros, the thing I hate by far the most in NixOS is .. nix.
I think it depends on your background. I did some Haskell at some point in my live and I like Nix. It is a very simple, clean, lazy, functional programming language. The primary thing I'm missing is static typing.
I instead opted for a less sophisticated solution in that ruby acts as the ultimate glue to whatever underlying operating system is used. What I would like is a NixOS variant that is simpler to use - and doesn't come with nix. Why can't I use ruby instead?
Because what nixpkgs does is not easily expressible/doable in Ruby. First, the package set is one huge expression in the end. That might seem weird, but it allows for a lot of powerful things like overlays. However, for performance reasons this requires lazy evaluation. Also other powerful abstractions require lazy evaluations (e.g. because there are some infinite recursions in nixpkgs).
Second, the Nix packaging model requires a purity (though this gap was only properly closed with flakes). You have to be able to rely on the fact that evaluating an expression evaluates to the same result. Otherwise a lot of things would break (like substitution from binary caches).
Third, things like overlays rely on fixed points, which can be done easily in a lazy functional language.
---
Having used Nix for 8 years now, I have a long list of criticisms as well though :).
Bikeshedding over the language is a huge waste of time, too.
I haven’t written a line of Nix since I started using it, yet it defines three of my systems. I just read diffs that an LLM created when editing my config.
Making a big deal about the language substrate feels like someone still trying to argue over vim vs emacs. It’s trivial and uninteresting.
Still much worse than what could have been. Compare to for example Fairphone, remove some screws and you can replace the battery. Same for the screen and other components. No glue.
Android strict attestation is popular because fraudulent cloned banking apps are a rampant problem for banks, not because they're trying to "stick it" to 200 GrapheneOS users.
Where I live in Europe, Fairphones are becoming fairly popular (as in, I encounter non-tech people using Fairphones). A subset of those users run /e/OS (anti-Google/big tech sentiment is growing pretty strong). This is increasingly becoming a risk for Google, because if /e/OS takes off big time in Europe, it would be easy to support a European app store besides Google Play and F-Droid (which the /e/OS App Lounge already support), leading to a loss of 30% on app spending.
Google will abuse their remote attestation implementation to shut out competitors. If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
> If all they cared for was security, they would have worked with other Android-based operating system vendors that support bootloader locking to come with an industry-wide standard.
Google actually "gave" customers the choice here, although I agree with you that it's crappy and there was almost surely some monopolistic intent -
There _is_ a standard implementation, the Hardware Attestation API. Unfortunately it is annoying to use in a practical way; it requires a fair amount of PKI-wrangling (although there's a Google library for it) and more importantly to allow non-Google trust chains but still enforce boot security, app developers need all of the verifiedBootKey hashes for the non-Google trust chains they want to trust. This makes sense, but unfortunately becomes a maintenance problem and turns app developers off of this.
So, app developers choose the Play Integrity API instead because it's easy, even though they get the side effect that they verify that the device is a licensed Google Play device rather than just a "clean" Android device.
All this is to say that if something like /e/OS were to actually take off, app developers could upgrade their apps to support attestation with the Hardware Attestation API with some extra effort - Google aren't really preventing them and the feature is there.
Anyway, going all the way back to the original story again, I still can't buy into the hand-wringing. A verified, attestable Linux on the server (or for stuff like forward deployed devices) seems quite cool and useful to me, and while I respect the issues with client attestation and the negative effect it can have on hardware ownership, I both don't see it as a practical outcome from this company and don't see it as a practical threat on the desktop at this time.
I strongly prefer apps. The thing that goes wrong here is: Duopoly bad. Competition good.
Since app distribution is not a fair market anymore, it needs to be regulated. Either the fees have to go down close to cost or alternative app stores should be allowed. And not the malicious compliance version of it (as Apple is trying in the EU).
I (native speaker) read it as cutting 3000 of the 4500 managers (keeping 1500) of the engineering arm. Of those 3000, ~1400 will move to an engineering position (probably because they are actual engineers promoted to management) and the rest is let go.
ASML wil zo’n 3000 van de 4500 banen van managers in de engineeringtak laten vervallen. De verwachting is dat ongeveer 1400 mensen een nieuwe functie als engineer kunnen gaan vervullen. „Van ongeveer 1700 mensen verwachten we afscheid te moeten nemen”, stelt financieel topman Roger Dassen in een toelichting.
Actually, they are eliminating 3000 of the 4500 engineering manager positions. However, of those 3000, they are moving 1400 to an engineering position. The article also says that engineers are spending 35% of the time coordinating with their managers and that they want to cut the red tape with this move.
Of course, it's hard to tell how much is PR and how much reality. However, if there is substance to it, it would want me to work there even more, since they value engineering culture over management culture. Having more velocity is good.
> of those 3000, they are moving 1400 to an engineering position
Interesting. In old companies the only way to climb the ladder (get a raise) was to get into management. And then if they were a bad manager, they might get 'sidemoted' into some position where they could still contribute. Anyway, back in the old days, it was not uncommon to see 'managers' or even 'directors' with no direct reports.
So are you saying that there are not new positions open for engineers that were actually doing engineering and that instead some managers that were not doing engineering will now suddenly have to pick up the thread again and start doing engineer?
That would be disappointing for engineers that were actually doing engineering, as yet again their grade increases would be taken by management types.
The difference is that social media is amplifying things a lot more and there is a culture of destroying people in public (made easier by social media amplification).
It’s really the same issue as outside FOSS, social media creates stronger bubbles, more extremes, more grifters, and more amplification of crap.
reply