In a previous post I referred to the refocusing of the OLPC project. Part of the reorganisation was to split off the Sugar shell from the core OLPC project, at which time Sugar Labs became separate and has developed the shell in its own right for a number of platforms. Since there is so much expectation of the merits of Sugar as an educational tool, it would be reasonable to expect that one day it will be ported to Windows and be able to run upon many more PCs worldwide than is currently the case.
At the moment with the lack of a proper port, there are several options which produce only a demo view of Sugar:
-
LiveCD
-
LiveUSB boot
-
Virtual machine
-
Emulator
I have played with the last two in particular. In theory the virtual machine would be an option but it is one that would have to be physically installed on each computer in turn. This is because Oracle VirtualBox, while it contains its own RDP server which can allow connections directly to VMs, it is not a session host server like Windows Remote Desktop Services is. This means one instance of the VM cannot spawn multiple RD sessions to allow each user to have their own shell instance of a VM.
The second issue is that the virtual machine is set up with one single virtual hard disk file which is quite large, some 540 MB at the present time. I don’t know if the shell can save data to this file and thus save the user state between sessions. If it can, then the only way of backing up this session is to copy the entire large vhd which is rather inefficient. If it was expected that a user would have data that is worthwhile to be saved and the virtual machine is capable of saving it, then the first enhancement necessary is to have a second vhd to save the user data. With a bit of work this file could be specified in the VM settings to be on a network volume and therefore a user would be able to retrieve their session while in different locations.
However everything I have written herein is somewhat speculative as it is not clear whether the VM edition of Sugar is intended to be usable in a production setting or is just another demo edition.
Another option is if this system can be made to work on a Linux terminal server (LTSP), it could be functional for any clients that want to connect, the sticking point so far seems to be whether it requires to be netbooted from the server or can just start a session in the OS’s RDP client. PXE requires more work to set up and it precludes user switching between two different terminal servers if there is more than one on a network. From my POV the PXE boot would be more complex and tricky, from my POV the whole point of virtualisation (whether session host or VM) is to avoid having to change boot configurations.