[HN Gopher] Freenginx: Core Nginx developer announces fork
       ___________________________________________________________________
        
       Freenginx: Core Nginx developer announces fork
        
       Author : bkallus
       Score  : 517 points
       Date   : 2024-02-14 18:29 UTC (4 hours ago)
        
 (HTM) web link (mailman.nginx.org)
 (TXT) w3m dump (mailman.nginx.org)
        
       | illusive4080 wrote:
       | Anyone have more info about the changes nginx made?
        
       | karolist wrote:
       | > Unfortunately, some new non-technical management at F5 recently
       | decided that they know better how to run open source projects. In
       | particular, they decided to interfere with security policy nginx
       | uses for years, ignoring both the policy and developers'
       | position.
       | 
       | Ah, I completely forgot F5 was involved in this, probably most of
       | everyone else and F5 gets no money from this. Shouldn't matter to
       | them, do they even have competition in enterprise load balancer
       | space? I spent 9 years of my career managing these devices,
       | they're rock solid and I remember some anecdotes about MS buying
       | them by the truckloads. They should be able to cover someone
       | working on nginx, maybe advertise it more for some OSS goodwill.
        
         | SteveNuts wrote:
         | The last two companies I've worked for have paid for Nginx+
         | since software LB is all we really need.
         | 
         | Handling a few thousand RPS is nothing to nginx, and doesn't
         | require fancy hardware.
         | 
         | That said, it replaced Kemp load balancers, which it seems is
         | the next biggest competitor in the hardware load balancer
         | appliance space.
        
           | karolist wrote:
           | The world has moved on in the sense that "good enough" and
           | cloud eats into their balance sheets I'm sure, but there's
           | loads and loads of banks and legacy enterprises that maintain
           | their ivory tower data centers and there's nothing to replace
           | these with AFAIK. Google has Maglev, AWS perhaps something
           | similar, MS no idea, everyone else just buys F5 or doesn't
           | need it.
        
             | JackSlateur wrote:
             | Lots of people are using haproxy
        
               | eddieroger wrote:
               | My org moved off nginx for haproxy after we learned that
               | (at the time, maybe it changed) reloading an nginx
               | config, even if done gracefully through kernel signals,
               | would drop existing connections, where haproxy could
               | handle it gracefully. That was a fun week of diving in to
               | some C code looking for why it was behaving that way.
        
               | nullify88 wrote:
               | How did you come to that conclusion? I always believed a
               | reload spawned new workers and let the old one drain off.
        
             | jvolkman wrote:
             | Amazon used to run entirely behind Citrix NetScaler
             | hardware; no F5 at all. This was back in the early 2010s so
             | I assume things have changed by now.
        
               | doormatt wrote:
               | Yup - there was a massive internal push to move off of
               | SSL terminating LBs back in ~2018
        
               | martinohansen wrote:
               | How come?
        
               | doormatt wrote:
               | Cost.
               | 
               | Now, SSL termination is done at the host level, using a
               | distributed SSL termination proxy developed by S3 called
               | "JBLRelay"
        
           | downrightmike wrote:
           | AVI if you're using VMware already
        
             | bkallus wrote:
             | I'm pretty sure that AVI just wraps Nginx, even though they
             | claim otherwise.
             | 
             | I think this because Nginx has a bunch of parsing quirks
             | that are shared with AVI and nothing else.
        
         | reactordev wrote:
         | HAProxy is an enterprise load balancer that's available through
         | Red Hat or other OSS Vendor. Nginx is just so easy to
         | configure...
        
           | bklyn11201 wrote:
           | HAProxy is a wonderful load balancer that doesn't serve
           | static files thus forcing many of us to learn Nginx to fill
           | the static-file-serving scenarios.
           | 
           | Caddy seems like a wonderful alternative that does load
           | balancing and static file serving but has wild config file
           | formats for people coming from Apache/Nginx-land.
        
             | dingnuts wrote:
             | I keep a Caddy server around and the config format is
             | actually much, much nicer than nginx's in my experience.
             | The main problem with it is that everybody provides example
             | configurations in the nginx config format, so I have to
             | read them, understand them, and translate them.
             | 
             | This works for me because I already knew a fair bit about
             | nginx configuration before picking up Caddy but it really
             | kills me to see just how many projects don't even bother to
             | explain the nginx config they provide.
             | 
             | An example of this is Mattermost, which requires WebSockets
             | and a few other config tweaks when running behind a reverse
             | proxy. How does Mattermost document this? With an example
             | nginx config! Want to use a different reverse proxy? Well,
             | I hope you know how to read nginx configuration because
             | there's no English description of what the example
             | configuration does.
             | 
             | Mastodon is another project that has committed this sin.
             | I'm sure the list is never-ending.
        
               | mholt wrote:
               | > The main problem with it is that everybody provides
               | example configurations in the nginx config format, so I
               | have to read them, understand them, and translate them.
               | 
               | This is so real. I call it "doc-lock" or documentation
               | lock-in. I don't really know a good scalable way to solve
               | this faster than the natural passage of time and growth
               | of the Caddy project.
        
               | reactordev wrote:
               | LLMs baby! Input nginx config, output caddy config. Input
               | nginx docs, output caddy docs. Someone get on this and go
               | to YC.
        
               | francislavoie wrote:
               | LLMs do a horrendous job with Caddy config as it stands.
               | It doesn't know how to differentiate Caddy v0/1 config
               | from v2 config, so it hallucinates all kinds of
               | completely invalid config. We've seen an uptick of people
               | coming for support on the forums with configs that don't
               | make any sense.
        
               | eropple wrote:
               | For just blasting a config out, I'm sure there are tons
               | of problems. But (and I have not been to your forums,
               | because...the project just works for me, it's great!)
               | I've had a lot of success having GPT4 do the first-pass
               | translation from nginx to Caddy. It's not perfect, but I
               | do also know how to write a Caddyfile myself, I'm just
               | getting myself out of the line-by-line business.
        
               | bklyn11201 wrote:
               | You're absolutely right. I'm going to do this today.
               | 
               | It's clear from this thread that a) Nginx open source
               | will not proceed at its previous pace, b) the forks are
               | for Russia and not for western companies, and c) Caddy
               | seems like absolutely the most sane and responsive place
               | to move.
        
             | mholt wrote:
             | That's the best part -- you can choose your config format
             | when using Caddy! https://caddyserver.com/docs/config-
             | adapters
        
               | bklyn11201 wrote:
               | True and I've made use of the Nginx adapter, but the
               | resulting series of error messages and JSON was too scary
               | to dive in further. The workflow that would make the most
               | sense to me (to exit Nginx-world) would be loading my
               | complex Nginx configs (100+ files) with the adapter,
               | summarizing what could not be interpreted, and then
               | writing the entirety to Caddyfile-format for me to modify
               | further. I understand that JSON to Caddyfile would be
               | lossy, but reading or editing 10k lines of JSON just
               | seems impossible and daunting.
        
               | mholt wrote:
               | Thanks for the feedback, that's good to know.
        
             | Piraty wrote:
             | > but has wild config file formats for people coming from
             | Apache/Nginx-land.
             | 
             | stockholm syndrome
        
               | Scramblejams wrote:
               | I can see that. But for me, I was so very relieved to no
               | longer deal with Apache config files after switching to
               | Caddy.
        
             | kelnos wrote:
             | A load balancer shouldn't serve static files. It shouldn't
             | serve anything. It should... load balance.
             | 
             | I can see why you'd want an all-in-one solution sometimes,
             | but I also think a single-purpose service has strengths all
             | its own.
        
             | LinuxBender wrote:
             | Just for completeness sake and probably not useful to many
             | people, HAProxy can serve a limited number of static files
             | by abusing the back-end and error pages. I have done this
             | for landing pages, directory/table of content pages. One
             | just makes a properly configured HTTP page that has the
             | desired HTTP headers embedded in it and then configure it
             | as the error page for a new back-end and use ACL's to
             | direct specific URL's to that back-end. Then just replace
             | any status codes with 200 for that back-end. Probably
             | mostly useful to those with a little hobby site or landing
             | page that needs to give people some static information and
             | the rest of the site is dynamic. This reduces moving parts
             | and reduces the risk of time-wait assassination attacks.
             | 
             | This method is also useful for abusive clients that one
             | still wishes to give an error page to. Based on traffic
             | patterns, drop them in a stick table and route those people
             | to your pre-compressed error page in the unique back-end.
             | It keeps them at the edge of the network.
        
               | TimWolla wrote:
               | FYI: Serving static files is easier and more flexible in
               | modern versions of HAProxy via the `http-request return`
               | action [1]. No need to abuse error pages and no need to
               | embed the header within the error file any longer :-) You
               | even have some dynamic generation capabilities via the
               | `lf-file` option, allowing you to embed e.g. the client
               | IP address or request ID in responses.
               | 
               | [1] https://docs.haproxy.org/dev/configuration.html#4.4-r
               | eturn
               | 
               | Disclosure: I'm a community contributor to HAProxy.
        
               | LinuxBender wrote:
               | Nice, I will have to play around with that. I admit I
               | sometimes get stuck in patterns due to old habits.
               | 
               |  _I 'm a community contributor to HAProxy._
               | 
               | I think I recall chatting with you on here or email, I
               | can't remember which. I have mostly interacted with Willy
               | in the past. He is also on here. Every interaction with
               | HAProxy developers have been educational and thought
               | provoking not to mention pleasant.
        
               | TimWolla wrote:
               | > I think I recall chatting with you on here or email, I
               | can't remember which.
               | 
               | Could possibly also have been in the issue tracker, which
               | I did help bootstrapping and doing maintenance for quite
               | a while after initially setting it up. Luckily the core
               | team has took over, since I had much less time for
               | HAProxy contributions lately.
        
         | salmo wrote:
         | I dunno about rock solid. I've had plenty of issues forcing a
         | failover/reboot, multiple complicated tickets open a year, etc.
         | But we have a sh ton of them. To be fair, some are kernel bugs
         | with connection table leaks, SNAT + UDP, etc.
         | 
         | Buuuut, they have by far the best support. They're as
         | responsive as Cisco, but every product isn't a completely
         | different thing, team, etc. And they work really well in a big
         | company used to having Network Engineering as a silo. I'd only
         | use them as physical hardware, though. As a virtual appliance,
         | they're too resource hungry.
         | 
         | Nginx or HA-Proxy are technically great for anything reasonable
         | and when fronting a small set of applications. I prefer nginx
         | because the config is easier to read for someone coming in
         | behind me. But they take a modern IT structure to support
         | because "Developers" don't get them and "Network Engineers"
         | don't have a CLI.
         | 
         | For VMWare, NSX-V HA-Proxy and NSX-T nginx config are like
         | someone read the HOWTO and never got into production ready
         | deployments. They're poorly tuned and failure recovery is
         | sloooow. AVI looked so promising, but development slowed down
         | and seemed to lose direction post acquisition. And that was
         | before Broadcom. Sigh.
        
           | kevin_nisbet wrote:
           | I'm very out of date so take my opinion with a grain of salt.
           | The customer support I received from F5 when they acquired a
           | telco product was about the worst support I've ever seen. Now
           | this wasn't the general LB equipment that F5 has the
           | reputation around, it's some specific equipment for LTE
           | networks.
           | 
           | We'd get completely bogus explanations for bugs, escalate up
           | the chain to VPs and leadership because there was an obvious
           | training, understanding, and support for complex issues
           | problem, and get the VPs trying to gaslight us into believing
           | their explanations were valid. We're talking things like on
           | our IPv4 only network, the reason we're having issues is due
           | to bugs in the equipment receiving IPv6 packets.
           | 
           | So it's one of those things where I've personally been burned
           | so hard by F5 that I'd probably to an unreasonable level look
           | for other vendors. The only thing is, this was awhile ago,
           | and the rumor's I've heard are that no one involved is still
           | employed by F5.
        
             | karolist wrote:
             | When was this? I worked with them 2009-2018, support was
             | really top notch. We could get super technical guys on the
             | call and even custom patches for our issues, but our usage
             | was relatively simple. I contrast them with McAfee products
             | we've used, now that was a complete shitshow as a product
             | and support.
        
             | salmo wrote:
             | I completely get this. I feel like every product I've had
             | outside of a vendor's wheelhouse has gone that way. We just
             | use the BigIP gear from F5 and they're better than the load
             | balancers we used in the past. Thank god Cisco just
             | abandoned that business.
             | 
             | I can't imagine them supporting telco gear. The IPv6 thing
             | has me LOLing because I just had a similar experience with
             | a vendor where we don't route IPv6 in that segment and even
             | if we did, it shouldn't break. Similarly, a vendor in a
             | space they don't belong that I imagine we bought because of
             | a golf game.
             | 
             | A thing I dread is a product we've adopted being
             | acquired... and worse, being acquired by someone extending
             | their brand into a new area. It's also why we often choose
             | a big brand over a superior product. It's not the issue of
             | today, but when they get bought and by who. I hate that so
             | much and not my decision, but it's a reality.
             | 
             | It's also a terrible sign if you're dealing with a real bug
             | and you're stuck with a sales engineer and can't get a
             | product engineer directly involved.
             | 
             | I have a list of "thou shalt not" companies as well, and
             | some may be similar where a few bad experiences ruined the
             | brand for me. Some we're still stuck with and I maaaay be
             | looking for ways to kill that.
        
       | pornel wrote:
       | I'm hoping the fork will allow having code comments.
        
       | larodi wrote:
       | Is called "rage-fork" perhaps this. So proposed title: nginx dev
       | rage-forks over security disagreement with boss company
       | 
       | But then perhaps he also has every right to do it, even though
       | AFAIR the original author was somebody else.
        
         | water-your-self wrote:
         | Why does the identity of the original author matter here?
        
           | allanrbo wrote:
           | In my opinion the original author did a really good job, so I
           | found it interesting to know where and whether he might
           | continue his vision.
           | 
           | Edit: I see now from the hg history that Igor hasn't been
           | coding on Nginx for a decade actually.
        
             | larodi wrote:
             | Indeed, the original work done by single dev (Igor) to get
             | the nginx project running was very impressive timewise, and
             | as a volume of code produced. I can't really recall why he
             | left, but with other comments around the thread implies
             | such forks have happened more than once.
             | 
             | As a sidenote I believe the people who start projects that
             | they themselves run in excellent manner, should be praised,
             | supported, noted and there is nothing more for their
             | identities to matter. It very much matters some particular
             | person with weird nick burntsushi created this wonderful
             | tool rg, and kept growing it for long time. Besides, I can
             | bet for projects such as Cosmopolitan C, it absolutely
             | matters that jart started/did it.
        
         | allanrbo wrote:
         | Igor, the original author, left in 2022 according to wikipedia:
         | https://en.wikipedia.org/wiki/Igor_Sysoev
        
         | Kluggy wrote:
         | Rage-fork doesn't show up anywhere in their announcement, nor
         | does it read like they're doing something specifically out of
         | rage.
         | 
         | Everyone has a right to forking the project. Only time will
         | tell if they get critical mass of developers to keep it going.
        
           | bklyn11201 wrote:
           | Surely "Nginx" is trademarked, copyrighted, etc. A cool and
           | collected fork would do some basic work to avoid trivial
           | lawsuits, consider the other forks already in the space, and
           | write up a bit on how this fork will be different from the
           | others.
        
             | Thoreandan wrote:
             | A quick glance at USPTO and
             | https://www.f5.com/company/policies/trademarks confirms
             | this.
        
           | MiguelHudnandez wrote:
           | It's worth pointing out that Maxim Dounin is, by himself,
           | likely critical mass for Nginx. Since he started in 2011 he
           | is by far the most active contributor to the codebase.
        
       | system2 wrote:
       | There is no news other than this individual post. I wish he could
       | describe it more. It says it is free but where is the github page
       | for it?
        
         | Y-bar wrote:
         | Source code repo is here, not everything need a Github account
         | to be free: http://freenginx.org/hg/nginx
        
         | Kluggy wrote:
         | They don't use GitHub
         | 
         | http://freenginx.org/hg/nginx
        
         | cogman10 wrote:
         | http://freenginx.org/hg/nginx
        
           | patates wrote:
           | They are using mercurial! This is such a breath of fresh air.
        
             | fmajid wrote:
             | Fossil would be a breath of fresh air, and I use mercurial
             | at work.
        
         | dvko wrote:
         | > It says it is free but where is the github page for it?
         | 
         | Not sure if serious, but you do realise that free is not at all
         | about having a GitHub page?
         | 
         | Maxim has been working on nginx for years and just forked the
         | project so that he can continue working on it. The license
         | remains the same as the original nginx project and you can
         | already download its sources here:
         | https://freenginx.org/en/download.html
        
         | davidcollantes wrote:
         | Not everyone uses GitHub. They are using something else:
         | https://freenginx.org/en/docs/contributing_changes.html
        
         | reactordev wrote:
         | There's a world of software out there that's _not_ on github or
         | using git.
         | 
         | "I don't always git clone, but when I do, it's hg clone"
        
           | karolist wrote:
           | I have mixed feeling about github's dominance. They have
           | created facebook for devs and uplifted collaboration of
           | software to a high level, but I can't help but feel like I'm
           | renting storage space in someone else's private shop when I
           | use them. Yes you get engagement, yes you get one link to
           | share your dev profile and timeline grid in CV, but it's a
           | for profit business that is run by MS.
        
             | mech422 wrote:
             | >>I have mixed feeling about github's dominance.
             | 
             | Yep - I remember what happened with Source Forge/VA Linux.
             | I actually paid for github when it first came out, just to
             | fund it.
             | 
             | Still makes me nervous tbh
        
               | karolist wrote:
               | Good old times, freshmeat.net also ;)
        
             | cellularmitosis wrote:
             | I'm much less concerned with this because github seems to
             | have to lowest vendor lock-in of any platform. If you want
             | to switch platforms, it should be as easy as changing your
             | upstream and push. Switching from MySpace to Facebook never
             | looked like that.
        
               | karolist wrote:
               | Sure you can switch, will others too? That's the problem,
               | when something gets dominating critical mass individual
               | actions stop to matter. You can replace Google with
               | another search engine as easily as opening a new tab,
               | does the dominance make it any less scary?
        
           | dylan604 wrote:
           | I was working at a startup where a potential VC sent over
           | their questionnaire with a question of where the github repo
           | was located. Since we were not using github, and using a
           | totally different git repo service, I was forced to move the
           | repo to github just because of this question.
           | 
           | Some people just don't have a clue and only know buzzwords
        
       | caycep wrote:
       | wondering also whether Igor and Maxim are ok, what w/ the
       | geopolitical situation there.
        
       | schneems wrote:
       | Can it un-swap the behavior of SIGTERM and SIGKILL please?
        
         | tyingq wrote:
         | Swap SIGTERM and SIGQUIT behavior? I don't think you can catch
         | SIGKILL.
        
           | QuinnyPig wrote:
           | Correct. The only other untrappable signal is SIGSTOP.
        
       | stefanos82 wrote:
       | I don't get it...does not he knows about angie [1]? It was
       | created by NGINX core devs after F5 acquisition if I'm not
       | mistaken and it's a drop-in replacement for NGINX.
       | 
       | [1] https://github.com/webserver-llc/angie
        
         | bemusedthrow75 wrote:
         | This surely is the question. Why _not_ Angie?
        
           | sodality2 wrote:
           | Could be related to the fact that Angie offers 'pro' version:
           | https://wbsrv.ru/angie-pro/docs/en/
           | 
           | From statement: "Instead, I'm starting an alternative
           | project, which is going to be run by developers, and not
           | corporate entities"
        
             | bemusedthrow75 wrote:
             | Hm.
             | 
             | I guess this consultancy-on-a-paid-version model doesn't
             | bother me (and clearly didn't bother the developer of
             | freenginx while they were paying him).
             | 
             | But a double fork can't be good.
        
               | bklyn11201 wrote:
               | I assume USA companies are by far the highest revenue
               | source for Nginx Plus. Both of these forks seem to be
               | based in Russia. How is a USA company supposed to pay
               | either of these vendors for their consulting or Pro
               | versions?
               | 
               | How long until F5 submits requests for domain ownership
               | of freenginx.org, and how quickly does Angie get takedown
               | requests for their features that look remarkably similar
               | to Nginx Plus features (e.g., the console)?
        
               | pests wrote:
               | > features that look remarkably similar to Nginx Plus
               | features (e.g., the console)
               | 
               | Its illegal for products in the same space to have
               | similar features?
        
               | bklyn11201 wrote:
               | Please compare the two and let us know if you think
               | "similar" is the right word.
        
               | arg98 wrote:
               | Compare what? Console/dashboard is open sourced by F5, so
               | anybody can fork: https://github.com/nginxinc/nginx-plus-
               | dashboard
        
               | pests wrote:
               | Thanks, I was trying to find the license for the nginx
               | console but thought it might just be part of the plus
               | offering only.
        
         | chomp wrote:
         | > not run by corporate entities
         | 
         | > webserver, llc
        
         | reactordev wrote:
         | angie is run by a corporate entity that could do exactly what
         | F5 did.
        
       | nginxforks2402 wrote:
       | There is another fork already from some "ex-devs from the
       | original team" https://angie.software/en/
       | https://github.com/webserver-llc/angie
        
         | bklyn11201 wrote:
         | Thanks, I've never seen this fork mentioned before. This alone
         | is compelling:
         | 
         | "Simplifying configuration: the location directive can define
         | several matching expressions at once, which enables combining
         | blocks with shared settings."
        
           | pests wrote:
           | Also owned by a for-profit company who offers a pro version.
        
             | spicykraken wrote:
             | Gotta pay the bills somehow
        
       | sevg wrote:
       | Worth noting that there are only _two_ active  "core" devs, Maxim
       | Dounin (the OP) and Roman Arutyunyan. Maxim is the biggest
       | contributor that is still active. Maxim and Roman account for
       | basically 99% of current development.
       | 
       | So this is a pretty impactful fork. It's not like one of 8 core
       | devs or something. This is 50% of the team.
       | 
       | Edit: Just noticed Sergey Kandaurov isn't listed on GitHub
       | "contributors" because he doesn't have a GitHub account (my bad).
       | So it's more like 33% of the team. Previous releases have been
       | tagged by Maxim, but the latest (today's 1.25.4) was tagged by
       | Sergey.
        
         | 687m786m78 wrote:
         | It is scary to think about how much of web relies on projects
         | maintained by 1 or 2 people.
        
           | ironmagma wrote:
           | Not that scary when you remember there are some systems that
           | haven't been significantly updated for decades (e.g. the
           | Linux TTY interface). A lot of stuff can just coast
           | indefinitely, you'll get quirks but people will find
           | workarounds. Also this is kind of why everything is ever so
           | slightly broken, IMHO.
        
             | yjftsjthsd-h wrote:
             | That only helps if it _stays_ static. For example, if the
             | Linux TTY interface was unchanged for decades to such a
             | degree that nobody worked on it, but then had a
             | vulnerability, who would be able to fix it quickly?
        
               | ironmagma wrote:
               | Perhaps someone with more knowledge can chime in. But, my
               | impression is that there are vulnerabilities with TTY,
               | it's just that we stay educated on what those are. And we
               | build systems around it (e.g. SSH) that are secure enough
               | to mitigate the effects of those issues.
        
               | codetrotter wrote:
               | SSH was a replacement for Telnet. But any weaknesses at
               | the TTY level is orthogonal to that, right?
               | 
               | Unless you mean, having thin clients use SSH as opposed
               | to directly running serial cables throughout a building
               | to VT100 style hardware terminals, and therefore being
               | vulnerable to eavesdropping and hijacking?
               | 
               | But I think when we talk about TTY we mostly don't refer
               | to that kind of situation.
               | 
               | If someone talks about TTY today, I assume they mean the
               | protocol and kernel interfaces being used. Not any kind
               | of physical VT100 style serial communication terminals.
        
               | TylerE wrote:
               | I wonder how many of these things that are just coasting
               | are gonna have issues in 14 years.
        
             | szundi wrote:
             | Not the web though
        
               | ironmagma wrote:
               | Certainly the web can mostly coast indefinitely. There
               | are webpages from decades ago that still function fine,
               | even that use JavaScript. The web is an incredibly stable
               | platform all things considered. In contrast, it's hard to
               | get a program that links to a version of Zlib from 10
               | years ago running on a modern Linux box.
        
               | quickthrower2 wrote:
               | The web is the calm looking duck that is paddling
               | frantically. You want to be using SSL from the 90s, or IE
               | vs. Netscape as your choice etc. Nostalgia aside!
        
               | 5- wrote:
               | this problem -- great forward compatibility of the web --
               | has been taken care of with application layer encryption,
               | deceitfully called "transport layer" security (tls)
        
               | colechristensen wrote:
               | HTTP 1.1 isn't really changing is it?
               | 
               | That and a small collection of other things are standards
               | based and not going though changes.
        
               | mynameisvlad wrote:
               | Sure, but HTTP3 was proposed in 2022.
        
             | the_duke wrote:
             | Nginx is still evolving a lot though.
             | 
             | Eg: http3 support was stabilized with 1.25.1 , which came
             | out June 2023.
        
             | Gormo wrote:
             | > Also this is kind of why everything is ever so slightly
             | broken, IMHO.
             | 
             | OTOH, things that update too often seem to be _more_ than
             | slightly broken on an ongoing basis, due to ill-advised
             | design changes, new bugs and regressions, etc.
        
               | ironmagma wrote:
               | I am thinking with things that don't update often, we
               | just get used to the broken parts. People learned to save
               | every five minutes in Maya since the app crashes so
               | often, for example. Every now and then, a PuTTY session
               | will fill the screen with
               | "PuTTYPuTTYPuTTYPuTTYPuTTY[...]" but it's been that way
               | for at least 20 years, so it's not that remarkable.
        
           | hadlock wrote:
           | This is your semi-annual reminder to fork and archive offline
           | copies of everything you use in your stack.
        
             | Dylan16807 wrote:
             | There's plenty of copies of the code. That doesn't help
             | with the actual problems with the setup.
        
           | Thaxll wrote:
           | For the vast majority of use cases nginx from 10 years ago
           | would not make a difference. You actually see the nginx
           | version on some html pages and very often it's old.
        
           | jackcviers3 wrote:
           | It's not that scary. If a project everyone depends on is
           | broken and unmaintained, someone else will manufacture a
           | replacement fairly quickly and people will vote with their
           | feet.
           | 
           | NGINX is the de facto standard today, but I can remember
           | running servers off apache when I began professionally
           | programming. I remember writing basic cross-broweser spas
           | with script.aculous, and prototypejs in 2005, before bundlers
           | and react and node.
           | 
           | Everything gets gradually replaced, eventually.
        
             | quickthrower2 wrote:
             | You can also probably host without a reverse proxy. Also
             | there are alternatives like Caddy. IIS!! And I imaging the
             | big cloud would swoop in and help since their expensive
             | CDNs and gateways will rely on it, or maybe Kubernetes
             | maintainers, since most likely they use it.
        
             | syslog wrote:
             | I still deploy Apache httpd, because that's what I know
             | best, and it works.
        
               | ktm5j wrote:
               | Same. I really only tend to use nginx as a glorified
               | proxy. And I love it for that purpose, it's super simple
               | to setup and manage.. but this drama might make me think
               | twice about deploying more nginx in the future. Will be
               | interesting to watch this play out.
        
           | mrtksn wrote:
           | Obligatory XKCD: https://xkcd.com/2347/
        
           | EasyMark wrote:
           | I don't worry when it's open source, as if it's that valuable
           | someone will pick it up, or corps would be forced to. I do
           | wish those 1 or 2 devs got more support monetarily from the
           | huge corps benefitting.
        
           | maxamillion wrote:
           | Evergreen xkcd is evergreen. https://xkcd.com/2347/
        
           | up2isomorphism wrote:
           | I think it is far less scary than the fact Joe Biden has the
           | nuke launch code.
        
             | ARandomerDude wrote:
             | _Had_ a nuclear launch code. He doesn't remember it
             | anymore.
        
         | nimbius wrote:
         | >freenginx.org
         | 
         | IANAL, but i strongly recommend reconsidering the name as the
         | current one contains a trademark.
        
           | tiffanyh wrote:
           | They could take the Postgres naming approach.
           | 
           | Ingress was forked; the Post fork version of Ingress was
           | called "Post"gres.
           | 
           | So maybe name this new project "PostX" (for Post + nginx).
           | 
           | Though that might sound too similar to posix.
        
             | virtualwhys wrote:
             | "Postginx" has a nice ring to it, could be an alcoholic
             | beverage, a name of a generation, or even a web server.
        
             | icybox wrote:
             | ... and postfix
        
             | anotherhue wrote:
             | Go roman? nginxii ?
        
             | Nijikokun wrote:
             | Postgres name is said to be a reference to ingres db, not a
             | fork of ingres.
             | 
             | > The INGRES relational database management system (DBMS)
             | was implemented during 1975-1977 at the Univerisity of
             | California. Since 1978 various prototype extensions have
             | been made to support distributed databases [STON83a],
             | ordered relations [STON83b], abstract data types [STON83c],
             | and QUEL as a data type [STON84a]. In addition, we proposed
             | but never prototyped a new application program interface
             | [STON84b]. The University of California version of INGRES
             | has been ''hacked up enough'' to make the inclusion of
             | substantial new function extremely difficult. Another
             | problem with continuing to extend the existing system is
             | that many of our proposed ideas would be difficult to
             | integrate into that system because of earlier design
             | decisions. Consequently, we are building a new database
             | system, called POSTGRES (POSTinGRES).
             | 
             | [https://dsf.berkeley.edu/papers/ERL-M85-95.pdf]
        
           | patrickmay wrote:
           | nginy?
        
             | austinjp wrote:
             | Bump each letter in nginx and we get.... ohjoy!
        
       | sschueller wrote:
       | Is this what the security disagreements is about
       | https://mailman.nginx.org/pipermail/nginx-announce/2024/NW6M...?
        
         | MZMegaZone wrote:
         | Yep. Maxim did not want CVEs assigned.
        
           | tptacek wrote:
           | MegaZone as in Usenet MegaZone?
        
             | MZMegaZone wrote:
             | No, a MegaZone. Haven't you heard, we come in six packs
             | now. ;-)
             | 
             | Yeah, very, very likely one and the same. Since 1989.
        
               | tptacek wrote:
               | Wow, that's a throwback. I was an ISP person back in the
               | Portmaster era. You're at F5 now, I guess!
               | 
               | Can you say more about the CVE thing? That seems like the
               | opposite of what Maxim Dounin was saying.
        
               | MZMegaZone wrote:
               | Yeah, I've been with F5 since 2010 - gotta love those old
               | PortMasters though, Livingston was good times, until
               | Lucent took over. I was there 95-98.
               | 
               | I don't know what else there is to say really. The
               | QUIC/HTTP/3 vuln was found in NGINX OSS, which is also
               | the basis for the commercial NGINX+ product. We looked at
               | the issue and decided that, by our disclosure policies,
               | we needed to assign a CVE and make a disclosure. And I
               | was firmly in that camp - my personal motto is "Our
               | customers cannot make informed decisions about their
               | networks if we do not inform them." I fight for the
               | users.
               | 
               | Anyway, Maxim did not seem to agree with that position.
               | There wasn't much debate about it - the policy was pretty
               | clear and we said we're issuing a CVE. And this is the
               | result as near I can tell.
               | 
               | Honestly, anyone could have gone to a CNA and demanded a
               | CVE and he would not have been able to stop it. That's
               | how it works.
        
               | mholt wrote:
               | > Honestly, anyone could have gone to a CNA and demanded
               | a CVE and he would not have been able to stop it. That's
               | how it works.
               | 
               | Even if third parties can file CVEs, do you think it hits
               | different when the parent organization decides to do so
               | against the developer's wishes? Why do he and F5 view the
               | bugs differently? It sounds like the fork decision was
               | motivated less by the actual CVEs and more about how the
               | decision was negotiated (or not at all).
               | 
               | (PS. Thanks for participating in the discussion.)
        
               | kayfox wrote:
               | Personally, I think its more honest if the parent org
               | does not try to contest a CVE being assigned to a
               | legitimate issue. If a CNA gets a report of a
               | vulnerability in code, even if its an uncommon
               | configuration, they should be assigning a CVE to it and
               | disclosing it. The entire point of the CVE program is to
               | identify with a precise identifier, the CVE, each
               | vulnerability that was shipped in code that is generally
               | available.
               | 
               | Based on my observation of various NGINX forums and
               | mailing lists, the HTTP/3 feature, while experimental, is
               | seeing adoption by the leading edge of web applications,
               | so I don't think it could be argued that its not being
               | slowly rolled into production in places.
        
               | dgacmu wrote:
               | Oh my god, the Internet is such a small place. Good to
               | hear you're doing well - we interacted a bit when I was
               | running an ISP in the 90s as well. (Dave Andersen, then
               | at ArosNet -- we ran a lot of PM2.5e and then PM3s).
               | 
               | And appreciate the clarification about the CVE
               | disagreement.
        
               | kelnos wrote:
               | Oof. Presumably Dounin had other gripes about the company
               | that had been building up? This seems like a pretty weird
               | catalyst for a fork. Feels more like this was the last
               | straw among many.
               | 
               | I get that CVEs have been politicized and weaponized by a
               | bunch of people, but it seems weird to object that
               | strenuously to something like this.
        
           | ddxv wrote:
           | Why wouldn't he want CVEs assigned?
        
             | tangus wrote:
             | >The most recent "security advisory" was released despite
             | the fact that the particular bug in the experimental HTTP/3
             | code is expected to be fixed as a normal bug as per the
             | existing security policy, and all the developers, including
             | me, agree on this.
             | 
             | >And, while the particular action isn't exactly very bad,
             | the approach in general is quite problematic.
        
             | mholt wrote:
             | I haven't read the content of the patches to understand the
             | impact of the bugs, but from my own experience [0] I can
             | suggest a few reasons:
             | 
             | - CVEs are gold to researchers and organizations like
             | citations are to academics. In this case, the CVEs were
             | filed based on "policy" but it's unclear if they are just
             | adding noise to the DB.
             | 
             | - The severity of the bug is not as severe as greater
             | powers-that-be would like to think (again, they see it as
             | doing due diligence; developers who know the ins and outs
             | might see it as an overreaction).
             | 
             | - Bug is in an experimental feature.
             | 
             | I'm not saying one way is right or not in this case, just
             | pointing out my experience has generally been that CVEs are
             | kind of broken in general...
             | 
             | [0]: https://github.com/caddyserver/caddy/issues/4775
        
               | TedDoesntTalk wrote:
               | To summarize: the more CVEs a "security researcher" can
               | say he created on his resume, the more impressive he
               | thinks he looks. Therefore, the incentive to file CVEs
               | for any stupid little problem is very high. This creates
               | a lot of noise for developers who are forced to address
               | sometimes nonsense that are filed as "high" or
               | "critical".
        
           | nailer wrote:
           | > Maxim did not want CVEs assigned.
           | 
           | ... to this specific bug in an experimental feature.
           | 
           | Originally I read your comment as Maxim doesn't want to use
           | CVEs at all.
        
         | tiffanyh wrote:
         | I don't see anything more in that mail list thread beyond the
         | post you linked too.
         | 
         | Where was the disagreement hashed out, so I can read more?
        
       | ComputerGuru wrote:
       | This isn't just "a core nginx dev" -- this is Maxim Dounin! He
       | _is_ nginx. I would consider putting his name in the title. (And
       | if I were F5, I'd have given him anything he asked for to not
       | leave, including concessions on product vision.)
       | 
       | That said, I'm not sure how much leg he has to stand on for using
       | the word nginx itself in the new product's name and domain...
        
         | amne wrote:
         | _He *is* nginx_ ?
         | 
         | https://freenginx.org/hg/nginx
         | 
         | I don't see it. Sure, he contributes. But in the last 3-4 years
         | he definitely does not look like he is nginx based on that log.
         | Or am I looking in the wrong place?
        
           | ComputerGuru wrote:
           | There's something wrong with the list. It's ostensibly sorted
           | reverse chronologically but scroll further and you'll see it
           | go from 2020-03-03 to "9 months ago" and from there on it's
           | all him.
        
             | jcranmer wrote:
             | Judging from the graph view
             | (https://freenginx.org/hg/nginx/graph), it has to do with
             | the QUIC branch landing onto the main branch, suggesting he
             | had little role in the QUIC development but heavy role
             | outside of it.
        
           | flawi wrote:
           | I think the mercurial log is not doing us any favors here,
           | most of the first few pages is the history of the `quic`
           | http/3 support branch which indeed Maxim is not working on.
           | Scroll past it and he'll be much more prevalent. See for
           | example the log of stable-1.24:
           | https://freenginx.org/hg/nginx/shortlog/420f96a6f7ac
        
           | jbverschoor wrote:
           | And that's how 100x developers don't get the recognition they
           | deserve.
        
           | EasyMark wrote:
           | you should have googled his name, and you would have known
           | within seconds. I mean it's everywhere nginx is mentioned (or
           | dev of it)
        
           | kelnos wrote:
           | And this is why counting commits doesn't give you an accurate
           | picture of productivity.
           | 
           | (Regardless, if you scroll back past March 2020, the timeline
           | "resets" to this past year, and you see a ton of Dounin
           | commits. Looks like an artifact of how the hg web viewer
           | deals with large, long-lived branches getting merged.)
        
         | stemc43 wrote:
         | > not sure how much leg he has to stand on for using the word
         | nginx itself in the new product's name and domain
         | 
         | pretty sure they can't really do anything to him in Russia.
         | Russia and US don't recognize each others patents, same as
         | China.
        
           | ComputerGuru wrote:
           | It's a .org domain, the registry is held in the USA.
        
           | bklyn11201 wrote:
           | Right, they will just go after the domain forcing either a
           | rename or a move to a Russian domain
        
           | nicolas_17 wrote:
           | What do patents have to do with this?
        
       | pbaam wrote:
       | What a coincidence, some days ago I was reading some HN posts
       | related to lighttpd and I found [1]. The link is dead and it has
       | inappropriate content, so use arhive.org. The author doesn't go
       | too much in detail of why nginx being purchased is a problem, but
       | in how to configure lighttpd. And the first comment predicts the
       | hypothetical case of F5 being problematic.
       | 
       | [1] https://news.ycombinator.com/item?id=19413901
        
         | synergy20 wrote:
         | I have been using lighttpd which can also host static content
         | and do proxying, on top of those lighttpd supports
         | cgi/fastcgi/etc out of the box as well, and it takes 4MB memory
         | only by default at start, so it works for both low end embedded
         | systems and large servers.
        
           | nullify88 wrote:
           | I've recently needed to build a docker image to run a static
           | site. I compiled busybox with only it's httpd server. It runs
           | with 300kb of ram with a scratch image and tini.
           | 
           | I didn't compile in fastcgi support in to my build, but it
           | can be enabled.
        
             | synergy20 wrote:
             | yes busybox httpd or civetweb is even smaller, both around
             | 300kb.
             | 
             | for tini you mean https://github.com/krallin/tini? how
             | large is your final docker image, why not just alpine in
             | that case which is musl+busybox
        
           | nickpsecurity wrote:
           | I used it to avoid having to learn lots of stuff about web
           | configuration that bigger servers might require. Between
           | lighttpd and DO droplets, I could run a VM per static for $5
           | a month each with good performance. I'm very grateful for
           | lighttpd!
        
       | arter4 wrote:
       | I admit I haven't followed closely this issue, but what is he
       | talking about?
       | 
       | >In particular, they decided to interfere with security policy
       | nginx uses for years, ignoring both the policy and developers'
       | position.
        
         | MZMegaZone wrote:
         | We (F5) published two CVEs today against NGINX+ & NGINX OSS.
         | Maxim was against us assigning CVEs to these issues.
         | 
         | F5 is a CNA and follows CVE program rules and guidelines, and
         | we will err on the side of security and caution. We felt there
         | was a risk to customers/users and it warranted a CVE, he did
         | not.
        
           | nmjohn wrote:
           | Why did he not want CVE's assigned?
        
             | MZMegaZone wrote:
             | I think you'd have to ask Maxim. My take is he felt
             | experimental features should not get CVEs, which isn't how
             | the program works. But that's just my take - I'm the
             | primary representative for F5 to the CVE program and on the
             | F5 SIRT, we handle our vuln disclosures.
        
               | Twirrim wrote:
               | I'm inclined to agree with your decision to create and
               | publish CVEs for these, honestly. You were shipping code
               | with a now-known vulnerability in it, even if it wasn't
               | compiled in by default.
        
               | aaronbwebber wrote:
               | if it's not compiled in by default, then you aren't
               | shipping the code! Somebody is downloading it and
               | compiling it themselves!
        
               | kelnos wrote:
               | If the feature is in the code that's downloaded,
               | regardless of whether or not the build process enables it
               | by default, the code is definitely being shipped.
        
               | anon-sre-srm wrote:
               | Yes. It's no different from any optional feature. Actual
               | beta features should only be shipped in beta software .
        
               | ramses0 wrote:
               | BRB, filing CVE's against literally any project with
               | example code in their documentation...
        
               | spicykraken wrote:
               | I've actually seen CVEs like that before, I agree that's
               | bonkers but I have seen it...
        
               | anon-sre-srm wrote:
               | Incorrect. Features available to users still require a
               | minimum, standard level of support. This is like the
               | deceptive misnomer of staging and test environments
               | provided to internal users used no differently than
               | production in all but name.
        
               | Twirrim wrote:
               | You and I have very different notions of "shipped". It's
               | open source code, it's being made publicly available.
               | That's shipped, as I see it.
        
               | aaronbwebber wrote:
               | This is an insane standard and attempting to adhere to it
               | would mean that the CVE database, which is already mostly
               | full of useless, irrelevant garbage, is now just the bug
               | tracker for _every single open source project in the
               | world_.
        
               | TedDoesntTalk wrote:
               | This. CVE has become garbage because "security
               | researchers" are incentivized to file anything and
               | everything so they can put it on their resume.
        
               | droopyEyelids wrote:
               | (not explicitly asking you, MZMegaZone) Does anyone
               | understand why a disagreement about this would be worth
               | the extra work in forking the project?
               | 
               | I'm not very familiar with the implications, so it seems
               | like a relatively fine hair to split- as though the
               | trouble of dealing with these as CSV would be less than
               | the extra work of forking.
        
               | kelnos wrote:
               | It probably wasn't. There's likely something else going
               | on. Either Dounin had already decided to fork for other
               | reasons, and the timing was coincidental, or there were a
               | lot of reasons building up, and this was the final straw.
               | 
               | Or he's just a very strange man, and for some reason this
               | pair of CVEs was oddly that important to him.
        
           | tky wrote:
           | This seems like a much larger story than the fork, given the
           | install base of nginx.
           | 
           | For clarity are you referring to CVE-2024-24989 and -24990
           | (HTTP/3)?
        
             | MZMegaZone wrote:
             | Yes, those are the two CVEs I was referring to. All I know
             | is he objected to our decision to assign CVEs, was not
             | happy that we did, and the timing does not appear
             | coincidental.
        
       | qwertox wrote:
       | Time for me to slowly start looking for an alternative.
       | 
       | There was a time when I wanted to move away from it and was
       | eyeing HAProxy, but the lack of the ability to serve static files
       | didn't convince me. Then there was Traefik, but I never looked
       | too much into it, because Nginx is working just fine for me.
       | 
       | My biggest hope was Cloudflare's Rust-based Pingora pre-
       | announcement, which was then never published as Open Source.
       | 
       | Now that I googled for the Pingora name I found Oxy, which might
       | be Pingora? Googling for this yields
       | 
       | > Although Pingora, another proxy server developed by us in Rust,
       | shares some similarities with Oxy, it was intentionally designed
       | as a separate proxy server with a different objective.
       | 
       | Any non-Apache recommendations? It should be able to serve static
       | files.
        
         | pablopr3 wrote:
         | Maybe take a look at Caddy (https://caddyserver.com/)
        
           | jbverschoor wrote:
           | Well, until you read
           | https://news.ycombinator.com/item?id=39351026
        
             | mholt wrote:
             | And?
             | 
             | (That isn't about Caddy, rather a third-party plugin.)
        
             | suprjami wrote:
             | That's a third party plugin, not core Caddy.
        
               | jbverschoor wrote:
               | Ohhh I didn't realize.
               | 
               | Then nothing
        
         | rouxz wrote:
         | Caddy, simple & easy, almost zeroconf.
        
         | TOMDM wrote:
         | I'm going to third the suggestions for caddy, I've replaced
         | nginx as a reverse proxy in a couple places with caddy and it's
         | been so much easier to maintain.
        
         | xcrunner529 wrote:
         | I mean I'm not sure how it's good to want to move to a dev who
         | is against CVEs and disclosures...
        
           | spydum wrote:
           | I think people are seeing this as a very generic "big bad
           | globocorp destroying OSS community", and not moving past the
           | headlines. I'm with you, this seems like a foolish thing to
           | decide to fork the project over. Probably there is other
           | conflict brewing, and this was just a convenient opportunity.
        
           | qwertox wrote:
           | Did I miss something regarding that Maxim didn't want CVEs
           | and disclosures? I was not aware of this. And F5 are the ones
           | wanting to add the CVEs (as happened in the announcement
           | which was released an hour earlier)?
           | 
           | I could have sworn that I've read about Nginx CVEs in the
           | past.
        
       | petecooper wrote:
       | Page won't load for me, Wayback Machine caught it:
       | 
       | https://web.archive.org/web/20240214184151/https://mailman.n...
        
       | petecooper wrote:
       | Mailing list discussion:
       | 
       | https://forum.nginx.org/read.php?2,299130
        
       | q2dg wrote:
       | Just use Apache
        
         | jdoss wrote:
         | As someone who used Apache 1.3.x through 2.x heavily from 2000
         | to 2015, I respectfully disagree with this statement. Nginx and
         | Traefik are easier to configure, have better communities and in
         | most cases perform better.
         | 
         | Traefik Opensource is my go to for almost all of my use cases
         | theses days and I have never stopped and said hmmm I wonder if
         | Apache would do better here. It is that good.
        
       | notsosubtle wrote:
       | https://my.f5.com/manage/s/article/K59427339
       | 
       | All F5 contributions to NGINX open source projects have been
       | moved to other global locations. No code, either commercial or
       | open source, is located in Russia.
       | 
       | yeah, yeah
        
       | BadHumans wrote:
       | Tangent, but I got curious about contributing so I went to the
       | Freenginx homepage, it looks like this project will be organized
       | over mailing list. I would love if someone would create a product
       | that gives mailing list a tolerable UI.
        
         | fmajid wrote:
         | SourceHut? It's a forge organized around an email rather than
         | pull request workflow.
        
         | dqv wrote:
         | Have you tried HyperKitty/Postorious? Does it get closer to
         | what you would consider tolerable?
         | 
         | https://mail.python.org/archives/list/mailman-users@python.o...
        
       | darkhorn wrote:
       | I don't understand why some people use a Russian software!
       | Especially in this age.
        
         | LinuxBender wrote:
         | In some cases there are not great alternatives that fit the
         | needs. I have not found anything that matches LFTP _Using the
         | mirror subsystem with SFTP and connecting to chroot SFTP
         | servers_. It replicates the behavior of rsync in a chroot SFTP-
         | only environment. Only downside is that since there isn 't a
         | syncing daemon on the other side, directory enumeration is much
         | slower. File transfers are exponentially faster however as it
         | can do as many SFTP sessions as desired for batches of files or
         | even one big file with the only limit being the bandwidth from
         | client to server.
         | 
         | For NGinx I have been able to make use of HAProxy and Apache
         | just fine. Long ago Apache was slower than NGinx but ever since
         | APR 1.7 and Apache 2.4 there are about the same performance
         | wise. Some here don't like the configuration syntax but I am
         | used to it.
        
         | ijhuygft776 wrote:
         | Because they aren't short sighted like some others?
        
       | rdl wrote:
       | Curious how to support Maxim despite Russia complications.
        
         | fareesh wrote:
         | bitcoin solves this
        
       | dmacvicar wrote:
       | It seems every time I read about a project being forked, they use
       | the (probably) trademarked name in the project's fork, just to
       | need a rename a few weeks after.
        
       | web3-is-a-scam wrote:
       | Apache my beloved
        
       | davecheney wrote:
       | Oh snap, F5 just Hudson'd themselves.
        
       | chrisweekly wrote:
       | Note for some reason Maxim chose to link to http://freenginx.org,
       | instead of https://freenginx.org
        
         | EasyMark wrote:
         | typo? it forwards to https anyway.
        
           | brunoqc wrote:
           | Are you sure? not for me
        
       | INTPenis wrote:
       | If I ever need nginx I'll use freenginx. But funny enough all my
       | services run in Traefik these days. 15 years ago Apache httpd was
       | the norm, and lately nginx has been, and now I can't even think
       | of a reason to use it.
        
       | resolutebat wrote:
       | Per the discussion at
       | https://news.ycombinator.com/item?id=39374312, this cryptic
       | shade:
       | 
       | > _Unfortunately, some new non-technical management at F5
       | recently decided that they know better how to run open source
       | projects. In particular, they decided to interfere with security
       | policy nginx uses for years, ignoring both the policy and
       | developers' position._
       | 
       | Refers to F5's decision to publish two vulnerabilities as CVEs,
       | when Maxim did not want them to be published.
        
       | fl0ki wrote:
       | Given this fork still boasts a 2-clause BSD license, the
       | corporate nginx can still make the effort to backport patches.
       | It's certainly harder than requiring a single converged
       | development branch, but how closely they track Maxim's work is
       | ultimately up to them.
       | 
       | If nginx continues to receive more attention from security
       | researchers, I imagine Maxim will have good reasons to backport
       | fixes the other way too, or at least benefit from the same
       | disclosures even if he does prefer to write his own patches as
       | things do diverge.
       | 
       | Though history also shows that hostile forks rarely survive 6
       | months. They either get merged if they had enough marginal value,
       | or abandoned outright if they didn't. Time will tell.
        
       | thomasjudge wrote:
       | How the heck am I supposed to pronounce that? "Free-en-gen-icks"?
        
       ___________________________________________________________________
       (page generated 2024-02-14 23:00 UTC)