linux containers, be it a lxd container, or a containerd/dockerd one, only run on linux hosts.
windows containers, only run on windows hosts.
when you run a linux container on a windows host, you're actually running a linux container inside of a linux vm on top of a windows host.
containers share the host operating system's kernel. it is impossible for a linux container (which is just a linux process) to execute and share the windows kernel. the reverse is true, a windows container (which is just a process) cannot execute and share the linux kernel
the article is correct, linux containers can only execute on a linux host
Except if you have a kernel that has multiple personalities, so it can implement different OS interfaces like the NT kernel implementing both Win32 and Linux.
The NT kernel does not operate like that, at least not anymore...
The NT kernel originally had Microsoft POSIX subsystem[0], which was discontinued and replaced with Windows Services for UNIX[1], which was then replaced with Windows Subsystem for Linux[2]. WSL has had two versions;
WSL 1 implemented a subset of linux syscalls directly in the windows kernel. This was discontinued and replaced with WSL 2
WSL 2 is running, you guessed it, a linux VM[3]
> The original version, WSL 1, differs significantly from the second major version, WSL 2. WSL 1 (released August 2, 2016), acted as a compatibility layer for running Linux binary executables (in ELF format) by implementing Linux system calls in the Windows kernel. WSL 2 (announced May 2019), introduced a real Linux kernel – a managed virtual machine (via Hyper-V) that implements the full Linux kernel. As a result, WSL 2 is compatible with more Linux binaries as not all system calls were implemented in WSL 1.
> Version 2 introduces changes in the architecture. Microsoft has opted for virtualization through a highly optimized subset of Hyper-V features, in order to run the kernel and distributions
> The distribution installation resides inside an ext4-formatted filesystem inside a virtual disk, and the host file system is transparently accessible through the 9P protocol
When you run linux containers on a windows host, you're running those containers inside of a linux vm.
WSL2 is not intended to supersede WSL1 but to coexist. Was you argument that the NT kernel doesn't do it since WSL1, or that it doesn't do it in WSL1? Only the later would lead to: "The NT kernel does not operate like that, at least not anymore...".
Which just validates my point that a generic-sounding domain is the wrong place to host content that even within the Linux ecosystem is a relatively minor player.
Not only is this project website older than Docker, early versions of Docker literally used LXC as the backend, which was supported in Docker for the first two years of its life.
The Docker folks could have done their work under this umbrella and (maybe for good reasons) chose not to. For later container runtimes, idk the story.
But this project/community definitely laid the groundwork for all of those later Linux container runtimes.
lxc is used really frequently in the home space (jellyfin/plex for instance). A lot of Proxmox use cases as well which is growing in popularity extremely rapidly.
Like that matters to consumers? Regardless of who invented sodas, the market has changed and people connect more brands to the kind of drink now, so equating Pepsi to Soda is factually incorrect.
LXC far predates docker regardless of size or impact. It's not disingenuous if you were literally the foundation docker was able to package into a shiny accessible tool.
"Can only host Linux" -- Windows Containers are a thing too: https://learn.microsoft.com/en-us/virtualization/windowscont...
"Can host a single app" -- not true either. It's just bad practice to host multiple apps in a single container, but it's definitely possible.
IMHO it's not very nice to use the generic-sounding "linuxcontainers.org" domain exclusively for LXC-related content there.