[sugar] Development environment for newcomers

Sun Mar 11 21:43:41 EDT 2007

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:

     http://en.wikipedia.org/wiki/UnionFS

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.

On 3/11/07, Ian Bicking < ianb at colorstudy.com> wrote:
>
> 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:
> http://dev.laptop.org/ticket/925)
>
> 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 | ianb at colorstudy.com | http://blog.ianbicking.org
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar
>

-- 
Drew Einhorn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/sugar/attachments/20070311/9dbb5b05/attachment.html