litchralee

Since this would be the phone number that you'd rely upon to have continued access to those government services, I wouldn't skimp on the expense: consider the monthly charge for a domestic phone plan as a cost of citizenship or residency.

Supposing you find and set up an eSIM with a domestic carrier in that country, then one which supports WiFi calling would allow you to receive SMS/MMS from anywhere, provided that your phone also supports WiFi connectivity.

As an aside, WiFi connectivity was greatly useful when I was traveling in Japan, since I'd be back at the hotel with WiFi in the evening, which conveniently overlapped with USA West Coast time, so calls were perfectly natural.

I'm going to try answering the titular question, despite the factual situation being wholly divorced from sanity, through no fault of the OP directly. Unless some new convention on the laws of the sea has been enacted vis-a-vis international waters -- which the Strait is -- a nation which provides some sort of service over that area is not entitled to remuneration. It would be gratis.

That said, in the very different context of aeronautical navigation, there is indeed precedence for providing a service to an international zone, but this is agreed to by multilateral treaty, not imposed. For this, we look to the massive area of the north Pacific Ocean, for which there is essentially no radar service available. And yet, to enable civil aircraft to fly without colliding with each other at speed, somebody needs to coordinate the flight routes and provide weather information. Through ICAO, the USA is the contracting state that provides such service over the Oakland Oceanic Flight Information Region. This means most of the Pacific Ocean is not USA airspace, but does follow the American procedures for organizing traffic (which follows from ICAO rules but possibly with small tweaks). This is the distinction between "USA airspace" and "USA controlled airspace". ICAO chose the USA because no other country can realistically perform this service, nor has anyone else put in an offer to ICAO.

To pay for this service, the USA FAA charges overflight fees. Since the FAA is a civil agency, it does not have authority to order a shoot-down of an airline's jets due to non-payment. Rather, the FAA can collect the owed fees through the American courts, just like anyone else would through a lawsuit for money damages. The FAA could also take adverse regulatory action, such as providing less or no service, subject to minimum obligations required by ICAO. The agency can also choose to cancel or disapprove of flights headed to/from USA airspace. If an airliner flies into the territorial airspace of any country without permission, then the air force would respond, not the civil air regulator.

So what does this have to do with international waters and maritime navigation? The air example shows how an equivalent fee for water passage would have to be implemented, when it concerns international waters. Everyone has to agree to the terms, the fee has to be economically reasonable, the contracting state must have some relationship to the area in question, and an international organization must actually contract with a qualified state to provide said service.

The present action in the Strait meets none of this criteria. So yeah, a ship could try their luck and pass through the Strait without making payment. Maritime and international law would not support the USA's claims for remuneration, even if adjudicated in an American court.

What is the absolute simplest way to accomplish this?

< gets on soap box>

The absolute simplest way is to use IPv6: on your Debian machine, assign multiple IPv6 addresses, one for each service you want to expose to your LAN. There's no penalty with having a dozen v6 addresses.

Although you have those addresses, your machine generally uses just a single one for its own outbound and inbound traffic. For each service, you would edit their config so that they bind to a specific IPv6 address. Finally, you would configure an AAAA entry in DNS so that your chosen subdomain will point to the IPv6 address in question.

As an example, suppose you had three different web servers running Nginx, currently on port 80, 8081, and 42069. What you would change is the server config for each server instance, adidng the IPv6 address as part of the "listen" directive. Since each instance is now bound to a different IP address, nginx can now listen to the conventional port 80 and n'ary will the three collide. In other software, the configuration option you're looking for is the "bind address". By binding each app to its own IP, it will only respond if you send a request to that IP (or DNS name, which translates to an IP); this conveniently makes debugging really easy.

For a home network, you might have a single /64 IPv6 subnet. But that still means you literally have billions upon billions of addresses to use before you ever run out. And as you've recognized, using DNS names to identify services is a lot easier and intuitive than using port numbers. It also neatly avoids the need to memorize IPv6 addresses, because that's never been necessary: we have DNS.

If your ISP won't give you IPv6, you can still use locally-assigned private ranges, known as ULA, and this works because your services are contained to your LAN. Best practice is to randomly generate a subnet then use it.

