Lars Wirzenius: February, 2006


Tuesday, February 28, 2006

Random hacks: DVD ripping with .desktop files

I watch movies and other DVDs on a computer rather than by using a dedicated DVD player box. For various reasons, it is more comfortable to watch a movie by first copying it on a hard disk. For example, often vobcopy will be able to rip it even though there are scratches or other errors. Watching directly from the DVD will fail or be painful, because of frequent stops.

The command to rip a DVD is vobcopy -m. I wrote a little script around that that also creates a .desktop file so that I can just double-click on it to start Totem. Double-clicking on the directory opens a new Nautilus window, which is not useful for viewing a movie.

Travel report: FOSDEM 2006

I went to FOSDEM in Brussels for the weekend. I had a great time. Some scattered notes:

Random thought: GNOME Typing Monitor induces housework

I have a tendency to sit statically for too long when using my computer, and this hurts my back. To force myself to have breaks, I use GNOME's Typing Monitor, set at a five minute break after 60 minutes of use. This seems to work fairly well.

An unexpected result of this is that those frequent breaks are a great time to do housework, like putting things in their proper place, wash some dishes, or such. Nothing major, but a little bit every hour makes a significant difference.

Monday, February 27, 2006

Debian: FOSDEM slides up

I'm back from FOSDEM 2006. I had a very nice time, and will be writing a fuller entry about that later; this is entry is to mention that I've made my slides available. I'll be giving an updated version of the talk at Debconf6 in Mexico, so beware if you fear spoilers.

Saturday, February 11, 2006

Debian: Device driver check page

It has been a while since kmuto advertised this: Debian GNU/Linux device driver check page. It is time to advertise it again, I think.

Basically, you paste the output of "lspci -n", and it tells you which hardware on your PCI bus is supported, and by which driver. Very, very cool, and makes it much easier to see what to buy (assuming you can find a store that lets you, say, boot a machine with a live cd).

Many, many thanks to kmuto!

Monday, February 06, 2006

Debian: What kind of DPL?

The nomination period for the Debian Project Leader is on again. This means that the Finnish winter is at its worst, and indeed, as I write this, it is -22 degrees Celsius outside. The sun went down about six hours ago; I woke up quite late, so I only saw half the sunset.

Back in November, while vacationing, I spent some time thinking about what the role of the DPL is, and now seems a good time to say it. The actual work of developing and maintaining Debian is done by package maintainers, translators, a handful of infrastructure teams or other special purpose teams, bug reporters, and others.

It is not the job of the DPL (in their role as DPL) to take charge of the actual development: the DPL is not expected to administer machines, to fix RC bugs themselves, or to make decisions about release management. Instead, the DPL's job is to help everyone else do those things.

If some part of project isn't working well due to resource shortage, or personality conflicts, or other issues, it is ultimately the DPL who needs to facilitate, mediate, or otherwise deal with it. This is not uniquely the DPL's job: any Debian member could step into a situation and help, but the project does need someone whose job it is to do that if no-one else will or succeeds.

Another important job of the leader (again not uniquely) is to provide inspiration. Our leaders in the past few years have provided fairly little of that. I would like us to have a DPL that inspires the project into setting and achieving goals that make us happy and make Debian the best operating system ever.

The important thing is to inspire, not to force, cajole, or otherwise unilaterally decide. Not quite sure now how that should happen. Perhaps the Finnish military saying that "leading is best done at the front" is applicable: an inspiring DPL is one who by his own work, and his own behavior, shows by example what a good, productive member of the Debian development community is like.

A third important job of the leader is to be the project's public face to the rest of humanity. Again, not uniquely, we have other members who are often prominently in the public eye, such as release managers or security people, but the DPL is the main such public face.

And finally, the fourth important job of the leader is to do the tasks assigned to him in the Debian Constitution. These are not daily tasks, but they're important, and these, at least, are uniquely the DPL's domain.

Friday, February 03, 2006

Rant: Followup to seven secrets

My friend Kenneth "Cessu" Oksanen, who has only recently started writing a web log, wrote a response to my previous log entry: YASSSP = Yet Another Seven Secret of Successful Programmers.

I have no further comments on Cessu's list. I think it's a swell list.

Rant: Secrets of Successful Programmers

The Seven Secrets of Successful Programmers article was on reddit today. I found it to be simplistic enough to be inane. Also not particularly good advice in all parts.

For example, the article says that "[m]ost compilers will strip the comments from the executable program". Strictly speakig this is true: there is probably one or two compilers out there that retain comments in the binary code they put out. They're so rare, though, that it is quite utterly pointless to say anything about it. Anyone who needs to be told that comments don't impact performance or executable code size needs a course in basic programming, not secrets about being successful.

"A good indication that you have got the level of comment right: could someone understand what your program does if all but the comments were removed?" I disagree with this: better advice would be "could someone understand the code if you remove all the comments?" It's the code that gets executed and so it is the code that should be used to communicate and not comments, except when code can't be made clear enough. For example: if you write a wrapper around malloc to check that it succeeds, a comment explaining why it is acceptable to just kill the application on failure would be good, and very hard to express with code.

"In particular any code branch (an IF..THEN...ELSE construction) and any code repetition (a WHILE...END WHILE construction) should be indented so that it is easy to see where they start and end." Gee, that surely is a big secret that only successful programmers know about.

"Expect the unexpected and deal with it. Before you open a file, make sure that the file is present." That's not a good way to deal with it. It's a race condition just waiting to blow in your face. The correct way is to attempt opening a file and then deal with an error if it failed.

"Name your variables to aid readability. - - - The key is to be consistent and to be as informative as possible." Packing as much information as possible into a variable name can be a hindrance to readability. Too many people read advice like this given in well-meaning but misguided articles and then go on to name loop variables nElementIndex.

The loop gets more readable if you name your loop variable just plain i. The loop variable is not significant enough to warrant all the attention from a reader that a long name requires. A short name in this context makes it much faster and easier to glance at the loop and see what it is doing.

Obviously names with scopes longer than a (fairly short) loop need to be more descriptive.

Here's my seven secrets of being a successful programmer.

  1. Learn to worship the goddess of simplicity. KISS a lot. This is much harder than it seems: it's more difficult to be simple and good than to be complicated and adequate. Simplicity starts with the specification of the program or system, and needs to permeate the design, and the implementation, at every step.
  2. Pick good tools, and learn them well. You need to know many tools, and know them well, or you'll waste time on doing unecessary things. Tools include software programs, books, algorithms, data structures, and mental models. Learn editors, programming languages, Unix command line tools, and so on. Learn at least three different paradigms for programming.
  3. Learn how to learn and keep on learning. New stuff is invented daily, and you need to keep up with it, or you'll end up as useless as a COBOL programmer doing a web shop.
  4. Develop debugging muscles. This is perhaps the hardest thing to learn, since no-body seems to be teaching it. You'll be spending most of your time doing it.
  5. Learn how to do testing well. Unit tests, test driven development, black-box testing, integration testing, regression testing, test automation, ... There's lots of ways of reducing the likelyhood that code escapes your hands with bugs still in it. It will inevitably happen, but if you know what you do, you can be better than most everyone else. The industry standard for commercial, proprietary code seems to be around 20 to 30 bugs per thousand lines of code; the Linux kernel has less than 1, and is known as a cesspool of bug-infested muck, so surely you can do better?
  6. Learn to write prose well. Then write a lot. If you can't write a README, a manual page, or the specification for your next work project, who's going to know about your great programming?
  7. Oh, you need to learn how to program well as well, and that isn't so easy either. Knowing how to program well merely isn't enough to be a successful programmer.