Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd vs. Docker

lwn.net

Post reply on HN
Print view View original

61–70 of 97 posts

Re: Systemd vs. Docker

#61

Post by JdeBP »

xaduha wrote: post #8
jimktrains2 wrote: post #5

Earlier quoted context omitted.

Or they can move to one of the BSDs and use jails which are much more stable, secure, and tested than linux containers.

Technology isn't that important here, it's what stems from it is. Adoption, infrastructure, tools, community. There's also a price for doing it differently. And believe you me, using BSD nowadays is the definition of doing things differently. What for? What I'm getting for losing my time and reinventing the tools that are already available and much more polished? Dockerfiles can be replicated. Docker Hub can be repli…

> And believe you me, using BSD nowadays is the definition of doing things differently.

... although people like Florian Haas argue that the way that one does things on the BSDs is actually the way that makes sense to do things with Docker, as well, and the way that you think to be "different" is actually the sensible way overall.

* https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN

* https://www.hastexo.com/blogs/florian/2016/02/21/containers-...

Re: Systemd vs. Docker

#62

Post by laumars »

xaduha wrote: post #59
laumars wrote: post #55

Earlier quoted context omitted.

> You're missing the point. Even if jails is the most elegant, easy and powerful technology in the world it's still on BSD. People are not going to switch to BSD just because of jails. We're not just talking about jails though. The OP was discussing systemd + containers. Switching to FreeBSD to escape systemd isn't that weird of an idea since most of the same Linux software will also run on FreeBSD. In fact I'm serio…

> Why not? This isn't a sports team where you're expected to only support one product. Linux/Docker and BSD/jails aren't even in the same league.

> Linux/Docker and BSD/jails aren't even in the same league.

Since you don't have any basis for comparison, I'm going to have to assume that you're now just trolling me. So I'll end our correspondence here.

Re: Systemd vs. Docker

#63

Post by xaduha »

laumars wrote: post #60
xaduha wrote: post #58

Earlier quoted context omitted.

What you're talking about is a luxury I can't afford. That's what I mean when I talk about the price. There are plenty of far more important technologies that I would rather learn. I can't afford to learn two technologies that do about the same thing, of which one is significantly less popular, might now have tools that other has and runs on a significantly less popular OS.

That's actually a fair point and one I completely sympathise with. But your original argument very much sounded like you were suggesting that people in general shouldn't bother with FreeBSD, jails, nor any other technologies which weren't dominant in their respective field. Which is why we disagreed.

You misinterpreted it.

Re: Systemd vs. Docker

#64

Post by Etzos »

qwertyuiop924 wrote: post #56
bryanlarsen wrote: post #36

Earlier quoted context omitted.

Your criticism of systemd still applies to docker. "Supervision, logging, communication, IO, configuration, state management — everything goes through docker" If I use systemd I have to type 'systemd logs' to get at my logs, or I can use a plugin to move it somewhere else. If I use docker I have to type 'docker logs', or I can use a plugin to move it somewhere else. etc. etc. P.S. Agree completely with your praise of…

Wrong. Docker manages containers, and only containers. 'docker logs' shows you the logs from your containers. Docker never tried to make me run my non-container logs through 'docker logs'. You know what else docker never tried to be? cron. Or udev. Or consolekit. Or init. It just tries to manage your containers.

I think this is a little bit off. You're looking at them from two different perspectives.

Docker wants to manage your containers. And in that regard it is one monolithic daemon that manages everything about your containers.

Systemd wants to manage your computer and things related to init. It is a bunch of modular, but strongly integrated, pieces that manage everything about your init and process management.

Re: Systemd vs. Docker

#65

Post by bryanlarsen »

qwertyuiop924 wrote: post #51
bryanlarsen wrote: post #6

Earlier quoted context omitted.

Why the systemd hate? Because it's a big monolithic project that takes over your system? You do realize that Docker is much more monolithic and opinionated than systemd, right?

Yes, but I will never have to use docker if I don't want to. For that matter, docker doesn't try to be cron, it doesn't want to handle mounting, didn't subsume udev, and doesn't encourage other project to link against it, and to drop all compatibility with non-linux systems. Systemd does, did, and is doing that right now.

"but I will never have to use docker if I don't want to."

I predict that fairly soon install instructions for a lot of different types of software will be "docker run ..."

