With the continual feature additions in the 2.4.x series, I dare say the project fell into a versioning slump like Linux had in the 2.6.x series. Rather than being a fixed set, instead it was continually evolving, and Apache's "2.4" prefix on version numbers is effectively just as meaningless at this point.
It could probably replicate Linux's solution to this and stop fixing "major" version numbers. Make the next release 3.0, then 3.1, and so forth. And every so often, bump that first part so it's not on "3." forever either.
Interestingly, Apache is roughly twice as old as SemVer (dating SemVer using the Wayback Machine looking at semver.org). I'd have guessed SemVer was younger than that, but time is weird.
Incidentally, that means that Apache is not, in fact, using SemVer. They're using the old-school even-odd system.
While that’s true, the GP is right that semantic versioning is a relatively recent term and a lot of older projects followed a principle of odd numbers being development versions with even numbers being stable releases (Apache 2.3 vs 2.4, PHP used to follow this, Linux kernel used to too, eg 2.4, 2.6).
The x number (in x.y.z) was still used to denote a major upgrade but jumps between y were usually considered breaking changes too.
It’s also worth noting that it used to be common to have 4 sets of numbers, x.y.z.n with n being automatic build numbers.
Lastly, there’s still another common trend to have version numbers based on release date. Ubuntu do this, for example. I personally quite like this approach as it communicates a little more than just a release version. For internal projects I often go even further and recommend a git hash included as part of the release version.
So yes, versioning schemes are older than the web. However agreed standards in how to use version numbers have always varied a significantly (and still do now). And the Apache httpd project does predate the rise in popularity of semantic versioning.
It depends on what piece of software your version numbering though. Semver is great for APIs but doesn’t have as compelling strengths for standalone applications, distributions of packages nor operating systems since what constitutes as a “breaking change” becomes harder to define.
For something like Ubuntu, signalling the age of a release to end users is more valuable than following semver strictly (not to mention that the patch part of semver wouldn’t even apply).
Whereas if your software is being consumed by other software, such as an API, then you need to communicate where interfaces might change in ways that are verifiable via other software interfaces.
So it really depends on who is consuming your software interface. You might even want multiple different version schemes for different parts of your application. You’ll sometimes see applications have one versioning scheme for their end user facing interface while their developer APIs, which are still bundled as part of their application, might follow another.
Going back to the original point about dates as version numbers, the biggest appeal for me is it takes human error out of the equation. I’ve lost track of the number of companies I have joined which were very good at supporting versioning but terrible at remembering to increment that version number. So having a system which can auto-increment version numbers takes one problem away from developers. And if you’re auto-incrementing private packages then the question becomes: “how strictly are you now following semver?” At which point you might as well have a timestamp and then have the bonus feature of communicating to your team when a specific build was committed.
I don’t think there is a right or wrong way to do these things though. You just need to pick a standard, document it and be committed to following it.
>It depends on what piece of software your version numbering though. Semver is great for APIs but doesn’t have as compelling strengths for standalone applications, distributions of packages nor operating systems since what constitutes as a “breaking change” becomes harder to define.
I wrote "changing primary version number" instead of "using semver" on purpose. I agree semver can be too narrow for bigger apps and that is why I only said about signalling "potential sysadmin action required", not signalling new features or bugfixes in version number.
> standalone applications,
can certainly have "we changed how configuration options work" at the very least
> distributions of packages
Distros are so far managing that extremely well all things considered
> nor operating systems
Cue loud Linus yelling about breaking userspace.
The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine.
> I wrote "changing primary version number" instead of "using semver" on purpose.
I was making a general point. I wasn’t suggesting you were advocating semver specifically.
> can certainly have "we changed how configuration options work" at the very least
Any major change to your versioning scheme can signal that. Including having a year number as your major iteration.
But what’s more valuable to your end users in these types of scenarios is documentation about the change.
> Distros are so far managing that extremely well all things considered
You’ve completely lost me now. It sounds like you’re trying to defend Linux distributions but my comment was neither a criticism nor was it about Linux distributions per se. These are plenty of instances where several packages are distributed as a whole. Like with multimedia applications that might ship ffmpeg, a Python scripting environment and a multitude of other components.
Linux distros, of course, is another example (and one on a much bigger scale). It’s worth noting that no major distro uses semver either. Some don’t even have a minor release let alone a major version number. But their signalling around versions satisfies a different problem to what an API needs to signal. Hence my point that versioning is about sticking to a standard more than it is about trendy schemas.
> The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine.
I don’t really understand your point here but I’m happy for you that your config is still working :)
That would signal "we are alive." Does it have any other practical purpose?
On the other side, who remembers the version of Chrome, Firefox, Thunderbird or even the Linux kernel since they started moving fast? They basically become versionless, we just upgrade to the latest one prompted to us by their autoupdates or by the OS.
What's missing from this history is the origins of Apache httpd 2.4: as I see it, circa 2009 Nginx started growing. Apache's market share was like fresh snow under foehn (from 75% at this time down to 20% today). Nginx was much more performant and its configuration was saner. Apache had to change or it would gradually disappear.
Another note on this 10 years anniversary is that, though Apache 2.4 was released in 2012-01, it was a rushed release and some features were still lacking. In my opinion, the most important was that mod_proxy could not talk to unix sockets. It made Apache 2.4 hard to use in many cases. This feature only appeared with 2.4.7 in 2013-09.
Nowadays I rarely see Apache installed on web servers that I work with. In one case, it was because the sysadmin was used to it (though 2.4 broke the compatibility with 2.2's config syntax), he didn't consider changing and even kept the awful Apache prefork engine. In other cases, it was because of some modules (e.g. shibboleth) that were packaged by the OS for Apache, but not for Nginx.
Is nginx still considerably more performant than Apache when both are configured well? (IE. Using mpm_event, not needlessly recycling processes, using mostly threads for concurrency, etc.?)
I'm one of those who always just stuck with Apache because 1) I'm used to it, and 2) it's never been close to a bottleneck in our stack. Especially now that the vast majority of static content requests don't even hit the servers at all. Buy I am curious! I haven't looked at comparisons in years, but last I did, everyone liked to compare nginx to prefork Apache, which is pointless.
HAProxy is faster than both of them for load balancing. Apache is slightly faster for static content. Nginx has more responsiveness under high load than Apache for dynamic content (Hence Tomcat workers for example)
Is that true even if you configure Apache to use a static number of processes? IE set startservers equal to serverlimit and maxsparethreads equal to maxrequestworkers? IME that allows Apache to respond to load spikes more quickly. But is the issue with high load and dynamic content specifically related more to connecting to the process manager for the scripting language? (I take the same approach there, using a static pool of processes. Haven't had any issues, but have no way of knowing if nginx might be even faster!)
Nginx uses an event driven model where a single thread might perform work for multiple requests. Often the batching and caching of these requests can boost performance. Apache however assigns each inbound connection its own dedicated thread which makes it slightly more responsive on average. At the end of the day it's going to come down to the priority of scheduling for the threads of the program whether it be one process with 65,535 threads or 65,535 single threaded processes
That description is not correct for any of them. Apache can use either an event queue or a thread pool, and nginx is also multithreaded and not forking. So there isn't any difference, except that Apache has a bit more knobs to tweak.
That is just a png of some text. The text is either wrong or outdated by a decade or more.
People sometimes like to have opinions about stuff. But there's no reason to google for secondary sources when the documentation is good.
Read the manual instead. The documentation for both projects is correct, short and to the point. They are both multi threaded, multi process, with an event loop. The documentation describes how to set those parameters. Look at the thread_pool directive for nginx and AsyncRequestWorkerFactor for Apache for example.
You could of course configure one thread per connection, but that only makes sense under specific circumstances.
If you're looking for this, you want kTLS, plus or minus nic accelerated kTLS. Read the Netflix CDN presentiatons for the state of the art, and see what you can make work with your system, etc.
I know abut Netflix work, and even some of this work trickled down to base FreeBSD (and opensource), but is still very fragile, not completely open-sourced and require very special hardware (1 or 2 models of specific NICs with specific versions of firmware) to work.
"EnableSendfile On" will enable that on Apache, and has been around since Apache 2.0.44. It's not enabled by default though, and as you say, TLS breaks it.
We switched from Apache to lighttpd back in the day specifically for performance issues; the other option would have been to add a new server. This wasn't "Facebook scale": just a small company with 2 devs running a few sites with quite a lot of pageviews.
Since then computers (and presumably also Apache) have become faster and I don't really know how it compares today, but at least in the past it really did make a significant enough performance difference to care about.
Getting Apache from distro repos is like using MS Word and Nginx like Notepad. Rarely you use all the features available on Apache but, mostly at the beginning, compiling Nginx to get features was the daily routine.
I still use Apache Httpd quite a bit, actually. Alongside haproxy, that is. The thing I appreciate about Apache is its modular layout. With Nginx I often run into a use case where I need to recompile stuff, something that never happened to me with Apache Httpd.
Well both of those are some guy (maybe even the same person...) saying it's an Apache 1.3 fork without copyright notices. On the other hand the full revision history is available and even linked in your first link. Also https://forum.nginx.org/read.php?29,207540,207585
> nginx is not Apache fork. I know well enough Apache 1.3 and I've got some
ideas from Apache such as memory pools, configuration methods, processing
phases, etc., but there is no line of Apache code. As to OCSP, I'm going
to implement it in the next 2.0 version.
edit:
Assuming "brianm" is Brian McCallister, he would be a former ASF board member. If "jimjag" is Jim Jagielski, that would be one of the ASF founders. Cursory googling finds a lot of shitpost-like tweets and comments from Jim Jagielski about nginx, like https://twitter.com/jimjag/status/1044638420545523712
Notice how these two comments are the only instances on the internet where this accusation is leveraged, but no sources or follow-ups. You'd think they'd be doing something with this, like sueing nginx inc.
Both of these seem to grind axes about nginx being more popular than apache, in whose development they are/were heavily involved.
It was not a fork. Some ideas from apache which were good can be found in nginx (as well as many other web-servers), but not the code. Also nginx architecture is fundamentally different from apache of that time (pre event mpm).
Yes. Nginx was forked from Apache by a Russian programmer.
What do you try to imply with your statement?
I don't know that he was trying to imply anything. But I find it useful information, since there are lots of companies with IT Security departments that will more heavily scrutinized software based on its geographic origin.
When I joined my company, one of the first things I was tasked with was determining the origin of all of the software installed by my predecessor. Some of it got chucked out because it was from certain places.
And this was looong before anyone started dropping bombs in Kyiv.
It's not weird for a company in the UK to favor UK software, or a company in Japan to favor Japanese software, etc.
It has belonged to an American company called F5 for years now. You should look for those evil Russians under your bed, I hear they like to hide there too.
Antisemitism is often referred to as "racism" and the specific domain of the word "Russian" is varied from person to person, so thanks for nitpick I guess?
In any case, I was referring to that specific "evil ${ethnicity/nationality/culture}" trope, tracing back to the day when Belarus and Ukraine had also been referred to as "Russians". So, maybe not technically "racism", but I lack a better word.
> replace with whatever nationality you like.
It has a ring of "evil Jews" to it. That's the replacement placeholder I use as a benchmark of whether something is appropriate to say out-loud.
I went to Russia during the war multiple times, lived with Russians in their homes, ate their food, talked to them - and obviously committed my code and worked on my projects with their internet.
I used their delivery service(s), their taxi service, use their music streaming service, and so on.
Not ONCE have I had any negative experience, invasion of my privacy, with any russian product.
The only negativity I experienced was caused by services I pay for (as a German) being blocked because I was in Russia.
I strongly urge people to reconsider that the Russian people are not evil, and that Russian intelligence services do not give a fuck about random people using services in Russia. Now consider that Nginx is not in Russia, its open source, and quickly it becomes clear that this whole discussion is motivated only by a boogie-man type fearmongering and nothing else.
You should be much more afraid of any tech that isnt open source, that you use, than this.
Apologies for the tone - I am just very sick and tired of this kind of talk, and as a German it reminds me of what we read in our own history books about inducing fear based on where one is from.
^above is ChatGPT style output: found mention of Russia in nginx’s wikipedia and immediately made conclusions (c)
Very sad times await us if people will start forming their opinions based
On what chatgpt hallucinates to them or what they find from quick skim of wikipedia page
Guess what, ape: Google has russian connection too (Sergey Brin) and even your chemistry books have russian connection (Mendeleev)
I started using Apache again in 2019. I wanted to set up WebDAV file sharing on my home network, and Apache's implementation of WebDAV was more compatible than nginx's. Even with https://github.com/arut/nginx-dav-ext-module, I had problems with Windows clients on nginx. Caddy 2, my go-to HTTP server, lacked a WebDAV plugin at the time. So I tried Apache, and WebDAV worked everywhere. (Since then https://github.com/mholt/caddy-webdav has come out for Caddy. I plan to test it for compatibility, but I am happy with Apache and don't see a need to migrate.)
The only time in the last ten years that I've reached for Apache was when I needed to put an LDAP auth reverse proxy on something— it looked like it was possible to do it with nginx, but would require running a separate script or dealing with Lua or something. On Apache it was batteries-included and a few lines of pasted-in config file.
I'd love to be shown a better way on that, but Apache did rack up a W for that one use case.
1. I have discovered that Matt Holt published the WebDAV plugin shortly before the launch of Caddy 2. So there was never a time when Caddy 2 was officially out and without a WebDAV plugin. I found out about the plugin later.
2. Caddy 2 actually launched in 2020, and I set up my server in 2019, when I only used Caddy 1. Caddy 1 did have an unofficial WebDAV plugin, https://github.com/hacdias/caddy-v1-webdav. I remember finding some compatibility issue with it, too.
"Fohn" is an English word directly derived from "foehn".
I am from none of those places, speak no relevant languages other than English, and I had no trouble with the phrase in question.
I appreciate your effort in trying to stick up for me, though (:
Perhaps if you want to be more helpful for those people who do conform to your assumptions, you could share a definition, in addition to your criticism.
"Fohn, an Englosh derivate of 'foehn', means 'a warm, dry wind', and is known for being particularly effective at melting snow."
I am from a native English speaking country and I had never heard the word foehn or fohn in my life, so assumed it was a typo of foot.
Which coincidentally happens to have a similar contention as standing on fresh snow compacts it, but only from the comments did I guess it was supposed to be a melting analogy.
We only use it for badly designed software that uses mod_rewrite rules as integral part of the application and not just "set those 3 rules to direct it to the entry point".
* applications are built to change them dynamically, making them part of application code, instead of you know... just having proper request router in app
* It is not "enter URL in, get rewritten URL out". You can do conditionals based on existence of files and a bunch of other stuff which means it can't be isolated from the app overusing it easily
Rewriting on loadbalancer to mangle some paths is to be avoided but overall not too bad to manage but what can happen in mod_rewrite by badly designed apps make app basically glued in into apache.
I used lighttpd for my previous job because the boss liked. The config language was definitely weird. I had to do a lot of fixups when someone made a well meaning change that didn't work properly because of how conditionals work. Usually informed by experience from when the someone was me.
I personally ditched lighttpd on my own website (PHP, large traffic, but only a single server) because it had some memory leak that would, over time, result in increasing memory usage and eventually cause the server to chug.
It had not seen any bugfix releases for quite a long time at that point, and nginx was available by then, so I made the swap. I continued to serve that website off of a single server for the rest of its lifetime.
nginx could send static file with one syscall and zero-copy if OS supports it. It could exploit all system async mechanisms - POSIX AIO, kqueue, whatever you have. Linux was worst in this regards before io_uring, and FreeBSD or Solaris were much, much better platform for nginx.
For example, Igor Sysoev (mastermide behind nginx) pushed patches to FreeBSD kernel to shave off one syscall per file on this system.
Now, when everything is HTTPS, Linux have io_uring and Igor left nginx after F5 acquisition, it is not very useful - nginx is stagnating, support for KTLS is absent, support for io_uring on Linux is absent (though there are some forks and patches for this)...
But compare nginx and lighttpd is simply stupid, it is apples-to-oranges comparison.
It doesn't sound like nginx is even close to having this wrapped up; which is a really good thing because I've tried nginx and the config and design sucks. Apache does so many things well.
That chart counts nginx and openresty as separate categories. If you combine them (which I think makes more sense, since a lot of openresty's adoption must come from ingress-nginx), nginx/openresty would be at 34%.
Either way I'm happy with a wide variety of products doing the job, it avoids lock-in.
Personally I use apache as I have very few users (internal facing stuff), it has a nice simple mod_auth_openidc config which remains the same from one year to the next
I do have to recompile ws_tunnel though as I proxy a broken product I proxy which doesn't accept the correct standard for camel-capped "WebSocket" -- my "fix" script runs
sed -i 's/WebSocket/websocket/g' ./modules/proxy/mod_proxy_wstunnel.c
> As of June 2022 W3Tech's web server count of all web sites ranked Nginx first with 33.6%. Apache was second at 31.4% and Cloudflare Server third at 21.6%.
It's interesting, it sounds like Apache is closer than I thought. I posted Netcraft's link since I've followed them for years, I'm not as familiar with W3Tech. I can't speak to which has more reliable data but W3Tech's numbers doesn't surprise me.
Eh, the prefork engine isn't awful. It's not without limitations, but it's an excellent fit for some loads and a bad/terrible fit for others.
The main limitations are:
The child ramping behavior: you should set MinChildren = MaxChildren = StartChildren. Ramping children on demand sounds nice, but it's easy to run out of memory when all the children start or spend too much time on childinit instead of serving requests.
Anytime the child spends connected to a client socket but not actively working. Some of this can be mitigated. Turning off http keepalive (or handling it elsewhere) and setting large socket buffers allows the server to generate a response, give it to the kernel, and move on to the next client. If you're often waiting significantly for disk i/o, Apache pre-fork isn't a good fit.
Http keep-alive is a big deal for
some uses, Yahoo had a nice hack for that, which I don't think made it out: have sockets wait for complete requests in another process, and send those sockets to apache over a unix socket; after apache is done with it, send it back to the 'cheapalive' daemon. That adds a bit of complexity, and I don't know of a public implementation, so not super useful to people, but it's possible to build.
I personally think prefork apache + mod_php is simpler than some other daemon + fastcgi php. But that's debatable.
Edit: oh and one more... .htaccess is clearly a performance suck. Perhaps a useful one depending on your application, but there's good reasons nobody else does it.
The only thing keeping Apache alive today is the need to support .htaccess files for PHP apps like WordPress and the like. For every other use case there are better alternatives.
I still use Apache httpd, I see no reason to change. It's a solid workhorse, I know it's not trendy anymore but I have yet to find anyone who left a website because it was served by httpd...
Ha, I remember the days where Apache was one of the poster childs of open source along with Mozilla.
Meanwhile nginx was the authors own homepage, complete with hammers and sickles, with a personal anecdote about how he read the c10k paper (describing how you should have 10,000 connections on a Pentium III ) and decided to use nonblocking io make a fast Web server.
Nowadays nginx is the safe choice and Apache is seen as a little bit old hat.
I mean, yes, there is an HTTP1, 1.1 and 2 spec, gzip spec, brotli spec, mime types, tls 1, 1.1, 1.2, and 1.3, quic spec, sni spec, but I did not bother replying as the grandparent comment hasn’t given any detail.
I actually liked the commie vibes in the free software movement. In some ways the movement was attacking big-capitals, and was attacked by big-capital.
Too bad Red Flag Linux[1] (from China) and Red Star Linux[2] (from North Korea) are not actively maintained. Nova Linux[3] (from Cuba) seems to be the only distro still somewhat maintained.
> And then when people complained about that, I explained in detail that Futurism was a popular style of propaganda art on all sides of the early 20th century conflicts; it was not used only by the Soviets and the Chinese, but also by US in their own propaganda, particularly in recruitment posters and just about everything the WPA did, and even by the Red Cross. So if you looked at our branding and it made you think of Communism, well, I'm sorry, but that's just a deep misunderstanding of Modern Art history: this is merely what poster art looked like in the 1930s, regardless of ideology!
> That was complete bullshit, of course. Yes, I absolutely branded Mozilla.org that way for the subtext of "these free software people are all a bunch of commies." I was trolling.
I've used nginx for a long time, but for the last few years I've been using Caddy for my projects. So easy to set up, easier configs and automatic tls certificates via letsencrypt
It has also been the first to gain HTTP/3 support. nginx still has some beta-quality branches which must be compiled manually and will be shipped to mainline god knows when. (Yes, HTTP/3 is noticeably faster on crappy high-latency networks, some of us do need that.)
yeah, there was a huge push for a breaking change from 2.2 to 2.4, but it was very well thought out. proof is that we had 10 years of security and features and nobody even noticed while updating.
that's actually great. and apache can keep with ngix without breaking a sweat if you know what you're doing.
the fact ngix took over apache metrics overnight is because few people know what they are doing, and while keeping apache, put ngix in front back in the days.
also nowadays every language packs their own server, which learn all the old lessons again, slowly...
It would be a great application server, if only it supported non-blocking IO and the handling of multiple requests simultaneously with each worker thread. Instead the event MPM is basically the worker MPM (thread-per-connection) with dedicated epoll/kqueue-based listener threads in front, but otherwise synchronous.
im sure nginx and whatever have way more elaborate performance features and integrations than apache, but i have never once used anything besides apache for production web serving. I've been using it for 25 years, I know everything I need to know about it, and for performance, since I'm not serving Google, there's never been any issue. I use the event mpm for static sites on Linode nanos (1 CPU / 1G virtual machine...tiny) and such a site has no problem with hacker news front page traffic.
20 years ago, Microsoft made a large donation to the Apache foundation.
I declared that it would be the end of innovation in httpd.
Microsoft, at the time, was making big moves in IIS in support of then-new ASP.NET web framework.
Although there was so much that could have been done to improve the DX/UX of Apache httpd, it stopped moving ahead, and the OSS community fragmented into nginx, lighttpd and others - often losing velocity because of the need to not only achieve feature parity with what httpd offered already, but also the slew of CVEs security issues that cropped up again and again as the Internet grew exponentially during that period as more people went from dialup to broadband, then into mobile.
What are some web servers suitable for use in containers? I’ve been using httpd or nginx but the images tend to be a bit bloated because it usually comes built on top of a distro. Are there any leaner alternatives?
Another comment along these lines was [killed], but I'll attempt to take a more diplomatic approach.
Nginx is a Russian (in its inception) product. The reason one should not be worried about this (as one is worried about Kaspersky products) is that Nginx is open source.
152 comments
[ 4.6 ms ] story [ 211 ms ] threadIt could probably replicate Linux's solution to this and stop fixing "major" version numbers. Make the next release 3.0, then 3.1, and so forth. And every so often, bump that first part so it's not on "3." forever either.
They could adopt it, but that'll mean the next release is 2.5, and if a feature is added, 2.6 after that.
Incidentally, that means that Apache is not, in fact, using SemVer. They're using the old-school even-odd system.
The x number (in x.y.z) was still used to denote a major upgrade but jumps between y were usually considered breaking changes too.
It’s also worth noting that it used to be common to have 4 sets of numbers, x.y.z.n with n being automatic build numbers.
Lastly, there’s still another common trend to have version numbers based on release date. Ubuntu do this, for example. I personally quite like this approach as it communicates a little more than just a release version. For internal projects I often go even further and recommend a git hash included as part of the release version.
So yes, versioning schemes are older than the web. However agreed standards in how to use version numbers have always varied a significantly (and still do now). And the Apache httpd project does predate the rise in popularity of semantic versioning.
I do like when first number change signals need to read the changelog (as in "backward-incompatible changes"). Semver or not.
For something like Ubuntu, signalling the age of a release to end users is more valuable than following semver strictly (not to mention that the patch part of semver wouldn’t even apply).
Whereas if your software is being consumed by other software, such as an API, then you need to communicate where interfaces might change in ways that are verifiable via other software interfaces.
So it really depends on who is consuming your software interface. You might even want multiple different version schemes for different parts of your application. You’ll sometimes see applications have one versioning scheme for their end user facing interface while their developer APIs, which are still bundled as part of their application, might follow another.
Going back to the original point about dates as version numbers, the biggest appeal for me is it takes human error out of the equation. I’ve lost track of the number of companies I have joined which were very good at supporting versioning but terrible at remembering to increment that version number. So having a system which can auto-increment version numbers takes one problem away from developers. And if you’re auto-incrementing private packages then the question becomes: “how strictly are you now following semver?” At which point you might as well have a timestamp and then have the bonus feature of communicating to your team when a specific build was committed.
I don’t think there is a right or wrong way to do these things though. You just need to pick a standard, document it and be committed to following it.
I wrote "changing primary version number" instead of "using semver" on purpose. I agree semver can be too narrow for bigger apps and that is why I only said about signalling "potential sysadmin action required", not signalling new features or bugfixes in version number.
> standalone applications,
can certainly have "we changed how configuration options work" at the very least
> distributions of packages
Distros are so far managing that extremely well all things considered
> nor operating systems
Cue loud Linus yelling about breaking userspace.
The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine.
I was making a general point. I wasn’t suggesting you were advocating semver specifically.
> can certainly have "we changed how configuration options work" at the very least
Any major change to your versioning scheme can signal that. Including having a year number as your major iteration.
But what’s more valuable to your end users in these types of scenarios is documentation about the change.
> Distros are so far managing that extremely well all things considered
You’ve completely lost me now. It sounds like you’re trying to defend Linux distributions but my comment was neither a criticism nor was it about Linux distributions per se. These are plenty of instances where several packages are distributed as a whole. Like with multimedia applications that might ship ffmpeg, a Python scripting environment and a multitude of other components.
Linux distros, of course, is another example (and one on a much bigger scale). It’s worth noting that no major distro uses semver either. Some don’t even have a minor release let alone a major version number. But their signalling around versions satisfies a different problem to what an API needs to signal. Hence my point that versioning is about sticking to a standard more than it is about trendy schemas.
> The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine.
I don’t really understand your point here but I’m happy for you that your config is still working :)
On the other side, who remembers the version of Chrome, Firefox, Thunderbird or even the Linux kernel since they started moving fast? They basically become versionless, we just upgrade to the latest one prompted to us by their autoupdates or by the OS.
Another note on this 10 years anniversary is that, though Apache 2.4 was released in 2012-01, it was a rushed release and some features were still lacking. In my opinion, the most important was that mod_proxy could not talk to unix sockets. It made Apache 2.4 hard to use in many cases. This feature only appeared with 2.4.7 in 2013-09.
Nowadays I rarely see Apache installed on web servers that I work with. In one case, it was because the sysadmin was used to it (though 2.4 broke the compatibility with 2.2's config syntax), he didn't consider changing and even kept the awful Apache prefork engine. In other cases, it was because of some modules (e.g. shibboleth) that were packaged by the OS for Apache, but not for Nginx.
I'm one of those who always just stuck with Apache because 1) I'm used to it, and 2) it's never been close to a bottleneck in our stack. Especially now that the vast majority of static content requests don't even hit the servers at all. Buy I am curious! I haven't looked at comparisons in years, but last I did, everyone liked to compare nginx to prefork Apache, which is pointless.
Its like having the same waiter vs a pool of waiters
Sources: https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-N...
https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf...
People sometimes like to have opinions about stuff. But there's no reason to google for secondary sources when the documentation is good.
Read the manual instead. The documentation for both projects is correct, short and to the point. They are both multi threaded, multi process, with an event loop. The documentation describes how to set those parameters. Look at the thread_pool directive for nginx and AsyncRequestWorkerFactor for Apache for example.
You could of course configure one thread per connection, but that only makes sense under specific circumstances.
TLS kills this, alas, and, I think, with TLS OpenSSL will be bottleneck for static content, not server.
OK. But you might as well use a fast setup if there's no cost in complexity to do so.
Since then computers (and presumably also Apache) have become faster and I don't really know how it compares today, but at least in the past it really did make a significant enough performance difference to care about.
Which use case is that?
What do you try to imply with your statement?
FLOSS licenses allow software to be used for any purpose. This is a good thing, after seeing lists of "undesireable countries" in EULAs.
Source? I fail to see any similarities between the two.
https://news.ycombinator.com/item?id=520077
Was it not? I find it hard to find sources, but I realllllly remember it started off as a heavily modified fork of Apache 1.3.
> nginx is not Apache fork. I know well enough Apache 1.3 and I've got some ideas from Apache such as memory pools, configuration methods, processing phases, etc., but there is no line of Apache code. As to OCSP, I'm going to implement it in the next 2.0 version.
edit: Assuming "brianm" is Brian McCallister, he would be a former ASF board member. If "jimjag" is Jim Jagielski, that would be one of the ASF founders. Cursory googling finds a lot of shitpost-like tweets and comments from Jim Jagielski about nginx, like https://twitter.com/jimjag/status/1044638420545523712
Notice how these two comments are the only instances on the internet where this accusation is leveraged, but no sources or follow-ups. You'd think they'd be doing something with this, like sueing nginx inc.
Both of these seem to grind axes about nginx being more popular than apache, in whose development they are/were heavily involved.
not a bad sum for apache 1.3 fork...
https://xakep.ru/2019/12/13/nginx-interview/
In 2019, Rambler tried to take over Nginx claiming dubious copyright infringement, putting the main author [https://en.wikipedia.org/wiki/Igor_Sysoev|Igor Sysoev(w)] at risk.
https://news.ycombinator.com/item?id=520077
Was it not? I find it hard to find sources, but I realllllly remember it started off as a heavily modified fork of Apache 1.3.
I don't know that he was trying to imply anything. But I find it useful information, since there are lots of companies with IT Security departments that will more heavily scrutinized software based on its geographic origin.
When I joined my company, one of the first things I was tasked with was determining the origin of all of the software installed by my predecessor. Some of it got chucked out because it was from certain places.
And this was looong before anyone started dropping bombs in Kyiv.
It's not weird for a company in the UK to favor UK software, or a company in Japan to favor Japanese software, etc.
Did you learn from chatGPT how to convicingly tell completely made up and false information?
What part do you think is wrong? I must say you are quite creative with insults. Great skill!
https://lwn.net/Articles/700060/
https://news.ycombinator.com/item?id=520077
https://xakep.ru/2019/12/13/nginx-interview/
Antisemitism is often referred to as "racism" and the specific domain of the word "Russian" is varied from person to person, so thanks for nitpick I guess?
In any case, I was referring to that specific "evil ${ethnicity/nationality/culture}" trope, tracing back to the day when Belarus and Ukraine had also been referred to as "Russians". So, maybe not technically "racism", but I lack a better word.
> replace with whatever nationality you like.
It has a ring of "evil Jews" to it. That's the replacement placeholder I use as a benchmark of whether something is appropriate to say out-loud.
Not ONCE have I had any negative experience, invasion of my privacy, with any russian product.
The only negativity I experienced was caused by services I pay for (as a German) being blocked because I was in Russia.
I strongly urge people to reconsider that the Russian people are not evil, and that Russian intelligence services do not give a fuck about random people using services in Russia. Now consider that Nginx is not in Russia, its open source, and quickly it becomes clear that this whole discussion is motivated only by a boogie-man type fearmongering and nothing else.
You should be much more afraid of any tech that isnt open source, that you use, than this.
Apologies for the tone - I am just very sick and tired of this kind of talk, and as a German it reminds me of what we read in our own history books about inducing fear based on where one is from.
Very sad times await us if people will start forming their opinions based On what chatgpt hallucinates to them or what they find from quick skim of wikipedia page
Guess what, ape: Google has russian connection too (Sergey Brin) and even your chemistry books have russian connection (Mendeleev)
While setting up Apache 2.4, I came to like certain things about it. For example, https://httpd.apache.org/docs/2.4/mod/mod_macro.html. Configuration seems less footgun-y than that of nginx (see https://news.ycombinator.com/item?id=30435282). I have also adopted https://tcl.apache.org/rivet/ and use it on the LAN server where someone else might reach for PHP. It is admittedly quite niche.
I'd love to be shown a better way on that, but Apache did rack up a W for that one use case.
> Caddy 2, my go-to HTTP server, lacked a WebDAV plugin at the time. [...] Since then https://github.com/mholt/caddy-webdav has come out for Caddy.
1. I have discovered that Matt Holt published the WebDAV plugin shortly before the launch of Caddy 2. So there was never a time when Caddy 2 was officially out and without a WebDAV plugin. I found out about the plugin later.
2. Caddy 2 actually launched in 2020, and I set up my server in 2019, when I only used Caddy 1. Caddy 1 did have an unofficial WebDAV plugin, https://github.com/hacdias/caddy-v1-webdav. I remember finding some compatibility issue with it, too.
> like fresh snow under foehn
I am from none of those places, speak no relevant languages other than English, and I had no trouble with the phrase in question.
I appreciate your effort in trying to stick up for me, though (: Perhaps if you want to be more helpful for those people who do conform to your assumptions, you could share a definition, in addition to your criticism.
"Fohn, an Englosh derivate of 'foehn', means 'a warm, dry wind', and is known for being particularly effective at melting snow."
Which coincidentally happens to have a similar contention as standing on fresh snow compacts it, but only from the comments did I guess it was supposed to be a melting analogy.
https://en.wikipedia.org/wiki/Chinook_wind
* applications are built to change them dynamically, making them part of application code, instead of you know... just having proper request router in app
* It is not "enter URL in, get rewritten URL out". You can do conditionals based on existence of files and a bunch of other stuff which means it can't be isolated from the app overusing it easily
Rewriting on loadbalancer to mangle some paths is to be avoided but overall not too bad to manage but what can happen in mod_rewrite by badly designed apps make app basically glued in into apache.
if (st && S_ISREG(st->st_mode)) return HANDLER_GO_ON;
Change it to if (st) without a regular file check, and it works as expected (great) with frameworks like Joomla etc (/administrator URLs, for example)
It had not seen any bugfix releases for quite a long time at that point, and nginx was available by then, so I made the swap. I continued to serve that website off of a single server for the rest of its lifetime.
nginx is very powerful and fast.
nginx could send static file with one syscall and zero-copy if OS supports it. It could exploit all system async mechanisms - POSIX AIO, kqueue, whatever you have. Linux was worst in this regards before io_uring, and FreeBSD or Solaris were much, much better platform for nginx.
For example, Igor Sysoev (mastermide behind nginx) pushed patches to FreeBSD kernel to shave off one syscall per file on this system.
Now, when everything is HTTPS, Linux have io_uring and Igor left nginx after F5 acquisition, it is not very useful - nginx is stagnating, support for KTLS is absent, support for io_uring on Linux is absent (though there are some forks and patches for this)...
But compare nginx and lighttpd is simply stupid, it is apples-to-oranges comparison.
Each one has its niche, of course.
Even Youtube used Lighttpd at some point.
Both are http servers, and lighttpd came out before Nginx, they both tried to solve the c10k problem.
nginx is at: 26% Apache is at 20%
It doesn't sound like nginx is even close to having this wrapped up; which is a really good thing because I've tried nginx and the config and design sucks. Apache does so many things well.
Personally I use apache as I have very few users (internal facing stuff), it has a nice simple mod_auth_openidc config which remains the same from one year to the next
I do have to recompile ws_tunnel though as I proxy a broken product I proxy which doesn't accept the correct standard for camel-capped "WebSocket" -- my "fix" script runs
sed -i 's/WebSocket/websocket/g' ./modules/proxy/mod_proxy_wstunnel.c
and recompiles
From the wiki.
Eh, the prefork engine isn't awful. It's not without limitations, but it's an excellent fit for some loads and a bad/terrible fit for others.
The main limitations are:
The child ramping behavior: you should set MinChildren = MaxChildren = StartChildren. Ramping children on demand sounds nice, but it's easy to run out of memory when all the children start or spend too much time on childinit instead of serving requests.
Anytime the child spends connected to a client socket but not actively working. Some of this can be mitigated. Turning off http keepalive (or handling it elsewhere) and setting large socket buffers allows the server to generate a response, give it to the kernel, and move on to the next client. If you're often waiting significantly for disk i/o, Apache pre-fork isn't a good fit.
Http keep-alive is a big deal for some uses, Yahoo had a nice hack for that, which I don't think made it out: have sockets wait for complete requests in another process, and send those sockets to apache over a unix socket; after apache is done with it, send it back to the 'cheapalive' daemon. That adds a bit of complexity, and I don't know of a public implementation, so not super useful to people, but it's possible to build.
I personally think prefork apache + mod_php is simpler than some other daemon + fastcgi php. But that's debatable.
Edit: oh and one more... .htaccess is clearly a performance suck. Perhaps a useful one depending on your application, but there's good reasons nobody else does it.
As far as benchmarks go, nginx is much faster using less memory.
Apache2 could save energy on the scale it is still used.
I stopped using it for 7 years now
[1] https://w3techs.com/technologies/history_overview/web_server...
Meanwhile nginx was the authors own homepage, complete with hammers and sickles, with a personal anecdote about how he read the c10k paper (describing how you should have 10,000 connections on a Pentium III ) and decided to use nonblocking io make a fast Web server.
Nowadays nginx is the safe choice and Apache is seen as a little bit old hat.
Like how example in Apache ordering of vhosts doesn't matter, except for choosing the default vhosts
Non-conformant to what? Is it following a spec somewhere?
My brain's shot and I thought they were talking about some sort of server spec (not sure for what? conig? request handling?)
https://www-archive.mozilla.org/party/2002/flyer.html
I actually liked the commie vibes in the free software movement. In some ways the movement was attacking big-capitals, and was attacked by big-capital.
Too bad Red Flag Linux[1] (from China) and Red Star Linux[2] (from North Korea) are not actively maintained. Nova Linux[3] (from Cuba) seems to be the only distro still somewhat maintained.
1: https://en.wikipedia.org/wiki/Red_Flag_Linux
2: https://en.wikipedia.org/wiki/Red_Star_OS
3: https://en.wikipedia.org/wiki/Nova_(operating_system)
> That was complete bullshit, of course. Yes, I absolutely branded Mozilla.org that way for the subtext of "these free software people are all a bunch of commies." I was trolling.
> I trolled them so hard.
No direct link to source because jwz.
https://dereferer.link/?https://www.jwz.org/blog/2016/10/the...
yeah, there was a huge push for a breaking change from 2.2 to 2.4, but it was very well thought out. proof is that we had 10 years of security and features and nobody even noticed while updating.
that's actually great. and apache can keep with ngix without breaking a sweat if you know what you're doing.
the fact ngix took over apache metrics overnight is because few people know what they are doing, and while keeping apache, put ngix in front back in the days.
also nowadays every language packs their own server, which learn all the old lessons again, slowly...
I declared that it would be the end of innovation in httpd.
Microsoft, at the time, was making big moves in IIS in support of then-new ASP.NET web framework.
Although there was so much that could have been done to improve the DX/UX of Apache httpd, it stopped moving ahead, and the OSS community fragmented into nginx, lighttpd and others - often losing velocity because of the need to not only achieve feature parity with what httpd offered already, but also the slew of CVEs security issues that cropped up again and again as the Internet grew exponentially during that period as more people went from dialup to broadband, then into mobile.
[0] https://caddyserver.com
Nginx is a Russian (in its inception) product. The reason one should not be worried about this (as one is worried about Kaspersky products) is that Nginx is open source.
Do I have this right?