6 ms·

This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to havi

This has been a topic brought up internally at Apple many times over the past decade. Glad to see it finally moving forward. Although I see the benefits to having a system-version of these packages.. if you're doing anything serious for production then the environment should be containerized.

new_realist 7y ago
Does OSX offer reasonable container technology? chroot?
- wedn3sday 7y ago
  Singularity recently released a (non-fully featured, but still useful) mac version.
- pram 7y ago
  macOS has a native hypervisor framework, Docker and xhyve uses it. https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit https://github.com/moby/hyperkit
  - AceJohnny2 7y ago
    In other words, nothing serious. Does anyone actually use Docker on Mac? Xhyve is more of a proof-of-concept than a production-ready tool.
    - abhorrence 7y ago
      I use Docker on Mac, and know many others who do as well.
    - RussianCow 7y ago
      > Does anyone actually use Docker on Mac? What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.
      - enneff 7y ago
        But doesn’t Docker on Mac run a Linux VM? I don’t think it uses any of MacOS’s isolation features.
        frizkie 7y ago
        It uses Hyperkit: https://github.com/moby/hyperkit https://github.com/moby/hyperkit
    - dwaite 7y ago
      > Does anyone actually use Docker on Mac? I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.
      - brianwawok 7y ago
        Unless you want to run CD to the App Store? So fun....
      - jackfraser 7y ago
        Ah, but if the XServe had not died and datacenters had racks of these things, there'd no doubt be a production quality implementation by now. Shame.
    - markn951 7y ago
      I personally know of at least 3 or 4 engineering teams of 30+ developers who use it daily.
    - jen20 7y ago
      Xhyve is but one of the options for fronting hypervisor.framework. Calling it “not serious” is quite wrong.
    - konart 7y ago
      >Does anyone actually use Docker on Mac? Sure, for development tasks.
  - bpye 7y ago
    Qemu has a backend too if I'm not mistaken?
  - new_realist 7y ago
    A hypervisor is not exactly a container. Definitely not in the Linux sense. It may be more secure, but it is also slower. Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no. Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.). I would rather chroot.
    - markstos 7y ago
      How much slower?
      - TehCorwiz 7y ago
        Measurably slower than a LXC container, but still much faster than a full VM.
      - jackfraser 7y ago
        Not much slower than, say, Hyper-V or Virtualbox or other hypervisors that live alongside a general purpose desktop OS. Remember, they're using the same Intel chips and VT-d and such as anything else; as long as you have enough CPU power it's going to run fine. IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint. I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.
      - wyufro 7y ago
        Primarily disk access is a lot slower, even with Hyper-V. Eg. Compilation suffers from this. But tasks that don't use the disk too much shouldn't be that bad.
      - tele_ski 7y ago
        Our build time on Linux container is 8 minutes, but it's a few hours on macOS using docker containers. I haven't dug into it but the hypervisor seems to be single threading the normally multicore compile.
- m463 7y ago
  I think apple fundamentally does not understand containers. All the interesting container stuff is on other platforms. It might be out of fear, maybe because apple doesn't want macos to be virtualized. It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines. or a dockerfile like: FROM macos:10.14 RUN installer xcode... RUN xcode-build myproject
  - eropple 7y ago
    > I think apple fundamentally does not understand containers. Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers. Just a little hunch, you know?
    - m463 7y ago
      The devops guys need to spread the love to the OS group and ship it with the OS. Maybe it's another "you're not the target market" kind of thing. The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.
  - saagarjha 7y ago
    > apple doesn't want macos to be virtualized. The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS. > It would be really nice to have say the current xcode in one container and a dev xcode in another. This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.
    - m463 7y ago
      - "allows" not the same as supports. - I think xcode-select just modifies a .plist.
- Gaelan 7y ago
  I imagine you could get pretty far with sandboxing+chroot, but it wouldn’t be docker. You’d definitely be able to prevent stuff in the container from getting out, but I’m not so sure you could reproduce docker’s “VM-like” (I.e. the inside of the container is ~identical to a normal Linux machine, with no need to make stuff compatible) quality.
Waterluvian 7y ago
Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.
- arvinsim 7y ago
  Learning how to install Python and Pip should be part of the learning process for newbies.
  - bshipp 7y ago
    Installing the version you need when you want to run a script is arguably easier for newbies than all the error messages arising from an out of date implementation originally included with an OS. it's not like installing python is any more complicated than any other piece of software that needs to be installed. Windows users have had no choice but to do that for decades.
    - SeanLuke 7y ago
      > Windows users have had no choice but to do that for decades. You're saying this like it's a good thing.
      - bshipp 7y ago
        It's not a good thing or a bad thing. I'm saying it's not a thing at all. If someone decides they want to run a custom ruby or python script the least difficult aspect of that decision is installing the interpreter. For example, I was dealing with someone yesterday who decided they wanted to learn how to write apps for Android. Without even seeing a single line of code (or even knowing which language they would have to learn!!) they had already successfully installed Android Studio and Jetbrains IDEA. Without coming across as some gatekeeping greybeard, I think anyone who has even a glancing interest in programming would agree if you can't follow a one-line/click installation instruction you may want to find a simpler tool for the task than writing your own code from scratch.
