SEUL: Migration, and a brief recap

[William T Wilson <fluffy@benatar.dunadan.com>]

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:

1) Commitments from interested parties as to exactly what they want to
work on, what experience they have in the area, what relevant skills they
have (programming languages?), how much time they plan to spend, and what
their priorities are.  Then people need to be assigned to appropriate
projects.  Otherwise, we'll have the same results as now (everyone
talking, no one doing, no one really knowing what they are supposed to
do).

We have to let those of us who are interested join the specific lists,
BTW.  :)  I tried to sign up for some but got rejected.

I believe that the lists should be for specifics.  Like, do we use ncurses
4.1 or ncurses 2 like redhat.  I couldn't compile Sendmail 8.9.3, does
anyone know how?  Things like that.  Not until then should we split
everything up.

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
(some can be concurrent, for example, apps doesn't have to wait for PnP
but it does have to wait for the shell) otherwise things will end up
getting redone.

Some of this is already happening.  The list of apps, for example, is
filling out nicely.

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?

We also need to decide what capabilities are essentials.  I would presume
that we'll do everything for x86.  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.

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.  Though some of us do greatly prefer the text-based
interface, less than 1% of the end-user clueless market agree. Besides,
we'll be taking mostly windows converts - they'll be used to graphics, and
text-based things seem like DOS = seem less powerful.

2) We'll be using RedHat's package manager.  Again, some of us prefer
debian.  However, it seems most of us have more experience with the RPM
flavor.  I don't believe that there's much difference between the two...
dpkg used to be much superior to RPM, but these days I doubt there's much
capability difference.

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.  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.  :)

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

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

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. 

3.3) It must have some useful autodetection.  I don't know how RedHat 5's
X-win setup goes, but it used to require people to know things like what
sort of mouse they have.  (Why doesn't the install ever look at the dmesg
log to see what the kernel says on the subject?)  Is this vaunted
autodection any use?  :) 

3.4) It would be nice to work off a single floppy.  Since we shouldn't
have to stuff into 4MB of RAM, then we can use ramdisks liberally.  Let's
not worry about it too much though- I don't think even the most clueless
newbie will have a problem switching disks.  :) 

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.  You could install one of those on a
system which was 100% FAT-based.  Without ever touching the partition
table OR a network.  Put that in RedHat's pipe and smoke it.  :)  The fact
that Slackware's packages would install off of an 8.3 FAT partition was
very useful. 

3.6) There has to be Plug & Play, and it has to work.  I would suggest
compiling (if there isn't one already - I avoid PNP devices like the
plague) a database of PnP devices.  Maybe we can loot M$ for this like
with the monitor list. :) 

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

whee, that was fun.