Lars Wirzenius: Random thought, 2004
- December 28: On burning up money uselessly
- December 09: Wishful thinking
- November 28: End of bitmaps, Where are all the Erics?, Death is depressing
- October 17: Audiences are fun, Job titles
- September 29: On touch typing
- September 28: My "cringe" essay translated to English
- September 25: A short Finnish lecture
- September 19: Find in an editor
- September 08: Mozilla popularity rising
- August 23: Measuring broadband connection uptime
- August 22: Subway systems
- July 26: Necessary computer books
- July 25: Epidemiology
- July 11: One droidy is three minutes
- June 29: Packaging system wars: how boring
- June 26: Stress symptom
- June 12: foo.c:123: Function is too slow
- May 30: Year one
- April 28: Flame wars are attractive
- April 25: Art of computer naming, part 2
- April 01: Search keywords for my pages
- March 29: Art of computer naming
- March 21: On successful revolutions, I hate computers
- March 19: Aircraft fantasies, Typewriter fantasies
- March 04: Most embarrassing way to spend hour
- March 03: Usability in editors
- February 25: Web sites resist link checkers
- February 13: Leanware or only using 1/10000 of your memory
- February 12: Musical revelations
- February 10: Programming language wishlist
- February 09: On being exact
- February 01: Perfect hacking furniture, I'm an artist!, Choosing names is difficult
- January 28: Living with NIHolism, Viruses in the news: Windows mentioned!
- January 12: Linux progress
- January 5: Spam will go away in two years
- January 1: New Year's resolutions, Saying thanks, giving back
Tuesday, December 28, 2004
It is that time of year again when Finns buy fireworks for New Year's Eve. It strikes me that the world would be a better place if they'd give the money to, say, the Red Cross instead. They could use the money right now, after the Indonesian earth quakes and their after-effects.
Thursday, December 09, 2004
I've been engaging in some wishful thinking today, as a way avoid being depressed or panicky. I've been wishing someone would mail me and say they would be happy to pay me to develop one of my pet projects full time. For example, one of the following:
- Enemies of Carlotta, my mailing list manager. It is already nice and works pretty well, but it could certainly be more flexible, faster, it could have a web based user interface for doing some stuff, and so on. The flexibility could come in handy if a site such as lists.debian.org would be converted to use EoC: they have lots of unique needs that it would be nice to be able to implement as plugins, for example. Integration with some of the web archive creaters for mailing lists would be nice. Documentation needs to be written and that will require some research into different MTAs. There's endless hours of fun to be had here.
- Duplicity seems like the beginnings of a nice tool for doing secure remote backups. That is, backups of files to a remote file server (over ssh or ftp or some other suitable protocol) done so that they are encrypted at the local end but the rsync algorithm is still used to avoid using excessive amounts of bandwidth. It seems to me that this would be a cool program to have, but that the current implementation needs some work still.
- General Debian development, helping where I can, instead of maintaining particular packages. Doing code reviews, writing manual pages, fixing bugs, writing tools to help others. This used to be a hobby for me, but I have not been able to much of it in my free time for some years now, and I would love to be able to go back to it.
- Writing a high quality typesetting engine back end that could be used from any number of applications. Something in spirit like "TeX as a library". Fop probably does most of this, but it might be too heavyweight for many applications, and also it is in Java, which makes it difficult to use from most other languages.
I have more ideas (my tinfoil hat isn't keeping them out), especially for smaller projects, but since I don't know any really generous multi-millionaires, I won't bore you with the rest.
Sunday, November 28, 2004
At work, my laptop has a 14 inch screen with 1400 by 1050 pixels, giving a resolution of about 123 pixels per inch. Such a high resolution (that is, pixel density, as opposed to pixel count) makes text and vector graphics look really nice. Bitmap pictures, such as web comics, are giving me a difficulties, however. For example, I find it difficult to read User Friendly at work: the text becomes a bit too small for my eyes. Similarly, photographs displayed on the web become almost thumbnails.
I expect resolutions to go further up in the future. This creates a dilemma: monitors now have resolutions that vary from about 70 to about 130 pixels per inch. That is quite a lot of variability. User Friendly's archived comics are 720 pixels by 247 pixels (the daily ones on the static page are a bit smaller, I think).
|Resolution (ppi)||Width (in)||Height (in)||Note|
|75||9.5||3.3||Common in older/low-end machines|
|90||8.0||2.7||My laptop at home|
|123||5.9||2.0||My laptop at work|
On the highest resolution monitor, the comic is only about 60% of the width on the lowest resolution monitor. No wonder the text can be hard to read.
How much resolution do we need, anyway? Screen resolutions are really far away from what even cheap ink jet printers are capable of. Those are not known for being too sharp.
The limit of human eyesight is probably the best limit. Take the sharpest known eyesight, make the screen resolution be slight sharper than that, and then be done with it.
Even with the current situation, I foresee the end of using simple bitmap pictures for showing information on the web and in applications. For a simple line drawing comic such as User Friendly, using SVG or some other vector format should work really well; it might even use less bandwidth than GIF. If done properly, the image shown on the screen should match or surpass the GIF in quality, whatever resolution the user actually has.
I don't know what this means for pictures that are not easily convertible to vector graphics, such as photographs. Still, something needs to happen.
Many years ago, when I first stumbled on the Internet and Usenet, I repeatedly ran into the Eric Conspiracy. I haven't heard of them in many years now. Did they succeed in taking over the world and now they are so powerful, no-one ever hears of them anymore? I guess I'll know if this log entry mysteriously vanishes.
I seem to have had an accidental break in my log writing. The main reason for this is that I've been thinking about life and death lately, and this has created a weird sort of writer's block. My grandmother died four weeks ago, and that turned my thoughts into sombre directions. Not morbid, I think. I've been thinking a lot about mortality, my own and other people's, and of the transitory nature of most things in general, as well as what is and isn't important to me. Whether I want be remembered after I die. Whether I want to reconsider my decision to not ever have children. That sort of thing.
- Death is depressing. An inevitable part of life, as they say, but a depressing part.
- I still don't want children. If I make any permanent marks on the world, they'll have to be something else. If don't make any, that's fine. It's more important to be happy while I'm here than be remembered after I'm gone.
- I cannot merely be happy and content. Merely being is a source of unhappiness and discontent. I need to do things, pursue goals, get over obstacles, win challenges. Yet I don't deal well with being in physical, emotional, or financial danger for extended periods of time. I need a solid, safe base, but then I am happy to tackle difficulties.
This probably sounds way too corny to everyone else, but that's all right. This process and its results are important to me and I don't really care what others think. My main reason to write this in my public log is so I can look back at it fifty years from now and remember this time, and I don't keep a private diary.
Sunday, October 17, 2004
I've given two talks this autumn, and found that I still like to speak in front of an audience. I haven't done much of that since I stopped being a TA at the university, eight years ago. My first presentation was on Real programming and the second one on The Joy of Human Interaction Over the Internet (or: Developing and integrating free software in a large project for fun and profit). I have put the slides on the web just in case anyone finds them interesting, but beware they do not contain most of my presentation. My presentations tend to contain many words that I don't put on the slides; the slides are meant to support my speaking, not function separately.
Benjamin Mako Hill and Scott James Remnant want fancy job titles. I want either something as simple as possible ("programmer") or much fancier than what those two want. I want something that makes the official title of Nicholas II to shame with simplicity and brevity. In case you hadn't heard, his title was
Nicholas II, by the grace of God, Emperor and Autocrat of all the Russias, of Moscow, Kiev, Vladimir, Novgorod, Tsar of Kazan, Tsar of Astrakhan, Tsar of Poland, Tsar of Siberia, Tsar of Tauric Khersones, Tsar of Grusia, Lord of Pskov, and Grand Duke of Smolensk, Lithuania, Volhynia, Podolia, and Finland, Prince of Estonia, Livonia, Courland and Semigalia, Samogitia, Bielostok, Korelia, Tver, Jugra, Perm, Vyatka, Bulgaria, and other territories; Lord and Grand Duke of Novgorod, Chernigov; Ruler of Ryazan, Polotsk, Rostov, Jaroslavl, Bielozero, Udoria, Obdoria, Kondia, Vitebsk, Mstislav, and all northern territories ; Ruler of Iveria, Kartalinia, and the Kabardinian lands and Armenian territories - hereditary Ruler and Lord of the Cherkess and Mountain Princes and others; Lord of Turkestan, Heir of Norway, Duke of Schleswig-Holstein, Stormarn, Ditmarsch, Oldenburg, and so forth, and so forth, and so forth.
Haven't quite yet formulated something to trump that, however.
Luckily, I don't often need business cards.
Wednesday, September 29, 2004
Rich Burridge over on Planet GNOME writes about his child learning to touch type at an early age. I was about 13 when I learned to touch type, from a book using my father's portable typewriter. It might be the single most useful practical skill I've learned to help me with programming. Being able to type fast enough that my typing does not lag far behind my brain makes me more productive, I think. It also makes it really cheap to throw code (or text) away and start from scratch. If I typed only very slowly and with a high typo rate, I'd be inclined to keep any old code and use lots of cut and paste to create new stuff. This helps improve the quality of the end result.
I guess being able type fast also makes me less interested in fancy editors. For example, I don't want completion for variable and function names, since by the time I would react to a completion cue, I've already typed the rest of the name. My preference is a simple editor that gets the hell out of my way when my fingers are flying.
Of course, I'm not a really fast typist. I might benefit from some training. On the other hand, since I rarely find my brain waiting for my fingers, perhaps I'm fast enough now and could spend the effort on learning something more useful, like French. Too bad I can't get a faster brain.
Tuesday, September 28, 2004
In 2000, as my then-employer moved into new offices, I wrote an essay to the company internal mailing list explaining why I thought it was a good idea to let us programmers work in peace without unnecessary interruptions. The essay, Kammoksu keskittyneen koodarin keskeyttämistä, was in Finnish, except for long quotes that were in English. Today, I translated the rest into English as well. The result is Cringe from crossing a concentrating coder. The title is the best I and a few friends could get to translating the alliterated title.
The essay could probably be summarized as "flow good, interruption bad". It is not revolutionary, but has been useful to me and some friends in explaining to co-workers why we dislike being interrupted.
Saturday, September 25, 2004
I pity people who don't understand Finnish, it is such a nice language, especially for word play. To help them in their plight I offer the following small lecture in the language.
Where English uses prepositions and other helper words, Finnish modifies the word itself. For example, the Finnish word for "house" is "talo". Where English would use the word "into", as in "into the house", Finnish uses a suffix: "taloon". Additional examples:
|into the house||taloon|
|into his house||taloonsa|
|also into his house||taloonsakin|
|he burned also his house||poltti talonsakin|
The Finnish system clearly results in fewer but longer words. Finnish also favors compound words: words catenated from simpler words. The word for "storey" is "kerros", and thus a house with many storeys (floors) is "kerrostalo". Compound words can also be modified: "twenty storey building" becomes "kaksikymmenkerroksinen talo", and "he also burned the twenty storey building, which he owned" becomes "poltti kaksikymmenkerroksisen talonsakin".
These are real, everyday words, not something specifically constructed to make Finnish words seem long. That can also be done: the word for "system for giving a hand towel" could be "käsipyyherullajärjestelmä". Actually, that word is used, but only by the device manufacturer. Real people use shorter versions.
Kiinnostavuustoivotusloppukaneettilisäyspaikkani (or "this is where I should add a note that I hope this was interesting to you").
Sunday, September 19, 2004
Bryan Clark wrote about the user interface of a Find feature in GNOME programs. To me, what he proposes sounds complicated and awkward. There are essentially two levels of find, and that alone makes me feel icky. I'm not sure how to do a good Find in the general case, but here's what I did for my editor.
Pressing Ctrl-F (or selecing Edit/Find) pops up small box at the bottom of the editor window, see below. You can then type in what you want to search for and press enter, and the editing area scrolls to the next match and highlights it. If you want to search further, just press enter. If you want to replace matches with other text as well, press Tab to get to the Replace box and type in the replacement text and press Enter, which then replaces and finds the next match. If you don't need to edit the replacement text, you can keep pressing Enter to replace and find further.
Once you're done, press Escape to close the search box. I could live with some other key closing the search box, as long as it is only one easy key press. Pressing Ctrl-G will always find the next match, whether the search box is open or closed.
This interface does not allow for displaying multiple search results. That's OK by me; what Clark shows would be pretty useless to me anyway. I usually want to see several lines of text surrounding a match.
Wednesday, September 08, 2004
I just had a look at the web statistics (by webalizer) for liw.iki.fi, my web site, for the month of September, prompted by Janne Jalkanen's rant about yet another web site that is Windows+IE only. He mentioned that people are switching away from IE, and I went to check what happens with my site. Here are the top five from July:
|hits||% of total||browser|
MSIE is clearly ahead of Mozilla. The top five from August:
|hits||% of total||browser|
Counting all versions of Internet Explorer together, it still comes ahead, but only slightly. It would seem to me that people really are switching away from IE, and that Mozilla is unsurprisingly gaining from this.
My web pages are not very representative of the general surfing population, of course, since they have a fair amount of Linux material, which is likely to attract atypically many non-IE surfers. Even so, given that IE has always been the most common web browsers among my readers, this change in the trend is remarkable.
Monday, August 23, 2004
Among broadband users, many tales are told about the relative quality of different ISPs. It would be interesting to have fairly reliable statistics of this. Something like this: a distributed project where a few people at each ISP run a statistics gathering program and send the results to a central server, which then makes pretty tables and pictures of them. The clients might do something like try to connect to half a dozen very well known servers around the world (google.com, amazon.com, and similar, probably permission should be asked) and fetch the headers for the front page with HTTP every 15 minutes.
The results should be arranged geographically so that people from all over the world could use the information easily to compare their ISPs.
I'm too busy and too tired to implement this myself right now, perhaps some day. There are all sorts of reliability issues here that need to be thought out: how can you trust a client's report is not faked, for example. If this were to become popular, ISPs would have an incentive to fake things to make themselves look better, or their competitors worse. Of course, if this were implemented and became influental, it would probably mean that ISPs would actually have to work harder to provide good service.
Sunday, August 22, 2004
Four cities. Four subway systems. Four maps. One of these cities is not a multimillion person metropol.
Monday, July 26, 2004
While browsing my hard disk, I found a draft for a page that introduces necessary books for programmers. The idea was to make a list of superb books on topics that any competent general programmer should know. I won't quote the whole text as it is too sketchy, but here's the list of books I and friends came up with:
- Abelson, Harold; Sussman, Gerald Jay; Sussman, Julie: Structure and interpretation of computer programs
- Aho, Alfred V.; Sethi, Ravi; Ullman, Jeffrey D.: Compilers: principles, techniques, and tools
- Bentley, Jon: Programming Pearls
- DeMarco, Tom; Lister, Timothy: Peopleware: productive projects and teams
- Tanenbaum, Andrew S.: Operating Systems
Note that these are topics that every programmer should know. There are, of course, superb books on more specialized topics, such as graphics or Internet protocols, but not everyone needs those topics.
Some justifications may be in order. The first book, SICP, covers the sort of basic and semi-advanced things about abstractions that a programmer needs to understand, as they are used every day.
The compiler book is necessary because pretty much every project requires some amount of parsing. Everyone needs to understand parsing. On the other hand, after one understands how a compiler works internally, including the code generator and the optimizer, it becomes much easier to deal with compilers.
The Pearls book is necessary because it opens up one's mind to think in new ways and to apply common sense to programming problems.
Peopleware is necessary for anyone who has to deal with a programming team. It is particularly necessary for managers, but even programmers need it, if only to understand that work doesn't have to suck.
The final book is necessary because everyone either uses an operating system or writes one, and so they need to understand them. Being able to make one's own operating system is not necessary, but understanding how they work in general terms is.
These books are somewhat old by now, but that's OK. The things they cover don't become obsolete anytime soon, even if there are new developments. That is a sign of good writing: it stays useful for a long time.
We may have forgotten about some books and topics. I'm sure I'll be told about them in short order.
Sunday, July 25, 2004
It strikes me that discussions of computer viruses, worms, and computer security in general might benefit from the analysis and inputs of epidemiologists. They have a mindset and analysis tools for tracking and dealing with problems that affect large numbers of independent hosts and that spread quickly. Some of that should be helpful for computer troubles as well.
Sunday, July 11, 2004
On the IRC channel where most of my friends hang out, there is one person, called Droidy, who is well known to be very quick at finding good information on the web. In many cases it is useful to compare the speed of various information finding methods, and thus I have proposed the following definition:
droidy = the average time it takes for Droidy to respond with the first useful URL
After careful measurements from IRC logs from the past year (helpfully provided by Zds), I have determined that one droidy is 3.0 minutes.
In the future we will be able to say things like "I can find that out, give me a couple of droidys". Very efficient communication.
Tuesday, June 29, 2004
The topic of religious flame wars about packaging systems recently arose briefly in a discussion. I repeated my opinion, which has not changed for years: It's not the technical features of the packaging software that counts, but the quality and integration of the packages into a working whole. Some of the technical features are quite important: e.g., having dependencies or post-installation scripts that are run automatically make many things possible that would not otherwise be. The thing that really matters, however, is that all packages are of high quality and that they work well together. The packages, not the packaging tools.
The Debian policy document is of crucial importance here for the Debian project. When you have a large number of people working together, oral tradition is not enough, you need to write down decisions made about how things should be done.
Saturday, June 26, 2004
I have recognized a clear symptom that I'm under too much stress: I start playing computer games. I don't usually play any, since they tend to be boring, but when I'm having trouble pushing thoughts about work aside before going to bed, I find that playing GNOME Iagno or Mahjongg for a few hours helps.
Somehow I don't think the makers of those programs are very happy about them being used only in desperation.
Saturday, June 12, 2004
In embedded programming especially it is important to avoid excessive time or space requirements. It would be nice if the compiler could check at compile time that a function fulfills its performance requirements. This is, obviously, somewhat untrivial, but perhaps it would be possible in enough cases that it would be useful enough.
Sunday, May 30, 2004
Today is the last day of the first year of this web log. It is traditional to afflict the readership with meta level reflections and some statistics.
The first question about any web log is "Why?". My web log is a place for me to easily publish short pieces of writing on various topics. I have a separate page for longer texts though I note that during the past year I have not added much to that page. This is only partially due to the log: I have also been uncommonly busy and stressed, which takes away any energy I have for writing longer or more difficult pieces.
Sometimes I write to present a thought, or record any achievements, and sometimes I merely want to express my feelings. Especially when I'm feeling really pissed off, it helps to vent it in public, for reasons that are unclear to me.
The second question about a Finnish log is "What language?". I write in English, because many of the people I want to reach do not understand Finnish. I'm also confident that my English is good enough not to limit my expression or style much. My topics are rarely related to Finland, anyway, so I choose to use the Internet what it is best suited for: to connect like-minded people from around the world, and English is the best language for it.
The third question about my log in particular is "Why is there no way to comment entries?". I have a mailing list for public commenting and welcome private mail if you don't want to comment in public. I choose not to have a mini-bbs on my pages, however. Some people have found this to be inconvenient. My log is, however, intended to be my soap box, not a discussion forum and I'm unlikely to want to change this, sorry.
In the past year, I've written about 61000 words. With fairly loose typesetting, that's about 190 A4 pages of text. I know the amount, since I gave a hardcopy to a friend whom I see rarely these days. That's quite a lot of text. I sometimes wonder if I shouldn't write a book or something instead, but then writing a book requires much more concentrated effort. But hey, perhaps I could start publishing a yearly volume of my log on paper?
I can no longer estimate how many people read this log, since it is published via RSS on Planet Debian. Planet Debian seems to have quite a lot of readers, but of course I can't know whether any of them care about my log in particular. I don't really care, however, I'm only mildly curious.
Wednesday, April 28, 2004
I seem to be attacted to flame wars. When I browse Usenet and enter groups I don't regularly read, such as comp.lang.c or comp.lang.lisp, it is the large threads I start reading. These are typically flame wars.
Flame wars can be quite fun to read, if they're waged by intelligent people. The various sides are clearly polarized and by choosing one side, you can jump and down in your chair whenever it scores a point. If your chosen side loses a point, you get to growl and shake your fist at the screen. A bit like watching sports or soap operas, in other words.
When the debate is unintelligent or the issue matters to you, flame wars quickly lose their fascination. It is a bit like a candle flame: as long as it is small, playing with it can be fun. Toying with danger is exciting. If the flame escapes the candle and burns your clothes, the fun stops.
Sunday, April 25, 2004
I received some feedback on my log entry on the Art of computer naming. The entry was mentioned on Debian Weekly News, and at least Wouter Verhelst, Joshua Kwan, Scott James Remnant, Tollef Fog Heen, Martin Schultze, Mauri Sahlberg (in Finnish), and Jesus Climent commented on this theme in their own logs and in some of those, additional people discussed it. Some people mailed me in private. Below is a summary of the themes suggested by others.
- Composers (Mozart, Beethoven, Bach).
- Animals (monkey, horse, elephant).
- Opera characters (Papageno, Carmen, Don Jose).
- Musical styles (rock, blues, folk).
- Gods and mythical characters (Hermes, Loke, Zeus).
- Bible characters.
- Evil fiction characters (Sauron, Zuul, Darth Vaders, Khan).
- Sunk ships (Titanic, Lusitania, Bismarck).
- Tropical islands (Haiti, Aruba, Kokomo).
- Cars (Barracuda, Beetle, Cadillac).
- Clown names (Bozo, Krusty, Ronald).
- Classic computer games (Elite).
- Words meaning boredom or tiredness or which have connotations thereof.
- Stars and planets (Procyon, Rigel, Jupiter).
- Output from pwgen: meaningless word-like strings (yiwaz, vojei, vawad).
- Aliens names (Ripley, Nostromo, Vasquez).
- Lord of the ring characters.
- Muppets characters (Kermit, Piggy, Gonzo).
- Asterix characters.
- Cities (Bern, Wien, Rome).
- Worthy stones (jaspis, karneol, onyx).
- Random Japanese words.
- Whitewater rivers the namer has kayaked.
- Errors (coredump, fatal, mistake).
- States of fear (horror, terror, scare).
- Martial arts (bushido, karate, taekwondo).
A couple of particularly bad ones were also mentioned:
- Adverbs (either, only, maybe).
- Ethernet MAC address.
Interestingly, there is an RFC (RFC 1178 a.k.a. FYI5) with advice for naming computers. It is short, and recommended reading.
Thursday, April 01, 2004
One of the more fun features of
is that it shows some of the search keywords with which people
find my pages. The topmost entries are not particularly
exciting: my most popular page ever is
with Advocating Linux
not far behind. Past the top ten, however, we get to the
In March, people have found my pages with searches such as "free sex" and "free sex new", "big sword big fight", "sex hack", and "better to travel hopefully". I trust that they weren't all by the same person.
Monday, March 29, 2004
Naming computers is half the fun of administering them. Some people prefer to name each machine uniquely, depending on its use and character. Others have naming schemes to make it easier to find many names.
I use two naming schemes. At home, I use names of female Discworld characters: granny, nanny, magrat, sybil, igor, angua. At work, I use names of famous computer scientists for servers. Therefore, our printer is called knuth, our main server for mail and intranet is turing, the big server for running our application is cray, and so on. Workstations do not follow this scheme: everyone gets to name the workstation they use.
In the past, I've heard of many funny naming schemes. There's even been articles in the computer press about them. I just did a quick search for such articles, but mostly I found extremely boring things such as "name of person using the computer", "complicated code revealing location, make, operating system and installation year of machine", or "whatever automatically generated binary garbage Windows offers on installation".
Does no-one else care about choosing names with care?
Well, of course they do, but it seems that mostly only for personal use or in very small organizations. I find this strangely depressing.
Sunday, March 21, 2004
On Thursday this week, over ten thousand Finnish university students demonstrated against proposed changes to laws regarding university studies. I have not followed the discussions and don't know what the whole thing is about. What did catch my interest was that some of my friends were upset about some anarchists trying to advance their opinions on other matters using the big demonstration as a launching pad.
It seems that these anarchists want to make large changes in the Finnish society and think that this can only be done via sudden and radical actions. Trying to subvert a demonstration for their own purpose is one way of trying to do that. I suspect they weren't particularly happy about it, either, as it is nowhere near a real revolution. Demonstrations tend to have pretty small effects, anyway.
In my experience, large changes that affect the whole society take a lot of work and time. Of course the public part of a revolution, which everyone sees and talks about, can happen quickly, but it takes a lot of preparatory work before that can happen. My experience is that of Linux and free and open source software.
It took from 1991, when Linux development first started, until 1998, when the term "open source" was launched, before Linux started to make a large impact on computing. That's about eight years of work by many people. The process of opening up Netscape's source code and marketing the term "open source" took only a few weeks in 1998, as far as the public was concerned. The revolution happened in 1998, but it started in 1991. Or possibly in 1984 when the GNU project started.
Very little of that work was marketing, publicity, public relations, or politics. Most of the effort went into getting things to work, to be useful, to be better than proprietary software. Then, when things were technically of sufficient quality, actual revolution part was possible and even easy.
I think there is a lesson here for anyone wanting a revolution: first spend a decade preparing, then it's easy to get everyone to follow you. If you have done all the work, everyone will want to follow you.
I had a very bad day yesterday. I was meant to build a new home server and firewall machine. The hardware was set up, I only needed to install the software. I used the beta 3 version of debian-installer to install a base Debian system, and everything related to debian-installer went quite well. My ADSL connection was flaky all day yesterday, and this did not make installing things easier. Luckily, I had downloaded the larger beta 3 CD image an earlier day, so I got the system installed despite network problems.
After I had the system installed, with all the DNS servers and stuff as well, I moved it to the corner where my servers live. I did it gently and carefully, but still something managed to break. Now the machine won't boot. The fans and hard disks spin up, but BIOS won't give the boot beep, and the screen shows nothing. The result of a day of tweaking and cursing: a non-functioning computer and a dozen new gray hairs.
I don't think I ever want to tweak computers at the hardware level again. This wasn't the first time something like this has happened, but hopefully if I never touch anything except the keyboard, this was the last time.
Friday, March 19, 2004
When I grow up to be big, I'll have to build myself a Bel Geddes #4 aircraft. I used to want a Zeppelin NT, but the Bel Geddes #4 is so much sexier.
I have a weird recurring dream where I buy a mechanical typewriter, go to a summer cottage, and don't come back until I've written the book that lurks in my subconscious.
That's never going to happen in real life, though. I learned to touch type on a cheapish mechanical typewriter. I can still remember the pain of fingers getting stuck between keys. I suspect that if I ever have to use a typewriter for real again, I'll be a nervous wreck for a week.
Thursday, March 04, 2004
Yesterday, I spent an hour fighting a problem where the a
string in one of my programs would change every time I made
a release candidate tarball. It would be OK in my editor, but
would be wrong in the release tarball. The program parses CVS
$Date$ keyword using
and the pattern string was the one that got garbled all
Okay, you can stop laughing now. It was obvious to me too, after I stopped doing several other things at the same time. I fixed the string in my editor, saved the file, committed it via CVS, which updated all instances of CVS keywords in the file. This replaced the pattern with the time and date of the commit, thereby mangling the string.
Wednesday, March 03, 2004
/bin/ed editor in Unix uses a
single question mark for error message. Legend has it that
the original manual for this claimed that the user usually
knew what the error was (I couldn't find it in 30 seconds
with google, though). It was thus unnecessary to bloat the
program with verbose error message text.
Well, the GNU project is well known for making bloat. Their version has a command to show the error text for the latest error:
Invalid command suffix ← SEE THIS ATROCITY!
Sigh. Where will the world go next? Pretty soon we'll have displays where text is shown as pictures, using as much as a dozen bytes per character! It was bad enough when characters went from 7-bit to 8-bit, slowing down transmissions by 14 percent!
Wednesday, February 25, 2004
I run checkbot on my web site automatically every Monday morning. It takes a while to run and then mails me a report of the links that are broken, moved, or otherwise require attetion. This is quite helpful: checking links manually is tedious in the extreme. Not checking links is an invitation to bit rot.
Lately, an increasing number of web sites seem to forbid
such link checkers, using
robots.txt or other
means. While I can understand the general desire for web
site operators to not have their sites bombarded by spiders
and such, this does make link checking less effective.
I hope it is not going to be popular in the future to do
this. Broken links on the web are not good for anyone.
Friday, February 13, 2004
Embedded programming has many interesting challenges and the most obvious one is that embedded computers tend to be slow and their memories small. They become faster and bigger, though, just like big computers, they just lag behind by over a decade. Those who programmed microcomputers in the 1980's will feel right at home with modern embedded computers.
My friend Kenneth "Cessu" Oksanen is writing an interesting article on leanware. He talks about not being able to use mainstream software and protocols in embedded devices and the way desktop software tends to bloat.
Whining about bloat is, of course, a common thing. As desktop hardware becomes faster and more capable, it is of course acceptable that software uses, say, memory less carefully in order to, say, increase speed of development. Cessu isn't saying that desktop software shouldn't become bigger, but that in order for embedded devices to be interoperable with the rest of the world protocols and file formats and such must be designed with them in mind. And that is a very good point.
Thursday, February 12, 2004
The day before yesterday I realized that my laptop actually has a decent sound card. At least it feels that way now: I plugged my headphones in my laptop for the first time in several months and they definitely sound better than the itty bitty speakers the laptop has, especially since the speakers are located under my arms when I'm typing.
The biggest difference is that now I can hear bass. I had almost forgotten that Metallica isn't a teenage girl band.
Music doesn't just sound better this way, it sounds so much better that it is an almost religious experience. It makes listening to music fun, rather than just something to drown background noise in. Since I can now tell the difference between Heather Alexander's March of Cambreadth and Dinah Washinton's Mad about the boy I have started to actually care about what song is playing. As a result, I've started no less than two playlists today.
The first playlist has "coding music": music that I like to have playing when I'm in a coding frenzy and trying to create the greatest amount of functionality in the shortest period of time. I can't say I'm actually listening to the music then, since I'm concentrating so fully on the actual programming (I am in hack mode or flow). I find, however, that certain kinds of music improves my productivity in this mode: it needs to be fast and heavy and what I can describe as grand. For example, Manowar's Number 1 and Alice Cooper's Poison work well. It doesn't have to be rock or heavy music, the Finnish version of The Internationale by KOM-teatteri works also.
The second playlist has "almostveryperfect" music: songs that I like to listen to when I'm feeling depressed and unsure whether existence is really worth it. Really good music helps then, just like a really good book or movie.
Tuesday, February 10, 2004
I'd like to find a new programming language for general purpose programming. Currently I use Python and I like it quite a lot, but I'm not entirely happy about its performance, and I'd also like static typing. It is good for your mind to experiment with other languages, even if you don't adopt them into your permanent toolbox. Each new language brings with it new ways of thinking about programming and that alone makes learning them worthwhile, and except for Hedgehog Lisp I haven't learned any in quite a long time.
To make the search more concrete, I thought I'd write down a wishlist. Some wishes for the language itself:
- Static typing with type inference (if inference is the word I'm looking for). I don't want to declare the type of local variables, since the compiler should easily be able to figure those out by itself. Declaring types of functions or methods should be enough. Preferably even those should be optional, since small quick-and-dirty programs do fine without any declarations at all.
- Small, simple, beautiful, orthogonal. Few special cases in syntax or semantics.
- Powerful, meaning that it is possible to express complicated processing with fairly little code. A very high level language, in other words: more like Lisp than like C.
- Low level detail available on request. When I do want to manipulate single bits in memory, I want to be able to do it.
- Functional or object oriented. I currently prefer the functional paradigm, but I could live with the object oriented one.
- A module system that scales up to very large programs and also easily allows huge number of third party libraries. Python has this, with its configurable search paths for modules and hierarchical module name space. C has a flat name space and doesn't scale up anywhere near as well.
Some wishes for the implementation:
- Must support a fast edit-test cycle and fast execution, though not necessarily at the same time. Traditionally this has been achieved by having two implementations: an interpreter and a compiler. I don't care how it is done, however, as long as the fast version is at most on the order of 500% of the speed of a corresponding program written in C.
- Easy to link with existing libraries written in C and maybe other languages. This is necessary for GTK+ bindings, if nothing else.
- Packaged for Debian in main. This implies freedom license and a sufficient quality and user community.
- Portable among the computer architectures that Debian supports, even if only in, say, a bytecode interpreter form and not native compiler form.
- Portable among Unix-like operating systems. I don't really care about, say, Windows in this regard, but I don't mind if there is a Windows version as well.
Finding a language that fits all these criteria is not going to be easy. Note that this is obviously not a complete list. I reserve the right to reject any language on whatever grounds I want.
There are of course many languages to choose from, even if you restrict yourself to those that are already packaged for Debian. I'm thinking I should learn a few of them superficially and write some benchmarks to see if they're fast enough. If I choose the benchmarks wisely, the results might be useful for other people as well. We'll see.
Monday, February 09, 2004
I was looking at the scripts I use to produce this log and noticed a bug in the part that generates timestamps for entries. Here is the code:
year=`date -u +%Y` month=`date -u +%m` day=`date -u +%d` hour=`date -u +%H` minute=`date -u +%M`
This is a part of a shell script. It uses arguments to
date command to store the current year,
month, day, hour, and minute to the corresponding variables.
Unfortunately, it can be wrong by a year.
The problem happens when all commands are not run within the same calendar second. If the date is December 31, 2003, and the time is 23:59:59 for the first command, but moves to the next second for the second command, the timestamp will be "2003-01-01 00:00" instead of "2003-31-12 23:59" or "2004-01-01 00:00".
None of this is very likely, of course. It's just a web log. It pays to keep an eye for race conditions, however, if you are a programmer. They do happen in important stuff, and then you might be in trouble if you're not correct. As this example shows, they can also happen even if you aren't doing several things concurrently.
Incidentally, here's the code as I corrected it:
now=`date -uR` year=`date -u --date="$now" +%Y` month=`date -u --date="$now" +%m` day=`date -u --date="$now" +%d` hour=`date -u --date="$now" +%H` minute=`date -u --date="$now" +%M`
We first catch the current date and time, and then extract the interesting fields using that timestamp. Easy, though it may require the GNU version of date.
Sunday, February 01, 2004
After twenty years of programming computers, I've come to the conclusion that the best place for me to hack is sitting in my armchair, with a laptop on a lap tray. It is more comfortable than even expensive office chairs, even if they are adjusted for me by a physiotherapist. It also seems to be better for my back, which I've hurt too many times already.
The only time this chair is not a good place to hack is when I need to refer to paper documentation. Or if I need to use the embedded computers at work (particularly since the chair is at home).
At at friend's birthday party on Friday, I claimed, for probably the first time in my life, that I'm a photographic artist. I don't know if it was pure hubris or not. I don't think I have any real artistic ambitions, I just like to make pretty pictures of people. On the other hand, what little I know of the history of art, that's not uncommon among artists. I guess being called an artist is similar to being called a hacker: it's better if someone else does it to you, rather than you claiming the honor for yourself.
The current Internet toy seems to be orkut.com. I've no idea what the name is supposed to mean, but I know what it means in Finnish. In Finnish orkut is the plural of a slang word for orgasm. I guess it is somewhat appropriate for a service that lets you keep track of the people you know.
Wednesday, January 28, 2004
Hello, my name is Lars and I am a NIHolic.
NIH is short for Not Invented Here. It is a phrase used about the attitude of programmers like me, who think that any code not written by them is not very good. NIHolism is not easy to live with, since you always feel you need to rewrite everything you see. For example, I have written my own editor, mail user agent, mailing list manager, Lisp interpreter, HTTP library, ... The stronger your affliction, the less software by others you want to have.
Luckily, I suffer from a fairly mild case of NIHolism. I do not want to write all the software I use. I have no interest in writing my own kernel, windowing system, desktop, and so on. While my interests in programming are wide, they have limits, and anything outside those limits I am very happy to let others take care of. I generally abhor having to write code that is very close to the hardware.
I have also learned to see when my own efforts are pointless because something so much better exists that it would be impossible to compete. Case in point: I much prefer to use Ximian Evolution rather than my own mail user agent.
Now please excuse me while I go write my own editor. Again.
There is yet another virus attacking Windows machines, and meanwhile also causing trouble to innocent bystanders. What seems to be different this time around is that the Finnish news media actually tends to mention that the virus is specific to Windows. Not always, but usually, in the news items I've read or heard. This is a significant change from earlier cases when the usual reports made the ignorant think that all computers were vulnerable, not just Windows.
I take this to be one more sign of the crumbling mindshare monopoly Microsoft has in matters of computing. Every time a news item mentions Windows specifically instead of talking about computers in general is a win for everyone except Microsoft.
Monday, January 12, 2004
In 1992, Linux was not considered suitable for real use (whatever that meant) by most people, because most things just barely worked. A couple of years later, most things worked, but the general opinion was that they didn't work well enough: networking was too slow, SCSI drivers were unreliable, or something else, depending on who was complaining. Again a couple of years later, these things worked, but Linux still wasn't ready for prime time, because it didn't have the support of this or that major proprietary Unix application (usually Oracle). Yet another couple of years later there was Oracle, but Linux still wasn't any good, because it didn't have a graphical desktop. When it got that, it didn't have office software. After it got OpenOffice.org, we're now told that there's no point in switching to Linux because there are no games.
I think this sounds like progress, don't you?
Monday, January 5, 2004
I predict that the spam problem for e-mail will be solved by the end of 2005. My reasoning is as follows: spam is getting exponentially worse, and it will not take very much longer for it to completely ruin e-mail. As a reaction, things will be done: legislation, enforcement of legislation, techinical measures, and so on. Eventually either most of the professional spammers will have been caught and stopped, or the e-mail system will have evolved technically so that spamming will no longer be feasible.
I'm not sure which kind of legislation is going to be most effective, or which kinds of technical changes are going to work. I fear that they will have unfortunate side effects, such as abolishing the possibility of using e-mail anonymously or preventing you from running your own e-mail server. But perhaps not.
Technical standards on the Internet tend to change pretty slowly. For example, after over a decade of use, there are still e-mail systems that have trouble with MIME. This is because there is not very much pressure to upgrade old systems or fix old software, and instead there is a strong pressure to be as backwards compatible as possible. This is good in many ways.
What spam does is provide a strong incentive to change. Systems that won't change will be flooded with spam and will become unusable and eventually die. The pressure is, I predict, going to be big enough that as soon as a sufficiently good technical solution is presented, it will be months, not years, before it is adopted by the majority of e-mail services on the Internet. Those left behind may well be effectively cut off at the same time.
The only way I can this not happening is if the spammers start regulating themselves: they limit their spamming so that it is barely tolerable, not bad enough to warrant a global change of protocols. I doubt that is going to happen.
Thursday, January 1, 2004
It is a new year. I went to a party at Talo, a commune where five of my friends live. The party was nice, and I only came back home at six in the morning.
New Year's resolutions are of course topical. I have not usually made any, but I thought I'd try this year. So, hereby I resolve that during 2004, I will:
- ... avoid re-reading books, to get out of the habit of only reading books I've read before;
- ... do at least one self-imposed photography assignment per month, to improve as a photographer;
- ... spend more face-to-face time with my friends;
- ... take better care of my health.
If I continue this log a year from now, it will be interesting to see how well I've kept these.
I've read a bit today on the theme of saying thanks or giving back in the free software world. For example, the Advogato article on saying thanks or Kylie J. Veale's article on gift Internet economies.
Veale brings up the very good point that in a gift culture such as the free software world the givers of gifts (those who write the software, etc) need to get something back. For some people, seeing hits on their web site is sufficient: the more hits they get, the happier they are. That's why I get a daily mail with a graph of the hits to my log, for example. It is always rewarding to see the graph jump up after I make an update. That is also almost the only feedback I do get. (I might get more if this log had an online commenting feature, but for various reasons I don't want to add one.)
Dan Connolly, author of the Advogato article, lists several traditional ways to give back in the free software world:
- Contribute code
- Contribute documentation
- Say some nice words
- Add a link to a visible place
These are all good ways, though not appropriate for all. Not everyone can write code, and even writing documentation can be hard, though every little bit helps. Most people are capable of at least spotting typos or pointing out unclear passages.
Saying nice things about a program you use, in a private mail to the developers or in a public place such as a mailing list, a newsgroup, or a web page, is something everyone is capable of. I would like to see a lot more of that. For example, if you participate in mailing lists or Usenet newsgroups, adding a few words of praise for something to your signature can be amazingly effective. Or write a review in your web log, if you have one.
Saying nice things in public is more effective about unusual programs than the most common ones. For example, a thousand more people saying "Apache is a really good web server" isn't going to make a very large impact, compared to the masses who've already said so. On the other hand, it might have a relatively large impact if the same number of people saying similar things of somewhat less popular programs: "GQview, by John Ellis, is a really nice tool for watching digital photograps".
In fact, authors of really popular programs, such as Apache or the Linux kernel, might not appreciate it if even one out of ten of their users would mail them.
I would add the following to Connolly's list:
- Send a good bug report
- Help others with the program or whatever
- Add a link in any place.
For a developer, a good bug report is extremely valuable, since it helps them fix the problem. The need to say thanks goes both ways here: if someone reports a bug, they should be credited in the ChangeLog (or other relevant place). This encourages people to report more bugs and report them better.
In contrast to Connolly, I would advogate adding links to programs.
I'm less sure about getting money or tangible things as thank yous. If it becomes common, it could easily become an expected form of payment and then the software isn't free anymore. An occasional surprise gift is always welcome, of course.
I've written before (in July, 2003) about parasites in the free software world: parasites are people who don't give back and, in fact, harm the program or project they use by saying only bad things about it. Parasites are unpleasant people. Don't be parasite: send a "thank you" mail to the authors of your favorite programs.
Of course, I should now start practising what I speak by writing reviews of my favorite software. A theme for 2004 for this log, perhaps.