The Boston Diaries

Wednesday, Debtember 01, 2021

Learning to sit back, relax, and enjoy the popcorn

It was decided that I would not change Project: Cleese and that the fake data would just have to be generated faster, despite it not technically being needed (I mean, it's fake data after all).

We are also stalled on an expansion of a current feature of Project: Lumbergh. The team lead has serious qualms about how it's supposed to interact with other features, even though it's not supposed to interact with other features as it's mutually exclusive with the other features. Unfortunately, there are some accounts with this and other mutually exclusive features, in production, and to me, it's clear it's an issue with provisioning of the accounts. But it's not clear to my team leader, nor may manager that this is the case.

And how many accounts are affected? Less than 300 out of 100,000,000. Or in other words, 1 out of 330,000 accounts (0.0003%).

The feature in question currently sends limited information about a call, and of all the “features” we have, this is the most limited in nature. The expansion will add information to bring it closer to par with the other, mutually exclusive features. I personally don't see an issue here, but it's above my pay grade. And now we're in a second round of gathering requirements on this.

I just have to learn to love the process über alles.

“Warthog. Delete word. Warthog. Delete word. Warthog. No, Dameon! Warthog! Duck ewe!”

[The title is a reference to the time Aden Oshea attempted to dictate a book he was writing to a computer. It fits the theme of today's post. —Sean]

We use Microsoft Teams at The Corporation. What I did not know is that The Corporation has tied our desk phones to Microsoft Teams. So when I logged on I noticed I had “voicemail.” I went to check that, and noticed that there was a transcription of the voicemail:

Hello, I'm not sure if this is the right number for XXXXXXXXXXXXXX and if it is this is a brother Maynard from the Church of Jesus Christ on Earth Day St and they were clerk and I see that XXXXXXXXXXXXXX moved from Jacksonville to the Hollywood area and we are trying to contact her and you live in or about the meetings on the meetings. Uhm, word cheap. It started at 9:00 AM. Uhm we sacrament meeting. Uhm thank you and if this is the right number please give me a call. Again this is brother manner. Me and a phone number XXXXXXXXXXXX. Thank you. Bye bye now.

It's a bit of a word salad, but I can see the gist of the message. I listened to the voice mail and yes, it's about as accurate as one would expect from someone with a heavy accent speaking English.

I'm now curious if he ever got a replacement for the Holy Hand Grenade of Antioch.

Monday, Debtember 06, 2021

It's still not easy adding crypto to gopher

I brought up gopher over TLS on the gopher mailing list today, and I learned of at least two new methods one could use to signal the use of TLS. They all have their issues though. So to recap the methods (in no particular order):

Running gopher over TLS over a dedicated port (currently in use): Older clients will still attempt to use TCP to connect; this isn't enough of a signal to say “all these ports are yours, except 743—attempt no TCP there.” So older clients won't be able to connect, and could annoy operators with useless log messages.
Adding a flag past the port value: Again, older clients will ignore this, and it could possibly break the Gopher+ protocol. This might not be that much of an issue, as Gopher+ isn't that widely used to begin with.
Adding new gopher types for TLS: The the plus side, clients that don't understand the new types will safely ignore them. On the other hand, this could potentially double the number of valid gopher types. A variation on this would be to set the MSB of the type character to indicate TLS, but then you run the risk of using an undefined character, especially given that the majority of gopher sites now return UTF-8 encoded characters, and setting the high bit will generate invalid UTF-8, which will break any existing client written in Python3.
A new type of protocol (currently in use): This exists—it's called Gemini and there are those who call for TLS to be removed from Gemini (for a variety of mutually exclusive reasons). Go figure.
Peek at the network stream for the TLS protocol(currently in use): First off, the server would need to peek at the incoming packet to determine if it's a TLS and if so, kick the connection over to the TLS library du jour, otherwise, fall back to the TCP connection. This can fail due to an adversary forcing a regular TCP connection by filtering out the TLS traffic.
Signal TLS via the caps.txt file (currently in use): There's not much documentation about caps.txt—there's an Internet draft that covers the format, but the actual specification seems to be this file from the creator of the specification. There is a field for TLS, but as it was pointed out on the mailing list, this is subject to a MITM degridation attack to force non-TLS.
Use DNS SRV records: There are several issues with this one—the state of DNS libraries was dismal enough that I wrote my own about a decade ago. Things might have improved since then, but this is something to keep in mind. Also, this is too, subject to MITM attacks, only at the DNS level, which is way easier to pull off.
Switch gopher to using TLS exclusively: Given this is a controversal topic for Gemini, I don't think this is a viable solution for gopher at all.

I think that covers all the methods. I'm of the opinion that gopher over TLS isn't worth the effort.

My blog on gopher is still a second class citizen, but it's getting better

Speaking of gopher, I've made it clear that the gopher version of my blog (as well as the Gemini version of my blog) are second class citizens. Since my last post on this matter, the formatting has improved a bit, but it's not quite there yet (the gopher version is okay at best, but the gemini version could use more work—more on that some other time).

But one thing that has improved is better support for displaying multiple posts. Granted, that feature is not used as much as I thought it would be, but I still wanted gopher and Gemini support. It took a bit of time, but I was able to get it working so now you can view my recent Brevard trip on one page on the web, on gopher, and on Gemini. And now in reverse chronological order: web, gopher and Gemini (well, you could always do reverse on the web since the beginning, it's just now I have support for the other two protocols).

All that's left is really thinking about reformatting the posts when “publishing” for gopher and Gemini …

Friday, Debtember 10, 2021

Working on legacy projects

The Corporate Overlords have assigned me to maintain “Project: Bradenburg.” It's a project my department is responsible for, but I never worked on it. It was written by fellow team member JC who left last year, and the person who was supposed to maintain it (he was assigned to our team shortly after JC left) also left this year. So now it's my turn.

Woot! Legacy code!

Unlike the rest of our code base, “Project: Bradenburg” expects to run on a modern 64-bit Linux system. Okay, cool! I get to learn about running Linux VMs on an Apple Mac book (only took two days, and constant reminders to myself not to throw the laptop across the room, to get the VM installed and running).

Then I attempted to build the system, and that's when I learned the Linux system I'm running is a bit too modern. It took some hacking to get the code compiled, and I'm concerned about how best to integrate the changes I have with the build system.

I'm also learning why people hate make. I've never really got the hate, because I never found make all that difficult to use (especially GNU Make—I find it quite nice to use). But diving into “Project: Bradenburg” really has me questioning JC's … um … design asthetic when it comes to make. I was able to replace six Makefiles comprising a total of 700 lines, with one Makefile of 197 lines, 150 of which comprise the dependency list (automatically generated—leaving 47 lines to do the actual building). I'm sure the Makefile will grow a bit (to cover building a release versus a debug build) but not 500 more lines.

Another thing I'm working on is finding out not only who uses “Project: Bradenburg,” but how they're using it. I know the Corporation uses it, but I do know that JC was working with our Corporate Overlords to have it used elsewhere. I want to rip some stuff out if it (like the internal stack tracing mechanism) but I first want to know if anyone uses the stuff I want to remove.

Notes on an overheard conversation while bringing in the groceries

“What an annoying Christmas display.”

“I tried knocking on the door to tell them their car alarm is going off. No one answered, and the entire house is dark.”

“That can mean two things—they're not home, or everybody is dead.”

“That's morbid!”

“Okay, third option—they're all deaf.”

Monday, Debtember 13, 2021

Maybe another name for this project should be “Charlie Foxtrot”

I'm still diving into “Project: Bradenburg” and I'm amazed that it's being used in production. I found mention of two specific versions of Linux distributions that are known to compile the code, but only one was able to compile the code as is (the other one had a compiler that was too old to use—go figure).

I wanted to start compiling with the version used in production at The Corporation, but it turns out to be difficult to check out that version. We use Subversion, and it appears that the revision used by production isn't in the main line of code, but in some branch. I tried using Fisheye (the Corporation has it installed and integrated into our build system) to find the appropriate branch, but the view for “Project: Bradenburg” was turned off four months ago

I was only able to find the branch by checking out the entire repository (all branches included—it took a while). It turns out that even if I knew which branch the production code was in, it wouldn't have mattered (per the wisdom of the ancients).

Eventually I get the proper version and … it doesn't compile. Two syntax errors and one linking error. Sure, they were easy to fix, but now I'm wondering how this was ever built by our build system to begin with. But that's moot as the build server can't even build the latest version—it can't find the proper target system to build on! It was then I noticed that “Project: Bradenburg” was last built over a year ago.

Woot!

This project certainly is putting the word “fun” in “disfunctional.”

Notes on an overheard conversation while checking the mail box

“I was worried we wouldn't get any Christmas cards this year.”

“I see we got one from Peggy, and … our neighbor across the street actually sent his card through the mail?”

“Yes.”

“He spent 58¢ for a stamp when he could have just walked across the street and put it in our mailbox?”

“Yes. That's the way it's supposed to be.”

“Across the street?”

“Yes. I'm doing the same.”

“You are wierd, sir.”

“Pththththththththth!”

Tuesday, Debtember 14, 2021

Putting the “fun” in “dysfunctional”

I finally heard back about “Project: Bradenburg” and it's not exactly good news. The Corporation is using revision 4873. The Corporate Overlords are apparently using a custom version of revision 5076 (custom because it contains a one line patch). No one else is using “Project: Bradenburg,” at least for now.

Lovely.

Also, around the time of revision 5076, the codebase started to be converted from C to C++. No reason I can find for the decision, and it's not complete. So now I have to deal with a hybrid C and C++ project, which is currently at revision 5567. Oh, the desire to switch back to the C code base is strong. I'll have to see.

On the plus side, “Project: Bradenburg II: Electric Boogaloo” (yes, an attempted rewrite of “Project: Bradenburg,” which itself was a rewrite of a previous project that never got into production, which was to replace a third party package that didn't quite do what we wanted and was thus patched to Hell and back) can be safely ignored. I also have a few months to figure this mess out.

Ah, what a legacy this code has.

Wednesday, Debtember 15, 2021

There seems to be a qualitative difference between C and C++

I need to decide if “Project: Bradenburg” will be in C or C++. I timed how long it takes to compile the last C version of the codebase: 2.4s. I then timed how long it takes to compile the hybrid C/C++ version: 18s. There's a qualitative difference there. And I should note—it's the C version that's currently in use, not the C++ version. And then our resident C++ expert said that you should start a project in C++, not convert a project from C to C++.

Hmmmmm …

And from the “Puts the Fun in Disfunction Department” I noticed that there are warnings enabled on the compiler command line, only for those warnings to be disabled in the source code (via many #pragma declarations). Oh, and the reason it runs so slow is that the optimization level is set to 0, possibly to make the code easier to debug by looking at the resulting assembly code (I'm guessing).

It's also becoming clear that no one really knows who is using “Project: Bradenburg.”

The fun never stops.

Thursday, Debtember 16, 2021

“Well, there's your problem!”

“Sean,” said Bunny, “do you have a way of testing an electrical outout?”

“Hmm … don't we have one of those outlet tester things? It looks like just a plug, but with a few LEDs on the back showing the status of the outlet. I thought we got one of those.”

“Let me look.” She then goes off for a few minutes, and returns with exactly what I described, still in the package. “This?”

“Exactly!”

We then grab a flashlight as the sun was setting, as the outlet in question was outside. I work my way to the outlet and lift the covers. The bottom outlet was a bit darker than the top one, so I decided to test the top one first. I plug in the device. “Nothing,” I said.

“Okay, now try the bottom one,” said Bunny.

I plug the tester into the bottom outlet. The air was filled with a loud buzzing sound as flames shot out of the outlet, engulfing the tester. Bunny and I were stunned for several seconds, not knowing exactly what to do. Fortunately, the flames died out and the sound stopped. I pulled the tester out of the outlet and we both went back inside.

“I wonder if this tester still works,” I said once we were inside.

“Sean, just look at it!”

I looked at it. the ground pin was slightly blacked at the base; the neutral pin was entirely black, and the hot pin was entirely black and partially melted. Looking at the directions on the package showed the “no lights' condition as “open hot”—the hot contact not connected. And item 3: Refer all indicated problems to a qualified electrician.

Although “flames shooting out of the outlet, destroying the receptical tester” isn't a listed issue, I'm guessing that's enough of a clue we should have the outlet looked at by a qualified electrician.

Twiddling my thumbs

I use The Corporate Overlord's mandated Windows Laptop only for a few things, like submitting my time card and to check how much PTO I have left for the year. So I turn on The Corporate Overlord's mandated Windows Laptop (hereafter named “Satan”) and immediately, my Internet connection is swamped. It's completely unusable. I check, and yes, Satan is sucking up as much bandwidth as computerly possible for doing Bill knows what. It certainly can't be malware, because it's already filled to the brim with anti-virus, anti-malware, anti-anything programs constantly running in the background that I can't do anything about because Satan is completely managed by the Corporate Overlords.

Okay, I think to myself. While I'm waiting, maybe I can see if this thing has Solitaire on it. I always liked playing Solitaire. And yes, it has Solitaire, only now it has ads, (only $14.95 a year to remove ads).

Really, Microsoft? Good lord.

It's been an hour so far, and Satan is still downloading Bill knows what.

I think come January, I'll ship Satan back to the Corporate Overlords. Bill knows I certainly don't use it.

Update just prior to publication

I turned off Satan, and immediately, the network was usable. Not only that, but I was able to log onto the enterprise application from a non-Windows system, so there is no reason I need Satan here anymore.

I'll definitely look into shipping Satan back to where it belongs.

Friday, Debtember 17, 2021

“Well, there's your solution!”

It turns out that Bunny's brother is a qualfied electrician, and even though he's 3,000 miles away, a few pictures and several phone calls were enough for him to walk us through replacing the problematic outlet. The hardest part—kneeling on the granite gravel beneath the outlet. Ouch. But we had everything we needed. I even found a duplicate receptacle tester in my toolbox!

And now the outlet works. But I did state to Bunny that if that outlet ever gives us trouble again, I'm calling an electrician—I'm not kneeling on gravel if I can help it.

C++11 is supported, but not C11 … of course

So I notice that JC used GCC atomic intrinsics for “Project: Bradenburg”. I also found out which distribution we're using for the Linux build servers, so I have that installed as a VM. I'm toying around with going back to C for “Project: Bradenburg,” and given that C11 has support for atomics, it seemed like a way of getting more portable atomics in the codebase.

Of course the Linux distribution we use supports C++11, but it lacks C11 support. Of course it does!

C11 is only a ten year old standard, so let's not rush into things here! But C++11—full steam ahead! It's 10 years old already! Why aren't you using it?

Words fail me.

Wednesday, Debtember 22, 2021

Are we having fun yet? And by “we” I mean “I.” And by “fun” I mean “misery”

Ah, “Project: Bradenburg”—the gift that keeps on giving.

The build server can now find the proper build node, so that's progress. The build fails, however, because of linking errors, which at least validates the issues I'm having on my local machine. I make one small change to the Makefile I know will fix the issue, and the build server didn't pick up the change.

What?

Some investigation, and it appears the build server is pulling the repository from git, and not from Subversion. It appears I did not receive the memo about this (a year and a half ago, I started to migrate our stuff to git, but stopped because some of our Solaris build servers couldn't check the repos out from git. And that's still an issue. But “Project: Bradenburg” doesn't run on Solaris so for that and some other reasons, Ops “moved” the repository to git a few months ago). So now the official build for “Project: Bradenburg” comes from git, and the rest of our official builds for projects in our department are still from Subversion.

Fine. I can deal. I actually prefer git over Subversion anyway.

I get the credentials worked out for the git repository, make my small change to fix the linking issue, only to have another linking issue. Because of course.

I swear, how did this ever compile in the first place?

A most persistent spam, part V

I received an email from new reader Sylvain asking about Alaksandr, the Russian sendmail spambot that was plaguing me for months. It seems that Sylvain is having to deal with Alaksandr and asked me for some help, having read one of my posts detailing the problem (and if you are having déjà vu, it's not a glitch in the Matrix).

I told Sylvain about my solution—removing the email accounts Aleksandr was spamming. I also decided to update each of the posts to point to my solution as it seems others are having similar issues and not finding answers.

Schadenfreude at some badly written bots

Back in October, I removed a whole section of my Gemini site because I got fed up with badly written bots. In the best practices guide there is a section about redirection limits (something that should be in the specification but for some reason isn't). In the section of my site I removed, I had such a test—a link that would always redirect to a link that itself would redirect, ad nauseum. So I would see a new client being tested and perhaps a dozen or two attempts to resolve the link and then it would stop.

But then there were the clients written for automated crawling of Gemini space that never bothered with redirection limits. It got so bad that there was one client stuck for a month, endlessly making requests for a resource that was forever out of reach. I had even listed the redirection test as a place for bots NOT to go in the robots.txt file for the site (also a companion specification).

So because it can be needlessly complex to locate a bot contact address, I was like, XXXX it. I removed the redirection test (along with the rest of the section, which included a general Gemini client test because, well, XXXX it). Why waste my bandwidth for people who don't care?

I only bring this up now because I'm noticing two bots who are attempting to crawl a now non-existant redirection test, probably with a backlog of thousands of links because hey, who tests their bots anyway?

Saturday, Debtember 25, 2021

I think I'm supposed to say “Merry something something,” and something about good wills

.qggL     .gggr.
  PMML    /|MM
  |!MM,  /`|MM   .d/"q,  qgg;+Ml qgg;+Ml vgg. .y.
  | YMM,j' |MM   MM;.jMl |MM` "  |MM` "   qM| j`  
  |  qM#'  |MM   MM|     |MM     |MM       MMg'
.j|.  qF  .+MM.. 'MMbxr` jMM.    jMM.      'MF
                                         x, /
                                         v#'
  .x/--\xxl ,xx               ,gb           .
.dMT    'q| |MM               '"'         .dM
dMM       ` |MM/dMg,  qgg;+Ml qgg  j/"`+  qMM-. qgg/dM#,w#Mb  ,g'`fg,  j/"`+
MMM         |MM  MM|  |MM` "  |MM  MMbx/  |MM   |MM  |M|  MM  `P'.jM|  MMbx/
'MMl      . |MM  MM|  |MM     |MM  .`vMMl |MM   |MM  |M|  MM  ,gP`|M|  .`vMMl
 'vMb...r/` jMM..MM|. jMM.    jMM. +,.,P' 'MMx: jMM..dM|..MM, MM|r+M|. +,.,P'
     ""

[It looks like Sean finally fixed the spelling mistake. It's about time! ---Editor]

Wednesday, Debtember 29, 2021

Still going strong, a week later

Heh, a week later and there are still bots following the endless redirections from my Gemini site that are now long gone. Given the nature of Gemini, there's little in the way of contacting the people responsible that they're wasting time and resources. Perhaps if it's still going on next week, I'll mention IP addresses …

Software can just never be done it seems

I released the Text::Template module several years ago, and it was immediately very successful. It's small, simple, fast, and it does a lot of things well. At the time, there were not yet 29 templating systems available on CPAN.

Anyway, the module quickly stabilized. I would get bug reports, and they would turn out to be bugs in the module's users, not in the module; I would get feature requests, and usually it turned out that what the requester wanted was possible, or even easy, without any changes to the module. Since the module was perfect, there was no need to upload new versions of it to CPAN.

But then I started to get disturbing emails. “Hi, I notice you have not updated Text::Template for nine months. Are you still maintaining it?” “Hi, I notice you seem to have stopped work on Text::Template. Have you decided to abandon this approach?” “Hi, I was thinking of using Text::Template, but I saw it wasn't being maintained any more, so I decided to use Junk::CrappyTemplate, because I need wanted to be sure of getting support for it.”

I started wondering if maybe the thing to do was to release a new version of Text::Template every month, with no changes, but with an incremented version number. Of course, that's ridiculous. But it seems that people assume that if you don't update the module every month, it must be dead. People seem to think that all software requires new features or frequent bug fixes. Apparently, the idea of software that doesn't get updated because it's finished is inconceivable.

I blame Microsoft.

Twelve Views of Mark Jason Dominus

I can't say I haven't myself wished that the industry as a whole just said, “Enough! Let us spend the next year on nothing but bug fixes!” But that's just not going to happen. Why? Because no one will pay for bug fixes, as stated by Bill Gates himself: “There are no significant bugs in our released software that any significant number of users want fixed. … I'm saying we don't do a new version to fix bugs. We don't. Not enough people would buy it. You can take a hundred people using Microsoft Word. Call them up and say ‘Would you buy a new version because of bugs?’ You won't get a single person to say they'd buy a new version because of bugs. We'd never be able to sell a release on that basis.”

But the idea of just arbitrarily increasing the version number every so often does seem silly, but hey—the industry as a whole has this idea that a project that hasn't changed in some period of time is dead and not worth using. It's silly ideas like this that has lead me, over the past five years, to do at least one release per year of mod_blog just because!

The “Somewhat Arbitrary Christmas Release” Version (2016)
The “Not-at-all Arbitrary Christmas Release” Version (2017)
The “Completely Arbitrary Christmas Release” Version (2018)
The “Christmas Time (in more than once sense) Release” Version (2020)
The “Enough Changes For A Christmas Release” Version (2021)
The “Post-Christmas Pre-Hook” Version (2021)

(Yes, I actually had enough changes this Debtember to cut two releases to inadvertantly make up for the one I missed in 2019)

I found the above quote from Mark Dominus via a comment to Chris Siebenmann, which itself was linked from a more recent post from Chris Siebenmann. Both posts are worth reading as they go into some depth as to why the industry as a whole wants constant upgrades over stable software.