Electronic dictionary recommendations

Electronic Japanese-English dictionaries are very popular among Japanese language learners, and the subject of which to buy is a perennial classic as there are constantly newer and better models coming out. Having been through this myself, I thought I’d weigh in.

The last electronic dictionary I had was a Seiko Japanese-English-Chinese one, probably an older version of this model. I tend to like Seikos in general, for no particularly good reason. Anything that has Kōjien (広辞苑, the standard Japanese-Japanese dictionary) and Kanjigen (漢字源, the standard kanji dictionary) is pretty much good enough in my book.

But when that Seiko inexplicably died after only 2 years and I was out ¥30,000 and left with no dictionary, I vowed never to buy another electronic dictionary again. I don’t need portability—pretty much the only time I need dictionaries these days is when I’m sitting at my computer. So I bought the PC version of Kōjien (also works natively on OS X, and on Linux via 3rd party software) and called it a day. Between Kōjien and the various other dictionaries available online, I find that I just don’t need a portable electronic dictionary.

Major dictionaries available online:

• Eijirō EJ/JE
• Daijirin and Daijisen JJ, Progressive EJ/JE, New Global EJ, New Century JE
• EDICT EJ/JE

Not online, but still very useful:

• The suite of JE/EJ, JJ, and thesauruses that come bundled with Mac OS X

I find that I don’t need much else these days, but if I need bigger and better dictionaries then I will likely invest in standalone PC or paper ones.

Ok, what if I needed portability? Here is what I would think about:

• Forget pen input entirely. It’s a waste of time for most kanji, especially if you don’t know the correct stroke orders. The fastest way to search for kanji is search by component name (部品読み検索). Of course this assumes that you know the names of kanji radicals. This assumption may not apply to you, but I recommend learning them if you’re serious about kanji proficiency.
• Kōjien and Kanjigen are the bare necessities for me. Some models substitute Daijirin (大辞林), which I find to be extremely limited in comparison.
• I don’t need color screens, 1-seg tuners, media readers, etc. If I was even remotely interested in that, I’d jump straight to a proper multimedia device like an iPod touch, an Eee PC, or something like that.
• “Bonus” dictionaries like English phrasebooks (とっさの英会話 or whatever), encyclopedias, etc. are also irrelevant to me.
• After considering the above items, the only other spec I really look at is the number of words in the English-Japanese and Japanese-English dictionaries. I don’t have a preference regarding Genius vs. Progressive vs. whatever, but some dictionaries are surprisingly limited.

So, those are my thoughts on electronic dictionaries. My needs are fairly different from the average language learner, but hopefully this will be useful to someone.

PS. I lied. I actually do use a dictionary on-the-go occasionally. It’s the crappy JJ one that came with my AU phone. But it often doesn’t have the words I’m looking for, so I wouldn’t recommend basing a cell phone purchase on this particular feature.

Malware on OS X

A friend of mine recently made the mistake of clicking a seemingly innocuous link sent to her over AIM. As it turns out, clicking the link somehow executed some code that got her machine infected with all sorts of spyware, adware, and other miscellaneous malware. Since this infection required user interaction it would be a trojan, not a virus, but whatever you call it, the result was several hours wasted trying to repair the damage. In the end, System Restore and an application of Adware and Spybot solved the problem.

No, my friend does not use a Mac.

If she did, she wouldn’t have been infected to begin with, since there are as of this date no automatically spreading viruses for OS X. There have been trojans, such as the infamous Opener, and there was at least one proof-of-concept exploit for the now-patched Dashboard vulnerability in Tiger prior to 10.4.2. But other than these things, and perhaps the omnipresent MS Word macro viruses, there’s nothing. Zip. Zero. Nada. Even Wil Shipley and his $500 say so.

Since most people who read my blog are already Mac users, I’m probably just preaching to the choir here. So I’ll cut to the chase: My main point is to stake my claim to being the first person to identify the first trojan for OS X. It was LimeShop, a background process run by LimeWire that apparently would monitor your web shopping and alter cookies so that the authors of LimeWire would benefit from purchasing referrals at sites like Amazon.com. I reported it at MacNN about a year and a half ago. As a result, LimeShop was removed from LimeWire soon afterwards. Go me.

]]>

