Wandering Thoughts archives

The hassle of email (as compared to RSS)

In my recent 'give me RSS feeds' entry I wrote in passing '[...] these days email is just too much of a hassle'. Which it is. Let me illustrate how.

To subscribe to new mailing lists these days I need to:

1. figure out how to subscribe
2. make up a new email address to give the list
3. go through a multi-stage subscription dance
4. make sure our antispam filters won't eat the list messages
5. adjust my filters to put the messages somewhere distinct
6. remember to check and read wherever I dumped it

In short, a hassle. Add bonus hassle if I ever want to unsubscribe to the list; often it's simpler to just kill the address. (Sometimes it's the only way out.)

A lot of this is due to spam. Some of it is due to vendor abuses of trust (leading to spam). Some of it is just because I no longer have any interest in sorting my inbox by hand; the volume is too high and my time is too short.

(Is it any wonder that reading mailing lists via newsgroups, especially newsgroups that someone else runs, is popular?)

Compare this to RSS:

• feed readers are good at showing me just updated feeds.
• feeds come pre-sorted from each other.
• subscribing to an RSS feed is easy.
• unsubscribing from an RSS feed is equally easy.
• I don't have to give you any information to subscribe.

It's sad to offhandedly write things like 'email is just too much of a hassle', and then realize that I mean it. It shouldn't be like this; it didn't used to be like this. But it is like this now. Sic transit gloria mundi.

Peter Drucker on the Five Deadly Business Sins

Every so often I read a genuinely electrifying article, one that makes me sit bolt upright in an 'ah-ha!' moment as it crystallizes things I've been stumbling towards.

Peter Drucker's The Five Deadly Business Sins is one such article. Go read it now; I'll wait. (It nailed me to the floor so much that I have a copy saved in case the Wall Street Journal ever removes it or moves it behind their pay-wall.)

Looking back over my entries, I can see how several of them are linked to various of Drucker's deadly sins; MarchOfTheCheap is probably the most direct example. I also had the experience of thinking 'I recognize that behavior', for example realizing that Ikea does priced based costing (they even tell you so) and suddenly understanding more of why.

It's kind of depressing to look around the tech landscape now and try to spot the deadly sins in action, because it's not too hard. It's more than ten years after Peter Drucker wrote his article and companies are still routinely doing all of them. (And as Drucker says at the end, it's not like this stuff was new when he wrote about it in 1993.)

I can even depress myself by taking an honest look at what we do around here in light of Drucker's fifth sin, 'feeding problems and starving opportunities'. What might we achieve if we were willing to make a serious investment in sysadmin infrastructure development? What opportunities to build better systems are we not even noticing?

(And it strikes me as telling that all the successful impressive systems, like Google, have put a lot of effort into developing things and not so much into firefighting monkeys.)

Van Jacobson illustrates the importance of cache effects

One of the most exciting presentation at the recent linux.conf.au 2006 conference (ironically held in New Zealand) was Van Jacobson's talk on speeding up the Linux networking stack. On a TCP stack that he says is already one of the fastest going, he managed to well over double the performance, while removing and simplifying code, even in driver hot paths.

(For more details, see David Miller's summary here; Van Jacobson's slides are here (1.4 MB PDF). Both are well worth reading.)

One of the things Van Jacobson did in this was to convert many of the queues used in the networking layers from linked lists (with locks) to what he calls a 'cache aware, cache-friendly queue' that is also lock-free. Converting just the driver level queues to these channels resulted in CPU usage dropping from 78% to 58% on a dual-CPU test machine.

This is not black magic; instead, this is a vivid illustration of just how much locks and cache contention cost you in practice. Multiple writers and atomic operations are now hugely expensive, so as Van Jacobson says, 'to go fast you want to have a single writer per [cache] line and no locks' (page 21 of his slides).

I can't help but note that that Van Jacobson's channels and his overall TCP processing architecture built around them don't look very much like the conventional threaded way to do parallel programming. Instead they smell a lot more like Hoare's CSP to me.

A suggestion: read your own syndication feed

I have a modest suggestion for everyone with a syndication feed (bloggers and otherwise, but especially bloggers): read your own syndication feeds. It saves embarrassment.

In theory this is unnecessary, because your blogging or publishing package makes syndication feeds just work. In practice I have seen all sorts of things happen, ranging from repeated entries to stray markup and text here and there. Reading your own feeds means that you find out about these sorts of things and can fix them.

(Counting on reader feedback to tell you about problems is optimistic. The people reading your feeds aren't normally hitting your site to start with, and errors mean they're probably not going to unless they really care. Even then, how easy have you made it for them to send feedback?)

Reading your own feeds also lets you check up on how well (or how badly) your formatting works in your entries. Again, there are surprises, some of them unpleasant (especially if you use a lot of CSS). As a bonus, those of you with partial-entry feeds can experience how annoying they are to users.

I strongly recommend that you use a feed reader that bitches about badly formed feeds; if your feed is malformed, some portion of your readers are getting garbled results. A local feed reader is better than a web-based one, because you can force updates whenever you need to. Keeners and people who do this professionally will want to check with multiple feed readers, minimally a popular local one and a web-based one such as Bloglines.

(You can also use the Feed Validator, although these days it insists on Atom 1.0 instead of the older Atom 0.3. Feedvalidator will even auto-discover your feeds off your web page, so you can check if that works too.)

I do this myself; it's found several problems, and otherwise I have the reassurance of knowing that everything really is working right.