In which government is, once again, the root of the problem

I went to look at Rocky Mountain Meadery this morning, which it turns out has renamed itself Meadery of the Rockies since I last bought mead from them.  It turns out that, thanks to your tax dollars at work, Rocky Mountain Meadery — or Meadery of the Rockies — no longer ships mead interstate.

Why?

In 2005, the United States Supreme Court reaffirmed its long standing position that state laws violate the Commerce Clause if they mandate "differential treatment of in-state and out-of-state economic interests that benefit the former and burden the latter."  This rule prohibits states from permitting in-state wineries to ship wine in-state while that state prohibits out-of-state wineries from shipping wine into the state.  Consequently, states are now requiring wineries to obtain licenses to ship within and into their states.  For us to purchase 20 or more licenses, plus incur the additional cost of paper work, tax compliance, and monthly reports would be prohibitive.  Therefore, we have decided not to ship wine interstate at the present time.

So, yet another active producer of goods that has had to cut back its business, and its contribution to the overall economy, because it can no longer afford the cost of compliance with government edicts.

Personally, I think we've had about all the government we can stand.

(As for our mead supply, it turns out Redstone Meadery does ship interstate, and has way cool bottles to boot.)

In which The Steve earns my ire yet again

Specifically, for yet another "clever" Apple technology with unintended consequences.

You see, ever since getting my new machine up, I've been noticing a really excessive amount of clock drift relative to my internal stratum-3 network timeserver.  Like, six seconds per day of clock drift.  This is really bad considering I'm running ntp.  The old babylon5 had some clock drift, but never this bad.

Today, I finally found the problem.  And the problem is that mDNS is shooting me in the foot.

mDNS is Apple's multicast DNS technology, and certain Linux packages — CUPS, for one, also created at Apple — are really rather difficult to persuade not to use it.  But when you install it on linux, it never gets properly configured.  The file /etc/nss-mdns.conf — which should contain a list of domains for which mdns SHOULD resolve IP addresses — is not created, and the package doesn't tell you that you should.  What's more, there's no documentation installed on doing so.

Now, this shouldn't be a problem.  You see, here's what should, if mdns were reasonably designed, happen when, say, ntpdate tries to synchronize to a timeserver:

1. ntpdate requests an IP address for the designated timeserver.
2. nsswitch checks the /etc/hosts file.  It doesn't find the IP there, so it passes the request to mDNS.
3. mDNS checks /etc/nss-mdns.conf and finds it empty or nonexistent.  mDNS says "Oh, no domains for me to resolve, nothing for me to do here", and passes the request to DNS.
4. DNS looks up the address, passes it back to ntpdate, and ntpdate makes the connection to the correct server.

But, Apple being Apple, this is what REALLY happens:

1. ntpdate requests an IP address for the designated timeserver.
2. nsswitch checks the /etc/hosts file.  It doesn't find the IP there, so it passes the request to mDNS.
3. mDNS checks /etc/nss-mdns.conf and finds it empty or nonexistent.  mDNS says "Oh, there's no list of domains for me to resolve, but you didn't explicitly tell me NOT to resolve anything, so here, LET ME GIVE YOU SOME RANDOM IP ADDRESS THAT I PULLED OUT OF SOMEONE ELSE'S ASS BASED ON MY OWN HIDDEN COMPILED-IN DEFAULTS.  It's not even REMOTELY in your network, but what the heck, what you don't know won't hurt you, right?"
4. "Gee, ntpd is running, but my clock's still wrong.  How can that happen...?"

Apple has from time to time come up with some very good ideas.  The aforementioned CUPS, for example, works very well.  My opinion of Apple would, however, be rather less jaundiced did it not so frequently appear that when designing or implementing a technology, Apple looks at what the rest of the world is doing, then deliberately does something incompatible.¹

I disabled mdns in /etc/nsswitch.conf, restarted ntp, and SHAZAM!  Magically, just like that, my machines' clocks are perfectly synchronized.

[1]  Possibly the classic example of all time² is Apple's proprietary Appletalk network protocol, in which network address assignment is basically accomplished by jabbering.  In every OTHER network protocol that I'm aware of on the face of the planet, jabbering is considered to be a severe networking failure.  This is why, whenever an Appletalk network exceeded a certain rather small number of nodes, nodes would start just randomly dropping in and out of view on the network.  There was nothing you could do about it.  You couldn't fix it.  Apple eventually sort of fixed it, by creating Appletalk Phase II, which divided networks up into zones, and an Appletalk device could only talk to other devices in the same zone that it was in.  This didn't fix the problem, but it sort of alleviated it.  Somewhat.

[2]  Though a close runner-up is the Apple one-global-system-menubar metaphor, which was bad enough on single-monitor Macs, but really broke hard when Macs started being able to handle multiple monitors.  A list of everything that's wrong with the single-system-menubar metaphor would be a post of its own.  Yet twenty years on, MacOS users are STILL stuck with it.³  Apple insisted that This Was The Best Way To Do It, because they had called in Efficiency Experts.  What I've always wanted to know is, did the "efficiency experts" know anything whatsoever about using computers in the real world?

[3]  The saddest part is, they don't care, because The Steve Has Decreed That It Is Good.