Updated fatclient script to work with Jaunty

I recently found myself banging my head against a wall because my fatclient script had stopped working for Jaunty, even though I was assured that the plugins code had not been modified. After some help in the #ltsp channel, I added set +x to the top of my script and set -x to the bottom, and this way saw specifically where the script was dying, which turned out to be due to another recent script that was smashing my own variables. This kind of thing happens because I've not uploaded the script upstream. Anyway, I tested the script and built a jaunty gnome evnironment which worked without problems. It was nice to see the quite significant speed increase one can get by using the script on modern netbooks with atom processors. As always, copy the script here and save to /usr/share/ltsp/plugins/ltsp-build-client/Ubuntu/030-fatclient

Rate It! (Average 0, 0 votes)



June 10th Sugar collaboration testing session

Starting the session was a little chaotic, as this was the first time we've tried a group collaborative session, and there were no specific goals we had in mind. The idea was generally to see how collaboration worked in a mixed environment (0.82, 0.84, different distros, different network connections, etc)

The good news is, that for the most part, getting connected worked, and once in a collaborative session response times were quite good. This means that the underlying sharing mechanism works, it just doesn't respond very quickly. The bad news is that the server load is much worse than originally thought and expected.

From our initial experiences, it was clear that the sugar-presence framework had some huge problems in terms of visually representing who was connected, which activities were being shared, and who was sharing these activities. It was not clear where the major bottleneck was in terms of reaction and response, but suspicions lie at the ejabberd end of things. In future sessions we will have to restrict connections and individual details to the point that we can make proper measurements, and thereby find out what is going wrong, and at what point it is going wrong. Suspicions are that the jabber server in question (jabber.sugarlabs.org) didn't have gadget enabled, and was therefore broadcasting the list of all registered users continously, which would burden the server severely. The lag and server load also affected the visual clustering of users around specific activities

Though reaction times were very slow, the underlying sharing framework clearly works very well. Once users were connected, their connections were stable, and within specific activites, reaction times were fast and reliable. We were able to test a fair set of activities, some of which had better implementation of collaboration than others, and some of which didn't seem to have collaboration enabled at all.

We started off with the chat activity, which took a good 10 minutes before people started being able to connect to the initial shared session. Once connected, reaction times were pretty decent, and the frame showed all the connected users. There was a large variance between the shared buddies shown. Some users reported seeing 5 buddies, some 3, some 7, and some even saw buddies with a ??? as their handle. The screenshot below shows how it looked:

Speak was another interesting activity to share, as it allowed multiple people to join a session where the computer speaks out what's typed in the accent of the user's choosing. The choice of accent is used for the proper pronounciation in different languages normally, though there was much fun to be had speaking English words in the various accents. Below is a screen shot:

Reaction times were again very good once users had joined the activity. Buddies connected was highly variable from user to user again, and though clustering around activites did take for ever, it did eventually start to happen, as can be seen from the screenshot below:

Etoys was a surprisingly good collaborator. Once users were connected they were able to create various items, even animated and custom coded, and then send them through to the connected buddies. We just scratched the surface of this activity, and it was clear that some really interesting things are possible with collaborative etoys:

Other activities that worked quite well were Cartoon builder, connect, Maze, Colors, and Tam Tam. We were unable to get write or paint to collaborate, and are unsure as to why. Talking with the authors of these programs seems appropriate, though it has been verified that write, at least, does collaborate. Below is a screenshot of what it looked like when multiple activites were being shared:

Rate It! (Average 0, 0 votes)



Chrome for Linux (openSUSE)

It turns out, even though its not advertised anywhere, the Chrome browser, based on Chromium, Google's great open source browser project, is available for download. It has been available for windows for a while now and work on Linux just fine via crossover or Wine.


Although I had to link a couple of libraries to get it working on my openSUSE machine, it was not a lot of work, and I have to say my first impressions of it are very good. It is a lot faster than Mozilla in both starting up and then the rendering of pages. It seemed to be about 2 to 3 times faster and tracking its CPU and memory usage showed it was less resource hungry than Firefox too. It is of course lacking a lot of features including plugin support (think flash), printing, gears support, etc.


The most noticeable feature was the visual cache u have of sites you visit most often. This creates a kind of dynamic favorite bookmarks page, which seems vey useful (to me at least.) It seems they are building various snapshots a day, making it a project that is clearly very active. If you'd like to get it running on openSUSE, follow these instructions once you've downloaded the file chromium.zip from the latest snapshot directory: ( http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/ )





cd /home/_user_
wget http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/_latest-snapshot_/chrome-linux.zip

Make sure you replace _latest-snapshot_ with the latest snapshot number from the page, and _user_ with your home directory


unzip chrome-linux.zip
sudo ln -s /usr/lib/libnss3.so /usr/lib/libnss3.so.1d
sudo ln -s /usr/lib/libnssutil3.so /usr/lib/libnssutil3.so.1d
sudo ln -s /usr/lib/libsmime3.so /usr/lib/libsmime3.so.1d
sudo ln -s /usr/lib/libssl3.so /usr/lib/libssl3.so.1d
sudo ln -s /usr/lib/libplds4.so /usr/lib/libplds4.so.0d
sudo ln -s /usr/lib/libplc4.so /usr/lib/libplc4.so.0d
sudo ln -s /usr/lib/libnspr4.so /usr/lib/libnspr4.so.0d

You should now be able to run chrome via command line or by clicking on the binary. If you are on Ubuntu, there is a PPA where u can download the latest version: https://launchpad.net/~chromium-daily/+archive/ppa


Rate It! (Average 0, 0 votes)



Sugar Camp Reflections

Massive strides were made in community integration and community driven projects which will be considered or worked on in the coming months for the next release of Sugar, referred at this time as 0.86, and to be officially released in August of this year, following a 6 month release cycle of Gnome and many other open source projects.

Some of the more interesting changes that are being considered are a move away from matchbox to metacity, the well known and supported backend window manager used by Gnome. This should in theory allow for much greater integration into Gnome itself of individual sugar activities, as well as the launching of sugar in Gnome, and even speed improvements. This move is possible because the XO 1.5 will have more memory and better cpu speeds, as well as a move away from sugar being agnostic to that hardware. Sugar on a Stick was the big focus, which is now working quite well, but still not perfect.

A desire for a revival of the help application was shown and that will become one of the core fructose activities, though likely it will be totally updated and perhaps even interactive. Browse will be upgraded to have tabbed browsing, and have better support for integrated flash/gnash, pdf support and youtube casts. A demo was shown of a screencast of the usage of an activity coded at the camp, using turtle art. These quick advances show that it is not only possible to strengthen the Sugar Core and its activities, but also that one day soon we will have a ubiquitous sugar solution that will run on all distributions and platforms and most hardware.

The mention of fundraising was raised and there is a target in place of aquiring 100,000 euros within the next release cycle which will be used primarily in marketing and gathering core sugar people to the places they need face to face talks like the one provided in Paris.

Rate It! (Average 0, 0 votes)