I dunno, it often matters a lot less than you think when something goes down. And distributed systems have a knack for going down in a much less predictable way, it's not going to automatically make your system more reliable.
(modern server hardware and operating systems are also surprisingly reliable nowadays, which makes it harder to reach breakeven with a distributed design)
To expand a little on this: a chip fabrication process is a series of steps from incoming bare wafers to finished chips (potentially multiple wafers get combined into a finished chip, as well). To build up the physical structure of the chip, there are a series of steps where different materials are deposited or grown on the surface, masked through photolithography, and removed in order to shape the structure of the chip layer by layer. Each of these depends on not just what that layer itself requires (material, thickness, resolution), but also on the layers around it, because these steps are not independent: a lot of process design is in finding a way to construct a given chip that means each step is compatible with the others.
What's more, the configuration and flow of the machines used for each step are quite sensitive: you cannot in general just stand up another fab with the same machines, apply the same settings, and hit go on a new chip design and expect any yield: you need to dial in each step, certainly for each process, and likely for each design. This makes switching things around more difficult as well.
So, while in general a fab will have certain common features: spin coaters, photolithography machines, vapor deposition chambers, ovens, etc, the number and specification of each one will vary based on the process, and a production fab will generally not want to change their process drastically, or even to swap between different designs too often.
With grapheneOS you can lock the bootloader with your own keys. Huge difference. (That said, I don't know if the apps which demand the attestation trust anything but the official grapheneOS keys)
Chip fabrication processes are not fungible: GPUs and CPUs might be made on roughly the same process, but DRAM is not (flash is a different process again, as is power electronics, analog electronics, MEMS, etc. And even within those broader categories there are different variations). While there are some overlaps in machines and techniques, a fab set up for one cannot generally switch to the other, and the economics of each process can also be drastically different.
>And he would have the unbridled rage of everyone in the UK who has decided that 100 years of the Tory/Labour cycle has run its course and meaningful change is needed
Binface is a better protest candidate than Farage for this purpose. Reform is worse than the status quo, hard as that can be to believe.
>He would suddenly have a serious job with real responsibilities
It would probably be worth reminding Farage of this. He has one of the worst attendance records as both an MP and an MEP, and indeed seems to have spent a lot of his time as MP outside the UK.
I think they were specifically bristling at the implication that 'high-end' was mainly relating to price as opposed to functionality. The most expensive watches are expensive for reasons of fashion while being inferior in terms of functionality.
Well, Death of the Author has been a concept for quite a while. How it's made and what the author intended is explicitly not a concern for a lot of criticism and analysis.
TBH, the whole of It Takes Two made me think 'these people are pretty terrible, I'm not sure I want to help them'. The stuffed toy bit was just the cherry on the cake. Good gameplay, not very good writing IMO (Split fiction is better but still... irritating at times)
> If the compiler can optimize a piece of code, it can also show the user what it thinks the optimal code would be so that they can rewrite it themselves, if they so choose
This is not straightforward. Apart from the mapping from a several-layers-deep optimization to the source level being very difficult, it may not be even representable in the original language. And even if it is, it may require complicating the code significantly. Part of the point of compiler optimization is so that you can write straightforward code and still have it be fast.
Compilers will often warn on dead code, but only at fairly early stages of translation where it's obvious that something is definitely dead code in all possible contexts and the fix is obvious. These rules are different to what the optimizer actually uses much later on in the pipeline.
The C++ style tends to create much larger omnibus libraries. If you're concerned about the liability and bloat extra dependencies create, you should be thinking of a) the number of people you are trusting in your supply chain, and b) the total amount of code you are importing. Neither of these correlate directly with the number of different packages that appear in your package manager, and in fact cargo-style splitting can allow you much more fine-grained control over what code appears in your application.
Probably the one security sin of most language package managers is allowing anyone to upload to the central repository without review. This is good for accessibility but bad for security. There are tools like cargo-crev, though, which can help you enforce some level of vetting if you wish.
I don't disagree, but there's a big difference between 'this is massively overinvested and valued and that's distorting the market around a useful product' and 'this is all basically a scam with no value to it whatsoever'. For some reason a lot of AI critics seem to be really hard pushing on the latter part despite it being by far the least credible take at this point. It might be overused, it might have some big negative externalities (though these are often overstated), it might have sucked up way more capital than it deserved, but it's also still very useful and valuable for quite a lot of people.
(to me it's a bit like criticising oil companies by claiming that oil doesn't actually produce any useful power after its refined. There's a lot to criticise about them but the fact that their product is very useful is in large part why it's so hard to do something about the rest of the problems they cause)
TBH, the whole thing reads like a pretty off-topic rant, its a leap from 'accesibility to blind users' to 'treatment of people with disabilities' to 'cyclists being aggressive towards the poster, who is neither but wears noise-cancelling headphones'. I'm not sure if there's a productive discussion to be had around it.
Better than that, you can get a bootstrapped rust from the Guix project, which has bootstrapped its entire system from source code from only a tiny verifiable binary.
The app can be open-source and verified to not be sharing extra info, though. Of course if no-one bothers to use the verifiable version of it, then it's all pointless, but this is true regardless (they could also just not use ZKPs).
Yeah, if the entities share data they'll share data, but ZKPs give a way to, in principle, verify that they cannot link two parts of that together by doing the verification. I'm not sure I understand your flow example though. If they ask you to enter an age, but will accept a zkp that you're over 18, then you could enter any age over 18 in the first part and they would have no way of knowing.
(modern server hardware and operating systems are also surprisingly reliable nowadays, which makes it harder to reach breakeven with a distributed design)