An acre of alfalfa is typically irrigated at 5.5 AF per year. The standard center pivot field is 130 acres ~ 700 AF of irrigation, to grow alfalfa to ship overseas. Converting to gallons, 210 million gallons, for one field.
80 fields of alfalfa equals all the data center water usage.
USDA estimates that total irrigation uses 55 million AF of water per year.
"In other words, we want UTC noon to be within a second of mean solar noon on the prime meridian."
Why?
If I travel 1 mile east or west of the prime meridian, my solar noon now comes 2-3 seconds earlier/later. It's nearly impossible to have your local time match your local solar noon. For most of the population, solar noon is, on average, 30 minutes off of 12:00 noon.
Um, because it's the prime meridian and that's how UTC is defined?
> It's nearly impossible to have your local time match your local solar noon.
Which is why I specified on the prime meridian, which is the particular local meridian that UTC is defined as corresponding to.
> solar noon varies from day to day by 10-20 seconds.
Which is why I was careful to specify mean solar noon.
I'm not quite sure what your issue is. Yes, we have time zones tied to specific meridians, and the actual sun's speed in the sky varies (which I mentioned in my post, so I'm not sure why you seem to think I'm unaware of it) so in most places local time by the clock doesn't match local time by the sun. Yes, a leap second adjustment to UTC is quite a bit smaller, taken in isolation, than the annual variation in actual solar time vs. mean solar time.
But over time, if we didn't have leap seconds, the difference would accumulate. The accumulated difference now between UTC and TAI is 37 seconds--which is almost twice the maximum variation in actual solar noon from mean solar noon that you refer to. We humans have collectively decided that we don't want that, and that it's better to do the adjustments a little at a time rather than in bigger lumps.
"But over time, if we didn't have leap seconds, the difference would accumulate. The accumulated difference now between UTC and TAI is 37 seconds--which is almost twice the maximum variation in actual solar noon from mean solar noon that you refer to."
No, the 10-15 seconds I mentioned is the daily variation in solar noon.
From the link I posted, in NYC, solar noon on 2026-01-01 is at 11:59am. On 2026-01-31, solar noon is at 12:09pm. In one month, it has drifted 10 minutes. That's much greater than the 37 leap seconds we have added in 60 years.
"We humans have collectively decided that we don't want that, and that it's better to do the adjustments a little at a time rather than in bigger lumps."
Yet we just reversed that decision. No more leap seconds after 2035. After trying it, we decided it was terrible.
> the 10-15 seconds I mentioned is the daily variation in solar noon.
Yes, but averaged over an entire year, it still comes out to zero. The difference between mean solar and atomic time does not. It accumulates over the years.
> we just reversed that decision
We paused it for 100 years after 2035. That doesn't change the physical fact that the Earth's rotation will continue to slow over the long term. We might eventually decide to just not care about that when it comes to civil timekeeping, but that's not what the decision you're referring to did. It just said we can afford to let the difference between UTC and TAI accumulate from 2035 to 2135 (by which time it is predicted to be about a minute) while we figure out what we want to do over the longer term.
> Um, because it's the prime meridian and that's how UTC is defined?
That's an explanation of how it is, not why we should care to preserve it.
The definitions of hours minutes and seconds have changed before, and in recent history.
> Which is why I was careful to specify mean solar noon.
And "mean solar noon" is meaningless to people's lives. Even in the areas where time zones do follow meridians and not country borders that are many minutes off.
> The definitions of hours minutes and seconds have changed before, and in recent history.
In terms of what physical process we use to set the standard, yes. But those very changes were made to try to preserve the same time periods that were important to humans. In other words, to not change what hours, minutes, and seconds mean intuitively to us humans as we go about our daily lives.
I completely disagree. The intuitive meaning is that a day is 24 hours and you can divide that by 60 twice. But that makes the second vary by some parts per billion, so we nailed down the second to make the technical side easier at the expense of relatability.
> The intuitive meaning is that a day is 24 hours and you can divide that by 60 twice.
And that's exactly why the SI second has the length that it has--to be as close as possible in terms of how atomic clocks work to 1/86400 of an Earth mean solar day at a chosen epoch. (Note that the actual definition before the atomic clock one was adopted was in terms of the Earth's tropical year at that epoch--but the fraction of the tropical year that was chosen was to line up the second with 1/86400 of an epoch day.) If we didn't care about "relatability", nobody would have gone to all the trouble of trying to determine how many cesium clock oscillations there were in 1/86400 of an epoch day.
I'm not so sure. The concept of 24 hours in a day originates in civil timekeeping, yes, but not minutes and seconds. Those originally came from astronomy, and corresponded to angles, not times, and those angles are constants; they don't change as the Earth's rotation slows down or as its speed in orbit around the Sun changes over the course of a year. I don't think people's intuitive concept of minutes and seconds is that they vary according to the time of year or the tidal effects on the Earth.
> I don't think people's intuitive concept of minutes and seconds is that they vary according to the time of year or the tidal effects on the Earth.
But if you asked people to choose between "seconds vary by an imperceptible amount, less than your clocks naturally drift" and "an hour doesn't have 3600 seconds" I bet most will pick the former.
And it doesn't have to drift day by day, you can average it over a multi-year period.
It's going to be weird once the earth slows down enough that we'd need a leap second every day or two. Once you can't ignore the drift anymore, the system we chose is significantly unintuitive.
> If we didn't care about "relatability", nobody would have gone to all the trouble of trying to determine how many cesium clock oscillations there were in 1/86400 of an epoch day.
I'm not saying we didn't care about it, I'm saying we didn't put it as top priority. We went with a nice clean fixed-length second that will drift away from the Earth over time. And it wasn't/isn't that hard to determine the number of oscillations since "matching" the Earth's unstable speed has a huge margin you can land within.
> Would you also say that getting rid of leap seconds and allowing UTC to gradually drift away from the sun is making the technical side easier at the expense of relatability?
Yes.
I'm in favor of both, to be honest. But it's a tradeoff, and it's a tradeoff that weakens the layman's definition of a second.
> we nailed down the second to make the technical side easier at the expense of relatability.
Would you also say that getting rid of leap seconds and allowing UTC to gradually drift away from the sun is making the technical side easier at the expense of relatability?
For things that need much more precusion than my lunch, ±1 second probably still isn't good enough, so they need another layer of correction anyway. Given that exists, might as well push leap seconds into that layer too.
The point is that quantizing the range makes it easier for humans to choose colors. But there's already the #ABC hex format, which while less intuitive to non-techies has the huge advantage of being well-established.
But it doesn't make it easier for humans to choose colors. For a specific list of detent colors, it reduces the amount you have to memorize relative to full RGB. But to actually reason about colors, you want a non-arbitrary scale; HSV (for instance) gives you hue direction and then you can slide saturation and brightness around.
I don’t know, but I use #ABC a lot, it’s much more convenient than #ABCDEF, never mind [0, 256) or [0, 1]. There are of course more intuitive coordinate schemes and color models, but I find RGB easy enough when you’re not actually doing serious graphic design. This is not about having a GUI color picker either, this is about hand-typing colors.
Maybe it’s just because I’m old and wrote CSS way before it got HSL or other fancy color functions, but personally, RGB colors are really deeply entrenched in my brain.
I think my thing here is, you can do any notation for colors you want. "Splash" is custom. So you might as well do a better custom. "rrb85" for "red, red, blue, 80% sat, 50% value" for a dark purple --- one step towards red from the midpoint between red and blue. I don't know, something! RGB is kind of bad!
Despite my background in color science, I find RGB more intuitive. With HSV I have to remember the chirality of hue and it's zero point, and when changing hue I find it difficult to reason about saturation. In practice this means I must "nudge and judge" with both systems. With RGB I can always make progress. With HSV I guess hue wrong about half the time. I could probably improve this.
To be fair, I'm also colorblind. That's probably relevant.
Anyway, I'd say the answer to both your questions is: "sometimes"
All you're arguing is that it's easier to memorize primary and simple secondary colors in RGB. No question, it is. Once you've got one of those detent colors locked in, how do you vary it? What does it mean to bring up i% of the first channel, j% of the second, and k% of the third? That's the problem HSV solves.
"Commercial Use" is only one part of the four prongs of the fair use test. For example, commercial Parody is generally considered Fair Use. Look at Space Balls, which is a direct transformation from Star Wars.
This is all new territory. We don't have court-settled law yet.
I'll pursue this when "they" decide to get real and make this not suck. Until then, I have sufficient alternatives.
I appreciate the writeup. It convinces me that integrated KVM stuff ~~ except for fewer wires ~~ isn't much better than the mess that's prevailed for years now, and I'm not missing much.
Why does video input source switching suck so much?
Back in the old analog CRT days I could forgive the switching latency. With today's all-digital signal paths I feel like video input switching should be pretty close to instant.
Is the technology in a broadcast switcher really so exotic and expensive?
> Is the technology in a broadcast switcher really so exotic and expensive?
No. My characterization of the problem was precision flippancy; the demand for this is niche enough that optimizing for it is a low priority, so "they" simply don't. That failure is stack-wide; the specifications around display negotiation would need extension to manage the additional state necessary for the "agile" KVM use case, and then the hardware+firmware would need to exist and become cheap, somehow despite Imaginary Property laws, so that one could hope to find it in real products.
There is regulatory friction here as well: it would complicate power management. Not infeasibly so, but enough that unless a need appears of such import that it motivates people to dare to disturb that writhing ball of copulating tapeworms, it simply won't happen.
So don't hold your breath. Unless you're relatively young, you won't live to see it. More likely, some other paradigm will obviate the problem first.
I also have a $900 monitor (provided from work) which is also a built in kvm switch, and it can show two desktops, one HDMI/windows and one usb-c/mac, side by side or as an inset as well. There's no delay switching either.
It is supposed to hot-switch the inputs if I move the mouse to the edge, but it does not, I guess it's because one of them is HDMI.
I used to have a Lenovo dock that I used as a switch, but not anymore and there's definitely less clutter.
Yeah, I read the whole article looking for any meat in there and there is none. I played with different setups as I, too, use both macos and linux. I remember doing a two screen setup where if you move the mouse to the edge of the linux screen, it appears on the macos one.
A two screen setup is not a one screen setup. I have a two screen mouse-edge setup and I was still interested to learn about being able to use a keyboard shortcut to control a monitor with a built-in KVM to switch between two computers on the same screen. That is, in fact, new to me.
