This. I've been making a game in Godot with zero AI help. Because I enjoy it. I enjoy solving with weird coding problems you run into. I enjoy leaning as I fixed things. I do it out of love for the process, knowing competition right now from things like this means a flooded market. But I'm ok with that and must be because the other option is to quit.
It will show in your game, and I think that will also continue to translate into a better chance at success even in such a swamped market. Maybe even because it's such a swamped market, players will value the games made with passion.
I have accidentally swipe-navigated far more times than I have ever purposefully swipe-navigated (zero times), so I am astounded to see someone who hasn't rage-disabled that misfeature upon installation of the OS.
I don't begrudge it being overridden here since this is a demo, but ever since, like, way early Opera era, swiping to navigate is muscle memory for me, and I prefer it both on desktop and mobile/tablet. Much simpler than reaching for the button.
Glad you have the ability to set your own preferences, but I’m pretty sure most people are happy with this. Do you by chance spend a lot of time reading PDFs while angry?
I don't use Android swipe gestures but I presume they would work in FF too. Nonetheless, we should avoid posting "it works in Chrome" as an answer to anything.
I have a deep-seated hatred for Chrome-only devs - not least of which is because it has contributed to the situation we are in, where Google is taking the "my way or the highway" approach to Chrome and adblockers, Android is locking us out of sideloaded apps, etc. Test at least in Chromium and FF as a bare minimum. Submit condescending bug reports to those stupid react components that break entire websites and nobody bothers to check, etc.
Except there's literally nothing a web page should be able to do to stop your back gestures from working, that's an OS and browser responsibility. If it isn't working it's the OS and/or browser's fault.
The *.home.arpa domain in RFC 8375 has been approved for local use since 2018, which is long enough ago that most hardware and software currently in use should be able to handle it.
RFC 8375 seems to have approved it specifically to use in Home Networking Control Protocol, though it also states "it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed. Rather, 'home.arpa.' is intended to be the correct domain for uses like the one described for '.home' in [RFC7788]: local name service in residential homenets."
Anyone familiar with HNCP? Are there any concerns of conflicts if HNCP becomes "a thing"? I have to say, .home.arpa doesn't exactly roll of the tongue like .internal. Some macOS users seem to have issues with .home.arpa too: https://www.reddit.com/r/MacOS/comments/1bu62do/homearpa_is_...
Thanks, I always mix up mold and mildew. However, "arpa" is specifically a lottery ticket, whereas there are tickets for concerts, tickets to ride, tickets in Jira etc...
Arpa is used for all kinds of random chance things, not specifically for lottery. I feel like ticket would still be the equivalent but I guess that would be more transliteration and opinion than direct translation? Also my view for lottery may be skewed due to the Finnish lottery culture, and how lottery has more meanings in English. Sorry turned ranty.
I simply quoted RFC 8375. It specifically called out that while RFC 7788 mentions ".home" (quoted below), it wasn't reserved, which ".home.arpa" aims to fix. But while you say "home.arpa is for HNCP", I also quoted RFC 8375 stating it's available for other uses as well.
> A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; [...]
I have been commandeering .home for the boxes on my LAN since forever. Why change it?
If I were going to do a bunch of extra work messing with configs I'd be far more inclined to switch all my personal stuff over to GNS for security and privacy reasons.
It's ugly and clunky, which is why after seven years it's had very little adoption. Home users aren't network engineers so these things actually do matter even if it seems silly in a technical sense.
The ".localhost" TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use
The RFC 8375 suggestion (*.home.arpa) allows for more than a single host in the domain. If not in name/feeling, but the strictest readings [and adherence] too.
Too much typing, and Chromium-based browsers don't understand it yet and try to search for mything.internal instead, which is annoying - you have to type out the whole http://mything.internal.
This can be addressed by hijacking an existing TLD for private use, e.g. mything.bb :^)
mything/ will make the OS resolve various hosts: mything., mything.local (mDNS), mything.whateverdomainyourhomenetworkuses. (which may be what you wanted).
If you want to be sure, use mything./ : the . at the end makes sure no further domains are appended during DNS lookup, and the / makes the browser try to access to resource without Googling it.
eh, you can just add search domain via dhcp or static configuration and just type out http://mything/ no need to enter whole domain unless you need todo ssl
I wrote a super basic DNS server in go (mostly fun and go practice) which allows you to specify hosts and ips in a json config file. This eliminates the need for editing your /etc/hosts file. If it matches a host in the json config file it returns that ip, else uses Cloudflare public DNS resolver as a fallback. Please; easy on my go code :-). I am a total beginner with go.
It would be great if there was an easy way to get trusted certificates for reserved domains without rolling out a CA. There are a number of web technologies that don't work without a trusted HTTPS origin, and it's such a pain in the ass to add root CAs everywhere.
*.localhost is reserved for accessing the loopback interface. It is literally the perfect use for it. In fact on many operating systems (apparently not macOS) anything.localhost already resolves to the loopback address.
> As of March 7, 2025, the domain has not been standardized by the Internet Engineering Task Force (IETF), though an Internet-Draft describing the TLD has been submitted.
> Resolved (2024.07.29.06), the Board reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications.
Minor note: authoritative servers don't have caches. I think you meant recursive resolver (or better "caching resolver" which covers other types of resolvers that may also be caching, such as some stub-resolvers).
That isn't necessarily incompatible with alternate domain name systems. If OpenNIC is registering names under .pirate and ICANN is aware of this then it can simply refrain from using .pirate as a TLD and you still have a unified namespace. It just happens by consensus rather than central authority.
If they would get along a little better then you might even have the ICANN root servers direct queries for those TLDs to the OpenNIC servers. It's not obvious what benefit is achieved by not doing this.
You may wish to read [RFC9476], which provides a solution for anchoring alternate name spaces in a way that provides both a signalling point for establishing that you've left the DNS and a way to prevent collisions with the DNS itself.
This doesn't help much to prevent collisions though, does it? An alternate namespace is obviously not going to use a TLD that already exists in the DNS, but it's much more likely to use one that exists in a different alternate namespace they've never heard of, since those will be more obscure and more likely to be missed. Putting them both under .alt does nothing to prevent this.
What you're really doing is reserving all of the as yet unallocated namespace to the DNS, privileging it over any alternatives which then have to use longer names. What you need is a mechanism for alternate namespaces to register their use of a particular subset of the global namespace against both other alternate namespaces and the DNS, at which point you wouldn't need to put them all under .alt.
They also immediately damaged that subset of the namespace:
> DNS stub and recursive resolvers do not need to look them up in the DNS context.
Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt, making it unsuitable for any namespace you would like intermediary resolvers to look up in an upstream server that supports them.
> This doesn't help much to prevent collisions though, does it?
It helps alternate name spaces not collide with the DNS. Without a registration system, it doesn't help alternate names spaces from colliding with each other (see .wallet for an example of this happening at the TLD space). There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place. EG, putting a centralized registration on top of decentralized architectures seems, um, weird at best. Supposedly the GNU naming system is creating a registration system that is optional to use. I don't know details about it and whether it's up and running yet.
The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also).
>> DNS stub and recursive resolvers do not need to look them up in the DNS context.
> Now some DNS stub resolver implementers or administrators will read this and reject any queries under .alt
So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay.
Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed.
The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD? If you want to truly revolutionize naming, then do something revolutionary and discard the current letters/numbers/etc separated by dots and create something entirely new and stop trying to look like the existing system. But that's an even harder problem because it also requires rewriting a lot of UI code. So most intentionally want to conflict with the DNS because it "helps them", theoretically, get more market space by hopefully believing that applications will suddenly be able to use an alternate naming space -- all without the user knowing they're in one?
> There was a very large, um, "discussion" about whether or not there should be a registration system for alternate spaces when many of the alternate spaces were being specifically designed because they hated registration systems in the first place.
Presumably what they hated was registration requirements.
If I need some namespace for my open source project, I can go and register a top level domain for it and all I have to do is pay $185,000 and shepherd it through a complex bureaucratic process and then pay $25,000/year forever. So corporations with more money than they know what to do with have their own top level domain that they don't even use for anything but small projects can't register one at all. Then there is nothing telling anyone else that they should pick a different TLD if they don't want a collision, and you create a default where new projects have to start out using unregistered namespace and then continue to use it as they start to get bigger.
Meanwhile you could have what amounts to an append-only wiki with some basic rules like "if your purpose needs multiple names, you get one TLD and put the rest under it" and "you have to register it again every 10 years if you're still using it". Then you wouldn't have two different things trying to use .wallet because one would have registered it first and the other would know to use something else.
> The real value (entirely IMHO) with .alt as a separation is that it allows people to figure out when they're communicate about why person A can't access the resources that person B has referred them to, is that when it ends in .alt it points toward "oh, I need to look somewhere else than the DNS" vs when it's under a TLD you'd have to know which are alternate spaces and which are not (for each person too -- see the gnu DNS also).
This seems like it would be pretty easy to look up if there was a namespace registry (and is already going to make you suspicious of this if you don't recognize the TLD), and doesn't work for the many things that already exist and don't use .alt.
> So.... let's say they don't reject them and you send a alternate name space query to a resolver that doesn't understand that alternate name space? You're still going to end up with a failed lookup, and thus just leaking alternate space queries to the DNS that can never resolve. This will look just like a rejection, but with a longer delay.
Except that the resolver might understand that alternate namespace. Suppose that OpenNIC started registering names under .alt, e.g. under .nic.alt, as this implies that they should instead of creating new TLDs. If they're the only ones using .nic.alt, recursive nameservers in general should be able to add the OpenNIC servers to their root hints and then be able to resolve those names, but now the stub resolvers will throw away the queries that might have succeeded.
> Alternate name spaces need alternate resolution mechanisms (by design), so software that wants to support both will need to figure out where that split point is so they can switch from one resolution system to another when needed.
And telling the stub resolvers to throw away the queries prevents that point from being in the upstream resolver. Most anything resolving names to IP addresses should be able to do that. You add support for it to e.g. your WiFi router or the recursive DNS resolver your company uses and then everything on your network can resolve those names.
> The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD?
Because they want to be supported by existing software. If your upstream DNS server is configured to support OpenNIC or Namecoin or what have you then you can just type those names into your unmodified browser or ssh client etc. and they get resolved.
There are many things that only want to provide an alternative to ICANN and don't have any need to provide an alternative to IP addresses or the way client applications issue name resolution queries.
I think this could go on for pages and pages more, and we can't get the entire industry to agree on the importance of any particular bullet point yet. I'd love to sit down face-to-face sometime and debate this endlessly, but I've done that with a lot of people on all sides already and there is no easy answer that any conversation has come to. It is never as easy as one side of the argument ever wants it to be.
> If I need some namespace for my open source project, I can go and register a top level domain
One common question here is: if you have an open source project, why do you need a TLD? Why is that special? the TLDs are designed into the DNS space and exceptions aren't cheap. Registering a domain under .org, or .horses is cheap compared to the $185k. And using something under .alt is free. Justifying the need for a TLD is difficult when there are other options.
>> The real thing is: why are alternate spaces even caring whether or not they look like the DNS and have a TLD?
> Because they want to be supported by existing software.
That's exactly the point I was making: the goal is to get the cheap way out trying to register part of an existing landscape rather than inventing a new universe. If the new universe is that much better, then everyone will want to deploy it anyway. As the web browser market will tell you, their applications (the only ones that most people care about these days [not me, mind you]) update ever 3 months. Getting them on board with a new universe should be trivial! In fact some browsers already support alternate spaces. Green-slate designs are often much cleaner and better when people aren't trying to do a mix of revolutionary and evolutionary approaches.
> if you have an open source project, why do you need a TLD? Why is that special?
It's not really a matter of whether it's a TLD, though that makes more sense in this context because putting it under some existing TLD like .org would imply to most people that it isn't a separate namespace. And you can see how forcing their names to be of the form myboard.chan.example.horses is putting the alternative at an unnecessary disadvantage vs. just myboard.chan or even myboard.chan.nic when neither .chan nor .nic are existing ICANN top level domains.
You also want it to be designated as a separate namespace, because it is. That makes the stakes much higher than they are for an individual domain name so it shouldn't be possible to lose it in a divorce or to a stickup artist if someone fails to renew it etc.
> That's exactly the point I was making: the goal is to get the cheap way out trying to register part of an existing landscape rather than inventing a new universe. If the new universe is that much better, then everyone will want to deploy it anyway.
Of course they don't want to invent a new universe. Who is going to use a web browser that can only resolve names in a new namespace and can't resolve youtube.com or wordpress.org? And why would someone want that, instead of being able to do both?
To provide a practical example, Tor Browser can resolve both .onion sites and ordinary web pages. Then the .onion sites can link to ordinary ones -- or vice versa, if the ordinary site is inclined to provide a link that only works in Tor Browser.
An upstream nameserver couldn't do that because it onion sites don't have an IP address to put in the response for an ordinary browser, but Namecoin sites do. Which is why there isn't a separate "Namecoin Browser" -- you don't need one.
> As the web browser market will tell you, their applications (the only ones that most people care about these days [not me, mind you]) update ever 3 months. Getting them on board with a new universe should be trivial!
I detect that you're deploying sarcasm because you know that is non-trivial. But then I'm not sure what your point is supposed to be. Are you insisting that people do the thing you know makes their endeavor more likely to fail?
> Green-slate designs are often much cleaner and better when people aren't trying to do a mix of revolutionary and evolutionary approaches.
This seems like telling someone who wants to make electric cars that they're wrong to want them to work on the same roads as gasoline cars.
You may wish to additionally read the history of the Root Server System, which was written by the Root Server Operators and provides significant more context and facts about it's development:
> I don't know the author's background, but I really hate that otherwise normal people have been reduced to such measures.
So, sorry if you read that as a complaint. But it was a feeling for how I think the world is reacting now. Not that it's necessarily bad -- as I think that after returning to normal levels of travel and in-person conversations, it's very clear to me that there was no good virtual alternative hallway conversations. That being said, it also feels like many meetings could be held virtually when there wasn't much need of true in-person interactions. However, to put one case in point: I had a fantastic trip to IETF-115 and much of that was likely because I was on-site. I'm glad I went.
It's actually a "CASEMATIX Portable Credit Card Reader Case Compatible with Square Contactless and Chip Reader, Case Only", which was the best possibility I could find. It would be nice if someone would make a dedicated case for the aranet4 as it is fairly sensitive. I'm fairly happy with this cheap case, but I'd like something that was better fit and designed for air intake, eg.
note that probably after hackernews caught the page (before all the data was in) I added a link by Boeing about this and what their belief is about CO2 levels at takeoff and in flight.
