Frustrating technologies
I saw an article the other day that asked how we know we live in the real universe and not in an elaborate simulation, a Matrix-like virtual reality. To me, the answer is that every attempt at imagining a world, from the earliest novels to the newest movies and video games, has inconsistencies, discontinuities, or anachronisms. Every piece of software ever written has at least one bug. If we lived in a simulation, we'd see such things in every day life. Miracles, we'd call them. But there aren't any miracles, edges, seams, or limits in the real world. It goes on forever, seamlessly, and every attempt we make to get to the bottom of it reveals still more. Columbus's ships didn't go over the edge. The world is not hollow, and no one has touched the sky.
And the world works smoothly. It doesn't crash or run out of memory. It never needs rebooting; its batteries never need charging, and it doesn't have one of those switching power supplies whose capacitors eventually dry out. It won't catch an update from Microsoft that suddenly breaks some critical function, and its software never outgrows its hardware.
From an early age, I've been interested in technology. I watched on my parents' TV as John Glenn was launched into orbit. I followed the Gemini and Apollo programs with great interest, and Wernher von Braun was one of my heroes, even if he later turned out to be an SS-Sturmbannführer. I built my own Estes rockets and even competed in the National Association of Rocketry's NARAM-13. I became a ham radio operator. I discovered computers, in the form of an IBM 2741 Communications Terminal connected to an IBM 370 mainframe, at the age of 15.
I was a teenage computer hacker, back in the days when computers cost millions of dollars, required legions of white-coated attendants, and lived in giant air-conditioned rooms. I mastered FORTRAN, COBOL, PL/I, APL, and the IBM 029 card punch. In college, I stood amazed as I watched someone on a computer in Cambridge, Massachusetts, connect to another computer in Berkeley, California, via something called ARPANET. I never imagined that some four decades later, the same network, now called the Internet, would be so important in our lives.
After college I began a career in radio. It was all analog in those days: vinyl records, reel-to-reel tape, and NAB tape cartridges that resembled 8-track tapes but had only two audio tracks and a cue track. Transmitters and even some audio equipment had vacuum tubes. One station where I work still has a transmitter with tubes, a venerable Gates BC-1J, built in 1955. But it's only a backup.
Analog technology had its frustrations, for there are myriad subtle ways in which analog technology can fail. "The sound has no balls"; "there's no low end"; "the horns sound like kazoos." But those frustrations were almost entirely for us technical types to cope with; the average user found analog technologies very easy to use.
Today I often find myself dealing with digital technologies and user interfaces that are anything but intuitive. How should I know I'm supposed to press F12 to bring up the screen that lets me record a new cut for airplay? It takes me ten minutes to figure out how to reset the clock in my car radio every spring and fall. I am repeatedly bombarded with questions by ordinary users who can't get through a simple Web site registration.
Why does Windows often require a reboot after the most trivial update? It's because of Windows file locking, designed to prevent one process from modifying or deleting a file in use by another process. Windows file locking is primitive, reflecting the fact that Windows evolved from DOS, which only allowed one user to do one thing at a time. Linux and MacOS, by contrast, evolved from UNIX, which was designed from the beginning to be multi-user, multi-tasking. In Linux, you can do anything to any file (if you have the right permissions), and the operating system will sort everything out.
Windows file locking used to take one of my clients' stations off the air. It happened during Boston Celtics basketball broadcasts: the network would signal for a commercial break, and the station's computer would play the commercials, after which the station went silent instead of going back to the game. It didn't do that all the time, only once a month or so, and I tore my hair out trying to figure out why this Thursday's game had a problem and last Thursday's didn't. It turned out that the station was trying to record ABC News headlines during the game, and if the news was already cued up and waiting to run when the record command came down, Windows wouldn't let the file be opened, and the software would crash. The software developers whom I contacted couldn't figure it out, and it took me a couple months to do so.
Right now I'm trying to figure out why a backup process that has been running every night for eight months is only backing up a few of the files. This isn't running under Windows, but under Linux. And while I'm watching it, it seems to be performing flawlessly. But when I check the backup repository, nothing is being written there.
In the immortal words of Joss Whedon: grrr, aaargh.
And the world works smoothly. It doesn't crash or run out of memory. It never needs rebooting; its batteries never need charging, and it doesn't have one of those switching power supplies whose capacitors eventually dry out. It won't catch an update from Microsoft that suddenly breaks some critical function, and its software never outgrows its hardware.
From an early age, I've been interested in technology. I watched on my parents' TV as John Glenn was launched into orbit. I followed the Gemini and Apollo programs with great interest, and Wernher von Braun was one of my heroes, even if he later turned out to be an SS-Sturmbannführer. I built my own Estes rockets and even competed in the National Association of Rocketry's NARAM-13. I became a ham radio operator. I discovered computers, in the form of an IBM 2741 Communications Terminal connected to an IBM 370 mainframe, at the age of 15.
I was a teenage computer hacker, back in the days when computers cost millions of dollars, required legions of white-coated attendants, and lived in giant air-conditioned rooms. I mastered FORTRAN, COBOL, PL/I, APL, and the IBM 029 card punch. In college, I stood amazed as I watched someone on a computer in Cambridge, Massachusetts, connect to another computer in Berkeley, California, via something called ARPANET. I never imagined that some four decades later, the same network, now called the Internet, would be so important in our lives.
After college I began a career in radio. It was all analog in those days: vinyl records, reel-to-reel tape, and NAB tape cartridges that resembled 8-track tapes but had only two audio tracks and a cue track. Transmitters and even some audio equipment had vacuum tubes. One station where I work still has a transmitter with tubes, a venerable Gates BC-1J, built in 1955. But it's only a backup.
Analog technology had its frustrations, for there are myriad subtle ways in which analog technology can fail. "The sound has no balls"; "there's no low end"; "the horns sound like kazoos." But those frustrations were almost entirely for us technical types to cope with; the average user found analog technologies very easy to use.
Today I often find myself dealing with digital technologies and user interfaces that are anything but intuitive. How should I know I'm supposed to press F12 to bring up the screen that lets me record a new cut for airplay? It takes me ten minutes to figure out how to reset the clock in my car radio every spring and fall. I am repeatedly bombarded with questions by ordinary users who can't get through a simple Web site registration.
Why does Windows often require a reboot after the most trivial update? It's because of Windows file locking, designed to prevent one process from modifying or deleting a file in use by another process. Windows file locking is primitive, reflecting the fact that Windows evolved from DOS, which only allowed one user to do one thing at a time. Linux and MacOS, by contrast, evolved from UNIX, which was designed from the beginning to be multi-user, multi-tasking. In Linux, you can do anything to any file (if you have the right permissions), and the operating system will sort everything out.
Windows file locking used to take one of my clients' stations off the air. It happened during Boston Celtics basketball broadcasts: the network would signal for a commercial break, and the station's computer would play the commercials, after which the station went silent instead of going back to the game. It didn't do that all the time, only once a month or so, and I tore my hair out trying to figure out why this Thursday's game had a problem and last Thursday's didn't. It turned out that the station was trying to record ABC News headlines during the game, and if the news was already cued up and waiting to run when the record command came down, Windows wouldn't let the file be opened, and the software would crash. The software developers whom I contacted couldn't figure it out, and it took me a couple months to do so.
Right now I'm trying to figure out why a backup process that has been running every night for eight months is only backing up a few of the files. This isn't running under Windows, but under Linux. And while I'm watching it, it seems to be performing flawlessly. But when I check the backup repository, nothing is being written there.
In the immortal words of Joss Whedon: grrr, aaargh.