[KLUG Advocacy] Linux tutor.

[Robert G. Brown]

On Sat, 04 Oct 2003 13:13:21 -0400, Adam Williams <adam@morrison-ind.com> wrote:
>>software itself was often free. In 2 instances, I got many hundreds of 80
>>column punched cards.
By "free" I mean without any mention of licencing at all. Some stuff had 
a BSD licence.

>Only used punch cards once, to load data into a machine.  I don't regret
>not having done it twice.
This was just about the ONLY use of punched cards, in my experience, which 
is probably greater than yours. Oh, the other one is the generation of some
amusing stories. Readers of this posting now know I have a skill that does
not appear on my resume.

>...I got some stuff my calling various companies BBSs through
>references in magazines like Byte.  Wasn't very efficient, especially at
>2400bps it took a VERY long time to find anything.

I saw that, but never did that sort of thing. I was still on mainframes, or
on what would eventually be known as the Internet, and didn't really deal
with this.

>>>I didn't even know anything like APL existed...
>>Right, another example of poor communication. In reality, there were a LOT
>>of fairly high-level programming tools that would deal with many of the tasks
>>you needed to do, but unless you browsed a couple of DOZEN magazines 
>>(and they had to be the RIGHT magazines) there was very little chance of
>>finding them.
>And the odds of finding those magazines on a magazine rack in GR? - 0 - 
Just about, I'm sure. Not that they were exotic or anything... they might have
been found in the GVCC library, or other reference libraries nearby. Mostly
they were academic or professional magazines and journals. 

>And I saw the trend of magazines like Byte and other periodicals I did
>have move away from "real" technological problem-solving meat towards
>review-mania.  With the decline of reader submitted material and
>articles I more-or-less abandoned the whole magazine realm of things. 

>Until periodicals like C++ User's Journal, Dobbs, and Sys-Admin somehow
>found me through their marketing arms, otherwise I had no idea such
>things even existed.
Yes, About when was this? I suspect your opinion of these (and how useful
they were) dependied STRONGLY on when in their life-cycle you were exposed.

>>I knew people who trolled for "better software" from the late 70's through
>>the time the world-wide web became pervasive, and it was tedious work.
>I was 9 when the seventies ended - all I remeber is Star Wars, snow
>days,  Carter interrupting my TV shows, and the cute girl down the
>street.  I got my first computer in 1982.  As bad as it was in 87/88
>when dial-up became possible I can only imagine what the 70's were like.
In the 70's, my use of computers outside of an office was limited to dialup
at speeds no greater than 45 characters per second, either to a company
modem, or the phone number of a packet-switched common carrier (like Tymenet
or Telenet). My first access to anything like todays Internet was in 1983,
via a mail server at Wayne State University, through Telenet from Richmond,
VA.

In the early 80's I played around with a number of 68000-based machines, and
had an IBM PC wherever I was from '82 to '87, though my focus was still on
mainframe-based stuff. I bought my first computer in 1987, a PC-XT, used,
from a good friend of mine.

>>I am belaboring these points because they are part of the economic tradeoff 
>>that drives choices like "Do we write the code here, or do we search for it?"
>>Overall, the economics used to be very much in favor of writing the code. Now,
>>the economics tend to favor spending at least some time searching for existing
>>software, instead of coding.
>Yep, I do very little coding now - at least beyond scripting.  Even the
>modern RDBMS (PostgreSQL, Informix, etc...) itself obseletes many of
>those older packages and tasks.  An OUTER join is a beautiful thing,
>otherwise even something like that required either writing code (if you
>were on a PC) or access to a "real" spreadsheet application (Wingz).
OK, but it doesn't really replace good front ends, or maybe for you, it
does. In general, DBMS'es don't.

>>>When I found awk on AIX I thought I'd died and gone to heaven. I was really
>>>surprised that there were no equivalent tools on the "PC":
>>I think awk and other "Unix tools" had been ported to the PC by the mid-
>>1980's, and was using them on PC's, in MS-DOS, before I hit real UNIX
>>systems in 1988.
>Maybe they were, but I looked for a couple of days, called people, and
>never found them.  I remember finding some things but they needed a
>specific compiler or some such to get them to work.
I was in a rather rich environment, in relative terms. UNIX was in essence
created by AT&T a few miles down the road from where I lived. Everyone seemed
to know someone who knew someone who was getting something purported to be
useful -- for something -- and if not, at least dsome of it was interesting.

