Understanding the (original) meaning of Unix load average
Most everyone knows the load average, and almost every systemadministrator knows that it's not necessarily a useful measuretoday. The problem is that the load average combines two measurements,as it counts both how many processes are trying to run and how manyprocesses are currently waiting for IO to finish. This means thata machine having a big load average tells you very little by itself;do you have a lot of processes using the CPU, a lot of processesdoing IO, a few processes doing very slow IO
When the Unix load average was added to Unix
For reasons beyond the scope of this entry itself, I recently becamecurious about when the concept of 'load average' first appeared inUnix. Fortunately we have the Unix tree from the Unix HeritageSociety , so I can answer this question bydigging through various historical Unix trees.
The answer appears to be that the concept of load average appearsfirst in 3BSD . Inthe 3BSD /usr/src/cmd directory , uptime.c is allegedly dated to October 4th 1979. The 3
Btrfs's mistake in limiting itself to two-way mirroring
Recently, I tweeted :
That btrfs still will not do more than two-way mirroring immediatelydisqualifies it for many serious uses as far as I'm concerned.
On the surface this may sound like a silly limitation to be annoyedat btrfs over, something that only a small number of people playingin the enterprisy (over-)cautious, cost is no object world willever use. Two way mirrors are pretty reliable, after all, and almostno one actually uses more than two-way mirroring (and
The 'cattle' model for servers is only a good fit in certain situations
To start with, let me define my terms. When I talk about 'cattle'servers, my primary definition is expendable servers that youdon't need to care about when something goes wrong . A server is cattle if you can terminateit and then start a new one and be fine. A server is a pet if youactually care about it in specific staying alive.
My contention is that to have cattle servers, you either need tohave a certain service delivery model or be prepared to spend a lot
My preliminary views on mosh
Mosh is sort of a more reliable take onssh that supports network disconnections, roaming, and otherinterruptions. I've heard about it for a while and recently PaulTötterman asked me what I thought about it in a comment on myentry on SSH connection sharing and network stalls . The short version is that sofar I haven't been interested in it for a collection of reasons,which I'm going to try to run down in the honest order.
First off, mosh solves a problem
SSH connection sharing and erratic networks
In the past I've written about SSH connection sharing and how I use it at work .At home, though, while I've experimented with it I've wound upabandoning SSH connection sharing completely because it turns outthat SSH connection sharing has a big drawback in the sort ofnetworking environment I have at home.
Put simply, with connection sharing, if one SSH session to a hoststalls or dies they all do . With connection sharing, all of yourseparate-looking sessions are running over one
All browsers need a (good) way to flush memorized HTTP redirects
As far as I know, basically all browsers cache HTTP redirects bydefault, especially permanent ones. If you send your redirectswithout cache-control headers (and why would you do that for apermanent redirect), they may well cache them for a very long time.In at least Firefox, these memorized redirects are extremely persistent and seem basically impossible to get rid of in any easyway (having Firefox clear your local (disk) cache certainly doesn'tdo it).
This is a bad mistake.
Looking more deeply into some SMTP authentication probes
Back when I wrote about how fast spammers showed up to probe our newauthenticated SMTP service , I said:
[...] I can see that in fact the only people who have gottenfar enough to actually try to authenticate are a few of our ownusers. Since our authenticated SMTP service is still in testing andhasn't been advertised, I suspect that some people are using MUAs (orother software) that simply try authenticated SMTP against their IMAPserver just to see if it works.
Ha ha
Why systemd should have ignored SysV init script LSB dependencies
In his (first) comment on my recent entry on program behaviorand bugs , Ben Cotton asked:
Is it better [for systemd] to ignore the additional [LSB dependency]information for SysV init scripts even if that means scripts that havecomplete information can't take advantage of it?
My answer is that yes, systemd should have ignored the LSB dependencyinformation for System V init scripts. By doing so it would have had(or maintained) the full System V init compatibility that it doesn'tcurrently
A significant amount of programming is done by superstition
Ben Cotton wrote in a comment here :
[...] Failure to adhere to a standard while on the surface making useof it is a bug. It's not a SySV init bug, but a bug in the particularinit script. Why write the information at all if it's not going to beused, and especially if it could cause unexpected behavior? [...]
The uncomfortable answer to why this happens is that a significantamount of programming in the real world is done partly