9 ms·

This is clearly a trend, though it remains to see if it will garner enough acceptance to actually be "the future". systemd supports launching container-based s

This is clearly a trend, though it remains to see if it will garner enough acceptance to actually be "the future". systemd supports launching container-based services via nspawn and already namespaces "legacy" services very heavily. In fact, systemd et al were among the heaviest early drivers of cgroup technology for cleaner starting and stopping of groups of processes.

pikzen 9y ago
Unfortunately, systemd/nspawn does not benefit from the hype Docker garners, despite being infinitely better. This industry is becoming more and more hype and cargo-cult driven, instead of making sane technological choices
- wmf 9y ago
  Being easier to try, having clear documentation/marketing, and having a bigger community are also forms of "better". If something is so infinitely technically better then winning is "just" a matter of creating on-ramps to ease its adoption.
  - otterley 9y ago
    systemd's documentation is second to none: https://www.freedesktop.org/wiki/Software/systemd/ https://www.freedesktop.org/wiki/Software/systemd/
    - JdeBP 9y ago
      Only if one sets the bar quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the descriptions that come to mind are "acceptable" and "mediocre". As people have pointed out passim over the years, the expected as the norm quality of doco for the worlds of the BSDs and the commercial Unices is noticeably a higher standard than in the Linux world. By those standards, "second to none" is most definitely an exaggeration. Sadly, "treated as an afterthought" is all too often still applicable, as well; this also being a disease of Linux doco that it hasn't wholly shaken off. The culture of updating the doco in lockstep when the software changes hasn't really taken a firm root, alas. Just one example of such doco problems is a systemd issue where the doco does not tell the the issue raiser that the entire basis for the issue is wrong. Users have to resort to finding commentary hidden in the source code. Raised as a documentation issue, it requests a documentation change to warn users of something that is not in fact the case at all. Ironically, the true doco issue is actually that it is deficient, and the correct doco change would be to move the commentary into the manual where users can easily see it. * https://github.com/systemd/systemd/issues/5735 https://github.com/systemd/systemd/issues/5735 * https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html https://www.freedesktop.org/software/systemd/man/systemd-tim... * https://github.com/systemd/systemd/blob/5f36e3d30375cf04292bbc1bf3f4d7512cf80139/src/timesync/timesyncd-manager.c#L321 https://github.com/systemd/systemd/blob/5f36e3d30375cf04292b... * http://jdebp.eu./FGA/systemd-documentation-errata.html http://jdebp.eu./FGA/systemd-documentation-errata.html
      - otterley 9y ago
        Can you give an example of a better-documented open-source project that is less than 5 years old and has the same level of complexity of the systemd family?
- thiht 9y ago
  >despite being infinitely better How and why? You're being condescending. I like Docker and if anything you make me not want to try systemd-nspawn with this attitude.
  - throwaway2048 9y ago
    Great job proving the second part of what he said
    - yebyen 9y ago
      Put up a sentence or two of informative discussion, or links or any kind, this is not any kind of way to advance the state of a thread. "Go on, try it" doesn't help me in any way. I believe that Docker has more attention, you might call it hype. I'd say "eyes" instead. We have here a way to shown to run everything in Docker, parent link of thread (RancherOS.) That's great, I already went ahead and tried it. I'm still waiting to be convinced that I should try nspawn instead. Without your help, I won't even know what OS Distro I can download to try it, let alone why it's better.
      - digi_owl 9y ago
        Docker also is less invasive. You do not need to build the distro around docker to use docker...
        jvoorhis 9y ago
        This hasn't always been so, as historically a kernel patched to support aufs was a requirement. It's easier to install docker in 2017 as much of the plumbing shared by the container ecosystem (including nspawn) has become ubiquitous.
      - JdeBP 9y ago
        You do not know an operating system that has systemd? Given https://news.ycombinator.com/item?id=13715574 https://news.ycombinator.com/item?id=13715574 that seems very improbable.
