Thursday, April 10, 2014
What I would like - hell! What I would absolutely fucking LOVE is for software products to have to include an ingredients list... if it uses open source garbage it should say so on the packaging in a great big warning label. The proportion of the source-code that the "author" hasn't even fecking well looked at, let alone understood, should be stated so that people have an idea how little the vendor knows about what they're selling.
It really REALLY pisses me off that there's no public distinction between the software written by people who have a clue what they're doing and the integrity not to use random garbage and the utter tripe that's thrown together by mindless, clueless garbage collectors, who go bin-diving in the open-source sewer and pile up sludge until they have enough to call it a product... except that image is far too kind for what clueless modern programmers actually do; there are really no ways to describe or conceptualise the extent of their miserable incompetence.
It sickens me to be thought of as belonging to the same profession as modern programmers. It utterly, utterly sickens me.
[later, after watching more news about the latest exploit found in open-sewer security software]
Whenever I see some turd of a programmer extolling the "virtues" of open-source software, using the lie that "anyone can see the source so it gets reviewed", as if many of the modern programming crowd have the competence to judge anything or anyone has the time to wade through the hundreds of millions of lines of code that get dragged into every project these days, I want to kick the lying shit out of them.
[muses] It would be unfair (and inaccurate) not to acknowledge that there are some very skilled programmers involved with writing open-source code, and most of the people who do it have good intentions. But the problem is that, like a chain, the weakest link is what determines the overall quality of any project, not the strongest, or even the average.
Writing reliable code involves far more than enthusiasm and the willingness to become involved; it's a real skill, it takes time to acquire and not many people have the right mindset, patience and consistency to do it even if they have the willingness to try, and few do - there's far less glamour in carefully writing a solid reliable application than there is in dashing something QAD (quick and dirty) out and then scampering on to something new and exciting, leaving behind a trail of half-finished projects for others to clean up.
But never mind... I have discussed this subject many times over the years and to do it justice requires more time and effort than I'm prepared to spend on it on facebook; I could and probably should write books on the subject. It's hard enough to get people to understand how to write code that can be tested, let alone expect them to try to test code that wasn't written with testing in mind by someone else who doesn't understand the process, who has a different coding style and skill level and like as not was introducing new problems while trying to deal with others and working on a completely different hardware platform... so the oft-mentioned concept of open-source generating reliability by peer-review and the process of bug detection/removal is childishly, painfully naive.
I predicted over twenty years ago that we should expect software to stop behaving like an all or nothing digital system that either works or doesn't, but instead to experience a combinatorial explosion of unreliability until computing environments behave in an analog fashion with multiple degrees of failure of varying severity following an exponential decay curve slowly approaching - but never reaching - a stable state. I pretty much nailed that one, unfortunately.