Freenginx: Core Nginx Developer Announces Fork of Popular Web Server

https://www.infoq.com/news/2024/03/freenginx-ngnix-web-server/

by kungfudoi • 2 years ago

136 94 2 years ago

qwertox• 2 years ago

Discussed previously Freenginx: Core Nginx developer announces fork https://news.ycombinator.com/item?id=39373327 2024-02-14, 475 comments

roschdal• 2 years ago

Excellent, I wish this project success!

yesbut• 2 years ago

Absolutely. This is great news.

RedShift12• 2 years ago

I'm glad I stuck with Apache httpd whilst everyone was moving to nginx. None of this drama with httpd.

tetris112• 2 years ago

I'm having a great time with Caddy. My whole Jupyter stack is reverse proxied to Caddy, and the Caddy config is a single line compared to the 100 line mess that they reccomend people use for Apache or nginx

(yes caddy takes care of upgrading your headers, websockets, certificates, all of it)

infofarmer• 2 years ago

once you actually need to configure Caddy, it is an abomination beyond imagination — the docs, Caddyfile, JSON config — all of them lack coherence or sensible design

never touching it again

good defaults matter; nginx configs were very concise and readable in 2005-2015 when I was using it heavily; http/3, ws, acme — perhaps new tech is yet to be incorporated properly (and maybe it never will)

citrin_ru• 2 years ago

A fork is not necessary bad for users. Nginx is already a great product and I believe both Nginx Inc version and freenginx will not become worse over the time. Likely they would gain different features, will have different release schedules e. t. c.

blowski• 2 years ago

Is it that much of a drama? Seems more like this is the whole selling point of open source - if you don't like something, you fork it, and people can vote with their installations. This kind of stuff happens all the time in private companies, but we as users have much less influence over the outcome.

Joel_Mckay2• 2 years ago

Apache needs slowloris mitigation, and a dozen other tweaks to get it secure (mpm-itk, fail2ban rules, and anti-spammer mods etc.) It can be good, but most people run the vanilla install. Sometimes it is the only solution... ;-)

However, Nginx gets over 20% more concurrent users per host... Hence the main reason people put up with its lack of features and silly HA design.

Forks can be healthy, but it usually quickly degrades into a competition for users.

Hope everyone has fun =)

yjftsjthsd-h• 2 years ago

Er, does nginx have some fail2ban built-in? Because it really sounds like that's apples-to-oranges.

maccard• 2 years ago

I'd rather have gotten 15 years out of a superior solution personally.

krisoft• 2 years ago

Drama? This feels like your own projection.

Nginx is a stable, and reliable piece of software. It was before this, and will be after this. What happened is that someone who used to work on it now works on a new thing. This happens, people are not slaves to their previous projects. They can and should do new things when they wish to.

In time if the new thing becomes usefull in some way perhaps some people will choose to use it instead of nginx. Perhaps that day will never come. Both of those are fine.

What is certain is that nginx has a critical mass behind it that even if a core developer moves away to do something else it won’t shrivel up and die. If you are an nginx user today in a personal or professional capacity most likely you will be able to use it until the end of your life with no special worries.

I have no problem with you using Apache httpd, and I am happy that you are happy with your choice. On the other hand it does not feel usefull to portray this as some special reason why one should not have choosen nginx.

wlonkly• 2 years ago

This is how Apache came into being (without so many hard feelings, maybe), though -- as (what we would now call) a fork, of NCSA httpd.

gudzpoz• 2 years ago

“Nginx is an incredible software and platform, but I was wondering if it wouldn't be time to just bite the bullet and create a more modern solution based on Rust.”

I actually don't understand why I am seeing arguments like this all the time. Rewrite takes time and effort. It may be OK for new projects. But for a mature project that has a quarter million lines of code and load-tested for cross-platform compatibility and security, it is way more than "just biting the bullet". (Not to mention that memory safety in Rust is ... still improvable. [1])

Rust is not a panacea. [2] When a corporate tries to seize control of a open source project, some one (or some entity?) has to do something, and rewriting in Rust by no means reclaims the freedom and openness of the project.

[1] https://news.ycombinator.com/item?id=39440808

[2] https://ariadne.space/2023/12/07/most-breaches-actually-begi...

jhgb• 2 years ago

Is it a rewrite...or a completely new piece of software that simply takes the NginX experience into consideration when designing its features?

wccrawford• 2 years ago

