Wandering Thoughts archives

2011-02-28

The evolution of filtering (a story from the Usenet era)

When I first started reading Usenet (back in the rather old days), I wound up hanging around some old Unix and Usenet hands. One of the things that I noticed about how they read Usenet was that they had really aggressive killfiles; they would go into what I considered a high quality technical newsgroup like comp.unix.wizards and their newsreader would promptly junk all but one or two of the articles.

At the time, I did not understand this at all. Sure, there was a certain amount of pointless chaff even back then, but they had to also be throwing out huge amounts of solid, interesting stuff; how could they stand to miss them?

I took the opposite attitude. For a long time I didn't use a killfile at all, because I didn't want to run the risk of accidentally missing a good article. Even when I started using killfiles, I was very conservative about what I junked; I felt it was better to wade through some amount of chaff rather than miss a gem.

Then one day I woke up and realized that I was wrong, because I had been fooling myself about the actual choices. In reality it was not a choice between reading only some of the gems or reading all of the gems (and some amount of chaff); it was a choice between effectively reading no gems at all and reading at least some, even if I missed others. Once I realized this, my Usenet filtering gradually became more and more aggressive. As the noise increased in the newsgroups I read, I became more and more willing to filter out almost everything in order to at least get something or at least not waste lots of time for nothing.

There is an obvious extension of this to email, and in fact I've wound up feeling that the same dynamic is inevitable. Put one way, there is only so much noise that people will put with for so long. At some point I expect people to switch attitudes the way I did way back when, and stop feeling that every email is (potentially) precious in favour of an attitude of extracting what use they can from email, even if it's imperfect and incomplete.

(Existing spam filtering is already helping with this, because it means that fewer and fewer people consider email a reliable communication method any more. 'It got eaten by my spam filter' is a great excuse partly because it's so often true.)

spam/FilteringEvolution written at 21:33:28; Add Comment

The slowdown of Solaris here

Oh, it's not that our Solaris machines have slowed down. As far as I know, they're still running as fast as usual. What's been slowing down is our interest in Solaris, or at least our interest in new versions of Solaris. There was a time when I was relatively carefully tracking what was new in patches, Solaris updates, and OpenSolaris; nowadays I had to check to confirm that Solaris 11 Express was ZFS root only.

A relatively small part of this is because our Solaris machines work fine as they are. A large part of it is because, ultimately, we don't trust Solaris engineering to get things right when they make changes (with good reason, we have seen terrible performance regressions introduced by well-meaning patches).

Because we have so little trust in Solaris, we must do a full test and re-qualification of any patches or new versions of Solaris; this is a lot of work, and we aren't going to start it right away, and when we might start it there's a new version that may be coming out. Beyond that, because we don't trust Solaris changes we always get to weigh the potential benefits of an upgrade against the equally potential drawbacks of running into serious issues in production. So far, that weighting has never come down on the side of an upgrade.

(Although I have not looked at ZFS changes recently, the last time I did the only really attractive one is 'zpool import -f'. And if we wind up needing that, we can always crash-build a current Solaris machine to do the pool import and re-export.)

Oracle's decision with OpenSolaris is a significant factor in this. Not having source code will hamper us in a number of ways and certainly makes running Solaris more dangerous; now if things go wrong we are entirely at the mercy of Oracle support, and our experience with Sun's old Solaris support environment certainly wasn't particularly positive.

(I suspect that the last released OpenSolaris code is already out of date with current Solaris patches, but I haven't checked.)

Given all of this, I simply haven't been very active in watching Solaris developments. There doesn't seem to be much point in paying close attention to something that we're very unlikely to use (at least not any time in the near future).

All of this opens up a large can of worms in terms of our long term future with Solaris, but that's another entry.

solaris/SolarisSlowdown written at 00:03:48; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.