Lars Wirzenius: February, 2006
Contents
- February 28: DVD ripping with .desktop files, FOSDEM 2006, GNOME Typing Monitor induces housework
- February 27: FOSDEM slides up
- February 11: Device driver check page
- February 06: What kind of DPL?
- February 03: Followup to seven secrets, Secrets of Successful Programmers
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:
- Air travel still makes me feel like I'm treated as cattle.
- Leaving unnecessary stuff (like my laptop) at home was a good idea. My luggage was lighter, and I spent less time fiddling with my computer and more time speaking with people. Or at least trying to, I'm still shy and introverted, so it's hard to strike up conversations.
- I still brought unnecessary stuff with me, like a sweater I never used. It took up a lot of space in my backpack.
- Djelibeybi, the Samsung YP-T portable music device that plays Ogg Vorbis files, turns out to be a really good idea for trips. It's small and light, and drowns out other people's conversations on planes so that I can get some sleep.
- A checklist of all the things I had with me made packing for the return trip a lot easier, since I didn't have to worry that I forgot something somewhere.
- A paper notebook for taking notes in works as well as a laptop, except that my handwriting font is worse than the one in my editor.
- An inflatable neck pillow made my sleeping on the plane almost comfortable, until it stopped keeping the air inside. The "cork" that plugs the hole wouldn't stay inside anymore. There must be a better way for this.
- The pre-FOSDEM gathering in the Roy d'Espange restaurant is a wonderful thing. It's way too crowded and noisy, however.
- Lots of people told me they were sorry to see me drop out of the DPL elections, and that they would really have liked to vote for me. Thanks for that. A few of them spent some energy trying to convince me to not drop out, but had no luck. If you liked my draft of a platform, please try to push ideas from it to the candidates. It's the issues and goals that count, and what actually gets done, after all, not the person.
- Conferences make sleeping difficult. I was tired all the time. Also, I walked around or was otherwise on my feet most of the time, and my feet are really, really sore.
- Jeroen's and Enrico's talk about the DPL team was nice. My main impression, however, was that the DPL and DPL team have mainly concentrated on diplomacy between various parts of the project, and to me, that's an indication that there's something seriously wrong that needs fixing.
- I brought four Debian amulets of glass and tin with me to be sold, and they were all sold, and at least one person was left without. They're made by a Finnish artist/craftsperson, and cost ten euros (though the price may go up a bit the next time), and were not sold for profit. Leena "Droidy" Romppainen arranged for them to be made. If anyone wants one, we could have some more made and I can bring them to, say, Debconf in May. Mail me.
- Holger and Herman recorded talks in the Debian devroom. This is a very nice thing, I can't wait to see mine. It would be ultracool if we could get a setup where such recordings could easily be made whenever Debian people gather. That's a lot of work, though.
- Martin Krafft's talk was inspiring, and gives me hope that he will come up with good things in the future. It was a talk about work to be done, so not yet concrete advice of how things can be done in better ways. Ideas, not experiences, at this stage. The next couple of years will hopefully be interesting.
- My talk seems to not have been disliked. Incidentally, Wouter, I didn't make a conscious reference to Hanna's talk the previous year with the title of my talk, but it might have been unconscious. Or it might just be that we're both infested by Monty Python.
- Hanna's talk was as good as ever. The factoid that stuck into my mind: 80% of the men in the free software world claim they have not seen discriminatory behavior towards women, and 80% of them women claim they have. Also, the distinction of active versus passive discrimination seems to me to be important. The former is usually easy to recognize and deal with, the latter is not. There might be a parallel here to other kinds of abusive behavior on, say, Debian mailing lists.
- Conferences == cool.
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 debian.org 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.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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?
- 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.