The Linuxoids and their cherished so☭ialist dreams

They’ve pretty-much stopped whining about The Year of the Linux Desktop; it’s a joke, even in the geekiest circles. ... But Behold! There are wildly-successful Linux/Unix desktops all around us: the multiplying Android phones and tablets are Linux, and the supernaturally-wonderful and profitable Apple computers, phones, and incredibly-beloved tablets are all based on BSD! ... These things are all proprietary out the kazoo of course, but did they really expect an entire computerized society based on loving caring sharing kindly geeks?!

... Yes, of course they did. And do. I mean Richard Stallman is a balkan folk dancing devotee! ... They’re all card-carriers, from way back! Red diaper babies at least! ... OK, many innocents can’t sing the Internationale, but just know in their hearts that everyone should share and be nice. ... Whatever. ... It never occurs to them that all the wonderful junk they play with, from Linus’s Minix to the 386 computers and onwards, were all entirely the product of the vicious heartless engines of capitalism! They did not arise in the beloved socialist vales of the gone-but-still-beloved Soviet Union....

And half the servers in the world run on real brutal command-line-only Linux, which is not to be sneezed-at. But still bought and paid-for by vicious profitable blood money....

Mendacious Delusions

So the astonishingly mendacious delusions the Linuxoids host and cater-to, things like telling innocent newbies how Linux is so much easier than Windows, are characteristic progressive traits: progressives believe in lying, they believe that correct lies are a higher morality, better than the mundane mud-spattered truth....

So below I have gathered together my irrelevant Linux thoughts and dreams from the stumbling years, where they can be isolated on my web site, harming no one, innocently idling-away the passing era with beautiful delusions and complicated excuses. ... This all occasioned by a recent Owenshow adventure, where I installed the so-easy-to-use “Mint” Linux in a VirtualBox, and it was so EZ! ... I was only required to use cryptic unknown command-line mumbo-jumbo about half the time; oh of course that’s why it’s such a wonderful EZ desktop....

— the sadder-but-wiser programmer
2/22/15

P.S. As I was editing this inspiring screed with my beloved Kompozer html editor, I managed to wreck everything by foolishly relying on Kompozer to move blocks from one page to another, and I think I will blame that on the compassionate open-source movement, too. Kompozer’s faults appear to be the result of the original selfless author trying to screw some pitiful bits of lucre out of the project by directing us to the no doubt exciting “http://disruptive-innovations.com/zoo/nvu”. ... Well, the guy who took over the project for quite a while claims credit/guilt, although he may be just explaining. ... And when I go to http://disruptive-innovations.com, it is clearly for-profit, and so I’ll continue to assume it was evil greed that drove it mad, even holy open-source as it may be....

Linux, the Wireless Internet, and Me

It doesn’t work. I believe here in 2/10, at least a few linices will connect through your wireless hardware, but many still won’t. If you’re thinking of installing Linux and expect your wireless to work, try and look it up on the web somewhere somehow.

It doesn’t work because wireless hardware is the cutting-edge feature today, and it’s designed to work on Windows. Once that works, the technical knowledge spills onto the floor and the table scraps are picked-up over the months and years by the Linux guys. ... And it doesn’t work also because the Linux guys spend their hours at wonderful geeky places like universities and tech companies where ethernet sockets are everywhere so anyone can plug in — and where the companies at least loathe the uncontrolled proliferation of wireless. ... So the privileged treats of the Linux class are reflected in their wireless neglect. ... And at 1/16, I read yet again, in the technical Q&A of some German Linux magazine, of the endless monstrous delvings a pilgrim was supposed to go through to get his Linux wireless working. Still....

The Broader, More Meaningless Issue: Why Are These Linux Guys Such Mendacious Weenies?

I had a revelation, a vision — doubtless one of the 17,000 symptoms of onrushing Alzheimer’s — of all the Linuxoids bonding to their command-line operating system around the same time I was discovering that one could do useful work in Windows 98....

