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?

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.

“Open Letter To Hobbyists” by Bill Gates, 1976:

Almost a year ago, Paul Allen and myself, expecting the hobby market to expand, hired Monte Davidoff and developed Altair BASIC. Though the initial work took only two months, the three of us have spent most of the last year documenting, improving and adding features to BASIC. Now we have 4K, 8K, EXTENDED, ROM and DISK BASIC. The value of the computer time we have used exceeds $40,000.
The feedback we have gotten from the hundreds of people who say they are using BASIC has all been positive. Two surprising things are apparent, however, 1) Most of these “users” never bought BASIC (less than 10% of all Altair owners have bought BASIC), and 2) The amount of royalties we have received from sales to hobbyists makes the time spent on Altair BASIC worth less than $2 an hour.

Why is this? As the majority of hobbyists must be aware, most of you steal your software. Hardware must be paid for, but software is something to share. Who cares if the people who worked on it get paid?

Is this fair? One thing you don’t do by stealing software is get back at MITS for some problem you may have had. MITS doesn’t make money selling software. The royalty paid to us, the manual, the tape and the overhead make it a break-even operation. One thing you do do is prevent good software from being written. Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free? The fact is, no one besides us has invested a lot of money in hobby software. We have written 6800 BASIC, and are writing 8080 APL and 6800 APL, but there is very little incentive to make this software available to hobbyists. Most directly, the thing you do is theft.

From Coding Horror, today:

I accept that software registration keys are a necessary evil for commercial software, and I resign myself to manually keeping track of them, and keying them in… Furthermore, registration keys are often the user’s first experience with our software– and first impressions matter.

Welcome to the age that thinks software is not the end, but just a means to an end; an end that is something useful to humans: communication, collaboration, creation, perhaps; something more than making someone else pay for something we made for the sole purpose of accomplishing our own goal that costs us zero dollars to give to other people.

Welcome to the age that has advanced itself.

This is disruptive technology. Deal with it.

(P.S. I’m around more often now and starting to contact people.)

Several of my peers recently asked how I’ve become knowledgeable about technology. I remember the first time I was asked: I was taken aback and didn’t know how to respond. Even dispensing with modesty, I never thought that I was ahead of any of my peers in this area, given how pervasive technology, and technologists, have become.

I continue to assert strongly that my domain specific knowledge isn’t nearly atypical but in fact is often below par. This is especially true in comparison to the people with whom I surround myself. Though, I have noticed that there are a lot of people here at Columbia who want to know more about technology but don’t really know how to do it. Most people think that an education in computer science will get you there, but learning how to learn aside (which itself is infinitely important), most of the stuff I’ve learned that is practical came from outside of the classroom.

I’ve since been reflecting on what I’ve done to further myself toward becoming a “master of the universe” (a technical term that means to be a domain expert). I’m definitely not there yet and I still have a lot to learn, but the fact is that I am continuing to learn. I force myself to learn. Taking into consideration peers of mine who are even better than I am as well as present and past mentors, here are some suggestions for becoming more aware and knowledgeable about technology. By no means is this authoritative or even deeply experienced advice. I’d be interested to look back at this list in a few years and see what I’d change myself.

• Ask questions. Lots of them. The point here is: Don’t be scared to ask a question. But don’t ask questions just to ask a question, unless everyone else is afraid to ask a question. The good questions will come naturally if you’re genuinely interested in something. The adage that there are no dumb questions is wrong, dumb questions abound and are annoying, but there are certainly no dumb legitimate questions. I personally have rolled my eyes at every question that was posed simply for gaining attention. On the other hand, I’ve actively encouraged questions that are in search of knowledge, even if I already knew the answer.

  Personal anecdote #1. I first interacted with my future uber-boss, Joe, at a panel discussion where I asked him a question. I followed up with him in an email after the talk with a few more questions, asking for references to learn more about his domain of expertise. He saw an opportunity and asked me to lunch to talk about my interests. We seemed to click well and have similar goals, and the rest is history.

  Personal anecdote #2. I was walking around near the South Street Seaport one day when I saw this tractor trailer that had the APC logo on it and a satellite on top. I walked around it and noticed the telecomm hookups it had. This was not your average bigrig. Even knowing what the company does, I didn’t really get why it had a truck parked in the Financial District. I told an executive-looking guy who shortly emerged from the truck who I am and asked what it was. He said, “You’re interested in this,” brought me inside, and introduced me to the chief engineer of this mobile datacenter project (a precursor even to Project Blackbox) whom I chatted with for a quite a while. It was a fun afternoon being able to geek out in a random location.

