My friend Larry Landis and I were at PyCon, but were unable to stay for the sprints. We were thinking about starting a similar project in a couple of weeks when he gets back from a gig in Italy. Since I got back from PyCon I have been fooling around with sugar-jhbuild off and on.  Gave it a lot more time and energy this weekend. I agree that sugar-jhbuild is not suitable for beginners to install on their computers.  In addition to taking way too long to compile (on an average box) and download (if you are bandwidth deprived, like me), it is way to unstable for beginners.  Something that worked yesterday may not work today, once the latest source with new bugs is retrieved by subversion or git. We will probably need a different balance between stability and bleeding edge for sugar itself and the develpment enviornment generated by:     ./sugar-jhbuild build-base I think preparing a pre-built development environment on a hefty server box that can support a reasonable number of beginners is the way to go. We could create an account for them to ssh into if they are comfortable with the command line.  We could use ltsp if they need gui-based tools, with freenx if the need to access the gui over a low bandwidth link. I have a dim recollection of a unionfs on OpenBSD, but those guys are way too hostile.  But the Wikipedia gives me some other ideas:      <a href="http://en.wikipedia.org/wiki/UnionFS">http://en.wikipedia.org/wiki/UnionFS</a> We could do a three layer unionfs, the base layer could be a read only file system with the standard development environment, each user could have their own read-write lay on top of it in their home directory, so any modifications they make would be their own and persistent, and a memory resident cache on top for performance (if the serve has enough ram).  Or maybe we only have two layers and do the caching some other way. Guido has been frustrated trying to get sugar-jhbuild running on his Ubuntu Dapper box, and kicked off a discussion about what OS would be best if he decides to build a new box to use for sugar development.  We should pay attention to that thread. I have not yet looked to see if he has gotten any responses. I think Ubuntu Edgy, Feisty, and Fedora Core 6 will be in the running.  I have no idea if any of them support a unionfs. <div>On 3/11/07, Ian Bicking <<a href="mailto:ianb@colorstudy.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> ianb@colorstudy.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">At PyCon a few of us looked at the development environment and how newcomers could work on it (the people involved where: Michael Fletcher, John Hall, Brian Dorsey, and Jeff Younker and Frank Wilder for a short while).  I've put this off a bit, but I wanted to write up our thoughts (unfortunately we didn't have real conclusions). Goal ---- My personal goal is to be able to run a coding sprint, where people can show up and we give them CDs, USB sticks, etc., and they can get a running environment that they can develop on in a reasonable amount of time (half hour or so).  I expect a variety of computers, and I don't want to depend on them having anything specific setup. When I've done this in the past with professional programmers using software that is reasonably simple to setup, it can still be very hard.   I'd like it to be simpler than that, and right now it is much more difficult. I also want to setup a development environment people can use.  There's a lot of things to learn at once, so I'd rather people just be able to use an editor they are familiar with, and other tools they know something about.  Minimizing the number of novel things people have to deal with will allow them to actually pay attention to the important stuff (like writing code). Ideas ----- I think sugar-jhbuild is pretty much right out; even if it was made perfect and totally self contained, I can't see people reasonably running it ahead of time, and it certainly takes too long to do at the sprint.  One idea Michael has been working on is to do a complete build in a virtual environment, and then people can use that environment; either with something like VMWare, or potentially produce a live CD.  I don't think the CD that is produced from the builds really makes sense -- doing stuff like hardware detection is really out of the scope of what OLPC should be concerned with.  But if we can setup all the dependencies on something suited for a live CD, and install and pre-build parts for that CD, maybe that would be workable.  That still won't give people the environment they are used to, unless they happen to be used to what we produce.  (I think Michael is using Ubuntu?) I'm more positive about emulation, as it's fairly reliable; i.e., qemu or the VMWare player.  You could a hosted/sugar-jhbuild environment, or the actual build image.  If you do a sugar-jhbuild environment, presumably people will use that environment for all their development, using whatever tools we put on there.  They'll inherit any network settings and hardware support.  Performance is a little slow; realistic for actually running the environment, somewhat tedious (but not unacceptable) when running development tools. (Note: one issue with VMWare emulation is that currently networking doesn't work because of a missing driver, as noted here: <a href="http://dev.laptop.org/ticket/925" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://dev.laptop.org/ticket/925</a>) Another option is using the builds themselves.  The builds and the OLPC environment really isn't suited yet to doing development.  I don't think that should be a blocker for people either (I'm not a big fan of eating your own dog food, at least not until much later in the process than we currently are). One of the more hopeful options seems to be some kind of network drive, so you can edit files from the host environment.  All testing would occur on the emulated image.  Either the host or the image could have the server, with different tradeoffs. sshfs was suggested.  This is fairly difficult to setup on host computers, and while something like Nautilus might be easy to setup, many other tools won't work well.  Another issue is that the host computer has to see the image on the network.  I haven't tried VMWare; I get the impression it's fairly easy to set this up there.  Setting this up under qemu is much harder, and it's not clear to me if it's reasonable at all under Windows.  I'd really like this to be workable for Windows users.  Of course, if the host can see the image there's no reason we could have many server options, including Samba and NFS in addition to ssh (all of which may not be part of the standard builds, but seems easy enough to add to a custom build). Setting up a server on the host computer has its own issues, though it can be potentially easier -- servers require relatively little OS integration compared to a client.  In that case, the host would run some server (NFS, ideally SMB could work), and the image would mount it. This avoids the emulation networking issues, but then we have to consider where to mount the share... can we overlay the entire filesystem? Disk space on the image is a problem.  It would be nice if people weren't constrained to 512Mb, so they could play around with larger things, even if those things can't be deployed in that form.  It may not be an issue if all the development tools stay on the host system; but I don't think gcc will work well on the host system, as it's not the image's native gcc.  Installing development libraries take a lot of space.  OTOH, I'm much more interested in getting people writing Python code.  But it would be nice if there was at least some story for how people could develop bits of C code (or Pyrex) if there are particular performance benefits in their application. Sorry if this wanders, I've tried to include at least some of the bad directions and possible good directions and caveats in this, and the result is scattered. -- Ian Bicking | <a href="mailto:ianb@colorstudy.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ianb@colorstudy.com</a> | <a href="http://blog.ianbicking.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://blog.ianbicking.org</a> _______________________________________________ Sugar mailing list <a href="mailto:Sugar@laptop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Sugar@laptop.org</a> <a href="http://mailman.laptop.org/mailman/listinfo/sugar" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://mailman.laptop.org/mailman/listinfo/sugar</a> </blockquote></div> -- Drew Einhorn