One enduringly popular model for blogging engines is that entries willbe files in the filesystem, and the blog engine will just wrap themup in various simple ways. This approach has a clear and attractivesimplicity and thus an obvious appeal, but as I have found out fromfollowing this route myself this simplicity hides a number of subtle problems .

All of the problems can be summarized in one word: metadata . Blogentries have (or need) quite a lot of of metadata associated with them,and making files your entries

In light of things such as Perl and Python, it is reasonable to askwhy the shell should have anysort of programming environment or language at all. Why not justrestrict shells to simple commands, pipelines, and redirections?

(I'm assuming here that you have a good Unix glue language around for everything that people currently writeshell scripts for.)

The obvious problem is the issue of where you draw the line. Is loopingover lists of files and doing something to each of them a common enoughoperation

Here's a couple of corollaries and effects of the charging problem that are worth mentioning (or at least that occurredto me).

The obvious corollary is how much more sensible the problem makesthe 'give away the service to build interest' approach often used byInternet startups. If people can't do anything with you before theyspend money, your window to get them interested enough to do so is verylimited (probably more or less one web page, at best). Giving them freeaccess gives

The more I use ZFS the less happy I become with it. It's not from anyissues with ZFS's features or with how it works in practice; ZFS isn'tone of those things that look better in theory than in practice. Basedon my exposure so far it pretty much does live up to its promise, andthe ZFS people are busy sanding off the rough edges and adding usefulfeatures.

My problem with ZFS is that if something goes wrong it all too oftengoes wrong in a

As I mentioned yesterday ,scripts in packaging systems are an opportunity to make mistakes. Thus,one thing that RPM could do to improve is to automate as many of thethings that are done repeatedly in install and removal scripts (of whichRPM has several variants).

There are two improvements that jump out at me. First, many packagesonly do things when they are being actually installed or removedinstead of being upgraded (and sometimes do other things during anupgrade). Right now people detect these cases by boiler

Once upon a time it was popular to laugh at package systems like RPMand say that all you really needed was ' make install '. This attitudemissed the point, because the importance of good package systems isthat they let you easily remove things .

This matters because it encourages experimentation with packages.If removing a package is difficult and painful, it's a fairly bigcommitment to just install a package in the first place. If removing apackage is easy and reliable, then installing packages is not at all

One persistent general belief, probably most common among a subset ofthe people who insist on going commercial for products (instead of opensource), is that your problems are over once you have a contract forsomething with some appropriate entity.

This is false. Contracts and agreements and so on do not insureactual performance , especially performance to your satisfaction ; all that they actually do is enable you, intheory, to recover some amount of money some distance in the future. Inpractice this 'remedy' is so

I like awk , I really do, but sometimes it really irritates me. Take, forexample, this fun little awk program:

awk 'BEGIN {print "5" == "05"}' /dev/null

You might rationally expect this to print '1' (awk's boolean truthvalue). As I found out once, you would be sadly mistaken; this isfalse, presumably because awk winds up doing a string comparisoninstead of a numeric one. Too bad if you

Here is something important to remember about your users:

Users are rational.

Users aren't crazy, and they don't do things just to irritate you; whatthey do and what they report about problems is not crazy from theirperspective, however odd it looks from yours. If users report 'I cannotlog into the intranet' when they cannot log in to the IMAP server, it isnot because they are stupid, it is because 'the intranet' is how theythink about your system .

(