The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, October 01, 2024

“What were the skies like when you were young?” was not asked by LeVar Burton

I always thought that the opening question in the song “Little Fluffy Clouds” by the Orb (music video) was a sample of LeVar Burton, maybe from his show “Reading Rainbow, but apparently, it's not! (link via Jason Kottke) Upon relistening to the song, it's now clear to me that it's not Levar Burton. It's very close though.

And while I like the song, my favorite one from The Orb is “A Huge Ever Growing Pulsating Brain That Rules from the Centre of the Ultraworld,” which is like a fever dream but in a good way [You're insane! —Bunny] [Yes, but in a good way! —Sean].

Monday, September 30, 2024

Ch-ch-ch-changes

Last week I got a letter in the mail from my ISP. In it, they said:

In a recent communication, we informed you that we are discontinuing the use of static IP adresses with our home internet service. We need to move your service to a dynamic IP address to avoid service ineterruption.

Please call before 9/30/2024 to avoid any interruption of your internet service. If you do not call, you internet service will be distrupted after this date.

I recall that previous communication. A few months ago I received a letter from my ISP trying to upsell me on a new plan, one that did not support static IP addresses. I called, and when I said that wasn't an option because of work (a slight embellishment on my part) they replied “how unfortunate” since they had no plans to offer one with the new plan. So I did nothing. I was happy with the plan I had (well, kind of still have).

And then last week, the letter above.

Now, I thought, given the wording the in letter, that I had until October 1st, you know, a date after their cut-off date of September 30th. And even then, I probably had several months, given my ISP is a large Enterprise that Does Not Move Fast™. Nope. Their definition of “after this date” was … today!

I only noticed when I couldn't log into my public server. The connection was still up, it's just that I no longer had the same IP address that I've had for the past … um … fourteen? years. I guess they can move fast when they want to.

I also found amusing this line in the letter: “We will switch your service to a dynamic IP address at no additional cost.” Wow! How nice of them. It's almost as if I wasn't already paying more for a static IP address!

Boy, how the Internet has changed over the years. Going from 32 publically addressible IP addresses aacross a dedicated ISDN link (years before DSL was a thing) to now, a dynamic IP address. Yes, I know, First World Problem™. It still doesn't make it less annoying from being a real peer on the Internet to just a cog in the client-server nature of the modern Internet.

And then, just three hours after the change, the company I host my public server with called—they're changing where the physical servers reside and that the public IP address I have for my public server will probably change, along with the DNS servers.

Boy, when it rains, it pours.

Sunday, September 29, 2024

“It's 250 miles inland! What do you mean it was hit by a hurricane?”

I've always thought of Brevard as a place safe from natural disasters, nestled as it is in the Appalachian Mountains. It's not along a fault line so no earthquakes … oh wait a second … there is a fault line nearby. But still, it's too far inland for anything horrible like a hurricane to worry about … oh … wait a second … Hurricane Helene is causing issues in the area.

Perhaps it's not as safe from natural disasters as I once thought it was.

Sigh.

Wednesday, September 11, 2024

This could maybe explain some of the emails I received, but not all of them

I received some responses to yesterday's post. The first was from Lionel Dricot who reported that he, too, has received emails for other Lionel Dricot's that lived near him. He also stated that it may be a bug in Gmail where one person can register “seanconner@gmail.com”; someone else could register “sean.conner@gmail.com” but when receiving emails, Gmail condenses the two addresses into one. That's possible, but I would suspect that would have been an issue caught early on. I've had my Gmail account for twenty years now [Has it been that long? —Sean] [Yes, it has. —Editor] [Shut up! —Sean]. and it's only been in the past few years that this has been an issue.

He also stated that people could just really be that bad with email addresses.

The second response has an explanation that is rather dire:

From
XXXXX­XXXXX­XXXXX­XXX
To
seanconner@gmail.com
Subject
People non knowing their email
Date
Tue, 10 Sep 2024 08:24:51 +0200

Hi, considering you've been shared on Hacker News, I'm afraid sooner or later some script kiddie will start abusing your address just to annoy you. I hope this will never happen ;) Thanks for sharing your blog, ave [sic] a nice day, White_Rabbit

That could explain maybe some of the email I get, which to me, I consider spam that Gmail hasn't filtered yet. But it doesn't explain emails sent to “sean.conner@gmail.com” that are obviously not a “Sean Conner,” and yet definitely contains private information. It also seems excessive to register a TikTok account or even an Instagram account.

And speaking of Tiktok, I finally have an account name associated with the TikTok account, so I have to wonder why “mommakmiller” decided to use my Gmail account? Perhaps they don't have an email account and need one to sign up for TikTok? Perhaps they didn't want to use their real email account? Perhaps they don't realize the danger in that?

Monday, September 09, 2024

How? How do people not know their own email addresses?

I'm still receiving emails from strangers who for some reason or another, think their email address is “seanconner@gmail.com” (no, really, I get so many emails). This time, it's from someone who's TikTok account was accessed on a new device:

From
TikTok <noreply@account.tiktok.com>
To
seanconner@gmail.com
Subject
New device login detected
Date
Tue, 03 Sep 2024 04:56:22 +0000 (UTC)

Hi xs,

We’re writing to inform you that we detected a login to your account from a new device.

When: 09/03 00:56 EDT
Device: iPhone 11
Near: Louisiana

If this was you, you can ignore this message.

