4 ms·

Honestly Docket Desktop for macOS has honestly been one of the most frustrating applications I have ever used and it isn’t Apple’s fault. Maybe with the new vir

Honestly Docket Desktop for macOS has honestly been one of the most frustrating applications I have ever used and it isn’t Apple’s fault. Maybe with the new virtualization layer the developers at docker can fix it. One of the other issues is that it starts to create and enormous docker raw file.

nicoburns 4y ago
> and it isn’t Apple’s fault Eh, yes it is. Apple doesn't provide a containerisation API for their OS, which means Docker is forced to run non-natively!
- oneplane 4y ago
  Eh, no it isn't. apple does have a public container API but the problem is you still can't run Linux binaries on macOS no matter how many containers you put them in. Containers on macOS don't use OCI images or anything like that, but scoped and grouped access to system resources with a separate user land that 'looks' like a full OS has been available for over 5 years. Even without that, XNU has plenty of facilities for it, and even if it didn't you'd still be able to use Launchd environments (which are more akin to LXC). Docker relies on specific implementation details of the Linux kernel. It always has. That is why you always need a Linux OS somewhere to run the containers.
  - eptcyka 4y ago
    There is an OCI implementation for Windows which allows for Windows native containers. So docker can run on non-linux systems just fine, it's just that nobody cares. People use docker to package Linux applications, not because of some inate dockerness.
    - oneplane 4y ago
      OCI images yes, but that doesn't make them the same. OCI can be used to store many things, and those non-Linux OCI images will not run on Linux. Does that mean that it is Linux at fault for not running arbitrary formats from OCI images? No. This applies everywhere; if you build for a specific target and package it up, not using that target when trying to run it is a PEBCAK. Example: there are artefacts you can store as OCI images that contain Mach-O binaries, and Windows and Linux won't really run those. You can even still PPC code in those binaries, and link to Cocoa frameworks. This means that the OS and architecture you are targeting will not be Windows or Linux, and that is not their fault.
      - eptcyka 4y ago
        In just pointing out that people are saying they want "docker" to work fine on non-Linux platforms but really, they want to run Linux binaries on non-linux kernels.
        nicoburns 4y ago
        > In just pointing out that people are saying they want "docker" to work fine on non-Linux platforms but really, they want to run Linux binaries on non-linux kernels. Is that true? Plenty of people are using multi-arch images (x86 and aarch64) which are essentially the Docker image equivalent of a fat binary. I might be wrong, but I think what I want are preconfigured macOS binaries packaged up a convenient image format with a layered filesystem, networking support, etc. Ideally with an equivalent linux image such that I can later switch the OS specifier and get an image containing an equivalent linux binary to run on linux. I am for example quite happy to run a macOS native version of Postgres. But that doesn't give me the easy disposable database for testing that a docker-compose setup gives me. If I could specify that I want the "postgres" docker image in my docker-compose file, and running that file on macOS ran a macOS version of postgres in a macOS-native container then I'd be very happy.
        oneplane 4y ago
        I think it's more than just multi-arch, it's also multi-OS (i.e. if we take Windows and BSD into account too we'd get 8 image types required for just 4 operating systems and 2 architectures if kept 'simple'). Packaging (including fat binaries but also byte code self-unpackers) has tried to make this possible for decades but it just won't stick. Take Debian or RedHat packages for example, there have been tools and repositories for very long times that were meant to make a universal method of distributing pre-packaged (and natively also chrootable/jailable) software for a multitude of architectures and operating systems possible, but package authors just didn't really want to do the work for what is essentially not something they wanted themselves. Building software for 1 or 2 major release versions within a single operating system is hard enough, tacking on extra systems is usually a step too far. The closest we got (and it still exists) is autotools, but that's just build tooling. It does however make it possible to build software from a single source for many targets and check for all the required features ahead of time. But this is so close to developing the software itself that it's not really compatible with the influx of end-user-style developers that expect pre-packaged 'commercial grade' software, which is essentially what Docker and OCI and Containers are. The only 'new' thing so far has been cgroupsv2, the v1 version and everything else (distribution, sandboxing, capabilities, separate user land etc) has been done for over three decades. But again, using it means knowing how to use chroot, cap, tun and jail for example, and not everyone wants to learn that much. So we get things like docker, which under the hood does exactly that, plus some union filesystem magic to make it cheaper/faster for registries to store data; essentially a re-implementation of dynamic linking and shared libraries, but for files. So now we have created an interface (docker) that is easy to adopt, easy to promote and easy to use, but it's hard-wired into Linux (the kernel) and only much later (post-OCI) got some hacked up windows version that is completely different and doesn't work anywhere else (because, well duh, not-windows isn't going to run windows apps). Aside from the fact that it's an OCI artefact, windows containers have very little to do with docker containers as we know them. Most of this stuff also didn't really come from a need to get containers on windows (or macOS) but from the need to get more 'developer light edition' into the workforce, which can be trained and onboarded faster. If you can get people to ignore the foundation they stand on, they can be put to work in building upwards much sooner. This does of course come to bite everyone in the ass at some point, because if you're standing on top some 'magic' infrastructure and something breaks, it's going to be really hard to fix it. Right now we're all trying to make it redundant enough so we can ignore the breakage, but I doubt this is a winnable race. Docker is a convenience, not a technical solution to a technical problem.