For example, try running discourse without using docker.

Re: Systemd vs. Docker

#66

Post by xaduha »

JdeBP wrote: post #61
xaduha wrote: post #8

Earlier quoted context omitted.

Technology isn't that important here, it's what stems from it is. Adoption, infrastructure, tools, community. There's also a price for doing it differently. And believe you me, using BSD nowadays is the definition of doing things differently. What for? What I'm getting for losing my time and reinventing the tools that are already available and much more polished? Dockerfiles can be replicated. Docker Hub can be repli…

> And believe you me, using BSD nowadays is the definition of doing things differently. ... although people like Florian Haas argue that the way that one does things on the BSDs is actually the way that makes sense to do things with Docker, as well, and the way that you think to be "different" is actually the sensible way overall. * https://plus.google.com/+FlorianHaas/posts/4xjQP1q6DEN * https://www.hastexo.com/blog…

Choosing BSD instead of Linux is "doing things differently". I'm talking about popularity and what it means in this whole comment tree, not about technical merits.

Re: Systemd vs. Docker

#67

Post by GFK_of_xmaspast »

kordless wrote: post #31
bryanlarsen wrote: post #6

Earlier quoted context omitted.

Why the systemd hate? Because it's a big monolithic project that takes over your system? You do realize that Docker is much more monolithic and opinionated than systemd, right?

When you ask questions, especially leading ones, it causes a good deal of confusion around the topic at hand. The reasons behind this are complex, but they have something to do with our tendency to double bind each other. Someone has the right to say why something is "disqualified" for them, even if it is devoid of context. What is awesome here is that the leading expert for this topic is replying directly to the neg…

So in other words "questions are a burden and answers are a prison for oneself".

Re: Systemd vs. Docker

#68

Post by js2 »

pas wrote: post #16
thwarted wrote: post #13

Poettering says that PID 1 has special requirements. One of these is killing "zombie" processes that have been abandoned by their calling session. This is a real problem for Docker since the application runs as PID 1 and does not handle the zombie processes. For example, containers running the Oracle database can end up with thousands of zombie processes. Why does Poettering keep claiming this when he's the one who s…

I guess he's saying, that you can't just take any random binary and run it in a Docker container, because if that binary spawns a lot of children but does not wait for them, then you'll have a lot of zombies. Docker could run a minimal pid1 in each container to address this. Though if this had been a big issue I guess this would have been already fixed. Naturally, a proof of concept of the problem would be great. (Le…

Just to clarify: even with a proper init, if a process spawns children and doesn't wait on them, you still have zombies until the parent either dies (allowing init to inherit the zombie, at which point it waits on it), or the parent waits. This is the reason behind the double-fork trick.

Re: Systemd vs. Docker

#69

Post by js2 »

One of these is killing "zombie" processes that have been abandoned by their calling session.

That's funny terminolgy, isn't it? Killing a process usually means sending it a signal, typically TERM or KILL, that causes it to exit. But a zombie process is one that has already exited, but hasn't been waited for by its parent, where its parent is either the process that spawned it, or if that process has died, the process with PID 1. This is usually referred to as reaping the zombie process, not killing it. AFAIK, a signal sent to a zombie process is simply ignored.

Or do the quotes around zombie imply a different meaning, such as "zombie-like"?

Re: Systemd vs. Docker

#70

Post by agentgt »

rdtsc wrote: post #48
agentgt wrote: post #44

Earlier quoted context omitted.

The issue I have with that is the tooling you mention while stable and mature is actively being replaced by cloud tools because you really can't just debug a single machine in production when you have a cluster.. not to mention it is production so debug symbols might not even be available. I understand your point of the maturity w/ tooling but I see it as a serious failure if you have to log into a machine in product…

> you really can't just debug a single machine in production when you have a cluster Somehow I ended up debugging, tracing, monitoring and even hotpatching individual machines in the cluster. Yeah the easy problems will show up in the monitoring and logs. The harder ones won't.

That must have been a pain in the butt :) . And for sure your right there are always exceptions.

I guess I haven't ran into those issues probably because I run JVMs but I suppose if you have native code or an interpreter using native code I can see how it would be helpful to just SSH and figure out what the issue is.

Now that I recall I have actually had to SSH a bunch of times because of Rackspace network interfaces randomly failing so I am a big hypocrite :)

Post reply on HN