[GRASSLIST:186] Re: Considering replacing ESRI

[Glynn Clements]

John Doucette wrote:

> I don't understand why computer programs are written the way they are today.
> Back in the DOS days programmers designed their own drivers for monitors and
> printers ...  Then along came Windows with every program sharing dll's and
> other program librarys.  F&%k program librarys.  I can still run my old DOS
> programs by by copying a directory of files onto a new machine, erasing the
> read-only attribute, and firing off the progams.  This is because the
> programs are complete in themselves and do not require shared files or
> program libraries.  Sharing is nice to teach to school childern but sucks in
> the program world.  Linux is just as bad as Windows, and maybe worse, when
> it comes to share file dependancies.  Trying to trace out these dependancies
> and to understand them requires a major commitment of time.  This is
> ridiculous to me in that shared librarys might have made sense when hard
> drive space was limited but with the multi-gigabite drives today it would
> not be an issue at all to let each program use as much space as necessary to
> be complete in unto itself.

There are several common reasons for using shared libraries, but
conserving hard disk space isn't usually one of them. The main reasons
are:

1. Conserving memory. Shared libraries are shared in memory; every
program which uses e.g. libX11 uses the same in-memory copy of it. 
Also, unless you have enough RAM that you don't need any swap,
conserving memory has performance benefits.

2. Consistency. If all programs use the same code for a particular
task, they will all behave consistently in that area.

3. Ease of maintainence (yes, really). If a bug is discovered in a
shared library, you only need to upgrade that library to solve the
problem; OTOH, if any programs were statically linked against that
library, you have to upgrade all of those programs as well. This is a
genuine issue; when a bug was recently discovered in zlib (which
implements the compression algorithm used by gzip), not only did the
OS vendors release fixed versions of zlib, but many application
vendors also had to release updated versions of application binaries
which had been statically linked against zlib (in order to eliminate
the dependency "problem").

The main problem with shared libraries on Linux is lack of binary
compatibility, which is basically down to a lack of discipline on the
part of the OS vendors. They should "just say no" to gratuitous
version upgrades, sticking with the same version until it's truly
obsolete (rather than just "not the latest version").

Having said all that, I'll contradict myself and point out that, for
GRASS, file size *is* important. The binary packages are already
~36Mb; that may not be a significant amount of disk space, but it is a
*massive* download for anyone without a flat-rate broadband connection
(for anyone who is downloading over a dial-up link with per-minute
charges, it's prohibitive).

> I ordered the CD version of Grass because I thought I could avoid time
> downloading and maybe make installation easier.

For anyone who hasn't discovered this yet: building from source may be
more work (although not necessarily), but you should eventually get
something that works. If you build from source, you only need to have
the right libraries. You don't need to have the right *versions* of
the right libraries, as is the case for a binary distribution. You
will end up with binaries which work with whichever library versions
you have on your system.

As far as binary compatibility goes: we can't force the distribution
vendors to start caring about this. The best that we can do (and we
*should* be doing this) is to accurately label binary versions. If it
was built on RedHat 8.0, then it's a "RedHat 8.0" package, *not* a
"Linux" package.

-- 
Glynn Clements <glynn.clements at virgin.net>