Sidebar on Operating Systems

⚠️ This section is laced with sarcasm. ⚠️

Containers are a technology created from combining a few Linux kernel features. This makes them incredibly versatile and just confusing enough to be wrapped in thick layers of software and high-tech jargon. Many others have written about the technology underpinning containers¹, so I won't go into more detail here. I merely point this out to emphasize that non-Linux operating systems only access containers via Virtual Machines (VM) hosting Linux.² Specifically, this means the other two big operating systems (Mircrosoft Windoze and Mac OS X) must be accomodated with VMs.

Windoze

(Misspelling Windows as Windoze since I think its funny.)

Microsoft released Windoze Subsystem for Linux (WSL) in 2016 after finally realizing that work can only really get done within a functional operating system (like Linux-based ones). While largely expected to be apart of their Embrace Extend Extinguish methodology, it still benefits us in that we can use containers in an almost equivalent way they would be used on a Linux system with the added step of having to wait for Windoze to boot and open WSL. One of the most popular container runners docker just plainly tells people to use WSL when installing it.

With this context in mind, denv supports Windoze indirectly through WSL in the same manner as docker. If you are on Windoze, first enable WSL and then interact with docker (or whatever runner you want³) and denv within the WSL terminal.

Mac OS X

Both docker and podman support Mac OS X by spawning light weight VMs that can be kept idle while awaiting container instruction.⁴ Since Mac OS X has a more similar filesystem (and presumably kernel) to Linux, its VM is able to have a tighter integration with the host system. This has both benefits and difficulties. The benefit is that we presumably get performance improvements (I'm assuming this, I have not tested it.) The downside is that the user is not exposed directly to a terminal within the Linux kernel system like they are for Windoze (via WSL) or bare-metal Linux. This is an issue for denv (and for other container wrappers) since, as a wrapper, we are trying to connect the container and host which is difficult to do when given only limited access to the intermediary VM layer.

With this context in mind, denv has limited support for Mac OS X. Namely, denv is able to support non-ID-necessary processes within the constructed denv. For example, compiling and running a program within denv works fine but making a commit with git within it does not. The discovery of this limitation and any ongoing work is tracked in denv Issue #102.

Graphical Applications

denv ensures that the X11 apps spawned from within the container can connect with the host by passing the DISPLAY environment variable and mounting the /tmp/.X11-unix directory. For Linux-hosts and WSL, this is enough⁵; however, on MacOS additional setup is required.

If you don't plan to use a graphical application from within the a denv (or if you are just using a network-based application like Jupyter Lab), then there is no need to do this additional setup on MacOS. These instructions⁶ which basically amount to installing XQuartz⁷ and then disabling access control with xhost + (check links for specific, permanent configuration of XQuartz after installation).