Hmmm, I’m not sure I understand…

A large explosion every second has units of power, not energy. So to me this is suggesting that the train is putting out power equal to its kinetic energy per second. That’s certainly not the case — it implies that the train is powerful enough to accelerate to the speed in 1s, which is definitely not true.

But that’s just my interpretation.

I don’t think your units make sense — kinetic energy has units of energy, but “kg TNT per second” is power (about 4MW). (I think just remove the “every second” and it’s correct?)

Edit: parent edited comment.

Ok so it is fully qualified then? I’m just confused because it sounded like you were saying I wasn’t using the term correctly in your other comment.

Hmm, my understanding was that FQDN means that anyone will resolve the domain to e.g. the same IP address? Which is the case here (unless DNS rebinding mitigations or similar are employed) — but it doesn’t resolve to the same physical host in this case since it’s a private IP. Wikipedia:

A fully qualified domain name is distinguished by its lack of ambiguity in terms of DNS zone location in the hierarchy of DNS labels: it can be interpreted only in one way.

In my example, I can run nslookup jellyfin.myexample.com 8.8.8.8 and it resolves to what I expect (a local IP address).

But IANA network professional by any means, so maybe I’m misusing the term?

If you have your own domain name+control over the DNS entries, a cute trick you can use for Jellyfin is to set up a fully qualified DNS entry to point to your local (private) IP address.

So, you can have jellyfin.example.com point to 192.168.0.100 or similar. Inaccessible to the outside world (assuming you have your servers set up securely, no port forwarding), but local devices can access.

This is useful if you want to play on e.g. Chromecast/Google TV dongle but don’t want your traffic going over the Internet.

It’s a silly trick to work around the fact that these devices don’t always query the local DNS server (e.g., your router), so you need something fully qualified — but a private IP on a public DNS record works just fine!

Shoot fish with lasers. No need to compensate for refraction, problem solved.

Is there any automation available for this? Do you fix them sequentially or can you parallelize the process? How long did it take to fix 450?

Real clustermess, but curious what fixing it looks like for the boots on the ground.

Right. And if you want to self host with some geographic redundancy, it requires having friends or family with a good Internet connection who are willing to let you have a server at their place. Not impossible, but can be annoying.

I’m setting up a raspberry pi+HDD at family’s house, with wireguard to my home network. Fun stuff, but it’s not an off-the-shelf solution, especially when you consider that it’s not my Internet access, it’s theirs, so trying to be polite with bandwidth/data caps means it’s a bit kneecapped.

Wrong. I breathed in some helium once and it made my voice all high pitched which threatened my fragile masculinity. Very toxic.

(/s…)

Never worked much with cryogenics, but the one thing I learned was to never get in an elevator with (large quantities of) liquid nitrogen — if the elevator stops it can displace the oxygen and that’s…kinda bad.

A French court has ordered Google, Cloudflare, and Cisco to poison their DNS resolvers…

There are plenty of distributions without systemd — https://en.m.wikipedia.org/wiki/Category:Linux_distributions_without_systemd

Codec has huge impact.

No, it was the client — not Google — who had a backup with another provider.

You may want to check local regulations — if there’s a legal requirement to delete the data, I’d try to take advantage of that.

On a related note, I cannot recommend Immich enough! I had previously used other self hosted solutions but Immich is just fantastic — great desktop and mobile, awesome locally run ML, great shared link support, an overall awesome experience. (I’m not affiliated at all. Bit of a “gateway drug” to self hosting…)

No no no, they’re right, it won’t happen again.

…but something with a very similar outcome due to a very similar, but not identical, root cause…well, no guarantees I guess.

This suggests nginx options to use re: hostname. Unsure of your nginx config…

https://forum.syncthing.net/t/web-gui-over-nginx-proxy-only/13767

403 Forbidden doesn’t necessarily mean a bad login attempt. Are you sure that’s the error? My troubleshooting steps would be to access directly (no nginx), and look at the logs for a successful login. Then, look try to login with nginx, and look at those logs (both access.log and error.log on nginx, and any/all logs from syncthing). Find out where the two cases diverge and go from there.

Does syncthing have a domain name specified? If it doesn’t know its domain name it may work from IP directly but not via reverse proxy. Just a hunch.

I’d definitely take a look at the syncthing logs…

Can you post the syncthing logs, as well as the nginx logs?

I assume you’ve seen this: https://stackoverflow.com/questions/48626459/refused-to-execute-script-because-strict-mime-type-checking-is-enabled

Can you post your nginx config? Is it just this one with different variables? https://docs.syncthing.net/users/reverseproxy.html

Disregarding the question but commenting on the material, I don’t think this is generally true. In labeling something as forever upfront (e.g., marriage, which generally includes a “forever clause”), it’s only natural though.

Contrast marriage with a “summer fling” — the expectation is a duration of at most one summer. Not really considered a failure (which is kinda the plot of Grease, dated though that may be…)

There was a great restaurant near me (Michelin star), and it closed a while back — the owner was upfront that he just had a kid and wanted to spend more time together. I don’t think anyone views that as a failure. A loss for the community, definitely, but not a failure.