HN user
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.
I've had good luck with https://www.rockauto.com/ though I haven't bought anything big through them.
The website is fun and nostalgic to me.
"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.
I wasn't familiar with the underlying effect. This paper seems relevant and is very readable.
https://www.sciencedirect.com/science/article/abs/pii/S23524...
I like https://www.borgbackup.org/ and you can get a relatively cheap storage plan on rsync.net just for Borg (https://www.rsync.net/products/borg.html)
Retrieving backups is a little manual. Perhaps someone has created a nice GUI for it.
It's a single axis version of a system my group at NASA developed:
https://roundupreads.jsc.nasa.gov/pages.ashx/787/New%20weara...
The internal application was to improve mobility in space suits. We had a partnership with some medical researchers looking to help patients with otherwise limited mobility.
Shoulders are difficult. The human body has a lot of amazing degrees of freedom. One of the biggest challenges was efficient and effective transfer of the assist forces to the body.
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
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.
I second this. Hobby focused content might seem amateur but it has some advantages in my mind.
Context: My biggest gripe with traditional education is lack of context for why a principle is important or useful. Not a problem when you are focused on a project.
Practicality: The practical aspects of theory are usually limited to core principles and help you see through the fog of all the details.
Narrative: Bringing many topics together in a project narrative give a linear path through the related principles which is less overwhelming.
https://hackaday.com articles, in my experience, have been a good jumping off point and often have solid links for better understanding.
A weakness of this approach is that it ignores the mathematical techniques to solving some of the problems. I doubt you will learn how to analyze circuits with differential equations or phasor analysis on a hobby site. That said, I rarely use these tools outside of an academic setting.
I'm sure someone will recommend The Art of Electronics. Its a great resource once you have the basics under your belt, but hard to use as a learning tool without prior knowledge. It touches on a lot of details by presenting a circuit and summarizing key points about its operation.
Once you have a handle on the basics I highly recommend playing with some circuits in a simulator. LTSpice is free and very high quality. There are other online options too.
You can experiment on hardware relatively safely if you stay away from high voltages and currents (avoid mains power and car batteries, always use circuit protection such as fuses). You will be frustrated if you have no test equipment though, a multimeter is a must-have.
I switched from Bose to Sony and haven't looked back. The capacitive controls on the headphones are crap but I never really use them so it's not a big issue for me. Rock solid for music and getting work done.
With what is at stake I'm ok being "difficult". At the end of the day the person running the desk just ensures that you have the minimum required for treatment.
In the US, at least in larger cities, one of the signatures is often to share your data on an ERM network with all doctors/hospitals in the network. I never sign this one and it's never been an issue.
Ebook is available too! https://armypubs.army.mil/ProductMaps/PubForm/Details.aspx?P...
Furthermore they use their own build system (catkin, WHY?), define their own IDL (WHY?), use their own dependency system (rosdep, WHY?) and even mess with your Bash environment.
I agree. When I ask these questions (we use ROS at our company) the answers usually sound like the following:
1. Catkin: No other solution for multi-project CMake. Apparently development often spans multiple projects / repositories for a single integrated "feature" on the robot.
2. IDL: Because they have their own middleware. I think this goes away in ROS 2.0 as they move to DDS.
3. Rosdep: Because they want to run on multiple distributions even though it seems Ubuntu is the only truly supported distro. Rosdep is just a thin layer over the local package manager, pip, and whatever else they have glued in.
4. Environment: They provide the concept of "workspaces" to enable checking out source for a small subset of packages to work on and override whatever is installed on the base system.
I live in the embedded / hardware world but my colleagues working on the higher level software tend think all of the above is necessary for dealing with the hundreds of packages and dependency hell that come with the "modular" robot software approach.
That said, the popular packages in the ecosystem for simulation, planning, robot modeling, etc seem powerful. Community developed ROS "drivers" (middleware integration) are also useful so you don't reinvent the wheel for off the shelf hardware integration.
Also see ROS Industrial [1] for extensions to the ecosystem to include common industrial robots.