Hacker News Reader

Comment by c0l0 | Hacker News Reader

I guess that signals it's time for nginx users to check out possible alternatives - just in case, if things turn out for the worse.

I can recommend having a look at https://varnish-cache.org/ - while its performance might not be 100% up to par with nginx in some (very, very high-end) scenarios, it has many other fortes that nginx (at least in its FOSS release version; I've never used nginx plus) just cannot match in my experience. Having seen `varnishlog` and `varnishtest` in action alone are worth spending a day or two exploring it.

View on HN

Given how widely used nginx is, wouldn’t a community maintained fork be the most likely outcome of things changing for the worse?

The antithetic case here has precedence too (node/iojs amongst others) - "org realizes its share of the base tech has outlived its 'welcome' to no real financial benefit". But I guess a more pressing question is: can a corporate entity be "hands-off" enough so that its subsidiary has room to work as effectively as it had prior to its acquisition?

I don't have the wherewithal to get at these arguments from any angle (and I'm certain I'm missing many others).

Studious maintenance of the base code and branches/PRs besides build tried/true code bases and I hope that we're not being torn of that practice from this buyout; but only time will tell ...

The problem, of course, when all contributions are "limited" to those within the company, that the talent and expertise required to keep things going exist just in the company itself, and not in the overall open source community. So when the company behind the tech "goes away", all the knowledge does too. It's for that reason that open source that is totally under the control of one company is so dangerous. Sure, you have the ability to fork, but the reality is that such a fork is almost assuredly doomed to fail. You really are beholden to that company.

Then again most nginx users are going to be fine with haproxy/traefik in front of good old apache or lighttpd. Or even just apache.

I've replaced most of my nginx instances with traefik, except those just serving static files. The configuration is more straightforward and the EncryptIt integration is a lot more elegant than in nginx's case.

The last two companies I've worked for used træfik and haproxy, and just this last weekend I converted my home clusters from nginx to træfik.

nginx is fine, but there are now other options that work just as well.

According to the public statements, F5 is committing to maintain the current level of resources NGINX has allocated to their open source programs, to keep the same dev team involved, to keep licensing as it currently is, not change any of the repositories on Mercurial and GitHub and to keep the NGINX brand.

Which only means that NGINX will get even better over time.

Hopefully if it declines we can have a MariaDB type fork take it's place.

nginy?

But yeah, hopefully the community around it is solid enough to make that a possibility. I'd really prefer to not go back to Apache...

Pronounced "en-genie", with an oil lamp as the logo?

Incrementing all letters : "nginx" => "ohjoy"

You win

Every company that has ever acquired anything says this exact same thing. Then the deal closes and it’s back to bottom line numbers.

In this case how does f5 make or lose money from Nginx?

I guess this[1] image from the F5 article gives an idea of where nginx fits from their perspective. F5 is a huge company (4000~ employees) that already likely has thousands of boxes running nginx. If you're going to continue using nginx as a critical piece of your business you might as well secure its future.

[1]: https://www.f5.com/content/dam/f5-com/page-assets-en/home-en...

I’ve seen that a lot of times. What I haven’t seen a ton of is the acquired company still existing 5 years later.

NGINX was already paywalling bug fixes once they launched Pro.

proxy_pass for example will only resolve a hostname at the time the configuration is parsed, unless you use a convoluted variable hack. This was a serious issue requiring you to restart your fleet if a backend server changed IPs. The bug fix for this was implemented only in Pro and sold as "DNS for Service Discovery."

How’s Apache doing these days? Haven’t looked in a while

Nowhere near as fast with concurrent connections.

That is simply untrue. Apache 2.4.x w/ the Event MPM is just as fast and actually has lower latency. That FUD has long, long since been disproved.

Put a load balancer between your reverse proxy and your backends. Problem solved.

What do you think nginx was being used for?

> committing to maintain the current level of resources NGINX has allocated to their open source programs

What are the contractual consequences if they don't keep that commitment? If the answer is "none", then it's not a commitment.

Which is an interesting statement given that everyone I've run into associated with F5 - local reps or users - have been relentlessly hostile to "open source crap".

Oh boy do I have a bridge to sell to you!

We've had good experiences with https://www.envoyproxy.io.

I really like h2o (https://h2o.examp1e.net) as a nginx replacement, very nice software, lot of features, extensibility using mruby and amazing perf.

h2o is neat, although its next version has sat in beta for something like 9 months.

The same nginx I was using yesterday, I have a license for tomorrow.

You already have a license for it today, too.

Are you the person behind caddy or is your username just a coincidence?

Edit: sorry, I should have just checked your profile.

Curious, why not envoy (https://www.envoyproxy.io/)? Its open-source, used/supported by variety of companies, has more features than NGINX.

Envoy doesn't support static file serving: https://github.com/envoyproxy/envoy/issues/378

I'm sure that's not the only feature it's missing compared to nginx. Envoy is not very comparable to nginx, in my opinion... but I also wouldn't reach for varnish as an nginx alternative either.

Envoy is not the web server, it's load balancer. If you want to serve static files It will be better to use any other software. Furthermore, it is a very complex problem for HTTPS servers, because the Linux kernel doesn’t have full-featured TLS support for sendfile syscall. I implemented daemon which is used as in-memory storage for static files and client for our proprietary web server. Trust me :)

The replacement should be written in a memory-safe language. Including the TLS library.

"There is more to life than increasing its speed."

Does it start with an "R" and rhyme with "repeated-so-often-its-been-ground-into-the-dust"?

Go has the advantage in having a native mature TLS stack.

It's not a memory safe language though.

> The replacement should be written in a memory-safe language. Including the TLS library.

No. Memory safety is a vanishingly small subset of all bugs and security problems. PHP is memory-safe, for example. Where has that gotten us?

> "There is more to life than increasing its speed."

Not if you're a computer.

I'm not sure if you are trolling or not. Just in case: all rce vulns in nginx have been memory safety bugs: https://www.cvedetails.com/vulnerability-list/vendor_id-1004...

Read what I posted again.

The number of security vulnerabilities due to PHP's crappiness is two orders of magnitude greater than all of nginx vulnerabilities combined.

Yet PHP is a memory-safe language.

Memory safety won't fix anything by itself, it will just shuffle the shit into some other place.

Now if you're claiming that if you take nginx developers and force them to use Rust they'll somehow start writing better code, then that's a valid point. Although I'm in extreme doubt that it is realistic or even true.

Idunno, it seems fine to me. There are plenty of HTTP daemons that get the job done though, and if you have exacting requirements, there's nothing particularly difficult about writing your own specialized one (generally you don't have to write every feature of NGINX).

Does varnish support SSL? Last I checked, I had to run nginx in front of it for https.

https://hitch-tls.org/

Reply on news.ycombinator.com