Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: webcam viewer?
Date: Sun, 31 Mar 2024 19:19:01 -0700
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <uud5ip$28dgh$1@dont-email.me>
References: <vgv80j5cnva6ib2959eo3v61j8nnijo2tj@4ax.com>
 <nd8d0j9jmpp4okfugpatctivbmt6r7bs4g@4ax.com>
 <l47e0jt0ivt8abq11u4tnrec9o0724o55t@4ax.com> <uu7ced$hc00$1@dont-email.me>
 <26fe0jpbfttsdmm3beeebf9acm58s2qigm@4ax.com> <uubpkc$1qlr9$1@dont-email.me>
 <uuc196$1sdmo$2@dont-email.me> <uuc8mg$1u550$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 01 Apr 2024 02:19:06 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4e8920cb7c2f0ba383491d77aa9b49ba";
	logging-data="2373137"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+UUDkzsG+Tz4UM9FjmVXGK"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:jcxbXGtWk1EQwwVFBZiVcKA0pKw=
In-Reply-To: <uuc8mg$1u550$1@dont-email.me>
Content-Language: en-US
Bytes: 5991

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??