May 24, 11
Apr 6, 11
This is an exciting time in the mobile space, and it's great to see new devices enter the market with such excellent support for web standards. There were only a few minor glitches to work out before the full desktop version of amoebaOS was running perfectly on the new BlackBerry PlayBook! Running a desktop-like OS on a table might seem weird, but we've had a lot of requests for that exact setup (similarly with ChromeOS, too). Perhaps the way of the future is to buy a web-enabled device that provides extremely simple productivity functions, and then use an online OS like amoebaOS to gain access to desktop-like functionality only when you need it.
Is there a device or OS you want to use amoebaOS on that we don't currently support? Let us know, and we'll do our best to get amoebaOS running on it.
Apr 1, 11
We've decided to take a different direction with the amoebaOS brand. Here's a sneak peek of our new logo:
New Slogan / Tagline:
amoebaOS is an online Operating System that gives you salmon-like powers using the cloud. We call it the salmon-cloud. With this newfound power, our beta testers are capable of amazing salmon-ey stuff:
editing pictures (like a salmon!)
listening to music (like a salmon!)
creating apps (very much like a salmon!)
Feb 19, 11
There's a solution though. Much more aggressive caching is going to help with this. Right now apps are always requested from the server as if there might be changes (it's possible, because you can run apps while editing them). With the addition of two-way communication with the server, this will become completely obsolete. If a file is open, the OS will then be sent notifications if changes are made to that file (until it is closed). That means the app launcher doesn't have to ask the server for an app it already has, it can already tell if the app has been modified or not. The same is true for files. If an app is reading preferences from a file, it will be able to request that file a million times and the file will only be downloaded once (assuming it doesn't change).
Also, another really cool feature coming is client-side file awareness. Like I talked about above where the server tells your browser a file has been changed, your browser will also be able to do the same. If an application saves a file, the system will store that as the cached version of the file. Then when something else goes to access it, the cached version is used. It's going to increase RAM usage a bit, but there's a solution for that too!
WebkitSQLite and HTML5 LocalStorage. Right now, when apps want to store a big chunk of data, they store it in-memory (seem a bit weird? it's actually the norm for web apps). So, to aid in killing this silly pattern, I'm going to be writing an extremely generic sandboxed cache API. Each application gets it's own cache when launched, and it can storeany information in that cache (literally anything: files, prefs, JSON, etc). When the application is closed, the cache is cleared. In Chrome, Safari, Firefox, Opera and IE9 this cache will use no RAM at all. This will be a massive reduction in the overall memory footprint of amoebaOS. In Internet Explorer 8 and below, the cache will be store in-memory because the read/write speed on their DOMStorage mechanism is terrible.
Anyway, the cache stuff is actually a pretty quick thing to add so count on that coming sooner than later. The filesystem additions, new Filesystem API and push API are already started, I just need a big chunk of development time in order to finish and test them (it's crucial they work perfectly and don't break compatibility with current apps).