docker-debian-artifacts VS Nginx

What's different between debian:bullseye-slim and debian:bullsye (assuming you are talking about https://hub.docker.com/_/debian)

let me try to answer/research this question myself to find the answer/go on this journey:

takes me to

non slim: https://github.com/debuerreotype/docker-debian-artifacts/tre...

slim: https://github.com/debuerreotype/docker-debian-artifacts/tre...

https://github.com/debuerreotype/docker-debian-artifacts/blo... versus https://github.com/debuerreotype/docker-debian-artifacts/blo...

two files are identical

so at a quick glance i have no clue what is going into rootfs.tar.xz that makes one slim and one not

go to google:

https://stackoverflow.com/questions/59794891/how-does-debian...

"just using an elixir docker image": [elixir](https://github.com/erlef/docker-elixir/blob/b108e93389b820554ad9f1e8e07001ed8186d230/1.14/Dockerfile) FROM [erlang:25](https://github.com/erlang/docker-erlang-otp/blob/3e60071a7f14aefe202b602aec0893678d0a0069/25/Dockerfile) FROM [buildpack-deps:bullseye](https://github.com/docker-library/buildpack-deps/blob/65d69325ad741cea6dee20781c1faaab2e003d87/debian/bullseye/Dockerfile) FROM [buildpack-deps:bullseye-curl](https://github.com/docker-library/buildpack-deps/blob/98a5ab81d47a106c458cdf90733df0ee8beea06c/debian/bullseye/curl/Dockerfile) FROM [debian:bullseye](https://github.com/debuerreotype/docker-debian-artifacts/blob/fe5738569aad49a97cf73183a8a6b2732fe57840/bullseye/Dockerfile). wtf is even running on that thing?

FROM scratch ADD rootfs.tar.xz / CMD ["bash"] https://github.com/debuerreotype/docker-debian-artifacts/blob/686d9f6eaada08a754bc7abf6f6184c65c5b378f/bullseye/slim/Dockerfile

Is it the 64 vs 32 bit time calls possibly? Like this: https://github.com/debuerreotype/docker-debian-artifacts/issues/106 What happens if you run the date command from inside the container?

Yeah, unless I'm looking at it wrong, there doesn't seem to be any meaningful difference between 1.25.5 and 1.26.0:

https://github.com/nginx/nginx/compare/release-1.25.5...rele...

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

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

Have a look at:

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

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

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

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

According to this article, nGinx is being used to serve 34% of all websites in the world. I checked out who's contributing to nGinx, and just like I thought, the project has 8,208 commits, and 5,366 of those commits was made by 2 software developers; igorsoev and mdounin.

Nginx + Roadrunner (fcgi mode)

Apache’s mod_fastcgi’s last commit was 2 weeks ago:

https://svn.apache.org/viewvc/httpd/httpd/trunk/

It’s a fork of what you linked (and was more popular afaik back when fastcgi was state of the art, and apache was the undisputed champion of web servers).

These days, nginx has more market share than apache, and its fastcgi module is one of the more recently updated ones in its source tree (5 months vs multiple years):

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

If I was going to build an embedded web server, I’d start with nostd rust, probably with though axum + tokio, since thats already memory safe-ish.

If I needed fastcgi for some reason (dynamically loadable endpoints, or os-level isolation), there are at least four implementations of fastcgi for it. No idea if any are decent though.

APISIX is an API Gateway. It builds upon OpenResty, a Lua layer built on top of the famous nginx reverse-proxy. APISIX adds abstractions to the mix, e.g., Route, Service, Upstream, and offers a plugin-based architecture.