On Tuesday 01 April 2008, Manuel Aróstegui wrote:
On Tue, 2008-04-01 at 17:31 +1030, Tim wrote:
> Back when I were a lad, we didn't use no debugger. We'd print the code,
> and attack the printout with pencils out to mark all the bugs and
> corrections, then type the changes back in.
You are easily impressed I take it. That's exactly how I wrote code for an
application that involved commercial video tape preparation for on air use
with a very early automatic station break machine. For an RCA 1802 cpu,
where I didn't even have an assembler, I was looking up the hex code in the
programmers manual and entering it with a hex editor. This was in 1978. I
also built the Quest Super Elf 'computer' from a kit that it ran on, and all
the interfacing hardware including the video to control the then state of the
art Sony 28xx u-matic video tape machines. I used less than 2k of the 4k of
static ram it had, and which cost nearly 400 dollars then. That code, and
that machine were still in use at that tv station in Redding CA, in 1994, and
they had no plans to replace it with something newer then! When I went on
down the road, I left a paper copy of the code, with instructions on how to
adjust its timing to match the motion ballistics of any newer machine they
hooked up to it.
The next time I wrote code with an extended lifetime like that, was on a
TRS-80 Color Computer running OS9 level 1, with device drivers in assembly
using an assembler, and the main portion in Basic-09. That function was in
place of a $20,000 Grass Valley Group E-DISK package that our first GVG
300-2A/B production video switcher didn't come with. It outperformed that
$20k unit by 4x in speed, and gave the operators english language names for
their individual 'bags of tricks' files whereas the GVG used 2 digit hex
codes for the filenames. That was in 1989, and was used continuously to 2003
when that switcher was finally replaced with something a little 'greener'.
Because I could each into that switchers data paths so easily with it, there
were many times that to troubleshoot the switcher, I would reach into it with
little 10 line code snippets and tickle a specific function to see if it was
working correctly, and based on its responses, go replace a failed chip to
restore a failed operation.
That's code with long, useful lifetimes. You live intimately with it day
after day, fixing the glitches until there are no more bugs left to fix, it
Just Works(TM). How long does perfectly good code last today? Maybe 3 years
till its thrown out like the baby with the bath water for some reason this
now old fart fails to grok.
I'll give you mplayer as a perfect example. Or xmms, just to name 2 apps that
because they worked so well, now seem to be something bad, and must be
replaced with something that doesn't work, like pulseaudio, whatever the hell
it is, apparently just to give someone a new container of bugs to fix,
whatever. All I know is that since I had to re-install due to a failed drive
over the weekend, the only noise I get is the system beep, and my machine
will be otherwise mute until I rip it out again. We put that on cornfields
in Iowa to grow taller corn.
What is the usual fix for the pulseaudio induced silence?
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)