jonwinstanley 4y ago
What are the issues you see? My team all use Docker with M1 Macs and all seems to work fine, if a little slow.
- geethree 4y ago
  My experience: it’s fine when using docker to run applications; painfully slow for a containerized development environments that want to share the file system with the host. Lots to do to combat this, like: not sharing the volume with the host (vscode dev containers recommends this)
- spamizbad 4y ago
  It's always the shared volumes that kill you. Especially for I/O intensive stuff like npm and webpack builds. With that said if you're doing mostly backend stuff in Go/Python/Ruby etc it's quite good. Most of my complaints are from full-stack development.
  - yolo3000 4y ago
    Why do you use docker to build local stuff?
    - ytjohn 4y ago
      Our team has pipelines that builds, runs, and tests our code in containers. We like to approximate this locally with docker compose. This helps eliminate things like forgetting to update pyproject.toml. Additionally, since the pipeline uses an internal artifactory/harbor (no external Internet), the containers we use have environment variables using the internal resources.
    - spamizbad 4y ago
      Good question: we actually decided to just not do this for local "statics". But having everything containerized makes it easier to attach editor contexts, work in the same environment as your CI/CD system etc. The other upside of being fully containerized - even for FE stuff - is that you side-step having to worry about having any sort of "local" dev environment configured beyond Docker/Podman/etc and some environment variables set. It makes onboarding new developers a breeze and eliminates "Weird, works locally on my machine!" types of issues.

nicoburns 4y ago

> and it isn’t Apple’s fault Eh, yes it is. Apple doesn't provide a containerisation API for their OS, which means Docker is forced to run non-natively!

