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...
3. E-smith is flexible
Although (IMO) e-smith needs more work here, it's still very good. I would like to see a bit more in the way of high-level abstractions for various functional services. E-smith users don't (and with few exceptions shouldn't) care about, say, what particular package sends or delivers mail. They should, however, be able to turn mail services on or off on an e-smith server with a single click. I personally would like to see the concept of local/remote and hierarchy embedded in the e-smith configuration. For instance, it would be really nice to build one-click configurations for "Corporate" servers (DNS master, a mail master, and a domain master, etc.) and "Remote Office Server" (DNS subzone (maybe) and secondary for DNS master, mail secondary, and domain secondary). I think this flexibilty is ulitmately tied to doing the blade sorts of things well - In cases where users just want a firewall, install e-smith, and uncheck everything but firewall/gateway in a config panel. Need a file server only? Just check the "File Server" box to enable Samba. Ultimately, it would be nice for that master/slave setup to use a designated set of LDAP masters and slaves to manage multiple servers and sites as a resonably coherent whole. (Yes, I know how hard that is, I did it at Chevron over 10 years ago. We did it then with YP, bind, and hesiod, and there's much more and better stuff to work with today.)
4. E-Smith should *not* try to include all functionality and applications
Gee, Im starting to sound like a broken record about this blades thing, but this is the key to giving flexibility to all without negatively impacting ease-of-use or cluttering up the distro with a bunch of seldom-used trash. The core e-smith distro should be exactly that, a core. It should *not* inlcude content management systems, groupware platforms, or alternative MTAs or mail handlers. There should be one good, solid default for the major functions, and if others want choices for thier own reasons, make them available through the new whatever-replaces-blades mechanism.
5. E-smith is (or at least should be) secure.
Here's where I may be at odds with many, but I believe that this is actually one of the most important aspects of e-smith. Unfortunately, being based on Red Hat is not exactly conducive to security. There is no doubt that replacing the current Red Hat core is going to be a huge undertaking, no matter what replaces it. Given that changing is a major PITA anyhow, why not take this possibly once-in-a-lifetime opportunity to do it right and go with the only core that is both really secure and as resistant as possible to the sort of core platform trauma we now face: Go OpenBSD. There is no Linux even close to being in the same league for either security or stability - that's no slam on Linux, but a statement of OpenBSD's well-proven excellence in this field. OpenBSD is the ideal platform for a server distro like e-smith, and it addresses a huge problem that they have, too: thier system is technically second-to-none, but it really lacks a friendly and easy-to-use face to make it usable by non-propellerheads. I also think that the BSD license improves the chances of building a vibrant community where commercial and open source parties can work together rather than somewhat at odds as we've seen with e-smith and many other GPL'ed projects. I know e-smith is tightly tied to Linux, but more than that,even, it's tightly tied to one particular Linux flavor - given the difficulties in changing at all, it may be worth looking at a jump to OpenBSD when a jump is indeed warranted. (That's not now, fortunately...) Aside: To be fair, I'm on record as being opposed to the GPL on principle, but that's not the issue here, the issue is what works and what has synergy - I think e-smith and OpenBSD are a great fit for each other, and we should at least seriously weigh an OpenBSD core as an option when the time comes to deal with replacing the Red Hat underpinnings. Note that I am *not* proposing that the e-smith bits be placed under a BSD license - that's probably impossible or at least impractical, although I'd love to see it, somehow...
The most important thing is to not lose the spirit of those things above that have made e-smith uniquely useful among all the distros out there. If we all pitch in to do what we can, we can not only save e-smith, but give it considerably more vitality than it has today. I'm a good system and application architect, but I am *not* a coder (programmers look at my code and supress a shudder, when they can avoid verbalizing something like "yick..." :-) ) I'd be happy to contribute in other ways, though, including possibly coordinating documentation, which I think is in need of some cleaning up and freshening.
Finally, despite my harsh words now and then over the years, I'd like to extend a thank-you to the crew at Mitel and E-smith for thier support and hard work over the years. Well done, guys, you're leaving things better than you found them...
Dub
-- 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
