EmbeddedRelated hosts articles by embedded engineers on algorithms, FPGAs, C techniques, hardware bugs, and the history of the 6502.
Commenters recommend its articles, such as Jason Sachs's LFSR series, and cite them on RF signals and complexity.
This is an excellent question, and I'm disappointed this hasn't received more attention.
Secretary problem - applicable to anything where you have a lot of choices, such as marriage, getting a job (not just hiring), picking a business partner, anything you have to accept/refuse.
The solution is you reject the first 37% of applicants, use that to establish a benchmark, and then pick the first one who is better than any rejected. You're 37% likely to find the best candidate. But such is life. In other words, once you marry someone out of 10 choices, there's 63% odds you'll find someone better later.
There's Amdahl's Law/Gustafson's Law, explained nicely here: https://www.embeddedrelated.com/showarticle/1033.php
Basically, upon first observations, Amdahl's Law seems true... even if you put 10x more effort into something, it seems like the total output is 42% higher. But this total output being 42% higher means that you can also do X, Y, and Z, 42% faster. Having Z 42% faster leads to A being 20% faster, leading to B being 8% faster, and B is a feedback back into the loop.
In more practical terms, much faster computers means software is written slightly faster, but slightly faster software allows for more complicated electronics CAD, which allows us much faster computers, which allows for even more advanced technical developments like Internet and cryptocurrency.
In short, if you're locked on Amdahl's Law (minor gains for tremendous effort), find a way to utilize…
This is by the founder about IAS (aka (Turing's) [*Bazaar-]Cathedral) founding between war & depression, while it was still at 20 Nassau St
Further Quaker background by Freeman Dyson's son George who wrote that book having grown up there
https://www.ias.edu/ideas/2009/george-dyson-tavern-and-meeting-house
*IAS was an open-maxxed Bell Labs
https://www.embeddedrelated.com/showarticle/700.php
>Dyson misses the point somewhat about virtual machines and cloud computing, which are much more about relocatable and rescalable computing — rather than having to house and maintain computers to handle the peak computational load, we can run software remotely as a service, and purchase resources on an as-needed basis; the providers of these services can reroute and reallocate resources in real-time without any intervention by or impact on their customers. There’s something here in Dyson’s statement alluding to parallel processing...
Paradoxes for outwitting the uni-context..
Great read!
Complexity is evil evil evil (my take on it: http://www.embeddedrelated.com/showarticle/132.php)
<quote from Conway's article>
Incidentally, today’s automobiles share this problem
of a massive amount of on-board code and the bugginess
that accompanies it. A few years ago, some Mercedes
owners found that when they pushed a certain button on the
navigation system the driver’s seat moved.
</quote>
I have this sinking feeling that my death is going to occur because of some interaction between software/firmware design and an unexpected situation (e.g. stuck in an elevator between floors because the firmware is expecting internet packets from Twitter or something). Hope I'm wrong, but the complexity of electronics seems to be increasing fast enough for system reliability to decrease.
This is an interesting play but doesn't seem like a good fit.
The examples on the front page: "how do I connect to our database", "what kind of email templates do we have". Are these questions that you're going to get multiple answers for and I'm going to upvote the best and/or select one as the "selected" answer. I would think this would be a sign of dysfunction in most cases. And how does the gamification play into it? (maybe it's a secret bus-factor detector.)
It seems like a regular wiki/knowledge base would be a better fit for this kind of knowledge. How would the SO structure help.
A related note, I wonder if you can disable the "Soup Nazis"[1] feature or it's too deeply embedded in the psyche of the product.
[1]https://www.embeddedrelated.com/showarticle/741.php
Why isn't volatile sufficient here? If they were both modifying the same variable, I can see how
A:read Ax;
(Interrupt: B:read Bx; B:write Bx+1; return);
A: write Ax+1 # (wrong!)
could occur. But the only error I can see here is that sometimes put() might fail thinking there is overflow when there's maybe one space left.
Am I missing something?
(Further investigation: This[1] thread suggests you can run into problems if your counter type is larger than the native ALU size, because the interrupt could occur midway through your increment operation. But here the size_t is 16 bits, so that should 't be a problem?)
[1] http://www.embeddedrelated.com/showthread/msp430/20400-1.php
When is VxWorks inappropriate, but QNX appropriate?
EDIT: http://www.embeddedrelated.com/showthread/comp.arch.embedded/123841-1.php says:
> the most fundamental difference between VxWorks and QNX is as you have described, QNX lends itself to a message passing architecture while VxWorks lends itself to a shared memory architecture.
>
> My personal opinion is that a message passing architecture is easier to get to grips with and as such is potentially easier to understand and debug.
> However, the majority of software engineers with experience of an embedded RTOS will be very well informed about the Shared Memory architecture.