4 ms·

... if docker ran “natively” it’d mean using kernel hooks provided by xnu, which means you’d be able to run another instance of macOS in a container. How is it

... if docker ran “natively” it’d mean using kernel hooks provided by xnu, which means you’d be able to run another instance of macOS in a container. How is it so many people use docker but have zero fucking clue about how it works?

haswell 6y ago
Docker obscures the implementation details. Part of this is by design: don't worry about the hard stuff, because Docker does it for you. It's completely unsurprising that many folks haven't spent the time to dive into the internals. In many cases, because they don't need to. Such is the nature of abstraction and higher level frameworks.
- outworlder 6y ago
  We aren't even close to a point where someone can just pretend a container is a magical box that just works. All abstraction leak. This is a relatively recent, quite leaky one.
  - haswell 6y ago
    > We aren't even close to a point where someone can just pretend a container is a magical box that just works. I challenge this assertion. While it is of course true that there are situations that require a deeper knowledge of Docker, this is also not universally true. Many projects these days have a Getting Started doc that has some options like: - Build from source - Install this package - Use Docker I often choose the Docker option because I know I'll (most likely) get a working version of the project in 5 minutes with minimal effort. I might not even fully understand the project yet or its architecture (much less that of Docker), but I can get it up and running with `docker pull` and `docker run`. In many cases, I'll never need to know anything more. I've personally spent more time using docker to build my own stuff, so I've had to learn more. But for many folks, it absolutely is a magical box that just works, and that's perfectly ok. I agree that all abstractions tend to eventually leak. But depending on why you're using Docker, you may never have a reason to encounter that leakage.
- stephenr 6y ago
  Just because CorporationX says “don’t worry about it we got you bruh” doesn’t mean technologists - people who actively work with technology and write software - should be excused for just throwing up their hands and saying “it’s just ducking magic I don’t know how it works”. I’m not talking about understanding it to the level of being able to contribute a patch to the project. I’m talking about understanding that containers are inherently tied to the kernel, and thus are limited to running software written for the same kernel as the host running the container. It isn’t rocket science. I literally explained it in one sentence, and I’ve never used docker in my life. This is along the same level of knowledge as “no, you can just take an iPhone app and run it on android” or “no you can’t just take a SQLServer query and run it on anything that vaguely knows “SQL”.
  - haswell 6y ago
    > Just because CorporationX says “don’t worry about it we got you bruh” doesn’t mean technologists - people who actively work with technology and write software - should be excused for just throwing up their hands and saying “it’s just ducking magic I don’t know how it works”. Entire industries are built on the premise that "don't worry about it, we got you". I'm not saying that it's appropriate to be completely blind/unaware of what you're using, but there's a line somewhere that's surprisingly difficult to draw in 2020. I don't think anyone would argue that learning more is a bad thing. But the more salient point is that for many, it's just not necessary. If you're doing work that requires a deeper knowledge of the thing, then of course you should learn it. If you're not doing work that requires this knowledge, it'd be a waste of time, the most precious commodity available to us. Others have made the comparison to learning assembly. Useful? sure. Necessary in 2020? Usually not. > It isn’t rocket science. I literally explained it in one sentence, and I’ve never used docker in my life. This is what you said: > ... if docker ran “natively” it’d mean using kernel hooks provided by xnu, which means you’d be able to run another instance of macOS in a container. Not only does this tell the reader nothing practical about how Docker actually works, it doesn't even address the parent comment in a useful/informative way. You followed this up with a statement that is a borderline personal attack on the parent comment. I mean this as constructively as possible, but you need to work on your delivery, and ask yourself what you're trying to accomplish with these comments. So far, they've been unhelpful and borderline abusive.
WrtCdEvrydy 6y ago
Because we use abstraction as a way of lowering barrier to entry to reduce the requirements for people to be proficient in the career and be able to reduce overall costs downwards?
- NikolaeVarius 6y ago
  Lowering the entrance requirements doesn't mean you should STAY at the entrance.
  - bamboleo 6y ago
    You keep going, I’ll take another door. I know enough Docker to create and launch a dev environment, but I don’t need anything more than that since I don’t do deployments. Likewise you don’t need to learn about browser rendering since you barely interact with it.
Ar-Curunir 6y ago
Do you know the details of the x86 architecture? Why so toxic?
diveanon 6y ago
It's called abstraction, and it is what enables you to live in modern society without knowing the technical details of every facet of your life. Furthermore, not being able to hook into xnu to virtualize macos is a business decision, not a technical limitation.
Groxx 6y ago
Because it's not necessary to know for day-to-day work. Which is what most software aspires to achieve.
geofft 6y ago
> which means you’d be able to run another instance of macOS in a container This is not true, for multiple reasons. Strictly speaking it only means you'd be able to run another instance of Darwin in a container. And, as you surely know because your tone of voice implies you bear immense knowledge, a Docker-style container is not a full OS: it doesn't run an init or normal system daemons, so it wouldn't even be a full instance of Darwin, so it wouldn't have to support functionality only needed by launchd or system daemons (e.g. WindowServer). It would just need to let you run a stanalone program in a chroot + separate network, PID, and IPC namespace + apply resource controls. Furthermore, since most people are using Docker for developing software that's going to run on Linux, there would be no real need to virtualize the parts of XNU that aren't also provided on Linux - notably all the Mach stuff. You'd just need to provide a BSD-style syscall API to programs in a container.
- jsjohnst 6y ago
  > it doesn't run an init or normal system daemons There’s no technical limitation stopping you from running init or system daemons inside a container, it’s just an anti-pattern and missing the point of a container in most cases.
