Category: Geekery

Whew!

I suddenly discovered I couldn’t reach my colo box. It wasn’t answering on any of the ports it’s supposed to be. But I didn’t get any indication that anything was going wrong before hand, and I couldn’t ping the IP one before mine, so I was was hoping it was a problem at Time Warner’s data center and not with my box. I called my colo provider, but didn’t get an answer. Ah good, I thought, ever the optimist, that means they’re working on the problem.

But the minutes turned into hours, and I still couldn’t get through to my box, nor was anybody answering the phone. But after nearly three hours of downtime, mail started flowing again! I could reach my web sites! And the IP one before mine became pingable. And it appears that they didn’t have to reboot my box to do it. My 65 day uptime survives. Yah!

Love: strace. Hate: RedHat

Well, thanks to my second favourite debugging tool (after System.out.println), strace, I figured out what was going wrong in Rants and Revelations » Today’s Java puzzlement.

(Short aside: CentOS is actually RedHat Enterprise Linux with the proprietary stuff filed off. So any changes between versions are RedHat’s fault, not CentOS’s.)

I had a short program I wrote some time ago to print out the names of all the fonts that Java knew about. Today I straced it on my CentOS 4.4 and my CentOS 5.0 machines to see what was the difference. Both machines opened up /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.bfc just fine. And both started opening up various TrueType font files. But what’s that? On the CentOS 5.0 machine, I’m getting ENOENT (file not found) for /usr/share/fonts/ko/TrueType/gulim.ttf. Oh, that’s not good, since I know the installer installs the “fonts-korean” rpm, which is the CentOS 5.0 equivalent of “ttfonts-ko”, which is what I’ve got installed on CentOS 4.4. Oh, but when the geniuses at RedHat renamed the rpm, they also renamed the directory the directory that the TrueType font files go, from /usr/share/fonts/ko/TrueType to /usr/share/fonts/korean/TrueType. And when they did similar renaming with Japanese and Chinese fonts, at least they had the decency to put symlinks at the old locations.

After that, it was a simple matter to copy the /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.properties.src to /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.properties, fix the directory names, and voila, I have Korean fonts.

Now I just have to figure out how to get this into the delivery RPMs.

Today’s Java puzzlement

Does anybody know why my CentOS 4.4 desktop system shows Korean fonts in both native apps (like gvim) and our Java application, but our CentOS 5.0 Theatre Management Systems (TMS) will only display Korean fonts in native apps. Obviously the fact that the TMS displays Korean fonts in gvim proves that the fonts are installed. And the fact that my CentOS 4.4 desktop shows the Korean fonts in our application proves that Java 1.5_011 can do Korean. Although the rpm names have changed, as far as I can tell the same Korean fonts are installed.

Anybody have any clues?

Dear Boss

Three years ago, when I was asked to implement a DocumentCache class in the cinlib, I made a mistake so that first build that had it was actually horribly slower than before it was implemented. Yes, I admit it. But I fixed that problem in the very next build, and it actually did end up being a net gain.

So is it really fucking necessary that every time since then when there the slightest question about cinlib performance, the first words out of your mouth are “can we try disabliing the DocumentCache to see if that fixes it”? I mean, it’s been three years. Give it up, already.

A stupid idea, stupidly done

In amongst my podcasts, iTunes downloaded three “PDFcasts”, two from Make Magazine and one from PilotCast. Of all the ways that people on the Internet have found to re-implement the same basic idea as Usenet, this has got to be the worst. If I wanted content that I had to read on my computer, what’s wrong with a web page? Or better yet, an RSS feed for a web page. Or an email list. Or Usenet.