Re: [Etherboot-developers] New directions for the Etherboot project

Hi,

Marty has been eloquent...

If he would have said "What about a gPXE prj?" I will probably answered 
"Ehhh????"

But the argumentations he led are convincing: if the code base will 
remain unified, and gPXE will be nearly a "compiling front-end" for 
etherboot (to make it simpler to use EB for getting PXE images), I agree 
for the gPXE prj.

It will surely widen EB community

A question: will gPXE cover only the first-stage loader (rom, floppy, cd 
etc etc...), or will it cover also the second-stage loader (UNDI driver, 
zpxe targets)?

What could a gPXE to-do list be?

Bye!

Paolo



Marty Connor ha scritto:
> Hello Everyone,
> 
> I've been thinking a lot lately about how to extend the infrastructure 
> needed to serve Etherboot's diverse user and developer communities, and 
> to build for the future.
> 
> It's taken some time, but I think I'm getting some clarity, so I'm 
> writing to share some ideas, and to start a conversation within the 
> Etherboot community, which includes developers, users, and people who 
> are generally interested in network booting technology.
> 
> __Growth and Expandability__
> Etherboot has grown lot, and is constantly gaining capabilities.  This 
> is a good thing, but after a while a single program can attempt to do 
> too much, and become difficult to maintain and use.
> 
> The inventors of Unix recognized this, and created a highly modular 
> operating system with pipes for inter-process communication.
> 
> The Linux kernel was once monolithic, but soon became modular to support 
> an avalanche of drivers and features that were contributed. Most Linux 
> distribution are package-based, allowing a diverse user community to 
> select features that they find appropriate for their individual situations.
> 
> The Mozilla project first created Mozilla, which included web-browsing, 
> mail, html page composition, and IRC chat.  Later, using Mozilla code, 
> Firefox (with a plug-in architecture) and Thunderbird were born, and 
> have flourished.
> 
> In a similar way, I believe that Etherboot has grown to a point where it 
> is time for us to generalize our code, and more importantly, ourselves.
> 
> __What Is Etherboot?__
> In thinking about this, I've started from the following essential points:
> 
> * We are the Etherboot Project.
> 
> * We create Free network booting code, and have done so for over 10 years.
> 
> * Our products include Etherboot (a network bootloader), mknbi (an image 
> creator), and rom-o-matic (a web-based interface for making ROM images).
> 
> A key insight that this reveals is:
> 
>     The fact that one of our products has the same name as our project
>     does not limit us to a single product!
> 
> For example, in the same way that the Mozilla project now has several 
> readily-identifiable products, each with its own purpose and name, the 
> Etherboot project can have more than one product, each of which does 
> something useful. Further, each one can have a name that separately 
> identifies it or what it does. This is a model that already exists and 
> is accepted in the larger Free Software community that we occupy.
> 
> __What Does This Mean?__
> As I mentioned above, the code base (product) called Etherboot has 
> evolved and grown over time, such that it now incorporates many 
> different capabilities. It is also, therefore, difficult to maintain. 
> Its richness of features can also make Etherboot difficult for people 
> new to the project to understand, configure, and deploy.
> 
> At the same time that Etherboot has been evolving and growing, PXE 
> support has become a de-facto standard for commodity i386 hardware. With 
> our newest release, Etherboot has a significant amount of support for 
> PXE, but it is bundled with many other features. People who need PXE 
> support often do not need a lot of the other features that Etherboot can 
> provide (and possibly vice versa).  This is true, even if the PXE code 
> within Etherboot leverages a lot of Etherboot code that non-PXE features 
> also use.
> 
> I think it's time we create a new product. Let's call it gPXE.
> 
> gPXE will be a GPL'ed version of PXE.  Core objectives for gPXE will 
> include a high level of interoperability with existing PXE bootloaders 
> and implementations, and reasonable compliance with the PXE specification.
> 
> gPXE will be a product of the Etherboot project, and generated from the 
> same code base (tree) as Etherboot, but will use a different 
> configuration file, and possibly a different binary directory from 
> Etherboot, to make it easier to configure and collect binary output.
> 
> __Why should we do this?__
> 
> Reason 1 -- We appeal to a wider audience
> 
> Let's face the fact that PXE compliance is something that most people 
> have come to expect from a network bootloader, and beyond that, they 
> require interoperability with existing PXE infrastructure.  They also 
> reasonably expect that if something works with their Intel or 3COM PXE 
> cards, it will work with gPXE.
> 
> SAMBA comes to mind as an example of interoperability that benefits lots 
> of people.  I'd like to see gPXE offer a similar high level of 
> compatibility.
> 
> Reason 2 -- We avoid confusion and create a new product identity
> 
> Etherboot has a wide reputation for being "not PXE".  This has 
> dramatically changed recently -- we are now working diligently to be 
> compliant with the PXE specification, and to be interoperable with other 
> PXE infrastructure and workflows.
> 
> But, because there's so much existing information about Etherboot that 
> says we don't do PXE, we need to create a name that counters the 
> perception that we are only grudgingly implementing PXE support. Without 
> that, people wanting a Free PXE implementation might not discover that 
> Etherboot supports PXE, or might assume that Etherboot PXE support is 
> "chancy".
> 
> Naming one of our products gPXE will help do that, and will make it 
> unequivocally clear that we are creating a Free PXE compliant network 
> bootloader.
> 
> Reason 3 -- We preserve our existing code base
> 
> Etherboot can continue to exist as our "Mozilla". There are people who 
> wish to use it, and there are people willing to maintain it, if it is 
> reasonably easy to do so. Improvement to a unified code base will 
> benefit both products, if we take some care.
> 
> This will allow us to keep legacy Etherboot features functional even as 
> we focus on new development.
> 
> Reason 4 -- We have a lot of the code we need
> 
> We already have a lot of the code necessary to do gPXE.  We are making 
> the necessary changes to the build system to support more generalized 
> builds from the code base.  There don't currently appear to be any 
> insurmountable technical obstacles to making this work.
> 
> Reason 5 -- We build and expand our community
> 
> By welcoming in people who need a PXE compliant network bootloader, we 
> expand our user and developer communities, and increase interest in and 
> respect for Free Software.
> 
> Reason 6 -- It's an interesting technical challenge
> 
> I have confidence that we can do this, but it is by no means an easy 
> task.  As developers we will need to learn new tools and techniques to 
> make this work.  We may face some tough technical challenges, but I 
> believe we can overcome them.  We will need testers and people willing 
> to write documentation of new procedures. It will be fun to figure this 
> all out, and to create something Free and useful.
> 
> ================
> 
> So there it is, the beginnings of a plan to generalize the Etherboot 
> Project to produce another product, gPXE, from our existing code base.  
> A way to preserve the old, while working on the new.  A way to expand 
> our user and developer communities by creating a product that appeals to 
> a wider audience, and using a name that is unambiguous about what we are 
> trying to accomplish. At the same time Etherboot -- both the project and 
> the existing product -- lives on with equal vigor.
> 
> I think we can do this, and more importantly, I think we _should_ do this.
> 
> What do you think?
> 
> Marty
> 

-- 
Paolo Salvan
_______________________________
X v i s i o n
Via Vigonovese 123A
35127 - Padova - Italy
+39 049 8709427 tel
+39 049 8709426 fax
www.xvision.it


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20