4 ms·

This is quite impressive, but this claim is a bit wrong: > All in one small self-contained executable. Size of algernon executable: 24.4 MiB Size of nginx-fu

by est31 8y ago

This is quite impressive, but this claim is a bit wrong: > All in one small self-contained executable. Size of algernon executable: 24.4 MiB Size of nginx-full executable: 1.1 MiB Size of apache2 executable: 648K

mholt 8y ago
If that's the main criticism you have of the project, I'd say that's pretty good. In fact, the readme of this project is really thorough!
- est31 8y ago
  Well yeah it's definitely an interesting approach. I guess it's much more lean than running a whole Ubuntu container VM that has all of these things installed, or running a gigantic bloated Javascript toolchain just to convert the scss or md files to css or html.
- interfixus 8y ago
  Very civilized comment from mr. Caddy himself. Heartening, not least considering the kind of vendettas some projects - Caddy among them - have to put up with from competing developers.
lawl 8y ago
A big part is almost certainly the difference between dynamic and static linking. Can you run ldd on all of these and then report the combined size for each binary+libraries?
- est31 8y ago
  I don't have nginx installed (got the number from a web download of the .deb package), but running this for apache: $ echo $((`ldd /usr/sbin/apache2 | cut -d">" -f 2 | sed "s/(.*$//;s/ //" | xargs du -L | cut -f 1 | sed "s/$/+/" | xargs echo` 0)) 3200 So 3.2 MB of shared library dependencies. 1.8 MB just being the libc which is almost guaranteed to be used by a different program already.
  - koffiezet 8y ago
    > 1.8 MB just being the libc which is almost guaranteed to be used by a different program already Not if we're talking about containers :)
- marcus_holmes 8y ago
  As someone else commented, the huge size of Go executables is down to a design decision to include a map of functions for panic reporting. There was a whole discussion on this recently on HN. I don't know why the grandparent was downvoted. Go binaries are not small and the claim that this is a "small" single executable is untrue. Hopefully the Go team will give us a flag to decide for ourselves whether to optimise for executable size or initialisation time. I know I'm fed up of uploading 50Mb files over dodgy wifi+vpn connections to update my server. (edit fix repetition of design)
  - throwaway5d097 8y ago
    That's one thing that might motivate me to set up CI/CD on a server.
  - baldomo 8y ago
    You can actually pass LDFLAGS to any go tool (e.g. go build[1]). The flags are specified in the linker documentation[2] [1] https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies https://golang.org/cmd/go/#hdr-Compile_packages_and_dependen... [2] https://golang.org/cmd/link/ https://golang.org/cmd/link/
    - marcus_holmes 8y ago
      which is useful, except as far as I'm aware it doesn't cover this case. The original is at: https://science.raphael.poss.name/go-executable-size-visualization-with-d3.html#overview https://science.raphael.poss.name/go-executable-size-visuali...
justinsaccount 8y ago
apache2 is mostly modules that are loaded at runtime.
- takeda 8y ago
  On my FreeBSD machine, all files in the entire apache package (including modules, manpages, headers, default pages, graphic for displaying directories in gif and png formats, tools are) take 4.3MB
sagichmal 8y ago
For self-contained architecture-specific server binaries, there is no practical difference between 240KB, or 2.4MB, or 24.4MB, or even, at a stretch, 244MB. It's not worth mentioning or optimizing for, except as novelty. I wish people would stop golfing with these numbers.
- takeda 8y ago
  You have it backwards, apache or nginx size is not for the novelty. Go is just a pig and its size grows every new release, and the size isn't really for being statically linked or debugging symbols, because it's huge even when those options are disabled. Right now a "hello world" application in Go has comparable size to an OS with full GUI.
  - sagichmal 8y ago
    Who cares? Literally, what problem does it cause, or what does it make worse? It is totally immaterial.
    - takeda 8y ago
      - increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it) - it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly) - it increases amount of data transferred on every deployment - increases amount of memory used (the whole point of containers, was to efficiently use hardware (BORG), although a lot of people today miss that reason and run containers on VMs)
      - Go0the0gophers 8y ago
        Lol, I let you use java spring boot technology. It is really bloat (ram, cpu, disk, infamous slowly startup and jit optimization, complex tuning eg. thread pool and so on). Good luck.
      - yetanotherme 8y ago
Propolice 8y ago
Algernon does a bit more than plain Nginx or Apache. 24.4 MiB also includes bloat. See: https://github.com/golang/go/issues/27266 https://github.com/golang/go/issues/27266 https://github.com/golang/go/issues/2559 https://github.com/golang/go/issues/2559 Hopefully we can get smaller binaries by Go 1.13.
- takeda 8y ago
  My Apache installation with modules takes 4.3MB, and I'm quite sure Apache with modules can do more than Algernon.
xyproto 8y ago
Algernon would be a lot smaller if it was not statically compiled and compiled with gccgo instead. Sadly, the Go package that provides support for QUIC does not compile with gccgo, yet.
chvid 8y ago
I don't think it is fair that you are being downvoted. Size does matter and not just in sense that it is using resources. The largest part of the 24 MB probably never gets executed but it adds unnecessary complexity that may hide bugs and security flaws.
xyproto 8y ago
The docker image is 9MB. https://hub.docker.com/r/xyproto/algernon/tags https://hub.docker.com/r/xyproto/algernon/tags

