Maybe the fedora usability sig can take a look on this. This can be a good
point for starting contributions ;-)
2006/9/23, Paul W. Frields <stickster(a)gmail.com>:
> On Sat, 2006-09-23 at 16:37 +0100, Dimitris Glezos wrote:
> > Hello all,
> > I just noticed that some of the system-config-* applications do not have
> > "Help" -> "About" -> "Credits" -> "Translators" menu, which is there to
> > credit to translators of the particular locale. All GNOME applications
> that I
> > have seen do have this menu item. I suggest we incorporate this too.
> > In the "About Fedora" dialog, there is a link saying "visit our website
> > http://fedora.redhat.com/About/Projects/translations/". Shouldn't that
> > changed to link to the wiki?
> Yes. During the last cycle, Translation had not yet moved any content
> to the wiki. That's all changed and so I have fixed this link.
> Paul W. Frields, RHCE http://paul.frields.org/
> gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
> Fedora Project Board: http://fedoraproject.org/wiki/Board
> Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject
> Fedora-trans-list mailing list
On Wed, 2006-09-20 at 10:48 -0700, Toshio Kuratomi wrote:
> Does pilgrim make an attempt to integrate any of stateless's work? In
> my mind integrating stateless with livecd creation just makes sense.
> But I don't think there's been much work done on that front since
> Jeremy's proof of concept fork of kadischi which I don't think he's been
Nope, I think it's much more elegant to just use dm-snapshot to provide
a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people
working on stateless team thinks of this, they might have a number of
good reasons that I haven't thought out. I still think stateless makes
sense for non-livecd work however.
Btw, If someone could talk davej into including unionfs into the Fedora
kernel, we'd use that instead of dm-snapshot and we'd have persistence
more easily solved .
 : we can already do this for our livecd but it will be tied to the