September Fools

I’d say this would be a great April Fools joke, but April is too far off to wait.

I highly recommend doing this to anyone who:

1. Has a Mac running OS X,
2. Grew up playing video games in the NES era, and
3. Has a sense of humor.

This is the perfect trick: It’s hilarious the first time, but then it gets old really quick. It’s also very easy to do, if you have the OS X Developer Tools installed. Here are the steps:

1. Download MegaManEffect. Play with it yourself a little bit (launch it, then launch any other app) to see what it does. Prepare tissues to wipe up your tears of laughter.
2. Copy the MegaManEffect app to your desktop or wherever.
3. Control-click on the app and choose “Show package contents.” Open the file MegaManEffect.app/Contents/Info.plist. If the machine has the OS X Developer Tools installed, it should open in Property List Editor automatically. Otherwise open it in TextEdit or the plain text editor of your choice.
4. If you’re using Property List editor, click the disclosure triangle next to Root, then highlight Root, and click the New Child button. Enter LSUIElement in the text field under the Property List column. Under the Value column, enter 1.

   OR

   In TextEdit, change the file to look like this near the middle-bottom:

   CFBundleVersion
   1.1
   LSUIElement
   1
   NSMainNibFile
   MainMenu

   Then save and quit. What this does is make the app a background app—when launched, it won’t show up in the Dock, the command-tab app switcher, or the force quit window.

5. Now we need to prevent the window from showing up. Open the file MegaManEffect.app/Contents/Resources/English.lproj/MainMenu.nib. It will open in Interface Builder. From the Tools menu, choose Show Inspector if it isn’t already on the screen. Select the app’s main window and uncheck “Visible at launch time” in the Attributes section of the Inspector window. Save and quit.
6. Copy your modified MegaManEffect app to your victim’s Users/Shared folder.
7. To be really evil, rename the app to .MegaManEffect.app to make the file itself invisible. You’ll have to do this from the Terminal:
   

   cd /Users/Shared
   mv MegaManEffect.app .MegaManEffect.app

8. And now for the most beautiful part: Make the app a login hook. That’s like a Login Item, except that there’s no GUI to access login hooks, so your victim can’t easily turn this off. Plus they can take effect for all accounts if you so desire. Enter the following in the Terminal all on one line:
   

   sudo defaults write com.apple.loginwindow LoginHook
   /Users/Shared/.MegaManEffect.app/Contents/MacOS/MegaManEffect

   Enter the admin password when prompted.

9. Now either log in and log back out again or, if you want this to take effect immediately, enter again in the Terminal:
   

   open /Users/Shared/.MegaManEffect.app

10. Wait for the hilarity to ensue.

To remove this, do the following:

1. Remove the login hook by entering in the Terminal:
   

   sudo defaults delete com.apple.loginwindow LoginHook

2. Delete the application by again entering in the Terminal:
   

   cd /Users/Shared
   mv .MegaManEffect.app MegaManEffect.app

   Then drag the now-visible app to the trash as usual.

I did this to my brother a while ago, and I can confirm that it is hilarious. I could hear the music every time he launched an app from across the hall in my room. If you’re reading this, Seth, it was I who violated your iMac. Mwahahaha!

Update Wed Sep 28 22:40:38 CDT 2005: Seth’s response:

FUCK YOU

Downloadable formats

I wasn’t sure what to call this topic. Software delivery vectors? Software download file formats? Anyway, what I want to talk about is form a piece of software is in when you download it.

First of all, why is software put into some special format for transfer? There are a couple reasons.