• Read a lot, including books and periodicals. Reading is the key to gaining knowledge and knowledge is power. It may be hard to take the time out of your day to read, what with being surrounded by more dynamic forms of entertainment, but if you’re serious in learning, you should be a serious reader.

  Read lots of dead-tree (meaning with physical pages) books. The first time though, just skim for overarching ideas and skip the details. Gain understanding on what a Linux bottom-half is, but don’t worry about knowing the source file they should be in. Figure out how a right outer join differs from an inner join, but don’t worry about knowing the implementation-level details of a B*-tree. Once you do this type of skimming, you should be conversational in a technology, you should be able to have a decent conversation with an expert in the field and show him that you know a thing or two. Then, if the book or subject interests you, read for the details. Master the book, read every word, and experiment with what you’ve learned between chapters. Don’t read dozens of chapters at a time or it won’t sink in.

  I often visualize the domains of knowledge I’ve come into contact with; this visualization takes the form of a long one-sided corridor with lots of doors. The topics I know most about are rooms that are brightly illuminated whose doors are removed and the topics that I know only exist are doors with labels. Whenever I start I new project, I think about this. I think about which doors I’ll have to open to explore in order to finish the project.

  Read lots of periodicals. Once you have a foundation in a particular domain or technology, periodicals are the best way of keeping on top of the goings on of that topic. This is how professionals stay professionals. Start with an accessible magazine, like Linux Journal, which doesn’t focus too much on any one thing. Once you get an understanding of the area, you can select something more specific like scientific or technology-specific journals and conferences. Included in periodicals should be electronic sources like Slashdot (for a 10,000ft view; please don’t read the comments and definitely don’t post any), wikis, and blogs.

  Get a good RSS reader. Once you amass all of these sources of information, it’s far too cumbersome to visit each of these websites. Let the RSS reader do the heavy lifting for you by retrieving articles and presenting them in one place. Set it to poll only every few hours, or else you’ll spend all day reading the news.

  Read a few papers. Scientific papers are how information is transferred from the guy who first thought of it to guys who can think about it more. They represent fresh knowledge, available to use to your advantage. Some of the ideas presented in papers are absolutely infeasible, but others are gold. Papers can be boring and hard to read, but give it enough practice and you’ll be read for what matters. Papers are great topics for discussion groups (see below).

  (For the record, I regularly read Usenix’s :login, Linux Journal, ACM Queue, IBM’s Journal of Research and Development, Intel’s Technology Journal. There are lots of blogs I normally read. I also frequent the proceedings of various conferences, like VLDB, SIGIR, and LISA; I really like reading these papers on the subway.)

  So read a lot. But, amidst reading, don’t forget to practice and investigate what you’ve read first hand. Look at code from professionals. Write some code, either toy code or a patch (see next two points). Run some queries. Do something.

• Join projects you’re not quite qualified for. Quickly learn the technologies that you need to in order to contribute. This is a fantastic motivator to discover new technologies and new aspects of technologies you’re already familiar with. You’ll get it wrong sometimes, but with a little exploring, you should be able to find a group that can foster your growth. Be sure to bring the areas of expertise you already do have to the team and use them effectively. Do not constantly join projects where you’re fully qualified to do, just to show off.
• Hack on bugs in a smallish open source project. Look over what open-source software you use and read over the project proposals of the groups participating in Google’s Summer of Code. Look at the bug lists of the projects that interest you. Checkout the anonymous code repository and look over some code. Join the project’s IRC channel and talk to the developers. (Praise them and say you’re interested in helping out). Subscribe to the developers’ mailing lists. Then start writing some code. The ideal project will be one where you’ll submit patches to the experienced developers and give you valuable feedback on how to make your code better. Less-than-ideal projects will be where you’re flamed for being a n00b.
• Get a good mentor. There are a lot of people out there who are friendly and were once a n00b. But now they’re friendly and experienced, which is a powerful combination for anyone starting to get interested in this arena. Ask someone if they’d be okay with looking over your code once in a while or talk about the industry and emerging technologies. Go out to lunch and talk about the journal you read last week. Discuss the patch you submitted on IRC.
• Form/Join a discussion group. I really like this idea of peers teaching a peer group. Each week, say, one member takes a turn presenting a paper or concept from a book (that they’ve already meticulously read) to the rest of the group. Each person presents something that interests them. There’s a lot of opportunity to learn about a diverse number of topics. About a year ago, a student here set up the Mainframe Interest Group, a weekly meeting of geeks to learn about an aged and often overlooked major technology. I didn’t appreciate it as much as I should have and consequently wasn’t as active in it as I should have been. Today, I sit in on the Database Research Group where some really cool, really smart graduate students and professors talk about current research in their field.
• Learn how to speak and write well in order to interact with people. A technologist is not some isolated coder sitting in the basement. A technologist grasps the role of technology and its interaction with its environment. He needs to convince others of its promise. This persuasion requires great communication skills, skills where surprising many people fail, and skills that are not listed on resumes (but should be if only there were a metric for it). Read Dale Carnegie’s books. For real practice, go participate in a discussion, join Toastmaster, or give a presentation to your peers. At university, don’t shy away from humanities classes that are reading- and writing-based. Take some non-required classes in a humanities subject in which you’re interested (mine is art history) and take the assignments seriously. Take some seminars that are discussion-based, participate often, and don’t sit in the back row.
• Meet as many people as possible. The more people you meet the more interesting people you talk to, the more interesting you get. N.B.: Interesting does not necessarily equal famous.
• Finally, Stand out. Disagree sometimes. Do stuff. No one ever got to be important by agreeing with everyone. Don’t be scared of confrontation when it’s called for. Actually go out and be productive.

