While I agree that it's important to pay attention to this problem of maintenance of existing systems, I'd argue that this is still a form of technical debt; not spending time keeping systems up-to-date is still a shortcut that leads to pain in the long term, which is exactly the definition of technical debt. I think a better analogy is the distinction between taking vitamins and taking painkillers: the latter makes you feel better when you're sick, but the former can reduce the likelihood of getting sick in the first place.

I'm curious to hear why you find PUT confusing, since I personally find it much more intuitive, but maybe that's because I've remolded my brain sufficiently. :) Using Apache is of course just an example. Working closer to HTTP's core concepts means firstly that more of the required software stack is already out there and secondly that the PubSubHubbub spec can be simpler since it can just refer to HTTP's existing definitions of these concepts. And as for "who uses Apache for their PubSubHubbub listener?", right now that's probably close to zero but I wonder if that's just because it hasn't been easy until now. It's unlikely that someone would use a feed-like resource in this way, since they'll want some application code to extract the items out of the feed rather than to just store the feed verbatim, but for something more atomic like an image or a Word document it's more likely that I'd just want to copy the data byte-for-byte onto my own server, and most HTTP servers can already do this. And sure, we can debate this in the group, but the debate there tends to get pretty heated so I think I'll wait until later, when I'm less busy, to start a thread. :)

Julien, The difference is really just that PUT has better-defined semantics and therefore generic server software like Apache HTTP can handle it out of the box for simple cases rather than needing to run some custom application code to handle the notification. Of course, in many cases you will want a custom application to do something deeper with the new data, but I like the idea of applying this to simple cases like, for example, copying an image onto another server and updating it when the source changes. Since HTTP basically defines POST as "some action but we don't know what it is" you always need specialized software to handle it, and the PubSubHubbub spec needs more prose on how to process the notification rather than just referring to what's been established by HTTP. But really my proposal was not about using PUT specifically but rather applying the full set of HTTP resource manipulation verbs (DELETE and PATCH too) to this problem rather than wrapping the result in a "notification envelope" as we do for Atom and then having to re-invent mechanisms to communicate the difference between "this is a full resource", "this is a delta" and "this is a notification that the resource no longer exists".

Most commercial software has any warranty disclaimed by the EULA too, so that's a bit dumb. Not to mention that there are a bunch of risks around commercial software: bugs you can't see or fix for yourself because the source is unavailable, company going out of business and software going unmaintained, etc, etc. Dumb, du-dumb dumb dumb!

The problem with this idea is that the password on sudo is not there to authenticate your connection -- that's what the auth handshake at connection time is for -- it's there to try to prevent attacks of the class where you walk off and leave your desktop unlocked and someone else walks up and uses your already-established session to run privileged commands. Therefore, for the purpose that password check is intended for, you defeat the object entirely by making it just re-use the ambient connection auth credentials; you might as well just enable NOPASSWD on sudo and have done with it, since the result will ultimately be the same.

I used to do this except that I would have my email clients write my outgoing messages directly into the archive by configuring it to be the "Sent" folder. Then I view my Inbox in flat mode as a todo list of things to deal with and have the archive folder in threaded mode where I can see context if I need to. However, since Exchange makes it hard (impossible?) for me to configure server-side filters without a Windows I'm back to manually managing my mail. *sigh*

TypePad generates open graph protocol markup to help Facebook find the right picture, but it generates a tag for each of the images in your post and then a tag for your userpic. (and then, for some reason, a second identical tag for your userpic.) So my best guess would be that Facebook was previously taking the first og:image tag and using that, but it switched to the last og:image tag instead? It doesn't look like anything changed on the TypePad side recently that would inspire this change in behavior, but I guess some further investigation is required.

I wish more sites would follow TypePad's lead with default userpics. As you said, they are attractive but don't convey any particular mood or personality, so they don't inadvertently set any preconceptions about the person who they are associated with. But best of all each user -- even anonymous commenters -- gets one assigned at random from a pool of 20 and that userpic sticks with them until they upload a "real" userpic, so if you have a discussion with 3 different default-userpic users, chances are they'll each have a different but consistent userpic so you can easily follow who is who not only in that discussion but across discussions too. The TypePad "spirograph" userpics have a big place in my heart because, although I can take no credit whatsoever for the ideas behind them, implementing them in code was my very first project when I started at Six Apart and I loved the idea as soon as it was explained to me by all of these new coworkers I barely knew. :)

This blog post is too long.

He's so cute. When can I meet him? :)