Kindly peruse the imbedded comments below.
regards,
Dick
-----Original Message-----
From: Sean 'Captain Napalm' Conner <spc(a)armigeron.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Wednesday, March 31, 1999 8:28 PM
Subject: Re: Kits vs ready-made (was RE: Rebirth of IMSAI)
It was thus said that the Great Richard Erlacher once
stated:
>
> >> You're certainly right about the cost of documentation. That's why
it's
> >> hard to recommend LINUX and some of the
rather excellent pieces of
software
> >> work which have been done in conjunction
with it. The documentation
is
> >> generally quite poor, and always several
generations out of date.
> >
> >Eh? I'd much rather do something obscure with Linux given a standard
> >distribution and _any_ linux book (of _your_ choice if you like) than do
> >something simpler with, say, Windows given _every_ published book and
SDK.
And I'd rather do with something that works without problems.
... but I've had VERY little trouble with
'95.
When I first ran '95, it was because a project I was working on required
it (or a Solaris box, but we couldn't afford a true Sun, and Solaris for
the
x86, which is also expensive, isn't that great).
For the year I used the
box I had no problems with it. Well, a few. Okay, it took too long to
change the dial up networking, and swapping the mouse (bus for serial and
back again several times) was an hour or so of frustration. And then there
was the time I put the machine on the local network only to have it insist
on dialing up. But other than that, it worked. I even got the Microsoft
telnet client to behave (although that required a registry hack).
It was only after a month of someone else using it (and installing a crap
load of applications, mostly Microsoft ones) did it become totally
unsuable,
to the point where I nearly lost some very important
files because it
refused to boot.
I tried installing '95 six times from scratch (across two days) and
failing miserably at it. Got fed up enough to install Linux on the thing
(the project I needed '95 for was long finished) and never had a problem
with the box after that.
Then again, I've been using Linux regularly since '92 and remember the
days of downloading 40 disk images ...
> At the POP, there are three LINUX boxes running satisfactorily for over a
> year, as terminal server, among other things, and one really can't
complain.
> I just complained because of the documentation
maze, which is certainly
in
ample
evidence.
Which is not to say I haven't had my share of problems with Linux. The
first time I connected two Linux boxes via PPP took myself and another
friend 16 hours to get working (with a few long distance calls to a friend
who helped us imensely). And we were NOT computer illiterate people (I had
been using Unix for four years at that point). The next time we got PPP
working it only took four hours.
Yes, getting PPP to work on the terminal server for the ISDN lines (the
first one we did) was a real pain. Linux doesn't like having you go
directly into the system with out a stop at the shell, even though that's
MUCH more secure.
Then recently was the IDE/SCSI fiasco (system with
both SCSI and IDE
drives, with the boot drive being SCSI. Upgrading the kernel in THAT
system
is a nightmare let me tell you, lilo being braindead in
that situation
(``No
damn you! The SCSI disk! The SCSI disk! Why the
@#$@#$@ did you put the
Q#@#$ kernel on the IDE? DIE LILO SCUM!'')).
You must have been reading my mail!
> Example: Simple tasks like installing LINUX on an
ESDI drive larger than
> what the BIOS supports are not supported by any written documents, though
> the writing about other drive types (not SCSI) may shed light on it,
though
> the doc's about EIDE are also conflicting.
These are made hopelessly
> complicated by the various often self-contradictory attempts at
describing
what's to
be done. I finally gave up on the half-dozen or so conflicting
write-ups I had and worked the details out with a fellow in Germany who,
though his English was limited, as is my German-"computerese," managed to
convince me that it was really quite straightforward.
I found this works (especially under RedHat). Make three partitions, the
first physical one small, 5M is more than enough space. The second I
usually make swap (typically twice the physical RAM, max swap space for a
single partition is 128M, but you can have multiple swap partitions) and
the
third the rest of the disk. Turn off DOS compatibility
(if using Linux's
version of fdisk. There might be an option under Disk Druid, but I don't
use that). Mark the first partition as bootable.
That's about what I wound up doing. . .
The first partition becomes `/boot' where the
kernel resides, and that
takes care of the problems of large disks not supported properly under the
BIOS. The third partition becomes '/' and contains the rest of the file
system. When you format the drives, select logical addressing (under the
RedHat installation program, it says use this for SCSI, I use it for any
type of drive system).
what I said before . . .
Of course I've now branded myself as a Linux
expert here 8-)
> >And yes, I do consider source code to be possible documentation for a
> >piece of software, just as I consider a schematic to be possible
> >documentation for a piece of hardware.
>
> It's true that source code SHOULD be part of the documentation. In too
many
cases it's
ALL the documentation, and though the code was modified, the
comments weren't kept in sync. That's where it's a real pain when they
leave out key words like NOT.
I've worked at a company that discouraged comments in code because ``The
code IS the documentation.'' And don't forget that programmers in general
hate to document, you end up with crap like we have today (well, that and
programmers can't program either, but that's a different rant ... )
-spc (Programmer forced into sysadmin and hating every minute of it)