From: Sean Conner Date: 10:33 on 28 Feb 2008 Subject: So much hate, spread across so much software, it's incredible It all started some five hours ago with my own hateful blogging software, when the web interface (which is something I rarely use it's so loathsome, but that's my own fault) didn't work. It took me the better part of three and a half hours to track down the actual problem deep within Apache. It seems that the ErrorDocument directives I have break the basic Authentication directives I have. How, I don't know. All I know is that I wasted the better part of three hours tracking down *that* little problem, and thinking I found an actual bug in Apache (you don't say?) I thought I would mention it to the users@xxxxx.xxxxxx.xxx mailing list, despite the knowledge that the first thing out of *their* mouths would be "upgrade to 2.0.61^H2^H3/2.2.6^H7^H8 and try your plea again." Only when I sent my plea to the mailing list, only to get back: > Hi. This is the qmail-send program at apache.org. > I'm afraid I wasn't able to deliver your message to the following addresses. > This is a permanent error; I've given up. Sorry it didn't work out. > > <users@xxxxx.xxxxxx.xxx>: > Sorry, only subscribers may post (#5.7.2) That's odd. Then were do all these messages from users@xxxxx.xxxxxx.xxx that keep filling up my inbox come from? Obviously, I'm subscribed in *some* fasion to the list. Did my email client (mutt) puke and set the wrong from address? The users@xxxxx.xxxxxx.xxx mailing list is sending it to my "spc at conman.org" address, and yes, mutt sent it out as "spc at conman.org", so what is in fact, the problem? Maybe I'm half-unsubscribed? Who knows? Let me subscribe again. Okay, there's the confirmation, let me reply to that. *NOW* let me try sending in my plea. Great, now I get *TWO* copies from users@xxxxx.xxxxxx.xxx. Did I just spam the list twice? I sent a reply to that, apologizing for the double posting (maybe), when I get two replies from that. Okay, what the @#!$#@!#!$ is going on ... An hour later, and I have my answer, only I'm not exactly sure who to blame for this incredible mess. Is it: Me, for not noticing that I was subscribing to the list using not "spc at conman.org" but in fact "spc at brevard.conman.org"? Postfix, for setting a return path of "spc at brevard.conman.org" even though I told it to use a "myorigin" of "mydomain" and not "myhostname"? Ezlml (what Apache apparently uses for their mailing lists) for using the email address in the Return-Path: header and *NOT* the address that appears in the From: header? At this point, I'm pointing fingers and naming names at Ezlml. Why, oh, why, oh, why, would you use the Return-Path: and *NOT* the From: header? Grrrrrrrrrrrr ... -spc (When did this stuff get so difficult to debug?)
From: Sean Conner Date: 02:06 on 19 Dec 2007 Subject: Web based applications wedded to MySQL (SugarCRM, I'm looking at you!) I'm working on an internal project and for reasons that get into business type logic of which I'm not privy to, SugarCRM [1] seems to fit the bill perfectly. Well, almost perfectly. For other reasons that at the time I fully agreed with but now am having a difficult time remembering, we decided against using MySQL [2] and felt that PostgreSQL [3] was the better database engine to use. But SugarCRM wasn't written to use PostgreSQL, but MySQL. "Oh, it can't be *that* hard to port," says I. "SQL is SQL, right?" says I. "PHP has been around long enough to support database engine abstractions, right?" says I. Nope. It seems that to use MySQL, you use a bunch of specific MySQL calls, all prefixed with "mysql_" to do your SQL queries. You open a connection using mysql_connection(), then mysql_select_db(), then mysql_query() to make the actual queries. Using PostgreSQL, it's pg_connect(), which handles both connecting to the actual database engine *and* the database you want to query, then you call pg_query(). The same mess exists for all other database engines that PHP laughingly "supports." Oh sure, PHP does have a database abstraction layer, but if you read up on it [4]: PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features. You should use a full-blown abstraction layer if you need that facility. PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0; PDO requires the new OO features in the core of PHP 5, and so will not run with earlier versions of PHP. Sad to think it took *five @#$!@#$@ major revisions" to get this functionality. Even sadder to think that PHP, being the "scripting language du jour" that it is, means that applications are pretty much targetted towards a particular version of PHP, and a program that worked under PHP X.Y.Z will typically break in some mysterious way under X.Y.Z+1. So even if I *wanted* to use PDO, I can't becuase SugarCRM was written for PHP 4.x, not 5.y. "Okay," says I. "Just change calls to mysql_* to pg_*, with some munging, and it'll be all okay, right?" Well, not really, because any work I do with SugarCRM 4.x will be tossed right out when SugarCRM 4.x+1 is released. Sure, I searched [5] for any work done on porting SugarCRM to PostgreSQL, but it seems that all the work was last done in 2005, with some done in 2006 if you search hard enough [6]. The guys working on SugarCRM pay lipservice to the notion of supporting other database engines than MySQL [7], but as you read up on this crap, it's clear they don't want to even think about this issue [8]. But I find a version of SugarCRM that has been ported to PostgreSQL. It's not the latest version, but it's *a* version and it appears to even work. Until the other day [9]. Apparently, there's a 3k character SQL query generated by SugarCRM that PostgreSQL doesn't like, which disabuses me of any notion that SQL is SQL is SQL. Apparently, PostgreSQL requires the use of AS, whereas such a little detail is optional, and some parts of the codebase add it, and some don't. And I apparently hit some less tested parts of the codebase. And the line of PHP causing the error? $result = pg_query($sql); in a function, where $sql is a paramter. I'll spare even more details of what I did because this is getting long, but I will say that the *easiest* fix for this mess, the one thing that I could do to get back on track, was this horrible gross hack of a fix [10][11]: $sql = preg_replace("/\s+\'\s+\'\s+([a-z]+)/"," ' ' AS \\1",$sql); $result = pg_query($sql); And at this point, I don't know where to direct my hate of software---is it PHP and it's serious lack of database abstraction? It's encouragement of shoddily written software with no pretentions of being portable? Is it the SQL parsing of MySQL for making some parts optional? Is it PostgreSQL for not supporting optional parts of SQL? Is it SugarCRM itself for ignoring other databases? -spc (Me? I'm willing to place this purely on PHP's hands, but than again, I'm a programming language snob ... ) [1] http://www.sugarcrm.com/ [2] http://www.mysql.com/ [3] http://www.postgresql.org/ [4] http://www.php.net/manual/en/ref.pdo.php [5] http://www.google.com/search?q=SugarCRM+PostgreSQL [6] http://www.sugarcrm.com/forums/showthread.php?t=20138 yeah, it's dated 2007, but it's JANUARY, 2007. [7] http://www.sugarcrm.com/forums/showpost.php?p=4641&postcount=10 [8] http://www.sugarcrm.com/forums/showpost.php?p=86781&postcount=3 [9] http://boston.conman.org/2007/12/17.1 [10] http://boston.conman.org/2007/12/17.2 [11] http://boston.conman.org/2007/12/18.1
From: Sean Conner Date: 21:40 on 26 Jun 2007 Subject: Installing Firefox should not wipe out /dev Ah, where to place the blame? That is the question ... The situation: I work in a small webhosting company, and in order to cut costs (and boost employee morale) we now all work from home. Or rather, we no longer have to work at The Office. Which is a Good Thing (TM). We have a large physical server (running Linux) upon which we installed OpenVZ, and my "workstation" is a virtual server (also running Linux) running on this monster box. My "workstation" is really only used to check email (I receive root's mail on this box from all the various servers) and to log into certain devices that have restricted access. I can do everything (short of anything requiring physical access to the servers, which is rare) from anywhere I have Internet connectivity. So far, so good. Except for accessing our spam firewall [1]. It's one of the restricted devices, and double plus ungood, the only interface is via the web [2]. Which wouldn't be so bad, except that when I set up my "virtual workstation" I did not install X Windows. At the time, I forsaw no need to install about a bazillion megabytes of crap. If I'm working remotely, I already have all the GUI crap I need in front of me. But recent events at The "Office" [3] require I check the spam firewall on a regular basis. Now, if I'm at home, this I can do. Since I have DSL with a static IP address [5], I can access the spam firewall. If I'm elsewhere (which I am half the time), then I can't. So, today, I decide to install Firefox on my "virtual workstation". That way, I can "ssh -X workstation" and run Firefox there, which has the access I require to access the spam firewall. Silly me, I thought it would be a simple: GenericRootPrompt# yum install firefox Surprisingly, specifying "firefox" to "yum install" actually did what I expected it to---install firefox---instead of bitching about not finding it because it *really* wanted "yum install firefox-pointless-version-numbers-and-architecture-information". But what I did not expect was the process *DELETING* the contents of /dev. Yup. Gone. The whole thing. No /dev. Oh, I didn't find out immediately. No. I first had to try GenericUnixPrompt> ssh -X workstation only to get the bizarre "couldn't exchange keys" or something error---the one that happens when sshd crashes on a connection. Okay, I'm still logged into my "workstation" as root---so just a simple: GenericRootPrompt# /etc/init.d/sshd restart but it failed, saying to couldn't generate some key or other. *THAT'S* when I found out /dev was empty. At least being a virtual server meant that I could do some stupid things to get it working (instead of doing stupid things and locking myself out of the "workstation" were a trip to the Data Center and a recovery disk were required). So ... Who gets the blame here? OpenVZ? Yum? The firefox yum installation script? -spc (oh, and apparently firefox no longer supports the "-no-remote" option [6] ... sigh) [1] An "appliance" from some company. I have no complaint with this device. It does what it does, and doesn't give us much trouble. Our customers, however, do, because they either receive too much spam, or "important" email is filtered as spam, and they keep asking to be added, then removed, from said spam firewall. But that's not a software hate, so I shall speak on this topic no further. [2] Okay, maybe I have one complaint about the spam firewall [1]. [3] Lost messages between three mail servers, one of which is the spam firewall, one of which is another email server we control, and one which is an email server controlled [4] by our customer, which I now have to debug. Joy. [4] They're a Windows shop, but have a token Linux box doing their email. Fun times. [5] DSLi. Static IP address at no extra charge. I love these guys. [6] http://spc.hates-software.com/2007/01/25/73ba6651.html
From: Sean Conner Date: 20:30 on 25 Jan 2007 Subject: Okay Firefox, that's ... interesting. Now cut it out! I'm working remotely today, and I need to log into the trouble ticket system (a web-based interface). Since I am remote, I don't have the trouble ticket system bookmarked or in the history of the Firefox instance I'm using, so I type it in by hand and get a site that I don't expect (a domain squatter). Obviously I didn't remember the URL correctly, but that's not that much of a problem. The system I'm currently using is Linux with X. My computer at work is Linux that runs X. Easy enough, just ssh to my workstation with X forwarding and run firefox. Sure, it might be a bit sluggish, but I can get the URL I need. ssh -X myworkstation.at.work.net blah blah blah GeneralUnixPrompt> firefox And sure enough, Firefox comes up. But ... it doesn't look right. The history shows the site I *tried* going to, and the bookmarks aren't quite right either. And why did the Unix prompt on my workstation come back? It should still be running Firefox. Some testing, and yes, I try to run firefox on my workstation, and somehow the instance running locally is notified to pop open a new window. No, I don't *want* that behavior. I truely do want to run Firefox on my workstation! Don't make me close my local Firefox ... Sigh. I'll close my local Firefox. Only *then* did I get the Firefox I wanted. I specifically use Linux *because* it has a history of not being user friendly and doing *exactly* what you tell it to. This business of being *clever* is disconcerting. I wish it would stop when I wanted it to stop. -spc (I suppose there's some command line option to get the behavior I want, but I certainly didn't see it when I ran "firefox -h")
From: Sean Conner Date: 07:43 on 22 Dec 2006 Subject: Re: perl It was thus said that the Great David Cantrell once stated: > On Sun, Dec 17, 2006 at 09:36:52PM -0800, Aaron J. Grier wrote: > > > this is exactly what I hate about perl. "there's more than one way to > > do it" invariably means that some dumbfucks out there will attempt to do > > it every single way possible in the language. perl apparently prides > > itself on this. > > A general purpose language which can't be used in different ways to > solve different problems is not fit for purpose. Are you proposing that > programming languages should be rigid and unsuitable for a wide range of > tasks? Um ... <raises hand> ... I'd like somethimg a bit more consistent. A typical programic idiom I use (when programming in C) is: if (argc == 1) do_some_process(stdin); else { for (i = 1 ; i < argc ; i++) { input = fopen(argv[i],"r"); do_some_process(input); fclose(input); } } So imagine my surprise when: if (scalar(@ARGV) == 1) { # the one bit of consistancy I can do without actually &do_some_process(STDIN); } else { for ($i = 1 ; $i < scalar(@ARGV) ; $i++) { open INPUT,$ARGV[i]; &do_some_process(INPUT); close INPUT; } } Doesn't work at all. Problem one (remember, I come from a C background here), $ARGV[0] *doesn't* contain the program name ($ARGV isn't right since it's only defined when using <ARGV> apparently---lovely), so okay, I adjust some numbers and it *still* fails because you can't pass file handles to subroutines. Only, it seems like you *can* but only if you use the *obvious* notation open INPUT,$ARGV[i]; &do_some_processing(*INPUT); close INPUT; Never mind the fact that every @#$@#$ variable in Perl is preceeded by a '$', '@' or a '%' *except* for filehandles, diretory handles and block labels. Yes, C has its quirks too, but at least there I can actually pass any type of variable to a subroutine without having a special notation for a certain class of variables. -spc (And least you think otherwise, there's plenty to hate in C, but I'm afraid I've lived with it long enough to subconsciously work around its quirks ... )
From: spc (Sean 'Captain Napalm' Conner) Date: 19:15 on 20 Mar 2006 Subject: The sorry state of i18n This stems from spam, so right off the bat it's hateful. But other than the spam issue, I'm not sure where to place the rest of my hate since it crosses multiple programs across multiple platforms. Now, you may be asking yourself, ``Self, what does i18n have to do with spam and softare hate?'' Glad you asked (even if you didn't). I work at a small web hosting company and even though we're small, we get an insane amount of spam through our network (then again, who doesn't?). We have a dedicated platform (read: commercial, proprietary and expensive) that does nothing but filter for spam---it is, in effect, a Spam Firewall. You point the MX record to this device and it'll scrub the incoming email---blocking from known spammers, letting through the rest but marking on the subect line emails that *may* be spam (and so far, it's never been wrong when it marks an email as spam). So, a message that comes into the Spam Firewall as: Subject: Play longer! Increase your mortgate by 3 inches! if not outright blocked, will be slightly modified to read: Subject: [SPAM] Play longer! Increase your mortgate by 3 inches! I'm the system adminstrator for said small web hosting company, and as such, I have root's mail from each of our servers headed to my account. Which means I get a ton of email---log summaries, mail bounces, problem notifications, what have you. In order to keep from being inundated I've set up procmail to filter and file all my incoming email. So, it was easy enough to setup the following rule in procmail: :0: * ^Subject: .*SPAM.* in-SPAM Never mind the obscure syntax and the difficulty in actually scanning for a literal '['---this works enough to send all spam marked emails to the bit bucket. But I noticed that not all marked spam was being caught. There I am, in mutt, and what do I see in my inbox? Subject: [SPAM] Play longer! Increase your mortgate by 3 inches! That shouldn't be there. Let me test something---I sent from my personal account an email to my work account with "[SPAM]" in the subject line, and lo' it ended up in 'in-SPAM' just like I told procmail to do. Yet I still get Subject: [SPAM] Play longer! Increase your mortgate by 3 inches! What's going on? Suspecting that somehow procmail wasn't seeing the actual subject line, I checked the incoming mail spool file directly and what do I see? Subject: =?ISO-8859-1?B?W1NQQU1dIA==?= =?ISO-8859-1?B?UGxheSBsb25nZXIhICBJbmNyZWFzZSB5b3VyIG1vcnRnYXRlIGJ5IDMgaW5jaGVz?= Aha! [1] MIME crap! [1] I18n crap! [2] With varying degress of support (or non-support in the case of procmail). Okay, so where's the hate? Let's see ... the Spam Firewall? Okay, it's nice that it can decode encoded header lines, but *why* oh *why* does it encode "[SPAM]" if the subject line is encoded? Obviously you can have portions of a head encoded and not all of it. I'm guessing the Spam Firewall vendor can't (or probably won't) fix this because the actual bit that does the rewriting of the subject line is probably some third party i18n library that the Spam Firewall uses and it's not cost effective to "fix" this particular problem, since for most people it's not a "problem" at all. Stupid. Procmail? For not supporting i18n at all? Are there any regex engines out there that can deal with i18n? Does procmail need to be updated to support MIME? Hate. Mutt? Well ... it supports MIME and i18n, but it masked this particular problem for a few days. It's tempting to rip out MIME support from mutt (since I can't stand MIME but that's an issue I have to deal with) but it does make it difficult to deal with the occasional attachment. Perhaps a toggle to flip MIME support on and off ... Agravation. Spam? Well, that's pure hate incarnate. So I dutifully add: :0: ^Subject: =?ISO-8859-1?B?W1NQQU1dIA==?=.* in-SPAM to .procmailrc and get on with my life, until I start seeing Subject: [SPAM] Play longer! Increase your mortgate by 3 inches! in the inbox yet again. What now? Subject: =?UTF-8?B?W1NQQU1dIA==?= =?UTF-8?B?UGxheSBsb25nZXIhICBJbmNyZWFzZSB5b3VyIG1vcnRnYXRlIGJ5IDMgaW5jaGVz?= Sigh. -spc (Actually, I think it was originally encoded in WINDOWS-1251 which is a whole other form of hate ... ) [1] It's actually encoded in UTF-8 in this example---I don't have a full example in ISO-8859-1 but it's close enough to serve for an example. [2] Mostly hateful, but I can see a use for it. [3] Not crap at all, but I'm ranting here.
Generated at 10:25 on 16 Apr 2008 by mariachi