Technical Difficulties from on Top of the Mountain
  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.

  Checking those spinning hard drives.
From Windows 7 command prompt:

wmic:root\cli>diskdrive get status

Well, ok then.

From how to geek

  The past is so strange, its almost hard to imagine.
My co-workers were complaining about printf() being named poorly, because in these modern times, the function doesn't cause a "printer" to do anything. Sadly I immediately knew what the problem was--perspective, and not because I'm super good at studying history so I can learn from it. I'm just old enough that I remember when things changed.

I was there when you still dialed a phone, because the phone had a "dial" on it. I was there when to send a letter to two people, you had to type the original on to two pieces of paper with a piece of carbon paper in between in order to make a "carbon copy". (Later shortened to just cc.) And I was there when a computer would "print" your program output onto paper as you ran it.

Computers are amazing, and the technology that's gone into them over the last 75 years has progressed at such a pace, that without being there, its almost hard to believe how limited, difficult, and just different things used to be. Just look at what was considered state of the art in smartphones 10 years ago:

So wind things back a little further, to the beginning of the interactive computer experience, and you'll find a bunch of these:

This was a Teletype, a machine for encoding typed characters either onto a paper tape (don't worry, they're long gone), or with the dawn of time-share, directly sending characters to a mainframe. The output would come back over the line and print on the giant roll of paper, thus a key command in many languages (including BASIC, C, PERL and so many others) was PRINT, or in the case of C, print with formatting ... printf().

The core of the teleprinter was a marvel of engineering, but again maybe not what you might expect, it was almost entirely mechanical:

In fact, the teleprinter wasn't even originally designed for computers, instead two of these devices were connected together between remote locations, and an operator would type a message one one, while the same message would be output onto the second, like telegraph but simpler to operate. But like many other technologies, teletypes were co-opted into computing, and shaped it greatly. Given its slow speed for both sending and receiving characters, Unix creators choose to keep basic commands as short as possible, and we still remember a host of two digits commands for navigating and operating on our filesystems (cd, ls, rm, df, mv, cp, you get the idea.)

So the next time you go to write a print statement, just remember, once apon a time, that's exactly what those first programmers were doing.


  Its the little things.
For some reason my new car only has two places you can open it with a key, despite having five doors.

Other than providing a struggling Hollywood writer with an interesting plot point for the 8,000th episode of NCIS and saving Toyota $2 in costs on a $60,000 car; I can't really think of a good excuse for the passenger door not to have a place to open it with a key.


  Its the little things.
For some reason my new car only has two places you can open it with a key, despite having five doors.

Other than providing a struggling Hollywood writer with an interesting plot point for the 8,000th episode of NCIS and saving Toyota $2 in costs on a $60,000 car; I can't really think of a good excuse for the passenger door not to have a place to open it with a key.


My three older kids are past this point, but with the twins now three, such phrases have begun to bounce around in my head again...

sweet and sour
about an hour


Oh well, that's parenthood I guess.

  The power in thinking about hard problems.
I am an engineer by trade, not a scientist, because I have a certain amount of impatience with thinking for thinking's sake.  But as I have spent great amounts of time solving simple problems, I have more and more appreciation for big thinking.  It can be a great place to go steal ideas to use tomorrow.

feynman One big thinker was Feynman.  He made many contributions to Physics, finding ways to solve problems that were intractable with traditional tools, but he was also curious about a great many things and was able to predict the future just by wondering about what would happen if you took things to their extremes.  He had predicted molecular machines (or MEMS) by just thinking about a serious of 10:1 reduction levers that just kept getting smaller and smaller.  But it turned out he also had been pondering the future of computing and its intersection with physics way back when.

The thread for this started from watching the quantum computing talk (LIQUi) from LangNext 2014: (channel9)

There was a reference to a list of publications at the end of the talk with a link: Search Results for Dave Wecker, and skimming through the paper 'Improving Quantum Algorithms for Quantum Chemistry', I noticed that the first paper was by Feynman: "Simulating physics with computers".  This actually was a keynote talk at a conference in 1981, but back not everything got recorded for uploading to youtube, so you'll have to be satisfied with a scan of the original paper (or you can pay $40 to Springer Publishing to get a copy of the transcript for which they paid nothing.)

Basically, almost 40 years ago, Feynman did the thought experiment about whether you could simulate quantum physics--and to be complete he considered both classical discrete computers as well as then non-existent quantum computers.  Short answer?  Classical computers would never be able to tackle big enough problems in a scalable way, but if engineers ever figured out how to build usable quantum computers for the physicists to use... well, we might just be in for more interesting times.

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 /

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