(Jeff Atwood just published an extremely similar article to this one. He links to another similarly good piece by Rob Walling. If this pertained to you, read those too.)

Amazing when the kids of today (very probably, the Road Runner residential customer at cpe-66-67-116-12.rochester.res.rr.com) think creating a page on a publicly-modifiable wiki is “hacking.”

Message: 2
Date: Sat, 24 Mar 2007 18:03:23 -0700
From: Wiki Guest
Subject: [cvs] [Wiki] created: Hacked
To: cvs@lists.horde.org
Message-ID: <20070324180323.dwoylco4oow0o4w4@wiki.horde.org>
Content-Type: text/plain; charset=UTF-8

guest [66.67.116.12] Sat, 24 Mar 2007 18:03:23 -0700

Created page: http://wiki.horde.org/Hacked

HACKED BITCH!

I’ve compiled what seems to be a working Intel version of Matthew Rothenberg’s NmapFE for OS X out of the CVS tree. See my previous post as to why this is necessary. It can be downloaded here. The md5sum is: 37c6f6269608fdb3d62efbfa58cec123 36cc7e74f2e17b6c47148bfaa51dce91

UPDATE: I made some modifications to the DMG, thanks to Udi’s feedback. Download location is the same, the new md5sum is 36cc7e74f2e17b6c47148bfaa51dce91.

I’ve added this to the README.rtf:

Addendum: This version was compiled by Eric Garrido. If anyone reading this knows how to contact Matthew Rothenberg, please let me know.

** According to Matthew Rothenberg’s website for this project (http://faktory.org/m/software/nmap/), this software is released under the GPL. I’ve included a copy of the GPLv2 (the GPL license available at the time of Matthew’s last release) in the disk image.

The developer of NmapFE for OS X hasn’t made a release since late 2004 and consequently is using an outdated version of Nmap. Outdated to the point it doesn’t work:

sendto in send_ip_packet: sendto(5, packet, 28, 0, 127.0.0.1, 16) => Invalid argument
Sleeping 60 seconds then retrying

I’ve created an Intel build from CVS using nmap 4.20, which seems to work for me. It is available for download here.

Update: Actually, this doesn’t work very well. I’ll compile something soon that does.

My patch for adding RSS support to mailboxes in Horde IMP was committed. This is the largest patch I’ve submitted so far. Thanks to Chuck Hagenbuch and Michael Slusarz.

Date: Fri, 12 Jan 2007 00:14:22 -0800 (PST)
From: “Michael M Slusarz”
Subject: [cvs] commit: imp rss.php imp/docs CHANGES imp/templates/rss
mailbox.rss imp/themes feed-rss.xsl
To: cvs@lists.horde.org
Message-ID: <20070112081422.423A23513C@coyote.horde.org>

slusarz 2007-01-12 00:14:22 PST

Modified files:
docs CHANGES
Added files:
. rss.php
templates/rss mailbox.rss
themes feed-rss.xsl
Log:
Bug: 2733
Submitted by: Eric Garrido
Add RSS/Atom feed for mailboxes.

Revision Changes Path
1.1004 +7 -4 imp/docs/CHANGES
1.1 +102 -0 imp/rss.php (new)
1.1 +23 -0 imp/templates/rss/mailbox.rss (new)
1.1 +79 -0 imp/themes/feed-rss.xsl (new)

Chora Links:
http://cvs.horde.org/diff.php/imp/docs/CHANGES?r1=1.1003&r2=1.1004&ty=u
http://cvs.horde.org/co.php/imp/rss.php?r=1.1
http://cvs.horde.org/co.php/imp/templates/rss/mailbox.rss?r=1.1
http://cvs.horde.org/co.php/imp/themes/feed-rss.xsl?r=1.1

Hooray! Two more one-line patches! That brings my total up to 12 or so one-liners.

From Horde:

Date: Mon, 25 Dec 2006 09:59:06 -0800 (PST)
From: “Chuck Hagenbuch”
Subject: [cvs] commit: hordeweb/bounties bounties.php
To: cvs@lists.horde.org
Message-ID: <20061225175906.3B6D4351DE@coyote.horde.org>

chuck 2006-12-25 09:59:06 PST

Modified files:
bounties bounties.php
Log:
fix bug number
Submitted by: Eric Garrido

Revision Changes Path
1.175 +1 -1 hordeweb/bounties/bounties.php

Chora Links:
http://cvs.horde.org/diff.php/hordeweb/bounties/bounties.php?r1=1.174&r2=1.175&ty=u

and from ViewVC:

http://viewvc.tigris.org/issues/show_bug.cgi?id=189

FIXED:
Sending INSTALL
Sending viewvc.org/index.html
Transmitting file data ..
Committed revision 1226.

Thanks, Eric.