The blogger keeps saying "Fork", but I can't find anything from the actual developer that says that. Instead, they keep saying it's a new project and that it "understands the nginx configuration language".

So I think it's pretty clear that it's not a fork.

To add to the confusion, it seems like they copied the site with all the bug reports as-is, which obviously would only apply to a fork, not to a project that hasn't even got any code yet.

GrayShade• 2 years ago

When a corporate tries to seize control of a open source project

Yeah, they wanted to have some CVEs for a bunch of bugs in experimental code, the author of the fork didn't.

dns_snek3• 2 years ago

What a weird hill to die on. Perhaps someone can illuminate the situation better, but I'm not keen to trust a project that seems to take CVE assignment against their software personally.

kristopolous3• 2 years ago

The large "rewrite in language X" projects, I can't think of any that succeeded without the significant cost of time, effort and users.

Maybe there's a survivorship bias in that only the ones that go poorly people talk about?

MrJohz2• 2 years ago

Fish shell would be the big counterexample right now. C(++?) to Rust in about a year, IIRC. I believe they were still pushing out updates to the original codebase during that time, although I assume they could have done more if they weren't also rewriting.

darylteo• 2 years ago

Lots of JS ecosystem is going to "rebuild in Rust" right now, ironically.

JS has a different lifecycle though, I suppose. Everything gets rebuilt like 5-10 times more often than other on platforms.

jasode2• 2 years ago

The large "rewrite in language X" projects, [...] significant cost of time, effort and users.

Well... if you're pre-qualifying the hypothetical rewrite with "large", that already means we take as a given it will require significant time & effort. (Unless there's a sufficiently smart automatic transpiler tool like a future ChatGPT-v17.)

There have been some successful big rewrites. Google rewrote the web crawlers from Java to C++. They also rewrote the search results front page from Java to C++. Microsoft rewrote C# compiler from C++ to C#. Go rewrote the compiler from C to Go.

