3 ms·

I've been developing on a Mac for years, and I've never needed to use Docker or virtualisation to do it. (I've been doing game development, and now web front en

I've been developing on a Mac for years, and I've never needed to use Docker or virtualisation to do it. (I've been doing game development, and now web front end development. I'm sure the major game engines and browsers will be ported to run on ARM chips (although it may take a while)). Honest question: What sort of development regularly requires using docker or virtualized OSes?

neurostimulant 6y ago
Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy your app without having to know its internal dependency graph first.
- anthk 6y ago
  If you use Docker as a production tool instead of prototyping several shit will happen soon.
  - yjftsjthsd-h 6y ago
    It's not quite as simple as GP implies, but why not? I work at a place running Docker in prod, and our only issues are with the swarm networking, not Docker itself.
  - neurostimulant 6y ago
    Certainly not for production, but when you can't run x86-64 images, just simple prototyping or building images that requires x86-64 will require using external servers instead of using locally installed docker, which will be a huge barrier for casual prototyping.
vertex-four 6y ago
Web development doesn't "require" it per se, but it's easier to keep track of the mess of ad-hoc dependencies with Docker. Really, I think the solution is keeping better track of your dependencies and avoiding ad-hoc system configuration, but...
marmaduke 6y ago
Honest answer: almost not much. Except, virtualization is a big trend, since it's a hugely convenient way to package a complex thing into a black box and run it with minimal attack surface. If you sit back for a second, you can see that things like systemd provide nearly everything you'd want from a container, that, like, who cares is the approach you could have, for the top ten languages. If you are running a massive stack then maybe you do need Docker and VirtualBox but at this point, shouldn't you be using a staging server anyway?
hesk 6y ago
Two examples: 1) I wanted to provide a Jupyter notebook with IBM DB2 support for a university course. (Why DB2? Because its optimizer can transparently use materialized views for query optimization which PostgreSQL can't AFAIK.) IBM provides a Jupyter magic which requires the Python package ibm_db. ibm_db requires a DYLD_LIBRARY_PATH hack which macOS doesn't support unless you disable System Integrity Protection. I don't want to disable SIP on my system and I can't ask our students to do that. A Docker image provides a convenient solution to the problem. 2) I do a lot of disparate project development using Flink and Hadoop. These get deployed on Linux machines. My preferred way to develop on my Macbook is to boot up a headless Ubuntu system inside VirtualBox, SSH into it, and then start a TMUX session. This has a number of advantages. a) The dev environment more closely resembles the production environment. b) I can setup my TMUX session, save the state of the VM, and then restore it months later to the exact state just by booting up the VM. c) I don't have to pollute my macOS environment with dev tools that I rarely use. It's not strictly necessary but it's actually quite convenient. I can even do development in IntelliJ on macOS, run the services inside the VM, and thanks to remote JVM debugging use the IntelliJ debugger on macOS to step through the code running inside the JVM.
jki275 6y ago
Embedded. Almost all the compiler toolchains for embedded devices will not run under anything but some esoteric specific version of Linux or Windows. I generally write code on Mac native (C or C++), then put it into a VM configured with all the right tools and such to build and install. Usually that VM is a copy of the VM I use for CI/CD with gitlab. I don't know how common that use case is, but I know everybody I know who does embedded work does it that way or something like it.

neurostimulant 6y ago

Almost every server applications (databases, webservers, webapps) are available as docker images. It's very easy to deploy those apps using docker, which is why it's taking over sysadmin world by storm. Previously, handling a big web application deployment is a complex task that requires a dedicated team. Now, you can just package your app as a docker image, and other people that know docker will know how to deploy your app without having to know its internal dependency graph first.

anthk 6y ago
If you use Docker as a production tool instead of prototyping several shit will happen soon.
- yjftsjthsd-h 6y ago
  It's not quite as simple as GP implies, but why not? I work at a place running Docker in prod, and our only issues are with the swarm networking, not Docker itself.
- neurostimulant 6y ago
  Certainly not for production, but when you can't run x86-64 images, just simple prototyping or building images that requires x86-64 will require using external servers instead of using locally installed docker, which will be a huge barrier for casual prototyping.

vertex-four 6y ago

Web development doesn't "require" it per se, but it's easier to keep track of the mess of ad-hoc dependencies with Docker. Really, I think the solution is keeping better track of your dependencies and avoiding ad-hoc system configuration, but...

marmaduke 6y ago

Honest answer: almost not much. Except, virtualization is a big trend, since it's a hugely convenient way to package a complex thing into a black box and run it with minimal attack surface. If you sit back for a second, you can see that things like systemd provide nearly everything you'd want from a container, that, like, who cares is the approach you could have, for the top ten languages. If you are running a massive stack then maybe you do need Docker and VirtualBox but at this point, shouldn't you be using a staging server anyway?

hesk 6y ago

Two examples: 1) I wanted to provide a Jupyter notebook with IBM DB2 support for a university course. (Why DB2? Because its optimizer can transparently use materialized views for query optimization which PostgreSQL can't AFAIK.) IBM provides a Jupyter magic which requires the Python package ibm_db. ibm_db requires a DYLD_LIBRARY_PATH hack which macOS doesn't support unless you disable System Integrity Protection. I don't want to disable SIP on my system and I can't ask our students to do that. A Docker image provides a convenient solution to the problem. 2) I do a lot of disparate project development using Flink and Hadoop. These get deployed on Linux machines. My preferred way to develop on my Macbook is to boot up a headless Ubuntu system inside VirtualBox, SSH into it, and then start a TMUX session. This has a number of advantages. a) The dev environment more closely resembles the production environment. b) I can setup my TMUX session, save the state of the VM, and then restore it months later to the exact state just by booting up the VM. c) I don't have to pollute my macOS environment with dev tools that I rarely use. It's not strictly necessary but it's actually quite convenient. I can even do development in IntelliJ on macOS, run the services inside the VM, and thanks to remote JVM debugging use the IntelliJ debugger on macOS to step through the code running inside the JVM.

jki275 6y ago

Embedded. Almost all the compiler toolchains for embedded devices will not run under anything but some esoteric specific version of Linux or Windows. I generally write code on Mac native (C or C++), then put it into a VM configured with all the right tools and such to build and install. Usually that VM is a copy of the VM I use for CI/CD with gitlab. I don't know how common that use case is, but I know everybody I know who does embedded work does it that way or something like it.