We just went in different ways, us Windows-using guys — accountants, word processors, and even assembly-language programmers — because Windows made those things easier, mostly because it was popular! ... And the Linux guys refined their favorite OS, until today it’s a substantial part of the server market. ... Which servers do not use wireless connections to shoot-out gazillions of bytes. Or heart-breakingly gorgeous GUIs for that matter — the Linux desktop was always an afterthought. ... So give it up guys; stop lying in your magazines and web sites, and admit that Real Men use Linux on the command-line and spit on GUIs. ... Which is the way servers work; the only reason Windows servers include a GUI is because they’re stupid! ... It’s that simple! ... Of course having the odd spare billion bucks makes Microsoft a threat in the server biz, and the race goes not always to the swift and sometimes to the weirdly-incompetent wealthy — but stop the nonsense about your Linux desktop already!!!

... Having ranted all that, it is entirely possible some Google cell phone or tablet computer will take over the world any day now, and then there will be a Linux desktop everywhere. ... But heck, there’s already a BSD distribution everywhere, aka The Macintosh! ... If Google scores, it’ll be just like that — except Linux!

— the often-coherent programmer
Mon 1/6/14 7:05 pm

1. The 2015 “Mint” Linux did connect without much fuss — but inside VirtualBox. That’s because I used a Vbox “appliance” which was presumably set-up by some kindly geek to work — presumably by supplying a working virtual wireless connection. They can’t afford to do that with actual hardware, which is why it probably won’t work on your computer. Unless you do it inside VirtualBox. So the obvious Linux wireless solution is to only use it inside a working-wireless Windows virtual box....

Wild card expansion in Unix

This section used to be called “Linux Recursive Grep: Insanity or Depravity” or something like that, but then after the passing years, a thoughtful correspondent wandered along and enlightened me. ... This is the Unix recursive grep:

grep -r --include “*.h” --include “*.c” lostfunction .

Note:

1. Single hyphen for “-r”
   
2. Double hyphen for “--include”.
3. “lostfunction” is what you’re looking for, recursively at last.
4. A single concluding dot.

ZSH?

