[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Development methods and standing decisions
> 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
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
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
> 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
> 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
> 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
> whee, that was fun.
Oooh, my fingers are hurting... :-)
Erik Walthinsen <firstname.lastname@example.org> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user