- notamy 9y ago
  > despite being infinitely better Genuinely curious, how is it "infinitely better"? I'm considering potentially switching away from Docker on my production boxes to something else, but I've mainly only heard about rkt when researching.
- hehheh 9y ago
  I feel exactly the same way about systemd as you seem to feel about docker.
frik 9y ago
I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Similar on Windows, using just sandboxie is so simple. Or do it like Android, execute every app/process with a different user.) https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups
- joshwget 9y ago
  Managing cgroups directly would be redoing a lot of work already done by libcontainer/runc (which we leverage through Docker now, probably containerd in the future). Using these projects in RancherOS allows us to focus on other things and not reinvent the wheel.
- wmf 9y ago
  systemd already puts each service in a separate cgroup AFAIK, so commands like cgexec aren't even needed. I suspect people are more interested in namespace separation, but recent versions of systemd can also do that [1]. I don't think systemd has image management so that's still a reason to use Docker. [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe...
  - gtrevorjay 9y ago
    In the case of system services, it is probably acceptable (perhaps even ideal) to leave the image management up to deb, RPM, or ostree. systemd shouldn't do everything :) .
  - technofiend 9y ago
    Systemd creates three "slices": system, user and machine. Daemons started by systemd go in system, user processes in user and virtual machines go in machine. Each process is placed in a hierarchy so you end up with system-httpd which makes it easy to assign or limit resources based on the slice. Redhat covers it extensively in their performance and tuning class.
Esau 9y ago
> This is clearly a trend More like a virus.
digi_owl 9y ago
It very much is a trend, a trend of by developers, for developers. All this is so that some primadonna developer somewhere can use the latest languages and frameworks to build his "app" without some sysadmin or other uses of available computing resources gets in his way. It's about kicking the question of static vs dynamic can up the stack, as now you have something that is a hodgepodge of dynamic bindings that seems to behave like something static as long as you do not look behind the curtains. Oh, and don't mind the turtles...

pikzen 9y ago

Unfortunately, systemd/nspawn does not benefit from the hype Docker garners, despite being infinitely better. This industry is becoming more and more hype and cargo-cult driven, instead of making sane technological choices

wmf 9y ago
Being easier to try, having clear documentation/marketing, and having a bigger community are also forms of "better". If something is so infinitely technically better then winning is "just" a matter of creating on-ramps to ease its adoption.
- otterley 9y ago
  systemd's documentation is second to none: https://www.freedesktop.org/wiki/Software/systemd/ https://www.freedesktop.org/wiki/Software/systemd/
  - JdeBP 9y ago
    Only if one sets the bar quite low, and has very lax standards for doco. Unfortunately, people often do set the bar low in the Linux world. But to those from other worlds the descriptions that come to mind are "acceptable" and "mediocre". As people have pointed out passim over the years, the expected as the norm quality of doco for the worlds of the BSDs and the commercial Unices is noticeably a higher standard than in the Linux world. By those standards, "second to none" is most definitely an exaggeration. Sadly, "treated as an afterthought" is all too often still applicable, as well; this also being a disease of Linux doco that it hasn't wholly shaken off. The culture of updating the doco in lockstep when the software changes hasn't really taken a firm root, alas. Just one example of such doco problems is a systemd issue where the doco does not tell the the issue raiser that the entire basis for the issue is wrong. Users have to resort to finding commentary hidden in the source code. Raised as a documentation issue, it requests a documentation change to warn users of something that is not in fact the case at all. Ironically, the true doco issue is actually that it is deficient, and the correct doco change would be to move the commentary into the manual where users can easily see it. * https://github.com/systemd/systemd/issues/5735 https://github.com/systemd/systemd/issues/5735 * https://www.freedesktop.org/software/systemd/man/systemd-timesyncd.service.html https://www.freedesktop.org/software/systemd/man/systemd-tim... * https://github.com/systemd/systemd/blob/5f36e3d30375cf04292bbc1bf3f4d7512cf80139/src/timesync/timesyncd-manager.c#L321 https://github.com/systemd/systemd/blob/5f36e3d30375cf04292b... * http://jdebp.eu./FGA/systemd-documentation-errata.html http://jdebp.eu./FGA/systemd-documentation-errata.html
    - otterley 9y ago
      Can you give an example of a better-documented open-source project that is less than 5 years old and has the same level of complexity of the systemd family?