erikpukinskis 7y ago
> if you're doing anything serious for production then the environment should be containerized. What do you mean?
- __full_pint 7y ago
  I’m not OP but: When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build. Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.
  - erikpukinskis 7y ago
    But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?
    - __full_pint 7y ago
      Of course you do that type of testing. The problem comes about when someone does the following: - creates python project - pip install some_package - import some_package Turns out some package was already in the path but a different version - proceeds to test and build with the assumption of some_package @ newer - all tests pass - ships project with requirements of some_package @ newer Someone attempts to use the package but it doesn’t work.
      - erikpukinskis 7y ago
        Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment? That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs. But maybe I’m not understanding your suggestion.
rurban 7y ago
The problem is not doing anything serious. Of course this would need an updated language runtime. The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.
- tlrobinson 7y ago
  It seems like there’s an opportunity for a lightweight statically-linked scripting language. Something between Go and Python.
  - rurban 7y ago
    The standard toolkit for this is perl. It's used in automake, most gnu utils and git. python and ruby bring nothing new to the table, besides being newbie friendlier.

new_realist 7y ago

Does OSX offer reasonable container technology? chroot?

wedn3sday 7y ago
Singularity recently released a (non-fully featured, but still useful) mac version.
pram 7y ago
macOS has a native hypervisor framework, Docker and xhyve uses it. https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/hypervisor https://github.com/moby/hyperkit https://github.com/moby/hyperkit
- AceJohnny2 7y ago
  In other words, nothing serious. Does anyone actually use Docker on Mac? Xhyve is more of a proof-of-concept than a production-ready tool.
  - abhorrence 7y ago
    I use Docker on Mac, and know many others who do as well.
  - RussianCow 7y ago
    > Does anyone actually use Docker on Mac? What? We use it at work every day for local development, and my previous employer did as well. It has issues, definitely, but they have more to do with Docker than with xhyve.
    - enneff 7y ago
      But doesn’t Docker on Mac run a Linux VM? I don’t think it uses any of MacOS’s isolation features.
      - frizkie 7y ago
        It uses Hyperkit: https://github.com/moby/hyperkit https://github.com/moby/hyperkit
  - dwaite 7y ago
    > Does anyone actually use Docker on Mac? I use it extensively. It is a desktop product however; it you aren't expected to put a swarm of MacBook pros into production.
    - brianwawok 7y ago
      Unless you want to run CD to the App Store? So fun....
    - jackfraser 7y ago
      Ah, but if the XServe had not died and datacenters had racks of these things, there'd no doubt be a production quality implementation by now. Shame.
  - markn951 7y ago
    I personally know of at least 3 or 4 engineering teams of 30+ developers who use it daily.
  - jen20 7y ago
    Xhyve is but one of the options for fronting hypervisor.framework. Calling it “not serious” is quite wrong.
  - konart 7y ago
    >Does anyone actually use Docker on Mac? Sure, for development tasks.
- bpye 7y ago
  Qemu has a backend too if I'm not mistaken?
- new_realist 7y ago
  A hypervisor is not exactly a container. Definitely not in the Linux sense. It may be more secure, but it is also slower. Further, there's no decent solution for shipping a macOS container image to run in a VM. Linux, yes, Mac, no. Finally, good luck getting your virtualized macOS app to interact reasonably with your main OS (no drag and drop, no OpenGL, etc.). I would rather chroot.
  - markstos 7y ago
    How much slower?
    - TehCorwiz 7y ago
      Measurably slower than a LXC container, but still much faster than a full VM.
    - jackfraser 7y ago
      Not much slower than, say, Hyper-V or Virtualbox or other hypervisors that live alongside a general purpose desktop OS. Remember, they're using the same Intel chips and VT-d and such as anything else; as long as you have enough CPU power it's going to run fine. IIRC the Docker implementation for OS X runs a tiny, carefully-configured Linux VM transparently in the background. This isn't that dissimilar from the Windows Subsystem for Linux from a user standpoint. I've done plenty of Docker work on OS X; the only real weirdness is that you're running Linux in the containers and OS X outside. Eventually, though, before switching completely to a native Linux desktop, I moved deeper into the containers and would barely ever see the OS X command prompt any more.
    - wyufro 7y ago
      Primarily disk access is a lot slower, even with Hyper-V. Eg. Compilation suffers from this. But tasks that don't use the disk too much shouldn't be that bad.
    - tele_ski 7y ago
      Our build time on Linux container is 8 minutes, but it's a few hours on macOS using docker containers. I haven't dug into it but the hypervisor seems to be single threading the normally multicore compile.
