The Daily Parker

Politics, Weather, Photography, and the Dog

1.5 Gs

As of just a few moments ago, I passed 1.5 billion seconds old.

Yes, this is a thing most people don't really think about, but as someone who works in software, this actually has some significance—and another Y2K problem that will occur just a few months before I get to 2.0 Gigaseconds (Gs) in 2038.

The problem is a thing called the Unix epoch. Computers can only count as high as they have bits to count. Unix computers, which include Macs and most of the infrastructure of the Internet, count time in seconds from 1 January 1970 00:00 UTC, which was (at the moment I'm typing this) 1,521,383,994 seconds ago.

Everyone knows computers can count to awesomely huge numbers. But you need to give them enough bits to do that. Unix time is measured by a 32-bit number, which can count up to 232-1, or 4,294,967,295 (in binary, a 32-item string of 1s), which is enough seconds to count just over 136 years.

But you sometimes want to measure things that happened in the past, so Unix time takes the first bit of the 32-bit number and makes it a sign. If the first bit is 0, the time is in the present. If it's 1, the time is the number of seconds before the beginning of the epoch. So this cuts the measurable period in half, to 68 years. Specifically, Unix time rolls over at 3:14:08 on 19 January 2038.

The fix is simply to use a bigger number. Today, 64-bit numbers are no big deal, and they give you 263-1 (9,223,372,036,854,775,807) seconds to work with in either direction. That's roughly 292 billion years, which is sufficient to measure most human-scale activities.

So, knowing all this, and knowing that I was born in the first year of the Unix epoch, it wasn't difficult to figure out my "epoch" birth moment at 9:12 CDT this morning.

But there's a catch. As I mentioned, computers count by 2s, not by 10s, so this entire post is a lie. I'm not 1.5 Gs old; I'm just over 1,500,000,000 seconds old. 1.5 x 230 (i.e., 1.5 giga anything) is 1,610,612,736, so I won't be 1.5 Gs old until Unix moment 1,631,995,056, which will be 18 September 2021 at 19:57:36 UTC.

So check back in three and a half years. I'm sure I'll have another post about this nonsense then.

(For those of you keeping score at home, I was 1.0 Gs old on 13 September 2004 at 20:09:04 CDT, during a lull in blogging. Else I'm sure I would have mentioned this then.)

Long weekend; just catching up

Saturday and Sunday, the Apollo Chorus sang Verdi's "Requiem" three times in its entirety (one dress rehearsal, two performances), not including going back over specific passages before Sunday's performance to clean up some bits. So I'm a little tired.

Here are some of the things I haven't had time to read yet:

Other stuff is going on, which I'll report when I have confirmation.

WTF to LoC ratio

I had a meeting this morning to bring a new developer onto a maintenance-mode project. In doing so I went over some code I wrote 4 years ago. Yikes.

We're doing a deep-dive on Monday...

Hardware and software debugging

I'm working from home today because I had a cable guy here for two hours, and because winter has finally arrived. The rain and sleet is also a problem because my Fitbit numbers have been off for four straight days.

I did get a lot of sleep this past weekend—but that also could be a factor today, according to new research into weekend lie-ins. (tl;dr: sleeping in on Sunday makes it harder to wake up on Monday.)

I'll have more later today. Now I have to figure out how to get a custom Microsoft Dynamics instance to play well with my company's software. That will be just as fun as it sounds.

Troubleshooting an upgrade conflict

After upgrading to the Azure SDK 2.8.1 yesterday, I'm unable to debug this application locally without an uncomfortable contortion.

The application is a Microsoft ASP.NET MVC website set up to run using IIS Express. It uses some Azure components, in particular the evil msshrtmi.dll that has caused so many versioning headaches in the past.

The symptoms are these: when starting to debug the application in Visual Studio 2015, the application compiles but immediately causes a system toast message to appear that announces "One or more errors occurred running IIS Express." Clicking there for more information opens this unhelpful dialog box:

The log file contains this single line:

Failed to register URL "http://localhost:64079/" for site "BlogEngine.NET" application "/". Error description: Access is denied. (0x80070005)

The other links point to articles on the MSKB, one of which is out of date and the other of which is probably irrelevant (because I'm running VS2015 as administrator).

I'll get to those in a second, because in reviewing the Windows application and system logs, I found some suspicious events that seem related.

In the Application log, there are multiple error events with IDs 2269 and 2276 that start after I installed the Azure SDK update. Event 2269 is: "The worker process for app pool 'Clr4IntegratedAppPool', PID='11000', failed to initialize the http.sys communication when asked to start processing http requests and therefore will be considered ill by W3SVC and terminated. The data field contains the error number." The error number is 0x80070005 with another code 13780. Event 2271 is just a cascading error, "The worker process failed to initialize correctly and therefore could not be started."

Googling Event 2269 yields quite a few articles but they seem to diverge from my problem very quickly. I'll plow through those in a minute.

The other interesting event is in the System log. Whenever I attempt to debug the app, Event 15005 appears: "Unable to bind to the underlying transport for [::]:64079. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine. The data field contains the error number."

Well, that's a lot more interesting. And it led directly to this article, which led to me looking at what is actually listening for what, which led me to changing the port in my debugger from 64079 to 49156. (I could see that 49156 was free by running netstat -aon.)

Sigh. I have no idea why upgrading to the latest Azure SDK would hose an IIS Express port, but even more than that, I am not entirely sure whether blaming the SDK is itself post hoc reasoning. But like so many things in systems this complex, I have now fixed the symptoms, and will go on with my life. Such a time suck, though.

Upgrade headache

I just upgraded my system to the Azure SDK 2.8.1, released earlier today, and also merged the latest code from the BlogEngine.NET master repo into my custom codebase. Do you see where I'm heading?

Once I "solved" the version issue with msshrtmi.dll (a perennial bête noir [not to be confused with this bête noir]), then published the changes, and promptly killed the blog for an hour.

It looks better now, but I'm still having trouble debugging it locally. Tomorrow, after I finish fixing a bug for work, I'll figure out why.