>>>"I mean WTF?  Doesn't anybody know about these?"  The
>>>answer was "Apparently not", so risking $10 on some funky OS that
>>>claimed to run on my PC *AND* provide those tools?  Easily worth the
>>>risk.
>>A no-brainer. Even so, with better communication, you might have known
>>about "UNIX tools on DOS" diskette I stumbled over, and you would have
>>not been quite so eager to jump from DOS/Windows...which ought to be a
>>lesson to Microsoft.
>Possibly.  But there was also the whole scale issue.  PC tools, even if
>they worked on a file with 8,000 records typically bombed out when you
>gave them 80,000 records.  UNIX also eliminated the need to peice-meal
>everything,  but that may have had to do in part with the hardware
>involved.
That's right. a lot of the algorithm construction used in writing the PC
tools of that era were pretty crude. A number of software creator of those
days didn't know or understand the implications of scaling things up, and
I'm not thinking of the obvious things, like memory. A lot of people wrote
some really BAD utilties, like sorts, which were O(n^2), while most of 
these could have been done with O(n * ln(n)), at least.

>I think M$ has learned that lesson well.
Oh? How so?

>>>>>..- OR - WingZ, awk, postgres, on an RS/6000?
>>>>Um, you've got a better shot at things here, people didn't appreciate Wingz
>>>People didn't, I did.  It was "odd" about certian things, and they could
>>>have learned some UI lessons from the Excel folks,  but it could process
>>>data - which was sort of the point.  Excel could think and possibly day
>>>dream about processing data.
>>Wingz was indeed appreciated (and still is!) by folks who had content over 
>>structure and behavior. That was the environment (Wall St quants) that I was 
>>in. These guys would wade through anything to get the results they needed,
>>and if the form was nice, but content free. it ended up in the shredder, if
>>it was lucky.
>I love result oriented people.
Yeah, they were (and are ) pretty ruthless about it, too. Hafta be. Nice place
to work, if you can keep up, and don't mind the stress.

>I had the advantage that no one had even a hint of understanding what I
>was doing or how I went about it - just that (what then was) really cool
>stuff came out on the band printer.
Yes, I never had problems in this sort of atmosphere. When people felt 
unable to discuss what was going on, but knew that the results of whatever
voodoo I was doing were useful, they were happy,and so was I.

>>>Although I did learn to loath Imake.
>>Yes, seemed to be the peak of UNIX obscurity at the time. No one liked it,
>>the only exception being a former SUN engineer who spoke in monosylables,
>>never made eye contact, and usually ate alone in his own corner of the
>>cafeteria.
>Probably because using imake drove him to slice-n-dice his family.
Hey, HIS THING.. no one wanted to ask! :)

>>Imake was a somethg of a black art, and it was powerful magic. I see that it
>>has been called a "horror" on a parellel subthread. No argument there!
>None here either.
Somehow, I wasn't expecting this thread to turn on a passionate defense of
Imake...but I'm patient... it could still happen...

>>>Those thick white volumes from IBM documented everything (and I mean
>>>everything down to the parameters for the various system calls).  One 
>>>could at least take a stab at it.
>>That's certaily true. IBM's failure related to indexing, and tables of 
>>contents (the nature of the failure being that they didn't have any, or they
>>were too detailed). I also recall looking up things like error codes that
>This is true, the cross-refernceing was basically non-existant.  I had
>the advantage of having the time to just read through all ~18 volumes,
>so I could find my way around pretty good.  Actually I'm not certain
>documentation has gotten that much better as far as indexing goes.
I do have a set of MVS^h^h^h OS/390 documentation CDs, and they are rather
an improvement, especially regarding indexing, over what we had to deal
with in the late 80's. 

>>weren't in the manuals, and IBM people on the other end of the phone line
>>saying things like "Gee, you're right, it's not there!". But these were 
>>bearable. Management seemed to understand when I said things like "We're 
>>still researching the A292 error", since it was so time consuming...
>Those are still in there.  Or the famous error code -25880 error code
>among informix users - "An unspecified error condition occurred" :)
I like that one, so similar to the old Xerox A5612 error, which I loved
so dearly: "Impossible exit from load module has occured, in addition an
unspecified hardware error may have taken place. Data interity checks
required."  I won't bore anyone with all the details, but this one error
code not only covered incredible territory, but had so many of its own
inconsistancies that it was almost worse than useless.

My fave IBM errors were GDDM error codes that were formatted so that the
real meaning was in the subcodes, and no manual contained some of the 
values we got for some or all of them.

