Technical Difficulties from on Top of the Mountain
  How I discovered my future
I learned about computers in the summer 1978. My father had used them previous at work, but I had no idea what they were, or that I wanted to spend the rest of my life playing with them. But thanks to a young school district that still had money after paying its teachers a pittance, the GATE program bundled me up in with 40 of peers on a school bus and sent me to Berkeley for a week. (GATE stood for Gifted ad Talented Education, a name they quickly had to come up with after we took the previous acronym: MGM and turned it from Mentally Gifted Minors into Mentally Gifted Morons, an insight that our slightly elevated intelligence was in some ways a hindrance in the social torture program society called school.)

So under the expert driving of our bus driver Dan "the oil pan man"*, we were whisked away to Lawrence Hall of Science for Astronomy, Earth Science, some other forgettable classes; and "Computer Lab". The computer lab was a giant concrete walled room, two stories tall, with rows of teletypes connected to a time share system, and a pen plotter at the far end.

teletype machine

We were shown how to log in, send messages to each other, access the central store and print out files (mostly ascii art), and create our own files. One of the files we could create, was a set of instructions for the pen plotter to draw a picture. Some of the other students drew their initials with it, or some interesting geometric shapes, but I had bigger ambitions.

Star was had come out the year before, so I wanted to draw space ships and laser fire. Major production value. Some how I got ahold of some graph paper, and drew out a ridiculously complex scene for a junior high school student with only a few hours to enter it in, and I spent every free minute I could typing in all the pen up/down and move commands to render my masterpiece. I get all the instructions typed in by the last day of the class, and command the printer to go, setting the pens to dance around and draw each segment painful step by step, when suddenly it all goes horribly wrong, and through some mistake in my instructions a large errant line is drawn across the entire page. There's less than 10 minutes left in the lab and the picture is ruined. I must have looked pitiful, because a sysop took pity on me and told me to follow him. We walked up the stairs to a mezzanine above where the sysops could watch over the room and do work. The sysop sat down and something completely strange which he referred to as a "glass teletype", opened up my file on the screen, pressed a magic key called a cursor key, and moved through the file to the line with the errant digit in it, which he replaced with the correct one I supplied, and then saved it.

glass teletype
I had never seen a mistake so quickly and effortlessly corrected. My picture printed out, correctly, though its since been lost to the sand of time; but more importantly after staring at that glass teletype, I knew with a certainty that I wanted to spent every possible moment of the rest of my life in that alternate universe where ideas could be constructed almost as easily as though, there was no entropy, and changes could be made in an instant. Looking back, it seems I have been fairly successful doing that.

* A story for another day, though I will give the hint that everyone on that trip learned that the lowest point on the underside of a bus is the oil pan, but he is the only bus driver who's name I can still remember 40 years later.


  Why we write.
I have written a number of stories, and have more still yet to write. Not expecting to become famous or rich, I write, as many others do, because its part of my nature just to want to tell these stories. As Ferris Jabr wrote in Harpers:
Stories sustain us: they open paths of clarity in the chaos of existence, maintain a record of human thought, and grant us the power to shape our perceptions of reality.
From The story of storytelling
Some days will be good, a few will be great.
Some days will be a step backwards, a few will be disasters.
A few days will be memorable, many will not be.


One must remember that no extreme will last forever, the market will not always go up, there is no such thing as the new normal.
Believing otherwise leads only to despair.

  Digital Hoarding
While I avoid most social media, I do enjoy Twitter for a number of reasons.  Not the modern form, but the 12 year old original invention:  144 character text messages sent to your phone.  This is very convenient for reading in the elevator or subway where there's no signal, and I can ignore them for days and they just pile up in my inbox.

Unfortunately I have accumulated a number of people I follow who are too interesting, and even after reading the initial message, I want to save the info for later to look into further.  One of the worst of course is @donpark who seems to have a great deal of free time to look into curious and interesting technologies of all sorts.  Cleaning out a previous phone that still had over a hundred saved notes brings up cool things like:
And that's just one person I follow over the span of about six months.
  The beauty of the proper design
After decades in the software engineering business, one can't read classic texts without getting mad.  Not because they were wrong, but because they were right, and nobody seems to have been listening.  This particular part about top level design from Mythical Man Month resonates with me dearly:
The process of step-wise refinement does not mean that one never has to go back, scrap the top level, and start the whole thing again as one encounters some unexpectedly knotty detail. Indeed, that happens often. But it is much easier to see exactly when and why one should throw away a gross design and start over. Many poor systems come from an attempt to salvage a bad basic design and patch it with all kinds of superficial relief.
Many a startup I worked on brought me in do just that kind of superficial patching.  At first I would present the need for deeper change to management, once I understood where the design had gone wrong.  Later I learned to avoid this waste of time, and occasionally succeeded in making the needed changes before the higher ups caught on.

Labels: ,

  Changing habits, one key at a time.
