Developers need IT skills

Often software developers can benefit from having skills typically found in IT support engineers.  For example I occasionally bring small embedded systems home from work since it makes working from home more productive.  It's hard to physically reconfigure equipment I've left at the office and the reset button is tough to hit across a VPN.  

In this scenario I need to be able to access the small embedded system on our home LAN as well as my build desktop machine which stays at work.  Having a VPN client which supports split tunneling makes this possible.  It requires that there be no overlap in IP addresses between the two LANs.  It also requires that I change the static IP address on the equipment I bring home to match the subnet which my home router uses.

The diagram gives a rough idea of how the split tunneling works.

Getting paid to solve puzzles

 

The thing I enjoy most about my job developing firmware for embedded systems is that it's a lot like being paid to solve puzzles.  Many of the projects I work on are just as challenging as the old text based adventure games such as Infocom's Zork series.

The datasheets which contain information about how the chips in embedded hardware are supposed to function can be challenging to decipher.  Vendors do their best but it's not unusual for the datasheets to either be incomplete or to contain subtle inaccuracies.  A chip I developed a device driver for recently had an accurate datasheet but the device driver gave the wrong results because of an issue with the C compiler for the ARM processor.  It turns out gcc for ARM CPUs does not support signed character types by default which this chip required.  Fortunately gcc includes a compiler flag "-fsigned-char" which allows this strange behavior to be overridden.

My worst technical interview

About 38 years ago I interviewed for a software job at GEISCO (GE Information Systems).  This would be my second software position after making the switch from field engineering.  It was a systems software position, writing software to run on one of their network nodes.  At the time GEISCO supposedly ran the largest private data network in the world

One of the engineers I interviewed with felt obligated to test my software skills by asking me to write a short program on his whiteboard.   The problem was most systems software was written in assembly language at the time.  I knew 4 assembly languages which didn't overlap at all with the assembly languages he knew.  Upon learning that we didn't share a language, I asked if he still wanted me to write a program since there was no way he could determine the correctness of my program.  Being a good corporate drone, he insisted that I still needed to complete this step so he could mark it off on the interview form.  So I proceeded to write some code in GMAP, the assembly language used by Honeywell mainframes since that was the one I was most familiar with.  I guess I talked my way through it successfully because I ended up getting the job.  

My program wasn't very functional as I wrote system software and it was rare for me to need to use system calls.  I definitely had never written a system call which performed any I/O.  I believe I loaded an immediate value into a register, performed a left shift, saved it into a memory location, and then ended the program with a MME GEFINI system call which terminates the current program.

Even though I first encountered GMAP assembly language 45 years ago, I still remember the numeric value for the opcodes of a number of the instructions.  Perhaps some day I'll once again need to know that a 235 opcode is a LDA instruction (load accumulator) but I'm skeptical.  There's a lot of old knowledge I'd love to be able to purge to reclaim the memory space.

Changing the oil

I changed the oil in my commuter car today, having grown tired of the "change oil soon" messages which started appearing on the dashboard about two weeks ago.  Changing the oil is something I learned to do from helping my uncle and grandfather work on cars when I was young.  It's much quicker and somewhat cheaper to do it myself than it is to take the car to the shop since you need to include the time spent driving to the shop and waiting for the oil to be changed.

The container on the left in the picture below which now holds used motor oil always makes me think of my grandfather.  It's one of a pair of 5 gallon oil cans I have which he used for delivering heating oil during WWII.  Several times when I've taken these containers to the county recycling center to recycle the used motor oil, people have asked whether I'd consider selling them.  These cans and the other tools I inherited from him hold far too much sentimental value for me to ever consider parting with them although the idea of some yuppie paying top dollar for something like that would have made Grandad laugh.

 

I'm always pleasantly surprised to see how easy it is to access everything on this car (a Chevy Equinox).  It seems every other vehicle we've owned for the past 20 years has placed either the oil drain plug or the oil filter in an awkward spot.  Some have gone as far as hiding them above frame cross-members which makes a huge mess when the old oil drains out.  I've tried all manner of do it yourself funnels to try to coax the oil into emptying into the drain pan with varying degrees of success.

Remote Desktop replacement

At work I have 5 Linux machines (1 desktop and 4 tiny embedded machines) and a Windows laptop in my office which I need to use.  There are KVM switches which would allow to connect my monitor, keyboard, and mouse to the machines in that large a setup but they're expensive and the cabling would be a nightmare plus I'd be stuck using just one machine at a time.  I tried using Remote Desktop and VNC to access the desktop of another machine remotely but that's cumbersome and it's slow across a VPN.  To be fair, there are situations when Microsoft's Remote Desktop works wonderfully across a VPN.  At my last job I used to use the Mac version of Remote Desktop to access my Windows laptop at work.  Since a Windows machine was the destination, Remote Desktop did a great job of data compression plus it allowed the client machine to arrange windows differently than they were arranged on my Windows laptop at the office.  So my old 27" iMac which has nearly 4k resolution gave me a better viewing setup than I had at work.

