Tuesday, September 25, 2007

Is There No Good iPod Software for Linux?

What good is a blog if you can't complain and vent your frustrations to the world? I have a 3rd generation iPod that I won in a raffle way back before anyone even knew what an iPod was really. The only software that worked with an iPod on Linux in those days was gtkpod, and let me tell you, using that software was an incredible exercise in patience. I had about 5 GB of music, and it took about 5 full minutes for gtkpod to display any of my music. Then if you, say, clicked a tab to have it sort by artist name, it was another 5 minutes for it to redisplay the sorted list of music, and you could do nothing else with gtkpod until it was done with that redisplay. It was so infuriating, but for some reason I stuck with it. Once I learned what things would send it off into long periods of unresponsiveness, I carefully avoided clicking on those things and was able to get some music synced up to my iPod. If I ever did accidentally click the wrong thing and send if off into one of its redisplay cycles I would howl in agony.

Most recently I've been using Amarok to interface with my iPod on Linux. My blood pressure has been a lot lower since ditching gtkpod. It has worked pretty well, but had no support for iPod playlists, which was a bit of a bummer. I think they've fixed that now, but for some reason the current version of Amarok for my Ubuntu (1.4.7) just crashes when I try and send files over to the iPod. This bothered me enough today (I don't actually use my iPod much, to be honest) that I tried Banshee. I was impressed. It's pretty slick, and typical for Gnome vs. KDE, much simpler to use than Amarok. I plugged in my iPod and hit synchronize and it hung for a while, then started to synchronize, and then it crashed. It looks like maybe it was trying to encode some random wma files (where did those come from?) so it could copy those to the iPod. That's kind of a nice idea, Banshee, but futile. Is there any way to turn that "feature" off? Poking around in the Preferences I see that the default "Output format" for "CD Importing" is AAC. Um, that's weird. Anyway, there seems to be no option to tell it to just ignore non-mp3 files when synchronizing. There's probably a gconf setting... Maybe I'll try banshee again later.

So, desperate, I actually fired up gtkpod. My stomach started to churn as I had it import my music. It popped up a window telling me that it couldn't import some pdf files, and some text files. I thought that was fabulously helpful. Then, once it imported everything, the moment of truth came. I moused over the Artist column, averted my eyes, and clicked. My blood pressure instinctively rose and I looked back, and gtkpod was just sitting there with my songs sorted by artist. I did it again with my eyes open, and it sorted 2402 songs by genre in the blink of an eye. This was very encouraging.

I plugged in my iPod next, dismissed Rhythmbox (I know there's a gconf setting to make that stop, I just haven't bothered to find it. Can Rhythmbox even write to iPods yet?), and gtkpod couldn't find it. I had to wade through it's messy preferences dialog and tell it that the iPod wasn't in /media/ipod, but /media/BRY'S IPOD (who knows why?). After that it acted like it still wasn't working for a while, but then suddenly there was my iPod, playlists and all. The next test was to see if it would sync up with what's on my hard drive. I right-clicked on the iPod name and say the old familiar array of choices that never quit made sense to me. I tried "Sync Playlist with Dir(s)" and it told me "Nothing was changed." Finally I stumbled upon File->Update tracks from files and it started to act like it was syncing stuff up. While it was doing this I noticed that the box above the list of songs that has tabs for Artist, Album, Genre, etc. doesn't actually list those things in alphabetical order. Very nice. It gave me no indication of how long this syncing process was going to take but was displaying each song name in that status bar at the bottom for about a half second to a second each. How long is 2402 seconds? Well, it didn't take quit that long, but when it was done some new songs that I have on my hard drive but not yet on my iPod where still not on my iPod. I give up.

Tuesday, September 18, 2007

Joel's History of Computing

But then, while you’re sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug, new versions of the browsers come out that support cached, compiled JavaScript. And suddenly NewSDK is really fast. And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things.

I just read this entry from Joel and I laughed out loud. It's funny, but it's also incredibly insightful. In a way, it's Joel's answer to Steve's New Big Language, but much more ambitious in its predictions and prognostications. I like it a lot.

Just for the record, a few of the genius observations from this essay have briefly visited my thoughts. I've pondered the various Ajax user interfaces that are all over the place. I've really been bothered that writing a web application seems to be a major step backwards in development methodologies, not to mention how slow they are. Of course, I never bothered to write these ideas down and develop them like Joel has here. I'm kicking myself now for that. Oh well.

Actually, lately I've been pondering more about whether embedded software will ever be written in a higher-level language than C or C++ (no, I don't really consider C++ to be higher-level than C). I think the real-time parts of firmware will always have need to be optimizable down to assembly to squeeze out every last clock cycle, but there are large portions of firmware that aren't real-time. I guess cell phones are already running Java apps, but if you read Joel's blog entry, you notice that he pointed this scenario out precisely because it's a good example of how badly the Java VM approach works:

