8 ms·

Anybody still using Apache?

by kimi 5y ago

jmnicolas 5y ago
What's wrong with Apache? (honest question)
- LinuxBender 5y ago
  Nothing really. Historically Apache HTTPD was slower than the newer web servers like NGinx when Apache HTTPD 2.2 was the mainline version. This is no longer the case with Apache 2.4 using the latest APR libraries. 2.4 has been out for a very long time, but some Linux distros were slow to uptake it.
  - da_chicken 5y ago
    Just like some of them were slow to take on 2.2 over 2.0, and 2.0 over 1.2. Web servers have historically been pretty conservative as far as software goes.
- trey-jones 5y ago
  About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine for most applications. There are other reasons to use nginx, and there are other reasons to use Apache. Both are fine, and I hear https://caddyserver.com/ https://caddyserver.com/ is coming in hot!
  - mholt 5y ago
    Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities.
    - throw_m239339 5y ago
      > Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities. At the expense of the memory footprint because developed with Go. Hi Caddy creator!
      - eric_h 5y ago
        > At the expense of the memory footprint because developed with Go. Hi Caddy creator! Makes sense to me that something built in a language with more memory safety than C would use more memory, but is it really significant in practice? I use go every day and memory usage has not been a significant issue for many applications.
        deleted 5y ago
        [deleted]
        arp242 5y ago
        I don't use Caddy, but I've written plenty of Go apps (which usually implement their own HTTP server with net/http) with plenty of users, and memory usage has never been much of a concern. There are other performance concerns of course, e.g. GC latencies, and at times the GC may bite you. See e.g. the "taming Go memory usage" story from a few days ago[1], but this usually isn't a huge concern for many use cases. [1]: https://news.ycombinator.com/item?id=28608083 https://news.ycombinator.com/item?id=28608083
      - whateveracct 5y ago
        We're talking about shaving megs here rofl cmon now terminal systems engineer brain is everywhere
    - SahAssar 5y ago
      Might be nice to disclose your involvement when commenting on caddy-related threads.
      - 5y ago
  - killingtime74 5y ago
    Caddy also does the whole Let’s Encrypt thing for you for SSL
    - yourad_io 5y ago
      There's a plugin for nginx that works well: $ apt-get install python3-certbot-nginx $ sudo certbot --nginx -d example.com -d www.example.com https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/ https://www.nginx.com/blog/using-free-ssltls-certificates-fr... On the other hand, caddy seems to auto renew them as well - one less cron job: > Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed. https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https Neat, but still not sold.
      - yjftsjthsd-h 5y ago
        certbot works with apache, if you're willing to spend that effort
      - francislavoie 5y ago
        What are you not sold on?
      - arp242 5y ago
        I never cared much for certbot because "sudo certbot" and it works by rewriting config files. I don't really fancy running it as root (which can probably be avoided with some muckery, but still) or a program automatically rewriting my configs. Overall, the entire thing seems very complex automagic black box last time I tried it (already years ago). Sometimes trying to make something easier can make it harder.
  - jart 5y ago
    redbean is a pure fork() web server and according to ab it is much faster than nginx. I feel like we've come full circle with history. Apache started off with fork() since it offers the strongest security versus other i/o models. The problem is that code bloat makes fork() go slower so as Apache ballooned over the years there was this race to the bottom in terms of i/o models, caused by tragedy of the commons. https://youtu.be/1ZTRb-2DZGs?t=761 https://youtu.be/1ZTRb-2DZGs?t=761
  - xorcist 5y ago
    To be fair, the event worker in Apache and nginx are roughly the same age, 2004. Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time. What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them. And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.
    - trulyme 5y ago
      Nginx configs do look more readable, but they have a lot of gotchas themselves. Quite surprising actually.
    - innocenat 5y ago
      I agree wholeheartedly that php-fpm rapidly speed up nginx adoption. Before nginx, lighttpd was a thing. It also comes with `spawn-fcgi` to handle fastcgi, but it's a little complex to set up. Back then people were also using `spawn-fcgi` with nginx, too. I remembered reading some tutorial and decided that I will continue to use Apache with mod_php due to complexity. When php-fpm come, I immediately switched.
