IT'S PUBLIC!

This is what I have been working on for the past year and months.

Canonical Launches Web-Based Systems Management Tool For Ubuntu Deployments

On Jargon

Sometimes computing jargon is pretty idiotic.

Take the words "synchronous" and "asynchronous".

A synchronous API is one which blocks until a result is available.

An asynchronous API is one which returns immediately and lets you do other things until it notifies you of the result.

Now take the English definitions:

  Synchronous \Syn"chro*nous\, a. [Gr. ?; sy`n with + ? time. Cf.
     {Chronicle}.]
     Happening at the same time; simultaneous.

  Asynchronous \A*syn"chro*nous\, a. [Gr. ? not + synchronous.]
     Not simultaneous; not concurrent in time; -- opposed to
     {synchronous}.

(taken from Webster's 1913 American English dictionary)

So clearly the jargon meanings of the words are exactly the opposite of their English meanings. How did this come to be? I'm guessing it had something to do with the invention of preemptive threading. When preemptive threading came along, suddenly it was possible to make a blocking API —one that does not allow other code to execute while it is executing, because it hasn't yet returned—to allow for some concurrency, or synchrony. Preemptive threading allows a blocking API to be used synchronously. Somewhere along the lines, I assume, people forgot about the part of the sentence "preemptive threading allows ... to be used" and mangled it into "blocking = synchronous". The opposite of this, "asynchronous", soon followed, unrelated entirely to the actual semantics of APIs described as such.

You'd better enjoy your crappy jargon while it lasts, programmers. When my revolution comes, you'll be the first up against the wall.

Using a Nintendo DS Lite expansion cartridge in a classic DS

Last month I ordered a copy of the Nintendo DS Browser (by Opera) from Amazon. When it arrived I was all ready to start syphoning porns from the very air we breathe, but my dreams were to be cut short, as I discovered that the Opera browser requires a Memory Expansion Pak, which, while included, was incompatible with my *original* DS. It would only actually fit in a DS Lite. Through observation I deduced that the physical interface was basically the same and that it would probably work in my original DS, if it weren't for the lip that was on the top of the cartridge preventing me from actually pushing the thing far enough into the DS for it to make electronic contact. I decided that it was time for a hardware hack.

All I needed to find was a file to rip off the lip so that it could be jammed in there. I didn't have one, of course, so I got the closest thing I could find: a giant bolt that Jp had left over from a table he built.



After filing the lip off, my room smelled like burnt plastic all night. Oh well.



Then I tested that it would fit into the DS by half-inserting it upside down to see if the lip would fit past.



I then realized that if I actually put the cartridge into the DS, I would have no mechanism with which to remove it. I tried taping a twist-tie onto the cartridge but that proved pretty weak; I then realized that putting packing tape on both sides of the cartridge would be the best.



Going in..



I then jammed it the rest of the way in with the back end of my stylus.

It works wonderfully. There may be other DS Lite-only expansion cartridges out there, and this technique will probably work on those. Tell me if you have any luck.

Storm released

Canonical just released a Python-based ORM called Storm.

http://storm.canonical.com/

Mostly it was developed by Gustavo Niemeyer, but since we're in the same team at Canonical and it's developed primarily for our project, I have contributed bits and pieces.

Communal ties will of course require me to mention Storm in relation to Axiom. While I'm still a big fan of Axiom, I do think Storm is definitely the best ORM (now) available for any project which needs to talk to a database other than SQLite, especially remotely.

The design is simple and straightforward, and the code is well-tested. As a cranky, bitter young man, I must maintain my image; frankly, I'm really shocked by the low quality of the Leading ORMs available for Python or any other language. Storm, fortunately, does many of the things that are obvious to most people who are familiar with how to write software which uses an SQL database, and leaves out the useless crap. Of course, it's not perfect, but now that it's open source, we can accept your patches :-)

Figuring out the best way to use Storm from an asynchronous codebase will be a challenge, probably, but there are techniques for it that are usable right now—one of them being "Just block because your indexes are defined to be fast"—but that isn't always appropriate. There are some other simple options, and maybe some complex ones too. I'll probably post (or get someone else to post) about those in the future.