[fab] Correspondence from a wandering board member

Christopher Blizzard blizzard at redhat.com
Mon Aug 7 12:33:14 UTC 2006


Greg DeKoenigsberg wrote:
> . gettext�s model of having English as the "master" language is a real
> problem when the translators do not speak English, and shuts out
> translations for a bunch of native languages where English was not the
> language of the conquerors/colonists. In this case, the translators know
> Spanish and Quecha, but not English, so they cannot make sense of the .po
> file that has English phrases as the keys for the Quecha translations.
> 
> . The problem of distribution is real - I think we know this but don't
> always understand how bad it is. It is a big pain for me to even get net
> access here while travelling, and apparently dialup costs something like $35
> per mo plus per minute for phone service, plus ISP charges. No idea how much
> DSL costs - mucho dinero. In particular, the problem of needing to connect
> to the Internet for downloading updates and new packages was raised. We need
> to support the ability to configure a local package repository into the
> distro and into yum, and make it easy to turn downloaded packages into a
> local package repository that can be served to other computers on an ad-hoc
> basis. Is OLPC going to help at all in this regards?

Yeah, this is a symptom of a few problems with the way that rpms work 
today.  You can't tell what's an app, you can't translate outside of the 
rpm (at least, not without some deep hacks) and everything requires 
"outside" (read: another repo) access to solve dependency problems and 
to get apps.

So for OLPC what I've wanted to do is to enforce a few rules:

1. The Base OS is an image, not a set of RPMs.  This means that instead 
of everyone having to go upstream to get updates, you get a binary 
delta.  This assumes that 1. the base image doesn't change across 
machines and that 2. people don't add software to that base image. 
Given the way that we work today, this is hard.  Which leads us to...

2. That the applications that a user installs are not part of the base 
system.  They are installed somewhere else that's not /usr/bin, probably 
in a user's home directory somewhere.  What does this mean?  This means 
that you can safely update or replace the operating system without 
hosing the user's applications.  It also enables binary updates, copying 
the updates from machine to machine instead of having to reach upstream, 
etc.  It also enables one of the most important things: applications can 
be given from person to person.  See above about ISPs being expensive. 
Why use an ISP when you can just give it to your friend directly?  Cuts 
costs, builds communities and is something that other operating systems 
just can't do.  The important rule has to be that the same image you use 
to install an application is the same that you use to run it.  In the 
real world an RPM is not related to whatever you have on disk.

3. User data is separate from the apps.  In the classic world this means 
/etc is clearly separated.  In our app's case, it's not that different 
from the direction a lot of stuff is going because of gconf and dbus and 
hal.  But you shouldn't have to go into /etc to make a program work 
right and root access is never the answer.

So using this model above a lot of things fall out of it:

o Applications can be translated after the fact.  As he points out 
above, this is really important to a large part of the world.  It's also 
the key to making translations scale.  Right now we have to get an 
entire rpm in order to get any of the translations.  What this means as 
that the number of translations grows, the amount that everyone pays 
grows with time.  You could suggest "adding an rpm per translation" but 
that sounds pretty hacky to me.  It would be great if the translations 
for a program were separated from the app itself.

o We can get a real platform.  Somewhere to start, some base for ISVs to 
assume is there.  We can get away with this in OLPC because we have 
space constraints that require us to make decisions.  But the current 
world of Linux distributions is that there's lots of disk and lots of 
memory so people aren't forced to make decisions about what to include 
in a base image and what's not.  In fact, there is no base image.  And 
now we have a 5 CD base install requirement.  There is no platform, 
there is only everything.

--Chris




More information about the fedora-advisory-board mailing list