Live data from Hacker News

We Should Ditch Nginx

hipyoungstartup.com

141–150 of 176 posts

Re: We Should Ditch Nginx

#141

Earlier quoted context omitted.

First, there is no proof of how much profit comes from nginx in a stack with PHP so you can drop the 'profit greatly' line. Second, the entire point of open source software and the FOSS movement is that you shouldn't be extorted for functionality. Do you harass people that file bug reports or submit requests for features to the Linux Kernel for not paying?

The entire point of FOSS is being able to have the source code of the software you use. Period. That's it. The people who write the software can do whatever the hell they want, as can the people using the software, as long as they abide by the licence. These are the only stipulations. Even RMS supports the right of creators to sell software. People who write FOSS software aren't required to be a charity...

> People who write FOSS software aren't required to be a charity...

I think this is a point so many users of FOSS miss. I'm an ardent supporter of FOSS, but I don't get to act entitled unless I'm paying someone (and probably not even then).

Re: We Should Ditch Nginx

#142

Earlier quoted context omitted.

>No you can always fork. What are you saying 'no' to? They have a conflict of interest since they are clearly in the business of selling features. It was a statement, and saying 'you can always fork' does not refute that statement.

No it is not insensible if they start rejecting patches for needed features because they conflict with commercial goals. If you want your patches to be upstream you should make sure they must be compatible with the upstream's goals. If you do not want to obey or play along with upstream you may become an upstream yourself or pay someone to be the upstream with your goals.

Except that danenania's comment which started this entire chain of discussion was portraying switching to software with an upstream whose goals were compatible - namely Apache - as an overreaction and somehow a betrayal of open source.

Re: We Should Ditch Nginx

#143

Earlier quoted context omitted.

What I love the most about the author's post is the "fork it" part. The author goes out of his/her way to pick out what's wrong with NGINX due to the inadequate SAN infrastructure and at the end suggests someone else fork the project so his/her company can continue to milk the free software of the backs of others. It's somewhat disgusting.

>The author goes out of his/her way to pick out what's wrong with NGINX due to the inadequate SAN infrastructure Wrong. NGINX has recognized this as a problem and discovered apache solved it years ago for a reason. So they decided to play catch-up, but charge for it. >company can continue to milk the free software of the backs of others. >It's somewhat disgusting. That's FOSS. If you don't like it, don't use it. What…

I agree with you. If you don't like it don't use it.

I don't have any problems with the author's discussion on the issue's with NGINX, but the solution to the problem is not to say its time for a fork and for a better product to come along. That's pretty much an ultimatum type argument and no one likes that.

