Debian Ramblings

>> Thank you for your message to the Adaptec Customer Service department.
>> Your case # is 000000000005432. (NB: not the real number.)

*ROTFL*  Exactly how many customer requests do they expect to handle?

If the answer is "about 100/day", which sounds somewhat high to me given the above number, then space will last roughly three times as long as the time until this nice planet will die a fiery death in its expanding sun's outer heliosphere.

Maybe somebody was afraid of the Year-100-Billion problem…

…

Sorry about the LiveJournal spam. Apparently they messed up.

I'll move to my own system. Real Soon Now.

Yet another item on the already-too-long list of blatantly unethical behavior by Micro$oft.

This says everything, and should surprise nobody.

So I'm setting up a new web server. It need to be secure (no user A spying in user B's files). It needs to run PHP. Yes, you may run away now. Oh yes, it also needs to be fast...

So how to do that? I'm not going to run Apache+mod_php on the thing. :-/

I've started with Apache2, FastCGI, PHP via FCGI, installed eaccelerator for 60% speed-up.

All of this works reasonably well, except for PHP scripts that want PATH_INFO (like http://.../blog.php/2005/12/03/some_random_gunk). mod_fcgi passes the whole thing's pseudo file system path in PATH_TRANSLATED. The PHP FCGI process checks that path, sees that it doesn't exist (blog.php is a file after all), and immediately returns an unhelpful error.

I've worked around that thing with an ugly hack, but I suspect that the real fix would be to add this same hack to PHP instead.

Opinions, anybody?

NB: Oh, and if somebody could tell me why my mysql server's kernel randomly ignores incoming TCP connections for a few seconds every minute (and yes, it's the kernel), I'd be grateful. I suspect that the solution is going to be "upgrade to something newer than 2.6.12-9-686-smp (Ubuntu Breezy's kernel)"... :-/

NB2: There's also a mod_fcgid for Apache2. Hint: It's crap -- if all FCGI processes happen to be busy, I want new requests to be delayed. I do not want them to be rejected with a terse, hard-coded error message.

Do not read further.

If you couldn't control yourself, do not go here.

If you did, run sudo apt-get remove frotz. Immediately.

If by any chance you didn't, under no circumstances should you open a terminal and type frotz bookvol.z5.

You did? Oh dear. Try not to ... spend ... the rest ... of your ... week ... aarrrggghhh .. too late...

See you sometime later. Much later.

I don't think it's as simple as Jacob Nielsen tells us, but I do think he isn't entirely off base in his latest column.

I'm picking my way through a C++ program (which shall remain unnamed for now), and find myself bemused.

Let's see. There's an interface class A, which has a method to register an abstract class B, which it will subsequently call various methods from. Fairly normal stuff, that.

The program also has C code which looks suspiciously like B's public interface. Since the whole thing is compiled with g++ anyway, I would assume that a reasonable programmer would just slap a class definition around that code, convert the various global variables it uses to proper instances, and be done with it.

What I see instead is a descendant of B that, for each method, calls a C helper, which calls through a bunch of function pointers, which have helpfully been filled by the main program -- with the addresses of the aforementioned code's functions.

Given that the whole program is written in statically-linked C++ anyway, somebody please enlighten me why that approach would make any sense whatsoever. (Actually, given that sort of coding I wouldn't have been surprised if there had been a fourth level of indirection, just for the hell of it.)

In the meantime I'll be busy rewriting it.

You might remember my accident from last month, when my left hand had a close encounter with a glass door.

Well, the problem came back to haunt me. One extracted tiny glass splinter and one un-severed tendon later, my hand is now in a nicely inconvenient cast. For the next six weeks.

Oh yes, and it hurts. A lot.

You may now pity me.

Yesterday I managed to discover dasher.

Basically, it's a way to enter text by just moving the mouse around a bit. I'd almost call it addictive. Try it, you'll hate me. :-)

It's written in C++, which is nice for speed but lousy for easy hackability. So, time to put a Python layer on top of it.

Dasher uses a fast auto-learning predictive algorithm that's already pretty cool in itself, but it doesn't work well for the command line. I wonder how difficult integration with bash3's command line completion would be. Or even "will be".

Now, somebody please give me a month that isn't in the calendar...

Two days ago, a contest between our glass-panelled swinging door and my left hand resulted in a draw.

I got the glass, and then the glass got me.

After a brief ER visit, my hand and wrist are now adorned by seven band-aids and related stuff with too-medical-sounding names.

The main problem, though, isn't the pain, or the damn blood throbbing in my finger. No, far worse: I have to type one-handed for the next two weeks or so.