Re: [DotGNU]portability of GNU software (was Re: Dotgnu written in C#?)

[Stephen Compall]

I may just be restating alot of what nb wrote, but....

DrDiettrich writes:

> This goal of platform and environment independence certainly is
> achievable. Free software should be either general in nature, so
> that it will run on any platform without modifications, or it will
> be designed for specific platforms or libraries, which then can be
> assumed as available and conforming to their own specifications at
> build and/or run time.

Perhaps achievable, but worthwhile?  A glance at sources for any of
the most portable programs, such as general.c from Bash, shows that it
isn't hard for portability crap (as I think of it) to overwhelm useful
C code.  And because no one seems to be able to push all this into a
portability library, it muddies up the waters for everyone.

As RMS said in "The GNU Project":

    Since each component of the GNU system was implemented on a Unix
    system, each component could run on Unix systems, long before a
    complete GNU system existed. Some of these programs became
    popular, and users began extending them and porting them---to the
    various incompatible versions of Unix, and sometimes to other
    systems as well.

    The process made these programs much more powerful, and attracted
    both funds and contributors to the GNU project. But it probably
    also delayed completion of a minimal working system by several
    years, as GNU developers' time was put into maintaining these
    ports and adding features to the existing components, rather than
    moving on to write one missing component after another.

If you want to see what portability does to other projects, take a
look at the strptime interface code in the Python distribution.  That
is ridiculous, and if that's what it takes to use strptime portably
across software platforms, I will reject it.  And I do, when I get
around to actually coding. :)

Much portability code, I believe, causes more problems than it solves.
For example, Bash provides /dev/stdin et al emulation for systems that
don't have it.  I can see how this would be a convenience in some
cases, for example if you want to read from a file on the command line
or stdin if none is specified (in which case you'd set the filename
variable to /dev/stdin), but consider this:

if test -f $1; then
    mozilla $1
fi

Unless mozilla also provides /dev/stdin emulation, you have a problem
here, but *only* on systems that don't already provide /dev/stdin.
Congratulations, you have a portability problem.

The choice we are offered, then, philosophically, is to either enhance
the capabilities of the GNU system (by moving on to another program or
feature), or to enhance the capabilities of non-free operating systems
(by porting the program to them).

Finally, my argument only applies to OS portability.  Hardware
portability is not only good and important (as GNU runs on many
architectures) but very easy (unless you are, er, generating machine
code).  I also consider it worth a little effort to get programs
running on BSD, unless you depend on glibc-specific features, such as
SysV-capable interrupt behavior.  After all, the BSDs should *really*
have switched over by now.

BTW, when I took some of the Bash code for my own project, I stripped
out the /dev/fd and /dev/stdin emulation.  Enough is enough.

--
Stephen Compall or s11 or sirian

What no spouse of a writer can ever understand is that a writer is working
when he's staring out the window.

computer terrorism domestic disruption SCUD missile Glock 22nd SAS spy
Defcon codes ASIO investigation bullion Belknap Consul BLU-97 A/B
Baranyi