Lars Wirzenius: Review, 2005


Thursday, December 01, 2005

Review: The Yepp revisited

This is an update to the initial review of the Samsung Yepp YP-T music playing device I bought in September. On the whole, it has been a very nice device, but there are a couple of problems.

First, it only saves its settings, such as play mode and current track and location in track, when it is shut down normally. If you run out of batter, it doesn't save. Usually this is not a problem, but if you're listening to, say, an hour long interview, it's annoying to have to get to the right place manually after replacing the battery.

Second, the device has trouble with long audio files, at least those of the vorbis persuasion. After I finally reached the end of the hour-long interview, the device froze. Rebooting sort-of worked, but it would freeze again at the end of the file or whenever I tried to use the menus. This continued until I removed the file manually via USB.

Other than that, I'm not complaining.

Saturday, September 24, 2005

Review: Samsung Yepp YP-T6X

Djelibeybi is my new toy.

In preparation for the Quest for Sun '05, I bought a portable Ogg Vorbis player. I happened to see one that was nice and small and fairly cheap, or at least cheap enough not to bust my economy.

Samsung Yepp YP-T6X "Djelibeybi"

In brief: Samsung Yepp YP-T6X, can play Ogg Vorbis and other formats, has 512 MB of space, acts as a USB mass storage device, operates on a single AAA battery, and weighs about 30 grams plus the battery.

For me, Ogg Vorbis and FLAC are the most attractive music file formats. The former makes small files, that still sound good; the latter is lossless, so no quality degradation whatsoever. Both are free, open specifications and unencumbered by patents.

While I can create MP3 files, if I want to, I don't want to, if I can avoid it. Unfortunately, though Ogg Vorbis is free, many portable players don't support it. Finding one that does, and is cheap, is nice. The box even lists Ogg Vorbis as the first file format it supports.

The box did not list Linux as a supported system. Many players require special software to load sound files into the device, and to remove them, which can be a bother for Linux users. This device just acts as a USB mass storage device, meaning that it looks like an external hard disk and managing sound files on it is easy even from Linux. I plug the device in, udev/hal/gnome-volume-manager/Nautilus magic happens and a folder window pops up on my screen, and then I just drag and drop to change the set of music on the device.

All this was not deducible from the documentation on the box, but the nice salesperson at Stockmann, where I bought the device, let me test things. I happened to be carrying my laptop, so I booted it up, attached the USB cable, and it worked the first try. I copied an Ogg Vorbis file onto the device, unmounted, unplugged, and played it, and the device crashed.

Turns out that the device has problems with some Ogg Vorbis files; see's talk page for more information. The device did play something else I put in it, so I bought it, and researched things. I'm now converting all my lowest-quality vorbis files to slightly bigger ones. So far, no problems with any of the new batch. (I do the conversion from the FLAC files I have made of my CDs. No more ripping the same CDs again.)

The device uses an AAA battery for power. I use rechargeables, and one lasts about a day of listening. That's pretty close to the 20 hours the manual promises, certainly good enough. Since the battery is easily switched, and the AAA ones don't weigh much, I should be able to listen to music through me entire quest.

There's only 512 MB of disk space in the model I bought. The one gigabyte version was too expensive, but half a gig should be enough for about a dozen hours of highly compressed songs.

While the thing doesn't weigh much, it is a bit of a bother to carry with you. The cable from the earphones gets easily caught in clothes, door handles, bag straps, and so on. Also, if you don't happen to have a pocket in your clothing, there's no convenient place to keep the player.

My solution is visible in the picture above. I made a little loop out of steel wire through the little attachment ring in the player. Then I taped the wire so that the ends don't stick out, puncturing skin or clothes, and also to keep it from coming undone. Than I hung the player using the loop in a neck keychain, a Debian one I got from Jörg Jaspert at Debconf. The earphone cable is rolled up so it is suitably short. Everything now hangs from my neck, and the cable is short enough that it rarely gets stuck anywhere. (Unless I bow down, but one near accident with an oven and hot food hopefully taught me to be careful.)

The user interface is not great, but for my needs it is quite sufficient. I want it to shuffle all songs and play them forever, and after I've configured this once, I basically only need to adjust volume and play/pause, and those are easy and don't require looking at the tiny screen.

All in all, I am extremely happy about this toy.

Wednesday, February 23, 2005

Review: 1978 perspective on programmer office space

I just read IBM's Santa Teresa Laboratory — Architectural design for program development by Gerald McCue, from IBM Systems Journal, Volume 17, Number 1, 1978. It describes the design process and some of the design decisions made when IBM built its Santa Teresa facility. It is remarkable in two ways: firstly in the extreme care they took to make sure programmers were happy and productive, resulting in things that many later building projects have failed to achieve. Primary among these is private rooms for programmers, with most of them having windows with nice views. I have worked in open offices, with tens of people in the same hall, and they suck. Totally. Yet they are common and new ones are still being built.

Secondly, it is remarkable to see how much the details of the programming profession have changed in 25 years. No longer is it necessary to choose a table based on the size of line printer fanfold paper. Having lots of space for storing printouts, punch card stacks, and other form of data storage, is not a high priority anymore.

A most interesting read, therefore. Recommended.

Saturday, February 19, 2005

Review: Tools for converting DocBook to manual pages

I decided recently that writing manual pages directly in roff markup is too tedious for me. I wrote my first manual page in 1989 or 1990, and have been producing them ever since. I still can't remember all the details, and getting all the formatting correct every time is still boring. So I'd like an alternative; others disagree, preferring to write in raw roff -man, and that's all right.

One of the alternatives is to use DocBook markup instead, specifically the refentry element and its children. I looked at docbook-to-man and saw that it does, indeed, produce manual pages. Writing DocBook markup is still slightly tedious, since elements have such long names, but it is a lot easier than roff. However, I was not happy with the output docbook-to-man produces. So I wrote my own tool.

After I'd written about 380 lines of Python code, I figured that maybe someone else had also written something better than docbook-to-man. I found docbook2man and docbook2x-man. The following is a brief comparative review of the three.

I used a very simple file as input, evince.xml. It is short, and has only the minimal amount of content to actually be useful, but this is good for comparison purposes. Some results:

My conclusion, based on this very small test: none of these three tools are perfect, but docbook2x-man is fairly good, and should be easy to tweak into near-perfection. The other two are clearly less good. In fact, I think they are so bad that they should be removed from Debian, unless further tests show that they can deal with input files that docbook2x-man can't.

I'm shelving my Python program, since there is no point in having a fourth program to do this. I may make some patches to tweak docbook2x-man, however.