And then, after a million years, another country: apparently the “zsh” shell has a kind of built-in recursion. The shell is available on many linices — you just go “zsh” — but I then typed in “grep opendir **/*.h” at /Developer/SDKs on my mini, and got an “argument list too long” error because, of course there are five million .h files in those directories. ... So close — but no cigar....

Backstory

... But to start our sad story at the beginning: grep is a programmer’s command-line tool that searches for text within files, and is essential for figuring-out where things are in one’s enormous overgrown projects, i.e., here in MSDOS-land (aka Windows)

might spew-out the names and lines of c-language and c-include files containing the text “lostfunction”. The “-d” option, at least in my Borland grep, means “-d Search subdirectories” because, of course, most adults and some children put our giant sprawling out-of-control projects in an entire directory tree, and we’d like to search all of it when we’re trying to find something.

And for years, as I wandered the byways and back alleys of Unixism, I was sure the hidden secrets of recursive grep would be revealed. ... I knew it wouldn’t be easy; I actually found a Unixoid lecturing some poor pilgrim how yes, of course grep has recursion, read the manual — but the adept gave no example! ... I googled another likely suspect “examples/grep.pdf”, but apparently the Unix police got there first — the thing was gone 404 not present! ... I encountered volunteers who were going to write their own recursive greps someday, and cunning scripts that would make it work — but none of them knew of the magical “--include” option....

... It was like when I encountered the MSDOS midnight bug in the land of the dinosaurs, where the time-of-day clock didn’t know about tomorrow if the computer was on at midnight, demonstrating, if there was any doubt, that the guys at Microsoft were not the crazed lunatic all-night hackers they apparently wished us to believe they were. ... Perhaps Unix, in its secret heart, had no recursive grep! ... Oh the shame! ...

But as it turned-out at last, it did, as my kindly pilgrim showed me. The option was there all the time! Let a thousand Linux directories grep! ... Except — it was a secret! ... Which brings us to ...

Unix’s Pathological Inability to Communicate

I checked my many Linux manuals for grep, and it does indeed describe the “--include” option:

That’s it: end of description. I doubtless tried that a few times in the years of darkness, and of course it didn’t work because there wasn’t the slightest hint as to what a “PATTERN” might be. ... Now I know, if the documentation had been tortured with burning bamboo splints under its fingernails it might’ve admitted that it really meant

--include “QUOTED_PATTERN”

but I couldn’t torture the Unix documentation, as much as I’ve yearned-to so many times....

Very Clever Shell

It works — or not — because of the exciting Unix “shell” feature where AFNs are helpfully expanded, so if I type “grep lostfunction *.c *.h” on the Linux shell command-line, what the grep program gets to see is the vastly-improved “lostfunction bingo.c bongo.c dopo.c bingo.h dopo.h” — i.e., the shell “expands” the asterisk (a well-known convention) to show all the files in the current directory that end with “.c” (for *.c) and “.h” (*.h). ... And quoting wild-card expressions suppresses expansion.

... In contrast, in the boringly-stupid helplessly-primitive MSDOS/Windows world, nobody does that for you; shockingly, every program that wants to provide this functionality has to do it itself. ... Like Borland’s grep.

Why is that?

MSDOS did it the dumb way because it’s dumb; it was supposed to be a small harmless system for microcomputers, not the mini and giant Unix computers. ... By the time Linux rolled down the pike, microcomputers were plenty powerful-enough to support such wonderful shell features, but Microsoft didn’t bother, particularly since doing-so might break millions of existing batch files. ... Note that both MSDOS — and its even micro-er predecessor, CP/M, where I first encountered AFNs — provide support for the feature with operating system functions that find one or more files based on an AFN, but the programmer must implement the feature.

So what?

The trick is, it’s harder to write recursive grep (or recursive anything) when the shell expands the AFNs — because the shell necessarily expands them in the single current directory in which the program starts. ... Maybe Unix’s clever shell expansion wasn’t so clever, eh? They could’ve instead provided a callable expansion function to do a lot of the work (i.e. as opposed to the primitive CP/M style); Windows probably has one by now somewhere in the 5,000,000 APIs. Heck, Linux has it — “glob”! ... So Unix could’ve done that instead of the shell expansion, and every single program would’ve had to use those system calls — but only if they needed AFN expansion. The majority of programs don’t need AFN expansion, and they wouldn’t have to “pay” for the shell code they don’t use. ... So the design trade-off is not really that obvious, and perhaps the brilliant Unixoids did something wrong, no? ... And then I finally bothered to look up Unix “glob”, and apparently

Long ago, in Unix V6, there was a program /etc/glob that would expand wildcard patterns. Soon afterwards this became a shell built-in.

... They don’t actually document the glob program, naturally. ... So this was all deliberately concocted, to make the shell ever more powerful, intricate, and impossible to understand!

... I believe it’s something to do with the script/program divide: in Unix, creating executable programs is generally so appallingly-difficult, and script languages are so EZ and powerful, that providing AFN expansion for just programs wouldn’t fly — and forcing scripts to use glob or something for the purpose must’ve been intolerable.

In MSDOS and onwards (and in CP/M before), we had the inimitable Borland all-in-one “Turbo” languages, which made creating executables practically a no-brainer — versus the primitive MSDOS batch files, which may have stayed so primitive partly because of the inexpensive Turbo languages. ... And in a nicely complementary fashion, *nix programming is so infuriating partly because of helpful shell features like wild-card expansion.

But Why Don’t Unix Talk Good?

It doesn’t help that most Unixoids pick up their secret hermetic inner knowledge during their university education, but don’t know that, so, like so many stupid smart people, they imagine others’ ignorance of things that everybody knows (i.e. everybody the stupid smart person knows) is evidence of a simple childlike nature in need of low-syllable-count instruction — when, instead, it is evidence of a different common psychological fault, the absence of psychic powers....

P.S.

And then 10/27/03 I read The Unix Hater’s Handbook — and it turns out they know all this already! And so much more! ... Ah so sad, we run and run and the wheel just goes around. ... Incidentally the UHH is an excellent introduction to Unix; they tend to contrast to the non-existent ideal a lot, but it’s still very helpful to see the stuff that a lot of people think is stupid — so at least you won’t feel so silly when it bites you....

Tick times: Windows GetTickCount() and Linux times()

In ancient days, when assembly language programmers roamed the earth, we were advised to stop using timing loops in our programs — do-nothing waste-time loops like (z80 assembler)

;WAIT A MILLISECONDS.
MSA: PUSH BC
MSA10: LD B,95
MSA20: NOP ;4
NOP ;4
DJNZ MSA20 ;13.
DEC A
JR NZ,MSA10
POP BC
RET

These were bad bad bad, because whenever the program moved to a different computer, all the timings would be wrong — your Kaypro and your Osborne (prehistoric CP/M machines) would play different! ... But in those dark days, we didn’t actually have any way to fix this¹. ... When we graduated to the wonderful new MSDOS world, IBM-compatible PCs had a timer interrupt, and with some fairly hairy programming one could derive useful timing functions. ... Things toddled-along nicely until Windows95 and Win32, whereupon Microsoft introduced GetTickCount(), and all was made anew.

GetTickCount()

The Win32 GetTickCount() function returns a 32-bit unsigned number representing the number of milliseconds since the machine was turned-on. It isn’t necessarily accurate to the millisecond, but that’s never been a requirement in our innocent endeavors. ... As for using it, when I googled for GetTickCount() recently, the first thing I found was a Microsoft page with this (correct) example:

DWORD dwStart = GetTickCount();

// Stop if this has taken too long
if( GetTickCount() - dwStart >= TIMELIMIT )
Cancel();

So What Happens When You Run Out of Ticks?

1. Well, that’ll never happen! ... At least it certainly never happened in the fledgling years of GetTickCount(), since the ticks last for 49.7 days — and nobody had PCs that stayed-up 50 hours, much less 50 days....

2. Ok, stupid answer. ... Here’s a better one: if you follow the style shown in the example, your timing will survive the 50 day limit with impunity. ... Amazing, eh? How does that work? ... Well I think we’ve reached the appropriate point in the discussion for an incomprehensible chart:

Assembly Language Programmers Versus Everyone Else

I started thinking about all this after reading Jack W. Crenshaw’s Embedded Systems Programming column, 6/05, page 11, where he related mysterious failures associated with Windows CE and the magic 49.7 day interval, noting that he had been blogged by two Microsofties who pooh-poohed such reports. ... And I must opine, I think the softies are almost certainly right; the reason these systems fail is probably because naive programmers wrote code like

DWORD dwStart = GetTickCount();

// Stop if this has taken too long
if( GetTickCount() > (dwStart + TIMELIMIT) )
//BAD BAD example
Cancel();

which can indeed fail after 49.7 days (although to make it worse, you could pass the 49.7 day boundary without error, depending on random factors). ... I suspect the reason these programmers don’t or won’t follow the simple example above is because they think it’s gobbledygook — how can it make a difference how you form the expression, they wonder, how can it make a difference whether you use addition or subtraction? ... The basic problem is these naive programmers don’t know — or believe — that ...

... or, to put it another way, they don’t understand “2s complement arithmetic” — which is how integer arithmetic works down there in the real computer (well, in most of our real computers; 2s complement, like everything, was young and new once) — which is the kind of thing all us assembly language programmers are born knowing. ... Maybe this makes more sense (less?) in hex

— the idea being that if you increment a 32-bit register containing FFFF,FFFF the result is 0. This leads to all the additional 2s complement magic like

and so much more — that’s what the computers are really doing down there!²

Linux times()

This informative diatribe used to be known as “GetTickCount() versus Linux times(): The Rollover Smackdown!” because http://www.die.net/doc/linux/man/man2/times.2.html (among others) says of the Linux times() function

RETURN VALUE

The function times() returns the number of clock ticks that have elapsed since an arbitrary point in the past. For Linux this point is the moment the system was booted. This return value may overflow the possible range of type clock_t. On error, (clock_t) -1 is returned, and errno is set appropriately.

and I foolishly believed that the last two sentences — about “overflow” and “-1 is returned” — were connected — and the times() function was essentially broken after 497 days or less. ... Then, at the instigation in an email from one of the very few people who have actually seen this site and doubtless wishes to remain anonymous and unassociated with my diversions, it’s occurred to me that I was probably wrong.

... My guess now, recollected in tranquility, is the Linux times() function probably never returns -1 for an error; that was just a fairly obvious effort to obfuscate things, probably thrown-in years ago by some well-meaning type who thought it might want to do that, perhaps, someday, and people should be warned....

And indeed I was warned; and concluded, probably erroneously, that the obvious error it was talking about was the overflow mentioned in the previous sentence.³

But I’m going to change my world-famous OwenShow so it assumes Linux times() never returns a -1 error, because that now seems most likely to me, and because it concerns something that’ll happen in 497 days and I just don’t care.⁵ ... Which, of course, is at least partly why the Linux so-called documentation was so free and easy about it — because, for goodness sakes, that’ll never happen!

Not As I Do

I couldn’t decently advise you to go and do likewise; and this is a classic demonstration of what’s wrong with bad documentation. ... My guess is times() works, and never returns -1 (except of course when that’s the tick count); but any program that assumes that could, some bright shiny morning, be wrong! ... Someone somewhere may rewrite the function and, reading some version of the documentation, assume that times() should return -1; maybe early and often!

... So you might start programming defensively by clearing errno before each times() call, and discarding the result if it’s -1 and errno isn’t zero. ... But what if our industrious rewriter concludes that times() should continue returning -1 if an error condition persists? Which, presumably, it would, if any of the counts overflow; that is, he would want to make sure the caller did not act on an erroneous timer value, and so he returns -1....

I hope he doesn’t do that; I’m guessing times() doesn’t do that now. If Linux were actually documented, on the other hand, we’d know under what conditions times() was supposed to return -1 or — preferably — that times() never returned -1. ... But instead, the function might return -1, for any reason whatever, according to the existing description (at least existing whenever I wrote this senseless screed).

But what the heck. ... It’ll only happen after 497 days (which I typoed throughout the “smackdown” version of this diatribe as 479!).

Linux clock()

And then there is a Linux library function clock(), of which http://www.die.net/doc/linux/man/man3/clock.3.html says

The clock() function returns an approximation of processor time used by the program. ... If the processor time used is not available or its value cannot be represented, the function returns the value (clock_t)-1.

which pretty-much guarantees the return value can be -1 on odd-numbered Tuesdays — and no nonsense about errno! ... Since the clock() and times() functions are sort-of in the same bailiwick, I take this as an argument against my recently new-found faith in the times() function’s likely behavior. On the other hand, the same document carefully notes “the time can wrap around”. ... My guess is clock() never returns -1 either, but its story is more ambiguously wrong, compared to times(). ... (Incidentally, blame not www.die.net; they present the documentation in a handy format, but the same stuff appears at many places on the web with practically the same words.)

And it’s all just guessology — also known as the Linux documentation science! ...

Source as Documentation

Well really what the Linuxoids think, is that real programmers’ll go to the source to find-out how things work; that is, the source is the documentation. ... This is one of those extremely stupid ideas that demonstrate that even really smart people like kernel hackers can be idiots. ... (Indeed later I got hold of the source and couldn’t find the times function — in the standard OwenLabs several-hours stupid documentation maximum allowed period.)

Mea Culpa⁴

I mustn’t leave this topic without noting that after reading the Crenshaw column, I vaguely recalled I had been bad somehow on this — and checked into my very own OwenShow: the sin I found there was not, of course, misusing GetTickCount(). ... No, since there’s no GetTickCount() in Linux, I used DateTimeToTimeStamp(now), a Delphi thing that supplies the current date/time with a high degree of (apparent) precision in Windows or Linux.

Unfortunately, I used it wrong. ... But whatever, it’s a bad solution no matter how I used it: instead of waiting for 49.7 days or 497 days to exhibit my incompetence, OwenShow could’ve hiccuped whenever the user set the date/time! ... And this is no idle menace; judging by some kernelish chit-chat on the web, some guy’s Linux MP3 player was unhappy because of this situation! ... So I “fixed” the next version of OwenShow by using GetTickCount() in Windows and times() in Linux — correctly, or at least as correctly as I know how, so it’ll never fail....

— Monday, April 24, 2006 10:09 am

__________________
NOTES

1. Actually I recall using a spare UART to ingeniously provide timing; you’d set it up just right, send a meaningless character, and check for TXEMPTY. To be sure, this was hardly portable either.

2. Floating point numbers are handled with entirely different mechanisms. ... I should also note that this undoubtedly makes even more mysterious sense in binary notation, i.e.,

1111,1111,1111,1111,1111,1111,1111,1111 + 0000,0000,0000,0000,0000,0000,0000,0001 0000,0000,0000,0000,0000,0000,0000,0000

See, the 1 provokes a carry in all the bits. ... This is like the old mechanical adding machines and comptometers, where you could fill the thing with 9s, add 1, and produce zero; same trick. Indeed, old comptometers have 10s-complement markings on them, for doing subtraction.

3. The other times() returned (in a structure passed to the function) might be more vulnerable because they might count faster — so they could be the source of error also, and this is noted on the web somewhere I forget. ... Without, you understand, explaining anything about what times() might return....

4. I fully expect my insightful thoughts to be lambasted by some Linux know-it-all. Actually, so far that’s the only way I’ve found of eliciting information from the caring feeling cooperative Linux community, q.v. ... And, of course, that’s what happened here! ... Owen still scores, in a perverse way....

5. Actually I chickened-out; I have OwenShow zero errno before the call to times(), and if the return value is -1 and errno is non-zero, allow the user to ignore the error, and mention that if he sticks a file with a particular name in the OwenShow program directory, it’ll never happen again. ... Of course if Linux ever actually does this, OwenShow and anyone who uses times() is probably sunk.

Linux Docker?

I’ve been vaguely following this from afar, and then Linux Format had an interview with “Mr. Docker”, which I found utterly unintelligible. But I think I’ve guessed the secret.

You see, Linux is so EZ-to-use, so superior to that despicable Windows or even the Mac, that the only way to get a “program” — a separate piece of software you might want to use — is if it’s included in the original Linux “distro”, the huge pile of software which Linuxoids must use to get hold of the wonderful free FOSS OS, comparable to a Windows installation except that the Linux thing also typically includes all the free applications you’d want — or it better, because that’s the only way a typical innocent user can get any applications.

Historic & Modern Fiction

For years the Linux puffsters — i.e. ever single living thing and many dead anywhere on the web or in print, excluding me — “solved” the problem by denying it existed. ... Then, it turned-out a wonderful thing called a “package manager” could install programs that didn’t come with the distro — if you got them from the distro’s web “repository”. ... And I do not speak in idle disparagement; I’ve tried installing programs in Linux, and almost always encountered something which the insider experts used to playfully refer to as “dependency hell”, where the install would complain that important libraries were missing, and I’d download the important libraries, and then it’d say something else was missing, etc. And very likely by the time I was through, numbers of other applications wouldn’t work anymore, if not the entire crate. And the package manager system did alleviate that somewhat — each specific to its distro of course — the only problem being that independent software guys didn’t necessarily package their treasures in appropriate package managers for all the wandering Linices....

Docker Murk

I believe this supernatural “Docker” product is a virtual application container thingey that lets an innocent Linux user install Docker-prepared programs into any Linux system without the distro having to compile it ahead of time — assuming it’s a recent-enough Linux. ... The murk surrounding the subject is, of course, because they can’t admit Linux program installation doesn’t work. ... Tangled web, you know. ... And shockingly, there’s more than one thing with this functionality! So they’ll have to fight....

— the cynical but good-hearted programmer
5/18/15

The Wonders & Marvels of Free Source

My beloved antique Sidekick95 appointment calendar, what I paid for around 1996, for some reason doesn’t get happy in the modern operating systems, and so occasionally I go through a fitful exercise of attempting to get some Delphi calendar components that’ll even get half as good as the intrepid ancient software — which, mind you, still works, it’s just the latest PC installation is always an agony. ... The Delphi 7 calendar component being a little feature-poor, I found myself wandering yet again in the vales of compassionate touchy feeling free software FOSS artisanal practitioners and found, yet again ... nothing works....

1. No EXE? Doesn’t Work....

The first lesson, which I cannot prove but seems to be unutterably consistent, is that if the free software includes no executable — i.e. a program with the .EXE extension that can be run on my pitiful cringing PC — it won’t work. The .EXE’s what we professional software mavens would call a “demonstration” or demo file: something that tells our audience that this stupid pile of junk we’re distributing for free actually does something, or at least did once. I haven’t yet encountered a case where, absent a demo .EXE program, the free source actually worked. ... Of course, the legions of non-working components include some with .EXEs.

2. Acres of Source? Doesn’t Work....

It’s hard to imagine what the children who commit these atrocities think they’re doing. ... I suspect they get some kind of puerile glee out of imagining poor clueless idiots such as myself trying to install this junk somewhere and compile it.

Broken JEDI

My most recent egregious acres o’ source example, which I’ve gone ’round the block with before, is the fabled Delphi “JEDI” now respectably named “JVCL” component collection, whose automatic / manual / any-kind installation fails repeatedly & consistently. And it has no .EXE anywhere amongst its acres of source — well, wait, I lie; the 2015 JVC has 4 or five .EXEs, particularly after I downloaded the “JCI”, some kind of utility package which for reasons unknown to human beings or programmers isn’t part of the JEDI JVC installation and must be installed separately. And the JCI’s installer actually executed and finished without screen-loads of error messages. But none of the .EXEs were anything like a demo, showing-off the incredibly-powerful JVCL’s talents.

And in the 2015 rendition, the JVCL installer only existed in the spiritual form of “JVCLInstall.dpr”, a Delphi PRoject file, which wouldn’t compile because, of course, I hadn’t installed the JVCL yet! ... So I am a complete fool, for downloading the JVCL without installing it first. ... And even if I laboriously managed to compile the installer, it’d probably still fail ... but I’ll never know....

Perhaps, I suggest to myself in pitiful supplicating amelioration, if I installed my obsolete 2002 Delphi version 7 in a vanilla new installation @ all the “default” directories — normally I do exactly the opposite — the JVCL’d somehow “catch”? ... But I won’t do that; life is too short, FOSS too stupid. ... And the shoddy JEDI was only the amazing glorious last in a series of pitiful alleged Delphi calendar component sources (the JVCL is of course so much more) only two of which contained .EXE demos, and those from 1997 and 2001. I guess the idea of actually compilable code got unfashionable after that. And none of those .EXE-equipped packages actually installed.

... I whine about the component concept elsewhere, but I must say this autumnal experience really confirms my deepest suspicions....

Petulance

Yes, I am petulant. Despite the monstrous generosity of all these kindly striving so-creative and just harmlessly-careless FOSSy geeks, I don’t properly appreciate their resumé-enhancing wizardly wonders — particularly when they don’t work. ... But I suppose I should be grateful that these innocents expose their incompetence in these obvious ways. Much worse would be somehow accidentally getting the exact version of the compiler and the silly calendar that actually worked, and only discovering how broken it was after weeks or months of struggle. ... So thank you, shameless incompetents....

Contrition

So I surrender. I will give-up lambasting these poor innocent component strivers, and component no more forever. Well, a little while, certainly.

— the ever so poignantly-regretful ancient programmer
1/19