Brainstorming is good.
These thoughts are good. :-)
Some thoughts on these thoughts:
* The only architecture for which we offer a boot floppy is x86.
* If we can conclude that we can (programatically, consistently, and
in a way that's easy for the consumer) make grub, or some other
pxe-boot-loader-on-a-floppy work with any (or almost any) net
driver on x86, then I think this may be a very clean exit from
continuing to limit boel to a floppy.
Advantages:
* I would also like to see a perl or python (or both) interpreter in
boel.
* It could simplify our build environ -- no more uClibc, less need
to rely on busybox. Busybox rocks, but it would be nice to use
some of the full featured tools from the get-go (tar).
* Who knows what kinds of cool solutions our developers would come
up with if we were to tear down the limitations imposed by the
boot floppy constraint!?!
So, Andrea,
Can you provide us with additional justification for providing a grub,
or other pxe-capable generic floppy, and some specifics on driver
support to help us make this decision? It sounds good so far...
Please let us know, and make a specific proposal if it still looks
feasible to you. :-)
I'm also very interested in the bittorrent idea. It's something that
Bernard approached me with at the last LinuxWorld (or was it
SuperComputing?), but we haven't been able to pursue much yet. We
should engage Bernard on this one regardless of the floppy decision, but
deciding on removing the floppy constraint could certainly make a
bittorrent implementation easier.
Cheers, -Brian
Andrea Righi wrote:
> Brian Elliott Finley wrote:
>
>> What should we do about floppy installs with 3.5.x and higher? There
>> may be other options, but here are a couple that come to mind:
>>
>> 1. Stop supporting floppy installs as of 3.5.x.
>> 2. Offer an even more minimalist kernel with the most popular
>> hardware only. Ie:
>> * e100, e1000, tg3 net drivers only
>> * IDE plus the top 3 scsi drivers
>> 3. Put up a good "HOWTO Build Your Own Boot Package" on the Wiki.
>>
>> Thoughts?
>>
>>
>>
>
> Hi all,
>
> I agree with both the points 1 and 3. IMHO it is not a good solution to
> sacrifice the kernel and offer less hardware support only to put the
> kernel & initrd in a single floppy...
>
> Moreover there are many programs that allow to use the PXE boot feature
> using a floppy disk... and that programs support a lot of network cards.
>
> For example GRUB implements the BOOTP protocol and a lot of network
> drivers, so it can be used to boot from network; I think you must
> recompile it to use this feature... but, who cares? for example we could
> also distribute a pre-compiled floppy image with GRUB already installed,
> or include the grub code + an opportune config file in SystemImager
> (analogous to each external software we're distributing).
>
> With this approach you are forced to setup a PXE server, but there is
> the image-server that can do this in a simply way (si_mkbootserver).
> Otherwise you should always use a CD-ROM...
>
> Moreover if you break the 1.44MB constraint we could consider to
> implement a lot of new features inside the BOEL kernel.
>
> For example we could use the same kernel that will be installed in the
> clients to test some hardware compatibilities at the installation time.
>
> Or imagine to put a perl/python interpreter inside the initrd... doing
> so we should consider to put some evolved technologies to propagate
> the images on client... we could also use a peer-to-peer approach...
>
> I mean bittorrent for example; in a scenario like this, I'd be able
> to strongly reduce the time to deploy the operating systems on the
> clients... probably in a way faster than flamethrower), exploiting
> also the output band of each clients: the image-server should be the
> tracker, for example, and the clients leechers and seeders...
>
> I think that massive installations should gain a lot of benefits with
> this kind of approaches. Here in CINECA, for example, we should be very
> interested in such functionalities and maybe I could dedicate some
> time to port, for example, bittorrent (or something similar... I know
> only that...) inside SystemImager..
>
> Opinions? (I've a little digressed with some brainstorming...;))
>
> Best regards,
> -Andrea
>
>
--
Brian Elliott Finley
Mobile: 630.631.6621
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Sisuite-devel mailing list
Sisuite-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sisuite-devel