thiht 9y ago
>despite being infinitely better How and why? You're being condescending. I like Docker and if anything you make me not want to try systemd-nspawn with this attitude.
- throwaway2048 9y ago
  Great job proving the second part of what he said
  - yebyen 9y ago
    Put up a sentence or two of informative discussion, or links or any kind, this is not any kind of way to advance the state of a thread. "Go on, try it" doesn't help me in any way. I believe that Docker has more attention, you might call it hype. I'd say "eyes" instead. We have here a way to shown to run everything in Docker, parent link of thread (RancherOS.) That's great, I already went ahead and tried it. I'm still waiting to be convinced that I should try nspawn instead. Without your help, I won't even know what OS Distro I can download to try it, let alone why it's better.
    - digi_owl 9y ago
      Docker also is less invasive. You do not need to build the distro around docker to use docker...
      - jvoorhis 9y ago
        This hasn't always been so, as historically a kernel patched to support aufs was a requirement. It's easier to install docker in 2017 as much of the plumbing shared by the container ecosystem (including nspawn) has become ubiquitous.
    - JdeBP 9y ago
      You do not know an operating system that has systemd? Given https://news.ycombinator.com/item?id=13715574 https://news.ycombinator.com/item?id=13715574 that seems very improbable.
notamy 9y ago
> despite being infinitely better Genuinely curious, how is it "infinitely better"? I'm considering potentially switching away from Docker on my production boxes to something else, but I've mainly only heard about rkt when researching.
hehheh 9y ago
I feel exactly the same way about systemd as you seem to feel about docker.

frik 9y ago

I am starting to wonder, why not just execute processes directly with cgroups commands? $ cgcreate -g memory,cpu:groupname/foo $ cgexec -g memory,cpu:groupname/foo bash https://wiki.archlinux.org/index.php/cgroups https://wiki.archlinux.org/index.php/cgroups It's the bare basic that libvirt and Docker et al are based anyway. So if you want to run just one process per "container" it seems rather logical to keep it simple and use cgroups commands directly. (Similar on Windows, using just sandboxie is so simple. Or do it like Android, execute every app/process with a different user.) https://en.wikipedia.org/wiki/Cgroups https://en.wikipedia.org/wiki/Cgroups

joshwget 9y ago
Managing cgroups directly would be redoing a lot of work already done by libcontainer/runc (which we leverage through Docker now, probably containerd in the future). Using these projects in RancherOS allows us to focus on other things and not reinvent the wheel.
wmf 9y ago
systemd already puts each service in a separate cgroup AFAIK, so commands like cgexec aren't even needed. I suspect people are more interested in namespace separation, but recent versions of systemd can also do that [1]. I don't think systemd has image management so that's still a reason to use Docker. [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html https://www.freedesktop.org/software/systemd/man/systemd.exe...
- gtrevorjay 9y ago
  In the case of system services, it is probably acceptable (perhaps even ideal) to leave the image management up to deb, RPM, or ostree. systemd shouldn't do everything :) .
- technofiend 9y ago
  Systemd creates three "slices": system, user and machine. Daemons started by systemd go in system, user processes in user and virtual machines go in machine. Each process is placed in a hierarchy so you end up with system-httpd which makes it easy to assign or limit resources based on the slice. Redhat covers it extensively in their performance and tuning class.

Esau 9y ago

> This is clearly a trend More like a virus.

digi_owl 9y ago

It very much is a trend, a trend of by developers, for developers. All this is so that some primadonna developer somewhere can use the latest languages and frameworks to build his "app" without some sysadmin or other uses of available computing resources gets in his way. It's about kicking the question of static vs dynamic can up the stack, as now you have something that is a hodgepodge of dynamic bindings that seems to behave like something static as long as you do not look behind the curtains. Oh, and don't mind the turtles...