Is the title a reference to hitchhiker's guide to the galaxy or is that too far-fetched?
Do svidaniya, Igor, and thank you for Nginx
121–130 of 366 posts
Re: Do svidaniya, Igor, and thank you for Nginx
#122I remember the days circa 2009 when the Nginx docs pages still had lots of Soviet-style graphics... those were the days :)
I'd love to see this if anyone has a screenshot from this era!
Re: Do svidaniya, Igor, and thank you for Nginx
#123Earlier quoted context omitted.
except, you know, the person you're conversing with this very moment, so that's a really bad (local) first approximation!
> except, you know, the person you're conversing with this very moment, so that's a really bad (local) first approximation! Well there's that saying about all models are wrong, and some are just more useful than others. My country is thankfully becoming more secular as demographics change, so hopefully that first approximation improves over time.
because forgetting things about the only tool we have for communication, imperfect though it is, is always an improvement. How else will we rediscover them badly?
Re: Do svidaniya, Igor, and thank you for Nginx
#124Earlier quoted context omitted.
>except, of course, when it does. To a good first approximation, zero people mean "god be with you" when they say "goodbye". That might be the etymological origin of the word, but meanings shift over time.
Most people don't become polyglots either, though, so that's not a good measure of the utility. It's not a question of language-learners learning etymology would be useful to the man on the Chatham bus, it's a question of whether it is useful to language-learners. Knowing the etymology of, e.g., "goodbye" makes it click faster/not be weird when you learn, e.g, that "hello" is "Dia is Muire duit" (God and Mary be with…
and putting utility aside almost completely, it’s just pleasing to know things.
Re: Do svidaniya, Igor, and thank you for Nginx
#125Earlier quoted context omitted.
It's worse than that, the first thing that I scanned in the article is if he is alive. A title like that without a pre-defined context more often, in my native Russian perception, could mean much worse that just leaving a company. I'm glad he's doing well, I really enjoy NGINX as a casual user. It is a great gift to people. Удачи (good luck) or всего хорошего (best wishes) would not trigger such a reaction to scan th…
maybe they've updated, but the fourth paragraph is currently "we announce today Igor has chosen to step back..." which would seem to imply "not dead". but given the tone of the first three paragraphs i think even that is a bit too late in the post to clarify.
I "scanned" the article twice, so could have missed. First time I did quit, because HN comments are often more clear and useful instead of "reading" every noise they publish out there. And I did not find what I was looking for. The second time I scanned again after I posted, just to find the paragraph if it was there at all. Even if it was in the 4th originally, it's still far too off. It should have been in the first sentence of the first paragraph.
Re: Do svidaniya, Igor, and thank you for Nginx
#126Earlier quoted context omitted.
Waiting for everybody else to test the product before you migrate is perfectly common sense strategy. Especially if that product does not give you any special edge over competition.
By the mid 2010s it had definitely proved its mettle. Arguing that it wouldn't have provided enough benefit to justify the switch is different than saying it was unproven by that point.
I think some of the pressure to update products is irrational. Just because something is newer and better is not yet reason to upgrade.
If Apache did everything they needed I can imagine a company to completely forgo investigating Nginx and this might have been cause of that kind of statement. Or maybe this was just a way to explain it to younger devs who could not understand "don't break it if it works". We don't know.
The correct way to decide this kind of decision (and many other) is to look at the RoI and your available bandwidth to run multiple projects.
I am still keeping some very old (but still actively developed) products. I am busy with other projects and there just have not been any pressure to update. When I have some time available I prefer to choose a project with highest RoI rather than update stuff because of peer pressure.
Re: Do svidaniya, Igor, and thank you for Nginx
#127It still surprises me that NGINX beat out Apache so quickly even though Apache had way more modules and was/is entirely free vs. NGINX which is more or less "open core" with some nice features requiring commercial licensing.
We added Nginx to our hosting environment in front of Apache and knew a bunch of other folks who did the same. The outwardly visible adoption of Nginx was not necessarily zero-sum with Apache’s footprint at first.
In my case we scaled Drupal and Wordpress sites by using Varnish as a reverse proxy cache in front of Apache. But then we wanted to go HTTPS across the board, which Varnish does not handle. So we terminated HTTPS in Nginx and then passed the connection back to the existing Varnish/Apache stack. I know other folks just skipped or ripped out the Varnish layer and used Nginx for both HTTPS and caching.
At the time both Drupal and Wordpress (and other popular PHP projects) depended on Apache-specific features for things like pretty URLs and even security. Over time, the community engineered away from those so there was little reason to prefer Apache anymore.
Re: Do svidaniya, Igor, and thank you for Nginx
#128Earlier quoted context omitted.
By the mid 2010s it had definitely proved its mettle. Arguing that it wouldn't have provided enough benefit to justify the switch is different than saying it was unproven by that point.
I think some of the pressure to update products is irrational. Just because something is newer and better is not yet reason to upgrade. If Apache did everything they needed I can imagine a company to completely forgo investigating Nginx and this might have been cause of that kind of statement. Or maybe this was just a way to explain it to younger devs who could not understand "don't break it if it works". We don't kn…
Well I think you and I are saying the same thing. Don't chase the shiny new thing.
That said, by that time Nginx was a proven performance upgrade over Apache 1.x and 2.x. Quantifying that value is tough but it certainly had value attached to it.
Re: Do svidaniya, Igor, and thank you for Nginx
#129It still surprises me that NGINX beat out Apache so quickly even though Apache had way more modules and was/is entirely free vs. NGINX which is more or less "open core" with some nice features requiring commercial licensing.
Back when the Apache was beaten there was no commercial licensing in Nginx. Also the Apache that was beaten was Apache 1, which was fork-only, and that was the whole reason Nginx was written in the first place. Then Apache did Apache2 with mpm modules and badly missed the mark. After that Apache was doomed. No async support == dead. It was that simple.
This jives with my memory of that time as well. Apache just couldn't keep up with Nginx' async speed, and if you weren't having to deal with PHP (before FastCGI's adoption), there was no real reason to use Apache.
And post-FCGI's adoption, you didn't need to use Apache, so... why use it?
Re: Do svidaniya, Igor, and thank you for Nginx
#130Earlier quoted context omitted.
It should be remembered that NGINX is used as a reverse proxy for a lot of servers behind the scenes. That NGINX is the web server identified up front doesn't mean as much as it might because of this architectural construct. I use NGINX to front a sites that have Apache on the back end and as a result, the Internet spiders think my websites are running NGINX rather than Apache. NGINX is incredibly easy to configure a…
Granted I've done exactly this before, but why put Nginx in front of Apache? In my experience it added headaches without any real benefit. (Unless you don't mean Apache webserver but rather some other Apache product)
I have done this to host multiple services (running using multiple users and setups) from one host.