SEUL: Various thoughts

[amjh@qns.com (Arnold Hennig)]

Because of VERY tight limits on available time, I will probably not post
more than about once a week, but remain very interested in this project
and its success nevertheless.

A note FWIW: a lot of comments attributed to me were in fact the comments
- reactions of others to my original posting. No big deal, but it makes it
difficult for people to form a concept of the way the other individuals on
the list think if their comments are incorrectly ascribed.

ON WHO THE SEUL END USER IS: (Complete Idiot vs. Technically capable)

I saw in an article recently that Donald Knuth (Art of Computing) said
that if you write in a way that is intended for the non-technical people
to easily understand, the non-technical people will not understand, but
the technical people will find it easy to understand, while if you write
for the technical people, they will fiind it difficult to understand.

My conclusion and suggestion: We should aim at making SEUL easy for any
person with reasonable intelligence to install with good results, so that
those with technical expertise may find it easy to do.

ON PACKAGING SYSTEMS:

I have a RedHat installation running on my home computer, with which I am
happy, HOWEVER

I have only been able to use the rpm that came with the disk with the
files that came on the disk. I have not been able to convince it to work
with any rpm files I have downloaded from any other source. I tried
installing the only version of rpm that I found distributed in a form
other than rpm on another computer that I wanted to use these rpm files
for and it continually complained about reference files that did not exist
since no packages had yet been installed. I wanted to try the new rpm
compatible PKG tool that was recently announced, but it's only posted in
rpm format, so I didn't bother to download it. In short PLEASE don't use a
format that is not universal. 

The older (5 yrs or so) slackware distribution that I still have on
floppies uses standard gzipped tar files, which can be manipulated either
with their pkgtool or with tar, and since there are some files in those
packages that I continue to use, this has been very helpful.  

ON INSTALLATION MEDIA:

Another thing, I know that installing from thirty floppies is time
consuming, but it does NOT require previously existing network connections
to work. Of course CDROM should be the medium of choice, but it should be
designed in such a way as to allow floppy installations. (I still have
this crazy idea that some folks who can't afford the hardware to run
Win95 et al, can still have as good a system on humbler hardware by going
to Linux, and I am in fact currently installing Linux on such a machine.)

ON THE INSTALLER AND INSTALLATION:

Re the comment on the size of a script complex enough to be really fault
tolerant: I would think you could cut the size of it down tremendously by
making it a compiled program. Our target user is not likely to want to try
to tweak it, although the use of config files should make this a doable
option, too.

The problem of trying to reduce the size of an existing partition is an
important one though. I have used fips twice, once sucessfully and once
unsuccessfully. The successful try was on a Win95 system. The unsuccessful
try was an odd case, though; it made DOS believe that the partition was
reduced in size, but not fdisk. I believe that the cause of the problem
was not the filesystem, but the overlay software that had been installed.
Even when I went ahead and deleted the partition altogether I still had
problems with that disk.

Along the same vein, most of the new computers with Win95 installed come
with a "Rescue Disk". Don't be fooled. This does not rescue your system,
it merely reinstalls what came preinstalled, and that on an all or nothing
basis. It comes down to the fact that the end user has to be aware that
although there is an 85% (or whatever) probability that he can keep all
his Win95 files and install Linux on the disk, too, it can not be
guaranteed, and he should DEFINITELY back up files he would be loathe to
do without before proceeding.

ON UI CHOICES:

I have rethought this one. I'm not so sure that a Windows (or Mac or
anything else) lookalike is really desireable, for two reasons:

1) I (for one) have always been of the opinion that Windows is a Unix
wannabee, let's not reverse that at this date!

2) If you're installing Linux, you obviously intend to use Unix anyway,
why not select a good, typical Unix interface, and tweak the
configurations so as to produce the most intuitive and easy to use version
possible?

If the interface is well designed, it won't matter whether it copies
another interface or not.


ON SOFTWARE TO BE INCLUDED IN THE DISTRIBUTION:

Herein lies a real problem: 90% of the businesses with which we (a small
translation agency) do business use MS-WORD, and accordingly it is the
file format of choice for delivering finished work. Since MS-WORD doesn't
automatically come with the Win Package and is an additional expense, I'm
assuming that only 60% of home users use it, and that 90% of the remainder
use MS-WORKS, which does come with the package.

     People like to share files! 
     And they generally don't think of ASCII files as a viable medium.

Now, it's not necessary to run MSWORD or WORKS on Linux, but unless the
"End user" can easily share his files with his brother-in-law, etc., he's
not going to be happy. To the best of my knowledge, there is not currently
a good way of dealing with this. Correct me if I'm wrong, and please point
me to it.

Also note that Applixware and WordPerfect are not free, and cannot be
considered for inclusion in the distribution.


ON REMOTE ADMINISTRATION:

Committing volunteer labor to an undefined and probably VERY LARGE
amount of long term tech support is a bad idea.

On the other hand, making remote administration by a friend, family
member, or hired tech support person possible is probably a very good
idea. 

For most private users, security is not going to be the kind of concern
that it is for businesses, so allowing a root login by default is probably
practical (include adequate notation about this and how to disable it in
the accompanying documentation, of course!).

I would suggest mgetty, set by the installer to monitor the ttySx that the
modem is on, but would make note of a couple of potential problems that have
to be anticipated:

While mgetty and minicom get along splendidly, mgetty and PPP do not. I
have dealt with this by having two versions of inittab, inittab.dialin and
inittab.ppp. The only difference is that in the ppp version the mgetty
entry is commented out. My PPP script copies inittab.ppp to inittab and
then does  kill -HUP 1  before proceeding with the rest of the ppp
sequence, and my disconnect script reverses the same process.

A lot of users will NOT have a dedicated phone line for their computer, so
may want to modify this a bit to only install the dialin capability when
they want their computer to answer the phone.



                                         Arnold M.J. Hennig
          -------------------------------------------------
          P.O. Box 82251                       amjh@qns.com
          Oklahoma City                 TEL: (405) 634-2025
          OK 73148  USA                 FAX: (405) 634-2060
          
----------------------------------------------------------------------------
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.
----------------------------------------------------------------------------