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.

So, I realized yesterday just how important bling is to creating buzz around free software projects. Today then, I decided to finish something that’d been cooking for a while – Google Gadgets in the sidebar:

Google Gadgets in Online Desktop sidebar

It seems that I need to do some gtkmozembed hacking to kill the scrollbar. But otherwise, it looks cool. Once I figure out fun focus issues, you might even be able to type in the todo list. Also in this screenshot you can see the widget manager which landed recently.

You might find someone has made a YouTube video of it complete with soundtrack! Nice, even if it is an older version and looks a bit ugly compared to 0.599.

Nicu – the question is, who would you rather have as an ally? Mozilla, or Apple? I know which one I’d pick – the people who open-sourced the browser and have been maintaining the very good Firefox experience for Linux (even if there are details to fill in), not the company making a proprietary platform that competes with ours for desktop marketshare.

That said, there is actually work ongoing now to integrate Tango for example. I don’t think it’s going to be easier or make more sense to change rendering engines just for the remaining integration points that could have been done as a Mozilla patch instead.