If this wasn’t you, open the TikTok app and go to “Settings and privacy” > “Security and login” > “Security alerts” and review unauthorized logins. If you’re unable to access your account, contact TikTok support.

You can also set up 2-step verification to secure your account by going to “Security and login” > “2-step verification”.
Learn more about 2-step verification

This is an automatically generated email.
Replies to this email address aren’t monitored.

This email was generated for xs
Privacy Policy
TikTok 5800 Bristol Pkwy, Culver City, CA 90230

It's not a phishing email as the raw message doesn't contain a link to “login” to TikTok, and the links that are in the email all point to the TikTok domain. So I'm at a loss. “xs” created a TikTok account, using my email address …

Why?

I don't know why this should surprise me any more, but it still does. I just … why? How? What's the angle here?

I can't even contact anyone, because TikTok send email from an address that isn't checked. I don't know who “xs” is, nor do I have any way to contact “xs” to inform them of their error.

Sigh.

Tuesday, August 27, 2024

The programmer's obsession with version numbers

It's yet another round of hand wringing about software versioning. Woot!

Over the years, I've found that semantic versioning works for me, but only for code code that is to be used in larger projects, like libraries, modules, or classes. Yes, a code base using semantic versioning doesn't always mean the code base follows semantic versioning to the degree that some would like (like any bug fix should automatically update the major version number, because bug fixes could break some code, somewhere). But in my mind, it signals intent, which, sans an extremely obnoxious and overly bureaucratic process, is the best we can expect.

So for me, the MAJOR.MINOR.PATCH of semantic versioning breaks down like this:

MAJOR
Some change in the code base was made; either a change in API behavior, removal of some portion of the API, file format, or otherwise any visible change (except for bug fixes) in how the code works. Work will probably be required to update to this version of the library/module/class.
MINOR
Only additions to the API were made, in a backward compatible way. No work is expected, unless you were already using a name used in the updated library.
PATCH
A bug fix. The intent is for no work required to upgrade, unless you were relying upon the buggy behavior, or used a workaround that might now interfere with the library.

For applications, I've found that semantic versioning doesn't work. At least, it doesn't work for me. I've switched to either using a monotonically increasing number (mod_blog is now at version 60—but given the five releases in just the past week because of a misplaced obsession with version numbers, I might entirely stop with the version numbers—especially since I seem to be the only one using it) or skip it entirely (my Gemini server has no version number, but it's had 322 commits over its five year life so far).

The worst form of versioning I've enountered is “named versions.” A “named version” give no semantic information about the version and, at least to me, leads to confustion. Is “Bulldog” newer than ”Beagle?” Or is “Bloodhound” the latest version? Oh, it's “Berzoi” that's less than 20 minutes old. Sheesh.

But if I had to apply “semantic versioning” to an application, I would like information about any breaking changes to either work flow or file formats. To me, an incompatable change to a file format, or any change in workflow (even a change in location of a menu item) is a breaking change (muscle memory is an incredible drug). Hell, even a change in color scheme is enough to possibly break my workflow (I'm looking at you, Google Maps, who changed the color of all the roads to the same color! Why? I liked the distinction between highways, major roads and minor roads. Did you see a 0.001% increase in engagement for that change? Did someone get promoted just because of that change? Okay, I'll stop ranting now).


Discussions about this entry

Saturday, August 24, 2024

How to run valgrind on a CGI program in C

There was still one bug left with mod_blog—it would crash with a memory corruption error (thanks to checking in glibc when doing a POST. I only found the bug because I was using the old web interface to make sure I had the right credentials when testing the PUT method. How long had the bug existed? At least six years—it's been seven sine I last used the web interface (I checked).

It did not crash on the development server due to subtle differences between the operating system and versions of glibc being used. But it is ultimately a memory corruption, so the use of valgrind would be instrumental in finding the issue. The problem is—it only manefests itself when doing a POST, which means testing the program under a web server. And a web server will pass information about the request to the CGI program through environment variables, and any input comes in via stdin.

So just how do you run valgrind on a program meant to be run as a CGI program?

After some thought, I figured out a way. I need to capture the environment the CGI program runs under, so I added the following bit of code to mod_blog to capture the environment:

extern char *envriron;
FILE *fp = fopen("/tmp/env.txt","w");
for (size_t i = 0 ; environ[i] != NULL ; i++)
  fprintf(fp,"export %s\n",environ[i]);
fclose(fp);

I wasn't worried about error checking—this is temporary code anyway. I then do a POST and I now have the environment variables in a file:

...
export GATEWAY_INTERFACE=CGI/1.1
export HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
export CONTENT_LENGTH=149
export CONTENT_TYPE=application/x-www-form-urlencoded
export REQUEST_METHOD=POST
...

The reason I added “export” was to copy these environment variables to a shell script where I can then run valgrind and debug the situation:

...
export GATEWAY_INTERFACE=CGI/1.1
export HTTP_ACCEPT=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,\*/\*\;q=0.8
export CONTENT_LENGTH=149
export CONTENT_TYPE=application/x-www-form-urlencoded
export REQUEST_METHOD=POST
...

valgrind $HOME/source/boston/src/main <r.stdin

Of course, I had to escape some problematic characters like the asterisk or semicolon, but there were only a few such characters and they could be done by hand. And I had to create the input feed into stdin but that was easy enough. From there, it's straightforward…ish enough to resolve the issues.


Discussions about this entry

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.