Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y 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: References: <26fe0jpbfttsdmm3beeebf9acm58s2qigm@4ax.com> 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: 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??