m463 7y ago
I think apple fundamentally does not understand containers. All the interesting container stuff is on other platforms. It might be out of fear, maybe because apple doesn't want macos to be virtualized. It would be really nice to have say the current xcode in one container and a dev xcode in another. It would be nice to farm work out to a lot of machines. or a dockerfile like: FROM macos:10.14 RUN installer xcode... RUN xcode-build myproject
- eropple 7y ago
  > I think apple fundamentally does not understand containers. Given that Apple is (or at least was) one of the biggest users of Mesos in the world and have invited me to interview specifically on the back of the operationalization of containers, I'm guessing that the staggeringly bright programmers they've got probably understand containers. Just a little hunch, you know?
  - m463 7y ago
    The devops guys need to spread the love to the OS group and ship it with the OS. Maybe it's another "you're not the target market" kind of thing. The point I'm getting at is that folks on other platforms have lots and lots of options and apple doesn't provide any.
- saagarjha 7y ago
  > apple doesn't want macos to be virtualized. The macOS EULA explicitly allows macOS to be virtualized if you do it on a Mac running macOS. > It would be really nice to have say the current xcode in one container and a dev xcode in another. This is the entire point behind xcode-select. I currently have Xcode-beta and Xcode on side-by-side on my machine, and they pretty much coexist.
  - m463 7y ago
    - "allows" not the same as supports. - I think xcode-select just modifies a .plist.
Gaelan 7y ago
I imagine you could get pretty far with sandboxing+chroot, but it wouldn’t be docker. You’d definitely be able to prevent stuff in the container from getting out, but I’m not so sure you could reproduce docker’s “VM-like” (I.e. the inside of the container is ~identical to a normal Linux machine, with no need to make stuff compatible) quality.

Waterluvian 7y ago

Python and pip just being there is a huge advantage for newbies. I really think that part of programming is constantly ignored because all the decision-makers are not newbies.

arvinsim 7y ago
Learning how to install Python and Pip should be part of the learning process for newbies.
- bshipp 7y ago
  Installing the version you need when you want to run a script is arguably easier for newbies than all the error messages arising from an out of date implementation originally included with an OS. it's not like installing python is any more complicated than any other piece of software that needs to be installed. Windows users have had no choice but to do that for decades.
  - SeanLuke 7y ago
    > Windows users have had no choice but to do that for decades. You're saying this like it's a good thing.
    - bshipp 7y ago
      It's not a good thing or a bad thing. I'm saying it's not a thing at all. If someone decides they want to run a custom ruby or python script the least difficult aspect of that decision is installing the interpreter. For example, I was dealing with someone yesterday who decided they wanted to learn how to write apps for Android. Without even seeing a single line of code (or even knowing which language they would have to learn!!) they had already successfully installed Android Studio and Jetbrains IDEA. Without coming across as some gatekeeping greybeard, I think anyone who has even a glancing interest in programming would agree if you can't follow a one-line/click installation instruction you may want to find a simpler tool for the task than writing your own code from scratch.

erikpukinskis 7y ago

> if you're doing anything serious for production then the environment should be containerized. What do you mean?

__full_pint 7y ago
I’m not OP but: When you build and package things for production you should create an environment. This ensures the packaging the right versioning of requirements for build. Say you build using the system version but use packages based on another version. It may work for you but probably won’t work elsewhere.
- erikpukinskis 7y ago
  But you wouldn’t want to develop in that environment, right? You do integration testing in it, but development should largely happen in small modules, with unit tests and test data, no?
  - __full_pint 7y ago
    Of course you do that type of testing. The problem comes about when someone does the following: - creates python project - pip install some_package - import some_package Turns out some package was already in the path but a different version - proceeds to test and build with the assumption of some_package @ newer - all tests pass - ships project with requirements of some_package @ newer Someone attempts to use the package but it doesn’t work.
    - erikpukinskis 7y ago
      Right, that’s why you do integration testing (manual and automated) but are you saying therefore you should do all development inside a production environment? That’s what doesn’t pass muster to me. Why should I work on my CSS styles in an environment with the production database? It will be much slower than just working on that package in my desktop environment with just enough scaffolding the code runs. But maybe I’m not understanding your suggestion.

rurban 7y ago

The problem is not doing anything serious. Of course this would need an updated language runtime. The problem is doing something simple, like an installer. bash => zsh: fine. You can still install with the old /bin/bash. but for many cases a shell is not enough, and then you have to compile something statically for a trivial dynamic task. Which makes the download 10x larger. Not cool.

tlrobinson 7y ago
It seems like there’s an opportunity for a lightweight statically-linked scripting language. Something between Go and Python.
- rurban 7y ago
  The standard toolkit for this is perl. It's used in automake, most gnu utils and git. python and ruby bring nothing new to the table, besides being newbie friendlier.