3 ms·

I see that systemd is still junk. I love Alpine Linux. If we (ZeroTier) had our infrastructure to do over we'd use it instead of CentOS for servers. It dumps s

by api 8y ago

I see that systemd is still junk. I love Alpine Linux. If we (ZeroTier) had our infrastructure to do over we'd use it instead of CentOS for servers. It dumps systemd and countless other pieces of over-engineered cruft that you don't need. It's a thing of beauty. If you appreciate clean, well designed, fast, and parsimonious systems check it out. FreeBSD is also worth checking out for the same reason. It lacks a bit on the hardware front but it's clean and fast and does not have systemd cancer. Over-engineering is the plague of all modern software.

tannhaeuser 8y ago
Completely agree, but what about Alpine using musl rather than GNU libc? AFAIK this has caused trouble in the past (such as https://github.com/gliderlabs/docker-alpine/issues/11 https://github.com/gliderlabs/docker-alpine/issues/11), and will eventually in the future again since third-party packages don't test against non-GLIBC Linux or do they? I'm wondering if it's prime time for Devuan.
- djsumdog 8y ago
  So long as Docker works on Alpine and Docker+musl bugs/issues are addresses and fixed, Alpine could be a great base for running a container infrastructure. Within the containers you could use regular Ubuntu/glibc based images.
  - tannhaeuser 8y ago
    I'd be careful with such assumptions. Docker forwards implementation details of the host system/userspace and isn't a VM after all. A Docker image is not forward-compatible with future Docker or host versions. Which implies the question whether people use Docker for the wrong reasons if their intention is to obtain future-proof reproducible builds etc., rather than merely increase image-per-machine density
    - danudey 8y ago
      Docker provides a lot more future-proof reproducibility than other deployment strategies, though. It's not 100% guaranteed, but whether a given docker image is forwards-compatible doesn't matter as long as the reproducibility of creating the Docker image doesn't change substantially. In other words, as long as I can get (or make) an ubuntu:xenial docker image and apply the same (or similar) transformations to it to make the end result, it doesn't matter nearly as much whether specifically this Docker instance works across all versions of Docker forever.
djsumdog 8y ago
Hating on systemd to hate on it is never going to give you a positive outlook. I personally really like the packaging simplicity and the concept of target files. But I have had lots of issues with the implementation and this article shows a pretty good example of just how complex it can get. I wish there were drop in replacements that just reused the target/service files, but almost all of those have been abandoned. systemd does solve legit full process management problems, but I think as we move to more docker based deployment strategies, its usefulness in that regard will start to decline.
- api 8y ago
  I don't hate on it to hate it. I hate on it because it's orders of magnitude more complex than it needs to be, has a history of being broken, and somehow managed to end up harder to use and more obtuse than the ancient wad of shell scripts it replaced. Its like its designers set out to make it as un-intuitive and hard to use as possible. I say this as a 20+ year Linux veteran.

by api 8y ago

tannhaeuser 8y ago

Completely agree, but what about Alpine using musl rather than GNU libc? AFAIK this has caused trouble in the past (such as https://github.com/gliderlabs/docker-alpine/issues/11 https://github.com/gliderlabs/docker-alpine/issues/11), and will eventually in the future again since third-party packages don't test against non-GLIBC Linux or do they? I'm wondering if it's prime time for Devuan.

djsumdog 8y ago
So long as Docker works on Alpine and Docker+musl bugs/issues are addresses and fixed, Alpine could be a great base for running a container infrastructure. Within the containers you could use regular Ubuntu/glibc based images.
- tannhaeuser 8y ago
  I'd be careful with such assumptions. Docker forwards implementation details of the host system/userspace and isn't a VM after all. A Docker image is not forward-compatible with future Docker or host versions. Which implies the question whether people use Docker for the wrong reasons if their intention is to obtain future-proof reproducible builds etc., rather than merely increase image-per-machine density
  - danudey 8y ago
    Docker provides a lot more future-proof reproducibility than other deployment strategies, though. It's not 100% guaranteed, but whether a given docker image is forwards-compatible doesn't matter as long as the reproducibility of creating the Docker image doesn't change substantially. In other words, as long as I can get (or make) an ubuntu:xenial docker image and apply the same (or similar) transformations to it to make the end result, it doesn't matter nearly as much whether specifically this Docker instance works across all versions of Docker forever.

djsumdog 8y ago

Hating on systemd to hate on it is never going to give you a positive outlook. I personally really like the packaging simplicity and the concept of target files. But I have had lots of issues with the implementation and this article shows a pretty good example of just how complex it can get. I wish there were drop in replacements that just reused the target/service files, but almost all of those have been abandoned. systemd does solve legit full process management problems, but I think as we move to more docker based deployment strategies, its usefulness in that regard will start to decline.

api 8y ago
I don't hate on it to hate it. I hate on it because it's orders of magnitude more complex than it needs to be, has a history of being broken, and somehow managed to end up harder to use and more obtuse than the ancient wad of shell scripts it replaced. Its like its designers set out to make it as un-intuitive and hard to use as possible. I say this as a 20+ year Linux veteran.