Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Freenginx: Core Nginx developer announces fork

mailman.nginx.org

Post reply on HN
Print view View original

401–410 of 501 posts

Re: Freenginx: Core Nginx developer announces fork

#401

Post by Too »

nullify88 wrote: post #381
xorcist wrote: post #368

Earlier quoted context omitted.

It doesn't drop it, it's just not persistent on reload, isn't that what you mean? Actually dropping a connection mid-request is something I haven't seen nginx (or indeed Apache) do for many years despite doing some weird things with it. I can see where you're coming from, but it's not unreasonable behaviour, is it? Connections needs to migrated over to the new worker and that's how all major servers do it. If that's…

Isn't the typical behaviour of an application to re-establish the persistent connection on demand? I wonder what the requirement is to have these persistent with no timeout.

Yep. Persistent connections are bound to fail sooner or later anyway, so a robust application should have its own recovery.

Re: Freenginx: Core Nginx developer announces fork

#404

Post by aftbit »

I dunno seems like a tempest in a teapot. Not sure why Maxim would not want CVEs to be assigned to something. Maybe it was just the final straw after a series of bad interactions. Every project has a lifespan, sometimes trying to keep them going forever is not the answer. I will miss nginx a lot if I need to migrate though.

Re: Freenginx: Core Nginx developer announces fork

#405

Post by arp242 »

MZMegaZone wrote: post #272
mike_d wrote: post #258

Earlier quoted context omitted.

QUIC in Nginx is experimental and not enabled by default. I tend to agree with him here that a WIP codebase will have bugs that might have security implications, but they aren't CVE worthy.

We know a number of customers/users have the code in production, experimental or not. And that was part of decision process. The security advisories we published do state the feature is experimental. When in doubt, err on the side of doing the right thing for the users. I find that's the best approach. I don't consider CVE a bad thing - it shouldn't be treated like a scarlet letter to be avoided. It is a unique ident…

> The question I ask is "Why not assign a CVE?"

There's tons of reasons why you wouldn't, but the core reason for this fork probably isn't really about the CVEs as such. It's either the final straw in a long line of disagreements, or the entire thing was handled was so badly that he no longer wants to work with these people. Or most likely: a combination of both.

I once quit after a small disagreement because the owner cut off my explanation on why I built something the way I did with "I don't care, just do what I say". This was after he ignored the discussion on how to design it, and ignored requests for feedback when I was building it. And look, I don't mind to re-doing it even if I don't agree it's better better, but I did put quite a lot of thought and effort in to it and thought it worked very well. If you don't even want to spend 3 minutes listening to the reasons on why it's like that then kindly go fuck yourself.

It's not the disagreement as such that matters, it's the lack of basic respect.

Re: Freenginx: Core Nginx developer announces fork

#408

Post by commandar »

janosdebugs wrote: post #333
laxis96 wrote: post #319

Earlier quoted context omitted.

Because Windows does not have a good SSH implementation and PuTTY has always worked extremely well for me as a serial and SSH terminal (also, it starts up instantly and never crashed on me). Are there any better alternatives?

Doesn't Windows ship OpenSSH these days?

It does. I use Windows Terminal and the native OpenSSH client literally daily.

Re: Freenginx: Core Nginx developer announces fork

#409

Post by commandar »

toast0 wrote: post #391
mcsniff wrote: post #389

Earlier quoted context omitted.

You trust them to run the entire OS and every stack included in it, but not to make an ssh client?

There's trust in the security sense, which yeah, you're stuck with the whole deal. But there's also trust in the rely on sense. Which at least I try to compartmentalize. I can trust Microsoft (or Google) to make an OS I can rely on to run other people's apps. If Microsoft or Google want to provide apps, they'll be evaluated as they are, not with a bias because the OS provider shipped them.

The client shipped with Windows is literally OpenSSH.
Post reply on HN