[Fedora-livecd-list] one-livecd-per-child?

[Jane Dogalt]

--- Andy Gospodarek <gospo at redhat.com> wrote:
 
> You know what the 'killer app' would be for the any fedora-livecd:
> pilgrim.  I realize we don't want to have 30 'official livecds' but
> it
> would be great to have one of them that made it easy for others to
> make
> their own livecd.  

You pretty much described the central aspect of my original post.  I.e.
make a default livecd feature the ability to effectively do a 1-button
regeneration from scratch* of the livecd, with arbitrary user
modifications.  I.e. in the example, the first user modification is to
just add the text 'hello world' to a file, to demonstrate to the child
that all they have done to 'program a computer' is change one little
'instruction', then hit rebuild, and there you have a newly created
appliance/firmware/livecd that 'does your bidding'.

That seems to me like boiling down the concept and teaching process of
'programming a computer' to its simplest.  (that involves some tactile
reward of holding onto a newly burned cd/media that 'does something')

*If you think about that crazy 'genesis' post I made a couple months
ago, you can see where I'm going.  I.e. put the entire source code on
the cd (in standard fedora source repo format), and put the build tool
(pungi?) in place which can literally recompile everything from
scratch, and give you a trivially rebranded hello world distribution. 
Of course this is sounding a lot like linuxfromscratch now, which I've
never had the time or justifcation to explore as much as I should have.


I once wanted to build a livecd to help someone
> clean
> their system (since they were sure it was infected with a nasty
> virus)
> and getting setup to build a livecd with the right tools was too
> cumbersome based on the amount of time I had.  Being able to download
> a
> livecd and boot it (or run with qemu) to make another would be
> awesome.
> It would allow me to make livecd's on almost any system.  (Sorry if
> this
> has already been discussed on the list, but I haven't been reading it
> much lately.)

Ahh... self-reproducing livecds...  Nope, there hasn't been enough talk
of it yet IMO.

> 
> > 
> > If the computers to be used by the students got 1GB of RAM or more,
> it
> > would even be faster, or at least as fast, as using a native
> install.
> 
> I didn't think of that, but it would be.  I assume that you are using
> tmpfs (or something similar) so the pages storing the applications
> allow
> them to execute in place.
> 

Yup, we are definitely reaching the age where a 1GB fedora install can
start to become 'firmware' basically.  


> > 
> > We would need the "keep state on USB stick" feature but that is not
> a
> > lot of work. The most work with this feature are writing UI tools
> so the
> > user can designate all or part of a USB stick to be used for
> > persistence. Probably some small python app is the right answer.
> 
> For the first pass, just being able to mount the usb stick easily and
> read write files to it would be fine.

Hmm... mounting and using external drives easily.  The never solved
linux problem. 


  Customization of the running
> environment based on the contents of the stick would be great, but we
> would probably want to focus on an easy way to have the stick mounted
> and accessed.  There might need to be some extra considerations as
> well
> since everything should work with a FAT-formatted stick (so everyone
> in
> the world doesn't have to reformat their sticks to ext/jffs to make
> them
> work on the fedora-livecd).

This isn't a big deal, as you just store a filsystem image file (or
devicemapper snapshot device image) on the usbstick.  That and
otherwise provide 'easy-to-use(tm)' access to the rest of the usb fat
fs from the livecd environment.
 
-dmc/jdog



 
____________________________________________________________________________________
Get your own web address.  
Have a HUGE year through Yahoo! Small Business.
http://smallbusiness.yahoo.com/domains/?p=BESTDEAL