5 ms·

When the big debate about systemd was going on, I couldn't really care less. In fact, I thought a future where the big distros used the same init system was a r

When the big debate about systemd was going on, I couldn't really care less. In fact, I thought a future where the big distros used the same init system was a rosy one. No need to have to rewrite some init script to yet another system depending on the flavour of my clients. No need for our config management tools to have a gazallion 'if os == foo' statements. Now, I'm just not so sure. The feature creep here is remarkable. Why on earth would systemd have anything to do with container management? Surely the 'docker' (or whatever) service which systemd is supposed to be managing should be doing this? Another nail in the coffin of simple software that does one thing well. Edit: s/docker/container management/

vruiz 12y ago
It's not about docker, it about systemd-nspawn which is systemd's own alternative to docker. I'm with you here, at first I didn't understand the alarm but now I'm starting to see the danger of this trend.
- ris 12y ago
  I don't think systemd is moving into this territory just for fun. I seem to recall it's because now the kernel is moving towards unified cgroups-trees if systemd wants to be able to use cgroups it more or less has to be "in charge" of them at the root, meaning it's going to have to take care of this sort of functionality.
  - jacquesm 12y ago
    Linux should simply adopt jails and get it over with rather than to get stuck in NIH territory.
    - ris 12y ago
      Right. They should "port" a feature that's intricately linked with the internal workings of a kernel over from another completely alien kernel.
      - jacquesm 12y ago
        Nobody said it would be easy.
        ris 12y ago
        You... more or less implied it
    - dezgeg 12y ago
      Cgroups are not a virtualization / containerization feature like jails, their use cases are entirely different.
  - digi_owl 12y ago
    Last i read on LWN the cgroups kernel dev was backing away from the idea of having a singular cgroups management daemon. And no, its not just for fun. RH is betting big on competing with Amazon and MS on cloud services. It would not surprise me if they are trying to get old RHEL server customers to move their servers onto the RH cloud with the switch to RHEL7.
    - sciurus 12y ago
      What Red Hat cloud?
      - digi_owl 12y ago
        http://www.redhat.com/en/technologies/cloud-computing http://www.redhat.com/en/technologies/cloud-computing
        sciurus 12y ago
        That doesn't answer the question. To clarify, what I meant was that Red Hat doesn't run a public IaaS cloud to which people can "move their servers".
- geofft 12y ago
  I'm not super familiar with either, but as I understand it, systemd-nspawn is only an alternative to "docker run". The docker command supports all sorts of other things, like creating container images, manipulating, uploading, etc. systemd-nspawn just runs things, and the upstream docs suggest using debootstrap, yum, etc. to create a thing for nspawn to run. (Running things is both the easy part, and the part that most makes sense for an initsystem / system daemon to do.) systemd-import will grab Docker images from the internet, but I'm not sure it will do very much else. In other words, even if you adopt systemd's way of doing things in deployment, your developers are still using the docker command.
  - justincormack 12y ago
    Well thats kind of why Rocket from CoreOS is writing specs and splitting these things up [1] so you can use different tooling. [1] https://github.com/appc/spec/blob/master/SPEC.md https://github.com/appc/spec/blob/master/SPEC.md
geofft 12y ago
Where was the simple software that does one thing well? Did it ever exist? I'd believe you if Docker was some elegant, tiny, well-written tool, and systemd was a bloated mess of AbstractLinuxContainerFactoryImpls. But as far as I can tell, Docker is the thing that is neither simple nor does its one thing particularly well, and systemd implements this straightforwardly, because of all things you might want to do, booting a system is kind of easier if you're already an initsystem. If systemd decides to implement WebGL or take on Sublime Text, let's talk, but these 200 lines of C don't seem like a reason to believe that we've moved away from simple software that does things well: http://cgit.freedesktop.org/systemd/systemd/commit/src/import/import.c?id=72648326ea6d3e68cdb0b5890df737047d031a41 http://cgit.freedesktop.org/systemd/systemd/commit/src/impor...
- lvh 12y ago
  The entire diff being discussed isn't just about import.c, but a bunch of other things too. For example, to get it to do something interesting, you also want import-dkr.c. Add it all up, and we're talking 2000, not 200, lines of C: http://cgit.freedesktop.org/systemd/systemd/commit/?id=72648326ea6d3e68cdb0b5890df737047d031a41 http://cgit.freedesktop.org/systemd/systemd/commit/?id=72648...
  - geofft 12y ago
    Oops. I got confused by gitweb's interface... thanks. I have some opinions, mostly negative, about new C code, but even so it doesn't seem all that bad by UNIX standards. The bulk of the stuff I missed mostly looks like it's about connecting to the Docker registry and linking to libcurl, and this is about as big as I'd expect for C.
eleitl 12y ago
> When the big debate about systemd was going on, I couldn't really care less. > Now, I'm just not so sure. The feature creep here is remarkable. Now you know why we had that acrimonious debate. This is precisely what was obvious right from the start. Linux is Windows NT now, the only way to have a decent nix is to pick BSD.
linuxydave 12y ago
>When the big debate about systemd was going on, I couldn't really care less. >Now, I'm just not so sure. You're starting to see what the original opponents feared a long time ago. It doesn't look like the feature creep is going to end any time soon, although I wonder if there will be a breaking point when even the fanboys say, "Hang on, this is a bit much..."
- jacquesm 12y ago
  By the time the frog realizes the water is boiling it is a bit late.
