Turning it on by default would be a massive disservice to the work that domain registries and registrars have been doing to allow Unicode to be used in domain names. In Spanish speaking countries the ñ character is pretty ubiquitous for example, and the workaround of replacing it with an n creates many problems like misdirected web traffic and typos in email addresses. Unicode in URLs and domain names is a feature, abuse should be attacked by means other than disabling it.
Well it looks like they found some references to subscriptions in an INI file, but that doesn’t mean it will require a subscription. It would be insane to try to sell new PCs with a trial Windows 12 license that’ll eventually require a subscription. I can’t imagine Windows could ever switch to a subscription model without a “base” version that’s a one-time purchase, even if it’s just for new PCs.
The local and remote port options sound exactly like something I’ve needed multiple times in the past, I’ll keep this saved for when it happens again. Great stuff!
Is VR really so ubiquitous to warrant these concerns? In my opinion most of the warnings about how this technology encourages “escaping reality” apply more to things that have had an established place in society for decades, namely phones, social media and online gaming. I have two kids and a VR headset is the least of my concerns, but they could be sucked in to the non-reality of a personal phone in two seconds if I allow it.
I set this up on my instance about a week ago and it works perfectly, thank you!
I recommend NSD or Knot for strictly authoritative servers. BIND is great too, but it is built to do both authoritative and caching DNS which makes it a bit too “big” for the task of serving only authoritative DNS data. You can definitely configure BIND to only serve authoritative data though.
I can’t comment on running from a container, I’ve always worked with NSD/Knot/BIND building directly from source.
Well, you can fact check later right? If nothing else kids will learn to be bored again, which is good.
I believe the issue is that Lemmy expects the codes to be generated using the SHA256 algorithm, while most generator apps use SHA1.
I think you still have to specify the URL up to the greader.php page, maybe in your case it would be
https://freshrss.example.com/api/greader.php