Hi folks -
There doesn't seem to be a place to talk about the RH OLPC project yet. I mailed the olpc@redhat.com address last week but didn't hear anything yet. It seems that Fedora and the OLPC development effort would have a lot in common. I wanted to make some suggestions which are a little radical but hopefully can make some interesting discussion before things are set in stone.
My core starting assumption is that the box cannot be made for the price suggested and that triage will be needed. Therefore the software must get ahead of the game by assuming a weaker processor and half the flash.
Please understand though that these are just suggestions for thinking about, not demands, complaints, etc.
Hardware
Seems hard to believe that with such a low price point, AMD will deliver optimal pricing and that the target CPU throughput is not excessive with x86. Isn't it better for the longer term to only weakly couple the concept of the cheap laptop to a processor arch? Isn't it better if it's more of a virtual specification that, say, random Chinese companies can compete with each other to provide at the lowest possible price, without encumbered CPU designs even like Arm? It's great to tout it around Large American Corporations, but it would be a big win if the final specification was buildable by anyone.
- AMD x86 -> OpenRISC 1200 (Has working GNU toolchain) http://www.opencores.org/projects.cgi/web/or1k/openrisc_1200
- ??? expensive patented video --> Opencores VGA/LCD controller http://www.opencores.org/projects.cgi/web/vga_lcd/overview
- Sound -> Cheap SPI codec, eg, http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html or AC97 interface to external mixer
http://www.opencores.org/projects.cgi/web/ac97/overview
Software
- Linux 2.6 with hardware-optimized .config
- glibc -> uclibc http://www.uclibc.org/ or newlib http://sources.redhat.com/newlib/
- coreutils + bash + a ton of other stuff -> busybox http://www.busybox.net
- ssh -> dropbear (http://matt.ucc.asn.au/dropbear/dropbear.html )
- apache -> lighttpd (http://lighttpd.net )
- firefox -> Opera? Used in Nokia 770... thought it was OSS now but couldn't find link on site.
- various media players / codecs -> Ogg Vorbis + Theora only
What will the new modular X do faced with linking to something other than glibc? What about Gnome?
- Although I am a KDE man, Gnome really impressed me for the first time on the Nokia 770. The KISS vibe actually worked in that context. The 770 would be a good model for what's needed generally in fact (http://maemo.org , http://maemo.org/platform/docs/maemo_exec_whitepaper.html )
- Ext3 root filesystem -> JFFS2 NAND root filesystem
- Grub -> u-boot (http://sourceforge.net/cvs/?group_id=65938 ) .. can pull a bzImage out of JFFS2 directly in <100K
Well I'm sure these ideas and more are already floating around, it would be cool if these can be dual-purposed into a uber lightweight "Fedora Beanie" version. Ultimately a lot of package specfiles will have to have the configure options revisited anyway...
-Andy
On Tue, 2006-02-07 at 10:11 +0000, Andy Green wrote:
Hi folks -
There doesn't seem to be a place to talk about the RH OLPC project yet.
Hi, thanks for your email. We (Red Hat) are in the process of setting up mailing lists, documentation, web-sites and code repositories for the OLPC project. It will be ready in a few weeks! Stay tuned!
David
David Zeuthen wrote:
Hi, thanks for your email. We (Red Hat) are in the process of setting up mailing lists, documentation, web-sites and code repositories for the OLPC project. It will be ready in a few weeks! Stay tuned!
Hi David -
Well glad to hear it, I hope these rather fundamental questions will still be in scope by then.
-Andy
On Tue, 2006-02-07 at 21:17 +0000, Andy Green wrote:
David Zeuthen wrote:
Hi, thanks for your email. We (Red Hat) are in the process of setting up mailing lists, documentation, web-sites and code repositories for the OLPC project. It will be ready in a few weeks! Stay tuned!
Hi David -
Well glad to hear it, I hope these rather fundamental questions will still be in scope by then.
Yes, things are definitely not set in stone yet. To comment on the list in your original mail.. it seems pretty good and thoughtful though it's probably a bit premature to discuss this at such a great detail. Indulge some rambling...
Our current thinking (and code) revolves partly around making it easier to build derived lean distributions based on Fedora Core. All this includes fixing a few obvious and not-so-obvious things in Core; it includes lots of thinking about distribution and updates in scenarios that the OLPC project targets (e.g. millions of users, extremely low admin/user ratios, think appliance); it includes thoughts about how lock down and provide a secure OS out of the box; it includes thinking about how to fit this in almost no space with very limited RAM and worse.. no swap; it includes thinking about how to easily enable application developers and other stake holders to participate... and a whole bunch of other stuff too..
It's also useful to keep in mind that the software side of the OLPC project is larger than the bits Red Hat will provide - there's a bunch of smart people thinking about... not so much how we provide the bits in a sane way to users (all the stuff in the paragraph above)... but what bits we should be providing... for example, it's not at all a given to me that we want the target users (they are kids!) to sit down and learn a difficult program like openoffice.org Writer.. (this doesn't mean that I don't like oo.o)
Anyway, it's probably not useful to start a huge thread here about these high-level thoughts (read: no need to reply)... First of all we need a dedicated mailing list and other infrastructure since a) this is sort of off-topic for f-d-l; and b) the S/N ratio here is simply too huge to have a constructive discussion. Second, and more important probably, we want to provide some bits you can try out along with some written-down thoughts. We want future contributors have a good starting point so we're all on the same page. And we're there pretty soon. Stay tuned!
Thanks, David
Le mardi 07 février 2006 à 22:32 -0500, David Zeuthen a écrit :
It's also useful to keep in mind that the software side of the OLPC project is larger than the bits Red Hat will provide - there's a bunch of smart people thinking about... not so much how we provide the bits in a sane way to users (all the stuff in the paragraph above)... but what bits we should be providing... for example, it's not at all a given to me that we want the target users (they are kids!) to sit down and learn a difficult program like openoffice.org Writer.. (this doesn't mean that I don't like oo.o)
So work through Fedora Extras. Please do not segregate OLPC packages where other projects can not benefit.
On Wed, 2006-02-08 at 08:34 +0100, Nicolas Mailhot wrote:
So work through Fedora Extras. Please do not segregate OLPC packages where other projects can not benefit.
Some of the content that goes into OLPC may not be appropriate for Extras. Things are still being worked out, please have patience.
On Tue, 2006-02-07 at 23:42 -0800, Jesse Keating wrote:
On Wed, 2006-02-08 at 08:34 +0100, Nicolas Mailhot wrote:
So work through Fedora Extras. Please do not segregate OLPC packages where other projects can not benefit.
Some of the content that goes into OLPC may not be appropriate for Extras. Things are still being worked out, please have patience.
That said, these are likely to be secondary tools and administrative apps (like tools for generating the images that you flash the machines with). Most of the work will either be done upstream or in Core itself, since it's usually just config changes (i.e. kernel), or splitting up packages to reduce dependencies. It's slightly unclear how this will work exactly, but it usually won't result in _code_ changes. Just packaging ones.
Any real code changes are going to be done upstream if possible; the kernel needs some work for the Geode companion chip, X.org needs heavy fixing of the 'nsc' driver, etc. But none of this has to live _only_ in Core or Extras. That's stupid. OLPC stuff is going to happen upstream as much as possible. That also lets _anyone_, not just Red Hat people, contribute as much as they can. And that's fundamental to the project in the long run.
Lots of this work is generic anyway and simply consists of breaking stupid dependencies and slimming packages down. Not too many people are going to be able to physically have the OLPC hardware, since it's going to governments and schools (and isn't on sale to the public). But since so much of the work is widely applicable, that's not much of an issue.
Dan
Any real code changes are going to be done upstream if possible; the
Just a FYI for people reading, I a Wiki "upstream" with more information about the project.
http://pedia.media.mit.edu/wiki/OLPC_software_task_list
http://pedia.media.mit.edu/wiki/Development_issues
"We plan to use the JFFS2 journalling flash file system on the flash..." "At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit"
Sounds good! Be aware tho that large JFFS2 filesystems are really slow to mount.
http://pedia.media.mit.edu/wiki/One_Laptop_per_Child
"We expect the release of a beta version of the emulator in early February."
And here is a hardware spec I didn't see before
http://pedia.media.mit.edu/wiki/Hardware_specification
* Processor: AMD Geode GX500@1.0W with AMD CS5536 companion chip (note that the "500" chip really operates at a 366MHz clock). * Memory: 128MB DRAM, possibly DDR Mobile * Nonvolatile storage: 512MB (possibly 1GB) NAND flash memory * BIOS/loader: hardware details TBD; either conventional, or maybe LinuxBIOS, if available in time. * Audio: AC97 codec (chip TBD; we are down to probably two or three alternatives), built-in stereo speakers and mono microphone, jacks for external stereo speakers and microphones * External ports: four USB2.0, one supporting On-The-Go functionality * Display: dual-mode, based on a 7.2" diagonal 800x600 monochrome TFT panel o Monochrome (high-res, low-power "E-Book") mode: 800x600, reflective (ambient light) o Color mode: 462x346, quincunx-sampled, LED-backlit * Input devices: keyboard, trackpad (supporting pointing, scrolling, and possibly graphical input), additional buttons adjacent to screen for use in E-Book/tablet mode * Wireless: Atheros AR5004G or AR5004GS chip, 802.11b/g. The requirements of mesh networking in combination with the abilities of the madwifi device driver have driven this selection; it is the best and most flexible wireless device driver today. There are not other viable alternatives at this time. * Power: 100-240VAC, 12VDC, also integrated crank charger based on a permanent-magnet generator and 100:1 gear train. Battery details TBD.
Many of the TBD's should be set by late January, 2006, and we'll try to keep this page up to date.
Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept.
-Andy
On Wed, 2006-02-08 at 15:47 +0000, Andy Green wrote:
Any real code changes are going to be done upstream if possible; the
Well, by "upstream" I mean upstream in the projects for which the changes would be made. Like the Linux kernel, Gnome, glibc, etc.
"We plan to use the JFFS2 journalling flash file system on the flash..." "At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit"
Sounds good! Be aware tho that large JFFS2 filesystems are really slow to mount.
Yep, and Dave Woodhouse knows the limitations quite well. Which is why he's beating JFFS2 into submission for OLPC as we speak.
Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept.
Well, remember that while this machine has some low-end specs that match more of a "smart" cellphone rather than a real laptop, it still is more of a laptop. If you're running interesting apps on it, I'm not sure that things like uclibc would really work. Most of the highly slimmed down environments are targeted at PDAs that are quite a bit lower-speced than this laptop.
With glibc, most of the size is actually taken up by all the locale information, which can certainly be stripped out for OLPC. The plan here is to use as much of Fedora Core as possible (including glibc) and only if there are severe space issues rethink that strategy. There really aren't many space issues however. The moderately slimmed JFFS2 image is under 250MB now, and there's still lots to be culled. I think the target is around 150MB - 200MB for the base OS and desktop library stack. That's quite reachable.
Dan
With glibc, most of the size is actually taken up by all the locale information, which can certainly be stripped out for OLPC. The plan here is to use as much of Fedora Core as possible (including glibc) and only if there are severe space issues rethink that strategy. There really aren't many space issues however. The moderately slimmed JFFS2 image is under 250MB now, and there's still lots to be culled. I think the target is around 150MB - 200MB for the base OS and desktop library stack. That's quite reachable.
Its almost similar to the maemo project in style where they've put a low end desktop style spec into a handheld. It has all the usuals like glibc, gtk (and co) gstreamer, X, window manager etc and fits in 128M I think so I wouldn't have thought it would be a major issue.
Peter
On Wed, 2006-02-08 at 16:13 +0000, Peter Robinson wrote:
With glibc, most of the size is actually taken up by all the locale information, which can certainly be stripped out for OLPC. The plan here is to use as much of Fedora Core as possible (including glibc) and only if there are severe space issues rethink that strategy. There really aren't many space issues however. The moderately slimmed JFFS2 image is under 250MB now, and there's still lots to be culled. I think the target is around 150MB - 200MB for the base OS and desktop library stack. That's quite reachable.
Its almost similar to the maemo project in style where they've put a low end desktop style spec into a handheld. It has all the usuals like glibc, gtk (and co) gstreamer, X, window manager etc and fits in 128M I think so I wouldn't have thought it would be a major issue.
Exactly. They have quite a few Gnome-slimming patches of interest, like killing Bonobo until it's dead dead dead. Many of those are already upstream, or are going upstream to Gnome, AIUI. There's activity in this area that has nothing to do with OLPC specifically, but from which OLPC and others could benefit. So for the OLPC project, that means working with upstream projects and others like Maemo to ensure that the software is suitable for lower-end systems across the board.
Dan
Dan Williams wrote:
Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept.
Well, remember that while this machine has some low-end specs that match more of a "smart" cellphone rather than a real laptop, it still is more of a laptop. If you're running interesting apps on it, I'm not sure that things like uclibc would really work. Most of the highly slimmed down environments are targeted at PDAs that are quite a bit lower-speced than this laptop.
uclibc is pretty friendly to the apps I have compiled it with, including fairly large things like Asterisk. This isn't very scientific, but
Fedora x86_64: 1485672 Aug 15 15:34 /lib/libc-2.3.5.so
Our ARM distro: 256988 Jan 18 11:15 /lib/libuClibc-0.9.28.so
http://uclibc.org/FAQ.html#why and the next FAQ entry have some information about the goals and compatibility.
With glibc, most of the size is actually taken up by all the locale information, which can certainly be stripped out for OLPC. The plan
Yep.
here is to use as much of Fedora Core as possible (including glibc) and only if there are severe space issues rethink that strategy. There really aren't many space issues however. The moderately slimmed JFFS2 image is under 250MB now, and there's still lots to be culled. I think the target is around 150MB - 200MB for the base OS and desktop library stack. That's quite reachable.
Are these "JFFS2 image" figures, after the JFFS2 compression? Just some example numbers, busybox on my Arm9 here is 606KB and allows you to throw away bash (it has ash), vi, coreutils, rpm (a weaker implementation, but still), cpio, tar, procps, etc, etc, even networking stuff like dhcpd and dhcpc are all in there. If you accept some small restrictions and losses of non-core functionality you can perform a massive reduction in distro size and packagecount with busybox with or without an alternative libc.
-Andy
Are these "JFFS2 image" figures, after the JFFS2 compression? Just some example numbers, busybox on my Arm9 here is 606KB and allows you to throw away bash (it has ash), vi, coreutils, rpm (a weaker implementation, but still), cpio, tar, procps, etc, etc, even networking stuff like dhcpd and dhcpc are all in there. If you accept some small restrictions and losses of non-core functionality you can perform a massive reduction in distro size and packagecount with busybox with or without an alternative libc.
But while not throwing away core functionality you add extra unneeded things like extra development and testing time (and a reduced audience for testing) by using things like uclibc in a fedora based distro and hence increasing the developments costs and time to market with very little gain in size. Things like maemo already prove that you can shoehorn all core functionality that you have in a modern desktop environment (I have a browser, abiword, gaim, gnumeric, evince and other stuff installed on the standard 128M on the Nokia 770 along with the standard browser/autio/video etc that comes default) into less than 256 without having to resort to using cut down libraries like uclib which may produce other issues. The advantage of using the core fedora libraries is that you have economies of scale when it comes to testing and bug hunting.
Peter
Peter Robinson wrote:
Are these "JFFS2 image" figures, after the JFFS2 compression? Just some example numbers, busybox on my Arm9 here is 606KB and allows you to throw away bash (it has ash), vi, coreutils, rpm (a weaker implementation, but still), cpio, tar, procps, etc, etc, even networking stuff like dhcpd and dhcpc are all in there. If you accept some small restrictions and losses of non-core functionality you can perform a massive reduction in distro size and packagecount with busybox with or without an alternative libc.
uclib which may produce other issues. The advantage of using the core fedora libraries is that you have economies of scale when it comes to testing and bug hunting.
Accepted that in reality that is also a consideration. But really you are not playing the PC game any more on a box with 512MB flash. I also have a 770 and for all its good points it is crashy with the current firmware image, locks up on low memory situations and so on.
Anyway the libc question is different to the busybox question. Does this laptop really need a full bash? A full *.rpm that will be in the minimal packageset? If not, busybox can soak up a huge area in the middle of the distro.
-Andy
On Wed, 2006-02-08 at 19:44 +0000, Andy Green wrote:
David Zeuthen wrote:
On Wed, 2006-02-08 at 17:24 +0000, Andy Green wrote:
Does this laptop really need a full bash?
Does this laptop really need a shell?
Is it having initscripts?
Not necessarily ones that require a shell to execute. The target users have nearly no use for a shell (or if they need one, we haven't done our job). Fedora's initscripts are a stinking pile of crap right now anyway. There's some room to rethink the init process for these things, and maybe that means ditching the dependency on a shell _during the init process_.
Dan
Dan Williams wrote:
Does this laptop really need a full bash?
Does this laptop really need a shell?
Is it having initscripts?
Not necessarily ones that require a shell to execute. The target users have nearly no use for a shell (or if they need one, we haven't done our
Still, ssh-ing into a box is normally very useful, and you really want to come up into a shell. But I take your point.
job). Fedora's initscripts are a stinking pile of crap right now anyway. There's some room to rethink the init process for these things, and maybe that means ditching the dependency on a shell _during the init process_.
I saw a lot of work was done mapping what happens during boot and initscripts and where the time is going. There's stuff like initng (http://initng.thinktux.net/index.php/Main_Page ) so that sounds like a great idea for Fedora too.
But ash in busybox really is negligible, sad to disallow the possibility of simple enduser scripts tying coreutils together with, eg, wget, for HTML screenscraping or whatever. Still good to hear this radical thoughtprocess is underway!
-Andy
On Wed, 08 Feb 2006 14:37:23 -0500, David Zeuthen david@fubar.dk wrote:
On Wed, 2006-02-08 at 17:24 +0000, Andy Green wrote:
Does this laptop really need a full bash?
Does this laptop really need a shell?
Yes, it does. There's a very large number of shell snippets embedded into applications. You may choose not to bundle gnome-terminal, that would be fine. But /bin/bash must be there and lame substitutions create problems which are not worth the saved space.
-- Pete
Pete Zaitcev wrote:
Yes, it does. There's a very large number of shell snippets embedded into applications. You may choose not to bundle gnome-terminal, that
Hm yes also in RPM pre/post[un]
would be fine. But /bin/bash must be there and lame substitutions create problems which are not worth the saved space.
That is hard to be certain about without estimating some idea of the saved space, both in flash and in RAM. Ash is cut-down alright but the most-used features like if [ ] , while, for and the usual compare actions are in there and so on. Most intricate script activity is done by calling echo/cat/cut/grep/etc inside `` it seems
It seems to me the biggest saving can be had with replacing many currently discrete packages with busybox. The busybox versions of everything are cut down... but... is that actually more of a bug than it is a feature is the question.
Here is the canonical list of apps that can be generated inside the busybox binary, with implemented options:
http://busybox.net/downloads/BusyBox.html
As you scroll down the list of apps, think of all the packages that go out the window... Busybox has a Linux kernel-style make menuconfig where you can do finegrained enable and disable and config of the packages in it. If one particular thing is too weak, you can turn it off in Busybox and make it in its own package. Otherwise Busybox makes symlinks to itself in /bin/busybox for all the commands that it is compiled to support.
-Andy
On Wed, 08 Feb 2006 21:16:46 +0000, Andy Green andy@warmcat.com wrote:
would be fine. But /bin/bash must be there and lame substitutions create problems which are not worth the saved space.
That is hard to be certain about without estimating some idea of the saved space, both in flash and in RAM. Ash is cut-down alright but the most-used features like if [ ] , while, for and the usual compare actions are in there and so on. Most intricate script activity is done by calling echo/cat/cut/grep/etc inside `` it seems
Very well, if you say so, ash may be all right. But busybox seems to take this too far. You know what the root of all evil is... So why don't we let OLPC group to actually build a system and take measurements? It seems too early to decide on busybox. For crying out loud, it's a system with GNOME. I'm sure 10 core systems can disappear in the noise of that set of packages. :-)
-- Pete
Pete Zaitcev wrote:
Very well, if you say so, ash may be all right. But busybox seems to take this too far. You know what the root of all evil is... So why don't we let OLPC group to actually build a system and take measurements? It seems too early to decide on busybox. For crying out loud, it's
That CPU has only 16K + 16K I/D cache. The AT91RM9200 embedded chip I use at the moment has the same cache :-O. It does have 64-bit path to its DRAM, but still, cache locality is going to be really critical.
And that suggests you need an extreme War On Bloat:
- because the less going through the small caches the less wasted CPU cycles waiting on DRAM
- the less thrashed back and forth between the caches and the DRAM the faster and better power efficiency
- because you have to suck it out the NAND flash and decompress it, the smaller the apps and libs the more responsive the system
- because you may not have the flash you think you will -->
Having stared at the spec, it is still the first and arguably only place cost reduction can happen, so it should be expected, in fact since I heard it had 1GB of flash that has already softened to "512M and maybe 1GB". In fact when people are desperate to save cents on the box you may end up with 64MB or less of flash onboard for the OS and be expected to use a USB flash pen to hold the actual usermode apps, if it lets them ship at the pricepoint.
a system with GNOME. I'm sure 10 core systems can disappear in the noise of that set of packages. :-)
I'm not sure how much of Gnome is planned to be in there as opposed to GTK2. Besides its not the way to get a tight system to say that other things are huge so everything can stay as in Desktop Fedora.
Coming from embedded it seems to me the challenge of this game is not understood well yet. Fit the whole OS and X and toolkits in 20MB, not 200MB. Anyway I see the main need right now is to ship a 0.1 version as you suggest.
-Andy
On Thu, Feb 09, 2006 at 11:11:28AM +0000, Andy Green wrote:
That CPU has only 16K + 16K I/D cache. The AT91RM9200 embedded chip I use at the moment has the same cache :-O. It does have 64-bit path to its DRAM, but still, cache locality is going to be really critical.
12K, 4K of the 16K D cache vanishes mysteriously as the blitter when in graphics mode. Also the RAM is shared with the video and although the video fetch is usually RLE encoded on that chip it still hurts, especially with funky shading and backgrounds.
I'm not sure how much of Gnome is planned to be in there as opposed to GTK2. Besides its not the way to get a tight system to say that other things are huge so everything can stay as in Desktop Fedora.
I see no point in running Gnome on such a device. Its way way too bloated and slow in its current form, and also has heavy FPU dependancies which aren't good on this device.
Alan Cox wrote:
On Thu, Feb 09, 2006 at 11:11:28AM +0000, Andy Green wrote:
That CPU has only 16K + 16K I/D cache. The AT91RM9200 embedded chip I use at the moment has the same cache :-O. It does have 64-bit path to its DRAM, but still, cache locality is going to be really critical.
12K, 4K of the 16K D cache vanishes mysteriously as the blitter when in graphics mode. Also the RAM is shared with the video and although the video fetch is usually RLE encoded on that chip it still hurts, especially with funky shading and backgrounds.
Is that actually true for this "AMD Geode™ GX 500@1.0W" device variant? It says on p17 of the GX databook PDF that the GX1 type did have BLT Buffers "In Cacahe Scratchpad RAM", but it says that for the GX500 variant being specified at the moment, BLT Buffers are "FIFOs in GP". It also says above
''... The Graphics Processor is compatible with the graphics processor used in the GX1 processor with additional functions and features to improve performance and ease of use. Like its predecessor, the Geode GX processor’s Graphics Processor is a BitBLT/vector engine that supports pattern generation, source expansion, pattern/source transparency, and 256 ternary raster operations. New features that have been added to the Graphics Processor include: • A 32-bit datapath that can support 32-bit ARGB full color. • Incorporated BLT FIFOs to replace the cache based BLT buffers used in the GX1 processor. • Improved bus protocols to increase bandwidth to the memory controller. • The ability to throttle BLTs according to video timing and VGA hardware.
...''
If true that's good news, because losing the cache wouldn't help video playback.
-Andy
On Thu, Feb 09, 2006 at 01:11:35PM +0000, Andy Green wrote:
Buffers "In Cacahe Scratchpad RAM", but it says that for the GX500 variant being specified at the moment, BLT Buffers are "FIFOs in GP". It also says above
Not 100% sure.
? A 32-bit datapath that can support 32-bit ARGB full color.
Thats actually the important but unsupported by X bit right now. Its got render acceleration so can support EXA which is important for compositing and friends.
? Incorporated BLT FIFOs to replace the cache based BLT buffers used in the GX1 processor.
Sounds promising
If true that's good news, because losing the cache wouldn't help video playback.
The Geode is not bad at video because it does have hardware colour conversion and scaling overlay logic in most variants of the support chip.
Alan
Andy Green wrote:
Pete Zaitcev wrote:
Very well, if you say so, ash may be all right. But busybox seems to take this too far. You know what the root of all evil is... So why don't we let OLPC group to actually build a system and take measurements? It seems too early to decide on busybox. For crying out loud, it's
I decided to get some numbers to give an idea of what I am going on about.
1) I started trying with FC4 as a basis. This is the minimum packageset for FC4 that includes bash, coreutils. There is a ton of stuff that is not needed at all in the usage scenario for this box.
rm -rf testfs ; mkdir -p testfs/dev ; chmod 777 testfs/dev ; mknod testfs/dev/null c 1 3 ; chmod 666 testfs/dev/null ; mknod testfs/dev/zero c 1 5 ; chmod 666 testfs/dev/zero ; rpm -r /usr/src/silentcat-0.2/packages/testfs -i basesystem-8.0-5.noarch.rpm setup-2.5.44-1.1.noarch.rpm rpms/filesystem-2.3.4-1.i386.rpm rpms/libgcc-4.0.2-8.fc4.i386.rpm rpms/bash-3.0-31.i386.rpm rpms/glibc-2.3.5-10.3.i386.rpm rpms/termcap-5.4-7fc4.noarch.rpm rpms/glibc-common-2.3.5-10.3.i386.rpm rpms/tzdata-2005r-3.fc4.noarch.rpm rpms/libtermcap-2.0.8-41.i386.rpm rpms/mktemp-1.5-23.i386.rpm rpms/coreutils-5.2.1-48.1.i386.rpm rpms/findutils-4.2.20-1.i386.rpm rpms/libacl-2.2.32-1.FC4.2.i386.rpm rpms/pam-0.79-9.6.i386.rpm rpms/cracklib-dicts-2.8.2-1.i386.rpm rpms/cracklib-2.8.2-1.i386.rpm rpms/audit-libs-1.0.14-1.fc4.i386.rpm rpms/libselinux-1.23.11-1.1.i386.rpm rpms/sed-4.1.4-1.i386.rpm rpms/initscripts-8.11.1-1.i386.rpm rpms/e2fsprogs-1.38-0.FC4.1.i386.rpm rpms/grep-2.5.1-48.2.i386.rpm rpms/ethtool-3-1.i386.rpm rpms/module-init-tools-3.2-0.pre9.0.FC4.1.i386.rpm rpms/util-linux-2.12p-9.13.i386.rpm rpms/mkinitrd-4.2.15-1.i386.rpm rpms/udev-071-0.FC4.2.i386.rpm rpms/SysVinit-2.85-39.i386.rpm rpms/cpio-2.6-9.FC4.i386.rpm rpms/gzip-1.3.5-6.i386.rpm rpms/lvm2-2.01.08-2.1.i386.rpm rpms/MAKEDEV-3.19-1.i386.rpm rpms/popt-1.10.1-22.i386.rpm rpms/pcre-5.0-4.1.fc4.i386.rpm rpms/libsepol-1.5.10-1.1.i386.rpm rpms/zlib-1.2.2.2-5.fc4.i386.rpm rpms/ncurses-5.4-17.i386.rpm rpms/device-mapper-1.01.02-1.0.i386.rpm rpms/hotplug-2004_09_23-7.i386.rpm rpms/mingetty-1.07-5.i386.rpm rpms/less-394-1.fc4.i386.rpm rpms/readline-5.0-3.i386.rpm rpms/hwdata-0.158.3-1.noarch.rpm rpms/net-tools-1.60-52.fc4.1.i386.rpm rpms/libattr-2.4.24-1.FC4.1.i386.rpm rpms/shadow-utils-4.0.12-6.FC4.i386.rpm rpms/tar-1.15.1-11.FC4.i386.rpm rpms/kernel-2.6.15-1.1831_FC4.i586.rpm rpms/chkconfig-1.3.23-0.4.i386.rpm rpms/fedora-release-4-2.noarch.rpm rpms/iputils-20020927-22.i386.rpm rpms/gawk-3.1.4-5.3.i386.rpm rpms/info-4.8-8.fc4.1.i386.rpm rpms/psmisc-21.5-5.i386.rpm rpms/sysklogd-1.4.1-30.i386.rpm rpms/procps-3.2.5-6.3.i386.rpm rpms/iproute-2.6.11-1.i386.rpm rpms/db4-4.3.27-3.i386.rpm rpms/libstdc++-4.0.2-8.fc4.i386.rpm
# du testfs -h --exclude proc --exclude dev -s 186M testfs
2) This is an i386 busybox with most mod cons and locale support, still using FC4 glibc (notice stuff like selinux libs, db4 and initscripts are gone)
rm -rf testfs ; mkdir -p testfs/dev ; chmod 777 testfs/dev ; mknod testfs/dev/null c 1 3 ; chmod 666 testfs/dev/null ; mknod testfs/dev/zero c 1 5 ; chmod 666 testfs/dev/zero ; rpm -r /usr/src/silentcat-0.2/packages/testfs -i basesystem-8.0-5.noarch.rpm setup-2.5.44-1.1.noarch.rpm rpms/filesystem-2.3.4-1.i386.rpm rpms/libgcc-4.0.2-8.fc4.i386.rpm /home/packager/rpm/RPMS/i386/busybox-1.1.0-21.i386.rpm rpms/zlib-1.2.2.2-5.fc4.i386.rpm rpms/glibc-2.3.5-10.3.i386.rpm rpms/glibc-common-2.3.5-10.3.i386.rpm rpms/tzdata-2005r-3.fc4.noarch.rpm
# du testfs -h --exclude proc --exclude dev -s 107M testfs
3) This is an i386 uclibc + busybox minimal filesystem, with ash, most coreutils, common goodies like network, ifconfig, udhcpc, modprobe, etc, etc. Without kernel though, which will be an extra 1.2MB or thereabouts. It has various libs including libstdc++, and libc provided by uclibc.
$ du -h build_i386/root -s 3.7M build_i386/root
-Andy
On Wed, Feb 08, 2006 at 02:37:23PM -0500, David Zeuthen wrote:
Does this laptop really need a full bash?
Does this laptop really need a shell?
The busybox and shell setup on the Nokia 770 rather proves the value of a shell I think. You don't need it, you can't even get at it without adding packages but it makes it possible to do many things.
Shells are cheap (40-50K) unless you let the FSF near them
On Wed, Feb 08, 2006 at 03:47:52PM +0000, Andy Green wrote:
requirements of mesh networking in combination with the abilities of the madwifi device driver have driven this selection; it is the best and most flexible wireless device driver today. There are not other viable alternatives at this time.
Madwifi is not free software.
Alan
Alan Cox wrote:
On Wed, Feb 08, 2006 at 03:47:52PM +0000, Andy Green wrote:
requirements of mesh networking in combination with the abilities of the madwifi device driver have driven this selection; it is the best and most flexible wireless device driver today. There are not other viable alternatives at this time.
Madwifi is not free software.
http://madwifi.org/wiki/ngFeatures
License and HAL
* The license for the driver has not changed. It is still dual BSD / GPL v2 licensed. * The HAL is still binary only and will still taint the kernel.
http://madwifi.org/browser/trunk/hal http://madwifi.org/browser/trunk/hal/public
Hm
http://pedia.media.mit.edu/wiki/OLPC_on_open_source_software
• Must include source code and allow modification so that our developers, the governments that are our customers and the children who use the laptop can look under the hood change the software to fit an inconceivable and inconceivably diverse set of needs. Our software must also provide a self-hosting development platform.
• Must allow distribution of modified copies of software under the same license so that the freedoms that our developers depend upon for success remain available to the users and developers who define the next generation of the software. Our users and customers must be able to localize software into their language, fix the software to remove bugs, and repurpose the software to fit their needs.
-Andy
On Wed, 2006-02-08 at 12:04 -0500, Alan Cox wrote:
On Wed, Feb 08, 2006 at 03:47:52PM +0000, Andy Green wrote:
requirements of mesh networking in combination with the abilities of the madwifi device driver have driven this selection; it is the best and most flexible wireless device driver today. There are not other viable alternatives at this time.
Madwifi is not free software.
Indeed. It would be entirely unacceptable to use the illegal madwifi HAL, and that fact has been made clear to all involved. Trust me :)
On Wed, 08 Feb 2006 15:47:52 +0000, Andy Green andy@warmcat.com wrote:
Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept.
You must be raving mad to suggest uclibc. Was that supposed to be a sarcastic pun on the miniscule RAM spec?
-- Pete
Pete Zaitcev wrote:
On Wed, 08 Feb 2006 15:47:52 +0000, Andy Green andy@warmcat.com wrote:
Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept.
You must be raving mad to suggest uclibc. Was that supposed to be a sarcastic pun on the miniscule RAM spec?
What do you see shrivelling up and dying from contact with uclibc? I am using it here with good success, admittedly on a limited range of apps, but all stuff like coreutils and packages at that level like procps and so on are fine, as is openssl, php and lighttpd.
What is your opinion about newlib?
-Andy
On Wed, 08 Feb 2006 20:58:06 +0000, Andy Green andy@warmcat.com wrote:
Pete Zaitcev wrote:
On Wed, 08 Feb 2006 15:47:52 +0000, Andy Green andy@warmcat.com wrote:
Actually quite encouraging, we'll see if "busybox" and "newlib" or "uclibc" form part of Rehdat's concept.
You must be raving mad to suggest uclibc. Was that supposed to be a sarcastic pun on the miniscule RAM spec?
What do you see shrivelling up and dying from contact with uclibc?
I see now that you built Asterisk with it, so it cannot be all that bad. My experience may be stale.
What is your opinion about newlib?
It's supposed to be better, but I do not have a personal exposure.
-- Pete
On Wed, 2006-02-08 at 15:47 +0000, Andy Green wrote:
"We plan to use the JFFS2 journalling flash file system on the flash..." "At this point, OLPC looks most favorably on the GTK+/Pango/ATK toolkit"
Sounds good! Be aware tho that large JFFS2 filesystems are really slow to mount.
Feedback on that now that we have it running and I've optimised JFFS2 a little bit.... it takes 5.9 seconds to mount the 512MiB flash, of which about 5 seconds is actually spent reading the flash, rather than in JFFS2 code. The flash controller on the board is reading the flash at about one tenth of the speed it should be, so our ideal mount time ought to be under two seconds.
We're working on improving the raw flash speed, and I'm also going through the JFFS2 'eraseblock summary' code to halve the amount of data we have to read from the flash at mount time, so even with the existing hardware it should go down to 3s or so.
I'd like to get it down to ~1s.
David Zeuthen wrote:
Well glad to hear it, I hope these rather fundamental questions will still be in scope by then.
Our current thinking (and code) revolves partly around making it easier to build derived lean distributions based on Fedora Core. All this includes fixing a few obvious and not-so-obvious things in Core; it includes lots of thinking about distribution and updates in scenarios that the OLPC project targets (e.g. millions of users, extremely low admin/user ratios, think appliance); it includes thoughts about how lock down and provide a secure OS out of the box; it includes thinking about how to fit this in almost no space with very limited RAM and worse.. no swap; it includes thinking about how to easily enable application developers and other stake holders to participate... and a whole bunch of other stuff too..
These are the preoccupations daily dealt with by embedded developers. I'm sure there are plenty of capable embedded devs in Redhat still, but I take from your answer that this is going to stay Redhat internal until it is set in stone. That's probably not so bad generally except that my suggestions are about the fundamentals of it that will be decided by then. I guess I did the suggestion action.
Core as it is implies quite a heavy demand on RAM, flash and CPU horsepower. I really do think what I said before about triage modifying the machine spec stands a good chance to happen (given that commitment is apparently being requested for money for a machine at a specific price point, and the easiest fat to trim is the CPU and memory), or, if not, the machine may grossly fail to meet its price point[1]. And that has a lot of ramifications on how to come at it that start to diverge from a vision of Fedora Tiny or whatever still looking much like what you get with today's minimal Fedora resolved packageset (especially in installed storage footprint).
It's also useful to keep in mind that the software side of the OLPC project is larger than the bits Red Hat will provide - there's a bunch
Well I can't usefully comment on the usermode stuff.
Anyway, it's probably not useful to start a huge thread here about these high-level thoughts (read: no need to reply)... First of all we need a
I will be interested to see what you come up with.
-Andy
[1] Reality check: how much would a PDA cost with those features, CPU and Memory in today's prices, minus say 60% for manufacturer and retailer margin and extra goodwill? An HP IPAQ hx4700 with 64MB SDRAM and 128MB flash, wifi etc, is GBP337 ($586.38)
http://www.dabs.com/ProductView.aspx?Quicklinx=380L&CategorySelectedId=1...
If we accept that base price despite no meeting the featureset then we still reach $234 with our -60% modifier. -70% gives $175. They need a -83% modifier to reach $100.
On Tue, 2006-02-07 at 10:11 +0000, Andy Green wrote:
Seems hard to believe that with such a low price point, AMD will deliver optimal pricing and that the target CPU throughput is not excessive with x86. Isn't it better for the longer term to only weakly couple the concept of the cheap laptop to a processor arch?
The choice of i386 was apparently largely influenced by the availability of a real FPU; something which wasn't really available in the same price/performance range on other embedded CPUs that were considered.
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Andy Green -
Dan Williams -
David Woodhouse -
David Zeuthen -
Jesse Keating -
Nicolas Mailhot -
Pete Zaitcev -
Peter Robinson