Re: Plan of action for dev-install

[George Bonser <grep@oriole.sbay.org>]

Thinking points only ... not ment to generate contoversy.

On 28 Jan 1998 jfm2@club-internet.fr wrote:

> 1) Delimiting boundaries.
> 
> When the install is ended?

Excellent point. When does mandatory end and optional begin. This must be
decided.

> For many distributions it is when the
> software has been loaded on disk.  IMHO this is not enough.  A Linux
> without a functional X is severely hampered in the applications it can
> run so without X is not completed. 

Do we intend to support a non-desktop configuration? I mean, is a
IP-Masquerading mail/news/router/diald configuration to be an option or
are we aiming solely at the desktop?

> I also consider of the utmost
> importance to allow the user to get help: mail and news must be
> functionnal for the install be considered complete.

Ok, this implies other services ... networking of some sort, ppp is a
likely candidate. You now need a newsreader that works well over a slow
link or a local news spool and method of retrieval. So the question now
becomes the size of the install.  Are we to be CDROM only? Do we install
basic networking and allow FTP install?
 
> That does not
> means than I consider than the dev-install group has to develop tools
> for configuring X or news just than I want than the tool be called as
> part of the installation or automatically at first reboot.

Back to an X-less install.  Will that be a supported configuration? WIll
we have scripted configuration in addition to / instead of GUI
configuration for basic services? If GUI only, to what extent?  How does
the new newt/whiptail interface look compared to the old dialog? Is it
useful to configure BOTH configurations (if we are to have a non-GUI
option).

> 2) Strategic issues: No wild dreams just removing bottlenecks.
> 
> as easy and coherent as a Mac.  So my intention is instead of an
> ambitious installation, who would be very long to develop, simply
> remove some critical bottlenecks.  When applicative software will
> allow Linux use by a wider population then it will be time to design a
> better install.  About bottlenecks a preliminary analysis shows some
> of them: kernel recompilings, partitionning, better
> internationalization, the crontab issue, enabling the user to ask for
> help and some easy improvements to the X configuration.

How about some choices for canned configurations? Examples being:

1) text-based server
2) user desktop
3) network admin desktop
4) software developer
... you get the idea


> 3) Kernel recompiling:
> 
> SCSI use is rare between unexperienced people so most of the optimized
> kernels will for IDE while SCSI users will get fewer choices and
> perhaps will have to content themselves with the universal kernel.  I
> nearly forgot: the user would not have to recompile to get sound
> support.  Sound is necessary for games and no end user system is
> complete without games.

How about a compromise here, support in the kernel the IDE and SCSI
drivers that make a point to provide driver development assistance to the
Linux community.  This would mean cutting out about all but Buslogic SCSI
controller ( now Mylex ) support.  If a user wants trouble-free SCSI
performance, they can get a SCSI controller that supports Linux. In
exchange we tell our users that they have a better chance of good
performance by using these controllers.
 
> About kernel recompilings I think Omega posted the propositions (mail
> me if you want  a repost) I made in another list for a cut down kernel
> recompilation procedure unable to cope with all cases but far simpler
> and less dangerous than the present ones.  That would aim at
> intermediate users.  However this is not part of Install so I just
> submit the idea.

I agree, the users should not be compiling kernels and we should not
encourage them to do so.


> 3) Partitionning.
> 
> At DOS level I want a front end for the preliminary phases so the FIPS
> phase and the Linux booting are fully integrated.
> 
> Another idea than I want to implement if time is available is a
> partitionless install.  No, I don't want to use UMSDOS.  I want we
> create big DOS files and use the loopback interface to access them.
> This should be far more efficient than UMSDOS both in speed (specially
> if the user defrags before) and in disk usage.

Brilliant! I have seen nothing in the docs that suggests that a loop
device file can not be on an MSDOS filesystem. The only drawback that I
can see is that I suspect that file is not needed after you have linux
installed so it detracts from space available for the linux partition
since you need to create that file before you run fibs.  

COMPROMISE: fibs the dos partition, create a linux swap partition. Make a
dos or ext2 filesystem in the swap partition. Use that as the loop device
file on install, once it is loaded you can mkswap that partition to
destroy it and mkfs the linux partition and continue on with the install.

> 
> 
> 4)  Internationalization.
> 
> This does not concern Americans but to us, aliens :-), present
> distribs are not satisfactory.  I want than if the user chooses a
> foreign keyboard then he will not have to type blind at LILO prompt
> (LILO 20 supports national keyboards) and than environment variables
> get set so the user will get error messages in his native language and
> the doc software will be able to know which of the translations to
> install and display.

Uhm, current Debian istall is for international keyboard configuration
right after selecting color or mono screen after booting but yeah, lilo
should be extended for internationalization ... a query in
linux.debian.i18n might be in order here.
 
> 
> 
> 5) Crontabs.
> 
> Many distributions perform cleaning tasks at some time between 00am
> and 04am.  This is only valid for computers powered on 24 hours a day.
> Home users pay the power bills so they power off their computers when
> not using them.  Any scheme based on doing chores at fixed times of
> the day will not work with home users computers.  I think Omega posted
> my propositions for a scheme based on batch (batch only releases jobs
> when the load is low) who would be more adequate for personal users.

I missed that post, would that be done on 1) startup 2) shutdown 3)
demand?

> 6) Networking.
> 
> The installation should not
> let the user with an unconfigured PPP.  Online mail and news reading
> is very expensive in many countries so we have to set up and configure
> mail and news servers for offline reading.  While some distributions
> prompt the user and set up adequate parms, none will set up the PPP
> scripts in a way than mail and news are shipped and fetched
> automatically: the habitual schemes for transfer are based on
> _permanent_ access to the outside world..  I have seen cases where the
> user had configured his software correctly but the failure point was
> the transfer.  This must not happen in SEUL.

This is, I fear, going to be a major sticking point unless we attempt as
far as possible to emulate Win95 for PPP login.  Most ISP's support this.

> 
> I would like to help UUCP users.  In some countries with expensive
> phone rates, and in third world countries UUCP with its high speed is
> much better than PPP (can be the only protocol available in third
> world) for transferring mail and news.  However because few ISPs use
> it, UUCP is useful for few people.  Therefore we will work on UUCP
> only if we are ready before other parts of this project while we wait
> for them.

NOTE: I can provide uucp via TCP for anyone intersted.  Allows you to
quicky connect to the internet, grab your mail and news and hang up no
matter where you are in the world.


> 7)  X setup.
> 
> I want to imitate RedHat who is resorting to automatic hardware
> detection.  Unless there is something better in the interim we would
> use their software (it is GPLed).  I think we have better to do than
> to reinvent the wheel.  There is a thing where we can improve on them:
> people getting only VGA16 (as good as unsupported) will be told why.
> I am tired of seeing posts in news groups of people who have fought
> for days getting only 16 colors, low res and slowness when the problem
> is than their card is not supported.

Look at the S.u.S.E. X servers.  These support more hardware and are being
fed back into the XFree86 project. They will likely always be a step or
two ahead of XFree




George Bonser 
If NT is the answer, you didn't understand the question. (NOTE: Stolen sig)
http://www.debian.org
Debian/GNU Linux ... the maintainable operating system.

===
SEUL-Leaders list, seul-leaders-request@seul.org
===