1. To save space. Back in the day, the difference between 10 KB and 1 KB was massive. If you don’t want to wait all day for your several-hundred-baud modem to download that text file, or if you want to squeeze the most out of your several-hundred-KB floppy, compression is your friend.
2. To bundle files together. Include a readme or a license file with your executable. There’s nothing like good documentation that people never actually read.
3. On the Macintosh platform, data can be stored in both the regular data fork, and another fork called the “resource fork.” Other platforms mostly don’t have such a concept, so when travelling over the internet you need to make sure all your data is in the data fork. Compression formats do that. (Note that, for instance, OS X’s built-in zip compression scheme has special extensions to handle resource forks.)

In dealing with these things, it seems like things went from complicated to simple to complicated. Way back in the day, most people didn’t have things like Stuffit, so a lot of things were distributed as self-expanding archives. It was basically an executable that would decompress an attached data payload. But you couldn’t count on everything to be in this format, so you were often caught in the chicken-and-egg problem of “I need Stuffit, but the download of Stuffit is stuffed, so I need Stuffit to download Stuffit, but…”

Then Aladdin (now Allume; what idiot came up with that name?) wanted to entice people to shell out for Stuffit Deluxe, plus handing out executables with your compressed data is inefficient, so they managed to get the free Stuffit Expander bundled with all Macs. That ushered in the Stuffit era, where pretty much everything for Mac OS was delievered in .sit, or later .sitx, files.

But why should Allume get to suck the teat of the industry when there are open and more versatile compression formats out there? Apple introduced the Disk Image format late in the life of the “classic” Mac OS, and in OS X it has become the preferred method of software delivery, with the built-in zip solution coming in a close second.

Disk Images are interesting beasts. It’s basically a file with a filesystem inside it, that gets mounted as a virtual disk when you open them. They can be fixed in size or expandable (“sparse” disk images), compressed or uncompressed, encrypted or unencrypted. They support interesting features like the ability to display a license agreement before mounting, where disagreeing will prevent the image from being mounted. There’s also the “internet-enabled” feature by which a disk image’s contents will be copied out and the image thrown away upon opening it. Since the result is basically a disk, developers can do cute things like setting custom background images to make things pretty or give instructions like “drag to the Applications folder.” In short, the .dmg (or .sparseimage) format is pretty nifty.

So how do developers manage to ruin it? They zip or gzip the disk image. This means that when I download such a beast, first I have to unzip it, and then I have to deal with the disk image. Why not just max out the disk image’s internal compression setting? That way everyone’s happy. The CLI command to do this is:

hdiutil create -imagekey zlib-level=9 -srcfolder $SOURCE $TARGET

I did a little experiment: I took a large text file and put it in a disk image with different compression settings. Then I tried also compressing the disk images. Here are the results:

Clearly, at least for plain text, the best results are given by using the max dmg internal compression and zipping it on top of that. But considering that most people seem to be using the default level and then zipping, the difference between that and max level without zipping is small (about a 10% increase). For the convenience, I think it’s worth it, especially in today’s world of fat pipes and monstrous disks.

]]>

Disrespectful to dirt

I found something great today: A Mr. Sparkle screensaver. It’s hilariously… something.

My only beef with it is the Japanese text in the background. It says 掃くークリーン, which is far from grammatically correct, and was not what the Mr. Sparkle box originally said as far as I could remember. I looked into it, and found that the screensaver author’s source was a Wikipedia article.

First of all, don’t trust the picture in the article, as it’s a very poor reproduction (specifically, the ン is mangled beyond recognition). Check out originals via a Google Image search.

Whoever wrote the caption in that article seems to have completely made it up. Part of the problem is that the original text was drawn very poorly, and most closely resembles ハワーワリーン, which is completely nonsensical. Clearly the second line is supposed to be クリーン, which makes sense for this context. Taken separately, the first line is probably パワー, but the animators forgot the ° and drew the ワ identically to the ク. If you have a lot of faith in the animators and assume that they intentionally drew everything as they did, it would be ハクー, which is meaningless and certainly should not be rendered as 掃くー.

In short, it probably was supposed to be パワークリーン.

Incidentally, the correct Japanization of “Mr. Sparkle” would be ミスタースパークル, not ミスタースパーコル.

]]>

Monitoring an NSTask subprocess

