www/nginx 1.25 and 1.26

Hello.
When will the www/nginx version be updated in the ports?
Now the www/nginx branch/version 1.24 is in the ports, but it is already old, the stable nginx 1.26 branch is now.
 
Last time I faced a situation like this, a bug report fixed the issue in no time.
If you kindly explain the problem, the maintainer might react as soon as he can.
Plus I can't imagine a so popular software like www/nginx not being updated for a too long period of time.

Ho yeah thanks to cmoerz I almost forgot that recent event, now there is a www/nginx vs www/freenginx, that's an alternative in case one is not updated.
 
I just noticed that there is such a port www/freenginx.
What is www/freenginx for?
 
Developer Maxim Dounin decided to fork the project because he disagrees with the direction of the upstream project. He posted about this some time ago:


We'll see where this fork takes us. Good to know that Nginx and Freenginx are entirely separate entities and I would not pick one over the other based on a version number alone.
 
I just noticed that there is such a port www/freenginx.
What is www/freenginx for?
 
I remembered reading about this software www/freenginx half a year ago.
For now I’ll stay on www/nginx.
 
For me personally, with $work located in the EU, it would be counterintuitive to jump ship to a fork maintained by a developer who -however unfortunate for him- got hit by the fallout from sanctions against his government. I'd have a lot more explaining to do than sticking with mainstream nginx, even if it actually is being mismanaged by F5 which I don't know about so I have no opinion in either direction.
 
Absolutely. Also, I still don't understand what the disagreements were with F5.
IIRC the management interfered more and more with development, various new/'advanced' features were demanded to be exclusive to the commercial "nginx plus" variant and the tipping point was F5 insisting on applying CVEs to some experimental/development code that wasn't even used or enabled in release versions.

I moved to angie a while ago - simply because it is a fully "free" project, not entangled with some commercial entity that isn't on par with its developers. This never was a good mixture and I fear with nginx it will be the same...
Also angie is maintained by a group of former nginx core developers, while freenginx is (currently) a one-man-show (which also usually never worked out for long...).

But time will tell - since those 3 are still drop-in-replacements for each other, jumping ships is as easy as "pkg remove / pkg add" and renaming the config file...
 
I moved to angie a while ago - simply because it is a fully "free" project, not entangled with some commercial entity that isn't on par with its developers. This never was a good mixture and I fear with nginx it will be the same...
I didn't know angie so I looked at the website and it says:
A commercial version, Angie PRO, is also available, which has additional features and is listed in the Russian software registry.
How is it different from nginx? it's a real question, no sarcasms.
 
I didn't know angie so I looked at the website and it says:

How is it different from nginx? it's a real question, no sarcasms.

I never knew there was a commercial version available. So yeah, my previous statement seems to be rather pointless...
The only difference might be: 'Web Server LLC' was founded for and is still lead by the developers of the angie project, rather than a big company (F5) buying such a project/company and installing their management there...

But still: with 3 concurrent drop-in-replacements I suspect (hope) even in a worst case scenario at least one of them (or yet another fork) will survive to which one can fall back upon...
 
sko
Yeah it's hard to predict what a project will become if it is successful.
But still: with 3 concurrent drop-in-replacements I suspect (hope) even in a worst case scenario at least one of them (or yet another fork) will survive to which one can fall back upon...
Fingers crossed otherwise people will be back to apache :)
 
I see the nginx port has updated the branch to 1.26, but why aren’t updates to the port released in a timely manner?
On the official website nginx.org version 1.26.1 dated (May 29, 2024), in ports the nginx version is 1.26.0.
 
Most port maintainers are busy people and often they might not even use the port (any more) themselves and hence don't notice if there are new versions available. Just reach out with a friendly request via PR. You could also try if the new version builds with the Makefile (and possible patches) of the port and either file a PR with the request to update it, to help fixing build problems or ideally providing a patch.
 
hmm, the point of using a system FreeBSD with such a policy is lost; in Linux, using Debian as an example, packages programm in repositories are updated in a timely manner, with no big difference in days from the official release of the program.
I have been using the FreeBSD system for a long time, I like management in system, but the policy of creating ports is all ports.
 
Debian apparently has more capacity to update packages. FreeBSD being what it is, you are always welcome to pick up maintainership over orphaned ports. If you rely on FreeBSD professionally this would be a good way to give back to the community.
 
back when I had some servers running debian they usually had *by far* the oldest software that was somehow still supported (or was kept alive via backported security patches)...
But yes, they have much more manpower and also many projects directly maintain packages in various linux distributions.

However - as long as there are no security implications, I'm not eager to always run the "leatest and greatest" version of anything. More often than not this has even worse security implications; that's also why servers should usually run the "quarterly" ports/pkg branch...

If you want/need the absolute bleeding edge version of some port/software, you should start looking into building your own packages via poudriere. This way you can easily maintain local patches to use newer versions than in the official ports. (If those are supported, i.e. not development/beta versions, those patches might also be very welcome in the official ports tree.)
 
hmm, the point of using a system FreeBSD with such a policy is lost; in Linux, using Debian as an example, packages programm in repositories are updated in a timely manner, with no big difference in days from the official release of the program.
I have been using the FreeBSD system for a long time, I like management in system, but the policy of creating ports is all ports.
Well that's just not true. Debian is famous for holding back updates.

Debian will only do major/minor updates to packages with each new release of debian, which happens every two years. This is why most debian based distributions rely on debian-testing. So with debian we are talking years between the official release of software and it being present in the repositories.
In the mean time they continuously backport patches.

If you want a bleeding edge updates on Linux you typically need a rolling release distribution like ArchLinux, OpenSuse Tumbleweed or void.
Or a good built system like that of FreeBSD, which allows you to update packages yourself when needed.

 
Debian will only do major/minor updates to packages with each new release of debian, which happens every two years. This is why most debian based distributions rely on debian-testing. So with debian we are talking years between the official release of software and it being present in the repositories.
In the mean time they continuously backport patches.
I have 50/50 systems, freebsd and debian.
Both are good systems, easy to operate intuitively, I’m probably already used to them. )
With debian, I didn’t notice that updates to (php/nginx/apache/mysql) take a long time to come out.
Probably because I point to software repositories from software developers.
I don’t understand, but why keep a formal package or port in the repository or ports, just for show, that we have it in our system?!
The person who installs the system on the server expects that software will be released in a timely manner and with security patches.
 
Back
Top