SEUL: Development methods and standing decisions

[Erik Walthinsen <omega@omegacs.net>]

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

To that end, I would like to get someone to volunteer to write a mysql 
database and ePerl front-end (I can do the front-end if given appropriate 
perl/sql code) to keep track of everyone working on the project, with the 
above information.  This has been planned for quite a while, but no one yet 
has had time to do it.  As arma and I are both swamped, we need people to 
help out with the construction of the remaining developer services.


> 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.
Which one?  There's only one closed list, seul-seg, and that's closed for a 
reason.  I don't know if we have that written up, but if not, here's the 
basic idea:

1) a development group has a question or set of questions
2) these questions are written up into a questionnaire and sent to Aldo
3) Aldo sends this questionnaire to the SEG list, and waits for discussion
   and official replies to come in
4) the replies, comments, etc, are tabulated and returned to the dev group

The idea is that we now have our own unpolluted focus group, populated with 
end-users of various types (mostly scientific for now, because of recruiting 
channels).  It is important that this list be closed so the development group 
does not interfere with the discussions of what end-users want.

The entire list is archived on the web site, so progress can be monitored, 
though this may be a little tedious.  If there is sufficient interest, a 
secondary list can be created with open subscription, and this list can be 
subscribed to the SEG list, as a one-way gateway for developers to listen in 
to, if they are curious.

> 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.
That's why I decided to try to split the discussions now.  Many of them are 
moving in towards the more specific decisions that need to be made.  The more 
generic decisions (as you have pointed out below) have solidified enough that 
they can be assumed for now (even if they change later).  We can (and 
should!) start thinking about details.

It's somewhat disconcerting to hear some people say we are not moving fast 
enough, it's all talk, and others saying that we need to hold off on 
discussing the details.  It makes it difficult for me to know which way I 
should be moving.  The problem comes when I chose one direction, and half the 
group squawks.

> 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.
Yup.  That's what I want to get started doing as fast as possible as soon as 
we are split up and organized properly.  As stated, my goal for this is the 
end of January, 1998.

> Some of this is already happening.  The list of apps, for example, is
> filling out nicely.
And we have a maintainer, and soon it should be on the web and being actively 
kept up, with comments, links, etc.

> 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?
I'm thinking along these lines:

Minimum		Recommended Min		Recommended		Max.... :)

486/33		Pentium/66		Pentium/133		PII/300
8MB RAM		16MB			32MB			etc...
500MB disk	840MB			1.2GB
VGA		SVGA			Accel SVGA
CD-ROM drive	CD-ROM drive		CD-ROM drive

The requirement of a CD-ROM drive should be obvious to anyone who's ever 
installed RedHat or Debian, and very painfully obvious to anyone who's had to 
install a full Slackware system from the floppies. <eg>

> We also need to decide what capabilities are essentials.  I would presume
> that we'll do everything for x86.
Likely, though this is another area where we can leverage (whoop!, whoop!, 
manager-speak!) what RedHat has been doing.

> Will we be concerned with security?
Not as much as we could be, but it will be something to keep in mind.

> 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?
Depending on what is decided relative to Linnet and e-Linux, networking 
services may be mostly ignored, such that it would take as much as it does 
today to configure them.  It also may be that Linnet, e-Linux and SEUL all 
co-develop the appropriate configuration systems, etc., such that the same 
environment can be used for both SEUL's user-land stuff and Linnet's 
daemon-land stuff, in which case we can provide everything in one package if 
we want.

> 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.
Precisely.  Some things are needed for office interoperability, like samba, 
and some thing are just plain cool to have for *anyone*, like apache. 


> A brief recap so far, of what we HAVE decided.
Sorely needed, I assure you.  Barring further major complaints, I intent do 
write most (if not all) of these down in a web page and make it "official".  
That's not to say they can't change: it's something to go on and develop 
relative to for now, possibly for the duration of the project.

> 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.
Very well put.

> 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.
Yup.  RPM has several things going for it: wide acceptance (read: almost a
dozen architectures are using it, check www.solaris.rpm.org if you wanna see
how "wide" I mean), many many existing packages, many spec-file gurus, active 
development, several decent frontends, a book(!), etc.

I would still be interested in a detailed technical white-paper showing the 
differences between dpkg and rpm from the developer/packager viewpoint.  What 
we don't need is more discussion over which is easier to use, as either way 
it will be a completely moot point once we have an installer and management 
tool in place.

> 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.  :)
Agree.  As I mentioned above (or maybe in another message, I forget), there 
might be some advantages in sticking with RedHat as far as 5.1 or 5.2, just 
to 'leverage' their advances in glibc6 stability (which some consider an 
oxymoron, but oh well).

> 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. 
One way to do it is to head for the CD-ROM drive as soon as the installer 
boots.  This way we can put just about anything we need on there.  In lieu of 
a CD-ROM drive, a reasonably good-looking initial-config networking tool can 
get the machine on to the net enough to start up X.

Because of that, it may not be possible to support any install method that 
requires keeping local copies of stuff.  The only one to do this now is the 
FTP method.  I feel (and others may disagree) that the FTP install method 
will not be utilized by anyone interested in installing SEUL.  Home users 
will have a CD-ROM drive and a slow link.  Office users may not have a CD-ROM 
drive, but will have a fast link and a sysadmin to export the CD-ROM drive 
from some random server.  I just don't see a need in this installer for the 
FTP method, and given its drawbacks, I'd be tempted to ignore it completely.

> 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?  :) 
It is, but IMHO it still isn't done right.  Like you said, the kernel gives 
some of the information, but the real issue are the various cards installed, 
plus printers, scanners, and other random peripherals.  Given carefully 
crafted sequences, most hardware can be probed for.  I was doing it manually 
today, in fact, because I had an ne2k clone at some random, semi-unknown port 
and IRQ, so I just started trying combinations till I got one that worked.  
Why is it that software can't do that for devices that are properly behaved???

> 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.  :) 
Given a decent fast/large media like CD or NFS/SMB, the second floppy won't 
be needed at all, even if we bloat the installer.  There's a lot of room on a 
gzip'd 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.  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. 
UMSDOS has advantages and disadvantages.  Using a loopback filesystem would 
be better, IMO.  Of course, this was discussed months ago on this list, so if 
you want to see the opinions, check the archives.  It would be advantageous 
to be able to do something along those lines, but then we have to decide how 
much work we want to put into something like this, given the percentage of 
users who would make use of it.  That's where SEG comes in handy, and it 
probably should be one of the very first questions seul-dev-distrib sends off 
to Aldo.

> 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. :) 
Paul Anderson is starting a database of monitor specs and modem init strings. 
Is there anything else that should be gathered up in a similar manner?  I 
don't use PnP if I don't have to, so I don't know the architecture, but don't 
the cards have UID's and data files that need to be fed into the software?  
That would be another database that would need to be written in that case.

> 3.7) The distribution has to be 'internet-ready' out of the box.  At least
> as much so as Win95... 
Trivial, given the *wide* range of choices.  The only trick is getting the 
right applications, and making sure they look good, work together, and are 
stable.

> whee, that was fun.
Oooh, my fingers are hurting... :-)

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user