11 ms·

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 un

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.

tempestn 3y ago
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.
- water9 3y ago
  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)
  - tempestn 3y ago
    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!)
    - water9 3y ago
      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
      - xorcist 3y ago
        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.
        water9 3y ago
        NGINX is multiprocess Single Threaded Apache is one thread per connection Its like having the same waiter vs a pool of waiters Sources: https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-NGINX-Infographic_Edit-2_New-SG-Logo.png https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-N... https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf=APwXEdcNR7H8yr2Iu7i9S9_FCIJgxziYPA:1684659916505&q=Is+NGINX+single+threaded+or+multithreaded https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf...
        3y ago
  - blacklion 3y ago
    Does Apache can do zero-copy for static content? nginx could on properly configured system. TLS kills this, alas, and, I think, with TLS OpenSSL will be bottleneck for static content, not server.
    - water9 3y ago
      I think it has more to do with the event driven nature of nginx vs the thread per connection nature of Apache.
    - toast0 3y ago
      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.
      - blacklion 3y ago
        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.
    - rb12345 3y ago
      "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.
- cheekibreeki2 3y ago
  For 99% of use cases webserver speed is rarely an issue.
  - nordsieck 3y ago
    > For 99% of use cases webserver speed is rarely an issue. OK. But you might as well use a fast setup if there's no cost in complexity to do so.
    - deleted 3y ago
      [deleted]
    - paulddraper 3y ago
      Rule 1: there is always a complexity cost
      - blackflame7000 3y ago
        [dead]
  - arp242 3y ago
    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.
    - tempestn 3y ago
      Were you using mpm_prefork on apache, or one of the threaded process managers?
      - arp242 3y ago
Freeaqingme 3y ago
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.
- gtirloni 3y ago
  > often run into a use case where I need to recompile Which use case is that?
  - stevefan1999 3y ago
    for example geoip2 support
    - ilyt 3y ago
      Debian have it pre-packaged as nginx module.
- tecleandor 3y ago
  Note, just in case, that nginx already has support for dynamic modules, and you don't have to rebuild it to add functionality.
ape4 3y ago
[flagged]
- cies 3y ago
  Yes. Nginx was forked from Apache by a Russian programmer. 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.
  - formerly_proven 3y ago
    > Nginx was forked from Apache Source? I fail to see any similarities between the two.
    - wildylion 3y ago
      Not forked, but written from scratch and was used at Rambler at the time. In 2019, Rambler tried to take over Nginx claiming dubious copyright infringement, putting the main author [https://en.wikipedia.org/wiki/Igor_Sysoev|Igor https://en.wikipedia.org/wiki/Igor_Sysoev|Igor Sysoev(w)] at risk.
    - cies 3y ago
      https://lwn.net/Articles/700060/ https://lwn.net/Articles/700060/ https://news.ycombinator.com/item?id=520077 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.
      - formerly_proven 3y ago
        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 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 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.
networked 3y ago
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 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 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.) 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 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 https://news.ycombinator.com/item?id=30435282). I have also adopted https://tcl.apache.org/rivet/ https://tcl.apache.org/rivet/ and use it on the LAN server where someone else might reach for PHP. It is admittedly quite niche.
- mikepurvis 3y ago
  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.
  - grepfru_it 3y ago
    Traefik, bruv
  - jacooper 3y ago
    Caddy, hands down the most sane webserver config for a reverse proxy.
    - mikepurvis 3y ago
      Thanks! That does look pretty reasonable: https://authp.github.io/docs/authenticate/ldap/ldap https://authp.github.io/docs/authenticate/ldap/ldap
unixhero 3y ago
Unless you're from Canada, Alaska or Norway this saying will make absolute no sense to anyone: > like fresh snow under foehn
- deleted 3y ago
  [deleted]
- tetha 3y ago
  Works for Germany too, since a Föhn is either a kind of warm wind, or a hair dryer.
  - johannes1234321 3y ago
    The hairdryer is the Fön without h.
    - aristidb 3y ago
      Since the spelling reform of 1996 both are spelled Föhn
  - Biganon 3y ago
    Same in Switzerland, even in the French speaking part
  - edwinjm 3y ago
    Same for Dutch. It's the common name for a hair dryer.
- madduci 3y ago
  You get it also under the Alps
- greggyb 3y ago
  "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."
ilyt 3y ago
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".
- slim 3y ago
  some peoples badly designed software is other peoples micro services
  - ilyt 3y ago
    The problem with mod_rewrite rules is that: * 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.
Thaxll 3y ago
Before nginx there was lighttpd that was pretty much what Nginx would be later on.
- ceeam 3y ago
  I still use Lighttpd. My weird idea why Lighty lost the war is that it had somewhat unorthodox rewrite rules, namely this one line in mod_rewrite.c: 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)
  - toast0 3y ago
    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.
  - Blackthorn 3y ago
    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.
- blacklion 3y ago
  Nope. lighttpd is simple and light. 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.
truthreplicator 3y ago
The April 2023 Netcraft survey: https://news.netcraft.com/archives/category/web-server-survey/ https://news.netcraft.com/archives/category/web-server-surve... 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.
- cypress66 3y ago
  That's most likely all cpanel php WordPress stuff that relies on .htaccess files
- virtuous_signal 3y ago
  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%.
  - ta1243 3y ago
    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 and recompiles
- jgalt212 3y ago
  > 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%. From the wiki.
  - truthreplicator 3y ago
    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.
toast0 3y ago
> awful Apache prefork engine 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.