Work on the Cocoa port of iPodBackup has slowed a bit lately since now I’m back at school. I did finally implement something nifty the other day, though—the progress indicator tells you what rsync is doing as it’s running.

I had some trouble getting this to work at first. I found some tutorials on monitoring NSTasks, such as this one at CocoaDevCenter. But there are some big problems with the approach they use:

1. Polling is inefficient. Rather than asking “Are we there yet?” over and over again, just wait until your parents tell you “We’re there.” With polling I found the app taking way too much CPU time.
2. As they note, AppKit is not threadsafe. That means you could have unexpected problems, though I’m not really sure what they’d be.
3. There were strange drawing artifacts in the NSTextField I updated with each poll. This probably could have been fixed by slowing the polling down, but then you risk missing some output.

To be a bit clearer, the task at hand is the following: Capture output from a background process and display it onscreen as the process is running. Doing this can be accomplished efficiently and elegantly by using notifications. Here’s how:

1. Register your application controller or whatever to receive NSFileHandle’s NSFileHandleReadCompletionNotification:
   

   NSNotificationCenter *center = [NSNotificationCenter defaultCenter];
   [center addObserver:self
   	   selector:@selector(myMethod:)
   	       name:@"NSFileHandleReadCompletionNotification"
   	     object:nil];

2. Set the output of your NSTask to a pipe:
   

   NSTask *task = [[NSTask alloc] init];
   NSPipe *pipe = [[NSPipe alloc] init];
   [task setStandardOutput:pipe];

3. Get a file handle from the pipe and start the monitoring process:
   

   NSFileHandle *handle = [pipe fileHandleForReading];
   [handle readInBackgroundAndNotify];

4. Begin the task as usual:
   

   [task launch];

Now when handle gets output from task, a notification will be sent to myMethod:. Attached to the notification will be an NSDictionary containing the output string stored at the key NSFileHandleNotificationDataItem.

The only problem at this point is that readInBackgroundAndNotify is not a repeated thing; it only notifies you once, so in myMethod: you will need to call it again if you want more notifications.

- (void)myMethod:(NSNotification *)note
{
	// Get output string
	NSData *data = [[note userInfo]
                objectForKey:@"NSFileHandleNotificationDataItem"];
	NSString *string = [[NSString alloc] initWithData:data
                                                 encoding:NSUTF8StringEncoding];
	// Put string in a text field
	[myTextField setStringValue:string];
	// Ask for another notification
	if (condition) [[note object] readInBackgroundAndNotify];

	[string release];
}

Additionally, sometimes the task can output so quickly that string is several lines long. If you’re expecting only one line, you can do:

NSString *oneLineString = [[string componentsSeparatedByString:@"\n"]
        objectAtIndex:0];

Update Sun Oct 2 11:16:25 CDT 2005: An additional problem with this approach is that often the NSTaskDidTerminateNotification is sent before the file handle is finished reading data output by the NSTask. I found a great solution to this issue at Cocoabuilder.

A nerd’s valiant struggle

Lately I’ve been learning a bit of Cocoa with the help of Aaron Hillegass’s excellent Cocoa Programming for Mac OS X. The big mystery project I alluded to earlier is actually just a rewrite of iPodBackup. The interface is much improved, but I haven’t figured out a good way to monitor the size of the log file, so it’s not quite release quality yet. I may put it on hold until Apple gets its ass in gear and fixes rsync. If anyone is interested in beta testing what I’ve got so far, please drop me a line.

Just to rehash what I bitch about every time… There are two main versions of rsync for OS X, both so buggy it’s funny and sad at the same time. On one hand we have the version bundled with RsyncX, which has a bug where it can randomly crash and spit garbage into the log file until your hard drive is completely full. This has been reported to the author by me and others repeatedly to no avail.

On the other hand we have Apple’s version bundled with Tiger. This one is not known to go berzerk like RsyncX’s, but it does completely fail for no good reason depending on the details of what you’re backing up. It seems to have something to do with the number of files in the destination. Also, it’s inefficient because it re-copies all metadata every time it’s run, rather than only the changed items.

