How much bandwidth do you think Google Reader saves, considering it can aggregate RSS pulls? I’d be really interested to see:

• …server logs from a really large blogging site and see how Google interacts with the site.
• …logs from several different sites to figure out how Google staggers them (hopefully distributed randomly), and
• …Google Reader usage statistics to correlate Reader membership to RSS pulls.

I was introduced to TED several months ago. For me, it’s an ingenious collection of original content, comprised of talks from some of today’s foremost thinkers. And, the vast majority of the speeches are under 20 minutes long, letting one learn about the world while brushing one’s teeth even.

Were I to post all of the clips I think are interesting, I’d end up duplicating TED.com’s index. I can’t help but share this one below: Sir Martin Rees discussing the future of Earth. Starting off by stating that he speaks “first as an astronomer and then as a worried member of the human race,” he asks the questions that I, hopefully along many others who are much smarter than me, have been thinking about for quite some time. In 17 minutes.

The other day, I was visiting a weblog that I wanted to include in my RSS aggregator. I clicked on the icon my web browser that indicates that the site provides such a feed and was presented with this*:

Great. Which one do I choose? I guess it’s clear: 2.0 is an order of magnitude better than .93, which it self must be three times better than 0.3. Right?

Uhh…No.

Okay. I’ve been a developer for a while and I’ve even developed RSS-related stuff. If I don’t know what the real differences are and how it affects my choice and subsequent enjoyment of the content, then I feel like most people wouldn’t either.

As syndication format family tree clearly shows, RSS .93 is the wicked step-child of earlier RSS 0.9x versions and the extinct scriptingNews formats. Basically, Dan Libby at Netscape borrowed (ahem.. stole, really, but for the better) in an effort toward standards. Then, RSS 2.0 is the inbred child of all RSS 0.9x versions, and, strangely, RSS 1.0. Then, the Atom format was created to make a fresh technology and leave all of the accumulated crud that an old protocol takes with it.

What does that all mean? Nothing. Not when the end user doesn’t care, just randomly picks one from the list, and hopes his or her client works well with it. Even after reading a more detailed account of RSS lineage, do you care which version of RSS you use? **

Any software developer will tell you that they’ve had the urge to throw out a piece of legacy code and start all over from scratch, applying best practices and lessons learned. That’s what Atom is supposed to be. It’s raison d’etre is to be the child who observes what his parents don’t like about themselves and improves upon those aspects.

On the Atom wikipedia page, these two points are listed among others under “Barriers to adoption”:

Many sites choose to publish their feeds in only a single format. For example CNN, the New York Times, and the BBC offer their web feeds only in RSS 2.0 format.

…which is actually doing a service to the user. This shouldn’t be criticized as a “barrier to adoption”, but a embrace of usability.

Sites that publish Atom will often publish RSS as well.

But why? If backward compatibility is a concern, then continue publishing content in all formats that you’ve given to users in the past, but advertise only the current best format.
I understand that backward support is good, so that people who subscribed to the RSS 0.93 feed don’t get burned when support for RSS 2.0 comes along. I also understand that too much meaningless choice for an unknowing consumer is just that: meaningless. And, if we’re supposed to be using standard technology, why are there three competing standards with no winner in sight? ***

Incompatibilities may exist with software being able to read the formats. **** Here is an informal survey of some popular feed readers on the formats discussed here:

Google Reader: RSS 0.92, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0
NewsFire: RSS 0.92, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0
RSSOwl: RSS 0.92, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0
Bloglines: RSS 0.92, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0
NetNewsWire: RSS 0.92, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0
FeedDaemon: RSS 0.92, RSS 1.0, RSS 2.0, Atom 0.3, Atom 1.0

Do you get the point?

Feedburner, a recent acquisition by Google, at least is tending toward the user:

Here we see a application-centric model of how to advertise syndication formats. Feedburner presents icons denoting popular applications that the user might use. If I’m a user of Pageflakes, I may not know anything about RSD 3.2 vs Atoms 1.4, but I do know that I go to www.pageflakes.com to see this week’s Dilbert cartoon on my homepage.

