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. > >No kidding? > >That's awesome!!! > >Manuel. 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? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author)
