Live data from Hacker News

We Should Ditch Nginx

hipyoungstartup.com

161–170 of 176 posts

Re: We Should Ditch Nginx

#161
post #142

Earlier quoted context omitted.

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.

It is a reaction, one that is perfectly acceptable. However to slam Nginx because they want to sell their product is an overreaction. Either accept that the Nginx creators can do what they want, or switch to Apache, but don't bitch about it. Whining that "X won't give me a feature for free" is ridiculous.

Likewise, forking from the mainline at the first sign of devs behaving badly is an overreaction. You don't throw out a team on the first sign of them doing something you don't like, that's crazy. There's nothing wrong with complaining about a conflict of interest. It only becomes a problem if the complaints continue, nothing changes, and no one forks. Then you and I will be telling people not to whine.

Re: We Should Ditch Nginx

#162
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?

It is going to the primary developers of the product.

Re: We Should Ditch Nginx

#163
post #27

Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. My team made a patch to have it log to UDP multicast, and it wasn't too bad. If you're really pissed at the nginx guys, contribute the patch back. Sure, I quibble with their approach to a commercial model, but I really think this is a case of "me thinks she doth protest too much" in both the literal and implied mea…

They wouldn't take it because it competes with the enterprise features. Do you see why this model is fundamentally incompatible with open source now?

As I said, I have quibbles with their commercial model. I get the problem.

In reality though, you can always fork, which puts pressure on them to embrace desirable patches if they are provided from outside, and to move their enterprise features into the main branch. If they keep stuff out of the their main branch that people can route around, it significantly reduces the commercial value they can realize.

Re: We Should Ditch Nginx

#164
post #27

Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. My team made a patch to have it log to UDP multicast, and it wasn't too bad. If you're really pissed at the nginx guys, contribute the patch back. Sure, I quibble with their approach to a commercial model, but I really think this is a case of "me thinks she doth protest too much" in both the literal and implied mea…

> Really, it isn't too hard to patch the logging in nginx and/or have a named pipe that writes to syslog. Be careful with high performance expectations on named pipes. The fifo is in memory, but the inode is on disk. It really sucks to block on stat() and friends when you dont expect it. Oh! And those FIFOs act as a 64kb buffer. Need more buffering? Put another pipe on it!

syslog is also a syscall, and has limited buffering. A named pipe can actually potentially amortize overhead more effectively. (And just because an inode is involved does not mean that a call to stat() involves a trip to disk.)

If you are really worried about buffering, you can always have a consumer of the named pipe with its own buffering before writing to syslog (yes, that can get ugly).

In a perfect world, I'd actually prefer to write to a ring buffer in shared memory (one per worker to avoid too much contention) and then have another process that empties it as fast as it can.

Either way, it's actually not that hard to hack in to nginx. If someone were to contribute a patch that did logging the "right" way and host it on say... github, I think you'd find the nginx commercial folks would have a response that works out pretty well for everyone. The catch is, it requires someone to do something.

Re: We Should Ditch Nginx

#165

Earlier quoted context omitted.

Others are pointing out that they routinely reject these features in the FOSS offering, citing a conflict with the enterprise edition. That's the worst part of this, imo.

I don't disagree, but my point is that the code people freely contributed prior to this change is still freely available to the public. If they are rejecting patches for features that impinge on their enterprise offerings and you have an issue with how the project is run now, you are welcome to not contribute, fork, or use another project.

>If they are rejecting patches for features that impinge on their enterprise offerings and you have an issue with how the project is run now, you are welcome to not contribute, fork, or use another project.

Which is precisely what is being argued.

Re: We Should Ditch Nginx

#166
post #162

Earlier quoted context omitted.

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

It is going to the primary developers of the product.

So it's just a nice 'screw-you' to the other people that contributed.

Re: We Should Ditch Nginx

#167
post #108

Earlier quoted context omitted.

Yeah, and other businesses have the right to conclude that they'd rather use a full-featured open source web server than one that's crippled to create a market for the expensive proprietary version. Of course, some people in this discussion seem to disagree - I've seen a lot of people acting as though it's somehow unfair to nginx for him to point this out to other potential nginx users or to switch to a different ser…

They're giving away high quality software for free, with the source code, and a liberal open source licence. They don't owe anyone shit...

you're right, they don't owe anyone anything, but no one is saying "You MUST do what I say".

The story is clearly pointing out what appears to be a flaw, that has being patched, but won't be accepted, because of a conflict of interest. It's something to make noise over, and eventually, something to fork over.

People make noise so it doesn't come to that. Very reasonable, if you ask me.

Re: We Should Ditch Nginx

#168
Nginx Pro is a bit expensive. I haven't looked into their licensing, but usually with paid software, the biggest issue is activating licenses and stuff, which can't work nicely with autoscaling. One example is when wanted to buy the commercial version of s3fs back in the day - it required running some tool on your server and emailing the guy the hardware signature so that he can email you a key for that server. I'm not saying this is the case with Nginx, but in general, the more strict you make your licensing, the less revenue you're gonna collect. FOSS that charges you for extra features is pretty much doomed - nobody wants to use the less capable version and subconsciously or consciously starts looking for alternatives. Charging for support I truly accept - that's the way to go and it keeps the attitude positive.

Re: We Should Ditch Nginx

#169
post #108

Earlier quoted context omitted.

Yeah, and other businesses have the right to conclude that they'd rather use a full-featured open source web server than one that's crippled to create a market for the expensive proprietary version. Of course, some people in this discussion seem to disagree - I've seen a lot of people acting as though it's somehow unfair to nginx for him to point this out to other potential nginx users or to switch to a different ser…

I am not against someone deciding to ditch some software in any means they believe fit. But thinking any company should go on development according to other party's demands and otherwise asking third parties to ditch the software is nonsense.

As the article states, a patch exists which implements the functionality required by the author, so the only 'demand' is to apply that patch, hardly a monumental task.

The problem here is that Nginx developers refuse to implement a free patch which already exists for a feature easily found in the competition in order to protect their business model.

Sure, what Nginx devs do is a legitimate practice, as legitimate as the author complaining about it and proposing a change of software or a fork. I don't understand why many get so upset about it.

Re: We Should Ditch Nginx

#170
post #162

Earlier quoted context omitted.

It is going to the primary developers of the product.

So it's just a nice 'screw-you' to the other people that contributed.

It is not they volunteered. These people volunteered as well for the longest time and then wanted to put some bread on the table based on their efforts. Don't see how that is a "screw you".
Post reply on HN