On Wed, 2008-09-03 at 17:01 -0400, Jim Gettys wrote:
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.
We'll never succeed if we don't try -- I actually think it is pretty possible at this point. It could also end up having the nice side benefit of having one less kernel being built for Fedora by merging to have an x86 and an x86-PAE kernel.
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.
Given that we can do a multitude of framebuffer consoles and have other places where there is no VESA (I'm looking at you Xen) where the main kernel works, this shouldn't be a blocker at all. And I fixed this once for Xen, if I have to dive back into the console code I will.
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.
It's not supportable _as Fedora_. We've already seen that with the various one-off changes in the name of expediency and size meaning that the OLPC-build kernels won't work for live images.
I was hoping to do some prodding at kernel builds today, but ended up doing some Sugar things most of the day instead
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.
The live images don't have writable blocks (except in ram) unless you set up persistence. And getting the persistence able to be run off of the jffs2 should be pretty straight-forward I suspect.
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.
What issues are there? I can get 2 gig SD cards for < $10 without any sort of bulk discount, so given that we're talking G1G1 and not the developing countries, cost isn't one. And hey, having a "premium" for a "normal" desktop experience seems to be the norm these days -- see the difference between Linux and XP netbooks :)
Jeremy