dabeeeenster 6y ago
Because you don't need to?
pitterpatter 6y ago
For the same reason that the general dev doesn't have in-depth knowledge about every OS they use: abstractions.

haswell 6y ago

Docker obscures the implementation details. Part of this is by design: don't worry about the hard stuff, because Docker does it for you. It's completely unsurprising that many folks haven't spent the time to dive into the internals. In many cases, because they don't need to. Such is the nature of abstraction and higher level frameworks.

outworlder 6y ago
We aren't even close to a point where someone can just pretend a container is a magical box that just works. All abstraction leak. This is a relatively recent, quite leaky one.
- haswell 6y ago
  > We aren't even close to a point where someone can just pretend a container is a magical box that just works. I challenge this assertion. While it is of course true that there are situations that require a deeper knowledge of Docker, this is also not universally true. Many projects these days have a Getting Started doc that has some options like: - Build from source - Install this package - Use Docker I often choose the Docker option because I know I'll (most likely) get a working version of the project in 5 minutes with minimal effort. I might not even fully understand the project yet or its architecture (much less that of Docker), but I can get it up and running with `docker pull` and `docker run`. In many cases, I'll never need to know anything more. I've personally spent more time using docker to build my own stuff, so I've had to learn more. But for many folks, it absolutely is a magical box that just works, and that's perfectly ok. I agree that all abstractions tend to eventually leak. But depending on why you're using Docker, you may never have a reason to encounter that leakage.
stephenr 6y ago
Just because CorporationX says “don’t worry about it we got you bruh” doesn’t mean technologists - people who actively work with technology and write software - should be excused for just throwing up their hands and saying “it’s just ducking magic I don’t know how it works”. I’m not talking about understanding it to the level of being able to contribute a patch to the project. I’m talking about understanding that containers are inherently tied to the kernel, and thus are limited to running software written for the same kernel as the host running the container. It isn’t rocket science. I literally explained it in one sentence, and I’ve never used docker in my life. This is along the same level of knowledge as “no, you can just take an iPhone app and run it on android” or “no you can’t just take a SQLServer query and run it on anything that vaguely knows “SQL”.
- haswell 6y ago
  > Just because CorporationX says “don’t worry about it we got you bruh” doesn’t mean technologists - people who actively work with technology and write software - should be excused for just throwing up their hands and saying “it’s just ducking magic I don’t know how it works”. Entire industries are built on the premise that "don't worry about it, we got you". I'm not saying that it's appropriate to be completely blind/unaware of what you're using, but there's a line somewhere that's surprisingly difficult to draw in 2020. I don't think anyone would argue that learning more is a bad thing. But the more salient point is that for many, it's just not necessary. If you're doing work that requires a deeper knowledge of the thing, then of course you should learn it. If you're not doing work that requires this knowledge, it'd be a waste of time, the most precious commodity available to us. Others have made the comparison to learning assembly. Useful? sure. Necessary in 2020? Usually not. > It isn’t rocket science. I literally explained it in one sentence, and I’ve never used docker in my life. This is what you said: > ... if docker ran “natively” it’d mean using kernel hooks provided by xnu, which means you’d be able to run another instance of macOS in a container. Not only does this tell the reader nothing practical about how Docker actually works, it doesn't even address the parent comment in a useful/informative way. You followed this up with a statement that is a borderline personal attack on the parent comment. I mean this as constructively as possible, but you need to work on your delivery, and ask yourself what you're trying to accomplish with these comments. So far, they've been unhelpful and borderline abusive.

WrtCdEvrydy 6y ago

Because we use abstraction as a way of lowering barrier to entry to reduce the requirements for people to be proficient in the career and be able to reduce overall costs downwards?

NikolaeVarius 6y ago
Lowering the entrance requirements doesn't mean you should STAY at the entrance.
- bamboleo 6y ago
  You keep going, I’ll take another door. I know enough Docker to create and launch a dev environment, but I don’t need anything more than that since I don’t do deployments. Likewise you don’t need to learn about browser rendering since you barely interact with it.

Ar-Curunir 6y ago

Do you know the details of the x86 architecture? Why so toxic?

diveanon 6y ago

It's called abstraction, and it is what enables you to live in modern society without knowing the technical details of every facet of your life. Furthermore, not being able to hook into xnu to virtualize macos is a business decision, not a technical limitation.

Groxx 6y ago

Because it's not necessary to know for day-to-day work. Which is what most software aspires to achieve.

geofft 6y ago

> which means you’d be able to run another instance of macOS in a container This is not true, for multiple reasons. Strictly speaking it only means you'd be able to run another instance of Darwin in a container. And, as you surely know because your tone of voice implies you bear immense knowledge, a Docker-style container is not a full OS: it doesn't run an init or normal system daemons, so it wouldn't even be a full instance of Darwin, so it wouldn't have to support functionality only needed by launchd or system daemons (e.g. WindowServer). It would just need to let you run a stanalone program in a chroot + separate network, PID, and IPC namespace + apply resource controls. Furthermore, since most people are using Docker for developing software that's going to run on Linux, there would be no real need to virtualize the parts of XNU that aren't also provided on Linux - notably all the Mach stuff. You'd just need to provide a BSD-style syscall API to programs in a container.

jsjohnst 6y ago
> it doesn't run an init or normal system daemons There’s no technical limitation stopping you from running init or system daemons inside a container, it’s just an anti-pattern and missing the point of a container in most cases.

dabeeeenster 6y ago

Because you don't need to?

pitterpatter 6y ago

For the same reason that the general dev doesn't have in-depth knowledge about every OS they use: abstractions.