Adding a link to a malware zip? That seems pretty naive.
Where are all the training-data poisoning repositories? Those set up so the next generation LLMs will be trained to include malware in the code they generate. Isn't that the new kind of supply-chain attack that's probably happening right now?
Sigrok is amazing! The killer feature for me is sigrok-cli. With it you basically convert from electrical signal to Unix pipe.
Super useful for running e.g. timing measurements and quick-and-dirty plotting. Or grepping through millions of signal transitions to pin down a nasty race condition.
My approach to solving problems that span complex systems:
1. Instrument 2. Measure 3. Interpret 4. Act
Iterate as necessary.
I have come to see this pattern working on electronics design, embedded software, industrial control systems, networking and webapp backends.
Breaking it down:
1. Instrument
Understand subsystems and their interfaces. Use tooling around these interfaces to trace the interplay between subsystems. Make sure all tooling is synchronized so you can correlate information across tools via timestamps. If you can't instrument remotely, bite the bullet and reproduce locally.
This ties back into the design phase: Design interfaces to be instrumentable, ideally remotely. Test points on PCBs, traceable APIs in software, using network protocols that tools like wireshark can decode. Pub/Sub systems are great for this, as you can easily add another subscriber for instrumenting all communication. Don't rely on "what happens to be available" for instrumentation. AWS CloudWatch will miss that one crucial piece of information. Your oscilloscope tip will not make reliable contact on a QFN pad.
Simply stated: Become good at interfaces and make them accessible.
2. Measure
Take the time to properly run tests and gather data. For issues in systems spanning mechanical, electrical, digital and software domains, you won't have one tool to do it all for you. Data preparation and cross correlation will be a manual process in most cases. That is ok.
3. Interpret
This is about understanding your problem and digging down from high-level symptoms to low-level root causes. Don't jump to conclusions. Let the data sink in to identify second order effects. Don't rush it because of pressure from your boss or the customer.
4. Act
Now that you understand your problem at a deeper level, it should be straightforward to apply corrective action. This might not solve the issue yet, but you will get closer to the root cause.
Two notes:
* Never stop after step 4! Always iterate once more so you can be confident the issues is actually solved and not just hidden by some effect.
* If you're a team player, document each step. A short note and screenshot in an issue tracker go a long way.
About engineering mindsets:
I find it infuriating when people calling themselves engineers don't follow any practice like this. Yes, you can solve problems through sheer experience or by hitting your head against the wall for long enough. Alone. On simple systems. But working together on complex systems you have to apply some methodology. Doesn't have to be my methodology, just not no methodology.
For me a big red flag is when engineers don't understanding why something works. Not understanding why something doesn't work is ok. We are human and systems are complex. But getting something to work, wondering why it does and then sending it to the customer? That's not engineering, that's tinkering. It's asking for trouble.
25cm birch logs surely are fun to split. With any kind of axe.
We use to chop 1m (~3feet) logs of a lot more compact wood (oak, beech), and this looks like a toy to me. Has anyone seen it used on more serious logs?
So allied governments are basically idiots for not thinking the USA would spy on them?
That would mean they should have put into place institutions protecting them from said spying. Which would be taking (defensive) military action because of the actions of an allied government. Now what kind of alliance is that?!
On the slide it shows an SPI- as well as uart-connection. Both should be very straight-forward to use, either relying on external libraries or by writing them yourself.
I liked the gradation of Arduino - Raspberry Pi - Beagleboard [Add further boards to liking]. This Yún thing seems like a step into the direction of "10 different boards, that all do the same thing".
On the other hand, more competition is probably healthy for this market...
In my opinion "dumping a child in front of a screen" should really be the last option; only used with a good excuse and balanced by extensive investment of time. (It's of course easy for me to talk like that, but I see one of the greatest responsibilities of live in raising your children properly. Which for me includes spending a whole lot of time with them.)
One thing about this whole discussion really bugs me:
Everyone is just talking about how to keep the children occupied with technology. I really think this is the wrong approach, there is so much more to learn and explore than stupid pixels on a screen.
When we were young my parents had the attitude that it's very important to get a "feel for the earth", in a very literal way. That's why we spend as much time outside as possible. One of the few things I remember about primary school: I was the only one who knew potatoes grow below ground. Where has this world come, that our children know so little about even the most basic stuff??
Low screen/front-size ratio, big fonts to compensate low resolution, flat UI and "clever" menu layout to compensate low contrast. Consumer expectations are high these days...
It saddens me how few of the people I meet have this attitude. I learned pretty early how rewarding hard work is, but the opinion I hear most is "life is for living, not working". "Life is for living" is a justifiable claim, but why don't people see living well and working hard can go hand-in-hand just fine?
Where are all the training-data poisoning repositories? Those set up so the next generation LLMs will be trained to include malware in the code they generate. Isn't that the new kind of supply-chain attack that's probably happening right now?