Erlang on LLVM? or: Outsource your JIT!
[info]chanson
Has anyone been working on using LLVM to do just-in-time code generation for the Erlang virtual machine?

Depending on the design and structure of the Erlang virtual machine, it doesn't seem like it would be all that tough a project. And it could provide a nice performance boost for those projects that are starting to use Erlang like CouchDB and ejabberd.

For an example of what I'm talking about, there's a project called VMKit that has implemented the Java and .NET virtual machines atop LLVM with reasonable performance. Essentially, if you have a virtual machine, rather than skipping either just-in-time or static code generation entirely, or trying to do it all yourself for some specific platform on which you want to run, take a look at what you can do with LLVM and see if you can leverage its code generation instead.

Why is Twitter not just Jabber?
[info]chanson
Twitter is a way to post a short message to a wide group of subscribers, and to receive messages posted by a wide group of subscribers.

That's instant messaging. There's already a standard protocol for it: Jabber (XMPP).

Why not just use it? Why invent a new protocol?!

Actually, Twitter already does have experimental XMPP access to the full timeline — rather than to individual timelines, or to your friends' timelines — and you can use it to build things like TweetMaps and TweetClouds and Quotably and…

But Twitter should really be built entirely around XMPP. It shouldn't be a web app at all, though it could certainly have a web front-end. In case you doubt me, here's an example Twitter-like service implemented by Process One atop the ejabberd XMPP application server.

OLPC chat bug (and fix)
[info]chanson
One thing that became apparent as I tried out the collaboration features is that there's a bug in the Chat activity on the OLPC. As you chat, it will continually scroll to the end. It's very easy to fix though, just follow the directions here.

Furthermore, if you actually take a look at the fixed chat.py you can see a little bit of what goes into an Activity in Sugar, the OLPC human interface and high-level software stack.

Trying out the OLPC collaboration features with xochat.org
[info]chanson
The collaboration features on the OLPC use the Extensible Messaging and Presence Protocol (XMPP) — otherwise known as Jabber — to manage presence. There's an overview of the entire collaboration stack on the OLPC wiki under Shared Sugar Activities.

Essentially, what this means is that as long as there's a properly-configured Jabber server that you can connect to, you can find other OLPC users and interact with them over the network. Tom Hoffman graciously set up just such a server at xochat.org, and I've talked with a few different people there and visited a shared document.

To tell your XO to use the xochat.org Jabber server, you can just open the Terminal activity and do the following:
$ sugar-control-panel -g jabber > ~/old-jabber-server
$ sugar-control-panel -s jabber xochat.org
That will save your old Jabber server in the file old-jabber-server in your home directory, and tell the system to use a new one. However, the system won't automatically update itself after this change; to do that, you need to hold down the alt and ctrl keys, and press erase to restart the interface.

Once you've told your OLPC to use the xochat.org Jabber server and restarted the interface, you can just press the Neighborhood button — that's the circle with a ring of several dots in it — and you'll see everybody who's using an OLPC with that server. You can create group chats, share documents, and use all of the OLPC collaboration features because all they really require is a way to locate the users you want to collaborate with. The higher-level software on the OLPC will take care of the rest.

Scoble whines about poor, poor Microsoft (again)
[info]chanson
Scoble is going on about how there's no business case for allowing third-party instant messaging clients free access to MSN Messenger, and how people criticizing the move need to support their criticisms with business cases and stop asking for things for free. Evidently it hurt his feelings when Dan Shafer called them nimrods for this decision.

This is the heart of the Microsoft attitude, which I've decided to start calling Microsoft Persecution Complex. Even though they have 90% market penetration and around $50 billion in the bank, Microsoft and its employees from the top on down still behave as though they're only a week or two from bankruptcy. And they appear to honestly believe it too — that if one small company flies under their radar without being coopted and releases one killer app, it'll be Game Over for Microsoft. This paranoia drives most of their behavior towards the outside, from various lock-in attempts like the MSN Messenger gateway, to their attempts to patent everything they do no matter how trivial, to their "We have to screw everybody else before they screw us because you know they're going to try to!" business practices. It's paranoia, pure and simple.

Here's what I posted in response to Scoble in his weblog's comments area:

Instant messaging is like email. It only works - it only has sufficient network effects - when enough people interoperate. The network effect is king, and Microsoft is gambling that they have enough of one going that shutting off outside access won't derail it. Doesn't sound like a wise bet to me.

This is exactly like announcing that the next version of Outlook will only let you email other Outlook users and talk to Exchange servers. It may look good for business in the very short term ("Just think of all that potential revenue that's going to be realized!"), but you'd see people switching mail clients and servers so fast you'd barely be able to make sense of it.

Fortunately, moves like these will drive people to use Jabber or another truly open, interoperable, IETF-managed instant messaging system quickly. Eventually to keep playing in the instant messaging space Microsoft, Yahoo!, and AOL will have to support the Internet standard. And at that point, the end users really win because they won't be locked in the trunk by any vendor.

Oh, and Scoble? You are nimrods. The reason you're nimrods is because your first instinct was to criticize the person complaining about an attempt at lock-in for wanting something for free and not considering poor, poor Microsoft's business needs, rather than asking what was best for Microsoft's customers. That's a very Microsoft behavior, and it's one of the things that needs to change about Microsoft culture. If you'd actually asked what was best for the customers, you might have come to a different conclusion.

Believe it or not, Trillian users are Microsoft customers! (Trillian only runs on Windows.) And isn't it a free application that replaces another free application that's used to access a free service? Hmm, what's the business case again for making MSN Messenger free but locking out another free application on the same platform?