The New York Times Open blog takes a look at Amazon’s SimpleDB. I have to agree with him, web-scale computing architecture is a fascinating topic. I’ve been meaning to set aside time to look at SimpleDB; it feels like the big gap in web-scale is standard/open APIs for structured data storage. EC2 gives you compute (and the API is fairly obvious), and S3 is your big key-value bucket, but until Amazon announced SimpleDB there were really only hacks for clustering MySQL. And that only gets you so far.

Another interesting project in this area is CouchDB.

Saw this short article about a new IEEE working group on a networking standard for devices in or on the human body. One cited use case is controlling a pacemaker from a wristwatch, which makes a lot of sense – it’d be pretty nice to be able to make small tweaks to devices like that without requiring open heart surgery.

What is kind of scary though is the security implications. The security disaster that was WEP shows us how important this stuff is to get right. Presumably a pacemaker or other critical device wouldn’t have a “turn off” function, but still…the implications sound like science fiction. Your wristwatch is pulling data from the web, gets cracked, and the next time you shake someone’s hand it tries to pass a digital virus to the devices in or on them…

Realistically though, pretty much everyone is far more likely to die in a car accident than have a digital virus for the forseeable future. So buckle up! But when it comes around, also be sure to apply security updates for your body =)

Fedora

It was fairly recently, when I installed OCaml on my Fedora 8 system with a quick yum install that it really struck me just how far the Fedora project has come in the last few years. Long ago when I was active in Debian, one of the things I really loved about Debian was how comprehensive the package set was – if you were a fan of semi-obscure languages like OCaml, Debian was the place to be. I even gave a talk about that in 2002.

Back then in Fedora (maybe it was even RHL timeframe), the default OS was very well put together, but if you wanted to stray a bit outside of what was shipped on the single CD – you had to do stuff like manually download the RPMs from the OCaml website. No provision for automatic updates, etc. It kinda sucked.

Fast forward to today – Fedora is not just a well put together default desktop, but also a pretty growing comprehensive set of over 8000 binary packages, active subteams concentrating on areas like awesome Java support, virtualization, and plenty more.

It really does kick ass. For sure there’s a few things we need to do still like sudo by default, but the balance of things has certainly shifted.

Firefox

It’s hard to describe how much better the Firefox 3 CVS is compared to Firefox 2. The beta 1 release notes just don’t do it justice, you have to check out reviews from Ars Technica or elsewhere. The awesomebar is something that really is hard to live without after you’ve tried it.

But what I wanted to talk about in particular in this blog entry is some of the really nice Linux-specific integration work that’s landed recently. A screenshot gives you an idea:

Firefox 3 CVS as of 2007-11-30

Note in particular the native tab look and use of GTK+ stock icons; this is part of the gnomestripe theme. Not pictured is the native look for form field widgets, along with a lot of other under-the-hood work like Cairo.

The increased focus on good platform integration is driven by talented people like Alex Faaborg and others who realize that being a crossplatform application doesn’t mean you have to look and feel exactly the same everywhere – what you have to do is be a blend of the good parts of your application and the platform. So Firefox 3 on Linux has the same kickass addons and other aspects that make it Firefox, while at the same time feeling much more like a part of your desktop.

Sandy blogged about Forkolator, which is a project to make forking web applications easy. There isn’t yet a lot of documentation on Forkolator, but from what I can glean from the web site and a glance at the source code, the idea is basically that each web application (Wikipedia, GMail, Forkolator itself) would include an IDE for forking the app.

Apps as platforms

In Marc Andreessen’s categorization, that would make Forkolator-using applications level 3 platforms – the hardest to create.

Sandy paraphrases Erik saying:

Erik believes that the data layer of the app would probably have to be well-defined and untouchable by forkers.

That makes things easier (though still far from easy), but we should consider that it also limits what you can implement in your fork. For example, I don’t see how you could realistically implement a label system for your mail app without the ability to add new database tables or the equivalent.

Writing web apps is just hard

Aside from the whole freedom aspect, one thing that we should note is that writing web applications is generally very hard, period. It requires a lot of expertise to do even passably well. Depending on the application of course; an online stopwatch is a little bit easier than eBay. Is there work on making writing web apps easier that could be leveraged to also improve forking apps?

Incentive

One angle that seems critical to any effort like this is creating an incentive for the application maintainer to support these changes.

Levels of modification and APIs

If the goal is “chrome” level modifications, an entirely different approach would be Greasemonkey-style client changes. From what I understand (though I haven’t looked myself), GMail effectively has a JavaScript API one can code to, and this lets things like Better GMail work in a maintainable way. Of course though, it’s usually not going to be straightforward for a web application author to fold a Greasemonkey script back into the site.

So to make a system maintainable there have to be defined APIs. As Andreessen says, a level 3 platform requires all of the level 1 and 2 work. I don’t see how something like Forkolator could work without them. If you want to make say a modification to Wikipedia that makes editing more collaborative, it would need to hook into the APIs for modifying pages, etc.

Some attempt at a conclusion

I’m not sure I’d completely agree with the assertion that “web apps are killing free software”; Free Software use on both the client and the server is growing (at least it appears so to me). Now, web apps are definitely killing certain types of software, Free or not. The challenge is to preserve the spirit of Free Software through a computing shift.

I think that while we don’t really have a shared “free/open/principled” service definition yet, there’s a general consensus around some points like data access APIs and source code availability. So it will make sense to continue evaluating services in that context – if they support a Forkolator-style approach, that’s even better.

Havoc and I were interviewed on LugRadio. Listening to the high quality Ogg now. They had a lot of good questions, it was friendlier than I expected given the intimidating pictures of the interviewers on the website =)

Improving the command line

