On Thu, Aug 28, 2008 at 10:33:54AM -0800, Jeff Spaleta wrote:
On Thu, Aug 28, 2008 at 9:54 AM, Luya Tshimbalanga
> The minimalFedora system weighed in at 67MB. 58MB was in /lib/modules. I could
> easily pare that down to a few MB, remove unused drivers with a little work.
> Another 6.5MB was in /boot and 1.7MB in busybox. Aside from the homemade
> inittab and rcS (init script) it was all from the Fedora distro,".
It's interesting...but if i'm reading the post correctly, he's
basically sacrificed the ability to receive system updates...that has
consequences. Consequences we as a project might not officially want
Now maybe he and a few other people can support pushing update images
instead of individual packages or something to deal with updates. But
a solution like that would classified as a derived distribution. Can
we make room for that sort of community effort under the larger Fedora
Project? The people who want to do this, they may need to provide
their own hosting and image compose iron. We may not be able to put
existing project resources towards it.
We are doing exactly this kind of model in the oVirt project. For the
'oVirt managed node' (ie the OS which hosts the virtual machines), we
build a OS appliance image using a derivative of livecd-creator. This
runs stateless - all persistent config is stored in oVirt's management
system. We just load the entire OS image over PXE at boot time. We're
currently building off Fedora 9 repos, and have a < 64 MB OS image.
Per-RPM updates are irrelevant - since we're stateless, we just upload
a new OS image to the PXE server and reboot the host in question and
it'll be running the new code. The key issue here is obviously the
periodic distribution of the binary OS images - arguably you could just
put the pre-built OS image inside an RPM and just use 'yum update' to
pull it down to the PXE server.
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|