I first learned to program on terrible square key calculator like keyboards, but back then the computer only had a few kilobytes of memory, terrible offline storage options, and no serious editor. We still wrote BASIC programs every hour we could get access to the machines, and considered ourselves lucky.

On a lark, I went over to the business department at high school, and signed up to learn typing. This involved pounding keys on a manual typewriter, and occasionally getting access to the high technology of an IBM Selectric typewriter. (You could change fonts, character pitch, and at it even had a backspace.) Still, it was mostly about the the letters and numbers, and a few standard symbols above the numbers. Nobody was trying to type a |.

In college, things progressed to the next level. Mainframes had hard disks (wow), and you could type something one day, and come back on another day and it was still there. Changing existing files became as important if not more, than creating new files, and so I buckled down and learned a few home grown editors, as well as the up-and-coming, vi editor. The control key, and the escape key became very important keys.

My favorite terminal at the time, a beastly thing, called the ATT DMD 5620 had the control key right to the left of the letter A, and the escape key right to the left of the number 1. Very easy to get to, and quick to punch. For years, I worked quite well.

Unfortunately, along that time came the IBM PC. This ruined everything. The computer was naturally seen as a successor of their popular typewriters (see above), and they wanted to make things as familiar as possible for people moving from typing on their typewriters to typing on the PC, so instead of putting the control key to the left of the letter A, they put CAPS LOCK there. For a while I fought a slow retreat, re-mapping keys in X windows with XModMap, or trying to find various utilities for Windows, but as I moved from startup to startup, it became too much trouble and I gave in to reality that I was stuck with that layout. So for almost 30 years I have been typing on computer where the control key is banished down to the row with the space bar, far in the gutter, and the back tick and squiggle have invaded the spot to the left of the 1, with escape key floating up in the sky with the function keys.

