Live data from Hacker News

Do svidaniya, Igor, and thank you for Nginx

nginx.com

291–300 of 366 posts

Re: Do svidaniya, Igor, and thank you for Nginx

#291
post #139

Earlier quoted context omitted.

I think the irony is that newness is irrelevant once it's being used at a certain scale. You can battle test more in an hour than you could a small scale project in ten years.

How do you battle-test in an hour the ability of the upstream developer to provide security fixes? To provide updates at all as the ecosystem develops (e.g. the rise of systemd, taking advantage of advancements in worker models, SSL library API changes, new Lua versions)? Ability to keep backward compatibility with modules? Your approach might have led you to invest heavily in lighttpd at some point in time.

Also: how do you battle-test a security track record?

It takes years to to tell if serious vulnerabilities are being found often or not.

Re: Do svidaniya, Igor, and thank you for Nginx

#292

Earlier quoted context omitted.

Doing Boyer and Moore proud. I think that if you want to support all verbs, you face at least 3 'ambiguities' whether you first check the first, second, or third character of the string. (It must be at most the third, as the shortest verbs are 3 characters long.) First checking the first character is ambiguous between POST , PUT and PATCH . First checking the second character is ambiguous between HEAD , DELETE , and…

A bit of a micro-optimization, but couldn’t you interpret 4 bytes (including the trailing null on the three-letter verbs) as a 32-bit unsigned int and then do integer comparisons or a case statement?

NGINX does exactly that (after finding the space character after the verb):

https://github.com/nginx/nginx/blob/7587778a33bea0ce6f203a8c...

There are several points to note: This trick only works if the architecture supports unaligned memory access. Macros are used instead of functions, so you don't have to rely on the compiler to do inlining. The shifts and ors should get optimized out by the compiler. I once tried something similar in C#, but sadly the JIT doesn't do that optimization.

Re: Do svidaniya, Igor, and thank you for Nginx

#293
post #49

unrelated but ive always thought the F5 acquisition of NGINX made little sense. I think F5 saw the writing on the wall a little late, panicked, and bought the first competitor they could come up with that showed up in a Gartner quadrant. so much of the NGINX product that aligns with F5 as a competitive element is essentially already implemented and free by people who are already completely competent in load balancing…

F5 was very much a hardware company in a world of software vendors. The high and low end of the hardware market has shrunk rapidly as cloud has taken over. At high end, cloud providers like Amazon, Facebook and Google are building their own hardware[0] and at the other end, companies are increasingly just using those cloud providers.

For any large company, the easiest way to enter a new market is to just buy some of the competition. Of Nginx's competitors, most are either not "enterprise-y" enough (Caddy) or are already part of the CNCF (Traefik, Envoy). Really, I think the only other option could have been HaProxy.

[0] https://www.geekwire.com/2017/amazon-web-services-secret-wea...

Re: Do svidaniya, Igor, and thank you for Nginx

#294

In January 2021, Nginx took over Apache as the #1 web server on the Internet that users can install: https://i.imgur.com/pjU1G61.png https://trends.shodan.io/search?query=http+port%3A443#facet/... I'm a bit surprised it didn't happen earlier as it feels like it's been the dominant choice for tech people.

Wordpress had some say in this i think.

Definitely.

I've founded and grew several webhosters, one specialised in WordPress. Our HTTP stack was varnish->nginx(loadbalancer)->nginx->phpfpm.

It was pain. Not even WordPress core could (can?) run all its features; e.g. the SEO-friendly-URL thing relied (relies?) heavily on - I kid you not - rewriting the .htaccess file from the CMS: really: the CMS rewriting webserver configuration files from the web.

Let alone all the plugins and themes. The community of plugin and theme devs is generally professional, but there is a staggering amount of stupidity found. Like a payment-processing plugin that would write all its payments into [bankaccount-number].txt files. Web-readable. Obviously a severe security breach for one of our clients. The plugin-devs reaction? "Not a bug: we include a .htaccess that denies access to those text-files. So no-one can read them but the plugin". I can't even...

Point being: WordPress is highly coupled to Apache. If you want smooth experience of hosting, just go for Apache. Or don't use WordPress. I'd advise the latter.

Re: Do svidaniya, Igor, and thank you for Nginx

#295

Earlier 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.

No, switching creates risks. Risk of configuration errors leading to downtimes or vulnerabilities, risk of unexpected delays in deployment, risk of running into bugs that the users are unaware of.

Many software projects fail by facing delays due to excessive complexity and tech churn. Moving carefully helps.

Re: Do svidaniya, Igor, and thank you for Nginx

#296
post #173

“Igor has chosen to step back from NGINX and F5 in order to spend more time with his friends and family” I wonder what this is really about. Either way Nginx is the reason myself and many others were able to survive without raising venture capital because we didn’t need a massive horizontal cluster of Apache servers consuming 20 to 100Mb per concurrent connection. Personally I scaled above 100k current connections on…

> I wonder what this is really about. Maybe just that? That's pretty much what retirement is about, also. Doesn't say that Igor won't work on personal or even non-personal projects at all, just that more time will be available for, well, friends and family.

Perhaps. However, I do find it slightly 'off' that his departure is announced in the form of an article, and not a personal statement in which he would have more or less unavoidably had to have elaborated on the reasons for choosing this moment to depart.

At least in my personal experience, when this happens to a senior leader it's usually because they had been informed by others that they WOULD be resigning.

Re: Do svidaniya, Igor, and thank you for Nginx

#297
post #76

It 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.

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…

> That NGINX is the web server identified up front doesn't mean as much as it might because of this architectural construct.

The exact same argument can be made to explain why nginx is undercounted. A lot of setups will run nginx behind proxies, so you'll count a proxy: a Varnish, a single nginx, cloudfront servers (are they running nginx?) while in reality there may be many nginx-es running.

Nonetheless: nginx is a gift and thanks go out to Igor, regardless of how good the spiders can count the number nginx instances.

Re: Do svidaniya, Igor, and thank you for Nginx

#298
post #49

unrelated but ive always thought the F5 acquisition of NGINX made little sense. I think F5 saw the writing on the wall a little late, panicked, and bought the first competitor they could come up with that showed up in a Gartner quadrant. so much of the NGINX product that aligns with F5 as a competitive element is essentially already implemented and free by people who are already completely competent in load balancing…

They had no integration plan, so I assumed they bought it to get some street cred for the push to become a modern devops software company (instead of hardwar) and also to kill nginx as they were beginning to win sales. I used to work at nginx and F5.
Post reply on HN