I’ve read that if you or your family depend on some kind of firewall provided by a company (and removing or disabling it is not allowed), then that firewall might outright refuse to connect to such a domain, even if the domain was never used. (Basically outright blocking .xyz at the root.) It’s not applicable in most cases but it is definitely a case of overzealous “protection” software. It’s just an unpredictable outcome and a risk. If you don’t plan on hosting email and don’t use a firewall like that, then it would be marginally acceptable.

I would still strongly recommend a .com or .net. The only advantage of using lesser known (or of low reputation) TLD is that more domains will not have been taken. I’d rather just try to be creative or pick something longer with .com.

Beyond just the registrar you pick, try not to pick some vanity TLDs. The ubiquitous ones (e.g. .com and .net) are fine. For example .xyz has a bad reputation (due to its initial low price to register, it became used for many spammers) and might be blocked in unexpected places. Others might lure you in with a cheap first year but charge much higher for subsequent years.

In addition to that, ccTLDs (country code) can be a wildcard, especially if you don’t live in the region served by it. Although rare, the country registry can seize your domain. Most commonly though, many, including .us, do not allow you to mask your personal information (WHOIS privacy). I’ve had a .me for a long time and even though they haven’t been much of a problem, they are also raising the price for renewal faster than an equivalent .com, and so I’ve been thinking of letting that domain go.

If you trust your country’s ccTLD registry and they’re reputable, that’s less of an issue, however.

Right. It’s optional so that Bash remains backwards compatible as a superset of POSIX sh. If you’re working with exclusively Bash, though, it’s nice to use as syntactic sugar if nothing else.

Bash (specifically Bash, not POSIX sh) does have a keyword for functions (function), but it’s optional.

In addition to podman unshare (which you would just prefix in front of commands like chmod), you can just temporarily do podman unshare chown -R root: <path> if you backup while the container is down. Don’t try that command on live containers.

For a more permanent solution, you can investigate which user (ID) is the default in the container and add the option --user-ns=“keep-id:uid=$the_user_id”. This does not work with all images, especially those that use multiple users per container, but if it works, the bind mount will have the same owner as the host.

To find the user ID, you can run podman exec <container> id. In most of the images I use, it’s usually 1000.