Lars Wirzenius: Rant, 2003

Contents

Sunday, December 28, 2003

Rant: Explosions

It is that time of the year again: kids are being armed with explosives and can't wait until New Year's eve. This is an unnecessary, pointless ordeal we have to go through every year. Not only is the noise an annoyance and the risk of mishaps a worry, you also have to worry about the more malevolent kids throwing fireworks at you on purpose. If not at people, then at dogs.

People aren't allowed to shoot guns at will. There's no point in allowing them to play with explosives, either. Owning and handling fireworks should require a license, just like with guns. People should pool their money to hire fireworks professionals instead of wasting them on stuff they don't know how to use properly. Blah.

Perhaps I should just move some into the middle of a forest, far away from everyone, at least during this time of the year.

Permanent link to this entry

Saturday, December 27, 2003

Rant: Too many passwords

I have recently been invited by various people to register at various web sites (these have partly been related to Christmas gifts). So far, I've resisted them without much difficulty. Registering is a bother: I have to come up with a username and password and remember them. Then, if I start using the site, I need to change the password periodically: I am, after all, responsible for things done using that password, so I am obliged to take good care of it. The more passwords I have to keep track of, the less pleasant my life is. It is easier to just not register at all.

Running a service as a web site usually inherently requires people to register and to log in, since not everything can be run as an open Wiki. For the few web sites that provide a service which I value (such as LWN or Freshmeat), I do register, and log in, but I find that my threshold is fairly high.

Some sites require registration even just to browse, such as a Finnish photography web site's discussion forums. Such sites are best ignored, in my opinion, unless there is a good reason to assume they are useful.

The multiplying password problem is not limited to web sites, of course. I find myself subjected to requirements to keep track of ever increasing numbers of authentication things everywhere. Having to administer many computers means having to remember many passwords. Bank and credit cards have PIN codes. Mobile phones have PIN codes (several, in fact). Some doors have electronic locks with PIN codes, sometimes in addition to a physical key. Mailing list subscriptions and unsubscriptions may require passwords. Even some IRC channels have passwords.

I've been resisting new passwords for a while, now. I think it's time to actually start reducing them. This may have the side benefit that my life in general becomes simpler: if I don't administer quite as many services on quite as many different machines, my life will almost certainly not suffer.

Life should be simple.

Permanent link to this entry

Tuesday, December 23, 2003

Rant: Needless dot files

I've just cleaned some dot files from my home directory. It is quite annoying that there were a couple of dozen unnecessary ones, all from programs I've started to see what they look like but never actually used. It is a stupid trend that a program should create a dot file with it settings unless those settings have actually been changed. What's worse, it seems that some libraries have started doing that as well: one of the removed files was called libgda. Blah!

Permanent link to this entry

Thursday, December 4, 2003

Rant: I hate phone calles

I'm beginning to be annoyed at my new phone. I rarely heard my old phone, since due to various reasons I always kept it in "silent beep" mode. The new one plays a melody instead, which means that I actually notice when someone is calling me. This means that I get interrupted at annoying moments seemingly constantly.