>>>And on the PC... "This application has performed an illegal operation" 
>>>(i.e. "Tough cookies").
>>Right. you're nowhere. The software vendor wants this put into a debug 
>>environment and rerun... except there is so much workstation-specific stuff 
>>going on that creating debugger-capable environemnts that really duplicate
>>production is quite a challenge.
>>...
>I tried capturing symbol tables, etc... on Windows once.  Once.  Just
>re-install the *#$&(*!@ *()$&@( @*@ thing.
As a once-upon-a-time MSDN subscriber, I got to install whole OS'es that
were "checked builds", with all the symbol tables. That was always fun,
since there was lots of overhead as a result. 

>>>>... In addition, you can make system image CDs completely legally... 
>>>And restore the system image to a different workstation, with different
>>>hardware - Linux cares how much?  You might have to reconfigure X and
>>>sound.  Windows XP?  Hah!
>>Right, with Windows, I often feel pretty much stuck...I'd like to be able to 
>>move packages from one drive to another, but it's not so easy, since the
>>Registry points to a specific drive, not an abstracted path...
>Supposedly they are going to begin to move away from drive letters in
>2003 and later.  Sort of.  Now I see things like \\HOST\C$\... instead
>of C:\...  Wow, yea, thats better.
Oh, piles! :)
I'd even like to see them go to the named device structure of VMS, which 
provided the abstraction needed without a lot of syntax changes.

>>Good software engineering starts at /home...
>Yep.
and /home is where the /etc/fstab says it is. Jeez, this is SO OBVIOUSLY
the right approach!


>>>>>Back in the day AIX was $1,400,  a comparable Windows installation with
>>>>>theoretically equivalent tools was about the same. (Early nineties, I've
>>>>>actually done that math).
>>>>OK, but what was the difference in the cost of the requisite hardware?
>>>You got it there.  RS/6000 530 - $57,000.  Compaq Presario - $2,100.
>>And in the past, the cash outlay was less favorable for the RS/6000.

>True, we got a steal on that RS/6000.  Before that there was a DEC
>16-way Z-80 based mini - for about $150,000. But management always,
>intuitively, understood the value of "real-time" processing.  Something
>a collection of PCs (or originally Eagle II CP/M machines) just couldn't
>provide....
If management understood that, they were a leg up on a lot of organizations.
Wall St. did catch on to these issues very early on, but they were forced
to do so. I recall writing apps that had to do this in the mid-70's.

>When user A moved part 123 onto a document, and user B checked
>availability four minutes later, they saw that everything in-stock had
>been sold.  Sounds really trivial by todays standard, but to management
>it meant never calling back and saying "Oh, hey, we actually don't have
>any of those." (And places like GM & Steelcase actually keep track of
>how many times their suppliers do that to them).
Actually,t his is the sort of thing that really got a lot of technology
off the ground, like shared file systems, networks, distributed processing,
messsage passing, etc.

>>>But, about ~100 people were using that RS/6000 at the same time I was
>>>doing stuff that would bring the Presario to the ground.
>>Sure, but you need those ~100 people to justify it. If you have 10 or 15
>>users, it doesn't look so good...
>True.  But if you have 10 - 15 users, your projects are probably also
>MUCH less abitious.
Hard to know... maybe it's true in manufacturing and more or less conventional
office situations. In big organizations, you can have workteams of this size
and smaller that form a user base for some pretty high-powered stuff. For 
example, when GM bought Hughs, there were about 10 people who worked on the 
data. *ALL* of the code was created in-house (no packages, other than progam-
ming tools), and no "user" wrote code (as in NO spreadsheets). The software
people were responsible for maintaining the integrity of the data and its' 
use, and the users told them what they wanted to model. This is intensive
stuff, but it goes on all the time.

The economics are different now. We did all that work on a mainframe, today
we'd be using midrange P4's, networked together. The overall approach would
be (and is) the same, since it served the needs of the business well. None 
of the costs really matter, since they are small compared to revenue and
the assets being handled.

It is INTERESTING that people in these situations are choosing Linux as their
platform. It is a chice that says everything about reliability and stability,
in places wehere cost is no object.

>>>$57,000 / 101 = $564.36 per user.
>>>$2,100 / 1 = $2,100 per user.
>>>Aren't we talking about TCO?  Yeah, you'd have to add $350 per user for
>>>a terminal.  So the RS/6000 came out at $914.36.
>>Which is a break-even at 32 users.
>Yep.  How many companies smaller than 32 users even have technology
>staff?
Assuming fairly ordinary IT requirements (accounting, order processing, 
e-mail etc., inventory, GL, office activity), probably about 25%, and
in rough times, or times of slow growth, that prson might be among the
first to go. Given the severity and depth of the current economic problems,
I'd predict it's a lot less than 25% at the moment.