The result is that I need to provide RsyncX’s rsync as a fallback for all unlucky Tiger users, and implement a check to make sure the log file doesn’t explode. Things would be so much easier if Apple and the RsyncX guys would just fix their damn software. Write your congressperson.

]]>

Thank you

I’ve received some very generous donations recently, one of which was sent anonymously. Since I can’t contact that person directly, I’d like to use this space to say to him or her, as well as everyone else that’s donated:

Thank you very much for your support. It makes me very happy that people use and enjoy my work. I hope whatever it is you donated for will continue to fit your needs in the future.

I’m currently working on a Cocoa project that I might make shareware. If I do make it shareware, everyone who donated, as well as everyone who contributed localizations or icons to any of my current software, will be given a complimentary license. Stay tuned to find out what it will be!

]]>

Tiger frustrations

I recently upgraded to the newest version of Mac OS X: 10.4, a.k.a. “Tiger.” Aside from the complaints I listed before about rsync, I’ve had a lot of problems with Spotlight.

Even after leaving my computer on all night for Spotlight to index my drives, I find that the mds and mdimport processes will randomly launch and take up all of my CPU. This occurs even if I haven’t mounted any disks or even done a Spotlight search recently. I also often find LAServer eating whatever CPU mds and mdimport will leave it.

While this is happening, my system slows to a crawl, and Spotlight refuses to give any results for anything, even files that I know exist. While Spotlight is thinking, the menubar and Dock are completely unresponsive. Also seemingly related is the phenomenon where Open File dialog boxes will freeze for over a minute when selecting an item. And often nothing happens when I try to add an item to the “do not index” list in the Spotlight prefpane.

I’ve also found many other minor bugs, like misbehavior when minimizing movies in QuickTime, but this Spotlight stuff is killing me. My computer randomly becomes unusable for hours at a time. Apple, hurry up with 10.4.1!

]]>

Tiger and iPodBackup

I just got Mac OS X 10.4 “Tiger” and I’ve been putting a good amount of time into updating iPodBackup for it. However, I’ve run into some snags.

iPodBackup uses a program called rsync to decide which files to copy and to actually copy them. Prior to Tiger, rsync didn’t understand resource forks, so I had to use the patched version of rsync that comes bundled with RsyncX. That version, however, is quite old, and has some serious bugs. Most irritating is the hard-to-reproduce “exploding log” problem where a file with weird permissions could cause rsync to crash and fill the log file with garbage.

The good news is that Tiger provides a version of rsync that understands resource forks. The bad news is that its behavior seems to be erratic at best. I modified iPodBackup to detect the system version and use the built-in rsync when running on Tiger. In tests I’ve found the following problems:

1. It’s resource-hungry. It brings my 800MHz iBook G4 to its knees when I run it on a decent number of files. The problem seems to be its RAM consumption; CPU usage may not rise above 60%, but the system pages out like crazy.
2. It’s slow. It re-copies the metadata (for a given filename, the metadata is shown as ._filename in the log) for every file, every time, even if the file hasn’t been modified. The slowness may partly be a side-effect of item 1.
3. It’s unpredictable. Sometimes it dies right after “building file list … done” and spits out an error I don’t understand. Sometimes it doesn’t. I really don’t know what the cause is, but my suspicion is that it has something to do with Spotlight indexing.

Other issues to consider: Is Spotlight indexing causing some or all of the slowdown? If so, can one create a disk image whose volume is automatically excluded from from indexing? It seems that the answer is “no,” as one needs to authenticate as root in order to exclude something from the command line. Given the limitations of the app (a shell script run through Platypus), I don’t know how I’d gain root cleanly during runtime.

If you’re interested in testing iPodBackup 1.5, you can download beta 2. You might want to backup your backup if you have room to do so. Also note that although the problems I’ve encountered so far are mostly performance-related, I can’t guarantee that it won’t cause your computer to burst into flames. Please proceed at your own risk.

]]>