bunnie took a brief look at it at CES.  Apparently they were quite grim when they (quickly) figured out who bunnie was.  Apparently the booth people had been told to look out for us   I guess our Open business model makes some folks nervous.

Python is an interesting choice - a system based on a more general scripting language was something we'd considered, along with all of the other (mutually incompatible) XML/Javascript/HTML file-splat schemes that most of the other widget systems use.

The problem with a generalized language, when one is pulling these untrusted binaries across the network, is security of the user's data.  If you care about that sort of thing (which we do), you really need a sandboxed environment, and at the moment, that pretty much comes down to Flash and Java.  Flash then becomes the natural choice if you want to make it easy to do interesting graphics, animation and audio, with all the assets in a single encapsulated file, and do it all in a small binary.

My limited understanding is that you have to explicitly install the widgets on the WidgetStation, which makes it more like how you'd manage a phone or computer's applications, than our system of a relatively stateless player pulling widgets on demand from a server.

The WidgetStation is an interesting product, and we'll be keeping our eye on it, and it's pretty clear they're doing the same.  We expect others to pop up over time.

Yes, we've fixed bugs and enhanced the performance and features of several of the existing widgets, which were effectively deployed immediately.

We'll be adding a form of caching to the chumby to reduce the amount of network traffic, but we'll still be able to update widgets and have them take effect pretty quickly.

Unfortunately, I haven't finished the Squeak port, but yes, you should be able to use Morphic.

What it needs is to be hooked up to the input devices (touchscreen, USB keyboard, etc) and an image built with the various elements positioned rationally for the small screen.

Um, well, widgets are written in Flash, so Rails, which is a server-side web application framework, probably wouldn't be too helpful, at least on the chumby itself.

You could probably use Rails combined with Ming or Open Laszlo on a server to produce Flash movies.

We provide a couple of programming languages so that people can write their own software and ignore normal chumby service, if they like.

At the moment, we have a serivce that serves Flash movies to the device, but we understand that folks may want to do other things, and we've simply made that easier rather than send out cease-and-desist letters as most companies are inclined to do.

It's up to you to figure out what to do with these tools we've provided.

If you want to play in our normal widget ecosystem, at the moment, that means Flash.

Not at the moment - a lot of people would like to be able to repurpose desktop widgets such as those used by Apple Dashboard, Yahoo Widgets, Google Gadgets, Microsoft WhateverTheyCallIt etc, which are typically a bizarre mishmash of XML, Javascript, HTML, a full browser with a rich selection of plugins, etc, but at this point is seems pretty unlikely we can support that sort of thing with the current hardware because these things are so resource intensive. It takes dozens of megabytes of software infrastructure just to run most of these widget systems and some pretty powerful processors.

The nice thing about Flash is that is can do everything those technologies can do, and more, in a small footprint (around 2 MB) and with a rational security model.  The downside is that existing widgets require a rewrite.

However, over time we expect embedded processors to become more powerful and cheaper so it's hard to say.

Widgets are Flash - there's no mechanism through our service to distribute other types of binaries as widgets.

The chumby has no native windowing system - several people (including me) have compiled and run nano-x successfully.  I've also experimented with GTK and some others, but they're much more difficult to cross-build, and use much more memory.

What's your concern with Flash?

Yes, you're right - we've definitely placed the user's security over developer convenience.

If we had gone with another technology besides Flash, I have to say we would have done something similar with security sandboxes.  Microsoft's alleged Flash-killer, Silverlight, uses exactly the same security model for exactly the same reasons - in fact, version 2.0 even understands existing Flash crossdomain.xml files.

There's a lot to be learned from the security disasters that have plagued Windows in particular, and we're not interested in being yet another vector for identity theft, spam, worms, botnets etc.

For your current application, all you need to do is put a small static file on your server.

You can certainly share your applications - just not through the standard Chumby Network widget service, which is simply not designed to do that.

If people want to create a directory of third-party applications on the chumby wiki (as I've done with the various languages, lighttpd and others), that's certainly fine with us.  I ported or found compatible versions of many of these languages and tools expressly for that purpose.

There also seems to be a Google Group of folks attempting to provide a replacement firmware image - we have no problem with that either.

Sorry to bump this thread, but it would be awesome if someone with the new toolchain installed could build python again and upload the build. I unfortunally don't have a linux install, so i can't build it myself

The ruby has been rebuilt for the GCC 4.3.2/EABI toolchain.