But the mass market machine came to my rescue--sort of. Since the keyboard had been turned into a $10 commodity with cheap switches and a terrible layout, it had actually created a niche market for people who cared about the device they were typing on. And it turned out that a great deal of them were programmers. So not only were there better buttons and switches, but a number of options let you re-arrange things in the firmware itself (usually with DIP switches, because of course that's what you'd use, we're programmers after all).

So I am trying to fight decades of bad habits. I have new keyboards with configurable layouts (and LED backlights, because again, of course you'd have that), and I have moved my control key back to where it should have been all along. At the moment, it is terrible painful. I either have to think first before typing a control sequence, or if using muscle memory, activate the Caps lock accidentally. But I will persevere. I will retrain myself, and rejoin the lost universe, where the keyboard is a finely tuned instrument for the programmer to create the program.

  The next space age.
Today I got take the whole family up the road to Space View Park, where along with about a hundred other people, we sat in the shade of warm summer afternoon, enjoying the breeze until someone called out "TEN".

Then the whole cround started counting down,

And then, right across the river, a rocket lit up and lifted up. At first it seemed to climb slowly, and it was totally quiet. But then it passed through the low clouds, gaining speed, starting to leave a trail. As it started to grow smaller up high in the sky, the sound finally reached us. Starting as a low growl, and then growing louder.

We watched and listened for a few more minutes, then there was some applause from the crowd, and everyone turned to go.

A rocket that had flown before, now flew again into space and landed again on a ship out in the ocean, and not even for the first time. And my kids potentially have many more rocket launches to see this year. They thought the one today was pretty neat.

  Technological Stratum
If you're going to hitch your wagon to an evolutionary dead end, you better be good at fixing a flat.

geologic strata In the beginning (for the purposes of our story) was Unix and C. And it was good. You had your shell /bin/sh, the wonderful /bin/[ for all your filesystem commands, and anything else you just wrote a program for.

But as soon as there were more than a few users on a machine sharing a common login script, things got a little complicated. Add in the fact that Unix was designed to be portable, and you had scripts that were running in slightly different environments on different machines, and the need for some logic in these scripts became obvious.

For no understandable reason, the systax for these basic logic statements was bizarre,

    if [ "$uid" -ge 100 ]
      echo "Mere mortal"

As anyone who's moved from rails to node will tell you, having one syntax beats switching your mental model back and forth constantly. And it was no different back then. Programmers have been universally lazy since the dawn of time--that's why we have so many cool toys. So finally when one particularly impatient programmer had had enough, he decided that there should be a shell that used the same sort of syntax for control that the C programming language used. Thus was born the C shell, or csh for short.

Unfortunately that programmer went on to write many other interesting things, like VI, NFS and Java; and the shell was closely associated with Berkeley BSD, so it did not spread out as fast as a competitor written by David Korn at Bell Labs which became part of the System V distribution widely licensed or copied by such workstation vendors as HP, DEC, IBM and SGI.

Finally as the personal computer advanced into the Unix domain, Brian Fox at the GNU Project wrote a open source shell called Bash which again used a compatible syntax with bourne shell.

Not that csh didn't get any love, Ken Greer had been working on a TENEX like file completition library, and finally patched it into a version of csh which he called tcsh. It gained additional following when it was made the default shell for Mac OS X originally, though Apple later gave into popular pressure and changed the default to bash.

By this time however, machines were faster (megahertz clock speeds), bigger (megabyte memories, gigabyte hard drives), and could support more cycles catering to the user with actual interpreted languages which grew in leaps and bounds. In short order you had your choice of perl, python, tcl, php, ruby and more. And there was no longer any good reason to try and do anything serious in a shell script. A few people kept trying, but nobody took them seriously.

But there are those of us who had to get something done back before the dust had settled, and we picked the best tool we could, and we got as good at is as we good. And once you have your login script which customizes things you want it, there's really not a good reason to change it.

c shell field guide

So I still use csh, well tcsh so I can tab complete things once in a while, but my .cshrc was written many years ago, and except for changing the names of a few directories, its stayed about the same. But I know I'm out on the fringe, and someday the last of us will logoff, and tcsh will be nothing more that a curiosity that computer re-enactment history buffs play with on the weekends.

And when something breaks, your're mostly on your own.

Like it did a few weeks back at work.

I fired up my terminals for the week, like I do every Monday, but instead of showing my a welcoming prompt, the cursor just sat there like the machine was dead. Being the impatient programmer that I was, I hit the interrupt key (^C for mortals), and was rewarded with a prompt. Hmmm. Everything else looked normal, so I interrupted all my terminals and went on about my business.

There was more though. I went to kill a sub-tab in urxvt, and it just stayed there. Wasn't taking input anymore, but it wasn't cleaning up and exiting. Another interrupt character, and its gone. But its getting more annoying. The pattern kept repeating itself: create a new sub-tab, interrupt to get it ready; close the tab, interrupt to get it to go away.

Next week I come in, Monday morning and the machines rebooted, so I have to interrupt all my windows to wake them up. But I have other fish to fry, so I just get around it and go about my business.

Third week begins. I login--same situation. Ok, my extreme laziness now takes effect. Time to figure out what's going on.

First I hunt down all the scripts that the shell executes when it logs in and logs out. There's a different list for login shells, and non login shells are behaving just fine for me. Check out the scripts, run each of them manually, that's not the problem.

We're going to have to poke into the guts of the shell and try to catch it while its stuck. Back in the early days, the tool of choice was dbx, even for programs without debugging symbols or source. You could still observe basic call chains and if you were clever enough, even follow along in the assembly as the program went from one state to another. There was this one time at a client's site, a third party piece of software wouldn't start because it was trying to read an inialization file, and we had the file, we just didn't know where the program wanted it, so I stuck the program in dbx and put a breakpoint on fopen() and low and behold it was looking in /var/spool/x and so we moved the file there and it worked, and the customer thought I was pretty clever--but I digresss. Thankfully there are some better, more pointed tools at our disposal now.

I fire up a new instance of csh, because I already have two dozen instances of tcsh running in all my windows and I'm too lazy to isolate one to test with. Then I find its process ID and feed it to strace(1), which gives me this nugget of information:

    fcntl(6, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}

which is gibberish for stuck locking a file. Still don't know what file is being locked, but its a file that's being accessed at both login and logout.

A bit of creative searching lands me here,

Addressed in this update is the following issue:

When using multiple shells simultaneously, the command history is saved from all shells in one ".history" file ... This update implements file locking mechanism that uses shared readers and an exclusive writer to prevent the ".history" file from being corrupted.
Hmmm. Ok, I have a .history file, its zero bytes.

    rm -f .history

Problem solved.

Life in the middle of nowhere, remote programming to try and support it, startups, children, and some tinkering when I get a chance.

January 2004 / February 2004 / March 2004 / April 2004 / May 2004 / June 2004 / July 2004 / August 2004 / September 2004 / October 2004 / November 2004 / December 2004 / January 2005 / February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / May 2008 / June 2008 / August 2008 / February 2009 / August 2009 / February 2010 / February 2011 / March 2011 / October 2011 / March 2012 / July 2013 / August 2013 / September 2013 / October 2013 / November 2013 / December 2013 / December 2014 / February 2015 / March 2015 / July 2016 / September 2016 / December 2016 / April 2017 / June 2017 / July 2018 / November 2018 / January 2019 / February 2019 / April 2019 /

Paul Graham's Essays
You may not want to write in Lisp, but his advise on software, life and business is always worth listening to.
How to save the world
Dave Pollard working on changing the world .. one partially baked idea at a time.
Eric Snowdeal IV - born 15 weeks too soon, now living a normal baby life.
Land and Hold Short
The life of a pilot.

The best of?
Jan '04
The second best villain of all times.

Feb '04
Oops I dropped by satellite.
New Jets create excitement in the air.
The audience is not listening.

Mar '04
Neat chemicals you don't want to mess with.
The Lack of Practise Effect

Apr '04
Scramjets take to the air
Doing dangerous things in the fire.
The Real Way to get a job

May '04
Checking out cool tools (with the kids)
A master geek (Ink Tank flashback)
How to play with your kids

Powered by Blogger