Re: Some thoughts on e-smith's Purpose and Architecture

Dub Dublin wrote:

> I'm going to take a shot at identifying a few things that we all agree 
> on (or at least that I think we *should* agree on), and one or two 
> that are not so consensual.
>
> 1. E-smith is a *server* distribution
> No X, dev tools, etc. in the default distro, nor should there be.  One 
> thing that has attracted many of us to e-smith as opposed to other 
> distros is its server focus and the simple fact that it is *not* a 
> developer distro.  As we pick up the mantle of developers, it's 
> important to keep that in mind.
>
> 2. E-Smith is consistent and *easy-to-use*
> Kind of like the above, it's important to remember what e-smith is 
> supposed to be all about - the easiest, fastest, and most robust and 
> reliable way to build a modern server.  One thing that is VITAL to 
> putting this feature back on track is an open replacement for the 
> blades function that Mitel promised to open up to third party 
> developers, but never did.  With Contribs.org beginning to look like 
> the rallying point for the community, I would like to suggest the 
> following as the first major upgrade in e-smith functionality:  
> Implement something that works just about like the blades mechanism to 
> present the user of a particular e-smith 6.x version with an option to 
> automagically download, install, and configure with sane defaults some 
> of the more popular packages.  (In a nutshell, this new "panel" would 
> connect to contribs.org, see what's available for the local version 
> and architecture, and provide "single-click" installs for things like 
> ClamAV, say, or maybe POPfile or SpamAssassin.)  A large part of the 
> value of e-smith is it's utility out-of-the-box and its ease of use.  
> Personally, the biggest reasons I (and I'm sure others) use E-smith 
> are because 1) it's way easier than setting up all those services on 
> any other distro, and 2) it just flat works.  Let's not blow that, 
> whatever we do...
>

----------

I Love NetBSD and FreeBSD for particular applications, e.g I run a lot 
of Cobalt gear ported to NetBSD 1.6.1.

However porting ESmith to OpenBSD or ANY BSD is just lunacy, you have no 
idea how migrating a generic Linux RPM based system to a juvenile and 
very new Pots package system would be. It would take you two years with 
four full time people to do it.

Reality.... Step inside and enjoy some sunshine

--
Please report bugs to [email protected]
Please mail [email protected] (only) to discuss security issues
Support for registered customers and partners to [email protected]
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org