>I think everything pretty much assumes 100+ employees, or even
>today, system and software providers really aren't interesting in
>talking.  We have ~500 employees and some places aren't interesting in
>talking to us.
This probably says more about the market and the degree to which different
firms are specializing, and interested in covering their overhead. Smaller
companies have fewer problems in that regard. I've worked for giant corpo-
rations, but I've also worked for 3-way partnerships, where it was clear 
that larger competitors couldn't afford to do the business.
 
>>We're also talking about something else, reliability and value. Will those
>>32 users get better service with AIX and the RS/6000 than with 32 Windows
>>machines? Will it cost less to administer? I think that in most cases the 
>>answer will be YES. This doesn't have a lot to do with AIX or UNIX per se,
>>but it does show the benefits of economy of scale, and where they kick in.
>>I think these numbers (and hence the breakeven point) is different today.

>I think the break even point may be much much lower.  At say the cost of
>12 PCs ($650 x 12 = $7,800).  So you could drop $5,500 on a server and
>still have $150 per desk for some type of thin device.
You're changing the numbers on me...we were working with number of a 
certain era; when $650 PCs didn't exist. OF COURSE I would expect todays'
breakevens to be lower.

I think that $150 for each thin client is a bit too thin. Even so, it only
raises the breakeven a little, not nearly back to 32.
 
>>>With twice the hardware and about $1,500 worth of software I could do my
>>>job on XP with no intense pain (other than actually needing to
>>>Edit->Cut, Edit->Past, all the time)....
>>Added labor cost? Also cost of added errors?
>It would certainly take more time to setup and upgrade.  And assuming
>all the software packages would play nice together.  I do still have
>problems on 2000/XP where software A has a hard time coexisting with
>software B - a problem I've never encountered on Linux/UNIX.

and something you may have less control over, too. Also, no guarantee
that it won't happen on the next upgrade. This raises TCO, since this
is a risk that has to be allowed for.

>>>...I really think the ongoing cost would be roughly
>>>the same, except for the annual upgrade fees.  But I don't use support,
>>>ever.  I have support contracts with IBM for hardware, and Informix for
>>>the RDBMS software, but nothing for PCs.  And I call on those contracts
>>>I have maybe once a year.
>>You are being unusually parsimonious with support, but you've matched what
>>you pay for with what you use, so that's good value. A lot of large organi-
>>zation self-support the PC stuff, 
>I don't even want to imagine what one would get if one tried to
>out-source PC support.  That way lies scary carnival death.
Well, you contract it all out, so you have PC technicians on-site, with a 
very limited charter to fix things, and it's all done at some fixed cost.
Risky? If the important stuff is on servers, not really. Quality support?
depends on how well the contracting comapny is run, who they can hire,
what margins they are willing to accept. It works, given some good head-
counts. Pfizer does this, as does Sears, Merill Lynch, etc.

>>and do similar with the bigger hardware...
>Right, we cover the heavy iron (RS/6000, bigger xSeries) with support
>and for things like Netfinity 4000s, etc... it really is cheaper just to
>keep a spare in the basement.
Yes, at very least, this is what THEY are doing, and they are marking it up! :)

>>>>Yes, I recall (early 70's) people telling me that something WAS NOT WORTH 
>>>>DOING if it took up more than 32 K... yes, that's K with a "K", not M. I
>>>>wroe a lot of stuff in 28 K work areas, and felt that the light of day and
>>>>the blessings of the diety [ies] shone upon me when I could use 128 K to 
>>>>do similar stuff.
>>>Was that 128k without bank switching?  Hallelujah is right.
>>No bank switching...this was on a MAINFAME.
>Nice, I hated bank switching.  I still get the twitches when I think
>about it.
I managed to avoid this stuff, too, primarily I spent most of my time 
working in high-level languages, on hardware that could support them well.

>>>>The last time I heard stories about doing plenty with no memory were as the 
>>>>USSR opened up, but before Western technology really got in there....
>>>Someone should go back to manufacturing the Commodore PET, just for
>>>training purposes.  Talk about agony.  OK, maybe we'll give then a
>>>KayPro II.
>>Absolutely. There are beneift to learning how to code on deficient platforms;
>>we sometimes think the 486's are to fast for this, but the guys who come out
>>of that program are writing NOTICEABLY faster code than others on contempor-
>>ary systems.
>What are you going to do when the last 486 dies? :)
You  should see OUR basement! :)
Actually, we have not had one die yet... oh maybe a couple of HDDs, but for
a few bux one can pick up used drives, and for all the value we get out of
'em, we'd buy new ones and stick 'em in the old machines.

							Regards,
							---> RGB <---