One of the more ingenious phone conversations of today was when a customer responds to my mail with a mail telling me to call him so that he can spend 8 minutes and 16 seconds (according to my phone's log) telling me that what I suggested in my original mail is fine.

I'm seriously considering dclearing my phone off limits for work stuff.

Permanent link to this entry

Tuesday, December 2, 2003

Rant: __semihosting_swi_guard

One of the bugs I've hunted these past two weeks caused the following compile time error:

Error: L6200E: Symbol __semihosting_swi_guard multiply defined (by use_semi.o and use_no_semi.o).

It took me a while to figure it out, but luckily I remembered having fixed it once already, last year. Then it took me a full day, though. What caused the error was trying to use a function from stdio.h that isn't defined for the embedded platform we use. Some functions are OK to use, but others are not and, of course, there is no documentation which ones are. When trying to use a forbidden function, the error messages are as clear as the one quoted above. Not fun at all to figure out, especially if you are in a hurry.

Permanent link to this entry

Wednesday, November 12, 2003

Rant: Embedded Linux

The more I spend time in the embedded area of computing, the better I understand the strong craving many people have for Linux as an embedded operating system. Analysts seem to think it is because the marketplace wants a standardized solution or because Linux is cheaper than the alternatives. I say it is because traditional embedded operating systems are written by hardware people who just barely understand programming and utterly despise programmers. No-one in their right mind wants to touch such operating systems. They're difficult to program for, and they do little to help you.

Even though Linux itself can occasionally be aggravating, at least the application programmer does not have to fight daily with code written by hardware engineers. Given that hardware people and software people are natural enemies, perhaps it is not surprising that the hardware people just love to put in nice surprises for the application programmer. Things like, say, magic and undocumented limits on how much memory you can use for static variables.

I've spent yesterday and today finding out that if a particular four kilobyte array is allocated statically, it will overlap with the C runtime stack. Allocating it dynamically makes things work. Blah. (Of course, to make things even more interesting, it might be that I've merely hidden the problem. We'll see.)

Permanent link to this entry

Thursday, November 6, 2003

Rant: Systematic API design

Imagine this: you're designing the system software for an embedded computer. Your hardware has various interfaces, such as analog and digital inputs, serial ports, various buses popular in the embedded world, and communication devices such as a GSM modem. Your task is to add support to the library for each of the subsystems. How do you design your application programming interfaces?

What you could do, is invent a new style of interface for each subsystem. For example, for the serial ports, you might want the application programmer to write a handler, which the interrupt routine for the serial port will call when the input buffer gets full. The TCP/IP subsystem could send an inter-task message to the main application task, which then fetches the actual input string from a buffer via a system call. The I2C bus is simple, so it gets a library function that just sends a message, or queries a device, as an atomic operation. And so on.

Just for fun, you could make the GPS unit be accessible via a serial port, but make it be just slightly different from all the other serial ports. A perfect way would be to not use the buffer the application programmer has defined, and instead pass a pointer to the actual buffer to the handler function called by the interrupt routine.

Of course, to make it easier to use the GPS unit, you will provide a nice module to deal with the unit and parse its output into a format that is easier to handle than the string encodings. To make things more interesting, however, you could put the module outside the library, so that it has to be compiled manually by the application programmer. You'll make the module send the GPS location as an inter-task message. To make things absolutely hilarious, you will make it wrong to manually free the memory allocated for this inter-task message, even though all other messages must be so freed.

Additional comedy can be generated by naming your C functions and types with semi-random prefixes. Say, occasionally capitalize the prefix you use, and occasionally change the prefix into a suffix.

If you document all your interfaces, everything should be fine, yes? In an abstract way, yes, everything should be fine. In practice, your system is a nightmare to write applications for. When nothing in the system is orthogonal, every little detail must be checked from the documentation, header files, examples, or other places. Not just the first time, either, but every time. Un-orthogonal interfaces are hard to remember, as well as being hard to learn. They make development slower, and cause more bugs. Evil things. Evil.

All idiocies in this rant are completely fictional, of course. No-one would write such a system in real life. Of course not. That would be stupid. Yes, indeed it would, and so they didn't. Please?

Permanent link to this entry

Wednesday, October 29, 2003

Rant: Make your program easy to install

If you're writing free software, you do yourself a big favor if you make your program easy to install. Programs that are difficult to install are harder to try out, and that limits the number of users you'll get. The absolutely easiest way to make your program easy to install, from my point of view, is to make sure the program is packaged for and included in Debian. Users of other Linux distributions and other operating systems want packaging for their favorite systems.

Note that packaging is more than just putting together a tarball of compiled binaries. It includes integration to the system the package is built. There are many subtle differences even between Linux distributions. For example, for many years the location of init scripts was /etc/init.d in Debian and /etc/rc.d/init.d in Red Hat. The way the init script was registered for different run levels is still different. The meanings of different run levels is different. Because of this, your program needs to be flexible enough to not hard code such things into the code, and must let the installer configure things easily.

Another issue is that your program shouldn't needlessly depend on unusual libraries or tools to work. For example, the first versions of bogofilter required a library that was not included in any Linux distribution at that time. It was also very difficult to install, because it did not follow any standard convention for configuration and installation. That's why I didn't install bogofilter until it was packaged for Debian.

By making your program easy to configure, and install, you make it easy to package it any platform. That makes it easy for people to try it. That means you get users more easily. Everyone is happy.

If, however, you make your program difficult to configure or install, it is tempting to assume you don't really care about getting any users. If you don't care about users, why are you releasing the software?

Permanent link to this entry

Tuesday, October 28, 2003

Rant: GUI code portability

For the most part, programming languages should be portable. One part that doesn't have to be portable is widget sets. Widget set portability is pointless.

The kind of portability I mean is where the same widget set works in several different graphical environments, such as both in Gnome and Windows. There seems to be two approaches for achieving this: either there is an abstraction API that is mapped into the native widget set on each platform, or the portable widgets are separate from the native ones and implemented for each platform separately.

The native widget sets on various platforms have much in common, but also there are huge differences. An abstraction API must be either so abstract, it prevents the programmer from doing anything fancy (and most interesting programs need fancy), or it must try to be a superset of all native widget sets, which makes it too complicated. Neither approach is good, but at least the widgets look like the native ones.

Writing non-native widgets for each platform is the approach of Tcl/Tk (and Python) and Java. The big problem is that the widgets aren't the native ones. They may try to look like the native ones, but they don't ever succeed completely. For example, GTK+ provides theming, and look-a-likes don't follow that. They also have subtle and not so subtle differences in how they react to keyboard and mouse input, which can be hugely annoying to the user.

I'm being provocative, of course. There are situations when portability is useful, but in general, it is better to write the user interface parts of each application for each platform, using native widgets for that platform. If you keep the UI code a thin layer over the actual application logic and data structures, the amount of effort to port to a new platform should reasonably small.

So why do I care? I'm on the lookout for a new programming language and most people seem to consider GUI programming as unimportant. They think it is enough to provide bindings to, say, Tk or WxWindows.

Permanent link to this entry

Wednesday, October 15, 2003

Rant: Accuracy of manuals

One of the boxes I'm supporting Hedgehog on has a built-in flash memory, and the operating system comes with an API for writing to it. So far so good. Unfortunately, the documentation does not specify things fully, and the technical support hasn't answered questions correctly, either.

For example, the flash memory can contain arbitrary user data, or an executable, and if it contains an executable, the functions for writing to the flash will change a checksum and other header information. That's not something you want happening to your data, unless it is an actual executable. The manual does not explain how these cases are differentiated. Technical support explained that the difference is that any write sessions that start at the beginning of the flash are assumed to be executable, others are not. Therefore, they said, I should start writing at offset 1.

It turns out that you must start writes at the beginning of a sector. There is a function for figuring out the size of a sector, but the documentation does not say what the unit is. Various parts of the manual and the API use different units: the size is reported in megabits, offsets into the flash are in bytes, and write operation lengths are in words of two bytes. So, exactly how long is a sector of length 4096? It could be 512, 4096 bytes, or 8196 bytes.

Permanent link to this entry

Tuesday, September 16, 2003

Rant: Windows harms the whole Internet

I was going to write yet another whining rant about Windows viruses disturbing the whole of the Internet, and the immorality of attaching machines to the Internet without the least amount of security. But what's the point?

Permanent link to this entry

Monday, September 15, 2003

Rant: University of Helsing rules for net presence

I just had a peek at the new rules for appearance of the University of Helsinki net presence: things like how web pages should look, and what domain names should look like, and so on. I'm very happy I don't have anything to do with the university anymore. The rules have been designed by some ad agency, and they are totally incompetent. I grant that the pages look nice - if you have the right browser settings.

I though the web was moving away from things like forcing the page to have a certain pixel dimensions. These rules specify the width of a page in pixels. Elements within the page, such as boxes that contain text, are also specified pixels. Fonts are specified in pixels. Therefore, if I have a high resolution (many pixels per millimeter), the text will be smaller on my screen. If I use the zoom feature in my browser, which makes text larger, it overflows the box it is designed for. This is gross incompetence in web design.

They also strongly recommend a signature for mails that is more than twice the size of the netiquette limit of four lines. More incompetence.

I have the feeling that ad agencies still don't get it that the web simply is not a brochure. This simple fact seems to be so difficult for them to grasp that they should be taken out and shot, out of mercy.

I can't give you a link to the PDF with the new rules. Apparently the university no longer believes in publishing things and has hidden the PDF so that it can only be seen from within the university's network.

Permanent link to this entry

Thursday, September 4, 2003

Rant: Insecure computers OFF the Internet!

While I came to work today and had a chat with my boss (a total time of about 90 minutes), I received 39 mails that bogofilter automatically and correctly classified as spam or other trash. They have a total size of 3.2 megabytes and most of them are actually sent by viruses trying desperately to invade my system. Windows viruses. The kind that has zero chance of affecting my system. Blech.

People who aren't capable of keeping their computers virus free shouldn't connect their systems to the Internet. This seems to include tens of millions of Windows machines and users. Blech.

Permanent link to this entry

Wednesday, September 3, 2003

Rant: Programming language implementation bloat

I found Hints for programming language design by C.A.R. Hoare on the web. (I forgot the URL, sorry.) He writes:

There is another argument which is all too prevalent among enthusiastic language designers, that efficiency of object code is no longer important; that the speed and capacity of computers is increasing and their price is coming down, and the programming language designer might as well take advantage of this. This is an argument that would be quite acceptable if used to justify an efficiency loss of ten or twenty percent, or even thirty and forty percent. But all too frequently it is used to justify an efficiency loss of a factor of two, or ten, or even more; and worse, the overhead is not only in time taken but in space occupied by the running program. In no other engineering discipline would such avoidable overhead be tolerated, and it should not be in programming language design, for the following reasons:

  • The magnitude of the tasks we wish computers to perform is growing faster than the cost-effectiveness of the hardware.
  • However cheap and fast a computer is, it will be cheaper and faster to use it more efficiently.
  • In the future we must hope that hardware designers will pay increasing attention to reliability rather than to speed and cost.
  • The speed, cost, and reliability of peripheral equipment is not improving at the same rate as those of processors.
  • If anyone is to be allowed to introduce inefficiency it should be the user programmer, not the language designer. The user programmer can take advantage of this freedom to write better structured and clearer programs, and should not have to expend extra effort to obscure the structure and write less clear programs just to regain the efficiency which has been so arrogantly preempted by the language designer.

I find his comments describe accurately the software development attitude today. It is common for programmers to write inefficient programs and then say it can be fixed by buying faster hardware. While I can accept this for many applications, it is really most inappropriate for programming tool implementations. Not the just compiler, either: libraries, frameworks, and such are tools and, these days, at least as important as the compiler. I find the CPU and memory requirements of modern tools to be distasteful, since they don't provide correspondingly more in the way of speed or power.

Ten years ago I could fit on floppy all the tools I needed to develop programs in C: an editor, a C compiler, and the standard library. It took a few moments to compile and link a program of a thousand lines. These days, the C compiler and library are about 28 megabytes, without an editor. That's about 20 times the size. I don't have a good way to compare CPU speeds then and now; clock speeds are about fifty times higher now. My RAM is now 64 times bigger. It still takes a few moments to compile and link programs of similar size, though I suspect it is a bit faster now. Where did all the speed go?

Of course the compiler and library of today are much bigger and more featureful than those of ten years ago. The compiler has many more warnings, and can produce better code. The library has all sorts of nifty stuff I didn't have then. Is the new stuff worth it? I don't know. Nothing fundamental has changed: program execution speed is still dependent on my designing and implementing programs well, and I rarely use most of the new stuff in the libraries. Programming in C isn't any easier now than it was then.

The popularity of C has, of course, not been growing this past decade. Other languages are occupying its place in various niches, and in most niches, that's for the better. C is way too low-level a language for general application programming, and it is good that, say, Java and Python are replacing it for that. On the other hand, a modern Java programmer may need hundreds of megabytes of RAM just to run an IDE, and claims that it doesn't matter, memory is so cheap these days. That would be all right, if their productivity would be correspondingly higher, or they would produce better quality than C programmers ten years ago, but I don't see that happening.

I do actually think that a good programmer using Java is more productive than a programmer of equal caliber using C, but not 64 times as productive. Maybe two times. Something, somewhere, is wrong with this picture.

The other reason Hoare's remarks feel so right on mark for me today is that I've been struggling with the performance of an application written in Hedgehog Lisp at work. It reads frames from a CAN bus (a data bus inside a vehicle). Frames arrive at about ten millisecond intervals, or about 100 per second. We miss most of them, even though we have about three million clock cycles per frame. Either the application is doing something very wrong, or the implementation of Hedgehog Lisp is not up to the quality we need. Either way, my fault. (Even though the current one wasn't written by me, I guided the work and set performance requirements, so I'm responsible.)

Oh, by the way, Hoare wrote those words in 1973.

Permanent link to this entry

Saturday, August 23, 2003

Rant: IE doesn't do PNG transparency

I'm a sucker for the drop shadow effect on thumbnails. Unfortunately, it seems I can't implement it using reasonable tools if I care about people using Internet Explorer (at least the Windows version). For no good reason at all, Microsoft refuses to add proper support for PNG transparency. There is a way to get it done, I'm told, but you need to use JavaScript and ActiveX or something like that, and it's useless complication for what should be simple.

Below are crops of screen dumps from three browsers: Galeon, Opera, and Internet Explorer. Galeon and Opera do the transparent drop shadow perfectly, but IE bungles it completely and loses the red background color of the page completely. There is no reason for it to do that.

PNG is an old standard, by Internet age. Years and years and years old; in fact, about 8 years old by now. If Microsoft wanted to support it, they would have already. There must be some reason why they don't (their browser is evidently capable of it), which probably has something to do with the fact that PNG is not a standard they control.

Galeon screenshot

Galeon: perfect.

Opera screenshot

Opera: perfect.

IE screenshot

Internet Explorer: crap.

The question is: should I care about supporting the Internet Explorer by avoiding drop shadows and other things that work perfectly on other major browsers? My pages try to follow the relevant W3C and other standards, so IE users should get at the information on all my pages, but they might not get such nice looks as those using good browsers. Decisions are hard.

(I know many people consider drop shadows lame. I don't care.)

Permanent link to this entry

Rant: The press protects Microsoft

The past week the Internet has been plagued by several new viruses for Microsoft Windows. I have noticed only one instance in mainstream media where it has been mentioned that it is a Windows problem, even if it causes mail overload for everyone else as well. One! What is wrong with journalists? Why must it be kept a secret that the reason all these viruses can thrive is that Windows security is bad? If, say, a chemical company would be as lax with its security, and caused so huge monetary losses internationally, everyone would be screaming for them to be shut down.

Permanent link to this entry

Friday, August 1, 2003

Rant: Electronics engineers shouldn't design APIs

Electronics engineers should not be allowed to design software application programming interfaces. The box we use at work has several analog inputs and a way to make a message to be sent by the operating system to the application if the input value goes outside bounds. The maker of the box provides a C structure to hold the configuration. The structure contains no less than three ways to refer to an analog input port: two different bitmasks and an index into an array. There is no point in doing this, since it would be possible to use a single name. Even if you just used one name for the bitmasks and another for indexing the array it would be simpler. Bah.

Permanent link to this entry

Wednesday, July 23, 2003

Rant: Free software parasites

Free software (or open source, if you prefer) has become pretty popular and commonplace in the past few years. We seem to have gotten past the phase, where it was somehow exceptional to use free software, even if we aren't the default option yet, except in some application areas.

With the growing popularity, the number of articles and speeches full of fear, uncertainty, and doubt, or FUD, have also become less. This is quite nice. On the whole, I think that the free software crowd has dealt with FUD in the right way: most public responses have been reasonable and calm, and actual problems with the software have been fixed. We're far from perfect, but we're pretty good.

Most people who use software, as opposed to those who try to sell it, or write about it, seem to accept free software on its own grounds. If it works for them, they're happy to use it, and if it doesn't, they use something else, without making a big fuss about it. Unfortunately, there seems to be growing a new class of free software users: the parasites. Parasites will use free software, but do their utmost to never give anything back to the community that produced it.

The parasite will happily use free software, but when talking about it, will mention only its shortcomings, never any of the good stuff. Every bug results in repeated whines, sometimes on several forums. The parasite will not report a bug, however. Not ever. When asked about it, the parasite will give all sorts of stupid reasons: "it's too difficult" (it would have to send an e-mail), "they aren't interested" (after being told by a developer that they are), "it wouldn't help anyway" (well, duh).

FUD and over-generalizations make the parasite happy. If it isn't happy with the user interface of one free program, it will claim that the free software movement won't ever produce a really user friendly desktop environment. It might back this up by claiming that free widget sets are a decade behind the commercial ones (naturally without ever having actually written code with the free ones).

The parasite may have to grudgingly admit that free software is good enough for, say, web servers and other server applications, but will always add that for real applications, commercial software is needed. "MySQL is OK for toy applications, but for real use Oracle is needed!"

I'm not sure how to deal with parasites. They greatly annoy me, but I suspect ignoring them is the best option, rather than bringing out military grade LART equipment and flaming them, or even patiently explaining things to them.

Permanent link to this entry

Sunday, July 13, 2003

Rant: Stupid spammers

A company using the address info@cmax.nl sent an advertisment about custom-designed Linux shoes. They start their mail with an explanation why this is not spam:

Sending "Spam" to Linux-users.

How dumb can these guys be you must be thinking? This is like teaching Bill Gates the word "open source" or like having sex with Mrs. Tyson. So, before you bomb the hell out of us or instantly block all of our IP addresses, please do listen up. We're not as stupid as you might think. We, like you, are proud Linuxers ourselves, so how could we be? We got your address searching on linux sites and we promise we will only use it once. What do you say? Deal?

Having to explain why your mail is not spam is a pretty good explanation why it is. Claiming that they will only use my address once is a common claim among spammers. (Irrelevant, even if true, anyway.)

As far as I care, these people are spammers, and the fact that they use Linux is not an excuse so send me advertisments even once. My bogofilter now knows about them, hopefully any further crap from them will be filtered away.

Permanent link to this entry

Monday, July 7, 2003

Rant: IT support attitude problem

It seems to me that IT support people, or system administrators, or whatever they're called this week, in many places have a bit of an attitude problem. I did, too, to some degree, when I first worked as a system administrator (at the HiBase project), but I think I have gotten over it.

The attitude problem I'm referring to is the delusion that the IT department's needs and desires override those of the users when in reality it is the other way around. The IT department is there to support the users, to make sure the users can concentrate on their real jobs, instead of having to deal with the ugly things to get computers working.

This does not mean that anything the users request must be implemented immediately. There is a conflict between what the users actually need, what they think they need, and what can be implemented in terms of resources or security. This conflict occurs pretty much anywhere. In recent years, security has become the easiest way to override users' requests and I fear it is being used without enough justification. This is wrong.

The users must get their work done. It is not the job of the IT department to dictate which tools are to be used. If the users request something that the IT department does not have the resources to provide, there are two steps that need to be taken: the actual need of the users are to be determined and a budget level decision of whether it the need important enough to warrant increasing the budget. These steps require discussion and thought, not power games.

From what I hear and see, power games are what actually happen in many places. The IT personnel will deny any request by reflex, without giving it any thought. At one place, a user needed a five meter long network cable, and the IT support person claimed they did not have such, even though he was holding a seven meter long cable in his hands.

The Bastard operator from hell stories are fun, but they should not provide role models.

Permanent link to this entry

Thursday, June 19, 2003

Rant: Combating viruses with law

It seems there is an attempt at making it illegal in Finland to have a copy of a virus, unless you have an acceptable reason for it. The justification seems to be that this will reduce the amount of damage viruses do. What utter bullshit.

I admit I haven't investigated whether that claim is made by the law makers or just stupid people who guess what the motivation is. It doesn't matter. The problem is that the perception is common, even though it is completely wrong.

Most, possibly all, of the viruses that cause damage come from abroad. A Finnish law won't reduce the damages they do at all. It might help get behind bars what few Finnish computer criminals there are, and for that the law might be good. For improving computer security, it helps not at all. Anyone who thinks it does, shouldn't be allowed to attach a computer to the Internet.

The number one computer security problem is that the majority of the computers on-line are insecure. Not just slightly insecure, but massively insecure. Not just their operating systems, either, but their applications as well. The best sign of this that the most common advice about viruses these days "don't open e-mail attachments". If the security of a system is dependent on the user not opening an attachment, the system's security design has totally failed.

Opening is what e-mail attachments are for. It's not only natural to open them, if you never do open them, having an attachment feature is completely pointless. Get rid of it.

The problem with attachments is that the programs that open them can execute program code inside the attachments. For example, Word documents can contain programs written in Word's macro language, and that language is powerful enough that the program can do essentially anything. Viruses exploit this. This is a fundamental insecurity deliberately designed into the system that makes the whole computer vulnerable. Remove the macro feature from Word and suddenly it becomes safe to open Word documents. Similarly for other types of files.

With such glaring holes in the basic security in a system, relying on external add-on tools such as virus checkers is not going to help a lot. To begin with, virus checkers won't help for completely new viruses. It takes at least hours for virus checker companies to update their databases. In this time, the virus will have time to infest the whole Internet many times over, if it is written cleverly enough. Security needs to be built into the system, it cannot be an add-on.

Permanent link to this entry

Friday, June 6, 2003

Rant: Rid the Internet of unsafe computers

It seems there's a new virus out loose again. I'm getting several mails each day sent by this virus. It is as ridiculous as usual: I am not vulnerable to the virus itself, but I still suffer since there are too many people on the net who are unable or unwilling to protect themselves.

As usual, it is also clear that the virus infects computers through the usual round of helpfully unsafe e-mail software. Yep, Microsoft's Outlook is at it again. This happens pretty much every time there is a massive virus problem and you never see anyone point this out when the problem is reported. Instead, the news media interview representatives from anti-virus companies who all claim the only way to solve this is to upgrade the anti-virus software. Wake up! The anti-virus companies have no incentive to solve the virus problem. Their business depends on there being a virus problem.

The virus problem won't be solved until the security problems are solved. Outlook, for example, has so many security problems its use on the Internet should be banned until it is fixed. Not doing so is exposing everyone, not just the Outlook users themselves, to bandwidth abuse.

That applies just as much to other unsafe programs, of course. Even if they run on Linux.

Permanent link to this entry

Sunday, June 1, 2003

Rant: Mailman

I'm on one mailing list managed by Mailman. I subscribed a couple of weeks ago and today the software reminded me that I'm subscribed to the list and told me what my password is. How friendly. If I were subscribed to mailing lists operated by Mailman on several sites, I'd be getting at least one per site. Ugh. Not the kind of mailing list experience that I want.

I've been told that Mailman lets you disable these reminders, but I didn't see any way to do that. The site in question may be running an old version of Mailman, or perhaps they've just decided not to allow that. Blech.

That list in question is spam-proofed by only allowing subscribers to post. I'm subscribed to the list with another address than the one in my From header. This means that all my posts need to wait for moderator approval. It isn't helping me participate in the discussions when it takes days for my messages to reach the list. I can't fault the volunteer moderator or moderators for their slowness; the software shouldn't be requiring my messages to be moderated.

My From header says liw@iki.fi, since that is a semi-eternal address. I've used it since 1995 and have a high expectancy to use it a decade from now. IKI is a non-profit organization whose primary practical purpose is to provide such a semi-eternal address. There is no yearly fee, just a one-time subscription fee and the whole thing is run by volunteers. To keep operating costs down, using @iki.fi addresses for mailing lists subscriptions is forbidden.

I want to continue using liw@iki.fi in my From header so that, years from now, when people find an old message of mine, they can still reach me. This happens to be important to me.

Other people have different reasons for having different address for subscribing and posting. For example, many people subscribe to mailing lists using constructs such as liw+listname@iki.fi. This lets them both filter easily and also see if the address is leaked from the mailing list elsewhere.

Thus, any attempt at a subscribers-only posting policy needs to take these people into account. Mailman boasts a fancy web interface. They could easily let me add additional addresses from which I could also post and have them be treated as if from subscribers. But no. It might be possible to kludge this by subscribing with each address and just disable delivery for all but one. That would mean I get each monthly reminder n times. Not good.

Not to pick too harshly on Mailman, in particular, though. Plenty of other mailing list software has the same flaw, including my own. And I need to fix this.

I utterly dislike that Mailman requires me to have a password (the mail interface for subscribing didn't work if I wanted to subscribe something else than the From address). I haven't had any use of the web interface for managing my subscription. Mailman advertising makes much out of the web interface, but for me, it is just clutter. Ezmlm got it right, the Mailman approach is just extra bother for most people.

I will eventually need the password for unsubscribing, and even that is stupid. Anything that mandates a password when it doesn't necessarily require it is stupid. Subscriptions must be confirmed by e-mailing the subscribing address. Unsubscriptions can be dealt with the same way. No password required. For most people, most of the time, no password is ever required for interacting with the mailing list software: they subscribe once, then eventually unsubscribe, and in between, they should be able to just ignore the mailing list software. Having to read monthly mails from the software is just extra bother that helps them not at all.

If the list software does have a web interface, and the user has a need for it, then, yes, a password is required. In that case, and not until then, create a password. Until then, the password is unnecessary and unnecessary passwords degrade people's willingness to have good passwords. Unnecessary passwords are evil.

For fairness, because I am sort of in competition with Mailman, I wish to add the following: I don't think Mailman as a whole is evil, or stupid, or badly designed. It has specific features that I dislike, but on the whole it is has improved mailing lists on the Internet.

Permanent link to this entry