valet

I'm still seething about `.dev`. For those not in the know, Google lobbied ICANN to get the name and in their application they stated (repeatedly) that the intent was to buy it so that it could be reserved; as .dev was already used by developers and if someone bought it for commercial purposes it would harm the developer community.[0] .... they then proceeded to start selling them. Leading to all kinds of issues, the exact issues that they raised... https://github.com/basecamp/pow/issues/397 https://github.com/laravel/valet/issues/433 https://danielbachhuber.com/switch-laravel-valet-from-dev-to... https://community.localwp.com/t/dev-domain-doesnt-work/4277 https://forums.theregister.com/forum/all/2017/11/29/google_d... [0]: https://gtldresult.icann.org/applicationstatus/applicationde...

I don't think IANA explicitly reserved .dev. It was made popular as a local dev domain by Basecamp's Pow[1] and Laravel Valet[2]. IANA only defines .test, .example, .invalid, .local, and .localhost as reserved (with .onion being the latest addition in 2015[3]) Though in this list, only .test and .example are marked as non-special and must be resolved normally by RFC 6761, and .local is reserved for mDNS by RFC 6762. In this list, .test would have been the most appropriate for Pow to use. CydeWeys (Tech Lead of Google Registry) has commented on HN in the past that they did not anticipated people weren't following the best practices[4], which makes me think IANA should have given .dev the same treatment as .onion: by explicitly reserving them (but this is another topic to discuss). [1]: https://github.com/basecamp/pow [2]: https://github.co

It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we didn't anticipate how many people weren't following the best practices, but that would have been hard to determine prior to doing the thing anyway. There were also lots of people who had the mindset of "We won't change anything until it stops working", so in some sense a lot of it was unavoidable. See e.g.: https://github.com/laravel/valet/issues/204 https://github.com/laravel/valet/issues/294 https://github.com/laravel/valet

> PHP's value proposition has always been one thing - ease of deployment. I think that advantage may have been real at one time, when FTP deploys were a thing. The myth loves on. Folks that chant this praise are often not be the same folks that have to maintain the webserver side of things, though. Easy to deploy looks like this: ./foobar --port=80 > Listening on port 80, ready for traffic That could be Go, could be Rust. But not PHP. PHP webserver / application separation does bring some advantages - for example if you bring your application to a corrupted state or crash it, it will go and die. Recovery is, well "implied". But deployment wise, no. It actually seems to be a LOT harder to run PHP that at first blush. Take this example: https://github.com/laravel/valet/issues/290 Turns out if you php-fpm app one Tuesday at 15:43 starts

Valet fixed this last year. Recommend that you update: https://github.com/laravel/valet/pull/436 Although that might only change the default for new installs; you might still need to change it for existing installs. I'm not sure; I've never used Laravel.