Especially if the author has no stake in the actual development. It's one thing for Linus Torvalds to be abrasive (he's earned the right) versus being abrasive without any real foundation (I didn't get the impression that the author is a strong contributor to the project).

Re: We Should Ditch Nginx

#144
post #62

Earlier quoted context omitted.

first, that price is almost certainly negotiable, particularly if you call and say "i'm running a ton of light vms for some strange reason" second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors!

>second, I think, at least for me, what bugs me is the massive entitlement on display. God forbid devs who built an awesome piece of software get paid; instead, dude whinges on the internet that he might have to gasp patch and compile an rpm or fork out some money. The horrors! On the surface yes, but consider the betrayal to all of the external contributors. Is the money going to them too? What about the people that…

So, I found myself in a similar position recently with a technically FOSS project. The patches I was submitting were being re-licensed under a commercial license and sold to enterprise customers. I had to sign contributors agreement before sending patches and after the fact I found myself having a philosophical issue with them selling my work. As a consequence, I stopped submitting patches to the main project and instead maintain my own patch repo now.

While I find the wholesale re-licensing of the codebase under a commercial license reprehensible, I agreed to that before committing code. That leaves me with one remedy, not committing additional code.

As a side note, this project had a basic FOSS version and an enterprise version with additional functionality. The only part of what they did that I took issue with is re-licensing the FOSS portion under a commercial license. Had they left the FOSS portion under the OSS license and simply added commercial code on top I would have 100% continued to commit patches.

Re: We Should Ditch Nginx

#145
post #67

Ok, fight fire with fire (inflammatory post with inflammatory response) here it goes: Scumbag Hipster Young Startup -- with a 3 floor building (mentioned CEO coming down all the way from the 3rd floor), aggregating 50M events related to sales every day, taking advantage of hundreds of thousands of volunteered man hours put into the FOSS stack they are using, are throwing a hissy fit about having to pay the creators o…

Is this money going to the external contributors as well? Volunteers that submitted patches, tests, and documentation?

Arguably you are paying for a license that covers support and the ADDITIONAL functionality. Everyone still has free access to the core code that people contributed towards.

If they were to take contributed code and lock it behind a commercial license, THEN you could get all uppity.

Re: We Should Ditch Nginx

#146

Earlier quoted context omitted.

You didn't hear what he said, he's specifically not talking about the memory hogging process bases mpm. You seem to think Apache only works that way, but the worker modules are pluggable.

He's talking about Apache MPM Worker which while offering better performance over the traditional Apache MPM Prefork because it's threaded based like NGINX is, it still consumes more RAM than NGINX does, so my point remains...

> NGINX's event based threads approach takes a big dump all over Apache's separate process lets consume every bit of available RAM the server has until it starts throwing errors and filling log files.

No your point doesn't stand, your point is completely wrong because you don't know what you're talking about. Go back read the crap you wrote before claiming your point still stands.

Re: We Should Ditch Nginx

#147

Earlier quoted context omitted.

It's perfectly reasonable to cringe at a $135K price tag. But if that's so onerous, why not spend a day compiling the source and setting it up for distribution on your servers? The answer is that you (or at least the hypothetical you) feel entitled to this software packaged how you want it with the features you want. If you want to use Apache, use Apache. That's totally your right. Or you can fork NGINX and do whatev…

>To be clear, it's perfectly fine to say, "I don't think this is a good feature to put behind the paywall." I'm just balking at the whiny and entitled tone of the original post. "How dare they ask me to pay for the things I want!" If I were trying to monetize an open source project, per Jacques's comment above, this is exactly the kind of high-scale feature I'd target for that. And you would be an anchor dragging the…

> As someone who submits patches to open source projects, I would be pretty damn pissed if the project I spent hours/days/weeks learning the architecture of pulled some shit like this.

That's a good point, and I agree. But that's not the perspective being presented by this article, as far as I can tell.

Re: We Should Ditch Nginx

#148
post #37

CloudFlare generates 50gb/s of logs globally and have handled collecting this volume in two ways. Historically the logs are sent to a local syslog-ng through the use of a PIPE and the forwarded to central logger. This can be done with nginx with no patches by just treating the PIPE as file. Just make sure you do a little buffering inside nginx. access_log /dev/nginx_access log_format_name buffer=64k flush=10s; Since…

Apologies everyone for the somewhat o/t question here but, what do you guys do with your 50Gb of logs every second? Where do they go after they leave nginx?

For most customer they are stored just long enough to provide support, create aggregates for the analytics dashboard, and update threat profiles. Our enterprise customers have the option collect raw logs through SFTP for up to 3 days.

Re: We Should Ditch Nginx

#149
post #37

CloudFlare generates 50gb/s of logs globally and have handled collecting this volume in two ways. Historically the logs are sent to a local syslog-ng through the use of a PIPE and the forwarded to central logger. This can be done with nginx with no patches by just treating the PIPE as file. Just make sure you do a little buffering inside nginx. access_log /dev/nginx_access log_format_name buffer=64k flush=10s; Since…

EDIT: Sorry wrote this after a long day. That should read per minute and not per second.

Re: We Should Ditch Nginx

#150
post #37

CloudFlare generates 50gb/s of logs globally and have handled collecting this volume in two ways. Historically the logs are sent to a local syslog-ng through the use of a PIPE and the forwarded to central logger. This can be done with nginx with no patches by just treating the PIPE as file. Just make sure you do a little buffering inside nginx. access_log /dev/nginx_access log_format_name buffer=64k flush=10s; Since…

That is a mind blowing amount of data. Is this all access/error log data, or are there other logs being generated? If it _were_ access log only, and your log lines average 1KB in length (pretty generous), that's 52m qps. If we take that further and assume each object is 93KB [1] then your outbound traffic is almost 40Tb/s (terabits per second). So I assume it must be more than just access logging! 1. https://develope…

Sorry. I wrote this after a long day and replied above that this should read per minute and not per second.
Post reply on HN