Re: SEUL: Migration, and a brief recap

[Kai Wetzel <k.wetzel@welfen-netz.com>]

William T Wilson wrote:
> On Tue, 6 Jan 1998, Erik Walthinsen wrote:
> 
> > We now have more than enough to talk about, and seul-project is less and
> > less the best place for much of it.
> 
> Unfortunately, before we can shuffle everything around, we need to get a
> real structure in place.  We need to have:
[...]
> 2) We need to then proceed in an orderly fashion.  First we get the
> building blocks.  Shell, package manager, netkit, kernel, PnP tools,
> X-Windows.  Then we decide what apps we're going to include. We compile
> them and configure them.  Then we decide on an interface.  Then we build
> an installer.  These things have to more or less proceed in this order
> [...] otherwise things will end up getting redone.

Hmm, I think there are quite a lot of things which can be done
in parallel now.  It is important to stay in sync, though, and
that's what management and the seul-project list are good for.

Many things just have to be started.  After that they can
operate in a way which keeps people motivated.

IMHO it's crucial that the lists' findings are shared
frequently, though, and that the leaders keap track of things
as well.
 
> Some of this is already happening.  The list of apps, for example, is
> filling out nicely.

Yes, that was a good idea indeed.  I hope we can continue
on this at fast pace on dev-apps.
 
> 3) We'll need to decide on some system requirements.  :)  I think that
> 500MB disk and 8MB RAM is a reasonable target.  Nobody has 4MB anymore and
> 500MB is about as tight as you can fit a distribution in, I think, and
> have it do something useful.  Maybe we should look for 1GB disk space?

The problem with disk space is that many people will install
SEUL on systems filled up with '95 apps as a secondary OS
at first.  So I'd suggest the following for a rough estimate:

RAM: Required:     8 MB + swap
     Recommended: 16 MB + swap
HD:  Required:     500 MB
     Recommended:  the more the better ;O)
Also: EIDE or SCSI controller, CD-ROM and VGA.

> Will we be concerned with security?
> Will we be concerned with being a functional network server, or will we
> assume that some capabilities like this will be set up by an admin that is
> competent enough to install actual Red Hat?  I think it would be fun to
> have a working httpd server and useful to have a working SAMBA server, but
> stuff like mars_nwe and BIND I would consider completely extraneous.

I'd say a working httpd server should be added when we
don't need the resources to get the most essential
end-user applications and an easy install.
 
> A brief recap so far, of what we HAVE decided.
> 
> 1) Everything at the end-user level has to be 100% graphical except,
> possibly, the install.

If we can figure out to make an "X as sson as possible"
install as a second step, I'd regard this as a big plus.

The text-phase of '95 is IMHO way too long for an ordinary
end user :O)

> Though some of us do greatly prefer the text-based
> interface, less than 1% of the end-user clueless market agree.

Of course we should always allow for a guru to step in
and fix something at the low loevel - IMO much better
then forcing a re-install like '95 or Mac (and such
situation can occur, e.g. an end-user manages to delete
a crucial file: too bad ;)

[...]
> 2) We'll be using RedHat's package manager.

I agree.  IMHO we should stay open for a switch in a later version IF:
debian is easy enough by then AND it's not going to drain too much power
from the SEUL team.

[...]
> We still don't know for sure whether we'll have an up-from-scratch
> distribution, a Redhat-based but not redhat-linked distribution, or a
> distribution that tries to mirror redhat.
> 
> I STRONGLY encourage the second of those three.

I agree on this, too.  We can at any time decide to modify
things as much as we want.  But we'd have something to start
with which will allow concurrently handling other tasks such as
configuration, GUI, app selection, etc.

> Starting with a working
> redhat saves us from having to do the REALLY stupid things like writing
> init scripts but frees us from having to follow RedHat's policy of making
> radical and often premature changes to their system.  WE CANNOT BREAK
> ANYTHING from version to version.  Period.  :)

Of course we're pretty open until we ship 1.0, so we should
take the time to make some mistakes ;O)

> 3) The distribution has to be very easy to install.

Yes =O)  The again, Slackware 2 "installed right out of the box" ;)

> 3.1) It must work for those with no net connection.

Very important IMO.  In this part of the world, phone
calls are so expensive that many people are still not
connected (e.g. I pay 8x as much for phone then for my
ISP - which makes me feal rather sorry for him :(

> 3.2) It must be able to install graphically.  Like Windows, which installs
> the most minimal of graphical shells before proceeding with the full scale
> system, our X setup doesn't have to be fancy.

Is there anything which has to be pre-checked other then
what kind of mouse the user has ?
(and keyboard layout, of course)

[...]
> 3.4) It would be nice to work off a single floppy.

ShouldnÄt be a problem, right ?  X can come from CD if
it doesn't fit, or from a second floppy.

[...]
> 3.5) More importantly, we need a more FLEXIBLE install than redhat.  We
> should take a page out of Slackware 2 and Slackware 3... they could
> install FROM anywhere TO anywhere.

Yeah, I liked this feature because my CD wasn't supported then.

[...]
> 3.7) The distribution has to be 'internet-ready' out of the box.  At least
> as much so as Win95...

Yeah, very important.
[...]
kai