If it wasn’t for readers, writing would be a lot easier.
Year Nine
In my forty-odd years of employment, I kept a list of things I wanted to do, but for reasons of expense or time, I had to put off. “Fly an airplane” was one of them. “Write a novel” was another.
When I retired at the beginning of 2015, I reviewed the list.
Some things were immediately struck off. “Travel and see the world” went away because, in my work, I’d pretty much done that. While I haven’t trod every square inch of the planet, I have been lots of places. Some I would re-visit–Singapore was fascinating, the highlands of Scotland still beckon, and the Gulf Coast of the US remains one of my favorites for seafood as well as the North End of Boston–but, for the most part, I will forego the travel to avoid the interminable airplane sits, drafty airports, and the challenges of foreign customs and languages.
I attempted some prioritization. “Flying an airplane” shifted down toward the bottom for a couple of reasons. While I would enjoy the technical and mental challenges, I’ve found that its the “being there” that I like, not the “getting there.” Traveling at private airplane velocities is slow, sometimes bumpy, and for much of what would be in range, I’ve already been there and done that.
I then began working my way through the list.
Some were accomplished fast. “Put our long-term finances into capable hands” required some research, consultations, and careful study, but was completed within a couple of months. Nine years later, I am confident we made a pretty good choice. Barring unforeseen disasters, the collapse of our financial system (!), or outright nuclear war, we’re gonna be Okay. Not rich, mind you, but Okay.
“Write a novel” made it to the top of the list in short order. And it’s stayed there for all of this time. In the process of doing that, I discovered that writing fiction is a totally different skill than writing non-fiction such as this blog, or the training materials I helped create during my employment.
Some days I work on that goal for just for a few minutes. There are still bills to pay, grass to cut, and slowly increasing medical diversions to the otherwise “best laid plans of mice and men.” (Cancer took a big bite out of our lives a few years into retirement, but we’re both done with that [for now] and the consequences have only small effects on us now.)
Some days, I find myself immersed for hours in a fictional world with letters spewing from my fingertips into the computer. When I’m “in the flow” as writers call it, having to stop and go take care of a different flow is a major annoyance. My neighborhood coffee shop is great for writing, but their single, unisex bathroom can leave me dancing in place for someone else to vacate.
And the education continues: I’m still learning how to write fiction.
Some things in the list will, I can see from this vantage point, never happen. To put it directly, the time has passed. Accumulating the 1,000 points needed for “Mountain Goat” status in amateur radio’s SOTA (Summits On The Air) program isn’t gonna happen. While I may garner some dozens of points by hiking up mountains worth from 1 to 10 points and, once there, setting up a ham radio station with what I’ve carried on my back, and making four, two-way contacts, doing that more than a hundred times will exceed my physical limits.
But the other side of that coin and staying home to be the other end of those contacts, through that I could gather a different 1,000 points and be awarded “Shack Sloth” status. That remains do-able. I’ll need to advance my morse code speed from the 15 words per minute I learned decades ago which has since decayed and “get it up” to 25 or so. But I can do that. Practice makes perfect, they say. That’s do-able.
What else is on my list?
Suffice to say, not only lots of things, but also an increasing number of them. As the world changes, new opportunities arise.
Cheap computing is a reality. Raspberry Pi computers are well under a hundred bucks, and I have lots of experience with the Linux that runs on them. And I know “hard real-time,” again from my career time, and my training in electronics—Ohm’s Law, transistors, ham radio and all that—mean I have the knowledge to do interesting things with the even more affordable Arduino platform. While I won’t be creating robots the likes of which you might have seen at Boston Robotics, I lack only the priority in my daily schedule to build things of that ilk.
What’s on your list?
Are you satisfied with merely flipping channels and barking complaints at politicians and news anchors who can’t hear you? Or are you out there doing something about it?
While you probably can’t unseat a President or prevent a newly elected one from moving into the White House, you can use gentle, patient persuasion—covert manipulation, let’s call it—on your friends and family to try and bring about change. They say that, in the long run, it’s the little changes that really make a difference.
So, write a few words today. Listen to a friend. Give someone a hand, or peer over your glasses at them with an obviously skeptical look to some outlandish, unfounded, and patently false statement they’ve made.
The world is still my oyster. And there are more pearls to find.
Chopstick Dexterity
Image licensed as Creative Commons by https://commons.wikimedia.org/wiki/User:Marcosticks
If the Dems had their way, they would be the only party. They’d tell you who the candidates are and you’d be allowed to vote for (only) them.
That’s how it works in China. The CCP (Communist Chinese Party) chooses the candidates in local elections, and then “the people” get to vote for (only) them.
In the US House of Representatives, the party that’s in the majority (was Dem, now Rep — this’ll be interesting) elects the “President of the House.” (FYI: That person is in-line for the US Presidency in case there are vacancies due to death, etc.) The majority party nominates candidates for the “Presidency of the House” and then your Representatives—435 of them—vote to elect one from amongst their membership.
Every five years in China, the general meeting of the CCP—about 2,000 elected members, see earlier herein—convenes. They elect their leaders from a ballot offered by the CCP. (Note that the CCP is led by the existing leaders, so it is they who specify who will be on the next ballot.)
The Chinese government, of course, strictly regulates the press and internet within their borders. It’s “their way or the highway.” Censorship is common, is “built-in” to websites and social media there, and happens without any knowledge by the general public. (If you want your social media site to be used in China, you must conform to the CCP’s dictates.)
The coverup Elon Musk is revealing (about Hunter Biden’s laptop) is about US government censorship (by the Presidency, the Dem party, the FBI, DOJ, etc.) of Twitter posts (on the internet). Because of the volume of posts, what began as manual intervention has been escalated to “built-in” to Facebook and most other social media.
One big difference is their versus our Constitution. Their Constitution is easy to change, and the CCP has done so repeatedly. What used to be several different high offices (Chairman, Premier, President) that had to be different people and with limited terms has been changed so one person, Li Jinping, now holds all of those powers, and can do so for life. China’s Constitution was drafted (by the CCP) to facilitate change.
The US Constitution, unlike China’s, is very difficult to amend. It is made that way for the same reason that the Legislature (House and Senate) can overrule the Executive (President and Vice President), and the Judiciary (the Supreme Court) can negate the efforts of the other two branches. The US Constitution is intended to impede change.
We have become much like China, and continue to become more and more like them.
Are you practicing your chopsticks yet?
Censorship
In China, I discovered how their government let’s you hear only the news they want you to hear.
In America, if you’ve haven’t heard about Elon Musk’s Twitter revelations, the reason is the same.
(Screenshot from https://rsf.org/en/index)
Computers Lie and Cheat
In the 70s, we had a Scrabble game where I worked, probably on an IBM 360 mainframe running VM1 or similar. The program may have come from what is called netnews, a very early and nerdy-type of what is now called social media.
The computer’s play was excellent and rarely beatable, so much so that I decided to look at the source code.
If you’ve played the board game, you’ll remember that each player draws seven tiles from a pool of face-down letters. When it’s your turn, you figure out a word (must be in Merriam-Webster or some other previously-agreed-upon dictionary), play it on the board, tally your score, and then draw replacement tiles from the pool.
But the computer doesn’t know English or any other human language so the program had to have a built-in dictionary of words for it to consult when playing its tiles. That built-in dictionary included many large words with lots of high-scoring letters as well as shorter and simpler ones.
Looking at the word-choice algorithm where the computer searched that dictionary against its letter-tray for the best-scoring word, there was a short segment where it compared the computer’s score to the players. That was rather odd because that comparison had nothing to do with actually finding the best word to play. In fact, the code already knew its best play for its seven tiles.
Further study revealed that if the player was ahead by some percentage and could not be overtaken by the computer’s best word, the program swapped out its complete tray of letters, drew seven new ones from the pool, and then repeated the search and score comparison. This continued until the computer “found” a really great play that would give it the lead.
The computer cheated!
That was the first, but not the last, instance of computer malfeasance I’ve encountered. Over several decades in the computer software business, I’ve run into a small number of other wrong-doings, usually to perpetrate the theft of goods or funds, that had been clandestinely programmed into “production” software. In some cases, the thievery amounted to hundreds of thousands of dollars, and the corporations rarely called the police or any other law enforcement entity. Their reasons were 1) it was embarrassing, 2) the loss was covered by insurance, and 3) “if we told people about it, more would try.”
But let’s be accurate: the computer is not cheating. Someone programmed it to do that.
Programmers are problem solvers. Figuring out how to cheat the system is a challenging problem that some may occasionally relish but few will admit.
Another “hack” is famous in the Unix community. As you’ve no doubt experienced, when you login to a computer, you are asked for a username and a password. The computer then checks them against the authorized list and you are admitted or refused.
The login algorithm and its list of usernames and passwords must be carefully scrutinized for possible errors (or cheats), and usually by several, independent people. Only when everyone has studied the code and pronounced it safe will it be put into production.
Ken Thompson, one of the early Unix programmers, wanted to give himself a backdoor into the computer. That’s a username and password that will always work, no matter what. Normally to achieve something like that, the login program would have to be hacked–corrupted to always admit that one login–but with many people checking the code for any such infraction, it would seem to be impossible.
Ken, however, was also responsible for the compiler. That’s a separate program that converts the source code into executable binary. And it’s then the binary that actually runs on the computer and authorizes logins.
To create the backdoor, he added code to the compiler to recognize the login source code, and when it was being compiled, his addition would “insert” his secret back door credentials automatically. The resulting binary contained his addition, the backdoor. (Security checking of the compiler was not considered a requirement because it was big, and ostensibly, it had nothing to do with computer security. Hence, nobody looked.)
Ken’s “hack” is actually implemented via a second-level and even more devious trick. For additional details, you can read his somewhat lengthy description, or a much shorter one with fewer details.
- Ken’s description of his “cc hack” and related issues. (Click to read.)
- A shorter but just as interesting description. (Click to read.)
In the decades since, programmers have come up with a great many new, clever, lucrative or damaging, depending on the intent, cheats for computers.
When someone tells me “the results are accurate because a computer tallied it,” I know from first-hand experience that is no proof. And like when a child tells a lie, the more it is repeated, the more suspicious I become.
The Antagonist’s Plan
Stories are usually focused on one character called the protagonist. Readers see through their eyes, experience their emotions, and thereby escape their problems for a little while. Such is the attraction of good fiction.
For the majority of these stories, that person–the protagonist–is, in fact, a puppet. He or she is yanked this way or that by someone else’s design. The protagonist is battered by external forces, and that force comes from the antagonist, be it a person or an ephemeral, sometimes self-destructive, quality.
Many books on fiction will tell you that most commercially-successful novels (and movies) have a relatively simple structure. Whether it’s a James Bond spy novel, a historical romance on the moors of nineteenth-century Devonshire, or a hack-and-slash murder mystery in downtown San Francisco, the story will have three key points, and they occur at remarkably predictable places in the story as measured in page count or movie minutes.
These three points are variously described as 1) Inciting Event (often on page one or in the first minute of the movie) that propels the main character out of his/her normal world into a new adventure, 2) a momentous event that, again, deflects the main character from one path into another, and 3) a final, earth-shattering moment in which he or she commits to either defeating the opposition, or dying in the attempt.
All three points occur within steps of the antagonist’s preconceived plan. The antagonist, be it a he, she, or the inner daemon, has planned this all out ahead of time. And like anyone focused on a distant goal, the antagonist simply squashes anyone or anything to keep that plan on track. To the antagonist, the opposition is a pesky annoyance. Like a biting ant, it must be dealt with, and a simple slap or brush of the hand will suffice.
So, as a writer, where do we begin? How do we come up with a story?
Many say it starts with a “what if?“
- What if that couple with the baby outside the coffee shop are Chinese agents intending to steal industrial secrets from a semiconductor manufacturing facility north of town.
- What if the man carrying two paper cups of coffee out the door intends to add rat poison to one before giving it to his freeloading but rich brother-in-law whose sole benefactor would be his married-to-the-good-guy sister?
- What if that white Mercedes SUV with Texas license plates that just pulled into a parking space in front of the coffee shop was stolen in Fort Worth two days ago, video-taped in a bank holdup in Albuquerque yesterday, and the cops are about to converge on its heavily-armed occupants?
While the protagonist may be mentioned, what we see in these three imaginings are the bad guy’s plan. Any changes they precipitate in the protagonist’s life are superfluous. They are, to the baddies, noise.
Many of the books on writing suggest you begin the development of a story with that idea, with that first “what if,” and then expand it, come up with the next “after that, what if this then happens?” And then what after that?
The problem with this approach is not recognizing that what you (the author) is doing has little or nothing to do with the good guy. Instead, you’re making up the bad guy’s plan. You, the author, must get into the bad guy’s head and plan the crime!
The good guy, inserted after the fact, just appears in the wrong place at the wrong time.
Squish!
Let’s call this what it is: Writers of fiction make up plans to steal industrial secrets, murder an in-law, and to rob banks.
Talk about vicarious living!
And once that evil plan is complete, we then plunk down some poor schmuck at an inopportune place and time such that it annoys the baddies. And like that biting ant, they swat or brush him aside, and then go on with their plan.
Story is born from evil.
And it has a plan!
Two Kinds of Writers
I see two kinds of writers at the writing groups I attend.
First and most common are the ones doing personal therapy. (Please note: I don’t intend any disrespect; I’ve been there and done that myself.) The goals of these writers include the revelation of daemons, learning where they came from and how to temper their often negative contributions to one’s character, and–to the writer’s end–finding rich fertilizer to pile on future plantings.
The second faction are the money-and-fame writers. They are chasing readers, not inner monsters. Their focus is on what will sell, and they ask, “What will grab and hold the reader?” What they know of themselves powers the “write what you know” dictate.
I will venture to guess that every one of the #2s were #1s previously, and that many of them alternate between inner delving to understand the forces within their psyche, and then incorporating those lessons in commercial fiction that will sell.
My only suggestion to the #1s is, until you understand that you’re a prostitute with something to sell and that you need to suggest what your John’s lust for, until you get that, save your navel contemplations because that’s where they have value, albeit not a monetary one.
The ghouls and devils within you will intrigue readers who will pay money and put you on a pedestal, but there’s story, and character, and plot, and a bunch of other things to craft into the work.
Telling A Lie
Words mean things, specific things.
A “lie” is when someone knows otherwise but chooses to intentionally deceive others.
That’s not the same as believing or hoping something and saying so. That’s not telling a lie.
And when those beliefs are challenged but the person sticks to their guns, that also is not telling a lie.
To be a lie, they have to know it’s a lie.
Joe isn’t lying because he doesn’t realize that what he’s being told to say is not the truth. Rather, he is being deceived, and is incompetent to realize otherwise. I pity the man.
And Trump isn’t lying because he believes something that others do not. He is being true to his beliefs. I honor his integrity.
Finally, when I read a news report that refers to “Trump’s lie” about the election, I know I’m reading the words of a biased reporter.
You and I are free to believe as we will about the last election. We can pick and choose the facts we like, dismiss opinions as we feel appropriate, and read-into people’s actions whatever intent we may.
But when a news report begins adapting, modifying, and mis-using the English language, I have to take exception.
It is not a lie to state what you believe to be the truth.
Cooking Up Plutonium-238
Somewhere between 1995 and 2000, I was sent to teach a pSOS+ class to Westinghouse engineers in Savannah, Georgia.
At the time, the debate between Assembler-language versus C for application programming was still hot and heavy. Programs written in Assembler took longer to develop and had more bugs to detect, ferret out, and correct, but once the code was correct, it ran with record speed. C language programs, on the other hand, were quicker to write and debug, but inherently slower. The pSOS+ RTOS was written in Assembler and intended for application programs written in that language. As such, it was faster than any of its competitors, most notably Wind River’s VxWorks.
The name, VxWorks, is a contraction of VRTX and “with the works” alluding to both its original core, VRTX, and a wrapper there-around which added functionality and, more importantly, a C language interface. With VxWorks, customers could write the application programs in C and have them working sooner than those working in Assembler with pSOS+.
As processor speeds increased, it had become apparent by then that the old Assembler language advocates were losing out to the C upstarts. And to keep its customers, Integrated Systems–the company selling pSOS+–made the critical decision to add a C language interface to pSOS+.
Consequently, the training department’s focus became programming for the pSOS+ operating system in the C language. Development systems shifted from the old, Motorola Exormacs (MC68000-based) systems running VERSAdos to the use of newer Unix-based systems from any of several vendors and cross-compilers that produced code to execute on the Motorola 68000 or Intel 8086 target systems.
At Integrated Systems, the old assembler-language training materials for pSOS+ were retired.
The Westinghouse class in Savannah, Georgia was to be on Unix development systems, and students were to use the C language interfaces. It took place at a hotel in Savannah, and we (ISI) provided a catered lunch as part of the training. (I put on several pounds with the generous midday meals, and had to learn to limit my caloric intake to keep from getting the nods during the afternoon lab sessions when I sat and waited, often for an hour or more, for help requests.)
On the first day of the class, I looked out at my students. As I recall, it was a small class, perhaps eight or so in the audience. But somewhat unusually, they were all in their late 40s and 50s. Characteristic of the time, however, there were no women, no one of foreign descent, and no one of color. (All of that would change in this segment of the market–aerospace and defense–in the next decade.)
I began the first day’s lecture which reviewed the general terms of interest, real-time principles, and the operation of various kernel primitives including scheduling and task prioritization. Hands-on labs would begin on the afternoon of the second day after an overview of the development tools and the mechanics of downloading and testing.
Before class on the second day as students were filling their souvenir ceramic coffee mugs with the ISI logo and sampling the breakfast tray of fruit and pastry, I asked about their application.
One of them said they worked at the Savannah River Nuclear Facility several miles inland and were responsible for the software running “Reactor F.”
I guess my silent ignorance prompted him to continue.
He added, “We breed Plutonium-238.”
Note: According to Wikipedia (consulted on September 2022), the Savanah River Site “stopped producing bulk” PU-238 in 1988. I can only guess that at the time of this class (1995-2000), “bulk” production was on hold, and only small-scale improvements, such as re-writing the software, were being considered. But I hasten to add, this is purely my own speculation.
I’d heard the term “breeder reactor” but didn’t understand what it meant. I asked him to explain.
“It’s quite simple, actually,” he might’ve said. “Basically you fill up the reactor with the rare but fissionable uranium, pull the control rods out to just the right degree, and in the resulting melee of bouncing particles, some of them stick to a nucleus and the uranium is transmuted into an isotope of the much rarer plutonium.”
PU-238 is used in radioisotope power systems. It gives off heat that can then be converted into electricity. Several Apollo flights left Radioisotope Thermoelectric Generators (RTGs) on the moon, and Andy Wiles’ fictional main character in “The Martian” dug up one that’d been buried on Mars for safety reasons to keep himself warm while trucking around the planet.
The Westinghouse engineer in my class said their assembler-language application read hundreds of sensors within the pile of Reactor F and tweaked control rod positions to optimize the production. The control system ran on two, identical Motorola 68000-based systems running in hardware lockstep, and if either system differed on pushing in or pulling out any control rod, the hardware would automatically “scram” the reactor.
As I mentioned, on the second day of class, the students were to begin development of C-language software on the Unix server I’d set up in the room. But when we reached that point in the morning, one of them said they didn’t know how to use the Unix system nor any of its editors. I had reserve training materials for that situation and prepared to shift gears accordingly when one of them added that they wanted to write in Assembler language, not C. Neither I nor the training materials were prepared for that.
I put the class on break and called my boss. He said that Westinghouse–the employers of these engineers–had mandated they learn C and Unix. Teaching them the assembler-language interfaces was not allowed. They were to write in C. And they were to learn how to use the Unix development environment, not the old VERSAdos.
Back in class, I relayed as nicely as possible what I’d been told.
The engineers refused.
“I beg your pardon?” I suppose I said.
They said they would not write in C, would not use the Unix development system, and that everything in class that had anything to do with either of those topics was of no interest.
I felt like I was in a bad Dr. Seuss poem.
I explained that, other than yesterday’s introduction, the C interfaces and the Unix development environment were the entirety of the training.
Five minutes later, I was alone.
I called my boss again. He instructed me to wait. The remainder of the morning passed slowly. I then ate my catered lunch and watched as theirs turned cold and dry on the other plates. I spent the afternoon looking out the window, talking to my wife on the phone, and watching the clock. Nobody returned.
The second day was the same: I was set and ready to go, but no one showed up.
When I updated my boss, he said that Westinghouse had paid for five days of training, and that the walk-out was not our fault. He said I should pack up the equipment and “indulge your whims” for the remainder of the week.
During the year that followed, I taught many classes and mostly forgot this unique experience.
Then, I received notice that I had been booked to teach the same class, at the same location, and for the same customer.
Dutifully, I showed up, prepared the classroom, and greeted the arriving students.
This time, however, they were all what I’ll call fresh-outs. That is, they all looked to be freshly-minted college graduates. They were conversant in C and Unix, and all of them stayed, did the labs, and asked the typical questions I’d learned to expect and answer for our typical customers.
At lunch on the last day, I asked the engineer sitting next to me about the previous group.
He said there was only one of them left, and that he was responsible for the old system, “the one we’re going to replace.”
I nodded, not fully comprehending what he was telling me.
“And the others? What are they doing now?”
Everyone fell silent as the student across the table from me put down his fork.
“They don’t work for Westinghouse as of about a year ago.”
I won’t express my opinion on either that first group’s refusal nor on what we might speculate was Westinghouse’s position. Most assuredly, there are other facts, memos, and meetings that preceded and likely followed that first class.
But what I learned is that the world moves on. Whether you agree or not with the direction, the bottom line is that the world is a lot bigger than you or me, and while our reasoning and opinions are important, at some point we may have to choose our battles.
Moving on is as much a part of life as sticking to your guns.
Only you can decide when to do which, and only you can decide–in hindsight–if that was a good or bad decision.
In the years that followed, if my employer asked me to go and teach a class, I always agreed before I knew where, what, or for whom it would be. My teaching took me to a lot of interesting places, some of which would change the subject if I asked what they were doing. (In time, I figured out some, but for most of them, I’m still in the dark.)
In time, Integrated Systems and pSOS+ would be acquired (and effectively shelved) by Wind River. I learned and taught VxWorks but it was an uphill battle in a training organization with too many teachers. I left and put in a couple of years with Monta Vista teaching embedded Linux. When they outsourced all their training to a different company and laid me off, I founded my own Linux training company, RyteTyme. Our money ran out in two years: I sold a single session of training to two engineers. That was it. I then spent a couple of years at Green Hills and learned their INTEGRITY operating system with the intention of developing a new course to replace their existing one (and its lack-luster training department). But that didn’t work out for what I’ll term as personal reasons even though I wasn’t one of the “persons” with the reason. I ended up back at Wind River with a newly-staffed training department and taught VxWorks and Linux through them for nine years, travelled around the world, and tallied more than 300,000 miles on their nickel.
Yeah, it was nice.
I retired from Wind River at the end of 2014. They have since been acquired, like ISI before them, and later Monta Vista in the embedded Linux arena, by other companies whose priorities and markets were different, and undoubtedly evolving as well.
That first faction of engineers at Westinghouse refused to accept the change that was taking place. Whether they resigned or were canned doesn’t matter. They refused to do what the company wanted, and they’re out.
My own experience has some of that. And I have some that says it is sometimes better to accept change, learn something new, and move with the flow.
If faced with the same kind of choice, I can’t tell you what to do.
But I do know it will happen.
And you will have to choose.
Inside or Outside?
Housing prices in Phoenix have skyrocketed with the influx of Californians. With their excess cash, they are “California-ing” the houses including the addition of concrete block fencing in front of the house, and sometimes all the way across the front of the property, albeit a low one.
For now.
They’re beginning to remind of me this picture I took in a residential neighborhood in Sao Jose dos Campos, Brazil in 2012. It’s the top of a block wall seven feet high, has an electric fence atop that, and if you look carefully, you’ll see broken glass embedded in the cement to further discourage the undesirables.
In the movie Jurassic Park, the animals were inside the electric fence. In Brazil, they are outside.
So, who is in the cage in your neighborhood, and who is running free on the street?