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
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
_______________________________________________
fedora-advisory-board-readonly mailing list
fedora-advisory-board-readonly@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-advisory-board-readonly
