As time goes by, there's an increasing amount of stuff I want to writedown. One of the things that stalls me out on this (apart from the sheereffort of writing) is the question of where and how I should put them;in particular, should I make a wiki page or write a blog entry?

In theory this shouldn't come up; WanderingThoughts is part ofa hybrid wiki-blog, which I've extolled the virtues of before . In practice this is an illusion

We just got the following message today from a well regarded commercialbackup system that costs a lot of money:

* host:/filesystem save: path length of 1025 too long, directorynot saved: /filesystem/long/dir/path/...

Path name length limitations; just what I like to find out about inmy backup software. (I suspect that the limit is 1024 characters andthat the path is not exactly 1025 characters, it's

A lot of hardware RAID systems (whether controller based or SANs) liketo present a multi-disk RAID array to the host operating system as asingle device. While attractive, this can lead to hard to diagnoseperformance issues under load (well, a random IO load).

The basic problem is that you get the best performance by keeping allof your disks busy. But when you aggregate multiple disks into what theoperating system sees as one disk, the operating system is going toschedule IO for one disk

Classic Mistakes Enumerated is an exerpt from the book Rapid Development by Steve McConnell; itruns through 36 familiar classic development mistakes that people makeover and over again. Brooks's Law makes an appearance, of course.

(From Bill de hÓra .)

I found out about Linux su 's ' -p ' option from comments on a a previous entry . The option is also known as -m and --preserve-environment ; the manpage describes it tersely as 'donot reset environment variables', but the info document tells the fullstory:

Do not change the environment variables `HOME', `USER', `LOGNAME',or `SHELL'. Run the shell given in the environment variable`SHELL' instead of the shell from USER'

This is perhaps an obvious observation, but I've recently consciouslyrealized that persistent SCGI and FastCGI daemons area form of caching of regular CGI programs; rather than caching data,they're caching code and often configurations. Thinking about them thisway has made several things clearer to me.

As caches, they have all of the usual concerns with detecting anddealing with cache invalidation, complicated by the fact that fewenvironments have really good support for loading new versions of yourprogram's code on the fly.

By convention, Linux kernels are called vmlinuz (usually with aversion suffix and found in /boot , although Debian is in love with a /vmlinuz symlink). This name has an interesting history thatprobably stretches back to the early days of Unix.

(I say probably because I'm just guessing at some of the Linux history,as it predates my involvement with Linux.)

Originally, Unix kernels were just called /unix ; this is the name BellLabs used for the original versions up through V7

The really interesting bit of Why Crunch Mode Doesn't Work: 6 Lessons for me can be summedup in the lead-in:

There's a bottom-line reason most industries gave up crunch modeover 75 years ago: It's the single most expensive way there is toget the work done.

The article elaborates this, and makes for interestingreading. In the same area is Hours of Work in U.S. History , if one wantsanother set of data.

(Unfortunately I

One of the things that some people like to trot out in defense of Unixis the old chestnut:

On Unix everything runs as a user process, so you never have bluescreen of death reboots like you do with Windows; even if somethinggoes wrong, it's just a user process and your system doesn't go down.

I like Unix, but this sort of defense of it has always irritatedthe heck out of me. Ignoring how it can be false in practice , it's completely disingenuous