up-n-atom 12y ago
It is singular software by implying a plural tense. It may be miss branded as a single monolithic unit but it exist to an extent as separate entities, and yes, some have a hard dependency between each other. It is no different to that of iproute2 which has succeeded net-tools; what were your thoughts on that?

vruiz 12y ago

It's not about docker, it about systemd-nspawn which is systemd's own alternative to docker. I'm with you here, at first I didn't understand the alarm but now I'm starting to see the danger of this trend.

ris 12y ago
I don't think systemd is moving into this territory just for fun. I seem to recall it's because now the kernel is moving towards unified cgroups-trees if systemd wants to be able to use cgroups it more or less has to be "in charge" of them at the root, meaning it's going to have to take care of this sort of functionality.
- jacquesm 12y ago
  Linux should simply adopt jails and get it over with rather than to get stuck in NIH territory.
  - ris 12y ago
    Right. They should "port" a feature that's intricately linked with the internal workings of a kernel over from another completely alien kernel.
    - jacquesm 12y ago
      Nobody said it would be easy.
      - ris 12y ago
        You... more or less implied it
  - dezgeg 12y ago
    Cgroups are not a virtualization / containerization feature like jails, their use cases are entirely different.
- digi_owl 12y ago
  Last i read on LWN the cgroups kernel dev was backing away from the idea of having a singular cgroups management daemon. And no, its not just for fun. RH is betting big on competing with Amazon and MS on cloud services. It would not surprise me if they are trying to get old RHEL server customers to move their servers onto the RH cloud with the switch to RHEL7.
  - sciurus 12y ago
    What Red Hat cloud?
    - digi_owl 12y ago
      http://www.redhat.com/en/technologies/cloud-computing http://www.redhat.com/en/technologies/cloud-computing
      - sciurus 12y ago
        That doesn't answer the question. To clarify, what I meant was that Red Hat doesn't run a public IaaS cloud to which people can "move their servers".
geofft 12y ago
I'm not super familiar with either, but as I understand it, systemd-nspawn is only an alternative to "docker run". The docker command supports all sorts of other things, like creating container images, manipulating, uploading, etc. systemd-nspawn just runs things, and the upstream docs suggest using debootstrap, yum, etc. to create a thing for nspawn to run. (Running things is both the easy part, and the part that most makes sense for an initsystem / system daemon to do.) systemd-import will grab Docker images from the internet, but I'm not sure it will do very much else. In other words, even if you adopt systemd's way of doing things in deployment, your developers are still using the docker command.
- justincormack 12y ago
  Well thats kind of why Rocket from CoreOS is writing specs and splitting these things up [1] so you can use different tooling. [1] https://github.com/appc/spec/blob/master/SPEC.md https://github.com/appc/spec/blob/master/SPEC.md

geofft 12y ago

Where was the simple software that does one thing well? Did it ever exist? I'd believe you if Docker was some elegant, tiny, well-written tool, and systemd was a bloated mess of AbstractLinuxContainerFactoryImpls. But as far as I can tell, Docker is the thing that is neither simple nor does its one thing particularly well, and systemd implements this straightforwardly, because of all things you might want to do, booting a system is kind of easier if you're already an initsystem. If systemd decides to implement WebGL or take on Sublime Text, let's talk, but these 200 lines of C don't seem like a reason to believe that we've moved away from simple software that does things well: http://cgit.freedesktop.org/systemd/systemd/commit/src/import/import.c?id=72648326ea6d3e68cdb0b5890df737047d031a41 http://cgit.freedesktop.org/systemd/systemd/commit/src/impor...

lvh 12y ago
The entire diff being discussed isn't just about import.c, but a bunch of other things too. For example, to get it to do something interesting, you also want import-dkr.c. Add it all up, and we're talking 2000, not 200, lines of C: http://cgit.freedesktop.org/systemd/systemd/commit/?id=72648326ea6d3e68cdb0b5890df737047d031a41 http://cgit.freedesktop.org/systemd/systemd/commit/?id=72648...
- geofft 12y ago
  Oops. I got confused by gitweb's interface... thanks. I have some opinions, mostly negative, about new C code, but even so it doesn't seem all that bad by UNIX standards. The bulk of the stuff I missed mostly looks like it's about connecting to the Docker registry and linking to libcurl, and this is about as big as I'd expect for C.

eleitl 12y ago

> When the big debate about systemd was going on, I couldn't really care less. > Now, I'm just not so sure. The feature creep here is remarkable. Now you know why we had that acrimonious debate. This is precisely what was obvious right from the start. Linux is Windows NT now, the only way to have a decent nix is to pick BSD.

linuxydave 12y ago

>When the big debate about systemd was going on, I couldn't really care less. >Now, I'm just not so sure. You're starting to see what the original opponents feared a long time ago. It doesn't look like the feature creep is going to end any time soon, although I wonder if there will be a breaking point when even the fanboys say, "Hang on, this is a bit much..."

jacquesm 12y ago
By the time the frog realizes the water is boiling it is a bit late.

up-n-atom 12y ago

It is singular software by implying a plural tense. It may be miss branded as a single monolithic unit but it exist to an extent as separate entities, and yes, some have a hard dependency between each other. It is no different to that of iproute2 which has succeeded net-tools; what were your thoughts on that?