- beamatronic 5y ago
  I was looking for a pre-hardened httpd just for serving static html files, is there one?
  - ldoughty 5y ago
    Probably not the answer you want to hear... But I push that stuff to AWS S3 website and put a CDN in front for SSL... that's my solution for "easy secure static site" when I don't want to invest more than an hour or so a year on the infrastructure... But obviously that's not for everyone. Edit: specific to your request, I would probably set up a container pointing to the latest apache build, and write a script to pull the latest image then roll over the container... Don't need to wait for your OS of choice to have the fixed versions... Your never more than a day behind
  - notRobot 5y ago
    https://github.com/emikulic/darkhttpd https://github.com/emikulic/darkhttpd darkhttpd is an option
    - chriswarbo 5y ago
      I've been running darkhttpd for years. I was recently complemented on how fast my site loads; although part of that is probably the lack of JS tracking bloat.
  - lhoff 5y ago
    Maybe Gatling fits your needs https://www.fefe.de/gatling/ https://www.fefe.de/gatling/
  - juangacovas 5y ago
    lighttpd is still a thing (I use it for very critical stuff)
deleted 5y ago
[deleted]
0x000000001 5y ago
Considering that it has a lot of features Nginx makes you pay for, yes
- rfraile 5y ago
  Stock Apache from distros compared with Nginx, is like MSWord vs Notepad. An Apache compiled with the exact options that you'll need shines, like an Nginx well done.