You can follow the p-code/Java model and build a little sandbox on top of the underlying system. But sandboxes are penalty boxes; they’re slow and they suck, which is why Java Applets are dead, dead, dead. To build a sandbox you pretty much doom yourself to running at 1/10th the speed of the underlying platform, and you doom yourself to never supporting any of the cool features that show up on one of the platforms but not the others. (I’m still waiting for someone show me a Java applet for phones that can access any the phone’s features, like the camera, the contacts list, the SMS messages, or the GPS receiver.)

So I don't think anything more than simple games are going to be written for embedded platforms in a higher level language like Java. I'm thinking most interpreted languages here, like Python, Ruby, etc. are in that "like Java" group in this scenario (sad, I know). It's going to have to be something that compiles to "native" code (the machine code for your target processor, of course), but still has high-level language features like memory management, and dynamic typing, and all those other things that we love about Perl, Python, and so forth. So let's hear it. What will be the NBL for embedded systems?

Refactoring Firmware

At the behest of Steve Yegge, I began reading the book, Refactoring, by Martin Fowler. Click the previous link and read what he has to say about it and see if you aren't intrigued. That essay, and the fact that my manager had the book collecting dust on his bookshelf, really made me want to read this book.

I finally started reading it this weekend, and even though I'm only 52 pages into it (well, I've taken some excursion into other parts of it, so I've read more like 100 pages), I completely agree with Steve. This is a good book. The writing is direct, concise, unapologetic, and still somehow very friendly. It introduces new vocabulary (new to me at least) seamlessly. There are extensive code examples (yes, you have to read code, Martin doesn't apologize for that either), but the code is fairly simple and you get to witness it becoming simpler before your eyes.

Here are a couple salient quotes to whet your appetite for this book:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (p. 15)
You may be concerned about performance in this case. As with other performance issues, let it slide for the moment. Nine times out of ten, it won't matter. (p. 121)

Some of things he does to clean up code totally made me stop and ask the same question as Steve, "Is this guy insane, or merely an idiot?" Actually, for me it was more like, "Sure this looks good for your desktop software application code, but does any of this apply to firmware?" The more I think about it, the more I think it can apply in a lot of places in our firmware. We have a lot of code that isn't exactly human readable, and I'm pretty sure it doesn't have to be that way. A lot of the refactorings in this book are things we all do here and there anyway.

I have a lot more of this to read, and I need to try some of it out on my code. This probably isn't the last you'll hear about it from me.

Friday, September 7, 2007

Video Game Nostalgia (Shameless Plug)

As I wrote the description for my latest ebay auction, I became awash in a wave of nostalgia. I was about 12 years old when Wing Commander came out, and I felt like quite the l33t h4x0r editing my CONFIG.SYS and AUTOEXEC.BAT to tweak my expanded memory settings and get the most performance out my games. So much fun.

I'm actually pretty loath to sell the game, but my wife really knew how to corner me, "So it's a video game that doesn't even work on our computer? In this big old box? Do we even have a floppy disk drive anymore?"

Actually, I just had a thought. There are emulators for old arcade games, Atari, Nintendo, etc. Does anyone know of a 386 emulator that will let me play old games like this? That would be radical!