Re: app-encapsulation and transparent-install (MS is doing it)

[David Jeske <jeske home chat net>]

On Sun, Sep 06, 1998 at 04:49:11PM -0400, Todd Graham Lewis wrote:
> On Sat, 5 Sep 1998, Geoff Harrison (mandrake) wrote:
> 
> > but seriously, isn't that more the job of your shell?  A good foundation
> > for the idea, but IMNSHO that's more controlled at the shell level
> > than at the desktop level.
> 
> Isn't the desktop the modern shell, the shell your Mom and Dad use?
> (Whoever earlier today said GNOME should let your Mom & Dad use Linux,
> I think that you were dead on, btw.)

I agree with this 100%. 

Think of a user like someone's non-techy mother or father. Can you
imagine them downloading and installing an application on today's
Linux? If anyone thinks they are going to be typing "rpm -add" or
"/usr/local/<anything", or even opening a command line shell they are
confused. They are not going to be typing in root passwords. They
won't even know what root is.

When I look at Gnome/KDE today, these are the things I see standing in
the way of non-techy users (like our mothers and fathers) using it:
  - to establish the 'Gnome application' as something different than
    standard UNIX applications, and thus something which should be 
    managed differently (no more RPMs hard-coded to install in /usr/local/bin)
  - create a label which distinguishes 'easy to install and use Gnome/KDE
    applications' from UNIX standard tools like perl, httpd, etc. Users
    need to be able to browse a website and know that if they download
    something, it'll be simple to install and use.

  - make it easy for any user (not just the root user) to install _and
    run_ an application which they downloaded with a web-browser. That means
    that if a user downloads an RPM, they should be able to:
      - install it as a standard user 
      - launch it easily (that means NO typing in the binary name
             in a shell; NO typing in a path to the binary in either
             a text or gui configuration tool; NO having to even see the
             many files which the program installed)
      - configure it easily (the less configuration necessary the better),
        and robustly (it should never get into a state which requires manual
        hacks to some configuration data)
      - deinstall it easily (and NEVER leave dangling entries, like dangling
        start menu entries or whatnot)

  - to influance a distribution to create a 'no questions' installation
    which can let you install Linux with a minimum of questions.
    This will probably be used for a client machine, not a server machine,
    and it should make assumptions accordingly. 
  - allow a 'single-user work-alike' configuration to be used in the above
    'simple installation'. This should hide the details of Linux being
    a multi-user machine, and should rely on physical access to the 
    console, rather than passwords, to provide authorization.


** Single User Work-alike Ideas:

Nextstep also did great stuff in this department. A Nextstep
installation by default has an account called "me". When "me" has no
password (like when the machine is first setup), the login panel just
automatically logs into the 'me' account. Thus, the machine comes up
as if it were a single user machine initially. If one wants it to be
multi-user, they merely need to set the password for the "me" account,
and then the login prompt will show itself. As long as it's not valid
for a user to login as "root" or "me" via telnet, and users are
required to be in a group (such as 'wheel') to use "su", this isn't a
terribly insecure thing to do.

** Easy to use software:

There needs to be a '3rd party market' (I'm not talking about money
when I say market) for software. Currently, a 'non-techy' end user
can't go out and look for "Linux software". They need to go look for
Linux software which is put together using the package manager their
distribution comes with. Because of how apps are installed in the
standard unix filesystem structure, some may not peacefully coexist,
and installation/configuration often must occur by the root
user. Thus, what we have is really much closer to 'monolithic
distributions', where you can choose which of the packages on the
redhat5.1 cdrom you wish to install but other tools don't go in so
easily. RPM is 1/2 way there, but as the Gnome/KDE folks are aware of,
the applications themselves have to change in order to go the other
half way.

** Easy to use distribution:

We also need and easy to use distribution. The redhat installation is
easy to use for a UNIX person, but it asks way too many questions for
a non-techy user. You can ask them what language they speak, and you
can ask them how much hard drive space to use (expect them not to know
the answer though), but you can't ask them much more.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net