Now I use X11 (aka X-Windows) for accessing all the Linux machines I need access to.  Making this work requires a couple pieces of software.

First off, I need an X Server on my Windows laptop.  That is used to display the windows created by the remote Linux machine.  I use VcXsrv, a version of the classic xorg X Server but recompiled under Visual C++.  This recompilation allows it better access to Windows resources and I find it works better than any other X Server I've tried such as xming or cygwin's xwin.  VcXsrv needs to be run on your Windows machine prior to attempting a connection to another machine.

The next thing required is an SSH client which is capable of X11 forwarding.  That allows any programs launched using the SSH client to send their displays back to the client machine.  I use PuTTY, which has been around a long time and which can handle serial and SSH connections.

Once you've run VcXsrv on your Windows machine and then used PuTTY to connect to a Linux machine (taking care to first set the configuration to allow X11 forwarding), launching a remote program and having it display on your client machine is as simple as typing the program's name.  As an example you can try xterm which will create an X11 terminal window.  Just be sure to launch it in the background by appending an ampersand so the program is placed in the background.  Otherwise, your input and output will remain tied up by the program being launched.  The command to launch xterm this way would be "xterm &".

Favorite books

Since I love to read, people sometimes ask me about my favorite books.  I inevitably leave some out so I thought I'd collect them in an easy-to-find place.  So here are my favorites.

Favorite authors still actively publishing
Connelly, Michael - Harry Bosch series
Crais, Robert - Elvis Cole/Joe Pike series
Doctorow, Cory - Little Brother, Walkaway, Makers, and others
Gaiman, Neil - American Gods and anything else
Hiaasen, Carl - anything
Ide, Joe - IQ series
Kowal, Mary Robinette - anything
Scalzi, John - anything
Sloan, Robin - Mr. Penumbra's 24-Hour Bookstore and others
Stross, Charles - the Laundry File series
Taylor, Dennis E - Bobiverse series
Wells, Martha - Murderbot series


Other favorite books (sorted by author name):
Adams, Douglas - First two Hitchhiker's Guide books and Dirk Gently series
Asimov, Isaac - Robot series, Foundation trilogy
Dudley, John Ball - In the Heat of the Night
Ellison, Harlan - Dangerous Visions and others
Feynman, Richard - Surely You're Joking, Mr. Feynman!: Adventures of a Curious Character
Follett, Ken - Eye of the Needle
Goldman, William - The Princess Bride & The Marathon Man
Heinlein, Robert A. - The Moon is a Harsh Mistress and his juvenile series
Irving, John - A Prayer for Owen Meany
Kidder, Tracy - The Soul of a New Machine
Kipling, Rudyard - Kim, Captains Courageous, and others
Leonard, Elmore - Maximum Bob
London, Jack - anything
Miller, Walter M - A Cantical for Leibowitz
Niven, Larry - Ringworld
Noah, Trevor - Born a Crime: Stories From a South African Childhood
Parker, Robert B. - early Spenser novels, Jesse Stone series, Virgil Cole/Everett Hitch series
Pullman, Philip - His Dark Materials trilogy
Robinson, Spider - Callahan's Crosstime Saloon series
Sayers, Dorothy - Lord Peter Wimsey series
Shute, Nevil - Trustee from the Toolroom
Sturgeon, Theodore - More Than Human and all others
Tolkien, J.R.R. - The Lord of the Rings trilogy
Twain, Mark - anything
Vonnegut, Kurt - Slaughterhouse Five and all others
Weir, Andy - The Martian
Winters, Ben H - The Last Policeman trilogy
Wodehouse, P.G. - Meet Mr. Mulliner and others

Favorite graphic novels (sorted by author name):
Ennis, Garth - Preacher, The Boys
Moore, Alan - Watchmen, V for Vendetta
O'Malley, Bryan Lee - Scott Pilgrim's Precious Little Life
Vaughn, Brian K. - Ex Machina

GNU Screen can make SSH sessions persistent

 I do a fair number of Linux kernel builds at work.  Doing a Yocto build for our target machine takes about an hour and 40 minutes for a the build to complete and the root filesystem to be prepared.  If I do that from home, there's a chance that I'll get a hiccup on my VPN connection which might disrupt the build in progress.  Even at work, I ssh into my Linux build machine from a Windows laptop and use xterm sessions for most of my development tasks.  If I kick off a build before heading home, there's always a chance that Windows will decide to do an update which could also disrupt my build.

Fortunately GNU Screen can make your sessions persistent through disruptions due to network disconnections or other reasons.  Now I make sure to start a GNU Screen session before doing my build.  I start named screen sessions with a command such as "screen -S build".  That way, if my session is disconnected, I can rejoin it with the command "screen -r build".

The one thing I don't like about GNU Screen is its default escape key, Control-A, since that interferes with the default Emacs command line editing mode in Bash.  So I've created a ~/.screenrc configuration file with the following command to change the escape key to Control-T.

escape ^tt