From TFA: We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.

ICANN and IANA very much are the DNS police. As a matter of fact, IANA maintains a list of special-use domains - though, despite its widespread use, .lan is not on the list - and these domains will get rejected from gTLD applications outright. The last thing I want is to require each recursive resolver to have their own idea of what should and shouldn't be resolved.

On a related note, Google owns a registry (CRR) and a recursive resolver (8.8.8.8) that's commonly used by default or as fallback. Letting them ban entire TLDs would be a massive conflict of interest.

Regarding that last point, I've had issues with dnsmasq in the past where it was remotely resolving domains even when they were configured to resolve locally. For .lan domains, this could be disastrous because I often send plaintext traffic to them. I did submit a fix/workaround[0], but it's still something to look out for. If anyone knows more about this issue or other ways queries could leak, please share!

[0]: https://github.com/openwrt/openwrt/pull/18610

Comments URL: https://news.ycombinator.com/item?id=50007353

Points: 143

# Comments: 158

Non-exhaustive list of things already named "nura":

- NURA: Premium Ingredients for Food & Wellness

- Nura - Award-winning personalised sound

- NURA: India's First Ai Powered Health Screening Center

- Nura Clinics | Pain Management Specialists In Minnesota

- Nura (German rapper)

- NURA - Shop Now for Health Essentials

- Nura | Hummus, Falafel & Shawarma

- Nura: Rise of the Yokai Clan

- Nura, a defunct consumer electronics company based in Melbourne

- Nura Space: Workplace Management Platform

Competing for this name seems like an uphill battle.

> HiddenServicePort 80 127.13.37.1:8080

> listen 127.13.37.1:8080;

This way, strangers won't be able to connect to a service bound to 127.0.0.1, should you ever decide to re-use the port and forget to disable the hidden service.

You'll also need to use separate ports and/or bind addresses if you host multiple hidden services and don't want people to correlate them - if nginx doesn't match the Host header, it will serve whichever site comes first alphabetically.

> Android provides two APIs for installing apps: a “privileged” API for things built in, and a “session” API for third-party apps. The built-in API provides key UX improvements, but is quite restricted due to the security architecture. The third-party API is not used by Google at all, and therefore it is buggy and receives sub-par maintenance. Also, Google is motivated to keep it lower quality since all apps that use it are inherently competitors to Google Play. The additional system prompts and potential instability owing to frequent changes in Google’s SDK requirements may frustrate users, particularly those who are not tech-savvy.

Other things not mentioned:

- updating applications with adb or the package installer (e.g. by downloading and opening the APK) seems to force F-Droid to show the dialog again

- applications are not eligible if their minimum API version is too low, meaning you get a prompt on every update

All in all I see no reason to put up with subpar installation UX just because Google doesn't endorse the store I use.

So... not easy? I don't suppose we're at a point where you could reasonably send a large-enough radiator for a multi-gigawatt cluster into space?

[0]: https://apt.izzysoft.de/fdroid/

This is a shame. Is the privileged extension a large maintenance burden?

What kind of views we're talking about are and how serious said politics are can vary greatly from situation to situation. From TFA:

> I kicked someone from the Nuxt Discord who had chosen an avatar (for the second time!) of a man in a Nazi uniform.