Live data from Hacker News

Google .dev domain early access

domains.google

221–230 of 475 posts

Re: Google .dev domain early access

#221

Alphabet has too much cash. They have a well established track record of enthusiastically backing exciting new projects way outside of their core competency just to dump them like hot garbage several years later. They also compete in random new industries each time this happens. It doesn't seem like a smart move to lease a domain from a politically active mega-monopoly that might decide to randomly become your compet…

I think the risk isn't that they become your competitor, it's that an algorithm flags your website for perceived abuse and that cascades down to you and your workplace being banned forever from Google, with no recourse because they choose to provide fake support despite having $100+ billion in savings and plenty of funding for eg global tax evasion.

Re: Google .dev domain early access

#223

How long until Google will start removing domains that don't fit their "values"?

Good question. Nobody seems to know the answer here.

HN seems to be generally knowledgeable, but in this case nobody seems to be able to provide answers with good references, just guesswork. Google operates the domain. How much regulatory power it has? What is the agreement with ICANN. What is the dispute solution mechanism?

----

edit

after looking around, operator agreement with ICANN seems include public interest commitments etc. Operator can't do whatever they want and their policy should be transparent.

> Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies.

https://newgtlds.icann.org/sites/default/files/agreements/ag...

Re: Google .dev domain early access

#225
post #199
post #23

> You can purchase an SSL certificate through one of our web partners or a Certificate Authority. Read this article to learn more. Really? No mention of Lets Encrypt? Does anyone still buy certificates nowadays, especially for dev sites?

I buy them. I don't like paying for them, but I want a certificate I know will just work for years without having to run certbot or one of its clones on my server. Well, that and LE didn't yet allow wildcard certs when I bought mine. They've already dropped their maximum validity from three to two years though, so I'll probably throw in the towel when they further reduce their validity to less than six months.

Well that's nice. But that mean you'll have to manually buy, upgrade install and test them. I have better things to do.

Re: Google .dev domain early access

#226
post #205
post #12

The .dev TLD worked fine before it was bought. Now we have to use .test or .local. I don't get what Google thinks they'll get out of sponsoring putting sites under development online.

.test also works, but I like .dev more, so I have and continue to use .dev via hosts file (edit: hearing Firefox is doing the .dev HSTS preload as well, that's very disappointing to hear.) I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.

If you like .dev so much instead of .test, why not use something like subdomain.[public-domain].dev.com for all of your dev use?

It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.

Re: Google .dev domain early access

#227
post #70
post #60

Earlier quoted context omitted.

Somebody makes this post on every HN thread involving Google now. But the three big public deprecations I'm aware of are Reader, Inbox, and G+. All consumer products. All the other stuff on that killed by Google site is stuff I've barely even heard of, and all consumer products. To my knowledge, no major GCP component has ever been deprecated. Am I missing something? This seems like it has just become a groupthink HN…

> But the three big public deprecations I'm aware of are Reader, Inbox, and G+. Google Code. Also Wave and half a dozen chat apps, but Code was a serious one that broke a lot of the developer web.

This is simply incorrect. As the person who (led? handled?) the shutdown/archiving, the vast majority of the 'developer' web had gone to github. The handful of active projects were given white glove treatment once we decided to shutter the site.

Re: Google .dev domain early access

#228
post #208

Damn, now I have to change my hosts file, I've been using .dev for local development

This is common, but sadly has always been incorrect. .test is the TLD you want, specified by RFC2606.

This seems like one of those anti-patterns that has been passed down by blog posts and from engineer-to-engineer. I've seen this in almost every single developer team I've been apart of.

Either way, like you said, people should be using .test so you don't have to worry about future collisions.

Re: Google .dev domain early access

#229

Earlier quoted context omitted.

/etc/hosts doesn't accept wildcards, so you probably didn't catch much. This was settled a long time ago: https://tools.ietf.org/html/rfc2606 .test is only one more letter.

That's why I was editing it with vim. I manually added the two dozen or so names and put them in my team's git repo. .test doesn't convey the meaning I intended.

Ok, but you are wrong, just like the folks who insist on using clever DoD IP addresses instead of RFC 1918.

Re: Google .dev domain early access

#230

Earlier quoted context omitted.

Safari is the new IE8. Every web dev I know bitches about it.

Every bad web dev bitches about it. There's nothing about Safari that makes it "the new IE8". Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.

Ironically, the very same HN that bemoans every new thing as "why should devs jump onto this shiny new things, just slow down already" criticises Safari for not jumping onto every new thing.

HN is quite diverse and I'm pretty sure those are two disjoint sets of users. (I'm in the former group myself --- not a fan of presenting information in such a way as to decrease its accessibility while also increasing resource usage.)

I bet I could make those accordion sections work in all browsers going back to IE5 without much effort, and use nothing near 120KB of JS to do it... but no, most "modern web devs" would rather pile on the bloat of their libraries and "best practices" to make something that works only in the very latest version of the one browser they personally use.

Post reply on HN