Yesterday I described how I could get away with ignoring encodingissues and thus how forced Unicode was and isirritating. However there is a gotcha in my approach, one that hidesbehind a bit of arrogance. Let me repeat the core bit of how my programstypically work:

What they process is a mixture of ASCII (for keywords, directives,and so on, all of the things the program had to interpret) anduninterpreted bytestrings, which are simply regurgitated to the useras-is in appropriate situations.

This

I've written a number of things that amount to grumbles that Python 3forces mandatory Unicode handling down people's throats where beforeI didn't need to deal with encoding issues. To start with it's worthexplaining why I could say this with a straight face.

I could get away with this ignorance because my programs almostinvariably work in a particular way. What they process is a mixtureof ASCII (for keywords, directives, and so on, all of the things theprogram had to interpret

One of our ZFS pools just experienced an error, and this time aroundI actually read the status message that ' zpool status ' prints out.Here, let me show it to you:

status: One or more devices has experienced an unrecoverable error.  An        attempt was made to correct the error.  Applications are unaffected.

The actual error was a checksum error (a single one) with no 'repaired'count; the pool is mirrored and reported no known data errors.

The problem here is that checksum errors are

A commentator on my previous entry on sysadmin education asked a very good question:

Now square your view with the fact that MSCE, CCNE, RHCE exist.

In thinking about it, I think that there are several reasons whypeople get such certificates.

• Historically, they've worked; getting a certificate has generallyled to getting paid better.

• Some certificates can be obtained more or less as a side effectof your employer getting you trained on some specific technologythat the employer cares about. If your employer needs someone to

A while back I ran across Tom Limoncelli's The road to intentional,formal, system administration education .In it Tom put forward the view that system administration shouldand in fact needs to move to a more formalized system of educationand training. Unfortunately I have to take the opposite side ofthis; I don't believe that such a move is likely any time soon andI don't believe that trying to make such a move would work out.

The fundamental reason I feel this is an economic one

You can take a number of views of what DevOps is about and what itmeans; for example, I've written about DevOps as a way to deal withthe blame problem . That was a relatively cheeryview of DevOps, so to go with it here is a really cynical one.

The grim view of what DevOps means is that it shows that people are notgetting their money's worth from traditional sysadmins, or at leastthey feel that they aren't; they feel that traditional sysadmins costtoo

Despite my grumblings about tunable parameters with stupid olddefaults , I've decided that I actuallyhave a reasonable amount of sympathy for kernel engineers and otherdevelopers who are in this situation and wind up leaving the defaultsuntouched. The following is only a theory, because I have never beenin this situation, but I think it's a plausible one.

The problem with the defaults for tunable parameters in any long-livedproject is that leaving them unchanged takes no work at all whilechanging them is probably going to

Yesterday I ranted in passing , as I have before,about Unix vendors that have never adjusted the defaults for any tunablekernel parameters and thus leave parameters set at values that wereperhaps correct fifteen years ago on much different machines, but whichcertainly aren't any more. Given that tunable kernel parameters canafter all be changed to better values, it may not be obvious why thisis a problem.

There's two reasons why you should get tunable parameters correctfrom the start. The first is that people will

I recently read Robert Haas's Absurd Shared Memory Limits ,in which he writes:

Despite the fact that System V shared memory is the only availableshared memory implementation that provides this feature, mostoperating system vendors frown on it, and encourage users to usethe newer POSIX shared memory facilities instead. They do this bylimiting the amount of System V shared memory that can be allocated bydefault to absurdly small values, often 32MB.

To put it one way, I'm not sure that Unix vendors