Wandering Thoughts archives

How to lose readers of your syndication feed

It's pretty simple:

• change your syndication feed URL
• but don't remove or redirect the old feed, just stop updating it
• and don't put up an entry about it (visible in the old feed).

Readers who are not especially attentive may not notice for weeks, only vaguely wondering if you've taken a vacation or something. Especially if they read a fair amount of feeds and are behind in their reading.

As far as I've gathered, most feed readers are perfectly willing to have the feed format change out from under them, so there's no real reason not to redirect old feed URLs to the new canonical one. If you have mass quantities of automatically generated feeds this may be a bit challenging to do, but most things with feeds just have one or two.

(In theory a permanent redirection should even cause feed readers to update their internal memory of where to get the feed from, but I'm willing to bet that that's mostly honored in the breach.)

In my case, the only way I noticed was that someone else linked to an entry I hadn't seen on the blog in question. When I clicked through to read it, assuming it was an old one, I happened to notice that it was actually a recent entry, and that set me to wondering why I hadn't seen it in the feed.

Most new products are upgrades

Most new products are upgrades of old ones. I don't mean in the sense of upgrade sales (although that too), but in terms of the code they're built from; they are revisions of existing codebases, not freshly written from scratch.

This has extremely rational economic and development reasons, as articulated by Joel Spolsky among others; there is a lot of money and value in existing codebases. But ignoring all the arguments about cost and captured knowledge and so on, there's another big reason this is necessary: it's our lack of programming productivity. We just can't (re)produce the code that fast; if we want to move forward, to have new features and so on, we have to reuse the existing codebase.

And having new stuff is what drives development; if there's nothing new, there's no point in doing it. (Mind you, sometimes the 'something new' is 'works on a new machine' or 'has less bugs'.)

The only area that I think still approaches a 'build it from scratch every time' model these days is games, and my impression is that even there it's no longer really true, now that there are graphics engines and physics libraries and so on. (And using them is increasingly necessary to get a modern game out in a sane amount of time.)

(To a fair extent the smaller your product is, the more you can change it each time. I suspect that this is one factor that gets companies into rewrite trouble as they grow, because they usually start with small products.)

Hardware RAID versus software RAID

Here's a good argument-starting question: which is faster and/or better, hardware RAID or software RAID?

A lot of conventional wisdom says hardware RAID, but I mostly disagree. Let's ask the inverse question: how (or when) can hardware RAID be faster than software RAID?

If you're doing RAID-5, the hardware could do XOR faster than your CPU can. But in modern systems XOR performance is pretty much constrained by the memory bandwidth, not CPU power. It is possible to have better memory bandwidth than the CPU (graphics cards do), but it's not cheap.

If you're doing RAID-1, hardware RAID can reduce the bus bandwidth needed for writes from N DMA transfers to N disks to one DMA transfer to itself. But for this to make your system faster, you need to be saturating the PCI bus bandwidth with write traffic, which is not exactly common. (In theory you might see this with RAID-5 too.)

I believe that's it. (Additions and corrections welcome.)

The usual retort for all this is that while hardware RAID may be no faster than software RAID, at least you're offloading the work from your main CPU so the system's overall speed goes up. However, for this to matter your system needs to be CPU constrained and doing significant write IO (if you only have insignificant write IO, the extra CPU usage for software RAID will also be small). This is not exactly common either.

There is one downside for software RAID: the operating system has to be running in order to use it, which can complicate early boot. But software RAID also has a lot of upsides, including hardware independence. (You're dependent on software, but you pretty much are anyways; only a few crazy people try moving filesystems between different operating systems.)

The one wildcard I can see in hardware RAID's favour is virtualization, which might deliver a future of heavily used hardware running close to both CPU and IO saturation.

(This entry is brought to you by the Tivoli Storage Manager documentation I was plowing through today, which made me grind my teeth by tossing off a 'hardware RAID is better than software RAID' bit in passing.)

Slashdot's tacit admission of failure

Slashdot has recently started running what it calls 'Backslash' stories, which have (as it puts it):

[...] some of the most interesting comments and exchanges on a handful of yesterday's Slashdot posts [...]

To me, the most interesting thing about these stories is that they are a tacit admission that Slashdot's comment management model is broken and that a lot of people don't read the comments on Slashdot stories. If most people did regularly read Slashdot comments, Backslash stories would be redundant and thus unnecessary. That Slashdot has introduced them and made them a regular feature suggests that they are not.

(This matches anecdotal evidence; neither I nor a fair number of the people I chat with online bother to read the comments on Slashdot stories and haven't for some time. It's just not worth it, because even at +5 there's too much noise in that signal.)

Since some of the comments that get promoted to Backslash stories are not among the highest-rated comments, this isn't just that there are too many highest-rated comments. It seems to be what Slashdot considers an outright failure of the system to rate comments as highly as they deserve, and indeed one recently used comment was only rated +2 (where +5 is the highest). (The Backslash stories also don't necessarily run the full comments, so there is editing even beyond mere selection and spelling corrections.)

It'll be interesting to see if other community moderated websites follow Slashdot's lead and make similar changes, or for that matter if Slashdot makes more moves to a more editor-based environment to differentiate itself from sites like reddit and digg (ceding more and more of the 'moderated by the community' ground to them).