tempestn 3y ago

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.

water9 3y ago
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)
- tempestn 3y ago
  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!)
  - water9 3y ago
    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
    - xorcist 3y ago
      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.
      - water9 3y ago
        NGINX is multiprocess Single Threaded Apache is one thread per connection Its like having the same waiter vs a pool of waiters Sources: https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-NGINX-Infographic_Edit-2_New-SG-Logo.png https://serverguy.com/wp-content/uploads/2020/10/Apache-Vs-N... https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf=APwXEdcNR7H8yr2Iu7i9S9_FCIJgxziYPA:1684659916505&q=Is+NGINX+single+threaded+or+multithreaded https://www.google.com/search?rlz=1C1CHBF_enUS874US874&sxsrf...
        3y ago
- blacklion 3y ago
  Does Apache can do zero-copy for static content? nginx could on properly configured system. TLS kills this, alas, and, I think, with TLS OpenSSL will be bottleneck for static content, not server.
  - water9 3y ago
    I think it has more to do with the event driven nature of nginx vs the thread per connection nature of Apache.
  - toast0 3y ago
    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.
    - blacklion 3y ago
      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.
  - rb12345 3y ago
    "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.
cheekibreeki2 3y ago
For 99% of use cases webserver speed is rarely an issue.
- nordsieck 3y ago
  > For 99% of use cases webserver speed is rarely an issue. OK. But you might as well use a fast setup if there's no cost in complexity to do so.
  - deleted 3y ago
    [deleted]
  - paulddraper 3y ago
    Rule 1: there is always a complexity cost
    - blackflame7000 3y ago
      [dead]
- arp242 3y ago
  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.
  - tempestn 3y ago
    Were you using mpm_prefork on apache, or one of the threaded process managers?
    - arp242 3y ago

Freeaqingme 3y ago

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.

gtirloni 3y ago
> often run into a use case where I need to recompile Which use case is that?
- stevefan1999 3y ago
  for example geoip2 support
  - ilyt 3y ago
    Debian have it pre-packaged as nginx module.
tecleandor 3y ago
Note, just in case, that nginx already has support for dynamic modules, and you don't have to rebuild it to add functionality.

ape4 3y ago

[flagged]

cies 3y ago
Yes. Nginx was forked from Apache by a Russian programmer. 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.
- formerly_proven 3y ago
  > Nginx was forked from Apache Source? I fail to see any similarities between the two.
  - wildylion 3y ago
    Not forked, but written from scratch and was used at Rambler at the time. In 2019, Rambler tried to take over Nginx claiming dubious copyright infringement, putting the main author [https://en.wikipedia.org/wiki/Igor_Sysoev|Igor https://en.wikipedia.org/wiki/Igor_Sysoev|Igor Sysoev(w)] at risk.
  - cies 3y ago
    https://lwn.net/Articles/700060/ https://lwn.net/Articles/700060/ https://news.ycombinator.com/item?id=520077 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.
    - formerly_proven 3y ago
      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 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 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.

networked 3y ago

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 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 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.) 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 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 https://news.ycombinator.com/item?id=30435282). I have also adopted https://tcl.apache.org/rivet/ https://tcl.apache.org/rivet/ and use it on the LAN server where someone else might reach for PHP. It is admittedly quite niche.

mikepurvis 3y ago
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.
- grepfru_it 3y ago
  Traefik, bruv
- jacooper 3y ago
  Caddy, hands down the most sane webserver config for a reverse proxy.
  - mikepurvis 3y ago
    Thanks! That does look pretty reasonable: https://authp.github.io/docs/authenticate/ldap/ldap https://authp.github.io/docs/authenticate/ldap/ldap

unixhero 3y ago

Unless you're from Canada, Alaska or Norway this saying will make absolute no sense to anyone: > like fresh snow under foehn

deleted 3y ago
[deleted]
tetha 3y ago
Works for Germany too, since a Föhn is either a kind of warm wind, or a hair dryer.
- johannes1234321 3y ago
  The hairdryer is the Fön without h.
  - aristidb 3y ago
    Since the spelling reform of 1996 both are spelled Föhn
- Biganon 3y ago
  Same in Switzerland, even in the French speaking part
- edwinjm 3y ago
  Same for Dutch. It's the common name for a hair dryer.
madduci 3y ago
You get it also under the Alps
greggyb 3y ago
"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."

ilyt 3y ago

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".

slim 3y ago
some peoples badly designed software is other peoples micro services
- ilyt 3y ago
  The problem with mod_rewrite rules is that: * 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.

Thaxll 3y ago

Before nginx there was lighttpd that was pretty much what Nginx would be later on.

ceeam 3y ago
I still use Lighttpd. My weird idea why Lighty lost the war is that it had somewhat unorthodox rewrite rules, namely this one line in mod_rewrite.c: 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)
- toast0 3y ago
  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.
- Blackthorn 3y ago
  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.
blacklion 3y ago
Nope. lighttpd is simple and light. 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.

truthreplicator 3y ago

The April 2023 Netcraft survey: https://news.netcraft.com/archives/category/web-server-survey/ https://news.netcraft.com/archives/category/web-server-surve... 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.

cypress66 3y ago
That's most likely all cpanel php WordPress stuff that relies on .htaccess files
virtuous_signal 3y ago
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%.
- ta1243 3y ago
  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 and recompiles
jgalt212 3y ago
> 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%. From the wiki.
- truthreplicator 3y ago
  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.

toast0 3y ago

> awful Apache prefork engine 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.