Re: Why Bloat Is Still Software's Biggest Vulnerability

On 3/13/2024 9:28 AM, Peter wrote:

I've been tempted to try reimplementing some early designs just to
see how quickly the development would proceed AND how much faster
the code would execute... big change from a ~700KHz i4004 to an
800MHz quad-core (costing a tenth as much!).  It would be
depressing to discover that a man-year effort can be reduced to
a long weekend!  :<

 My last design is 100x faster than anything done before, and the CPU
costs about $7.

Yup.  I can recall paying $60 for an i4004 -- in 1970's money!
And, a time when 2716's hit $50/each.
For me, it's the difference between a 700KHz processor and an 800MHz
quad processor (at less money).
The idea of trying to save on hardware costs is just silly-speak
(for most designs).

But the software takes as long - because 90% of the functionality is
now connectivity! MbedTLS etc. There is even an HTTP server (simple: I
wrote it myself) for config.

And, there is *increased* functionality.  You do things that you wouldn't
ever have considered, previously.
E.g., that first i4004 product required an offline PDP-11 to
calculate initialization coefficients for each customer/deployment.
Customer moves to a different part of the world and we have to
rerun the initialization code.
*Second* product did all of that *in* the device -- something you
would expect, nowadays (but were wowed by, 45 years ago!).  A lot
harder to get that sort of code working in a device that you (as
engineer) will no longer be able to stand watch over ("What if the
code throws an error?  How will the customer handle that situation?")
But, realizing that connectivity/intercommunications is the
heart of the problem (always has been... "Eschew Globals", etc.)
coaxes you to address THAT issue in your design framework.
My current biggest challenge is designing for 24/7/365 runtimes
where hardware changes and software upgrades happen without
power cycling or rebooting (the MULTICS "Software as a Service"
mantra).  A completely new set of design challenges... (how do
you test devices WHILE they are providing services??  how do
you flag them as failed AND replace them without interrupting
the rest of the system?)