Applications selection discussion....

[Jim Gettys]

On Wed, 2008-09-03 at 16:18 -0400, Jeremy Katz wrote:
> > > So, the thing is, rather than trying to think about a bazillion
> > > different spins that each largely replicate decisions that already have
> > > to be made in other situations, I think there's instead a lot of value
> > > in just ensuring that a user with a G1G1 can just download *any* spin of
> > > Fedora, put it on a USB stick/SD card and use it.

Certainly a good goal, but I think we're unlikely to make it for
F10/G1G1. And I sure want a spin including sugar if at all possible.

> > 
> > Yes, but right now, the requisite kernel support is not available.
> 
> Based on the previous discussion -- all the big bits are upstream now
> and just a matter of config, no?  Yes, maybe it's not as "perfect" of a
> kernel in that there are some fixes which have not yet made it upstream,
> but either
> a) they're not critical or

A generic kernel config on kernel.org won't boot: we use fbdev, and do
*not* have support for VESA in the firmware, which the usual x86 kernels
presume to print to the console.  How much work it will be to get to
where it might be able to boot a generic x86 kernel is is an interesting
question, but one we're not likely to be able to solve in the short
term.


> b) if they're important, carrying a critical fix in the Fedora kernel is
> doable as long as its being pushed upstream at the same time

Andres has been working on this; but we're not done yet.  By far the
most supportable situation in the short term is a kernel that is the
same as we already support in the OLPC builds. 

A few of the remaining big patches have been contentious, as there have
been several competing versions of the same feature (device tree, in
particular).  I'll chat with Andres to get a feel for where we are with
this and related topics.

I'm hopeful in 3-6 months the situation will be different....  But
that's beyond the initial need.

> 
> > Nor will any existing spin fit in 1GB of internal flash.
> 
> We fit on 700 meg CDs, so it's definitely doable.  There's nothing that
> would fundamentally prevent the way we do things for the cds to also
> function off of jffs2.  Two different compressions is kind of silly,
> though.  

Not to mention the performance consequences, which won't be pretty. And
writable files need to be stored on the internal flash with JFFS2 anyway
to get  wear leveling.  It isn't like an external SD or USB key that
could be replaced if you wear out particular blocks.  Bare flash
soldered onto a board really wants wear leveling.

> 
> Also, I did state "off of a USB stick or SD card".  I actually think
> that in a lot of ways, that's better because it means that we can not
> worry about using any of the built-in flash leaving all of it for use
> with Sugar and then wanting to run a joyride build, etc.

For many people it is; but some don't want the issues around having a SD
or USB stick.  USB sticks in particular are problematic.


> 
> As I said, though -- rather than just pulling from a spin that's
> specific to the OLPC, let's work with the people on the font SIG.  If
> they're not needed on the OLPC, there's a pretty good chance they're not
> needed in other cases as well.  Then we can have the efforts benefit all
> of Fedora (freeing up 13 megs means more space for apps on the regular
> livecds too) rather than just something done off in OLPC-land

I've started poking at the fedora font SIG.


> 
> Err, yes -- I need more caffeine clearly.  The point about the maturity
> of the app stands :)  

Dunno.

> 
> > > > 3) Printing...  Several options:
> > > >    a) none at all unless you yum install it
> > > >    b) default config cups client library only (no cups server);
> > > 
> > > If you don't have cups-libs, you don't have GTK+.  So a) really isn't an
> > > option.  This might work, but owuld need someone testing
> > 
> > cups-libs certainly has to exist; but it's a gnome print dependency
> > rather than GTK+, just to be pedantic.
> 
> No, GTK+ provides printing widgets and directly uses libcups as of GTK+
> 2.10.

As I said, you can configure libcups to be strictly a client of a cups
server elsewhere on the net (specifically, any IPP server) by
configuring a text file, and not have to carry a CUPS server, much less
any drivers or driver databases.

Most people are not aware that this is even possible, they are so used
to having a local CUPS server.

I don't know how well it works at present; my experiments are a bit over
2 years old.  It worked (albeit a few problems) when I tried this then.
                        - Jim


-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child