November 2002

Statskontoret - The Swedish Agency for Public Management - is working on a preliminary study on the use of Open Source software within the agency.

Tom Coates, plasticbag.org (see here): We already have a low-budget tool that is designed for mass publishing, and that tool is the web - ultimately democratic in that people can publish on it whenever they want and given the extra advantage of being immediately an opt-in way of viewing content...

Introducing a pay-per-mail system, and deploying this world wide, which is a requirement for the whole thing to work as expected anyway, would be a great challenge both technically and politically.

If we're talking about such great changes to one of the corner stones of the Internet infrastructure, we might just as well imagine a completely different solution replacing the old technology. One example - which resembles how the web works today, and which would perhaps solve or lay a foundation for a solution to the problem that a pay-per-mail system addresses - is Dan Bernstein's Internet Mail 2000 system.

Using this system, the greater part of the cost of distributing mass e-mails would fall on the sender. It's an interesting concept.

For a background see here. Check out the lively discussions on slashdot, which link to articles on The Register and digitalMASS.

What proof has Antipiratgruppen provided? The article's I've read seem to indicate that the only evidence shown to the Danish judge was the IP addresses of the pirates and listings of available files. I.e. the names of the files. Hopefully something more substantial has been provided, like checksums of the actual files. Without checksums of the content of these files, how on earth could these names prove anything?

One could also argue what the existence of such a checksum could accomplish in a court, without proof of where the file was obtained (implying that the accuser would need a copy of that same file he or she say the pirate had at the time). How do you prove you got the file from specific host?

Another issue discussed on slashdot and in the articles concerns the legality of the bureau's actions. digitalMASS quotes the Danish attorney Martin von Haller:

In this case, we're talking about compensation for the damage the Anti Piracy Group claims its members have suffered. It's the courts that decide the amount of compensation to be paid due to copyright infringement, not the victim.

What rights did the collected evidence give the bureau? The Danish judge apparently gave the bureau legal access to the ISPs' customer records of the pirates in question. From this grant, taking the step to send fines of arbitrary amounts is quite large. Shouldn't the evidence instead have been used by the copyright holders - or someone representing them - to prosecute the pirates?

Are the Danish Anti Piracy Group using questionable methods?

Datormagazin writes (in Swedish) that the Danish counterpart to Antipiratbyrån - a Swedish organization working to catch copyright pirates - has been lurking on Kazaa and eDonkey for some time. Based on their findings fines will sent to about 150 Danish users.

I'm not sure I see a problem with these fines, at least not in relationship to what our current laws say. However, I think the anti-piracy bureaux often go too far in their views of what should and should not be allowed.

For example, the Datormagazin article ends in a paragraph describing how the Danish anti-piracy bureau has criticized Microsoft for its advertising of MSN Messenger. They seem to mean that as MSN Messenger allows for easy exchange of files over the Internet, Microsoft is encouraging illegal distribution of copyrighted material.

It's a strange argument if you ask me. Perhaps we should forbid programs implementing and advertising the FTP and HTTP protocols as well? Both protocols enables the exchange of files across the internet and would, by the anti-piracy bureaux' own words, therefore encourage criminal activity.

Rachel Ross hasn't grasped the concept of pair programming at all. She writes about it in her article 'Pair programming' an ill-fated shotgun wedding [found via Jonas Bengtsson].

First of all, pair programming isn't a subset of XP, it's a requirement. Or rather, the effects of pair programming - its benefits - as described in the XP literature is what's required. Rachel hasn't grasped this at all.

Perhaps if you read her arguments against pair programming outside the scope of XP, you might say she makes a few good points, but I disagree. And she is writing about pair programming in the context of XP. As such, she's just plain wrong and she displays an incredible amount of ignorance on the subject. Read your homework Rachel.

... forcing two great programmers to work ...

... when you force two people to work together so closely ...

XP isn't about force. You can't possibly succeed with XP if you try to force it onto a team. XP can only be adopted if mutually agreed upon. Likewise, pair programming - as a requirement for running an XP project - can only be adopted if mutually agreed upon.

If a team trying to adopt XP chose to exclude a specific practice, that team will not succeed if it does not find a suitable substitute for the dropped practice. This of course includes the practice of pair programming.

Most of the arguments against pair programming that Rachel presents in her article rely on the assumption that the practice of pair programming is being forced onto a team by the management. This of course automatically voids them all.

Another passage in her article that I just can't leave without commenting is It's too bad the entire concept works against human nature ...

What the heck is that about? People don't work together? Humans don't live in flocks, doesn't work together in groups? She's saying that humans are all lone wolves?

Commenting on my previous posting my friend Peter asked me why I suggested using helper programs instead of bundles.

I've come to think that bundles (dynamically loaded modules in Mac OS X) should be used with care. I'm not saying you shouldn't ever use bundles. You should, but only if you have a good reason to do so.

Using external programs instead of loading bundles or modules dynamically gives a few advantages:

• Separate namespace.
• Easy testing.
• A bug in the plug-in won't crash the invoker.
• Plug-in need not worry about thread safety in the invoker.
• Not worrying about thread safety means less and easier code.
• Automatic true multi threading as the plug-in runs in a separate process. The OS will handle it they way it seems fit. The invoker can call the plug-in from a separate thread if it doesn't want to wait for it (in a Cocoa application for example, where the main thread handles the UI). The plug-in doesn't care.

Some things cannot be externalized this way. In these case dynamically loadable bundles are a great thing. But if you don't need'em, consider using helper programs instead.

It would be really cool if iCal was to provide a configurable program invocation interface. What I'm looking for is a way for the user to specify programs to be run by iCal when its about to display a new range of dates (day, week or month view). It's a very dynamic and safe plug-in architecture.

iCal would dictate a command line API that the programs would have to follow in order to work as a plug-in. For example:

• iCal will start program with command line parameters as specified by the user (in preferences).
• iCal will write (in an unambiguous and easy to parse format) the time period to be displayed to program's file descriptor 3.
• iCal expects program to write iCalendar data to its standard output.
• iCal expects program to exit 0 if program did not encounter any problems.
• iCal expects program to exit <some other code> for temporary errors and <yet another code> for permanent errors.

What would the benefits be with such an architecture?

Many types of calendar information could easily be calculated by a small program. This includes for example:

• Data that is dynamic to its nature, for example easter and the holidays based on it.
• Data that is repetitive, for example annual holidays, birthdays etc.
• Data stored in a legacy database.
• Combinations of the above and more variants that I haven't thought of.

These small programs could of course be invoked manually and its output redirected to files, files which could then be opened in iCal. But, letting iCal invoke these programs itself, in a clearly documented and standardized manner, would save a lot of disk space. I always want to know about easter, but I don't want a huge file containing all easters from now to eternity.

One argument against using such programs would be the overhead of invoking the program, wait for it to finish and then parse its output. This could be solved by introducing simple caching algorithms, perhaps announced by the program itself, perhaps configurable by the user.

Some programs will generate output that for a given period of time won't change once its been calculated. Such a program need only be executed once for each period of time that the user wants to look at during a session; Some programs generate more dynamic data and might need to be consulted more often.

I think this is a cool idea! I'll submit it as an iCal Enhancement Request.