From: mjinks Date: 01:08 on 23 Aug 2006 Subject: errno=104 Cool. Thanks, that's really helpful. Somewhere along this chain of client<=>middleware<=>server, somebody encountered some difficulty and killed my connection. Well thank goodness they threw an error! An "errno=104"! Now, I wonder who did the throwing? And in what .h file buried deep in whoever's bowels might I find out what an "errno 104" FUCKING MEANS? Sequel: as it happens, client and server in this case are both part of the same package, so it seemed like a reasonable guess to go pawing around in that package's headers. Yay, 53 of them define something as a "104", and of those 53 header files, none has a name with "err" anywhere in it. Lovely. This of course assumes that the numbers in the headers and the numbers reported at runtime are even in the same base, such that my naive text string search is even vaguely on the right track. I mean honestly, numeric error codes, why the hell bother? Why not just die and keep your trap firmly shut so I'll know right away that I'm going to be running two or three different processes inside debuggers, rather than pretending to try to be informative? Oh wait, I get it. Never mind. Loathe, -j
From: mjinks Date: 20:58 on 30 Sep 2003 Subject: does this count? I'm skipping a meeting right now, which some of my colleagues were roped into, because I cannot bear to sit through another 1.5 hour tour of a vendor's web-based application. I know how to use a web browser. I even, believe it or not, know how to fill out forms in a web browser and hit "submit". And I'm bothered by the apparent contradiction between "Oh, we'll make it Easy and Intuitive! We'll put it on the Web!" vis-a-vis "Please come to yet another meeting in which one of our salesdroids will show you PowerPoint [HATE] slides of screenshots of our intuitive, easy-to-use web application so you, idiot, will be able to use the damn thing." And the vendor? Sun Microsystems! Sun "why should Unix provide any usability tools at all?" Microsystems! Sun "we'd really like it if everybody had to pass through US$10,000 worth of LCD training classes before laying a finger on any of our products" Microsystems! Sun "all our employees run our main competitor's OS on their laptops because our own OS is just too damn tough to get any real use out of" Microsystems! Sun "we clearly have no idea how anybody manages to make their way around one of our machines without our help" Microsystems! And the application? An abomination which (Sun thinks) is going to sit on all our machines and send them constant updates on their status, like which particular DSIMM is going to go tits up and cause their half-million-dollar sooper-dooper fault-tolerant megabox to do a hard reset next Saturday night. Automagic! Easy to use! Huge time saver! Huge reliability increaser! Yeah. I'd rather spend my time venting at the hates-software list, thanks anyway. I hates software, and I hates the spawning grounds in which it breeds. Colleague, now on his way in to the meeting I'm boycotting: "They must know better by now."
From: mjinks Date: 20:31 on 30 Sep 2003 Subject: eudora I hate Eudora so much. So very much. And I don't even use it. I hate it because I hate all things that foster and encourage stupidity in computer users, and Eudora does this with a vengeance. Please, Eudora programmers: they are called "mail headers". The whole world calls them "headers". People who don't know what a header is will not bother to make use of a menu option which refers to headers, or they'll try it out to see what it does and they won't be harmed. They do not now, nor did they ever, need an option called, "Blah blah blah". Seriously. "Blah blah blah"? What the fuck good is that going to do anybody? Eudora users can't tell one flavor of "Blah blah blah" from another so why not call them HEADERS? Do you know how stupid it sounds when a tech support person tells somebody to "turn on your 'Blah blah blah' option"? The obvious and inevitable first response is "Huh?" And do you know how stupid I feel when I ask any member of our user community to please send me a copy of a particular e-mail with the headers attached, when I know that chances are pretty good that they're a Eudora user and can't tell a header from a hole in the ground from their Blah blah blah? But I dare not say to them, by the way, if you're a Eudora user, please activate your Blah blah blah option, because that would make me sound like some sort of patronizing idiot.
From: mjinks Date: 07:24 on 03 Sep 2003 Subject: "stone knives and bearskin" they said! ha! This one is minor and picky but it's been smouldering in my guts for years now waiting for the advent of a forum like this one, so. Here's something I hate: File monkeying tools that don't support the same range of expression as the filesystem they shipped with, that the vendor presumably intended them to interact with. Hate, hate, hate. Case in point: find(1) on Solaris. Or cpio(1) on Solaris, depending on your point of view. I'm sure each would blame the other if we asked them, even though the bloody manpage for cpio(1) strongly suggests that the developers intended these two beasts to get along nicely with one another, so let's all hate them again for acting like quibbling, petty siblings. Hate, hate, hate. In case it isn't obvious -- and it apparently wasn't to Sun -- I refer to the fact that you can't use SunOS find(1) to feed a pathname containing a space (legal as sea salt in UFS since heck was a pup!) to the stdin of SunOS cpio(1). For that, you have to use GNU find(1), with a GNU-find(1)-specific option at that, and also GNU cpio(1). Or preprocess that input somehow (How? I dunno, I gave up and punted). Or give up and punt like I did when you find, er, discover that someone who came before was kind enough to equip the system with rsync(1). Ah, rsync(1). I find so little to hate about rsync(1). Somebody help me out here, quick. And no, guilt by association with Samba does not count, though it's a helluva nice try.
From: mjinks Date: 00:01 on 19 Aug 2003 Subject: how can i hate it? i can't even install it. So, I'm the JumpStart gimp in our shop. For those who haven't had the pleasure of hating JumpStart, it's Sun's software for automatically (HA! Ha ha, ha!) setting up Solaris. When it works (ha!), it saves loads and loads of time and even more aggravation. Having set up jumpstart over the past months-and-months, I wonder how many machines we'll have to let it install before we start to see a positive return on the time. But I did not come here to hate JumpStart, nor Solaris, nor any specific chunk of nasty nasty software; rather, I have come to hate an entire class of software: interactive installers which don't offer an automated option of the sort that would let them become part of our happy new JumpStart regime. Case in point: Sun's own "Forte" compiler package, formerly known as Sun Workshop or something else, who knows. Because it simply must have a host-specific license key which is generated from an installation key and some host-specific info, you can't just make a tarball and truck the same installation out to all your machines at install time. Oh, no. You have to drop the distribution media into the box, answer all the happy questions, drop in your installation key, and let it install all the files itself, or it just won't work. Even better: Veritas' NetBackup. A hateful piece of software if ever there was one, NBU had to have an installer of similar hatefulness. Unlike Forte-or-whatever-they-think-sounds-cute-this-week, NBU doesn't require a license key. There's no reason why it couldn't be distributed as netbackup.<platform+version>.<version>.tar.gz, or a SysV-style package, or whateverthehell. But because Veritas is staffed entirely by slope-browed sadists, they made up for this oversight in inconvenience by writing an installation script. The script must be run interactively. Because Bog knows you're not ever going to want to install NBU on every last machine your operation runs, because after all who would ever want to back up all their systems, so what's the harm in requiring hands-on interaction for each and every blasted copy of NBU that your shop sets up? And in those few cases where NBU installation might be a good idea to include in the initial setup of all a site's machines, well, people will just write expect scripts or something, right? I hate expect, so now I'm picking through Veritas' chain of scripts (just one install script? oh how droll! we need a chain of them which call each other!) looking for the point at which they stop collecting silly environmental information (which will always be exactly the same on every bogdamn box we run) and actually frickin' /do/ something. (I already know that, rather than running tar, or cpio, or pkgadd, or any of the other perfectly-reasonable approaches to installing software archives, they call "cp" many, many times on many, many files.) Then I'm going to slice off all the fat and include just that part of their script in our JumpStart setup. It won't work of course. There will end up being some reason why every box we set up must first be JumpStart'ed, then some human will have to sit down, log in, cd to the NBU source directory, run ./install, hit three keys, and go on to the next thing. Meaning that some percentage of our machines will fall victim to human error and won't get backup software at first. I wonder how long before such a machine has a catastrophic data loss before the oversight is corrected. Then there's ipf. I hate ipf, and now that I'm trying to include it in all our automatically-installed machines, I have new reason to hate it even more. Now, if you hate ipf as well, and particularly if you've hated ipf on Solaris, you might wonder why I mention it here. After all, Mr. Reed makes ample provision for distributing ipf as a Solaris package, so what's the problem? "pkgadd -d <file> -a <admin_file> ipf ipfx" and you're done, right? Well you are if you run that command from an interactive shell, sure; zips right on through, never bothers the user to answer any dumb prompt. But run it as part of a script (as in, say, JumpStart) and it dies, with some moron error like "no TTY set" or some shit like that. Other SysV packages don't do that, but who cares? Why on earth would you want to automate ipf installation anyhow? Not like you'll actually want all your computers to be able to filter unwanted network traffic, after all. Maybe it's my fault. Maybe I'm just a luddite who doesn't see the advantage in having more and more Unix software act more and more like Windows software, with individual quirks requiring knowledgeable humans spending their time clicking "OK" over, and over, and over, and over, and over, and over, and over again. I'm learning though. I typed "and over" manually each time, rather than having vi repeat for me, because I'm a get-along-with-others kind of guy, and if that's the trend, then dammit I'm gonna fit in. *fume*
Generated at 10:25 on 16 Apr 2008 by mariachi