oneplane 4y ago
Eh, no it isn't. apple does have a public container API but the problem is you still can't run Linux binaries on macOS no matter how many containers you put them in. Containers on macOS don't use OCI images or anything like that, but scoped and grouped access to system resources with a separate user land that 'looks' like a full OS has been available for over 5 years. Even without that, XNU has plenty of facilities for it, and even if it didn't you'd still be able to use Launchd environments (which are more akin to LXC). Docker relies on specific implementation details of the Linux kernel. It always has. That is why you always need a Linux OS somewhere to run the containers.
- eptcyka 4y ago
  There is an OCI implementation for Windows which allows for Windows native containers. So docker can run on non-linux systems just fine, it's just that nobody cares. People use docker to package Linux applications, not because of some inate dockerness.
  - oneplane 4y ago
    OCI images yes, but that doesn't make them the same. OCI can be used to store many things, and those non-Linux OCI images will not run on Linux. Does that mean that it is Linux at fault for not running arbitrary formats from OCI images? No. This applies everywhere; if you build for a specific target and package it up, not using that target when trying to run it is a PEBCAK. Example: there are artefacts you can store as OCI images that contain Mach-O binaries, and Windows and Linux won't really run those. You can even still PPC code in those binaries, and link to Cocoa frameworks. This means that the OS and architecture you are targeting will not be Windows or Linux, and that is not their fault.
    - eptcyka 4y ago
      In just pointing out that people are saying they want "docker" to work fine on non-Linux platforms but really, they want to run Linux binaries on non-linux kernels.
      - nicoburns 4y ago
        > In just pointing out that people are saying they want "docker" to work fine on non-Linux platforms but really, they want to run Linux binaries on non-linux kernels. Is that true? Plenty of people are using multi-arch images (x86 and aarch64) which are essentially the Docker image equivalent of a fat binary. I might be wrong, but I think what I want are preconfigured macOS binaries packaged up a convenient image format with a layered filesystem, networking support, etc. Ideally with an equivalent linux image such that I can later switch the OS specifier and get an image containing an equivalent linux binary to run on linux. I am for example quite happy to run a macOS native version of Postgres. But that doesn't give me the easy disposable database for testing that a docker-compose setup gives me. If I could specify that I want the "postgres" docker image in my docker-compose file, and running that file on macOS ran a macOS version of postgres in a macOS-native container then I'd be very happy.
        oneplane 4y ago
        I think it's more than just multi-arch, it's also multi-OS (i.e. if we take Windows and BSD into account too we'd get 8 image types required for just 4 operating systems and 2 architectures if kept 'simple'). Packaging (including fat binaries but also byte code self-unpackers) has tried to make this possible for decades but it just won't stick. Take Debian or RedHat packages for example, there have been tools and repositories for very long times that were meant to make a universal method of distributing pre-packaged (and natively also chrootable/jailable) software for a multitude of architectures and operating systems possible, but package authors just didn't really want to do the work for what is essentially not something they wanted themselves. Building software for 1 or 2 major release versions within a single operating system is hard enough, tacking on extra systems is usually a step too far. The closest we got (and it still exists) is autotools, but that's just build tooling. It does however make it possible to build software from a single source for many targets and check for all the required features ahead of time. But this is so close to developing the software itself that it's not really compatible with the influx of end-user-style developers that expect pre-packaged 'commercial grade' software, which is essentially what Docker and OCI and Containers are. The only 'new' thing so far has been cgroupsv2, the v1 version and everything else (distribution, sandboxing, capabilities, separate user land etc) has been done for over three decades. But again, using it means knowing how to use chroot, cap, tun and jail for example, and not everyone wants to learn that much. So we get things like docker, which under the hood does exactly that, plus some union filesystem magic to make it cheaper/faster for registries to store data; essentially a re-implementation of dynamic linking and shared libraries, but for files. So now we have created an interface (docker) that is easy to adopt, easy to promote and easy to use, but it's hard-wired into Linux (the kernel) and only much later (post-OCI) got some hacked up windows version that is completely different and doesn't work anywhere else (because, well duh, not-windows isn't going to run windows apps). Aside from the fact that it's an OCI artefact, windows containers have very little to do with docker containers as we know them. Most of this stuff also didn't really come from a need to get containers on windows (or macOS) but from the need to get more 'developer light edition' into the workforce, which can be trained and onboarded faster. If you can get people to ignore the foundation they stand on, they can be put to work in building upwards much sooner. This does of course come to bite everyone in the ass at some point, because if you're standing on top some 'magic' infrastructure and something breaks, it's going to be really hard to fix it. Right now we're all trying to make it redundant enough so we can ignore the breakage, but I doubt this is a winnable race. Docker is a convenience, not a technical solution to a technical problem.

jonwinstanley 4y ago

What are the issues you see? My team all use Docker with M1 Macs and all seems to work fine, if a little slow.

geethree 4y ago
My experience: it’s fine when using docker to run applications; painfully slow for a containerized development environments that want to share the file system with the host. Lots to do to combat this, like: not sharing the volume with the host (vscode dev containers recommends this)
spamizbad 4y ago
It's always the shared volumes that kill you. Especially for I/O intensive stuff like npm and webpack builds. With that said if you're doing mostly backend stuff in Go/Python/Ruby etc it's quite good. Most of my complaints are from full-stack development.
- yolo3000 4y ago
  Why do you use docker to build local stuff?
  - ytjohn 4y ago
    Our team has pipelines that builds, runs, and tests our code in containers. We like to approximate this locally with docker compose. This helps eliminate things like forgetting to update pyproject.toml. Additionally, since the pipeline uses an internal artifactory/harbor (no external Internet), the containers we use have environment variables using the internal resources.
  - spamizbad 4y ago
    Good question: we actually decided to just not do this for local "statics". But having everything containerized makes it easier to attach editor contexts, work in the same environment as your CI/CD system etc. The other upside of being fully containerized - even for FE stuff - is that you side-step having to worry about having any sort of "local" dev environment configured beyond Docker/Podman/etc and some environment variables set. It makes onboarding new developers a breeze and eliminates "Weird, works locally on my machine!" types of issues.