That’s not the case, you just need to be able to make an outbound connection.

The minutiae of how certbot works or if that specific person actually did it right or wrong is kind of aside the point of my “intended to be funny but seemingly was not” comment about how sometimes the easiest solution to implement is the one you remember, even if it’s overkill for the immediate problem.

I think they generated real certs, rather than self signed.

This is confusing to me, because the point of the request seems to be “get a certificate”, not “get a self signed certificate generated by running the openssl command”. If you know how to get the result, it doesn’t really matter if you remembered offhand the shitty way or the overkill way.

Is it really more helpful to say “I remember how to do this, but let me lookup a different way that doesn’t use the tools I’m familiar with”?

Do you think that, in this example, using certbot is fucking shit up, or breaking something?

The thing about overkill is that it does work. If you’re accustomed to using a solution in a professional setting, it’s probably both overkill and also vastly more familiar than the bare minimum required for a class project that would be entirely unacceptable in a professional setting.

In OPs anecdote, they did get their certificates, so I don’t quite see your “intentionally fucking things up” claim as what’s happening.

I’ll be honest, I’ve had times where there’s the “simple” solution, and “the solution I remember off the top of my head”, and 10/10 the one that’s happening is the one that I remember because I just did it last week.

I have no desire to google the arguments for self signing a cert with openssl, and I cannot remember which webserver wants the cabundle and the public cert in the same file. If I had done it even kinda recently I’d still remember what to poke in the certbot config.

Well, I don’t give him too much credit for that given that it was his day job, not some passion project.

Most of the hate towards him was because he took an abrasive stance against anyone who disagreed with him, or pointed out bugs.

No, not everyone thinks it’s a bad thing. It is, however, infectious, which is a reason some people don’t like it.

Knowing why people dislike something isn’t the same as thinking it’s the worst thing ever, and liking something doesn’t mean you can’t acknowledge it’s defects.

I think it’s a net benefit, but that it would be better if they had limited the scope of the project a bit, rather than trying to put everything in the unit system.

It’s that it also decided to take over log management, event management, networking, DNS resolution, etc, etc.

If it were just an init system that would be perfectly portable. People were able to write software that way with sysv for years.

It’s that in order to do certain low level tasks on a systemd system, you need to integrate with systemd, not just “be started by it”. Now if a distro wants that piece of software, it needs to use systemd, and other pieces of software that want to be on that distro need to implement integration with systemd.

A dependency isn’t infectious, but a dependency you can’t easily swap out is, particularly if it’s positioned near the base of a dependency tree.

Almost all of my software can run on x86 or arm without any issues beyond changing compiler targets. It’s closer to how it’s tricky to port software between Mac and Linux, or Linux and BSD. Targeting one platform entails significant, potentially prohibitive, effort to support another, despite them all being ostensibly compatible unix like systems.

It’s also “infectious” software. The way systemd positions itself on the system, it can make it more difficult for software to be written in an agnostic way. This isn’t all software, and is often more of a complaint by lower level software, like desktop environments.
https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/ This isn’t a terrible summary of some of the aspects of it.

Another aspect is that when it was first developed, the lead on the project was exceptionally hostile to anyone who didn’t immediately agree that systemd definitely should take over most of the system, often criticizing people who pointed out bugs or questionable design decisions as being afraid of change or relics of the past.
It’s more of a social reason, but if people feel like the developer of a tool they’re forced to use doesn’t even respect their concerns, they’re going to start rejecting the tool.

I believe, and we’re at the edge of my understanding here, that the satellites need a consistent adjustment for local relativity. Because the satellites also have their clocks tick differently.
So they define a new time standard for the moon so that lunar operations can function based on that time standard, rather than having to recalculate relative to earth.

https://arxiv.org/abs/2402.11150

That’s the paper from NIST that’s basically the timezone part of it all.
They’re basically defining how to calibrate moon clocks so we all agree exactly how they differ from earth clocks.

That’s pretty close to what they’re doing. The tricky bit is detailing how you convert a lunar timestamp to a terrestrial timestamp.

Jostling clocks with things like leap seconds turns out to be more trouble than it’s really worth. Better to just let them get out of sync but be able to precisely define what the drift is.

So, there is an actual utility for it, it’s just not people centric.
Having a framework for how you convert the clock measurements from the lunar reference frame to terrestrial reference frame is helpful for orbital maneuvering and navigation, as well as communication coordination.

They’re not building a "UTC+5” style timezone, but a “given the moons mass and orbit, here’s how we define the time ratio between the earth and moon so we can consistently calibrate our clocks”.

They probably actually will end up with atomic clocks on the moon, or at least in close lunar orbit. If the plan is to have something like gps on the moon, that’s a first step.

It’s that relativity thing where each person will see the oscillations happening correctly, but when they look at what the other person did, the answer will seem wrong.

The difference is small enough that it really only matters if you’re NASA and building moon GPS. MPS?

It’s also important for things like GPS, as related to other planets, as well as orbital maneuvering.

What they’re actually being told to build is “write down the rules for moon time”, which is basically what you said but defined in terms of “this much faster than earth time”, and a system doing the same thing on other planets or places in the solar system.

So it’s less a timezone and more a time system, and instructions for how you calibrate your atomic clock on the moon and reconcile the difference with terrestrial clocks.

It’s well understood math, but it’s “only” relativistic orbital mechanics.

It boils down to a pretty consistent number, but how you get there is related to the weight of the moon, how far it is from earth, and how fast it’s going.
Since the moon is going different speeds at different places in it’s orbit, the number actually changes slightly over the month.

They’re just using the average though, since it makes life far easier. We use the average for earth too, since clocks move differently at different altitudes or distances from the equator.

Yup. So building a system for “how we build time systems in different reference frames” and “define how we relate those to earth” isn’t irrational, just makes for headlines that are either difficult or very misleading.

That’s actually what they’re doing. The reporting said timezone when the actual order is more about time standards.

They’re creating coordinated lunar time, as a complement to coordinated universal time, so it’s a different time system with details about how it relates to UTC.

https://www.whitehouse.gov/wp-content/uploads/2024/04/Celestial-Time-Standardization-Policy.pdf

Timezones on the moon don’t serve as much function, because the day/night cycle is closer to a month long, and doesn’t map to human rhythms at all. In a hypothetical where we have moon colonies on opposite sides of the moon, there’s no reason for them to not still have synchronized day/night, since it already has no relation to the movement of the sun in the lunar sky.

That’s actually what’s different on the moon. Relativity and all that means that time itself actually flows differently on the moon than it does on earth.

The actual problem they’re working to solve is around timekeeping and GPS applications in different reference frames, but it’s hard to make a short headline about.

So, in this case a moon timezone, and more generally a “space timekeeping framework” makes sense because time actually moves at a different speed on the moon, so epoch times wouldn’t actually stay in sync.
If the goal of “time” is to make it easier to reason about simultaneous things, then space makes that way more complicated.
It’s just tricky to condense that into a headline that conveys the point.

https://arxiv.org/abs/2402.11150