Lars Wirzenius: Review, 2005
Contents
- December 01: The Yepp revisited
- September 24: Samsung Yepp YP-T6X
- February 23: 1978 perspective on programmer office space
- February 19: Tools for converting DocBook to manual pages
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.
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 xiph.org'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:
- Using the XML version instead of the SGML version works fine. I didn't use anything XML specific, like empty elements, however.
- Getting the DOCTYPE right is important. I'm not sure what I did is kosher, but at least it shuts the tools up.
- docbook-to-man and docbook2man copy spaces in the input file directly to the output file. In XML, using many spaces should in most cases be equivalent to using one, so the tools should compress them. docbook2x-man gets this right.
- docbook-to-man and docbook2x-man do not convert the name of the manual page to upper case.
- docbook-to-man requires dashes to be escaped in the input file. That is, it requires \- to be typed instead of - to get a dash instead of a hyphen. For pure ASCII output this doesn't matter, but for high quality typesetting or Unicode output it does. However, using roff escapes in XML source is the wrong way to do this. It is better for the tool to do the escaping. There needs to be a way in the XML source to specify a hyphen, however.
- docbook2man produces some spurious empty lines in the output. Some of them result in empty lines in the formatted manual page (as it comes out from the man command). This is ugly.
- docbook2x-man does not fully follow the font conventions described in (Debian's) man(7). For example, in the synopsis, replaceable parts should be in italics (which becomes underlined in terminal output). Also, when referring to the command, boldface is best practice.
- docbook2man puts extra spaces inside the brackets indicating an optional argument in synopsis.
- docbook-to-man and docbook2man format alternative names for an option on separate lines and with empty lines in between. docbook2x-man follows the more common style of putting them on the same line, separated by a comma. Separate lines would be reasonable, but the empty line is ugly.
- docbook-to-man and docbook2man render a ulink element so that both the url attribute and the contents of the element are in the output. If the url is duplicated in both in anticipation of a non-hypertext output format, which is fairly common, the output is quite ugly. The way docbook2man renders this also results in a line that groff has trouble rendering, resulting in a warning. docbook2x-man is more reasonable here, producing the url only once.
- docbook2man invents the date for the page footer. The input file has a date, but docbook2man replaces it with the date when the program is run, and, worse, outputs it in the locale it is run in. In my case, this resulted in a Finnish language date in an English language manual page. Not pretty, and potentially problematic with character sets.
- docbook-to-man(1) does not follow manual page conventions. It uses shell redirections in the synopsis, indicates that command line arguments are optional (they are not), does not capitalize a non-standard section (should arguably use a subsection) nor the "SEE ALSO" section, formats references to other manual pages incorrectly, etc.
- docbook2man produces not only the output file (into a named file, not the standard input) but also the files manpages.links and manpages.refs. This is ugly, to say the least.
- docbook2x-man(1) lacks descriptions of the options it uses, and instead only refers to programs it runs during the conversion. The synopsis uses braces to indicate non-optionality of command line arguments, and uses bulleted lists weirdly.
- docbook-to-man is implemented generic SGML tools and a custom 7000 line C program. docbook2man is shell and Perl scripts, mostly. docbook2x-man is XSLT, mostly.
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.