Why I have gone the GNU route
Alan Robert Clark
Printable pdf version
1 Introduction
I am often asked what my problem is. I don't know---how should
I know :-). Fact is, many people are puzzled by my adherence (as
far as is possible), to GNU principles and products, and my aversion to all
things Bill. These are my personal opinions as to why the standard
executable-only software (please buy the upgrade) just doesn't cut it for me.
2 What is GNU?
Gnu's Not Unix. Its official, and consistent with the standard recursive
acronyms that abound in the unix world!
Its about freedom. Of course, GNU is free, and it isn't free, if you see
what I mean.
Many people confuse GNU software with Freeware, or shareware, or
anythingelseWare, that is so popular in the DOS world. The GNU licence
effectively ensures that the CODE, or SOURCE is free. You may pay to get
the executable, or some support, but the code is available. Having
said that, most GNU products are free in the cost sense too.
There is also confusion between GNU-project products and products that are
distributed in terms of the GNU License. The GNU project as such can be
found at "www.gnu.org" and has many quality
products. Many other people contribute software, to be found all over the
show, of excellent to shoddy quality, licensed under the GNU ``GPL'' or
CopyLeft.
Many people (particulalry non-programmers) are puzzled by the insistance on
the availablility of the code---it is important for the future growth of the
product. Not only are you able to tinker with the software, but so
can others when the current maintainer gets run over by a bus, gets too
busy, or simply gets tired of it.
Some of the GNU software that I use has gone through several
``maintainers'' (PCB, DOSemu, MusicTeX), and has gone from strength to
strength! Another advantage is that you have an international team of
coders actively working on the software. Most have never met each other,
but all contribute code, or patches, or maintain sub-parts of the project.
Many think that the above model would simply produce nightmare code! There
are some good guidelines to follow, however, and the exposure of the code
to others generally tightens it up! Peer-reviewed code is far less
likely to contain bloopers that you simply can't see because you wrote it!
GNU software is by no means bug-free, but it crashes a heck of a lot less
than Bill, and the bugfix is *very fast*, without a wait for the next
6-monthly ``service pak'' that is almost as big as the original software
(and costs as much)!
3 OK, but really Why?
We'll start with document preparation, a never-ending task in an engineer's
life. By document, I don't mean those things that Turd thinks are
documents, I mean 100 page reports with hundreds of figures, references,
sections etc. A quick tour of the history follows:
3.1 WordStar
The late, great classic, useless at maths, pictures, but wonderful :-) One
of the only editors for YEARS thereafter with column cut-and-paste!
3.2 Manuscript
Manuscript was a brilliant wordprocessor created by Lotus. It was truly the
Greatest thing since sliced bread in about 1988. It handled postscript
graphics (well), did equations really well (via a similar syntax to TeX),
and had text and preview modes, which meant that it was really fast for
text entry (really important in 1988!!). It printed as it previewed.
NO little quirks or ``funnies''. What you previewed is what you got! The
Manuscript upgrade to 2.1 was a really good one. It used a ``folding
editor'' where you could hide sections, subsections etc. This was a really
brilliant feature, which I have not yet seen efficiently replicated,
although many folding editors are out there. It also encouraged the
LATEX-like structure in documents.
But there were no references, figure refs, cross refs, etc. These had to be
done by hand. Hence we all used the harvard system, and at the very last
moment, we did a search-and-replace to numbers! Still used by people in the
department. One problem was that it was a tad unstable on large files. A
colleague's PhD was 600k or so, and every now and then, it would corrupt it
whilst saving. Back to the previous version!
This was my first introduction to the disastrous nature of Proprietary file
formats (ie non-ascii), which are almost impossible to repair after they
have gone awry.
Lotus unceremoniously dumped Manuscript, and graciously allowed you to buy
AmiPro as a replacement.
3.3 AmiPro
The ``successor'' to Manuscript, bought into Lotus from the competition. It
had no Postscript capability, no math capability, and the ``Manuscript
Document Import'' facility converted text. Only text. A later version had
a TeX maths engine, but could not do inline equations!. Well, it
could, but for heaven's sake don't move the paragraph! The text of the
paragraph moved, but the inline equation stayed put. I discovered this
whilst setting an exam: I had a question which said something about a
50W transmission line. I then moved the question in front of another
one, and it left the W sign behind!
This was my first introduction to the disastrous nature of Proprietary
maintainers, who could sell, buy, or drop a package, regardless of the
user's need.
The summary dropping of an excellent package really cheesed me off. It was
to be repeated later in other ``acquisitions'' and ``mergers''. The
replacement of that package by a grossly inferior product (from an
engineer's point of view, I guess most business types were most happy)
cheesed me off to an exceptionally large extent! They could have released
the source code!
Again, engineers do not do (or should not do :-) office memos in
one-of-twenty-million fancy formats, that occupies two lines and 40 megs, a
document contains maths, figures, cross-references, citations...
Another thing that escapes these types is that a document also needs to be
maintained, as well as the software etc, hence an awful amount of
time is spent massaging older documents (and esp graphics) into newer
document packages!
The classic ...Proprietary file format...change (still called
.doc!) infuriated more people than MS thought it would. It was a blatant
``I will force you to upgrade to remain compatible with your cleverer
friends'' tactic. It certainly blew the ``If its Microsoft, its
compatible'' line out the water. Some of my colleagues are still of the
opinion that all MS products are compatible though! (Sheesh, never mind
the products, what about the product versions) Turd still doesn't
handle postscript at all well (you get a Bounding Box if you're lucky, if
not, it doesn't work---eg Matlab output (which is Blue Book
correct postscript)). The mathematics is absolutely horrendous---it looks
hideous at the best of times). Does not have a citations database interface
(ie References) ala BiBTeX, and even its cross-references are weak.
The biggest problem with Turd is the way people are encouraged to
``fiddle''. You get headings in wierd unreadable fonts, with no guidance
as the the heading ``level'' etc. (I recently received a press release in
Brushscript, at 10 points. Nobody in the office could actually read it)
4 What Else?
Graphics packages:
4.1 TurboCAD
Excellent little package---rather a torturous route of exporting and etc to
get figs into Manuscript etc, but it worked well, and was dumped. (There
was a much later, revised edition after yet another aquisition, but it was
essentially dumped.
4.2 Freelance
Did reasonable drawings, in a completely proprietary standard! Worked well
with manuscript though, via a metafile output that did not always get
everything right. Altogether, one got used to the idiosyncracies and
actually had a working system, although a bit tedious at times..
It was dumped.
4.3 No real successor
There has been no real successor to these graphics packages, with various
ones being tried, but unless you go for a mega-buck package like AutoCAD,
there is not much to touch xfig (naturally not available under MsLoss :-).
These days, I am a convert of GNU pic, using the GNU m4 based
``circuit macros'' as a basis for my graphics. It
really works exceptionally well.
5 Compilers, editors and etc...
Yet another tale:
5.1 Turbo Pascal
I loved Version 3 :-) (limited by 64k size etc, marvellous!). I stuck with
it (ie paid for 6-monthly ``upgrades'' aka bug-fixes) until version 7.0 (ie
through about 7 upgrades---various sub-point versions too) Notably, even by
that stage, although it could handle DPMI, and tons of memory, variables
could still not be bigger than 64k!
I would hate to add up the cost of the 6-monthly upgrades...Borland
brought out a brilliant text-based windowing Toolkit---Turbo Vision.
Borland dumped it! The disastrous nature of Proprietary maintainers again.
And there we were---stuck with the TV bugs, and completely held to ransom!
Note again, COST WAS NOT THE ISSUE, I had reams of software written
with this toolkit, which was a binary release, with bugs. Eventually they
also brought it out in Borland C++, and then released the source code! it
is still a popular Toolkit, and has been ported to many platforms including
Linux.
Great little programmers editor, many good features, inc column or
block-wise editing. Not of tremendous use under Linux, though. Brief was by
a company called UnderWare. They sold out to Borland, who released it as
their main programmers editor for one upgrade only, thereafter going
the WYSIWYG route too. Brief basically died after that, no updates etc.
Crisp was the shareware version of brief, compilable under Linux. Great!
used it for several years, but no colour-syntax highlighting etc. Crisp
moved over to being real-money ware, but the difficulty was the source.
2.2e was such legacy code that it wasn't really worth the effort in doing
anything about it. The commercial Crisp is now available under Linux, NT,
etc, but a friend has it, and its Buggy. It also has developed the attitude
of: Gee Sir, yes, that it a bug, thanks for bringing that to our attention;
here: buy an upgrade to fix it.
Again, GNU is not Freeware or Shareware---I was still held to ransom.
5.4 Borland/Watcom/MSVC
Ever tried taking a ``bog-standard'' Borland-C++ app to Watcom or to
Visual? Let alone the library inconsistencies, how about the differences in
longevity of i in "for int i="??? The only (compatible) way around this is
to declare "i" at a higher scope, ala Pascal, and go with the "for i="
syntax.
The real problem is that you can wait for months before a bug-fix
for which you then have to pay! The most classic response ever, was
received by us when we used M$ SourceSafe as opposed to RCS/CVS
revision-control software: ``What you are wanting to do is exactly what we
intend SourceSafe to be used for. Unfortunately the inclusion of
sub-version numbers will be a big performance-hit in the software at
present. This will not be solved in the next release of SourceSafe. Thank
for choosing M$ SourceSafe.'' The last sentence killed me. I now use CVS,
and my colleagues in the team that run '95/8/NT use CVS-RCS, a shareware
package that interacts perfectly with my Linux Samba-shared drive.
12 June 2000. So you thought it was all over, that Bill had finally
triumphed? Well, we used to use PVM (Parallel Virtual Machine) for
parallelizing SuperNEC computation, but now PVM has largely been surpassed
by MPI(Multiple Processor Interface). Most apps used M$ VC++ and M$
Fortran4.0 THEY DUMPED IT. Have to fork out for Digital's Visual Fortran.
Once again etc etc.
Before 3.1 had a TCP/IP stack of any note, I switched to OS/2 version 2.0,
for 800 bucks. The netware requester weighed in at 600 bucks and the TCP/IP
at about the same. Only found out after that that they did not work
together!!!! This was later fixed, but not marvellously. Dos support wasn't
all that hot either. I lasted about two months before switching to Linux in
October 1992. (Remember, 1990 bucks were actually worth something!!!)
The oldest file that I still have in my home tree is a set of m-files that
I used in matlab 3.5 and is dated 29 December 1992 :-)
5.6 Toolkits
Originally I used Prof. Walkers' Screen Management Library under TP3,
migrated it to graphics under TP4, added all sorts of extensions under TP5,
and then moved to TV. No sooner do I embrace Turbo Vision under pascal,
which eventually gets brought out under C++ (With source, nogal) than it
gets dropped. OWL is the way forward, which gets dropped (in essence,
anyway), then Macrosloth's Foundation Classes come along in their various
incompatible incarnations...
A man can get tired of reworking code. Some of my apps ("wkhm") are still
around and useful, but there are executables under TP4 (with the SML), TP5
(with TV) TP6 (with OOP)(Actually also TP5.5) & 7 (with XMS, non 640k
limit management), and GNU-Linux! I have tried GNU-DJGPP(Dos), but the lack
of support (at porting time) of standard Un*x utilities was a problem. In
essence, no extra functionality was added in each of these versions!! its
just plain reworking.
6 So?
If I would add up the amount of porting and re-porting of documents, code,
toolkits that I have done...If I would add up the cost associated with
this...and the cost of the ``upgrades'' of the packages
themselves...In a word, it is ``fed-up''. I have been around for too
long in the software world. I am sick-and-tired of being held to ransom,
and of being dictated to.
Again, though, the major problem is the lack of source. I once designed an
editor ``Ted'' based on the Turbo-Vision editor example code (buggy as
hell). Fixed the bugs, and added wordwrap features and autosave that the
original did not have. A popular DOS UseNet news-reader (Trumpet) was based
on the same original code. But I couldn't get autosave implemented in the
news-reader as although it was free of charge, it was not free in the
source sense. Quite a number of emails passed between me and the author of
the reader, but he would not agree on my method of implementing the
features. So the Trumpet had no autosave, and no word-wrap. (At that
stage, for some reason, we were having regular power cuts).
This illustrates again that if I had had the source, I could implement my own
version that the author doesn't agree with, but that I want!
I have been forced to massage countless programs and documents into some
other form, simply because of an upgrade, which usually has some
``must-have'' feature that is the attraction in the first place. I suppose
I could still use Manuscript, but I write longer documents now, with more
and better-looking graphics, and have more than 640k in my machine :-)
7 What I do use
Hence my attraction to code that is freely available,
maintainable, not subject to ``buy-outs'' and political decisions
etc etc.
7.1 Editor
As an editor, VIM; in everything. Its
extensible, and runs on any platform known to man...
I use it for composing mail, writing C++, html, Microchip Assembler,
LATEX documents. It is free, strongly supported by a large user
community, and a large contributor community, has many many Web pages
devoted to it, is largely Vi friendly, has column/block operations,
syntax-highlighting, language-specific commands, ie a key binding to `make'
calls "make" in c++, "latex" for LATEX, etc. It compiles on every
platform known to mankind including Linux, all unices, NT, 95/8 Dos, OS/2,
Mac, Amiga......
Its extensible, remappable, programmable, compatible with a large range of
``usual'' Un*x stuff.
My customizations of it can be found here.
7.2 Document typesetter
As a document typesetter, LATEX. Its extensible, and runs on any
platform known to man...
It was designed for mathematics, has a decent structure at its
heart, has good olde fashioned ASCII as its file format. No matter what,
you can always retrieve most of an ASCII file, even if it has been
corrupted!!!!
Has decent html tools (TtH, latex2html), has decent self documentation
tools for packages (DocTeX, aka .dtx), handles extremely large documents
without a hiccup, has intelligent multipart document support, uses any
decent editor of your choice, has exceptional postscript support (dvips),
excellent and entirely accurate previewing (xdvi, or yap on the MsLoss
world (MikTeX)), has extensive support structures "comp.text.tex", and the
CTAN---Comprehensive TeX Archive Network, a collection of ftp sites with
all sorts of (free) add-on packages, there is a
local
mirror.
For my figures, I use "xfig", a truly excellent package which allows me to
embed LATEX maths etc in my figs. I use the "pstex" output method, and
thence "dvips" to get truly good quality figs.
For circuit diagrams, and increasingly for any graphics, I use a truly
excellent text-based bunch of macros ``circuit macros'', some of my figs
can be found here.
7.3 Compiler
As a Compiler, G++, the GNU compiler. G++ runs on any platform known to
man...If I need pascal, p2c does a good job, for fortran, f2c does
likewise, although there is a ``native g77'' that I now use in preference.
Decent tools such as debuggers (xxgdb), segfault and memory hole traps
(Electric Fence), decent Make (GNU Make), auto code-writing thingy's (yacc
and bison). IDE's also exist (which I dont like or use, I use VIM) such as
wxpe, a Borland Turbo-Vision look-alike, etc. In addition to this, we have
benchmarked G++ code versus various other compilers (on the same machine)
and have had better results, sometimes stunningly better results.
7.4 Utilities
As a bunch of utilities, including a shell, the GNU tools. These have been
ported to every known platform that g++ compiles on, including bash for
NT!!! This is why the system I run is actually GNU/Linux. Most of the
utility and system software is GNU, and the Kernel is Linux. GNU/FreeBSD
also exists, as well as GNU/NT etc etc.
7.5 Electronics Stuff
I use the REAL SPICE, sans restriction on nodes etc that the
commercial chaps slap on their version which run exactly the same code! I
use PCB by Thomas Nau to design my printed circuit boards, and the Circuit
macros by Dwight Aplevich for schematics. There is a wealth of stuff out
there! (try octave as a Matlab replacement).
7.6 Toolkits
As a windowing toolkit, I am going to investigate gtk+, the Gimp Toolkit. A
native 'Doze port is available. ie Code should be portable across
platforms. In the past I have used Turbo Vision, which is available for
'95/8 and Linux, but I find a lesser need for a GUI-like front-end these
days!
Most of the serious technical windowing code I am involved with is written
in Matlab, namely SuperNEC, and Visual CASED, an
Electromagnetic Method-of-Moments and a Variable Speed Drive State-Space
code respectively. Rumour has it that The mathworks also releases a 9x/NT
port of Matlab, so code written with this toolkit is platform
independant too :-) :-)
The online version of this document is "http://ytdp.ee.wits.ac.za/WhyGNU.html"
Back to Home Page
Webalizer Stats
This document was translated from LATEX by
HEVEA.