< gets off soap box>

Melodic dubstep when I'm debugging, metalcore when I'm developing new code.

I can't do lyrics when I'm working with GDB, and the gutteral screams help me maintain my composure as I quietly swear at the prior maintainers for leaving me with a poor foundation for my new code.

TUI users have much less tolerance for "lag"

In a lot of ways, I think software that harkens back to an older era understood the assignment exceptional well: when you're working on a glass TTY attached to a 9600 baud modem via a microwave network to the university computer in the next state over, the latency from the connection itself was pretty bad. So to then have inefficient software that "lags" would be intolerable.

Fast forward to the present day, with broadband and 1 ms latency, it's less of a concern, sure. But good software remains good software, even if the environment has improved. And for some, my work often travels with me aboard the train, where the congested 4G backhaul really makes me appreciate the miserly bandwidth of vim and SSH.

I also find myself reconfiguring systems that only have no editor installed except VI (and sed, lol) due to disk constraints. So while the command set is grossly reduced from vim, they have similar commands and workflows that I can maintain proficiency even in these sparse environments.

"Lowest common denominator" software definitely has its use-cases.

Without knowing which medication, there can only be speculation as to why it requires a specific quantity of water. And even then, the best source of authority would be to ask the doctor for the reason.

Is that something you're looking for? As a practical matter, the effort to maintain multiple release branches and backports -- compared to the norm of just maintaining a single main branch -- is an outsized effort, available to only well-funded FOSS projects, usually by having an industry sponsor that makes it a priority.

I posit that the grand majority of selfhosted FOSS software, by project count, do not have back ported branches. And so production environments will want to set up an offline validation setup to evaluate update, prior to making the switch. Not convenient, sure, but not exactly insurmountable either.

At some point, some amount of responsibility for use of FOSS software must fall upon the users, or else the project is less about creating value by building up the commons for software, and more on the exploitation/abuse of the volunteers.

Downside: breaking changes are fairly common AFAIK.

By my extremely cursory reading, this stopped being a problem after the v2.0.0 release, when they adopted semantic versioning. According, breaking changes would only occur when the major version number is rolled. And version v3.0.0 was just released 5 days ago, whereas v2.0.0 was released in October 2025.

It may be down to taste, but I view 9 months as being acceptable, given the breadth of features offered and the folks willing to put effort into the project.

There are indeed places where large amounts of human activity takes place underground, often being metro systems and their associated retail spaces; Tokyo Station in Japan comes to mind as having an underground mall attached to it.

But the same caveats for underground construction of transportation systems also apply to all other underground structures that humans would like to build. Consider the differences between ground conditions in: the San Francisco Bay Area, Denver, and New York City.

The Bay Area is the outlet for major rivers in northern California, bounded by mountain ranges on virtually all sides. The surface is either a thin covering of soil atop this mountain rock, or is a layer of looser soil or mud, made from the sediments carried in by those rivers. This makes for fantastic agricultural conditions but presents a real risk of liquifaction when there's an earthquake. While an underground structure wouldn't fall over -- because it's within the ground -- it could certainly lose its supports unless it has piles all the way down to the rock. And that's only buildable on the narrow shoreline region where there's sufficient depth before hitting the rock layer.

With Denver, it's basically all rock, so to build within the rock would require blasting it away and building within the hole, or to build normally then bury the structure in fill, so that it's below grade.

With NYC, it's a different story because the ground conditions make it fairly easy to dig tunnels and drive piles, and the bedrock layer beneath Manhattan is strong enough to support the weight of supertall-class skyscrapers. On this point, the New York Fed's Gold Vault is in the basement in Manhattan, precisely because the volume of gold inside would be a serious strain on any foundation and the geology beneath.

All that said, the surface conditions in some extreme climates may warrant building underground, or avoiding the underground outright. Burying a dwelling in New Mexico would make a lot of sense, due to the hot and dry Southwestern climate. But in Alaska, an underground dwelling would cause melting of the permafrost layer below, resulting in a similar situation to liquefaction. I suppose this can be mitigated, but it would be a monumental effort, akin to Camp Century in Greenland. That project was abandoned due to changing ice geology.