brendanclune 5y ago
It appears so [1]. It's surprising how far behind most non-tech industries are when it comes to legacy software (not sure I'd call Apache "legacy", but still). I'd also be interested to see the stats for IT/developer positions in tech vs. non-tech fields. My intuition suggests that there are a lot more Apache sysadmins than you'd think. [1] https://w3techs.com/technologies/overview/web_server https://w3techs.com/technologies/overview/web_server
cestith 5y ago
Lots of companies that have been around a while and haven't replaced legacy applications still run those behind the web server they were designed to run behind. Moving to another server seems simple until you actually try to do that with a handful of 15-year-old sites with proxy rules, rewrites, custom headers, and such in one server's central config file and a bunch of per-directory access files. Technical debt is a real thing. Shared hosting is still huge for small sites, and the major control panels for that (cPanel, Plesk, DirectAdmin, vDeck) still support Apache as the primary web server.
- trulyme 5y ago
  And Apache supports .htaccess files which are great for hosting (nginx doesn't, afaik).
  - arp242 5y ago
    Not by default, but since nginx is pretty flexible you can implement support for it, and it seems like people have. There are some downsides with .htaccess files though; since it can change you need to at least check if it was modified since the last request, and since it's recursive (i.e. /foo/.htaccess applies to /foo/bar/file.txt) you may need to check several locations. Basically, it's a lot of stat() calls for every request. The upside is that it's convenient; i.e. "tar xf somephpapp.tar.gz" and it "just works" without mucking about with configuration to disallow certain files, but this convenience comes with a fairly hefty performance impact, and it's only certain types of PHP apps that really take advantage of this.
    - trulyme 5y ago
      I don't agree with the downsides - what you are describing is simply a bad implementation of this mechanism. At the very least, the files could only be checked every 5 seconds, or inotify or similar mechanism could be used. The main upside is that it is possible for sysadmin to allow 3rd party users to change parts of http server config via ftp (!). And last I checked, php was dominating web landscape - I would argue that the convenience of deploying plays a large part in this. Plugins... If it is not part of original app, can I trust it will stay available? I might as well use Apache instead.
bcrosby95 5y ago
We still use Apache. It's never been a bottleneck for us so we haven't had a reason to switch.
omoikane 5y ago
Apache is at 26%, behind nginx's 36%, according to Netcraft: https://news.netcraft.com/archives/category/web-server-survey/ https://news.netcraft.com/archives/category/web-server-surve...
rcoder 5y ago
Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it. Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Furthermore, these modules could themselves expose language-specific APIs; ergo `mod_perl` and its ilk, which provide a bunch of useful building blocks for a full-stack webapp but are entirely specific to Apache's module API (vs. something more standard like FCGI, WSGI, etc.) I've worked at some shops with heavy investments in Apache-based application servers and the cost of moving away from HTTPD modules and towards a more standalone, Apache-free implementation was generally quite high. Usually you need some other forcing function (rewrite in a new language, microservice decomposition, etc.) to justify the investment.
- francislavoie 5y ago
  I don't understand the claims you're making. Caddy is very pluggable, you can write a request handler middleware very easily: https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy
- mholt 5y ago
  > Unlike nginx or Caddy, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Huh? I must be misunderstanding, because everything in Caddy is a module, even its HTTP server, and all its middleware handlers are equally modules that you can plug in as much as any other module you could write and publish. Some Caddy modules also expose dynamic scripting / language interpretation capabilities as well. Caddy is used for well more than just static files and HTTP reverse proxying.
nobody9999 5y ago
>Anybody still using Apache? A similar number of folks as are using nginx[0] [0] https://w3techs.com/technologies/overview/web_server https://w3techs.com/technologies/overview/web_server
codegeek 5y ago
This reminds me of the classic "Anybody still using PHP" question.
- lucb1e 5y ago
  raises remaining hand Now if someone asks me if I also still use the same laptop as when Apache had >6 times the market share of Nginx (https://news.netcraft.com/archives/category/web-server-survey/ https://news.netcraft.com/archives/category/web-server-surve...), I will need to find more hands.
lucb1e 5y ago
You seem to not be a fan of it, do you have a feature-complete replacement? For example, Nginx's standpoint on htaccess is basically "find yourself another web server" (https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/ https://www.nginx.com/resources/wiki/start/topics/examples/l...). I don't fancy giving users access to /etc/nginx and the power to reload the config just to add aliases on their own subdomains. Much better if they can add password protection to a directory by themselves. It also breaks that each site can live in its own project directory: without htaccess, if I copy over a project I would also have to modify my global nginx config to set per-directory (or at least per vhost) aliases, error pages, etc. Right now, I can say that deploying a project is "download the directory into the desired location and configure your database credentials and a pepper in the config.php". No global configuration changes are ever needed, the global config only does global stuff: tls ciphers, fallback error pages, compression, log files, and more such things. And that's ignoring the fact that, even if there was some objectively better web server, I'd have the task of rewriting a decade of htaccess files into their fancy new format while Apache2 is still alive and properly supported.
rsync 5y ago
I used to run apache for general purpose web service / perl CGI and Zeus to serve static images. I thought I was so cool ...
- 0des 5y ago
  oh come come now, you're still kinda cool.
oars 5y ago
We use Apache Kafka at our company. It's one of the most popular streaming platforms in the world at the moment. https://kafka.apache.org/ https://kafka.apache.org/
Symbiote 5y ago
I use it. We probably have 50+ websites hosted on Apache HTTPD. It's very stable, supports that one special thing many sites need (special headers, stripping file extensions, caching etc) and has excellent documentation. It's not fashionable, but it will still be unfashionable in another 10 years, and we won't have needed to update the configurations in that time.

Anybody still using Apache?

by kimi 5y ago

Anybody still using Apache?

jmnicolas 5y ago

What's wrong with Apache? (honest question)

LinuxBender 5y ago
Nothing really. Historically Apache HTTPD was slower than the newer web servers like NGinx when Apache HTTPD 2.2 was the mainline version. This is no longer the case with Apache 2.4 using the latest APR libraries. 2.4 has been out for a very long time, but some Linux distros were slow to uptake it.
- da_chicken 5y ago
  Just like some of them were slow to take on 2.2 over 2.0, and 2.0 over 1.2. Web servers have historically been pretty conservative as far as software goes.
trey-jones 5y ago
About a decade ago nginx stormed onto the scene with event based multi-processing, and even though mpm-event became a thing not too long after that, Apache retained mpm-prefork and then mpm-worker as defaults for a very long time, and lost a lot of market share. A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine for most applications. There are other reasons to use nginx, and there are other reasons to use Apache. Both are fine, and I hear https://caddyserver.com/ https://caddyserver.com/ is coming in hot!
- mholt 5y ago
  Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities.
  - throw_m239339 5y ago
    > Yeah; and unlike nginx and Apache, Caddy has a higher degree of memory safety, so it's impervious to a whole class of vulnerabilities. At the expense of the memory footprint because developed with Go. Hi Caddy creator!
    - eric_h 5y ago
      > At the expense of the memory footprint because developed with Go. Hi Caddy creator! Makes sense to me that something built in a language with more memory safety than C would use more memory, but is it really significant in practice? I use go every day and memory usage has not been a significant issue for many applications.
      - deleted 5y ago
        [deleted]
      - arp242 5y ago
        I don't use Caddy, but I've written plenty of Go apps (which usually implement their own HTTP server with net/http) with plenty of users, and memory usage has never been much of a concern. There are other performance concerns of course, e.g. GC latencies, and at times the GC may bite you. See e.g. the "taming Go memory usage" story from a few days ago[1], but this usually isn't a huge concern for many use cases. [1]: https://news.ycombinator.com/item?id=28608083 https://news.ycombinator.com/item?id=28608083
    - whateveracct 5y ago
      We're talking about shaving megs here rofl cmon now terminal systems engineer brain is everywhere
  - SahAssar 5y ago
    Might be nice to disclose your involvement when commenting on caddy-related threads.
    - 5y ago
- killingtime74 5y ago
  Caddy also does the whole Let’s Encrypt thing for you for SSL
  - yourad_io 5y ago
    There's a plugin for nginx that works well: $ apt-get install python3-certbot-nginx $ sudo certbot --nginx -d example.com -d www.example.com https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/ https://www.nginx.com/blog/using-free-ssltls-certificates-fr... On the other hand, caddy seems to auto renew them as well - one less cron job: > Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed. https://caddyserver.com/docs/automatic-https https://caddyserver.com/docs/automatic-https Neat, but still not sold.
    - yjftsjthsd-h 5y ago
      certbot works with apache, if you're willing to spend that effort
    - francislavoie 5y ago
      What are you not sold on?
    - arp242 5y ago
      I never cared much for certbot because "sudo certbot" and it works by rewriting config files. I don't really fancy running it as root (which can probably be avoided with some muckery, but still) or a program automatically rewriting my configs. Overall, the entire thing seems very complex automagic black box last time I tried it (already years ago). Sometimes trying to make something easier can make it harder.
- jart 5y ago
  redbean is a pure fork() web server and according to ab it is much faster than nginx. I feel like we've come full circle with history. Apache started off with fork() since it offers the strongest security versus other i/o models. The problem is that code bloat makes fork() go slower so as Apache ballooned over the years there was this race to the bottom in terms of i/o models, caused by tragedy of the commons. https://youtu.be/1ZTRb-2DZGs?t=761 https://youtu.be/1ZTRb-2DZGs?t=761
- xorcist 5y ago
  To be fair, the event worker in Apache and nginx are roughly the same age, 2004. Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time. What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them. And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.
  - trulyme 5y ago
    Nginx configs do look more readable, but they have a lot of gotchas themselves. Quite surprising actually.
  - innocenat 5y ago
    I agree wholeheartedly that php-fpm rapidly speed up nginx adoption. Before nginx, lighttpd was a thing. It also comes with `spawn-fcgi` to handle fastcgi, but it's a little complex to set up. Back then people were also using `spawn-fcgi` with nginx, too. I remembered reading some tutorial and decided that I will continue to use Apache with mod_php due to complexity. When php-fpm come, I immediately switched.
beamatronic 5y ago
I was looking for a pre-hardened httpd just for serving static html files, is there one?
- ldoughty 5y ago
  Probably not the answer you want to hear... But I push that stuff to AWS S3 website and put a CDN in front for SSL... that's my solution for "easy secure static site" when I don't want to invest more than an hour or so a year on the infrastructure... But obviously that's not for everyone. Edit: specific to your request, I would probably set up a container pointing to the latest apache build, and write a script to pull the latest image then roll over the container... Don't need to wait for your OS of choice to have the fixed versions... Your never more than a day behind
- notRobot 5y ago
  https://github.com/emikulic/darkhttpd https://github.com/emikulic/darkhttpd darkhttpd is an option
  - chriswarbo 5y ago
    I've been running darkhttpd for years. I was recently complemented on how fast my site loads; although part of that is probably the lack of JS tracking bloat.
- lhoff 5y ago
  Maybe Gatling fits your needs https://www.fefe.de/gatling/ https://www.fefe.de/gatling/
- juangacovas 5y ago
  lighttpd is still a thing (I use it for very critical stuff)

deleted 5y ago

[deleted]

0x000000001 5y ago

Considering that it has a lot of features Nginx makes you pay for, yes

rfraile 5y ago
Stock Apache from distros compared with Nginx, is like MSWord vs Notepad. An Apache compiled with the exact options that you'll need shines, like an Nginx well done.

brendanclune 5y ago

It appears so [1]. It's surprising how far behind most non-tech industries are when it comes to legacy software (not sure I'd call Apache "legacy", but still). I'd also be interested to see the stats for IT/developer positions in tech vs. non-tech fields. My intuition suggests that there are a lot more Apache sysadmins than you'd think. [1] https://w3techs.com/technologies/overview/web_server https://w3techs.com/technologies/overview/web_server

cestith 5y ago

Lots of companies that have been around a while and haven't replaced legacy applications still run those behind the web server they were designed to run behind. Moving to another server seems simple until you actually try to do that with a handful of 15-year-old sites with proxy rules, rewrites, custom headers, and such in one server's central config file and a bunch of per-directory access files. Technical debt is a real thing. Shared hosting is still huge for small sites, and the major control panels for that (cPanel, Plesk, DirectAdmin, vDeck) still support Apache as the primary web server.

trulyme 5y ago
And Apache supports .htaccess files which are great for hosting (nginx doesn't, afaik).
- arp242 5y ago
  Not by default, but since nginx is pretty flexible you can implement support for it, and it seems like people have. There are some downsides with .htaccess files though; since it can change you need to at least check if it was modified since the last request, and since it's recursive (i.e. /foo/.htaccess applies to /foo/bar/file.txt) you may need to check several locations. Basically, it's a lot of stat() calls for every request. The upside is that it's convenient; i.e. "tar xf somephpapp.tar.gz" and it "just works" without mucking about with configuration to disallow certain files, but this convenience comes with a fairly hefty performance impact, and it's only certain types of PHP apps that really take advantage of this.
  - trulyme 5y ago
    I don't agree with the downsides - what you are describing is simply a bad implementation of this mechanism. At the very least, the files could only be checked every 5 seconds, or inotify or similar mechanism could be used. The main upside is that it is possible for sysadmin to allow 3rd party users to change parts of http server config via ftp (!). And last I checked, php was dominating web landscape - I would argue that the convenience of deploying plays a large part in this. Plugins... If it is not part of original app, can I trust it will stay available? I might as well use Apache instead.

bcrosby95 5y ago

We still use Apache. It's never been a bottleneck for us so we haven't had a reason to switch.

omoikane 5y ago

Apache is at 26%, behind nginx's 36%, according to Netcraft: https://news.netcraft.com/archives/category/web-server-survey/ https://news.netcraft.com/archives/category/web-server-surve...

rcoder 5y ago

Note: several folks have pointed out that I was totally wrong about Caddy. Sorry! I should look at it again before I spout off any more opinions about it. Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Furthermore, these modules could themselves expose language-specific APIs; ergo `mod_perl` and its ilk, which provide a bunch of useful building blocks for a full-stack webapp but are entirely specific to Apache's module API (vs. something more standard like FCGI, WSGI, etc.) I've worked at some shops with heavy investments in Apache-based application servers and the cost of moving away from HTTPD modules and towards a more standalone, Apache-free implementation was generally quite high. Usually you need some other forcing function (rewrite in a new language, microservice decomposition, etc.) to justify the investment.

francislavoie 5y ago
I don't understand the claims you're making. Caddy is very pluggable, you can write a request handler middleware very easily: https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy
mholt 5y ago
> Unlike nginx or Caddy, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy. Huh? I must be misunderstanding, because everything in Caddy is a module, even its HTTP server, and all its middleware handlers are equally modules that you can plug in as much as any other module you could write and publish. Some Caddy modules also expose dynamic scripting / language interpretation capabilities as well. Caddy is used for well more than just static files and HTTP reverse proxying.

nobody9999 5y ago

>Anybody still using Apache? A similar number of folks as are using nginx[0] [0] https://w3techs.com/technologies/overview/web_server https://w3techs.com/technologies/overview/web_server

codegeek 5y ago

This reminds me of the classic "Anybody still using PHP" question.

lucb1e 5y ago
raises remaining hand Now if someone asks me if I also still use the same laptop as when Apache had >6 times the market share of Nginx (https://news.netcraft.com/archives/category/web-server-survey/ https://news.netcraft.com/archives/category/web-server-surve...), I will need to find more hands.

lucb1e 5y ago

You seem to not be a fan of it, do you have a feature-complete replacement? For example, Nginx's standpoint on htaccess is basically "find yourself another web server" (https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/ https://www.nginx.com/resources/wiki/start/topics/examples/l...). I don't fancy giving users access to /etc/nginx and the power to reload the config just to add aliases on their own subdomains. Much better if they can add password protection to a directory by themselves. It also breaks that each site can live in its own project directory: without htaccess, if I copy over a project I would also have to modify my global nginx config to set per-directory (or at least per vhost) aliases, error pages, etc. Right now, I can say that deploying a project is "download the directory into the desired location and configure your database credentials and a pepper in the config.php". No global configuration changes are ever needed, the global config only does global stuff: tls ciphers, fallback error pages, compression, log files, and more such things. And that's ignoring the fact that, even if there was some objectively better web server, I'd have the task of rewriting a decade of htaccess files into their fancy new format while Apache2 is still alive and properly supported.

rsync 5y ago

I used to run apache for general purpose web service / perl CGI and Zeus to serve static images. I thought I was so cool ...

0des 5y ago
oh come come now, you're still kinda cool.

oars 5y ago

We use Apache Kafka at our company. It's one of the most popular streaming platforms in the world at the moment. https://kafka.apache.org/ https://kafka.apache.org/

Symbiote 5y ago

I use it. We probably have 50+ websites hosted on Apache HTTPD. It's very stable, supports that one special thing many sites need (special headers, stripping file extensions, caching etc) and has excellent documentation. It's not fashionable, but it will still be unfashionable in another 10 years, and we won't have needed to update the configurations in that time.