[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Distributions
------------------------------------------------------------------
First Topic:
There has been a lot of discussion about, among other things, whether
to use an existing distribution or to create a new one. Although I
must admit that I considered making a new distribution (about the time
that redhat 3.0.3 came out, and debian was releasing 1.2, I think), I
stuck it out with redhat and have been fairly pleased (never caught on
to Debian, but I to have heard good things).
Along with this thread of discussion is what to offer the user
installing it, i.e. Minimal/Typical/Complete/Custom.
After looking at the RedHat's installation (4.x) for about the 17th
time, it already does this to a certain extent. For example, the user
can choose to install package-sets such as "C/C++ Development Tools,"
etc, _or_ select individual packages. Even then, they are broken down
into the categories that all RPM's are (supposed) to be parts of:
Applications X11
Communications XFree86
Editors Applications
Mail Games
Publishing Utilities
... ...
Utilities Networking
Archiving Admin
Printing Daemons
... ...
Documentation Development
Shells Libraries
Games Languages
...
However, the present RedHat installation isn't ready for linux-unaware
end-users.
>>>>> "Luka" == Luka (Peter) <luka@mit.edu> writes:
Luka> c. installer robustness can also be considered here.
Luka> failure due to a keypress between stages should just _not happen_.
Luka> seul is not ready for distribution yet if it does.
Luka> also, i believe the installer (internally) should run in 2 stages.
Luka> it should first ask all questions, and verify that the install will
Luka> probably succeed (not run out of disk space, etc) as much as
Luka> possible, and _then_ run the entire install at once. is there any
Luka> good reason that current distributions do not do this?
Luka> i am assuming it was just a convenience for the programmers, so
Luka> let me know if i'm wrong.
If you think about it, though, the RedHat installation setup is based
on two scripts: the first of which (stage 1 is on the first disk, and
the second is on the second disk and on the installation media
(i.e. cdrom or installation directory via NFS, etc.). (I will admit,
though, that RedHat's 2-stage installation doesn't follow luka's idea
that the 2nd stage does the installation and the 1st stage does the
prompting.
So, with this in mind, let's think about it a second -- RedHat has its
source freely available, and the installation programs are easy to
find and (*gasp*) replace as needed.
Luka> d. what distribution to use? create our own?
Luka> this decision influences how painful the other steps will be for
Luka> us. using an existing distribution gives us a large base to work
Luka> from, but it traps us into sticking to the structure of that
Luka> distribution, and keeping up with any changes they make, as mentioned
Luka> by others on this list.
Luka> i suggest creating a new distribution, because the startup benefits
Luka> are not worth the problems caused in the long run. however, if
Luka> possible, we can start off from an existing distribution that is
Luka> close to what we want. i have not tried debian, but am hearing
Luka> good things about it, so i will try it out today or tommorrow.
Luka> if it's fully gpl, then we should be able to just take what they
Luka> have, and start changing it, if we decide it is easier than coding
Luka> from scratch. then we should distribute our modified version
Luka> as seul, just so we are not restricted by decisions made by the
Luka> debian team.
Would it be feasible to retain the entire distribution and just plug
in an installation program specific to SEUL?
RedHat already uses a compressed root disk, etc, and has (AFAIK) had
good luck with doing things that way. (Note: I am being fairly
RedHat-centric, I know that. This is because I'm a little more
familiar with it. Without checking it out, I'm sure that Debian would
be as easy to work with.)
Another thing this could enable for us: RedHat already installs via
CD/partition/NFS/FTP. The newest version (4.2) is supposed to install
via PLIP (not necessarily pertinent to SEUL) and SMB-shared volumes.
This in fact is helpful to those users who are networked (*somehow*)
yet don't have a cdrom on the linux-to-be system or an NFS/FTP server
to work with.
------------------------------------------------------------------
New Topic: (brace yourselves ... no whiplash intended)
One suggestion I caught a whiff of was:
Luka> if anything goes wrong, it should do something
Luka> incredibly new and innovative: save the install config so far!
I must admit that this may be a problem with a boot/root system that
loads things read-only ... perhaps, if necessary, it could be the last
thing before rebooting the system (perhaps after a failed
installation), and it could write it to a few free blocks reserved for
this on the root floppy. As an alternative, have the user provide a
pre-formatted disk (dos formatted, that is) and save it in an
arbitrary file, so that (1) if need be, it can be copied for
archiving, and (2) if it is written in human-readable format, perhaps
it could be altered (albeit by somebody who knows a little) for
automated installations. This way, once the boot disk has loaded, it
can optionally be given a configuration file and bypass asking any
questions and start installing right away.
------------------------------------------------------------------
Connection with the first topic: (again, brace yourselves)
With the 2-stage installation, perhaps the 1st stage would by default
create this configuration file (whether a real or temporary file) and
the 2nd stage just uses this to install everything else.
This could very well be a viable option whether we go with an existing
distribution or not. It's a "clean" solution and offers some
flexibility not necessarily offered by monolithic installation
implementations (that was hard to type, much less say ;-).
This would require that a couple of design issues be met:
(1) format of the configuration file (shouldn't be too hard ... just
brute force figuring out the basics needed to be saved in this
state); and
(2) creating programs that can create and parse this file (trivial if
kept simple).
Development using this paradigm would be simplified, too, as you can
fake an installation through stage 1 without even having to boot to a
floppy, etc. Output the configuration file, test it to make it is
complete to the user's specifications, and tweak. Somebody else,
meanwhile, could be working on a 2nd stage that takes the
configuration file and just starts installing (this, too, doesn't have
to be done from a dedicated boot-up system -- just one that has access
to a large enough target filesystem).
Comments?
-wfe
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
William Evans < wfe01 @ gnofn . org >
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------