Hi Brendan, If you are using LTSP as your thin client technology, the majority of your issues have already been taken care of. These include: - collaboration via ejabberd. - home folders stored on server so backups are just a server side script (rsync.) - activities can be installed through browse in the regular way (only an admin can do that) and can be added removed as you wish, thereby populating the program list. Unless u mean individual programs for different users, in which case you'd probably need to virtualise sugar somehow or create custom chroots for it. - file server is not needed since you are in effect already storing everything on the server. - mounting local media (this is part of the underlying LTSP technology and has been available to all LTSP distributions for several years now. That means, usb, cdrom, hard drive, local printer, bluetooth, and sound are all working for all LTSPed distros, including for sugar.
These issues are relatively straight forward to fix: - printing should be an easy task to tackle, and just requires a connection to cupsys (this is really up to the programs to support this.) - logout instead of exit (apart from the design change of the button) - one simply needs to replicate the action of alt+cntrl+backspace which exits the client with no hanging processes. - Running just some sugar apps, or just one sugar app and not the whole thing seems a little like a waste of time since its very fast loading up and you need the underlying core anyway. I see no significant gains by launching just one app on top of sugar instead of all of it. However... you can do this with local apps, which is a plugin for LTSP that allows you to install whichever program you like directly into the thin client cpu and ram space, so it doesn't burden the server (useful for heavy apps like firefox+flash, video editting, blender, etc. >From what I can see, LTSP already does almost all of what you are wanting it to do, unless you use some other thin client technology. Kind Regards, David Van Assche www.nubae.com On Sat, Oct 25, 2008 at 3:30 AM, David Farning <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 23, 2008 at 3:25 PM, Brendan R. Powers <[EMAIL PROTECTED]> > wrote: >> >> Greetings, > > Hey Brendan, > Welcome to the list! >> >> Our company and developers are interested in getting involved with the >> development community for Sugar. We deploy Linux desktop solutions in >> schools in the United States via thin client and fat client methods. We >> believe that Sugar's collaboration tools, journal, and other features could >> be very appealing to younger grade (elementary and middle school) students >> and teachers. Several of our schools are interested in using Sugar in the >> classrooms already on their thin client desktops. > > Very cool, we are interested in making Sugar available to a wider audience! > >> >> We have the Ubuntu packages running fine, but it is evident that there are >> changes that should be made to Sugar when its not being used on the OLPC. >> Some of the challenges for deploying Sugar on desktops in a school >> environment are different than using it on standalone OLPCs, which need to >> be overcome for Sugar to take a major foothold independent of the OLPC. >> Below we have listed some of the issues we think need to be addressed based >> on our experience with working in schools. > > > What would be your preferred work flow? One thought would be set up a > client/server git tree for client/server development. Then, the work you, > and others do, can be pulled into the main tree. In the near future, > SugarLabs will be hosting a git server. Either we can host a C/S tree or you > can host it yourself. > > Do you use LTSP as the basis for your client server technology? > >> >> The technical challenges we see are mostly problems integrating sugar into >> a thin client architecture, and into the networks of schools. One of the >> most immediate changes we will need to make are customizations to the >> interface. For example, thin clients may not need the shutdown and reboot >> options, and need a logout option. There are other customizations that we >> may need to make, such as adding or removing items from the control panel. >> These sorts of changes are small, and once done will allow people to deploy >> sugar in a small classroom environment. >> >> On larger installations, schools will want sugar to integrate with there >> existing file and print servers, as well as some centralized administration >> of the sugar interface. Ideally, the journal and datastore would be stored >> on the file server in such a way as to allow teachers to access the saved >> activities from a normal Windows or Linux computer. It would be interesting >> to see if we could launch sugar activities without running the entire sugar >> interface. Also, local media attached to thin client may pose a challenge, >> as the normal ways to search for and mount media are not available. >> >> Another important aspect of larger sugar deployments would be the ability >> of admins to customize the user interface. For example they may not want >> users to have access to the control panel, or may want to set up the list of >> activities per grade, and prevent users from installing there own >> activities. >> >> One of the most interesting aspects of sugar is its collaboration >> features, but this too poses some difficulties. In multi classroom >> environments its not clear how the collaboration would work. Ideally there >> would be one jabber server for the entire network. This would mean that >> every student on the network could see every other student on the network, >> when the desired behavior may be to only see the students in the current >> class. > > Using the Jabber server in a non-xs environment is a issue on which we are > only just now starting to focus. We have a lot of work to do. > >> >> These are some of the issues were thinking about. We could solve most of >> these problem by creating our own custom build of sugar with the patches >> needed to integrate with our current software. However, we would rather work >> with the community to create solutions to the problems. For example, one of >> the things we would like to do is to extend the profile class to allow for >> multiple back ends, as well as the ability to store generic settings. This >> would allow us to integrate some of the important profile settings, such as >> the jabber server, into our management software, while at the same time >> keeping a consistent API and keeping our code separate from the sugar tree. > > Thanks for you willingness to work with us! By Monday, Marco our lead > developer will be able to answer you questions in more detail. > > thanks > david >> >> We are very excited about the possibilities that sugar provides. We look >> forward to contributing to this project, and we are interested in your >> thoughts about these issues. >> >> >> >> ----------------------- >> Brendan Powers >> Resara LLC >> >> 1.888.357.9195 >> www.resara.com >> >> _______________________________________________ >> Sugar mailing list >> Sugar@lists.laptop.org >> http://lists.laptop.org/listinfo/sugar > > > _______________________________________________ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > > _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
