D
Don Y
Guest
On 1/10/2023 3:21 AM, Martin Brown wrote:
And communicating via email/USENET/telephony software, bank
relying on the software to keep track of your REAL account
balance, car to get you from A to B, furnace/thermostat to
heat your home, etc.
You don\'t notice the software that \"just works\". And, even
the \"buggy software\" apparently still has value (why are you
using Windows? It\'s got bugs in it!!!)
We also tend not to notice the bugs in hardware designs *as* bugs.
They are \"excused\" -- perhaps a tacit acknowledgement that you can\'t
design GOOD/reliable hardware?
I\'ve got a charger for an electric wheelchair that dramatically
overheats when connected to a fully charged battery! (how hard
can it be to design a battery charger?)
When a power supply dies, we don\'t attribute it to a shitty design.
Shouldn\'t power supplies last forever? Even if the user abuses it??
You can open many padlocks without keys/combinations; doesn\'t that
sort of defeat the purpose of being a LOCK?
When I was in school, I played a lot of pinball. Damn near every
machine had bugs that could be exploited.
*Sit* on the glass as the ball was draining and you could prevent
\"flags\" from reseting (the glass would deflect just enough that the
flags would strike the glass as they were trying to flip... and fall
back into their \"activated\" states -- before you\'ve even started to
play the next ball you\'re halfway to some reward!).
The \"random\" match feature (awards a free game if the last two digits
of your score \"match\" the internal random number generator) was
completely predictable -- because there were no real sources of
entropy in the machine so observable events would advance the random
number generator in predictable fashion (tilt the game, on your last
ball, when your score happens to coincide with the known \"hidden\"
random number\'s value).
Drop a nickel into the coin mechanism, carefully, so it gets caught
in the cradle. Then, carefully feed two pennies (one at a time)
in to queue up behind the nickel. Now, every penny deposited
rolls over and past the caught coins and trips the \"coin accepted\"
sensor. When you\'ve bought enough penny-per-quarter, hit the coin
eject and get your initial 7 cents back.
I don\'t recall folks complaining about all these *mechanical*
bugs... (\"Why are there a bunch of pennies in the cashbox?\")
To be fair, many folks have never worked in a disciplined development
environment -- let alone a *regulated* one! Design a gaming device and
have to reassure the client and regulators that: it is \"fair\" and
there are no exploits. Is your RNG truly random? Folks tend to get
antsy when the machine you\'re designing HANDS OUT MONEY -- *their* money!
And, many firms don\'t even *control* their software products robustly.
Can you rebuild an identical binary image for a product N years old?
Do you still have the tools that you used to build it? And, the
commands used to make it? Do they still run on whatever version
of OS you have available, now?
[I\'ve got innumerable VMDKs with all of the build environments
I\'ve used, over the years, for every project.]
*Who* can make changes to your sources? And binaries? Can the same
sort of people mark up schematics or ALTER subassemblies committed
to stock without oversight?
Is your codebase portable? What will you do if the processor on which
you rely goes out of production (or, to 52 week lead times)? Will
your code build correctly for another target? Have you tried?
Will it actually *run* as expected?? Will you *know* that, with
any degree of certainty (or, do you just see if it LOOKS like it
is working properly)?
Do you treat software modules as *components* -- with individual
specifications and validation procedures? Or, do you keep reinventing
the wheel? Do you only deal with the final assembly (and hope its
constituent parts are what they should be)? Any firm doing any amount
of real software development likely has more part numbers assigned to
software modules than \"discretes\" and \"acceptance criteria\" for each.
If The Powers That Be don\'t have their shit together, you can
bet they don\'t have any procedures in place for their employees!
And communicating via email/USENET/telephony software, bank
relying on the software to keep track of your REAL account
balance, car to get you from A to B, furnace/thermostat to
heat your home, etc.
You don\'t notice the software that \"just works\". And, even
the \"buggy software\" apparently still has value (why are you
using Windows? It\'s got bugs in it!!!)
We also tend not to notice the bugs in hardware designs *as* bugs.
They are \"excused\" -- perhaps a tacit acknowledgement that you can\'t
design GOOD/reliable hardware?
I\'ve got a charger for an electric wheelchair that dramatically
overheats when connected to a fully charged battery! (how hard
can it be to design a battery charger?)
When a power supply dies, we don\'t attribute it to a shitty design.
Shouldn\'t power supplies last forever? Even if the user abuses it??
You can open many padlocks without keys/combinations; doesn\'t that
sort of defeat the purpose of being a LOCK?
When I was in school, I played a lot of pinball. Damn near every
machine had bugs that could be exploited.
*Sit* on the glass as the ball was draining and you could prevent
\"flags\" from reseting (the glass would deflect just enough that the
flags would strike the glass as they were trying to flip... and fall
back into their \"activated\" states -- before you\'ve even started to
play the next ball you\'re halfway to some reward!).
The \"random\" match feature (awards a free game if the last two digits
of your score \"match\" the internal random number generator) was
completely predictable -- because there were no real sources of
entropy in the machine so observable events would advance the random
number generator in predictable fashion (tilt the game, on your last
ball, when your score happens to coincide with the known \"hidden\"
random number\'s value).
Drop a nickel into the coin mechanism, carefully, so it gets caught
in the cradle. Then, carefully feed two pennies (one at a time)
in to queue up behind the nickel. Now, every penny deposited
rolls over and past the caught coins and trips the \"coin accepted\"
sensor. When you\'ve bought enough penny-per-quarter, hit the coin
eject and get your initial 7 cents back.
I don\'t recall folks complaining about all these *mechanical*
bugs... (\"Why are there a bunch of pennies in the cashbox?\")
To be fair, many folks have never worked in a disciplined development
environment -- let alone a *regulated* one! Design a gaming device and
have to reassure the client and regulators that: it is \"fair\" and
there are no exploits. Is your RNG truly random? Folks tend to get
antsy when the machine you\'re designing HANDS OUT MONEY -- *their* money!
And, many firms don\'t even *control* their software products robustly.
Can you rebuild an identical binary image for a product N years old?
Do you still have the tools that you used to build it? And, the
commands used to make it? Do they still run on whatever version
of OS you have available, now?
[I\'ve got innumerable VMDKs with all of the build environments
I\'ve used, over the years, for every project.]
*Who* can make changes to your sources? And binaries? Can the same
sort of people mark up schematics or ALTER subassemblies committed
to stock without oversight?
Is your codebase portable? What will you do if the processor on which
you rely goes out of production (or, to 52 week lead times)? Will
your code build correctly for another target? Have you tried?
Will it actually *run* as expected?? Will you *know* that, with
any degree of certainty (or, do you just see if it LOOKS like it
is working properly)?
Do you treat software modules as *components* -- with individual
specifications and validation procedures? Or, do you keep reinventing
the wheel? Do you only deal with the final assembly (and hope its
constituent parts are what they should be)? Any firm doing any amount
of real software development likely has more part numbers assigned to
software modules than \"discretes\" and \"acceptance criteria\" for each.
If The Powers That Be don\'t have their shit together, you can
bet they don\'t have any procedures in place for their employees!