Re: diff between RedHat and us

[JF Martinez <jfm2@club-internet.fr>]

I won't quote the exact Stephan's replies because I don't have access to 
the box.

1) I told about the Unix steep learning curve being unadequate for
   those people who don't benefit of assisted training ie home users
   who are virtually absent of Unix but are present on Linux and are
   important for its future.  Steplan objected thet Gnome solved the
   problem.

My reply:

Slapping a nice GUI is not enough if you don't undestand the real
problems of the Linux isolated user.  To begin with you are assuming X
is working.  If it doesn't work the user is left out abandonned at the
# prompt be it an expert or one who sees an Unix for the first time.

Now RedHat's implementation of this is frail because a seemingly
inocuous action like stopping a font server lefts the user without X.
It si also very easy to have the distribution choosing the wrong one
between gdm, xdm, kdm and this also makes the user being dropped at
the command line.

In Indy I assume the user has to solve problems from ths start so I
made it far more forgiving of user errors (stopping a font server does
not makes you unable to run X, if the user selects a ?dm and then
unistalls it then Indy it is smart enough to find another one).

I also remeber the day I had to tell a guy to reinstall everything not
because I could not tell him how to fix his problem but because /usr
was not being mounted and that meant he had no alternative to VI.  In
Indy I think in people who have to fix problems just minutes after
their first boot so I ensure they have an editor who is reasonably
easy to use (Vim is leagues ahead of plain VI but I am still
unconvinced), and who is placed in /bin so it will ever be available.

I would like to improve upon this by ensuring that a user who has to
connect as root to solve a crisis is not dropped defenseless on the
command line.  The scheme would be  in Python like :

if feature == ACTIVE and user == root and not under_X:
   start_mc
else:
   start_shell


This woulkd require hacking the rootfiles RPM and finding a sensible
scheme for experienced users disabling the feature.

Another difference is in booting: There is nothing I can do if the
problem is realated to LILO but if it is say a broken inittab I ensure
the user knows how to boot by displaying on the LILO screen how to
shoot such problems.  The scheme could be improved by ensuring the
install scripts in lilo's RPMs select the right file so the user gets
troubleshooting info in his native language.

All the preceeding (X robustness, helping the user to troubleshoot
problems) are features Indy has and RedHat hasn't and who are not
solved by just slapping a GUI on a distribution who in every other
aspect is designed for knowledgeable people.


2) About Samba

   I gave an example about printing and messages and gave it as an
   example of RedHat aiming at the server and not at workstation.
   Stephan told that this was not true because he had been able to
   print as a client.

My answer is that RedHat allows _using_ Linux as a client of an NT (or
Samba) box but functionnalities are limited.  You can print but if the
printer is twenty meters away like it happens at office then you
really would like getting the message of the server telling you it is
time to go collect your ouput.  RedHat does not allow this, Indy does.

If you want to mount an SMB share just by clicking on it you cannot do
it with RedHat, you can in Indy.  RedHat (and Mandrake) ship Gnomba
for this but in the case of RedHat not in the main distribution and in
addition I cannot believe the RedHat and Mandrake have used it for
real.

First: because it forces the user (_every_ user not only the system
adminustrator) to use IP addresses in order to configure it.  A low
level concept instead of the high level concept of workgroups.

Second: Because its method of finding SMB boxes is trying every
possible address in the range.  This work only for very small networks
with full ranges like two home PCs linked by an ethernet and only two
addresses to probe.  It does not work if you are in a large
organization who subdivides its class A intranet (10.xx addresses) in
sparse subnetworks (long timeouts to wait) each one with 65536
possible addresses.

Indy 6.0 used TkSMb and Indy 6.1 will use knetmon for the SMB mounting
and both use SMB methods for finding SMB boxes and will work whatever
the size of the network.

That is what you do when you give a real thought about in Linux use in
client roles.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org