As the following touches many topics, please reply suitably modifying the subject line.
I'd like to start a discussion about what applications set to include on a spin targeted at G1G1 purchasers looking for a "conventional" laptop. Daniel Drake's initial experiments make it seem like with care a Gnome desktop is usable, which is a much more polished environment than xfce (which while smaller, is much more of a hacker's system), if one is careful on app selection. Having said that, if someone wants to do an xfce spin too, that is not a bad thing to have in one's hip pocket.
For the basic spin, we'll have very limited flash, and should not presume the use of swap (so RAM matters too).
Here's some things that I think are a given (note that others are very open to discussion)...
Remember: we have a zero-sum game here. Everything we put in, requires we take things out... The question will just be what to take out, and how much work it will require to do any needed repackaging...
Toolkit stack -------------
GTK+/Pango/cairo toolkit for UI applications (for I18N and Sugar compatibility)
ATK, but only as an option (it pulls in some of the more objectionable bonobo dependencies at the moment).
Avoid Mono libraries in basic load (footprint)
Window Manager -------------- Metacity
Definite outs -------------
Open Office (too big basic footprint; users can load if they want/need it) Evolution (Oink, Oink)
Graphics drivers for everyone else's hardware: these add up
Fonts We'll need to sort through a lot of these and nuke a lot of bitmap and other fonts (e.g. type1, etc).
Extra themes
Extra Wallpaper
Some icon sizes, those generally used at 72DPI.
Basic apps and accessories ==========================
Panel Applications Accessories Archive Manager (dependencies?) Calculator Character map Screen shot Text editor Games What games? Can we afford the gnome assortment, or must we repackage for size reasons? Download size is only a bit over 1 meg compressed bz2, so I'm tempted to include them all. Graphics Some camera app for the camera (see below) Some image viewer. (see below) Internet Mail client (see below) Firefox RSS reader (see below) Instant message program (see below) Office Abiword Gnumeric Sound and Video Totem Rythymbox (see below???) Pulseaudio volume control? Sound recorder System tools Disk Management File Browser SE Linux stuff (can we afford SELinux????) System Log System Monitor Terminal Panel->System Preferences Personal About Me File Management Keyboard Shortcuts Preferred Applications (dependencies may kill us). Sessions Look and Feel Appearance Main Menu Screen Saver Windows Internet and Network Network Proxy Hardware Default Printer (see below) Keyboard Mouse Sound Volume Control Systems Authorizations (????) Power Management System Update
Administration Add/Remove Software Date & Time Firewall (?) Language Network Network Device Control Printing (see below) SELinux Management (if we can afford SELinux....) Services Software Sources Update System
Applets Custom app launcer Application Launcer Character Palette Clock (if we don't get screwed by the cities data) Command Line Disk Mounter Drawer? (does anyone use these?????) Force Quit Lock Screen Log out Main Menu Menu Bar Network Monitor Notification Area Run Application Separator Show Desktop Shutdown Sticky notes (Tomboy pulls in Mono, IIRC). Trash Volume control Window List Window Selector
Definite ins ------------ Gnumeric Abiword Firefox (some may question this, but I'm not yet sold on webkit) evince
Meta-packages ------------- I'd love to have a few metapackages to pull in a set of o Sugar!! (unless we squeeze enough to get in the base image, which is my first choice...) o regular games o educational games o graphics - (gimp, inkscape, others) o If we need to strip below where we would like to get olpc-update to be an installation path, a meta-package to pull in the rest of basic functionality. o accessibility
Questions =========
All these need to be vetted for size and dependencies!!!!!
1) mail client.... The logical candidates would include Thunderbird, Claws, Sylpheed, Balsa. Are there others? Sylpheed has poor docs. I'd be quite interested in Thunderbird, but right now, Thunderbird 2 is based on the old gecko engine, and won't make it in time, so would come at a higher cost of both flash and RAM footprint.
Possibilities I know of boil down to Claws and Balsa. Opinions?
2) RSS reader.... Claws has a plug in; Firefox can do it, but dunno how well; others?
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 are in an IPP environment, you can then find a cups server (Linux or Mac) and use it, or could the last I tried (2.5 years ago) - any volunteers? This is literally like 1 file to configure and test (I had some trouble in the large MIT Media Lab environment when I tried it 2.5 years ago. c) minimal configuration of printer drivers for most popular printers - but who would do this work? Would be generally beneficial, however, to cull a lot of antique prs.inter d) full printing database - probably not feasible at all and would be best left to yum install.hat
4) What themes?
5) What camera application? Need something to demo the camera in the XO. This will likely need testing, as gstreamer/VFL2 seems immature in OLPC's experience....
6) what IM client? And don't suggest xchat ;-) Pidgin?
7) music player Rhythmbox? or something else? There are many to choose from.
8) Our screen is small, and the keyboard inappropriate for people with disabilities under many circumstances. I think we should keep accessibility out of the basic load if we can, to save space. But a meta package to pull in the usual stuff is well worthwhile, as the size and cost of the OLPC has in particular attracted the interest of people with certain classes of disabilities. I still worry about its memory footprint, however.
- Jim
Some comments inline :
On Wed, Sep 3, 2008 at 8:38 PM, Jim Gettys jg@laptop.org wrote:
Fonts We'll need to sort through a lot of these and nuke a lot of bitmap and other fonts (e.g. type1, etc).
Wrt fonts: I would suggest having the Dejavu series of fonts and the Liberation series. The primary target is G1G1 users, as per my understanding, and in that case, these two fonts should cover most of the requirements.
Games What games? Can we afford the gnome assortment, or must we repackage for size reasons? Download size is only a bit over 1 meg compressed bz2, so I'm tempted to include them all.
gnome-games was split in the past to have a separate package for the heavy (dis space wise) components like extra artwork, themes, etc. In that case the base gnome-games package can be included, I think.
Definite ins
Gnumeric Abiword Firefox (some may question this, but I'm not yet sold on webkit)
Some suggest that Epiphany is lighter than firefox at times - I'm not sure whether this is true or not. Also, if Epiphany-webkit is packaged for Fedora, I would definitely like to give it a shot.
- What camera application? Need something to demo the camera in the
XO. This will likely need testing, as gstreamer/VFL2 seems immature in OLPC's experience....
Cheese is an application that comes to my mind. It should (hopefully) work with the XO camera out of the box.
- music player Rhythmbox? or something else? There are many to choose
from.
The other major contender would be banshee - it's dependency on Mono leaves it out.
Thanks, Sayamindu
On Wed, 2008-09-03 at 21:40 +0530, Sayamindu Dasgupta wrote:
Some comments inline :
On Wed, Sep 3, 2008 at 8:38 PM, Jim Gettys jg@laptop.org wrote:
Fonts We'll need to sort through a lot of these and nuke a lot of bitmap and other fonts (e.g. type1, etc).
Wrt fonts: I would suggest having the Dejavu series of fonts and the Liberation series. The primary target is G1G1 users, as per my understanding, and in that case, these two fonts should cover most of the requirements.
Yes, until we get into eastern languages. But I don't want to go there initially....
Anyone care to spend some time to package a set of font aliases to cause use of outline fonts for the common antique bitmap families? This would be good in general to start weaning people off those disk space wasters....
I did this for at least a few fonts in the OLPC build (necessary if you run into any bitmap font applications), but stopped once we got flash and java to run that had such dependencies.
Definite ins
Gnumeric Abiword Firefox (some may question this, but I'm not yet sold on webkit)
Some suggest that Epiphany is lighter than firefox at times - I'm not sure whether this is true or not. Also, if Epiphany-webkit is packaged for Fedora, I would definitely like to give it a shot.
Data, RAM usage, disk footprint and compatibility would be needed to make a webkit sale. o Firefox 3 has done seriously better on memory consumption at the time of its release than other browsers, but it's a (constantly) moving target.... o Also note since Sugar's browse is based on Gecko/Xulrunner, there is sharing there when sugar is installed; installing something else would go to the detriment of the combined footprint for including Sugar.
Unless such data appears and is very compelling, I think Firefox is it, at least unless we decide to convert sugar's browse to webkit. I therefore don't plan to spend any time on this evaluation personally.
- music player Rhythmbox? or something else? There are many to choose
from.
The other major contender would be banshee - it's dependency on Mono leaves it out.
Ah, that makes it an easy choice, unless there is a third option....
Jim Gettys wrote:
On Wed, 2008-09-03 at 21:40 +0530, Sayamindu Dasgupta wrote:
Some comments inline : On Wed, Sep 3, 2008 at 8:38 PM, Jim Gettys jg@laptop.org wrote:
[...] snip!
Definite ins
Gnumeric Abiword Firefox (some may question this, but I'm not yet sold on webkit)
Some suggest that Epiphany is lighter than firefox at times - I'm not sure whether this is true or not. Also, if Epiphany-webkit is packaged for Fedora, I would definitely like to give it a shot.
Data, RAM usage, disk footprint and compatibility would be needed to make a webkit sale. o Firefox 3 has done seriously better on memory consumption at the time of its release than other browsers, but it's a (constantly) moving target.... o Also note since Sugar's browse is based on Gecko/Xulrunner, there is sharing there when sugar is installed; installing something else would go to the detriment of the combined footprint for including Sugar.
Unless such data appears and is very compelling, I think Firefox is it, at least unless we decide to convert sugar's browse to webkit. I therefore don't plan to spend any time on this evaluation personally.
Well, I'd agree with Jim - Webkit might have gained popularity in the last time, but I don't see a reason to switch, either. Webkit for Epiphany isn't ready yet, since it has been postponed due to issues with rebasing Evolution to Webkit (they want to rebase both Epiphany and Evolution). AFAIK, it won't be ready for Gnome 2.24, and therefore not for F10 (there's this compiling option to use Webkit with Epiphany, but...).
- music player Rhythmbox? or something else? There are many to choose
from.
The other major contender would be banshee - it's dependency on Mono leaves it out.
Ah, that makes it an easy choice, unless there is a third option....
Heh. Want me to come up with more? ;)
Well, the first question is, do we want to have something like Rhythmbox or Banshee in (I mean this iTunes-like music library) - or do we just want to stick with a normal player like Totem. If the first is the case, then we've...
rhythmbox, /me personally prefers this one banshee, pulling in mono, so no real option imo exaile, a amarok clone (not a real clone) based on GTK and Python quodlibet, another music library, based on GTK and Python
There's more stuff around... but I'm just adding 'em for completeness: If you want still talk about the mono, there's still stuff like cowbell and muine around. And if you need to go the complicated way, we could even run for songbird...
--Sebastian
On Wed, 2008-09-03 at 11:08 -0400, Jim Gettys wrote:
- RSS reader.... Claws has a plug in; Firefox can do it, but dunno how
well; others?
The atrocious liferea is probably one of the best RSS readers in Fedora.
Ignacio Vazquez-Abrams wrote:
On Wed, 2008-09-03 at 11:08 -0400, Jim Gettys wrote:
- RSS reader.... Claws has a plug in; Firefox can do it, but dunno how
well; others?
The atrocious liferea is probably one of the best RSS readers in Fedora.
/me agrees.
I think liferea pretty good, too - the question is, whether we need a seperate RSS reader: If yes, there are blam (which pulls in mono and is therefore no option) and penguin-tv (on which the XO activity is based on) around. The latter one isn't included in Fedora right now afaics, but they provide an RPM on sf.net... if we don't need a seperate one: see above!
--Sebastian
On Wed, 2008-09-03 at 19:39 +0200, Sebastian Dziallas wrote:
I think liferea pretty good, too - the question is, whether we need a seperate RSS reader: If yes, there are blam (which pulls in mono and is therefore no option) and penguin-tv (on which the XO activity is based on) around. The latter one isn't included in Fedora right now afaics, but they provide an RPM on sf.net... if we don't need a seperate one: see above!
--Sebastian
As always, depends on size and dependencies. But we can certainly punt entirely. - Jim
On Wed, 2008-09-03 at 11:08 -0400, Jim Gettys wrote:
As the following touches many topics, please reply suitably modifying the subject line.
I'd like to start a discussion about what applications set to include on a spin targeted at G1G1 purchasers looking for a "conventional" laptop. Daniel Drake's initial experiments make it seem like with care a Gnome desktop is usable, which is a much more polished environment than xfce (which while smaller, is much more of a hacker's system), if one is careful on app selection. Having said that, if someone wants to do an xfce spin too, that is not a bad thing to have in one's hip pocket.
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.
Then the discussion could still be relevant for a preloaded "dual-boot" XO, but exactly how much so could be debatable.
Toolkit stack
ATK, but only as an option (it pulls in some of the more objectionable bonobo dependencies at the moment).
ATK itself is, I suspect, pretty much impossible to avoid. The higher level bits that are actually the accessibility implementations I can see not including
Avoid Mono libraries in basic load (footprint)
We leave mono off of most of the live images already due to space constraints
Definite outs
Open Office (too big basic footprint; users can load if they want/need it)
Yep, again, matches what we do with the default live image
Fonts We'll need to sort through a lot of these and nuke a lot of bitmap and other fonts (e.g. type1, etc).
The default font set that's being installed now should be pretty reasonable. If not, letting someone from the fonts SIG know would be a lot better than just pulling haphazardly.
Games
What games? Can we afford the gnome assortment, or must we repackage for size reasons? Download size is only a bit over 1 meg compressed bz2, so I'm tempted to include them all.
Yeah, the basic gnome-games isn't big at this point and is a reasonable set.
Graphics
Some camera app for the camera (see below)
cheese should be being installed by default now and works okay
o graphics - (gimp, inkscape, others)
inkscape ends up being expensive as its one of very few things which requires gtkmm.
- mail client.... The logical candidates would include Thunderbird,
Claws, Sylpheed, Balsa. Are there others? Sylpheed has poor docs. I'd be quite interested in Thunderbird, but right now, Thunderbird 2 is based on the old gecko engine, and won't make it in time, so would come at a higher cost of both flash and RAM footprint.
Possibilities I know of boil down to Claws and Balsa. Opinions?
Claws is just an obsolete version of Sylpheed that's basically not maintained anymore iirc. Balsa is ... not good.
Maybe someone looking at building tinymail and modest would be interesting. As if it can fit on the n8x0, then surely it should be fine for the XO.
- RSS reader.... Claws has a plug in; Firefox can do it, but dunno how
well; others?
How many people really use standalone rss readers? I'm not really sure this is something that matters as part of a "default" application set.
- 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
- What themes?
While it's silly, having a few things to choose from by default here really makes people feel "better" about it being a complete desktop. If your target is someone using their G1G1 as a "normal-ish" laptop, then having a few themes by default is worth the small cost
- What camera application? Need something to demo the camera in the
XO. This will likely need testing, as gstreamer/VFL2 seems immature in OLPC's experience....
cheese should be the answer here. And if it's not good enough, file bugs/fix it.
- what IM client? And don't suggest xchat ;-) Pidgin?
With Fedora 10, there may be a transition to empathy from pidgin -- it's at least being tested out for the beta. Following that is likely the best plan
- music player Rhythmbox? or something else? There are many to choose
from.
As someone else said later in the thread, if you just want to play a few songs (seems somewhat likely given the lack of storage :), totem may well be plenty here.
Jeremy
On Wed, 2008-09-03 at 14:50 -0400, Jeremy Katz wrote:
On Wed, 2008-09-03 at 11:08 -0400, Jim Gettys wrote:
As the following touches many topics, please reply suitably modifying the subject line.
I'd like to start a discussion about what applications set to include on a spin targeted at G1G1 purchasers looking for a "conventional" laptop. Daniel Drake's initial experiments make it seem like with care a Gnome desktop is usable, which is a much more polished environment than xfce (which while smaller, is much more of a hacker's system), if one is careful on app selection. Having said that, if someone wants to do an xfce spin too, that is not a bad thing to have in one's hip pocket.
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.
Yes, but right now, the requisite kernel support is not available.
Nor will any existing spin fit in 1GB of internal flash.
So we need something for the moment.
Then the discussion could still be relevant for a preloaded "dual-boot" XO, but exactly how much so could be debatable.
Toolkit stack
ATK, but only as an option (it pulls in some of the more objectionable bonobo dependencies at the moment).
ATK itself is, I suspect, pretty much impossible to avoid. The higher level bits that are actually the accessibility implementations I can see not including
Could be...
Fonts We'll need to sort through a lot of these and nuke a lot of bitmap and other fonts (e.g. type1, etc).
The default font set that's being installed now should be pretty reasonable. If not, letting someone from the fonts SIG know would be a lot better than just pulling haphazardly.
Sure... But it looks like there is a significant amount of space to be had.
/usr/share/fonts# du 1684 ./default/ghostscript 4536 ./default/Type1 6224 ./default 296 ./mathml 7076 ./bitmap-fonts 13600 .
The Type1 renderer we have is terrible, and the bitmap fonts are antique and not used by any current modern Linux application. Some fallbacks need to exist, however.
inkscape ends up being expensive as its one of very few things which requires gtkmm.
Interesting.
- mail client.... The logical candidates would include Thunderbird,
Claws, Sylpheed, Balsa. Are there others? Sylpheed has poor docs. I'd be quite interested in Thunderbird, but right now, Thunderbird 2 is based on the old gecko engine, and won't make it in time, so would come at a higher cost of both flash and RAM footprint.
Possibilities I know of boil down to Claws and Balsa. Opinions?
Claws is just an obsolete version of Sylpheed that's basically not maintained anymore iirc. Balsa is ... not good.
I think you have it backwards; sylpheed-claws was the predecessor to claws, and is not maintained anymore. Sylpheed seems less developed.
Maybe someone looking at building tinymail and modest would be interesting. As if it can fit on the n8x0, then surely it should be fine for the XO.
- RSS reader.... Claws has a plug in; Firefox can do it, but dunno how
well; others?
How many people really use standalone rss readers? I'm not really sure this is something that matters as part of a "default" application set.
OK, we seem to be getting to consensus: don't worry about rss at all.
- 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.
- What themes?
While it's silly, having a few things to choose from by default here really makes people feel "better" about it being a complete desktop. If your target is someone using their G1G1 as a "normal-ish" laptop, then having a few themes by default is worth the small cost
OK, let's plan on 2 themes, unless space gets really tight.
- What camera application? Need something to demo the camera in the
XO. This will likely need testing, as gstreamer/VFL2 seems immature in OLPC's experience....
cheese should be the answer here. And if it's not good enough, file bugs/fix it.
Presuming dependencies are tolerable, let's go for it.
- what IM client? And don't suggest xchat ;-) Pidgin?
With Fedora 10, there may be a transition to empathy from pidgin -- it's at least being tested out for the beta. Following that is likely the best plan
- music player Rhythmbox? or something else? There are many to choose
from.
As someone else said later in the thread, if you just want to play a few songs (seems somewhat likely given the lack of storage :), totem may well be plenty here.
OK, we'll leave a music player off the initial manifest, beyond what totem provides.
On Wed, 2008-09-03 at 15:06 -0400, Jim Gettys wrote:
On Wed, 2008-09-03 at 14:50 -0400, Jeremy Katz wrote:
On Wed, 2008-09-03 at 11:08 -0400, Jim Gettys wrote:
As the following touches many topics, please reply suitably modifying the subject line.
I'd like to start a discussion about what applications set to include on a spin targeted at G1G1 purchasers looking for a "conventional" laptop. Daniel Drake's initial experiments make it seem like with care a Gnome desktop is usable, which is a much more polished environment than xfce (which while smaller, is much more of a hacker's system), if one is careful on app selection. Having said that, if someone wants to do an xfce spin too, that is not a bad thing to have in one's hip pocket.
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.
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 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
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.
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.
Fonts We'll need to sort through a lot of these and nuke a lot of bitmap and other fonts (e.g. type1, etc).
The default font set that's being installed now should be pretty reasonable. If not, letting someone from the fonts SIG know would be a lot better than just pulling haphazardly.
Sure... But it looks like there is a significant amount of space to be had.
/usr/share/fonts# du
[snip]
13600 .
The Type1 renderer we have is terrible, and the bitmap fonts are antique and not used by any current modern Linux application. Some fallbacks need to exist, however.
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
- mail client.... The logical candidates would include Thunderbird,
Claws, Sylpheed, Balsa. Are there others? Sylpheed has poor docs. I'd be quite interested in Thunderbird, but right now, Thunderbird 2 is based on the old gecko engine, and won't make it in time, so would come at a higher cost of both flash and RAM footprint.
Possibilities I know of boil down to Claws and Balsa. Opinions?
Claws is just an obsolete version of Sylpheed that's basically not maintained anymore iirc. Balsa is ... not good.
I think you have it backwards; sylpheed-claws was the predecessor to claws, and is not maintained anymore. Sylpheed seems less developed.
Err, yes -- I need more caffeine clearly. The point about the maturity of the app stands :)
- 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.
- What camera application? Need something to demo the camera in the
XO. This will likely need testing, as gstreamer/VFL2 seems immature in OLPC's experience....
cheese should be the answer here. And if it's not good enough, file bugs/fix it.
Presuming dependencies are tolerable, let's go for it.
It didn't end up pulling anything beyond itself into the live images when I added it a month or two ago, so it should be good. That's actually one of the nice things about it
Jeremy
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.
- 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
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
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.
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. The latest discussions I had with her centered around putting together an aftermarket solution that "just works", and making it possible for G1G1 folks to purchase that solution when they get the laptop.
Which implies that we should be focusing on USB/SD for now -- but Jim, you may want to validate that thinking inside the walls at 1cc.
--g
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.
Unfortunately, jffs2 does not have a way to say "don't compress a file", though dwmw2 has talked about this from time to time.
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.
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.
The latest discussions I had with her centered around putting together an aftermarket solution that "just works", and making it possible for G1G1 folks to purchase that solution when they get the laptop.
Which implies that we should be focusing on USB/SD for now -- but Jim, you may want to validate that thinking inside the walls at 1cc.
I will, though this is not my current understanding from previous conversations; it would make our lives somewhat easier and time is short; we've lost some weeks due to Fedora's mis-adventures, as we're still getting up to speed and have needed more of Jeremy's time than we've been able to get.
Having something that can run viably without USB or SD gives Linux a cost advantage over windows.
I'm also very concerned about applications selection that is so heavyweight that its performance will be poor: e.g. The stock Fedora desktop includes apps that will get us into pretty immediate trouble in RAM use, I think (e.g. evolution). I don't think an xfce desktop is what the general market will bear, sufficient though it is for hackers. - Jim
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.
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?
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.
Jeremy
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