[Sugar-devel] SoaS on XO issues for discussion

[Martin Langhoff]

On Tue, Apr 21, 2009 at 2:46 AM, Martin Dengler
<martin at martindengler.com> wrote:
> Sebastian and I had a discussion about SoaS builds being used on XOs.

Very interesting and timely discussion. The notes that follow are my
(hopefully well informed)  opinion only. No employers were involved or
harmed in the writing of this email.

Overall, my answer leans to "yes, include anything that makes it
useful for users, within SL's resources". The game is one of removing
barriers to entry -- Joel Spolsky has written a bit about this wrt
Excel - the details differ but the strategic principle applies -
http://www.joelonsoftware.com/articles/fog0000000052.html

So I'd make a cost-benefit analysis of which of those barriers take
priority, and tackle those in order. Whatever time / people you have,
start at the top of the list and make it as far down as possible.

(Bah, you probably know all of this already :-) )

All the successful projects I've worked on (and many of the successful
tools we prefer) have been moderately good at their general purpose,
and excellent at demolishing barriers to entry.

> * Should an olpc-update-like mechanism be supported?

That's a more technical question :-) -- I don't know what the answer
is, but right now the notable facts in that area are:

 - Yum updates are not supported, and brittle
 - Anaconda updates are supported, but suck on netbook-type hw, and are brittle
 - olpc-update is a network hog, does not apply %pre %post hooks (etc
- it just sidesteps rpm execution) and eats up a lot of diskspace. But
it's not brittle.
 - BTRFS is in the horizon -- if it delivers on the promises made, its
snapshotting feature could solve the rpm/yum/anaconda brittleness.
OTOH, it's fashioned after ZFS, and ZFS is a humongous memory hog.

Note that when I say brittle, I mean that any glitch - like powerloss
- during an update leaves the system in mysterious state that is
likely to be "unrecoverable" -- from the PoV of the rpm toolchain
anyway. With a bit of knowledge of rpm internals, it would be possible
to write a tool to help the rpm infra to make sense of the state of
things, but it's a sizable project of its own...

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff