I started PC programming in 1982, had to teach myself asm almost immediately in order to write a hardware interrupt handler for the serial port.
Back in those days code size was important, and for any driver/TSR type program it was simply crucial. Here in Norway we needed to load the KEYBNO.COM program which took over the keyboard interrupt and provided the official Norwegian layout, including the 'æÃÃ¥ÃÃÃ...' keys for our 3 extra letters in the alphabet.
Over the years, Microsoft/IBM had many version of this driver, the final one which also did text more font layout changes (at least for the default 25x80 mode) was up to 60 kB. This was large enough that lots of US-developed engineering/DB applications simply didn't fit, so I wrote a replacement:

All keys (including Ctrl- and Alt- modified combos) were handled, along with font remapping for 25x80, 43x80 (EGA only) and 50x80 (VGA only) screen layouts, using a total of 704 bytes. It became so popular that Compaq/HP stole it to give to their customers, then when we caught them red-handed (they had not figured out how to get rid of my startup Copyright message) they refused to pay but promised to not do it again.

Half a year later we caught them again, they had started telling customers that they had to keep it a secret.

Terje Mathisen

NIST have always been the world leader in creating ever more accurate clocks, the current masers work in picoseconds and below, so allowing the reference to drift by 4.8 microseconds means that precision dropped by at least 6 orders of magnitude.

If allowed to propagate to the GPS control clocks, this would have been enough to totally destroy the navigation system since a clock that is off by 4.8 us corresponds to a position error of 1500 kilometers. (OTOH, USNO has its own large ensemble of atomic clocks, so they don't depend short term on NIST updates.)

Full disclosure: I worked with the NTP Hackers (network time protocol) team for 20+ years, so I'm probably a bit more interested in precise timekeeping than most. I have personally soldered together 4 or 5 GPS-based reference clocks that would deliver 25-35 ns RMS precision.

Full disclosure: I was somewhat involved with the Quake development, helped Mike Abrash a little bit to optimize the asm code that actually made a pure SW 3D rasterizer fast enough to be playable.

The Castle Wolfenstein - Doom - Quake progression might seem from the outside to be a fairly linear upgrade path, but in reality Quake was at least an order of magnitude harder to achieve.

Just the number of amazing ideas John Carmack managed to come up with in order to make a real 3D game possible will forever give Quake a special place in my programming heart.

Terje

I'm Norwegian, have driven EVs since around 2000, and only EVs since March 2016:

This was the first time I could buy an EV which had both a long enough range to drive up to the Telemark mountains to go skiing, and had the 4WD to reliably get up hills on snowy/icy roads. At the time, this was a Tesla Model S, which we since sold to our son, replacing it with the "made for Norway" Model Y (which has been the best-selling vehicle in Norway for the last 3 years).

As noted above, we started with a lot of EV incentives, we saved over $5000 per year in gas and toll road fees until around 2020 when they (as planned) started to roll back some of those incentives.

However, all of that doesn't really matter: By now it is pretty much inconceivable for most Norwegians to buy any new non-EV vehicle: They are just so much better!

Terje

Please re-read what I wrote: Smearing works perfectly well in an environment where you control both the (smearing) server(s) _and_ the clients!

If you can make sure that all your clients reduce their poll interval before the smearing starts, then you can track any reasonable smearing trajectory, without ever getting more than a ms or so away from your reference, and consequently, all your peers in the same environment.

For a global/pool server, the NTP Hackers would prefer all this to just work, with all clocks agreeing what the time is, without any single client dropping out of sync because it suddenly realizes that its local clock is more than 128 ms away from the reference(s).

As soon as you need this to also work in a real-time process control environment it becomes a lot harder: Are you sure that all your processes can handle a temporarily non-stable time reference? Can you even apply smearing to some of those process-internal clocks/frequency references?

Terje

NTP has absolutely nothing to do with local time and/or daylight savings: It works only in UTC, but with corrections to handle and propagate leap second events.

Terje

Smearing the leap second is a solution Google came up with for their own data centers when they realized that they had too many protocols that didn't know how to handle UTC leaps properly, it really cannot be applied generally unless everyone can agree on exactly how to do it.

In my own test code, I did the smearing over a 24 hour period, centered around the leap event. The main arguments here are on how to determine an optimal smearing function: You want a gradual increase, then a mostly constant slope period, before a gradual decrease near the end.

There are however several potential problem areas with smearing:

a) ntpd works within a maximum of 500 ppm adjustment rate, of which the majority must be reserved for correcting the local clock, leaving maybe 100 ppm as the maximum smearing, so at that point it will take about 10000 seconds (or ~3 hours) to smear a second. Reducing the max smear rate to around 20 ppm is compatible with a 24-hour adjustment.

b) Very stable clients will only poll the server(s) every 1024 seconds, or even less (every 2K/4K/8K seconds), and to detect a change in the reference clock, a client needs 4 consecutive polls showing a drift from the previous stable value.

c) ntpd considers an offset of 128 ms to be infinity, at that point it will restart the protocol engine and losing sync until everything has been stabilized against the current smearing rate. It should be obvious that a smearing setup which drops sync at both ends of the process would be really bad.

d) If you can force the protocol to drop the sync interval, from 1024 s down to the standard minimum of 64 sec, then it becomes much easier to track/follow a smearing server.

Terje

No. You are thinking of Harlan Stenn who took over the lead role more than 15 years ago. He does not live in Nebraska though, instead he migrates a bit between Oregon and California (Silicon Valley). Otherwise that comic is _exactly_ right!

Terje

Full Disclosure:
I was a very active member of the NTP Hackers team for 25+ years, network time protocol did foresee the possibility of both positive and negative leap seconds. Among other things, there's a two-bit field in every server packet where two of the four combinations indicate an upcoming plus or minus leap second, to be applied at the next UTC midnight.

That said, I am 99%+ sure that we will _not_ subtract any leap seconds in the next 100 years, and the reason is very simple:

Too many systems would fail very badly!

Over longer time scales, the Earth's rotation _will_ slow down further, adding positive leap seconds, and correcting this more short-scale speedup would therefore happen automatically. However, this is almost certainly moot because we will abolish leap seconds completely, and instead require astronomers and others who care a lot about the offset between UTC and UT1 to maintain their own tables.

Currently, GPS sats all transmit the UTC-UT1 offset in a field which can only cover about a second, so what we have been doing over the last 40 years is to measure said offset and when it got above ~0.6 seconds, the IERTS would announce a positive leap second so that the offset became -0.4 instead.

Terje

Prof Mills have done a lot of work on this particular problem, i.e. Timekeeping in the Interplanetary Internet:
https://www.eecis.udel.edu/~mi...

Terje

I've been a member of the NTP Hackers group of maintainers since the 1990'ies, over most of that time Harlan has been in charge, with close to zero resources. The only thing xkcd got wrong is that Harlan moves up and won along the US west coast, instead of Nebraska.

When Covid happened my then job went away and until I found a new one (at Cognite, a Norway-based startup), Harlan tried to come up with funding for me to move into fulltime NTP development.

I had previously written a high-perf multi-threaded version of the stock ntpd deamon, my branch version was capable of handling maybe 100 M users all polling at the minimum 64 s poll interval.

Terje

We've been at 80-90% EVs sold for a year or two now, in the morning traffic around Oslo a majority of all cars are EVs.

Yes, this has reduced the profits of many of the traditional car makers, particularly those like Toyota who has been forced (kicking and screaming) into the EV age, but it is very obvious that the air in Oslo has never (at least since the middle ages) been as clean as it is now.

There are issues with EVs, mostly related to how heavy they are (is it efficient to move more than 2 tons of hardware around just to transport a single person to/from work?), but battery-operated vehicles (from E-bikes and scooters, via motorcycles and cars to big trucks and ferries) are obviously the future of all transportation.

When we get another factor of two battery improvement (energy/kg) then commuter planes will stop using jet fuel as well.

Terje

Heavy spinning stuff, like generators and flywheels do provide quite a bit of inertia, but as you wrote, batteries can respond almost instantaneously, so the need is significantly smaller.
Here in Norway pretty much all our energy is from large-vertical-drop (i.e. very high pressure) hydro-electric generators, so we can handle load changes in a few seconds, while all those massive turbines provide all the flywheel inertia we need if a power plant falls out (400 kV line error?). In combination with onshore and offshore wind and some residential and warehouse solar we are probably good for a few decades but I would love to see a modern nuclear plant. In particular we have one of the largest known thorium deposits in the world (near Ulefoss in Telemark), that single source has enough energy for the world for 1-10K years if we can figure out how to run thorium reactors for decades, not just as a shorter term experiments which is what the US did more than 50 years ago. I am very encouraged by the current renewed interest in this area!

Terje

Just the OS/2 beta with compilers & docs cost something like 3000 NOK, so about $300 at the current rate.

Terje

In the fine article "California will now be the only government in the world that mandates zero-emission vehicles. It is unique."

So by setting a 2035 target in a single US state, this is in some way unique and more ambitious than Norway's 2025 target from nearly 10 years ago. That target is actually very close now since we've been over 80% pure EVS in both sedans and SUVs for more than a year.

I.e. if we get to 90% that's fine, for the remainder it is far more important to also speed up the switch to EV buses, trucks and construction equipment. We've already started to use batteries in ferries and at least one autonomous short-haul ship.

Terje