241–250 of 301 posts
Earlier quoted context omitted.
I wish there were a site that all this stuff could be posted so we can all share in the fun. Always entertaining hearing about this stuff.
https://thedailywtf.com/ is pretty close When I read reddit (before it jumped the shark imo) there was something similar in a non-tech way called /r/idontworkherelady
Earlier quoted context omitted.
hotels.com? uber.com? stamps.com? There's lots of really big businesses built around single word domains. Not every single one of them of course, but definitely enough for good domains to be immensely valuable.
Yes, but did they sell for $1 million? Or did these "premium" domains sell for something more realistic?
PS. This behavior is quite prominent in real estate prices, they're so slow to fall down. For example the US real estate market bottomed only in 2011. You have to be very patient if you want to buy the dip in such "I will only sell for the right price!!" markets.
Earlier quoted context omitted.
Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google. I've always hated Google for egoistically claiming this tld, and ICANN for letting them.
Yes. Not nearly as many people were using .dev in local environments as you seem to think. We didn't know anyone, and by the very nature of them being fake and locally-configured-only it's not something you can easily find out about. And no, our intention was not to use .dev for fake domain names. Also, just because someone is using a fake domain doesn't preclude that from being created as a real domain name farther…
I mean, I THINK this is "properly configured", but it also isn't a huge deal to avoid. Just was annoying when it started happening. Didn't FEEL like I was misconfigured. :-)
Something that I’m surprised a lot of devs don’t know; there are official domains you’re supposed to use for documentation, testing, etc. They are specifically reserved by IANA for these purposes. Originally I think it was just example.com, but they now have a list of all them: https://www.iana.org/domains/reserved
Earlier quoted context omitted.
This is also the email I signed up to reddit with since they started requiring emails.
This is actually a dark pattern on their part, surely designed to boost email signups. The sign up page has an email box and a continue button, but you can press continue without entering an email.
Something that I’m surprised a lot of devs don’t know; there are official domains you’re supposed to use for documentation, testing, etc. They are specifically reserved by IANA for these purposes. Originally I think it was just example.com, but they now have a list of all them: https://www.iana.org/domains/reserved
Thank you, I was unaware of this. I found the relevant section in the doc that was linked from your original link: 2. TLDs for Testing, & Documentation Examples To safely satisfy these needs, four domain names are reserved as listed and described below. .test .example .invalid .localhost * ".test" is recommended for use in testing of current or new DNS related code. * ".example" is recommended for use in documentatio…
I discovered quickly that some other systems wouldn't accept the placeholder emails such as notused@email.invalid. Too many systems try to be too smart about the syntax of emails (+ subaddressing is another minefield).
Had to go back to using something like notused@invalid.toplevel.com
Earlier quoted context omitted.
ICANN should never have assigned .zip, there's just too much potential for abuse, confusion giving away a common extension as a TLD.
We just never should have allowed filename extensions to have semantic power. Resource forks are far more elegant and you could do simple look ahead checks to verify types etc.
It's easy to say "we should never have" in retrospect. But you're basically accusing programmers back in the late 70s of having insufficient foresight to see problems that would make their decisions seem bad almost half a decade later.
We also should never have let companies sell cigarettes. Or burn fossil fuels. Or start social networks.
Earlier quoted context omitted.
Using a question make in front of the term is traditionally how some browsers trigger search. They usually have a jeybconbe to add it automatically. For example, in firefox and chrome ctrl-l will clear the URL bar and put the cursor and focus there to take you to the location you enter, and ctrl-k will do similar but pre-fill the location bar with a preceding '?' so a search is triggered on the input. These shortcuts…
What's a "jeybconbe"? It's a googlewhack for this thread.
Earlier quoted context omitted.
Interesting, and makes sense, seeing as how the Web didn't yet exist when domain names were first invented, but email did. It does make sense that they were thus represented in a manner catering to that use case. In hindsight I guess we'd prefer if emails were backwards too, e.g. com.gmail@cydeweys
Only that the @ ("at") reads terribly than. So com.gmail/cydeweys maybe? Or it could be just an object in a global namespace (accesses through a protocol specific facade). So com.gmail.cydeweys
Earlier quoted context omitted.
Yes. Not nearly as many people were using .dev in local environments as you seem to think. We didn't know anyone, and by the very nature of them being fake and locally-configured-only it's not something you can easily find out about. And no, our intention was not to use .dev for fake domain names. Also, just because someone is using a fake domain doesn't preclude that from being created as a real domain name farther…
My problem was that it also broke properly configured domains. We have machines in xxx.dev.example.com (for example) that I used to rely on the resolver searching for, so I could just type "xxx.dev" and it would then know to try it with example.com banged onto the end. Then everything in .dev started resolving so my abbreviations started resolving to other hosts. I mean, I THINK this is "properly configured", but it…
In this particular case it sounds like your resolver was set up to try an external resolution first and then append an internal domain if the external resolution failed. And as you say, this clearly worked just fine for a long, long time. Then it suddenly started failing one day, for reasons unrelated to anything you changed.
At this point, most people would find it reasonable to blame the external change for breaking their fully functional, correctly working, "properly configured" setup. Some, perhaps contrarian or perhaps more cautious, would note that the "properly configured" approach only worked so long as external systems played ball. I think it might be the case that you were bitten by this assumption that seemed safe at the time, leading to the awkward and uncomfortable conclusion that your systems were indeed misconfigured.