< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 35 of 76 ]
From: Michael Leuchtenburg Date: 22:40 on 25 Apr 2006 Subject: Gtk+ keyboard layout handling X has a system to handle keyboard layouts. While it's far from perfect, it functions. If I want to change between two layouts (QWERTY and Dvorak, say, leaving an easy escape to QWERTY for other users of my systems), then I can just bind that to hitting both shift keys at once. Skip forward up the chain to Gtk+. Gtk+ likes to second guess X. If I have both QWERTY and Dvorak available as layouts, it will use the QWERTY keys for all the application shortcuts. Because, after all, Gtk+ knows better than X what the user wants. It's too much to ask it to fucking pay attention to the keyboard change. Dvorak is the default layout? No, no, that doesn't matter. Clearly the user wants to use QWERTY keybindings anyways. After all, everyone uses QWERTY! And Gtk+ shouldn't offer any way to configure it some other way, since it knows what they *really* want. It's not like different users might want different things, after all. Configurability is for wusses, and so is paying attention to what the user configured. SO. MUCH. HATE. Of course, much of this should really be developer-hate, since this is apparently considered to be a feature: http://bugzilla.gnome.org/show_bug.cgi?id=162726 But isn't all software hate really developer hate, in the end?
From: Daniel Pittman
Date: 15:15 on 21 Apr 2006
Subject: gstreamer
Having recently converted a computer used by a family member from
Windows to Linux[1], things have gone smoothly. More so, in fact, than
I expected.
Except in one painful, hateful, evil way. KUbuntu, the distribution
that I chose, is nice -- but it uses the horrible GNOME gstreamer
multimedia infrastructure by default, because that is what Ubuntu do.
Which would be great, except that none of the gstreamer audio output
options work. At all. Except to abort the running process after they
complain about this.
This is especially annoying when a gstreamer based application registers
itself as the first preference plugin for embedded media *without*
showing up on the list of plugins.
So, after hitting that with a heavy rock ^W^W set of preferences for a
while and getting /that/ issue resolved, I try another bit of software
to get downloaded audio working, now that embedded streaming does.
All the options for playing back content use gstreamer -- of course --
is I have the choice of the movie player (no audio device, abort!) or
the iTunes alike music player. (hey, audio. whadaya know?)
Then, gstreamer gets to show more hate: play the audio to verify that
things work, and be happy -- they do. Exit the application. Listen to
the next thirty seconds of audio as gstreamer, presumably, runs through
the decoded buffer in the background and finally exits with the
"something broke" sound. (No error message, of course.)
Whee, plenty to hate there. Next try: switch between tracks, and hey,
nothing is happening. Hit the button to pause playback and, wow,
playback actually starts for no comprehensible reason.
Worse, I /know/ that all of these applications can run reliably, produce
high quality sound without these stupid problems. I have them running
myself, and working without hate.
I just can't apply the fix here, which is to get rid of hateful
gstreamer and use the xine engine instead, because the machine only has
a dial-up modem attached, and 20MB at 3KB/s is a little more than I can
take the time to get through...
In conclusion, let me just say: gstreamer, I hate you. GNOME, you
wretched pathetic attempt to introduce the complexity and inflexibility
of Windows to Linux, I hate you for causing gstreamer to form from the
=E6ther.=20=20
Gah!
Daniel
Footnotes:=20
[1] ...because the other options were having to clean up another virus
infestation, or having to pass on it and let someone else suffer.
--=20
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707 email: contact@xxxxxxxxxxxxxxxxxxxxxx.xxx.xx
From: Aaron J. Grier
Date: 08:08 on 13 Apr 2006
Subject: dump
mt(1) can't differentiate between an unloaded drive and a drive which
has a tape in it but hasn't been ejected yet. maybe this is a hardware
limitiation. I can understand that.
I've got a tape changer. I've got control over it via chio(1). it
works great. I can load and unload tapes from slots and drives. it
blocks if the picker is busy, as desired. however, dump(8) has no way
to integrate with chio(1), other than prompting for the next tape:
DUMP: Is the new volume mounted and ready to go?: ("yes" or "no")
all the IOCTLS exist to completely map the availability of an additional
tape in the library, yet dump has no support for them.
"-e" ejects a tape when a change is required, but since we can't
differentiate between an empty drive and an unloaded drive, this is
useless.
"-l timeout" ejects a tape and waits for the drive to be available
again, "to be used with tape changers which automatically load the next
tape when the tape is ejected." which doesn't apply here, since the
changer isn't of the autofeeding variety.
to get this working as desired it seems like I need to write a wrapper
around dump which parses its output and makes calls out to chio to do
tape changes when necessary.
there's got to be a less hateful way.
From: Chris Nandor Date: 22:34 on 12 Apr 2006 Subject: Safari Sampling In most Mac apps, cmd-shift-s means "Save As ...". But in Safari, if you have debugging on, it means "Start Profiling With Sample". So instead of getting a save dialog box, my whole computer froze up while attempting to profile Safari, which was playing a rather large Shockwave movie at the time.
From: H.Merijn Brand Date: 15:33 on 12 Apr 2006 Subject: glib causes bloat I just want a 64bit ethereal on HP-UX ethereal needs glib and gtk+ those need pango and atk so far so good. Understandable and OK. But glib does not allow to be configured without NLS, hence requires gettext and libintl, two of the most stupid extentions ever invented to make software portable. --disable-nls should be the default, and supported by every single piece of open source software. There is no fucking guarantee that any of my client systems have either gettext or intl installed, and if the sysadm's are sane, they are not installed. I am left with only two options: 1. Build static libs for gettext and intl so I can use glib 2. Find another utility that does what ethereal does As my customer asked for ethereal, I am afraid I will be stuck with option 1
From: Mike Fleming Date: 23:35 on 11 Apr 2006 Subject: I Hate DNS It's so easy to mis-configure, and so difficult to test. For example, this works: % dig @xx.xx.xx.x we.hates-software.com But this doesn't: % dig @xx.xx.xx.x we.hates-software.com So I may or may not be able to get to this site, depending upon who's DNS server I use.
From: James Green Date: 15:40 on 04 Apr 2006 Subject: Wordpress OK, so it's blogging software, which makes it automatically hateful, but someone wanted me to set up a site for them with it, so I figured I'd have a go. Refusing absolutely to show posts in the future (there's not even a config option to override this) is, I guess, not completely insane -- it suits what most of their users will probably want, although it'd be nice to give those of us who want something else another option. So I can live with that, especially since I found a plugin that lets me handle future posts as "events" to be tracked in a calendar, which is what I really wanted all along. So far, so hoopy. But, in possibly the worst bit of UI design ever, it seems that if I want to future-date a post, as well as editing the timestamp, I need to tick a little tickybox on each post, "Edit timestamp." Did it not occur to anyone that, given I already EDITED THE FRICKIN' TIMESTAMP, my intention to edit the timestamp was, perhaps, implicit? I'm not exactly going to do it by accident, now, am I? Wankers. -- James
From: Mike Beattie Date: 03:10 on 27 Mar 2006 Subject: Good intentions that never get followed through... Right, so I've dutifully been quagmired in http://we.hates-software.com/ for the last few days (Was introduced sometime last year, and forced myself then to ignore it till I had the time to read.. :P).. And I feel empowered enough to share with you lovely bitter folk, a Hate of mine that reared its pustule infected head on Friday. So, I live in a part of the world that has a severely Intellectually Handicapped Broadband service. No points for guessing where. Anyway, I've got this 2mbit/128kbit connection at home, that's basically grown from a 24/7 56k modem link some years ago. Some years ago, the 486 firewall with ISA 10mbit NIC's was un-hateful. Now, on the otherhand, I get about 85-90kbytes/sec through this box. Ok, so perhaps I should replace it with something a little more grunty, that can get me the full potential of that 2mbit. Enter one disused "development" Linksys WRT54G. Update the firmware to the latest OpenWRT (RC4, as of Friday, RC5 was released today... *seethe*). "Development", because I'd hacked it to add an SD card slot.. no matter, the firewall could probably do with a little storage for logs and whatnot. Anyway, I have this slightly tempermental, but definitely better than the alternatives, 3com HomeConnect ADSL Modem. 3com, in their infinite wisdom, decided to change the Ethernet frame types for its implementation of PPPoE. This is a whole other Hate that I just won't go into now. (PPPoE on the LAN side, it's an Access Concentrator.. it basically converts the PPPoA ADSL we have here to PPPoE on my side.. just a bridge, doesn't do any login or anything). Oh... and the modified frame type values? 0x3c12 and 0x3c13. Now, I can't imagine why they chose those.... On with the story, less rambling... Ok, so the linux kernel mode pppoe driver, and the pppd plugin to use kernel mode pppoe, don't support these different frame types. Hackery time. Fetch the OpenWRT dev environment from Subversion. Type 'make'. Wait. Wait some more. and some more... ok, done. (download sources for kernel, gcc, etc, etc, build crosscompile environment). Find locations to change frame types, to see if it'll work. Kernel tree - include/linux/if_ether.h. easy. pppd. Hrm.. ok, plugins.. ahh.. pppd/plugins/rp-pppoe/pppoe.h: /* Ethernet frame types according to RFC 2516 */ #define ETH_PPPOE_DISCOVERY 0x8863 #define ETH_PPPOE_SESSION 0x8864 /* But some brain-dead peers disobey the RFC, so frame types are variables */ extern UINT16_t Eth_PPPOE_Discovery; extern UINT16_t Eth_PPPOE_Session; Oh, brilliant! there must be some config options to do this.. that makes it easy! Hunt around... Ok, those variables are only given values in one place, in if.c: /* Initialize frame types to RFC 2516 values. Some broken peers apparently use different frame types... sigh... */ UINT16_t Eth_PPPOE_Discovery = ETH_PPPOE_DISCOVERY; UINT16_t Eth_PPPOE_Session = ETH_PPPOE_SESSION; HATE. HATE, and some more HATE. Ok, I can see the intention is there to perhaps actually do something useful with those values in variables... but honestly, whinging about some "broken" and "brain-dead" peers not using the right frame type values, then half-heartedly having a go at supporting them? Would have been better to just define the bloody values, and not say anything.. *Argh*. Now, this probably isn't the best hate I could muster.. but supposedly I need to be doing this thing called work.. Thankfully I finished battle with the SCO box last week... there's some Hate there, but it's worn off a little now. Mike.
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.
From: Aaron J. Grier Date: 23:38 on 16 Mar 2006 Subject: yay raid controller I've got the following in my vintage late 90s alpha 1000A: mlx0 at pci0 dev 12 function 0: Mylex RAID (v2 interface) mlx0: interrupting at dec_1000a irq 3 mlx0: DAC960P/PD, 3 channels, firmware 2.70-0-00, 32MB RAM AKA the DEC KZPSC. it's a three-channel hardware raid controller, and is wired into a nifty storageworks shelf in the alpha. I saw that it was supported under NetBSD and decided to actually use it. first mistake. switching from SRM to ARC to run the configuration program isn't completely godawful; I had a monitor and keyboard hooked up when I configured and initialized my starter 16GB RAID5. no big deal, it didn't take too long to initialize the array, and the machine wasn't being used for anything yet, so I could afford downtime. second mistake. as old hardware from my alma mater is wont to do, a largish (126GB is large to me) nstor disk tray made its way into my basement. "wouldn't it be great to connect this to my hardware RAID controller?" so I bought the requisite HD68 to HD68 (honda) connectors to wire it up. third mistake. by this point I had moved the 1000A off my desk and into my rack, and given it a proper serial console. I wired everything up, fired up ARC, and... hey... god how awful this is over a serial console. still, I trudged along. fourth mistake. after some missteps involving the internal serverworks shelf being wired to the same channel as one of the external connectors (even though the controller has three channels) and figuring out that the nstor box doesn't need two separate SCSI channels anyway since it only has seven devices, I got everything ironed out and prepared to configure another logical device... it has HD68 connectors but only scans IDs 0-6, I assume since there are only seven slots in a storageworks shelf. I've got seven drives in the array, numbered 0-5, and 8. I don't know why I didn't renumber the last one to 6, but it's not terribly important, since I couldn't create a logical disk over 32768MB in size. so I ended up creating three logical disks; two 32.7GB ones, and one leftover. I should have given up at this point, but I figured I would just concatenate the logical drives together and just deal. fifth mistake? it took FOUR HOURS to initialize the logical disks. four hours of downtime, since the tool is being run out of ARC. oh did I mention that the firmware is too old for NetBSD's mlxctl to use, and I have a sneaking suspicion that if I updated it, SRM probably wouldn't be able to boot off it? (I may still replace the firmware and see what happens.) meanwhile I've got a nice 64bit LSI 53c1010 controller here that I wish I would've used in the first place...
< mari
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
chi >
[ Page 35 of 76 ]
Generated at 10:28 on 16 Apr 2008 by mariachi