by est31 8y ago

mholt 8y ago

If that's the main criticism you have of the project, I'd say that's pretty good. In fact, the readme of this project is really thorough!

est31 8y ago
Well yeah it's definitely an interesting approach. I guess it's much more lean than running a whole Ubuntu container VM that has all of these things installed, or running a gigantic bloated Javascript toolchain just to convert the scss or md files to css or html.
interfixus 8y ago
Very civilized comment from mr. Caddy himself. Heartening, not least considering the kind of vendettas some projects - Caddy among them - have to put up with from competing developers.

lawl 8y ago

A big part is almost certainly the difference between dynamic and static linking. Can you run ldd on all of these and then report the combined size for each binary+libraries?

est31 8y ago
I don't have nginx installed (got the number from a web download of the .deb package), but running this for apache: $ echo $((`ldd /usr/sbin/apache2 | cut -d">" -f 2 | sed "s/(.*$//;s/ //" | xargs du -L | cut -f 1 | sed "s/$/+/" | xargs echo` 0)) 3200 So 3.2 MB of shared library dependencies. 1.8 MB just being the libc which is almost guaranteed to be used by a different program already.
- koffiezet 8y ago
  > 1.8 MB just being the libc which is almost guaranteed to be used by a different program already Not if we're talking about containers :)
marcus_holmes 8y ago
As someone else commented, the huge size of Go executables is down to a design decision to include a map of functions for panic reporting. There was a whole discussion on this recently on HN. I don't know why the grandparent was downvoted. Go binaries are not small and the claim that this is a "small" single executable is untrue. Hopefully the Go team will give us a flag to decide for ourselves whether to optimise for executable size or initialisation time. I know I'm fed up of uploading 50Mb files over dodgy wifi+vpn connections to update my server. (edit fix repetition of design)
- throwaway5d097 8y ago
  That's one thing that might motivate me to set up CI/CD on a server.
- baldomo 8y ago
  You can actually pass LDFLAGS to any go tool (e.g. go build[1]). The flags are specified in the linker documentation[2] [1] https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies https://golang.org/cmd/go/#hdr-Compile_packages_and_dependen... [2] https://golang.org/cmd/link/ https://golang.org/cmd/link/
  - marcus_holmes 8y ago
    which is useful, except as far as I'm aware it doesn't cover this case. The original is at: https://science.raphael.poss.name/go-executable-size-visualization-with-d3.html#overview https://science.raphael.poss.name/go-executable-size-visuali...

justinsaccount 8y ago

apache2 is mostly modules that are loaded at runtime.

takeda 8y ago
On my FreeBSD machine, all files in the entire apache package (including modules, manpages, headers, default pages, graphic for displaying directories in gif and png formats, tools are) take 4.3MB

sagichmal 8y ago

For self-contained architecture-specific server binaries, there is no practical difference between 240KB, or 2.4MB, or 24.4MB, or even, at a stretch, 244MB. It's not worth mentioning or optimizing for, except as novelty. I wish people would stop golfing with these numbers.

takeda 8y ago
You have it backwards, apache or nginx size is not for the novelty. Go is just a pig and its size grows every new release, and the size isn't really for being statically linked or debugging symbols, because it's huge even when those options are disabled. Right now a "hello world" application in Go has comparable size to an OS with full GUI.
- sagichmal 8y ago
  Who cares? Literally, what problem does it cause, or what does it make worse? It is totally immaterial.
  - takeda 8y ago
    - increases amount of time to fetch and run container (it actually is quite noticeable when you have app that scales out and you updating it) - it increases amount of storage to store multiple versions of containers (when you have an internal app and do frequent releases it adds quickly) - it increases amount of data transferred on every deployment - increases amount of memory used (the whole point of containers, was to efficiently use hardware (BORG), although a lot of people today miss that reason and run containers on VMs)
    - Go0the0gophers 8y ago
      Lol, I let you use java spring boot technology. It is really bloat (ram, cpu, disk, infamous slowly startup and jit optimization, complex tuning eg. thread pool and so on). Good luck.
    - yetanotherme 8y ago

Propolice 8y ago

Algernon does a bit more than plain Nginx or Apache. 24.4 MiB also includes bloat. See: https://github.com/golang/go/issues/27266 https://github.com/golang/go/issues/27266 https://github.com/golang/go/issues/2559 https://github.com/golang/go/issues/2559 Hopefully we can get smaller binaries by Go 1.13.

takeda 8y ago
My Apache installation with modules takes 4.3MB, and I'm quite sure Apache with modules can do more than Algernon.

xyproto 8y ago

Algernon would be a lot smaller if it was not statically compiled and compiled with gccgo instead. Sadly, the Go package that provides support for QUIC does not compile with gccgo, yet.

chvid 8y ago

I don't think it is fair that you are being downvoted. Size does matter and not just in sense that it is using resources. The largest part of the 24 MB probably never gets executed but it adds unnecessary complexity that may hide bugs and security flaws.

xyproto 8y ago

The docker image is 9MB. https://hub.docker.com/r/xyproto/algernon/tags https://hub.docker.com/r/xyproto/algernon/tags