drew einhorn wrote:
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.
Yes; sugar-jhbuild is useful if you are developing Sugar, but less so if
you are developing on Sugar. Well, more than "less so", it's quite
distracting to worry about the underlying platform.
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 would be reluctant to start down the path of building this kind of
infrastructure. Mostly because it's a pain in the butt, and I'm not
sure it satisfies the basic needs for a beginning (OLPC) developer.
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.
It would also be helpful if the image could mount a network drive (from
the host) over the image's own drive, thus allowing the host system to
edit an file, and also revert those changes fairly simply. I think(?)
that Bitfrost involves this same sort of overlay, so maybe the
functionality is already there in the images? (Or due soon)
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.
This would be useful at least for the image that Michael is trying to
build, where we could give people a working live CD based on a system.
Ideally it would be built so people won't have Any Problems At All.
He's been blogging his progress over at http://blog.vrplumber.com/ -- I
think he might actually be using Gentoo? Hm.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