Here’s the bottom line: Stop advertising the older formats. It’s fine to continue to serve up the others, just don’t actively advertise it. No one cares what formats you advertise, or the format they click on, as long as they get the content they want.

I’ve chosen Atom. I think it’s in the winner in its modularity, feature-set, and future growth. I could go on about why I think it’s the right choice for this application, but here’s the point: no one cares.

* Admittedly, www.ericgar.com suffered from this affliction, which are the default options for Wordpress. This has been locally remedied.

** Ironically, that wikipedia article has an “Incompatibilities” section, with no “Features” section or similar. What is the (probably unintended) implication of that?

*** The Blu-ray vs. HD-DVD competition at least was better in this regard: there was a financial motive that would produce a winner. This is not so in RSS .93 vs 1.0 vs 2.0 vs Atom .93, Atom 1.0

**** Strangely, this isn’t listed under as a “barrier to adoption” on the Atom wikipedia page. I wonder why?

I was just looking through Adium’s changelog when I came across this:

I said, “Naw, that can’t be.” So I clicked on the Trac ticket number:

Freaking awesome.

When work is a big playground (albeit with real consequences of failure), it’s hard to get out of the mind set of the enterprise infrastructuralist.

Today I was walking back home and thinking, “My apartment is a single point of failure for some of my critically important data. Hmm. Okay, well, I should replicate it remotely somewhere. But if I were to do that, I might as well have remotely replicated storage as well. So I need some SAN space mirrored at the hardware level between two disparate geographic sites. But then, I need two dedicated servers co-located with that storage to actually serve me the files. Or maybe I should just use snap-mirrored NFS toasters.”

Then I came to my senses.

I’m still sad I don’t have my own datacenter(s).

…but the bartender had no idea what i was talking about.

(This, a thank you post, to whomever anonymously sent me a copy of The Hitchhiker’s Guide to the Galaxy. While I kind of enjoyed being made fun of for not having read it, it was really good to finally do it.)

A person on screen-devel, who shall respectfully remain nameless since he didn’t post to the list proper, sent me this in response to my proposed patch:

I would never use this feature because I would rather that window #n
always remain window #n, but I can see the usefulness of the feature
if you used to have more than 10 windows and now have fewer than 10
but some windows still bear numbers greater than 9, so you can go
back to using Ctrl-A to switch to them quickly.

My recommendation is that you call it compacting, not renumbering.
“renumber” doesn’t make it clear enough HOW they get new numbers.

To which I replied:

Thanks for the mail. Your comments are fair enough and definitely anticipated. I often can peak way above 10 windows, begrudgingly, and often want to migrate down to as few as possible so that the next window allocated is the highest available number. And, I’m an active user of the hardstatus line, including labeling windows. I implemented this because I know several people who use screen like I do, though knowing many people do not.

I do like your suggestion that the patch feature be called “compacting.” I was in fact struggling with how do best describe the action, and that does, in a single word. I will create a new patch sometime in the next week reflecting this, even just for my purposes.

I’m curious, though, for my own usage: how do you remember which window is which? What is your typical screen workflow?

Thanks,
Eric

After running a single session of screen for a long time, I often find that I have several gaps in the numerical ordering of windows. Using :number is definitely feasible, but it takes a bit more effort than I’d care to contribute every time I want to make my windows contiguously numbered.

I’ve created a patch against CVS HEAD to fill in the holes of the window numbering. It simply moves windows to lower positions until there are no holes left. Any [constructive] comments are welcome.

The patch can be found here. It was also sent to the screen-devel mailing list.

From O’Reilly:

named is pronounced “name-dee” and stands for “name server daemon.” BIND is pronounced to rhyme with “kind.” Some creative people have noticed the similarities in the names and choose to mispronounce them “bin-dee” and “named” (like “tamed”).