On Thu, 2008-09-04 at 11:24 -0400, Jeremy Katz wrote:
On Thu, 2008-09-04 at 08:42 -0400, Jim Gettys wrote:
On Thu, 2008-09-04 at 01:24 -0400, Greg Dekoenigsberg wrote:
On Wed, 3 Sep 2008, Jeremy Katz wrote:
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.
It is also a performance killer; you're taking a slow processor and having it decompress twice. We need to get to the bottom of why the current spins are so slow off USB/SD as quickly as possible, while Daniel's native install on SD is very usable.
As I mentioned earlier in the week, trying off of SD was looking quite a bit better as far as usability was concerned. So I think either I picked the wrong USB stick or the one I picked is beginning its death throes.
The SD's I have on order haven't come in yet. Daniel's build is on the one 4 gig SD I have; I may have a few slower 1-2 gig SD's I can try.
Unfortunately, jffs2 does not have a way to say "don't compress a file", though dwmw2 has talked about this from time to time.
A bit of an aside and not really relevant for the Fedora on XO discussion, especially in the short-term, but ubifs might be interesting to look at as an alternative to jffs2 as it seems to be adding a lot of the things which have stalled out in jffs2
Not having wear leveling on bare NAND is a non-starter, if there is any substantial write use. We may need to page to make a viable system, and will need to page to a file.
Where did anyone even suggest using the bare NAND?
The internal 1 gig of nand is bare.
Interfaced via the CAFE chip.
Runs very fast at the hardware level (25 MB/second); extremely low latency, in particular. We're generally compression limited.
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.
In my latest discussions with Kim, it seems unlikely that we will be able to get something to the hardware manufacturers in time for an "onboard" solution anyway.
But olpc-update allows a late-binding: you can install bits later with no hardware cost. I'm pretty sure a small enough spin is not very hard to do.
Making spins is fundamentally trivial. Adding more variations of things to build, support and maintain is not trivial.
I agree; I want, as close as possible, a formal subset of the "normal" fedora desktop, and not to bring in any packages for OLPC beyond the minimum. - Jim