Win vs. UNIX Usability
From jeske@... Wed Sep 23 18:20:23 1998
Message-ID: <19980923182022.B9067@home.chat.net>
Date: Wed, 23 Sep 1998 18:20:23 -0700
From: David Jeske
To: gnome-list@gnome.org
Subject: Re: Win vs. UNIX usability (Was: Re: gnome-terminal idea)
Mail-Followup-To: gnome-list@gnome.org
References: <19980923140251.S9067@home.chat.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.92.1
In-Reply-To: ; from Tim Moore on Wed, Sep 23, 1998 at 07:39:24PM -0400
Status: RO
Content-Length: 15720
Lines: 289
On Wed, Sep 23, 1998 at 07:39:24PM -0400, Tim Moore wrote:
> Right. This is more a social problem than a technical problem. RPMs are
> easier to deal with than tarballs (IMHO, and obviously still not easy
> enough for non-techies) but a lot of software is not available as an RPM
> package (and when it is, it's almost never available in ppc binaries, so
> I'm mostly building from SRPMs, which is arguably more difficult than
> tarballs, but is easier to manage/upgrade in the future).
RPMs have a few serious problems which are just as related to the app
code itself as they are to RPMs:
- you can't install multiple versions of the same RPM package at the same
time. (the binary will overwrite itself)
- you can't install an RPM unless you are root (RPM has some experimental
stuff where you can retarget the install location, but this breaks
most apps because they have a compiled-in install location)
> The other difficulty is that software packages on Unix tend to be fairly
> fine-grained and interdependent. When you get a Windows software CD,
> generally it installs not only the application you bought, but all of the
> libraries it needs, etc. Whether this is a good thing or a bad thing is
> arguable, but it certainly makes things easier for the user who never has
> to be concerned with which libraries they have, or even that libraries
> exist. It seems like Debian has made some acheivements here, where
> installing a package with unsatisfied dependencies can automatically
> download everything else you need and install those first.
I think the Debian solution is better. However, what happens when one
piece of software depends on "netscape v3" and you have "netscape v4"?
What happens to /usr/local/bin/netscape. What happens when a non-root
user needs to install an application?
> Right, but its unclear what to do about this. I don't think a purely
> technological solution, because even if we design a super-great installer,
> we can't be sure that everybody is going to package their software to use
> it any more than Red Hat can be sure that everyone packages their software
> to work well with their distribution.
Exactly. That's why I think we should change the concept of what an
"application" is for easy to use Gnome/GUI apps. Instead of conforming
to the old school "throw your stuff in some precompiled
/usr/local/bin", we should encourage all GUI apps to follow the
Nextstep/Gnustep conventions for doing "app-wrappers", like
"wmprefs.app", and we should make these app wrappers install location
independent.
> Downloading and copying aren't fundamental problems, though, just problems
> with the quality of tools. With a good file manager, it can be just as
> easy to do these things on Unix as on Windows/Mac OS or whatever. There's
> no technical reason why the GNOME file manager shouldn't be as good as the
> Windows one (or better!)
Agreed.
However, remember a few key things. Devices under unix can't currently
be protected in the correct manner. Who should be able to access a
cdrom? The user sitting at the console. Linux dosn't handle this very
well right now. You basically let all users mount/unmount cdroms, or
none.
> Installing software is different, though. Unix has security issues to deal
> with, as well as portability issues and any number of other issues. This
> is the tough problem.
Agreed. That's why I really think we should move away from the old
UNIX 'legacy' style of installing software executables into
/usr/local/bin. I hope as a few Gnustep "app-wrappered" apps start to
become mainstream, people really start to see the benefit of this
encapsulation and install location independence.
> Of course. But with a good file manager and an automounter, Unix can be
> just as easy. All we need to do is put a link to /mnt/cdrom on the
> desktop, give it a nice icon....but here's another portability problem.
> You apparently mount cdroms on /cdrom. Presumably this sort of thing will
> be resolved somewhat by the FHS, and by distribution maintainers.
The automounter should be smarter than that. It should present the
label of the CDROM, and it should be able to handle multiple
CDROMs. (my windows machine has a CD-R and a CDROM). We need to get
away from special case hack solutions like "put a link to /mnt/cdrom
on the desktop".
> > Open ended fields in Linux which confuse beginning users:
> > - LILO prompt
> > we should be using GRUB not LILO.
>
> I don't know what GRUB is, but this is clearly not under GNOME's scope.
GNOME is trying to make Linux a desktop which is accessable to a
broader user base. This won't do any good if they can't figure out how
to boot to Linux. So, I believe that while it's not under GNOME's
scope to implement this, it is under GNOME's scope to think about it.
> But in the interest of discussion, it is a good idea to use friendly boot
> loaders. Have you seen BootX for LinuxPPC? It's a graphical boot manager
> which lets you choose beetween MacOS and Linux on startup.
> http://people.a2000.nl/mwielaar/bootx.jpg
Yeah, and I think that this is a perfect example of how broken Linux
is for the average user. What do you have to do to book MacOS? You
click the button. What do you have to do to boot Linux? You have to
click the button, but before you do make sure that the open-ended text
field has the correct cryptic setup string in it.
> > - LOGIN prompt
> > win98 explains the login prompt to the user the first time it
> > boots. Nextstep installs with an account called "me" with no
> > password. It automatically bypasses the login prompt as long
> > as the "me" account has no password. To get the login prompt
> > one merely has to set a password for the "me" account.
>
> NEXTSTEP seems to be a great example of how Unix can be made usable. One
> problem which Unix has as a multiuser system is how to deal with the
> difference between a genuinely shared computer and one which is being used
> essentially by one user. There is a lot to consider in the usage
> differences between "My Computer" and "the computer which I use."
>
> But again, this is a distribution problem more than a desktop environment
> problem.
I disagree completely. One of the ways that Nextstep really made Unix
usable was by admitting that 'GUI/Nextstep' apps are not the same as
UNIX apps. They designed their whole GUI/desktop environment to handle
'next apps' as easily managed end-user stuff. The file manager knew
about app wrappers, the file-open/save dialogs knew about
wrappers. The environment as a whole knew about how encapsulated items
were packaged together. When an app was launched, it was told where it
could find it's files _relative_ to the location it was launched from,
so that it didn't have a compiled in install location.
Take this simple example. In nextstep, BECAUSE of work done with the
desktop environment, you can do the following:
- browse through the filesystem, find "Omniweb.app", and double click on it
to launch it... it has an icon in the filemanager, because the
filemanager knows where to look inside the app-wrapper for the icon to
display.
- before launch it, drag that "Omniweb.app" to the Doc. Then double click
it on the doc to launch it.
In windowmaker, you can launch and app, and it'll get an icon, which
is usually derived from a database of pre-setup icons which came
WITH windowmaker. If you get some app that windowmaker didn't know
about, it can try to pull the X WMhint icon out, if there is one, but
I've not seen this work. Then, if you drag it into the doc, unless the
app was in your path, you have to right click and modify it's settings
and put in the correct full path. In fact, much of the time you have to
re-put in the full path to the icon anyhow.
In Nextstep, all this stuff "just worked".
- you can drag that Omniweb.app to a server directory, and instantly
people who have access to that server directory can launch it from the
server. In fact, because of FAT binaries, you could have people from
different machine architectures all launch the same application.
- you can drag that OmniWeb.app into an email you are sending to a friend
of yours. He can drag it out into a folder and launch it. It will
work perfectly, it will have an icon, it's filetypes will be registered.
These are things which need to be done through conventions in the
desktop environment. They are not merely a distribution issue.
> > Other things in Linux which have too steep a learning curve:
> > - app installation
> > You should not have to be root, and things should not have to
> > install in some precompiled location.
>
> This is another single vs. multiuser problem. On a multiuser machine,
> obviously random users can't install software globally in system
> directories. They *should* be able to install it in their own directories,
> but then there's the problem of everyone on a system locally installing
> the same program. I guess that's an issue for the sysadmin to handle.
That's a non-issue. If people have quotas, they shouldn't exceed
them. If everyone installs an app privately, then it's a good
candidate for public install by the sysadmin folks.
> To install software in system directories, you obviously should have to be
> root, and I think this is true even on home machines. The problem, then,
> is how to make this requirement easy for the user. I think the answer lies
> somewhere in presenting root access not as becoming another user, but as
> "the system password" or some such which would be requested whenever a
> program or command needed root access to run. If they chose to not have a
> password, that would be OK too (but it should make them aware of the
> possible consequences of that) but it would still tell them when a program
> does something as root.
This is a good idea. Although I think it was much easier in nextstep
where if there was "one user" of a machine they pretty much never
installed anything in system directories. Because of all the stuff I
explained above, they would just put application in their "apps"
directory, and they would work.
> > - app icon setup (i.e. icon settings in windowmaker)
> > An app should be able to come with it's icon automatically.
> > There should be no changes to window manager configuration files
> > to get the app icon to correctly display.
>
> Well, there are a couple of issues here. One is the icon displayed in the
> window's titlebar or when the window is iconified. This is handled by the
> window manager and applications use hints to specify it. If the app is
> well-behaved, there shouldn't be any configuration necessary.
>
> The other is the icon displayed by app launchers, which many window
> managers include, though they aren't actually related to the task of
> window managing. Each launcher has its own way of determining icons, and
> there's really no way to ask the apps. This problem is nearing solution,
> though. For one thing, there's Red Hat's wmconfig tool. This generates
> config files for various window managers based on the contents of the
> /etc/X11/wmconfig directory, which are files associating a command with
> (among other things) an icon. Many RPM packages install a file for their
> apps into that directory, so no config file hacking is necessary. You do,
> unfortunately, have to run wmconfig again to regenerate your wm config
> files, though.
wmconfig (IMO) is a _TERRIBLE_ solution. It's just like all the other
UNIX mindset solutions. (1) non-root users can't write things in
/etc/X11/wmconfig, so again only root users can install apps, (2) as
you say you have to regenerate your wmconfig files, and restart your
window manager, how many users are going to know to do that each time
they download and install an app? (3) wmconfig has to be hacked for
every new window manager. This means that we have one group which is
responsible for every window manager's ability to present icons to
users. It should be the window manager authors conforming to a
standard which allows them to present icons, not some other developers
which don't have enough time as it is.
> But in the longer term, GNOME should solve this problem by providing a
> single launcher and single config file syntax and single icon and config
> file location. When GNOME becomes more popular, it's reasonable to predict
> that window managers will start to lose their app-launcher components.
I think this is a very poor idea. I think this should be solved by
providing a way for applications to passively export information such
as their icons and filetypes from an encapsulated, relocatable
wrapper. Just like Nextstep did.
Then Gnome can provide some common code and CORBA/whatever APIs for
accessing the database of filetypes, and for dealing with encapsulated
apps.
> > - installs
> > The Linux installs have WAY too many questions for a beginning user.
> > Win98 asks you what language you speak, and NOTHING ELSE. I think
> > this is just great, and I am a technical user. BeOS is the same
> > way. Everything which can be setup and configured can be done once
> > the system is up. That way the user only has to learn one install
> > and configuration UI. None of these configurations (i.e. networking,
> > modems, etc) should require a reboot.
>
> Yeah, I'm really surprised how much more difficult it is to get Linux up
> and running than it is with other OSs. I have a Mac, so I'm used to the
> working plug-and-play and easy installs you get in Mac OS. LinuxPPC by
> comparison was a chore to install and get working. Lest you assume that
> the difference is Apple's access to proprietary information, I found BeOS
> just about as easy to install and configure as Mac OS.
Unfortunatly, I think the crux of the problem lies in the UNIX
mentality to solving problems. MacOS developers would shudder in their
boots if someone brought up the "wmconfig" solution we talked about
above. In my experience UNIX developers tend to think about solving
"their" instance of the problem, if it means hacking a script here, or
creating a new /etc/footab there, that's fine. This is a really bad
way to go about creating a flexible and open system which many people
can contribute to without stomping all over eachother.
UNIX systems are built as castles, where you lay one brick and then
another brick, and then another brick, until your castle is
standing. RedHat is just a pre-packaged 'ready-fab' castle, which you
can pop-up in a few minutes. However, the more third parties try to
get into the mix, the more of a pain in the neck UNIX becomes.
I made a package encapsulation system for UNIX at a former job. We
called it UNIXTools and you can read about it at:
(http://www.chat.net/~jeske/Projects/UnixTools/). I would painstangly
go through each new package, download the source, configure it to be
installed in it's own private install location, and then install it
there. As a result we got lots of cool things like: (a) multiple
versions of the same package, easy to use package environments,
automatic notifications to the users when new packages were added to
their environments, a web interface for listing packages,
etc.. However, I could only install packages into it which I had the
source for, and I had to custom compile them all. This was a pain in
the neck.
Conversly, I used to admin Next machines long ago, and installing lots
of next apps on a server took no more work than just "copying" them
into "/LocalApps" on the server.
--
David Jeske (N9LCA) + http://www.chat.net/~jeske/