I generally shy away from downvoting even things I dislike. I don't want to fall into an echo chamber where all I see are only the things I agree with.

This is not how Lemmy works. If you don't ever up or down vote anything, and if you have your client hide the up/down votes on all comments and posts, you will still see the same content as someone who prodigiously votes. Votes here are, in the truest possible way, optional.

But for people who do utilize up/down votes, they are a signal. Sometimes they're a weak signal, sometimes a bad signal, and yet other times might be a strong signal from the community. How to evaluate the signal is a matter of continued debate.

Now, as an aside, a major difference in the Fediverse compared to commercial social media networks is that the block functionality here is used for more than just dodging abusers. Precisely because there is no algorithm, blocks and mutes are how users curate what they don't want to see. This alone does not create a so-called online echo chamber, the same way that most people don't want to see a steaming pile of poo on their morning walk. People reasonably deserve to have a pleasant experience online. And depending on their life circumstances, this might be a lot better than their IRL situation.

You can, of course, engineer reliable things from unreliable components.

I think the only way this statement can hold true in all circumstances is if we select an arbitrary boundary for what constitutes "reliable". And that's no small matter, because the threshold of reliability in a consumer IoT device would be inappropriate in a commercial or automotive setting, would be deeply wrong for industrial personnel safety, would be manifestly unlawful for a military or aerospace application, and potentially fatal for medical use.

Engineering is all about balancing a set of objectives, be it cost, time to market, efficiency, size, weight, or competitive advantage, and more. Doubling up as a way to improve reliability necessarily implicates size, complexity, and efficiency, but that's tolerable for large data centers where the customer counts servers by the number of floors, not the number of Rack Units (RU). But no one would accept installing two pacemakers because one of them might fail early; that's an intolerable solution to the product's base objective.

As it happens, most USA jurisdictions only require a single brake on a bicycle, and it doesn't even have to be on the more-effective front wheel. But the idea in law is to enforce the absolute minimum of requirements: having no brakes at all is where the line has been drawn, for a mode of transport that rarely gets above 50 kph (~30 MPH). But even then, all commercial bicycles for sale must have two brakes, so the law implicitly allows for some lost redundancy, because even one brake should be enough.

Could a bicycle brake be developed such that it is inherently always able to stop? Likely yes. Would it appreciably improve macro safety objectives such as by reducing collisions with stationary objects? No, not really.

And that's the rub: just because engineers can double up things to get more redundancy, is this any better than the alternative? If an LLM is used as a search engine, is that appreciably better than using "grep", a battle tested, secure, locally-ran application with a lineage harkening back to the 70s?

The drawback with inherent unreliability is that it can only be statistically reduced, but never eliminated. NASA understands this risk better than most, because cost pressures mean they can't be using military-grade hardware for everything. Perhaps then, it can be better said that engineers also have to balance risk in their decisions, and as it stands right now, the risk/uncertainty for LLM output is unquantifiable by any existing approach.

Academics have long been researching ways to make LLMs "safe", so that their outputs are constrainted in concrete ways. But I believe they've long concluded that the current approach of generative transformers simply cannot have safety "bolted on" after the fact. New constructions for machine learning will have to be invented with safety from day zero. The academics continue to work on that, while the commercial AI vendors are barreling ahead with LLMs, in spite of their risks and in the pursuit of a return.

I've not seen anything that would suggest the academics are wrong, nor that industry has managed to produce large safety or reliability improvements, so at this point, I only see a plateau and dead end for the industry. Maybe if the industry would put more into R&D and theoretical work, this would be a lot more graceful as they run up against the buffer stops.

If a Nintendo Wii counts as retro, there's at least one person hosting a website using one: https://infosec.exchange/@alexhaydock/114377262481451962

But that was (incredibly!) able to run a prebuilt version of NetBSD, which had drivers for the official Wii USB LAN adapter. If instead there's a piece of hardware that can boot an OS but doesn't have a network interface device, then SLIP could be useful. Here's a vape hosting a website: https://bogdanthegeek.github.io/blog/projects/vapeserver/

And if still, said retro device has no concept of IP or networking, can it at least speak serial over a 300 baud modem?