Re: [tlug] Browser blues

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Josh" == Josh Glover <tlug@example.com> writes:

    Josh> Quoth Lyle (Hiroshi) Saxon (Mon 2004-06-07 10:55:59AM
    Josh> +0900):

    >> Josh Glover wrote:

    >>> As a fellow Mozilla / Firefox "dual-booter", how did you get
    >>> around the fact that running 'mozilla' (/usr/bin/mozilla on my
    >>> machine) starts up Firefox (or vice-versa, depending on which
    >>> you installed last)? I run /usr/lib/mozilla/mozilla-bin, but
    >>> is there a better way?

Is this attribution correct?  Hard to believe ....

Aside: On most distributions it is a bad idea to run the *[-.]bin
version, because the no-bin version is a wrapper script that sets up
the environment properly.  I don't know of any distribution, including
Debian, with a documented policy about what the wrapper may contain.
(I haven't checked in at least two years though.)

The way to get around that fact is to run a distribution (such as
Debian) that makes the assumption that if different binaries come in
different packages and both are installed, the user might want to run
both in some convenient way.  Otherwise, you need to install all
conflicting versions and see what they put in the wrapper (if there is
one).  Then check each version to see what happens if you give it a
different name.  It is now considered "worst practice", to coin a
phrase, but historically many binaries had name-dependent behavior.

Eg, GNU grep used to be a single binary whose behavior changed
depending on whether it was called grep, fgrep, or egrep, but now the
latter two are shell scripts, at least on Debian.  Busybox still
behaves this way I believe.

    Josh> Obviously you downloaded a binary package. There is nothing
    Josh> wrong with installing software to your home directory--this
    Josh> is yet another way in which Unix lets the user do what he
    Josh> wants without affecting anyone else.

Which of course is a double-edged sword.  It always used to piss me
off that traceroute, which does not require root privilege, is in
/usr/sbin which is not on the default path for ordinary users in
Debian.  (It would piss you off too if your ISP's NOC were as
incompetent as Tsukuba-Dai's.  :-P )  Similarly, if you install Moz
or Firefox in a particular user's directory other users, and in
particular root, won't have access.  Going one more level, nobody in
their right mind would browse as root, so in this case it doesn't
matter.  The point is that this flexibility is rope: you can hang a
tire from it and make a swing, or you can tie a noose and ....

Also, I note that "it just fired up".  That suggests the possibility
that "." is on the path, which is a ba-a-ad idea.

    Josh> There is no difference from a security point of view.

However, as I point out above, you do want to have a ~/bin directory
to put those executables in.  (In general it's OK for it to be
one-per-app; the point is you don't want "." on PATH.)

    Josh> can thus only affect that user's account.

Obviously as a black hat you have little imagination.  First, there is
typically a lot of stuff on the system that the user can read, and
some stuff they can write, that they don't own.  Second, I bet his
account can send mail, use ping, and fetch http URLs, all of which can
be used for nefarious purposes.

    Josh> The technical term for this is "segfault and die", or just
    Josh> "segfault":

Maybe.  Segfaults usually leave spoor behind, although he's probably
running the GNU Numbskull-Oriented Mental Eviscerator or something
like that, which makes assumptions about user intelligence that any
life form above slime-mold should take exception to.  It's actually
quite likely that an assert was triggered.

There should be a GNOME Console application which simply sucks data
out one end of a named pipe (OK, this is GNOME, so I guess pipes are
out, you have to use CORBA) and spits it out on a window (with a huge
scrollback buffer), while all GNOME apps stuff their studly errors in
the other end.  (I wouldn't be surprised to find there isn't one, mind
you, but surely there are enough inquiring minds that want to know
that there _should_ be one.)

    >> So, my installation of both Mozilla and Firefox is totally
    >> unscientific and sloppy, but they do seem to run totally
    >> independent from one another, as well they might I suppose,
    >> being that they are not installed correctly, but are running
    >> from independent folders under user......

Actually, this is a well-known method for organizing applications.
The Mac has always done it this way.  Windows does it this way (except
that applications regularly replace stuff with "known good" (for the
application, not necessarily for the system) versions of DLLs in
c:\windows\system, which is why a regular reinstall of a recent
version of Windows is necessary).  The "depot" and /opt are Unix-based
methods for doing this.

The FHS-style bin, lib, share, man organization is a pure optimization
based on the fact that traversing a directory tree in Unix is
inherently slow because every link you follow requires a system call,
and therefore requires at least two context switches, and usually many
more, before you get your next turn at the processor.  Thus, to find
something "on the path" it's much faster if everything you might want
to find is in the same directory, or in one of a small number of
directories.

To give you some idea, early in the development of XEmacs 21.4, on my
machine it took over 45 seconds to cold-start XEmacs without running
the user's rc.  Now it's under 10.  The difference?  About 2500 calls
to stat(2), based on optimizing away unnecessary directory searches
while setting up the Lisp library load-path.

    Josh> Nope, you inadvertantly stumbled upon The Unix Way. And
    Josh> whoever said that Unix is not user friendly!? :)

Paternalists.

    Josh> Jim Tittsler would not have informed me about the existence
    Josh> of the magical 'about:config' URI.

Heh heh heh.  That's why you should attend TLUG technical meetings.
Kat Momoi mentioned it too.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.