Re: Plan of action for dev-install

[jfm2@club-internet.fr]

> 
> 
> 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 me once the software is on disk and the user can fly with his own
wings my job is ended.  But to me that means with X and a link to help.

> > 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?
>  

A local news spool.  Online reading is too expensive here in Europe.

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

An X install is too risky: there are chances it will not work and at
this point of install the means for investigating aan X failure are
poor.   I am for a character mode install even if that is ugly.

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

That idea is present in many distributions.

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

No.  You were right.  INITRD is an additional point of failure.  But
notice than usual practice for someone prudent given the hazards in
kernel recompiling or LILO is to have two kernels: the original one
and the one he has optimized.

I propose we install a superlean kernel using INITRD as a production
kernel and a recovery kernel with IDE and SCSI drivers, plus essential
filesystems but only basic networking for recovery in case something
bad happens to /lib/modules or /boot/initrd.

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

I want to dispel the folklore about real men recompiling their
kernels.  That is the reason I want than ours be so good than the user
gets only negligible benefits in doing it.

But in case he needs a driver we don't provide or he upgrades I have
ideas for making this easier.  

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

In fact what I want is than users afraid of partitionning or wanting
just give a try will be avle to do it with loopback files.  Ie all the
distrib goes into these files.

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

Integration is the strongest point in Debian.  This is for them.

> > 
> > 
> > 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?
> 

Automatically but based on resubmitting batch jobs and with a boot
time check in case some job needs to be resubmitted.

> > 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 meant when INN is configured correctly but it is not handling news
to UUCP or not sending them when PPP is on.

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

Six months after realease the install software should be pointing at
trying to get a new version if card is not supported so they will find
about Suse.

-- 
			Jean Francois Martinez

==================== The Linux.  Use the Linux, Luke! =======================

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