[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some ideas quickly jotted down



On Wed, 2003-12-03 at 07:08, Fabian Fagerholm wrote:
> Hi,

G'Day from down under!

> I trying to unload all my thoughts about the Enterprise Debian project.
> I don't have time to participate actively in the discussion on
> debian-devel, but I'm following it as much as I can since I'm very
> interested in the directions of this project.

:)

I find too that my mind can race sometimes - it can be inspiring if I
can keep it at a manageable pace so I _can_ get it down, and it can be
almost depressing if I can't control it, and I feel as though I've
missed a lot...

> I made a quick and very incomplete drawing of what I have in my mind.

Way cool! Great stuff indeed - you were inspired :)

> I'm attaching it as a PDF. Despite it being somewhat naive in many
> respects, I think it already shows some important things, such as how
> things could fit together and some of the pieces that make up the whole
> thing.

It definitely does.

Perhaps "The Core" should become Enterprise-Debian.org (or
[gn]UserLinux.com, or whatever it eventually becomes).

Next, I don't know how easy it is, but color coding would be nice - the
reason is actually technical, since the next layer around the core is
currently Security, Auth, Networking, Storage. You see I think that
"GNU/Linux Operating System" should be there. So we could color code
that layer, and then have a legend/key to say that "orange" means
GNU/Linux operating system or something.

Perhaps more free-form layers (or for some of them) - eg. for this layer
immediately above the core, we could do away with the bars and just have
the circle, with different aspects within it - with [Debian] GNU/Linux
at the top (all of it inside) the circle, and then security/
authentication/ networking, etc cascading around inside the rest of the
circle.

There are almost two perpendicular aspects - organisational (the core
community organisation, service providers, umbrella service organisation
(as per Bruce Perens' paper - which I'm in the middle of reading right
now too)) and technical (GNU/Linux operating system, middle tier
services, "end user" applications and web services).

So perhaps this top circular diagram should be two - one for
organisational and one for technical... ?

Just as it is is an inspiring start though.

Is it easy to create a jpeg of that first circle, so it is easy for
people to view straight off the web page? (I'll put the PDF there too,
naturally.)

I'm thinking that the circles should perhaps be more free form (or just
one or two bars to give the diagram structure - perhaps coloration would
make bars unnecessary?) - since I don't think the existing layers
exactly correlate where the bars are.

Here is a question: custom debian distributions (aka internal projects,
subprojects, metadistros, etc) have so far been named debian-PROJECT.

This is the convention I have followed so far. But this diagram has
Enterprise Debian as its name. So which should we go with. If the
mailing list will be called debian-enterprise, the website
debian-enterprise, then perhaps the name should be also. But perhaps we
can buck the trend and go with the reverse. Thoughts?

> While drawing I came up with the following:
> 
> Enterprise Debian is actually not one singular thing. An enterprise
> needs many different things: back-end servers that run things like
> databases and authentication services, front-end servers that run things
> like web servers, file servers and print servers, terminals and
> workstations used by the people who work in the company. The key point
> of Enterprise Debian is that some choices must be made for the
> administrators:
> 
>       * How does one begin installing Enterprise Debian?
>       * What parts does the system include? What parts require separate
>         hardware?
>       * How is security integrated?
>       * How do you extend the system? When installing a new file server,
>         how does the administrator connect it to the rest of the system
>         in terms of authentication, storage, security and maintenance?
>       * and so on...
> 
> Really, the main difference between Debian and Enterprise Debian should
> not be the set of packages provided, but the fact that there is a
> special, pre-defined procedure of how to do things. The packages and
> custom installer will be there to implement some parts of the
> procedures.
> 
> I must stress this: Enterprise Debian is an excellent example of a
> Debian _flavor_. I would like to phrase it in the following way:
> 
> Debian is the super-project.
>         Enterprise Debian is a Debian Subproject
>         that makes special flavors of Debian.
> 
> I think I'll post something about that on d-devel.

This is exactly the concept being discussed at the moment on -devel. We
have pretty well come to the conclusion that the terms flavour,
metadistro, subproject and internal project, will essentially be
subsumed by Custom Debian Distribution. Search -devel for discussion on
this.

Also, I'm going to combine some more stuff in a talk by Andreas Tille
onto the CustomDebian wiki - I will announce on -devel when I'm done.

> The great difficulty will be to offer several different sets of
> pre-defined procedures. This is required because Enterprise Debian might

I think you are over-estimating the difficulty. FAI-bootCD (again, if
you search -devel threads discussing FAI) and the debix/knoppix type
projects - as well as debian-enterprise and other subprojects are all in
alignment with their technical needs in this regard. There might be some
volume (eg. that last 10% of packages not yet supporting debconf, but
perhaps enterprise debian can be defined to exclude all packages not
debconf'ed, except for those we need as part of a DE release, which we
supply patches for. or something.) of work, but certainly not the end of
the world.

> be introduced as a gradual upgrade from another system. So, for example,
> Enterprise Debian must let the system administrator choose a suitable
> authentication scheme that can be integrated with an existing
> authentication framework.

Well, at the end of the day, it will be whatever the end users
(companies etc) need and/ or pay for in some way (someone's time may be
the payment).

> As you notice, I'm talking in quite broad terms here. But you could
> easily translate the stuff in my picture to package names that could be
> included in the horizon of Enterprise Debian. slapd, libpam-ldap and
> samba, anyone? Or cyrus21-imapd, saslauthd and slapd? And slapd and
> postfix? Etc. The reason I don't get more specific is that I have to
> sleep, and this is just an unstructured dump of my thoughts after having
> read the thread on debian-devel and made the drawing.

:)  You're of course welcome to your on-topic thought dump.

> There are many unexplained things in the drawing. The segmented
> concentric circles represent, from the center outwards, the core (as it
> says), the common subsystems, optional application and software
> services, and supporting features of the Enterprise Debian project.
> Also, the drawing is quite arbitrary, and it's only my personal view.
> Perhaps someone else will share it.
>
> The drawing could use more work, and I'd like some feedback on its
> contents. It is my belief that if people would work on the drawing, we
> could gradually approach more and more concrete actions to be taken,

Or vice versa. As many approaches as there are people at the end of the
day. At the moment these threads serve as a great collation point for
this discussion.

> such as selecting a group of packages and defining clear goals. Working
> in this way would also make it easy to explain the motivation and
> structure of an Enterprise Debian system to a sysadmin, a management
> person, or a user. Writing lots of words about this is unavoidable, but
> I think a structural drawing must be agreed upon if a project such as

A great contribution, and there may be alternative conceptual diagrams
that also apply. We should keep an open mind rather than getting
dogmatic about it...

> Enterprise Debian is to succeed. The effort of cleanly integrating all
> components requires all minds to see the same map, so to speak. It would
> also make it easy for developers to point at the map and say "I want to
> work at this part", instead of having to deal with scattered resources
> such as the BTS or a Wiki to gain an overview of what the goal is.

Good points. I do agree - I diagram is a great way to get a quick
overview of a project. Your inspiration in creating it is very much
appreciated.

> Ok, now I must sleep. Thanks for your time. :)

Sleep .. bah, who needs sleep (well, you could be right - in fact... oh
hang on, I just woke up. Oh well, I get some more sleep one day. :)

regards
zen

-- 
Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/
* Homepage: http://soulsound.net/     * PGP Key: http://soulsound.net/zen.asc
* Please respect the confidentiality of this email as sensibly warranted.



Reply to: