asd4

The security researcher in the article was concerned about accidently confirming the prompt on his watch.

I don't think its a matter of being "smart enough". Human error can easily creep in when dismissing 10's or 100's of prompts.

They seem to gate ECC support behind Xeon for higher end processors. You see ECC memory in a lot of workstation class machines.

"What they mean by IO bound is actually that their system doesn’t use enough work to saturate a single core when written in Rust: if that’s the case, of course write a single threaded system."

Many of the applications I write are like this, a daemon sitting in the background reacting to events. Making them single threaded means I can get rid of all the Arc and Mutex overhead (which is mostly syntactic at that point, but makes debugging and maintenance easier). Being able to do this is one of the things I love about Rust: only pay for what you need.

The article that this one is responding to calls out tokio and other async libraries for making it harder to get back to a simple single threaded architecture. Sure there is some hyperbole but I generally agree with the criticism.

Making everything more complex by default because its better for high throughput applications seems to be opposite of Rust's ideals.

Most hardware engineering is done ahead of time without a full production style environment. This is because the cost of iterating is much too high. You can't build a bridge every time you want to try a new cable or bolt. It forces designers to make models and assumptions about their systems and, inherently, puts downward pressure on complexity. It also forces them to truly understand the principles behind what they are building.

The fact that Perseverance and other Mars rovers have been successful is amazing and took an incredible amount of work to accomplish. These are complicated systems that were vetted using models and simulations without ever having been run "in production". This comes at a high cost.

Critical software is never tested in production or run "in system" before it is deployed. Airplanes, banks, medical systems all require extensive validation through testing on models and simulations. You can't test your changes for the first time on a live aircraft or living tissue. Costs reflect that.

The truth is, a lot of software is not critical. You can get away with hacking / trial and error type development and never fully understand the system you are helping build. Frankly there is a lot of money to be made providing brand new services that are unreliable or quirky or ephemeral because those services never existed before.

My point is that how you test and validate your software product depends on your application. Sometimes the costs don't make sense to "run everything" and sometimes its physically impossible. I agree that you should always advocate for the highest fidelity testing your business case can afford, but be prepared to settle for less than everything and rely on your engineering skills to buy down risks in the gaps.

On the list of features: "Dedicated Audio Processing DSP and sub-system".

The hardware might be there to do some good audio processing, but how it integrates with the OS is something I'm not experienced with.

I did not know this about connection limits.

The multi-domain assets really bug me when I'm enabling domains one by one in NoScript.

Here is an example of domains used on Amazon's website:

  amazon.com
  www.amazon.com
  amazon-adsystem.com
  associates-amazon.com
  media-amazon.com
  ssl-images-amazon.com

On its own "associates-amazon.com" sounds sketchy, but I suppose you assume the HTTPS page that you loaded from amazon.com knows what its doing.

The security boundaries rationale is interesting. I think I need to learn more about that.

From the description it seems there is no backup or redundancy.

Unfortunately the controls problem gets much harder in a non-rigid system. Now you have to solve autonomy AND overcome poor sensing and manipulation.