Re: webcam viewer?

On 3/31/2024 11:06 AM, Dimiter_Popoff wrote:

And, with the legions of "programmers" who are just trying to
get something to APPEAR to work, there isn't even a real desire
to ACQUIRE any of this understanding.  Who can blame them?  Will
they be rewarded for producing a robust product ("But, that's
your JOB!  Why should we reward you for doing it?!") or
penalized for making a shitty one?  Is there even anyone in
the organization who has the skills to be able to make such
an assessment??

 Well these and other details amount to what I keep on saying about
shit and piles of it. Look at the sheer amount of memory they *waste*.
I don't know what they do - as you know I live on another "planet" for
software - but I strongly suspect they keep on putting everything on
the stack which ends up full of what is effectively waste as most of
it gets accessed once in minutes of not days. The thought of what

I think modern OOPS software encourages lots of flitting around
invoking methods from various classes to achieve even the simplest
of actions.
But, even old procedural languages suffer from too much complexity.
Even *if* it was structured well (after several refactorings),
there's just too much for a developer to "internalize".  You're
never really *sure* of what is supposed to be happening... just
vaguely optimistic.

the mass software looks like  - be it MS or FOSS - just makes me
sick, I am glad I went my own way all these decades ago. Cost me
several fortunes I guess but people have spent many times that
and don't have a fraction of what I have - which I will likely carry
into the grave, so what.

Consider what you, as a developer, have available for information
about something as trivial as a diode; several *pages* of technical
DATA characterizing it's operation over a wide range of conditions
(temperature, voltage, current).  This implies that the design of
the component and it's actual manufacture has been quantified to
that extent.
Now, look at a *trivial* piece of software -- even something like a
small "standard function".  It is *described* by a few paragraphs
of PROSE.  Nothing beyond its intended function.  Definitely nothing
specific/quantitative.
How *big* is it?  How fast does it execute?  What resources does
it draw on?  Are there exceptions to its operation?  How do its
"calling parameters" impact each of these issues?
strcpy(3c) copies a NUL-terminated string of characters from one
memory location to another.  That *suggests* an implementation...
but doesn't DEFINE one!  What if the source and destination addresses
are the same?  We *assume* we know what the result will be.
But, do we know what will actually happen "on the bus"?  Might
the implementation recognize this condition and simply quit
without doing anything?  Will your system fail because it was relying
on side-effects from the operation??
What if one address is END_OF_MEMORY-(N) and the string exceeds N bytes
in length?
Now, look at more complex "modules".  When is the ARP cache updated?
How is an entry selected for eviction?  *IS* there a cache?  How big
is it?  What if the desired entry is not present in the cache?
What do each of these conditions cost?  How can they be exploited
to coax the device to "misbehave"?
Can't answer definitively?  Why not?  Didn't know the mechanism
even existed??  Or the consequences of its presence?  Ooops!
What else don't you know about the software that you are relying on?
If you don't know how a component works, how can you know what you can
reliably expect from it?  Or, how to verify that it is functioning
correctly?
In light of this, don't you think YOU should be more thoroughly
documenting your code?  Or, are you just going to worry about getting
something to LOOK LIKE it works and let someone else sweat those details?
Wouldn't your employer have procedures in place to ensure these
issues are nailed down?  (or, does he naively just "trust the developer"
because he is unable to understand the issue or its consequences?)
Because this stuff isn't documented, there are no "component catalogs"
to browse to determine what's available to you when writing NEW code.
I saw a piece of production code that read a file, one byte at a time,
and incremented a counter -- to determine the size of the file!
Um, don't you know there are hooks that will TELL you that -- in
constant time?  Common sense -- do you think a list of files in a
directory is produced by reading every file in its entirety in order
to be able to report their individual sizes??