One of the goals I had when starting the Hotwire shell project was to experiment with possible UI improvements to the command line[1]. The old terminal+shell combination gives quick access to a lot of the system, but the tty interface is very limited. I think Hotwire does successfully demonstrate that you can improve on things like ls while still retaining most of the general power of a traditional Unix terminal+shell.

How not to do it

One of the things I’ve wanted to improve since the beginning of the project was the ssh experience. Now when you think of “GUI SSH”, you may be imagining something like Putty. No offense to Simon or any of the Putty developers who brought a very useful bit of Free Software to those of us periodically stuck on Windows, but Putty has a poor user interface. It’s quite complex and confusing if you just want to connect to a remote computer; all of the useful options are mixed in with the options created for all of the 3 people in the world using Kerberized SSH or whatever, it doesn’t remember which hosts I use most, etc.

What is HotSSH

HotSSH is my afternoon hack to create a thin SSH-specific runtime UI, written in ~500 lines of Python/GTK+. Here is how you are expected to run it (using e.g. bash):

$ alias ssh='/path/to/hotssh/bin/hotssh'
$ ssh example.com

In other words, I’m not breaking your workflow here by making you type into some crappy dialog. HotSSH is designed to be launched from your existing shell. You can keep taking advantage of any smarts your shell has, like intelligent host completion, history etc. So what does HotSSH do then? A picture is in order here:

OpenSSH icon, knows which host you’re connected to, etc.

So when you type ssh hostname from your shell, it opens a new tab in your existing HotSSH window, instead of taking over your terminal. You get a nice OpenSSH blowfish icon in your task list instead of an undifferentiated terminal icon. In the future there will be more, here’s the current TODO:

* Connect dialog, with completion from known_hosts
* Reconnect button
* Open SFTP button?
* <owen> … doing a list down the left rather than tabs with both favorites and running ssh, and have running ssh bold
* Latency display (not sure how to implement this with OpenSSH)

And that’s about it. Right now I’m tentatively planning to ship HotSSH with Hotwire, so Hotwire users get a nicer out of the box SSH experience, but I did make it a separate code base, so if you don’t yet use Hotwire you can still take advantage of HotSSH. Here’s the Git repository:

git clone http://submind.verbum.org/~walters/hotssh.git

Send any feedback, patches etc. you have for HotSSH to the Hotwire Discussion Group.

Relation to other projects

The Internet is full of projects which create terrible looking connection dialogs for SSH. I initially searched for a project like HotSSH trying to improve the post-connection aspect while still allowing you to use it as a drop-in replacement for the ssh command but didn’t find one. It would be interesting though if someone added support for HotSSH to say SSHMenu.

[1] – In addition to creating a shell that by default does not lose all of your history if your computer crashes.

<

I have a feeling that a few years from now we may look back on the Eee PC and say “Yep, that’s when Linux really entered the consumer market”. Going to various coffee shops in Cambridge, I see a ton of iBooks, followed by smaller Dells dominating the “lightweight student laptop” category. But at less than half the price of those the Eee could really undercut them while providing about as much functionality.

Overall, a good unconference. I got to see some old-school Debian developers that I last saw at Debconf 2 and meet in person others. Being in the same location as Colin Watson again was fun, though I don’t have long hair anymore so we’re harder to confuse.

One thing I noticed is that it seemed like everyone wanted to give a talk the first day, and then there were many fewer talks for the second. There was at least one talk the first day that I wanted to go to but had a conflict, whereas on the second day I only saw one talk that sounded compelling, though I had to leave early.

Upstart

Good talk led by Scott on Upstart. One idea was that Upstart could be the backend for D-Bus System Activation, which made a lot of sense to me. Upstart seems like a good choice for a new Fedora init system, though I would like to be sure the API is dead-simple for 3rd party vendors, and Upstart should have an easy way to distinguish between services which have state to save at shutdown and which can just be killed.

PackageKit

The PackageKit discussion was very good; we reached a consensus that it makes a lot of sense to share high level desktop components like an updater applet between distributions, and hopefully share more as time progresses.

Hotwire

Thanks Ryan from Ars Technica for the well written Hotwire article!

David – there’s nothing specific to Google in Prism. It’s also confusing in a sense that they mention Adobe AIR and Silverlight in the blog post, because Prism isn’t really competition for them; Prism is saying HTML and JavaScript is an OK platform. You could certainly still use Silverlight or Flash on a web service packaged using Prism though.

Prism is basically the equivalent of a .spec file or debian/ for a web service. In other words, it’s a bit of goo code, not really very complex or platform-like. Now I did raise the idea of possibly elevating some privileges for services packaged using Prism, but it’s likely not to be useful unless IE does something similar, which I doubt Microsoft would be interested in.

But the real thrust of your post is is about non-open services, and I wish I had a good answer here. I can say that I’ve recently removed some Google stuff from the default configuration of the GNOME Online Desktop work. And Havoc is working on a better system for giving the desktop information about which services you use, so we can adjust more sanely rather than having a set of default services.

The fact is, the computing industry is clearly moving in this direction. Ignoring it or stopping work on integrating with different services gives us less control over the future, not more.

Prism looks very cool. It fills in a gap we have in the GNOME Online Desktop project where we didn’t really have a good way to make web applications prominent in the desktop menus. Originally, we tried packaging things as RPMs, but it didn’t work very well because the web changes extremely quickly, and popular pages are can be highly locale-specific; desktop applications are none of these. Concretely, I don’t want to be the one updating spec files every time a new online office suite appears.

Prism starts this process naturally, from the web browser. Right now it’s basically a way to break things out of tabs sanely. Where I think things will get interesting is for example, elevating privileges somewhat for Prism applications, such as allowing web application authors to use the platform’s notification system.