specific build you're using, e.g. in practice it's tied to the physical
media you created it with.
With unionfs things might look much better and we'd easily be able to do
a harddisk install of "livecd + your changes made" instead of harddisk
install becomes contents of "stock livecd", ie. without your changes.
That said, I'm not sure that this really matters in real life.
(adding back fedora-desktop-list as that Cc: field mysteriously
On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote:
> You really should use the stock Fedora Core utilities however.
> If you are making an installer to system from LiveCD, why not use Anaconda?
I'd rather ask; Why use anaconda? At the end of the day, installation is
a pretty basic task
- yum install what you want
- write out some configuration files
- perform other post-installation configuration.
So, you know, I'd hate to replace < 100 lines of code by depending on
anaconda, which, I might add, is designed to do far more than the
relatively straightforward task of doing live cd's. I'm not even sure it
makes sense to carry around code in anaconda to facilitate live cd
installs but I'll leave that judgement call to the Anaconda developers.
FWIW, yum works perfectly fine and one goal of the pilgrim effort is to
make the process as robust as possible as well as being able to run on
host OS'es that are not super current. For example, the image I linked
to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on
There's also an historical angle here - pilgrim is the successor to the
now defunt olpc-image tools. Anaconda simply didn't allow to be used in
> If OLPC is a "derived" from Redhat or Fedora Core distribution, I really
> do not see how this pertains to this list.
I think Rahul answered this already. I'll also note that this is not a
kadishchi specific list (or at least that's my impression) and several
people have asked me to specifically post my work here.
> On another note, what functionality does this LiveCD stuff you mention
> provide over Fedora Core's Kadischi?
> If you are unfamiliar with Kadischi, you can find it here:
> Available via CVS.
I think there are some key differences
- specifically designed to be able to install the livecd payload on
your hard disk. I've read through the archives of this list and
seen objections from Jeremy and others about the feasibility
of changing Kadischi to facilitate this. Pretty sure there are
few objections to the approach I've taken with pilgrim but I'll
leave Jeremy to comment.
- designed specifically with downstream consumers in mind, e.g. it
must be extremely simple to put together an Fedora Eclipse,
Fedora Music, Fedora Livna Desktop, whatever live cd. This is what
I tried to describe in my original mail.
- r/w root so the OS actually works like it's supposed to (with
the live cd ISO that I linked to you can easy yum install what
you want or perhaps even use pirut)
- Use selinux - ok, so I ran into some issues with enabling this
(see the README.fedora file) so it's disabled in the ISO I linked to.
However, if your build environment matches the target environment
this works nicely. I'll be working on fixing this, certainly OLPC
needs this feature anyway.
- the codebase pilgrim is based on have been used successfully to build
OLPC images for many months now. Pilgrim have now replaced this and
is a critical component of the OLPC release infrastructure. As such,
I and others are committed to maintaining pilgrim for at least this
So these are the key differences I think.
You probably know how it is with software development. People will use
your software in unforeseen ways. As such, as software developers we
tend to make our software prepared to do this. I just happened to
identify a huge overlap between what we're doing in OLPC and what a nice
livecd infrastructure should look like. So I spent a day or two making
pilgrim doing just this.
Hope this clarifies.
On Wed, 2006-09-20 at 10:38 -0700, Toshio Kuratomi wrote:
> > Well, I take it that you are aware that cd media is not normally
> > partitioned (it is for bizarre things like Apple Mac OS X install CD's
> > using Apple Partition Map; but that is totally not relevant for a Fedora
> > Live CD on any architecture we want to support).
> I was confused when I first read autopsy's comment as well. Autopsy,
> are you talking about partitioning when creating the liveCD/liveX image?
> Or talking about paritioning when installing from liveMedia to a hard
I might add that for the latter, we want to allow the user to create
LVM / swap / crypto whatever to install to. That's why we need something
like gnome-diskutil that I mentioned in the README.fedora.
> I like pilgrim's simplicity. I'm a little hesitant that it's written in
> shell (Shell doesn't scale to larger projects nearly as well as python.
> Although the original kadischi code had a lot of
> reimplementation-of-the-wheel problems.)
Shell was chosen as that's the natural language you want to use when
defining derivatives. It's simple, lots of people know it and it's very
Btw, I don't expect pilgrim to grow a lot in size and complexity, it's
pretty much feature complete except for a few features.
For the record, I've written quite a bit of stuff in python but always
ended up disliking it - I guess I'm one of the types of programmers that
pick extremes. I love writing code in C and think I'm good at it. Shell
is pretty useful for stuff like pilgrim. Python always been in the
middle for me, I like to call it a "cute" language, but not really
useful for the stuff I wanted to do. It always ended up letting me down
one way or another. Of course, YMMV, I understand and see that some
people use Python in wonderful ways, more power to them. I just don't
> I'll have to run pilgrim to see how kadischi and pilgrim differ in real
Let me know if you need help. I tend to hang out on #fedora-desktop on
GimpNet and #freedesktop on freenode as davidz. I suppose this list if
fine to use too.
On Wed, 2006-09-20 at 10:41 -0500, Jasper Hartline wrote:
> David Zeuthen wrote:
> >(adding back fedora-desktop-list as that Cc: field mysteriously
Doing this again. Please don't munge the To: or Cc: headers. Thanks.
> >So, you know, I'd hate to replace < 100 lines of code by depending on
> >anaconda, which, I might add, is designed to do far more than the
> >relatively straightforward task of doing live cd's. I'm not even sure it
> >makes sense to carry around code in anaconda to facilitate live cd
> >installs but I'll leave that judgement call to the Anaconda developers.
> Ok. Good luck partitioning a disk in any sort of way with Yum.
Well, I take it that you are aware that cd media is not normally
partitioned (it is for bizarre things like Apple Mac OS X install CD's
using Apple Partition Map; but that is totally not relevant for a Fedora
Live CD on any architecture we want to support).
So I assume you are talking about creating Live USB images, e.g. an
image people can dd(1) to the USB key e.g.
# dd if=some-image.img of=/dev/sdb
where /dev/sdb is the block device for your USB stick.
First, pilgrim supports this (partitioning is not hard), it was the
first installation target since that is what we use for OLPC; see
Second, a Fedora system on a USB stick / hard disk is useful.. Heck,
this can be done today with the pilgrim system by simple changes to
streams.d/fedora-base.stream in the pilgrim source tree (just define a
new variant, liveusb, where PILGRIM_FS_liveusb=ext3). The reason I
haven't done this is just lack of time. And motivation.
The lack of motivation has to do with the fact that I'm not sure how
useful it is since ext3 basically is pretty wasteful and have no
compression . To have any kind of useful system you'd need a 2GB or
bigger stick. Second, I think once we get the "install to hard disk"
feature done people can just install the OS to a USB stick / hard disk
from the livecd and be done with it. That will also ensure that we fix
up the UUID of the file system and other stuff.
We can easily add variants for "usb stick" builds until we have the
"install to hard disk" feature. But I'd rather that we worked on the
latter, that feature is so much more important for Fedora as gdk so
eloquently points out.
We could also add a new hack to use squashfs / ext3 / dm-snapshot hacks
to the live USB image where the overlay lives in a file on a different
partition of the USB stick. That way we'd have a semi-useful system that
would fit on a 512MB stick. Again, not sure how useful live USB is, I'd
rather focus on getting the "install to hard disk" feature done and just
tell people to install to a USB stick / harddisk if they want a portable
 : though I did read something about "compressed block devices" being
added to Linux. Dunno where that is going.
I've spend a little bit of time adapting the OLPC build system to be
able to spit out Fedora livecd's. First some background on what we do in
o OLPC is an OS built on Core but also includes bits from Extras and
a dedicated OLPC repository
o Rather than using an installer, we deliver the OS in two ways
- for USB sticks we provide an image that can be copied onto the
whole disk. This image includes a partition table, boot loader
and so forth. This image is also used for qemu.
- For installation to the OLPC hardware, we provide a JFFS2 file
system image that can be put on the flash using nandwrite from
o The build system must be easy for downstream to use for creating
a derived build of the upstream OLPC distribution. The thinking here
is that OLPC customers (which are governments, countries) are
able to very easily tweak the package selection, provide alternative
packages and change how the system is configured.
o (for more info on OLPC development, see http://dev.laptop.org )
As such, the goals are pretty similar to Live CD: Assemble an OS and put
it on bootable media. So I spent a few days a few weekends ago to do
exactly that; the how's, why's etc. are here
Specifically, I've made it a goal to make live cd's built with this
infrastructure possible to install to hard disks such as to provide a
nice user experience: you download the livecd and if you like it, you
simply press the "Install" icon on the desktop and the OS is installed
in a matter of minutes. No need to go through anaconda here. The
README.fedora file linked to above contains some pretty specific
information of what we need here. With some hard work perhaps we can
make this happen for FC7.
Another important goal is that it should be easy to create derived CD's.
So if you are into the whole Java and Fedora things, maybe you want to
easily create a Fedora Eclipse livecd. You know, to show off to your
friends. I've included an example here, fedora-eclipse
note how fedora-eclipse is derived from fedora-gnome
which in turn is derived from fedora-base
and also that fedora-desktop
is derived from fedora-base. Ie. we have
There is nothing to prevent us from having
| | |
fedora-eclipse fedora-desktop fedora-music
in the future. For example, it's not far fetched, I think, to have
people from the tools group in Red Hat maintain the fedora-eclipse live
cd bits (in fact, I'm not even sure if that image builds any more, it
did some weeks ago. But y'all get the point, yes?)
The very nice thing is that downstream, for example fedora-eclipse and
fedora-eclipse-kde, would benefit from general improvements in
fedora-gnome and fedora-kde. The barrier to entry is pretty low, just
look at the simplicity of of the current fedora-eclipse and
fedora-desktop stream definition files.
Anyway, enough talk, it's getting late and I'm too old to miss sleep
these days :-) - Here's a screenshot of the fedora-desktop livecd
and here is an ISO, weighing 618MB, of fedora-desktop