Re: Why Bloat Is Still Software's Biggest Vulnerability

On 3/12/2024 6:05 AM, Peter wrote:

I trust all is well, remodel long completed, kids now grown
(which of them was first to make you "Gramps"?  and wasn't your
youngest looking for his pilot's license?), thus PBfH having
less of an impact on your life, etc.

 Divorced the witch in 1999,

Yes.  But, IIRC, there was still a lot of "interaction" as a
result of the boys.  Now that they are grown, presumably that
is less of an issue, limiting the intensity of any such interactions?

then the next one (2003-2023) sadly ended in 2023.

(sigh)  Sorry to hear that.  I recall you had high hopes and,
hopefully, some of those were realized.
"One can't get divorced TWICE; the first takes HALF of everything,
the second would take the OTHER half!"

Youngest has a PPL (UK and FAA) and flies, both mine and his RV6.

But, is his interest purely recreational?  Or, might he pursue
that "commercially"?

Chases females on Tinder and Hinge, like everybody else :)

Thankfully, I've never been down that road.

I had a customer many years ago who did write a ton of code in hex. To
enable modifications they had a bit of space after each function, so
edits to a function did not need shifting everything after it :)

>
But what was their *reason* for this?  I had an employer (*had* been
an engineer and deluded himself into thinking he could still *do*
engineering) who was stuck in the past -- as if the tools and
techniques he had used were still relavent, even a few years later!

 Stupidity - assemblers have always been around.

I think a lot has to do with wanting to THINK that an imagined skillset
is still valuable.  With UV/OTP EPROM, that tactic *might* make sense
(as a rebuild could be time consuming vs. patching an image, on-the-fly.
But, with FLASH and RAM-based solutions, there's no time to be saved
(to outweigh the potential for screwing up "manually")

When it took hours to assemble, link, burn images, it made sense to
have mechanisms to support minor tweeks to the code (overwriting
instructions with NOPs and filling in a "0xFF" postamble with new
code).  But, nowadays, make world on even large projects is just
a coffee break -- and, you can dump your code into RAM to watch
it run (assuming you have to run on a target and not in a
simulator).
>
[Nowadays, I netboot images just for the savings that one step
makes possible!]

 Indeed.

It's delightful to see what can now be done on-the-cheap!  No
more playing games with hardware (and its costs/reliability)
when you can just emulate any functionality you want!
(I have a design where a '7180 acted as an EPROM emulator in
a production design to give me debugging support via a
serial console that it provided; i.e., let the 7180 "fetch"
bytes over the serial console instead of having to store them
*in* its EPROM -- a predecessor to netbooting!  :> )
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!  :<