Live data from Hacker News

Nginx to Be Acquired by F5 Networks

nginx.com

211–220 of 408 posts

Re: Nginx to Be Acquired by F5 Networks

#211
post #42
post #27

what are some good alternatives to nginx?

Nginx does a lot of things today that the erstwhile notion of a 'web server' would never have been tasked to to. So depending on what you are doing, varnish, lighttpd, apache, or haproxy (and likely more) might be used alone or in combination to match functionality.

> Nginx does a lot of things today that the erstwhile notion of a 'web server' would never have been tasked to.

Can you explain more? (Serious question, as a long-time httpd user who hasn't used nginx)

Re: Nginx to Be Acquired by F5 Networks

#212
post #176

Earlier quoted context omitted.

(Usually not the EFF; more likely Software Freedom Conservancy or someone. EFF is more digital rights and privacy stuff, not copyright.) A copyright holder can't get anything more from you by using the GPL. Infringement is infringement. The difference is that a company is usually happy to settle in exchange for a properly paid license, and an open source hacker instead is happy to settle in exchange for complying wit…

You can't actually be guaranteed to win by being in the right. You can be in the right and lose.

>> Also, lawyers are not like Pokemon. You cannot beat the opposing team's lawyers by having more stronger lawyers. You can certainly lose by having bad lawyers, but you can only be guaranteed to win by being in the right.

> You can't actually be guaranteed to win by being in the right. You can be in the right and lose.

What he's obviously saying is that there is a seriously decreasing marginal benefit to more expensive (and presumably competent) lawyers.

It's better to have competent lawyers and be right than have amazing lawyers and be wrong.

Obviously there are shades of grey, nuisance lawsuits are a thing, etc.

Re: Nginx to Be Acquired by F5 Networks

#213

So...what is the future of enterprise open source? Is there a future for enterprise open source? If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as…

Gitlab and Hashicorp are going pretty strong. Maybe they get acquired though.

Re: Nginx to Be Acquired by F5 Networks

#214
post #67

Earlier quoted context omitted.

Caddy

I found Caddy to have a lot of user-hostile behavior, and outright dangerous behavior in the way it fetches SSL certificates. It is a very bad choice for critical sites that can't go down. AWS's application load balancer with SSL is much more reliable.

I help out a lot at Caddy's community forums. I'd like to know more about your experience with Caddy.

> user-hostile behavior

Which behaviour is user-hostile? Perhaps we could address it?

> outright dangerous behavior in the way it fetches SSL certificates

For reference, Caddy uses https://github.com/xenolf/lego/ for its ACME interactions with LetsEncrypt. Could you elaborate on what part of Caddy's behaviour is _dangerous_?

> very bad choice for critical sites

What makes it a bad choice, exactly?

Re: Nginx to Be Acquired by F5 Networks

#215

Earlier quoted context omitted.

What are some of these "many ways"? because I strongly favor the quality of life under nginx over that of apache. For smaller projects, these days I reach for Caddy which is even more pleasant to use than nginx.

Not OP, but here are some (IMO big) advantages Apache has over nginx (FOSS): - Provides HTTP caching (via mod_cache) - Simplifies the deployment stack by providing built-in interpreters for dynamic languages. e.g. mod_php (i.e. you don't need php-fpm), mod_wsgi (i.e. you don't need gunicorn) - Load-balancer upstream affinity ("stickiness") based on HTTP cookies - Load-balancing based on upstream's connection count (v…

the FOSS version of nginx has great built-in caching, so I disagree there, but the others I can agree on, especially mod_php. I don't ever use PHP these days, so it's not something I routinely think about, but I'm sure Apache is better for PHP than nginx.

I feel that the let's encrypt CLI clients are plenty good for nginx, to the point that installing a new module for apache (let alone nginx) is more work than just running a CLI client.

If you want TLS automation, Caddy is superbly good at fetching its own certs, and you don't have to fiddle with installing an additional module to do it.

Re: Nginx to Be Acquired by F5 Networks

#216

So...what is the future of enterprise open source? Is there a future for enterprise open source? If you start a company and open source your core/clients, your product becomes part of AWS, and AWS runs you into the ground. If you mix in proprietary licenses to protect yourself, AWS forks your core, adds in open-source licensed clients, then runs you into the ground (and you lose open-source contributors/supporters as…

Or keep open source and do enough antitrust that businesses must compete on other axes.

Re: Nginx to Be Acquired by F5 Networks

#217
I am using F5 BigIP 5600 for quite some time now. In one line: I hate it! Can’t rename „objects“. You can’t search properly for something in a DataGroups - at least not within the UI. There is just so much that I really hate about that product. I was about to tell my chef about NGINX - well ...

Re: Nginx to Be Acquired by F5 Networks

#219

Earlier quoted context omitted.

I found Caddy to have a lot of user-hostile behavior, and outright dangerous behavior in the way it fetches SSL certificates. It is a very bad choice for critical sites that can't go down. AWS's application load balancer with SSL is much more reliable.

I help out a lot at Caddy's community forums. I'd like to know more about your experience with Caddy. > user-hostile behavior Which behaviour is user-hostile? Perhaps we could address it? > outright dangerous behavior in the way it fetches SSL certificates For reference, Caddy uses https://github.com/xenolf/lego/ for its ACME interactions with LetsEncrypt. Could you elaborate on what part of Caddy's behaviour is _dan…

I can summarize my feeling with Caddy as it's probably a good choice for solo developers with a handful of sites on a single VPS that's not terribly important. If you have something really important, I would look elsewhere.

Caddy used to put non-removable advertisements in the response headers. (That one got such a bad backlash that they backed away...)

Caddy refuses to cooperate with OS packaging teams. It reeks of self-importance. It's questionable whether caddy is really FOSS with its odd licensing arrangement.

I've seen a number of backward-incomptatible updates that break config files from point-upgrades.

Caddy EXITS with error on boot if any of its HTTPS enabled sites fail to get certificates.

Which puts your webserver in a fragile state: the server may serve happily for months (with a hidden cert error) until you restart the service. Then all your sites are down.

Migrating a live website from one server to another is (or was, until recently) quite un-supported and hard to do with zero downtime. See caddy needs DNS pointed at it before it can get the cert -- but it can't start serving pages until it has the cert.... Just not acceptable story in a high availability environment.

I understand that now caddy can share its certs with a pool of other workers which may help migration processes moving forward.

I may be bitter about this as it caused a lot of damage and downtime for my business. Not inclined to ever touch Caddy again if I can help it.

Post reply on HN