In any case, for curiosity... I ran the CLOC tool to count lines-of-code in the main NGINX repo ./src/* subdir. A project to convert ~165k of C to Rust is small enough to be doable by a small team. "Small" being 1 or 2 developers. (I'm not recommending they rewrite in Rust but just comparing the scope of the work to the resources.)

Semi-related footnote is Cloudflare replaced NGINX with in-house Pingora and that was written in Rust: https://hn.algolia.com/?q=pingora

  -----------------------------------------------------------------------------------
  Language                         files          blank        comment           code
  -----------------------------------------------------------------------------------
  C                                  256          54041           6165         153818
  C/C++ Header                       134           4810           1077          10041
  Perl                                 2             45             18            112
  SKILL                                3             24              0             99
  Bourne Shell                         1             30              5             78
  make                                 1              9              0             21
  C++                                  1              9              3             19
  Windows Resource File                1              3              2              1
  -----------------------------------------------------------------------------------
  SUM:                               399          58971           7270         164189
  -----------------------------------------------------------------------------------

SoothingSorbet• 2 years ago

It of course depends on what you mean by "large", but one obvious case is rsvg.

__s• 2 years ago

I'm not sure which ones have gone poorly

I guess you'd consider librsvg in the poorly bucket, whereas its maintainer considers it a success. I think there's a distinction to be had between "maintainer lead RIIR" & "rando RIIR"

https://lwn.net/Articles/771355 https://viruta.org/librsvg-rust-and-non-mainstream-architect...

masfoobar• 2 years ago

Rust has been getting A LOT of traction in the last few years.

It seems many programs are getting Rust replacements in one shape or another. If not being replaced it is, at the very least, being included in existing projects. The linux kernel now supports Rust which I believe, at this time, for Device Drivers. I also heared Rust compiler is included in the Windows Kernel.

Whether you/we like it or not, Rust is a serious contender! As a developer myself, would prefer to focus my energy on Odin or Zig but the reality is Rust is where job security is likely to be.. alongside languages like Java, Python, C#, etc.

Over the years, Job adverts have evolved from "must know OOP" to "must know design patterns" to "SOLID principles" and... now is likely to be "must focus on memory safety!"

For many, which Paul Graham referred as "the pointy haired boss" in his Revenge of the Nerd peice, is just cool buzz words of the time. It is just the current thing we need to do/use. Rust is going to gain the edge with these buzzwords.

This brings me back to projects like freenginx. The reality is new developers coming in are not focusing on C or C++. Academia is likely moving away from them in the coming years, in favour of Rust. The reality is new projects in C or C++ might not last when alternatives are being written in Rust. As it has "memory safety" it will likely be the default choice many look for, especially in a business environment.

As I have mentioned, I have been focusing my energy on Odin and (a bit of) Zig. However, the reality is there are not going to be jobs using them.. compared to Rust, C#, Python, etc. This means I will have to bite the bullet... and soon... learning Rust.

viraptor• 2 years ago

I actually don't understand why I am seeing arguments like this all the time.

Have a look at:

https://github.com/nginx/nginx/blob/master/src/http/modules/...

It's got the whole checklist: nginx idiosyncratic module system, inline parsing, custom utf conversion, buffer preallocation and adjustments, linked lists, comments about side effects of custom allocator, and probably other things.

It's not easy to deal with source like that and any serious improvement to that area would effectively be a rewrite anyway.

Since anything doing work in nginx is a module anyway, it wouldn't even have to be a full rewrite in one go.

anonymoushn• 2 years ago

Anecdotally in the cache module, it's unclear what invariants are supposed to be maintained for a big ol struct full of information about this cache lookup, which functions expect to only be called while holding a lock, etc. The module design and the issues you mentioned also causes suboptimal performance :(

ergonaught• 2 years ago

The person who actually wrote your quote explicitly referred to doing this as a “new project” within the quote.

wvh• 2 years ago

A lot of the needed functionality might already be available in the Rust ecosystem, while a large amount of the code in Nginx predates general HTTP utility or even Unicode libraries. I assume that software that has grown organically with the web has gathered a lot of cruft and hacks that might not be needed anymore and make further development a lot harder.

It might be a worthwhile experiment to take a common set of HTTP libraries in Rust and add Nginx-specific configuration parsing and some other bits together and see how far that kind of hackery would get. With a good BDFL and some community involvement, it would be a great way to get the ball rolling.

traceroute665• 2 years ago

Rust is not a panacea.

Amen to that.

I don't understand why more people don't highlight Rust's main weakness. The lack of strong stdlib.

No stdlib means you have two choices:

    (a) Re-invent the wheel; or
    (b) Use a crate.

Most people choose (b) because they don't have the time, inclination or expertise to do (a).

Which means you open yourself up to supply chain attacks, unless you constantly audit the upstream crates, which, let's face it, most people won't, they probably won't even audit the original version they pulled in, let alone the updates.

Which means with something like an nginx re-write in Rust, which is a complex piece of software with many moving parts, you end up importing a whole ton of random crates. Half of which will probably become abandonware within a few years, because that's the way of the world with open-source, maintainers move on to bigger and better things.

There is a difference between rewrite in Rust and rewrite properly in Rust.

No doubt there are people out there doing solid open source work with Rust (e.g. the guys at tweede golf) but that takes time and effort, and in the case of tweede golf, the extra effort is financially sponsored, something that is not the case with most open source projects, especially the single-maintainer ones.

bborud6• 2 years ago

Yeah, the poor stdlib is the main reason Go is my go-to (no pun intended) language for writing servers rather than Rust. That and the slow compiler, which a lot of people think shouldn't matter, but does matter.

finaard• 2 years ago

Also: No bootstrapping rustc from source. There are a bunch of projects trying to get that fixed, but currently pretty much everybody relies on binaries coming from upstream. Having a core infrastructure component like nginx rely on a compiler we can't verify would make a supply chain attack against the compiler very attractive.

bborud6• 2 years ago

While I agree that a rewrite of Nginx in Rust probably isn't the best use of resources, I wouldn't be so quick to dismiss the idea of writing an Nginx equivalent. And you might as well do that in Rust.

There are things I'd love to see in this space. For instance I'd love a proxy that explores the idea of being fully configurable via a gRPC API and which can delegate decisions to some other service (over gRPC).

(Doesn't the commercial Nginx have some of these features?)

sophacles• 2 years ago

I think you're confusing two things. "create a more modern solution" is not the same statement as "rewrite it in rust". The later implies "make the same software in a new language", the former suggests "create new software because the use cases and problems the software solves have changed".

The software was initially released 20 years ago. It was designed in an era where most http requests served static assets and html w/o js, and https was for special situations like banks and order forms. At that time multicore CPUs were just emerging, and servers still shipped with 1Gb ethernet. JSON was a quirky idea, php was king, and Gmail was shaking up web-dev with this funky new Ajax thing[1].

Point being, things have changed - these days there are a lot of situations where you wouldn't even consider nginx since it's not the right tool, there are situations where nginx is no longer the easiest component to use and/or deploy, there are situations where it's a giant hassle to maintain an nginx deployment compared to tools written for a "servers are cattle" world.

Put another way, the web was 13 years old and the internet was a little over 30, and both had really only gotten big over the previous decade. If we were talking aviation, it would be arguing to retrofit the best fighters from WW1 on the dawn of WW2 or asking why we can't just strap jet engines on a DC3.

nginx has been an amazing bit of software and a solid workhorse getting us here. But more and more people are looking at other solutions, because the problem to solve isn't the problem nginx was designed for. That's ok - the world changes all the time.

Software isn't done, we haven't even had computers for a hundred years. Heck we haven't even finished figuring out all the ways to use computers yet. I'm leary of any claim that we fully solved some aspect of it, and more so when the claim is applied to tech from the early days of that field.

[1] it wasn't new new, but this was the first time most people really started to grasp what you could do on the web with javascript.

technion• 2 years ago

I know its early days but I think it's really broken to directly copy the upstream website, and impacts on how usable the product appears.

For example, https://freenginx.org/en/security_advisories.html states "All nginx security issues should be reported to security-alert@freenginx.org." and then has a complete history of bugs from prior to the fork (and thus were never freenginx issues).

creatonez2• 2 years ago

For example, https://freenginx.org/en/security_advisories.html states "All nginx security issues should be reported to security-alert@freenginx.org." and then has a complete history of bugs from prior to the fork (and thus were never freenginx issues).

What exactly to display on the security advisories page on a brand new fork project with no vulnerabilities yet seems like it could be a particularly hairy problem. You want users to visit the page and see the schema of information they would get in a security advisory, so they are prepared to use the website if they need to. So you could display an example advisory if none are available. But at that point it would be easier to keep the old advisories, because they also help to inform users on why they should upgrade from pre-fork versions.

jtc331• 2 years ago

Because it’s a fork those issues were in fact issues with freenginx IMO.

tinco• 2 years ago

Now that pingora is open source, it might make a lot of sense to build that project on top of pingora. You'd get the battle tested quality that nginx is lauded for. I wouldn't switch to a "fork" of nginx if it's a from scratch rewrite with no proven track record, regardless of the track record of the author.

sergioisidoro2• 2 years ago

This might be a controversial opinion, but with the current Russian invasion of Ukraine and tensions between East/West, forking a project like Nginx to be maintained by a Russian company, by a person living in Russia, raises additional questions, especially considering how security critical nginx is when it comes to accessing all traffic of services. I'm thinking here as well about the case of Pavel Durov and his struggles with Russian government.

From the post it seems their intention are good, and towards better secured software, and against business interfering with security. But the part where they say "I no longer able to control which changes are made in nginx within F5" might be a good thing. Should a single person have that much control over a critical piece of infrastructure?

justsomehnguy• 2 years ago

Like some guy from Finland?

sergioisidoro2• 2 years ago

To the best of my knowledge, Finnish government hasn't made any attempts at interfering with software development built in Finland, or spying on software users. The same cannot be said of Russia.

I'm not saying Russian people cannot make safe and secure software, just saying that people living in Russia have historically been targets of pressure.

* and to be honest, the USA and China do not have the cleanest of records either.

tipiirai• 2 years ago

Pretty sure this is a reference to Linus Torwalds

sneak• 2 years ago

The same argument based on the “Russia vs the global west” narrative can be leveled perfectly accurately against western-citizen maintained software.

Everyday Russian developers are no more or less involved in their country’s empire-building than everyday American developers are in theirs (lest we forget about the 12(!) foreign countries in which US forces are currently invading). “Russian” is not synonymous with “suspect”; or, if indeed it is, perhaps “American” should be, too.

bjourne• 2 years ago

More power to him! But calling the fork freenginx is perhaps not the best decision since there is nothing unfree about nginx. Call it rustnginx instead.

imiric• 2 years ago

Agreed about the current name, but a "rusty engine" doesn't inspire confidence in a web server. :)

ChrisArchitect• 2 years ago

Another one?

https://news.ycombinator.com/item?id=39373327

Freenginx: Core Nginx Developer Announces Fork of Popular Web Server

Related Stories