Containers can be based on operating systems that are different to your computer.
Containers utilise the host’s kernel - which is why there needs to be some hoops to run Linux container on Windows (VM/WSL).
That’s one of the most key differences between VMs and containers. VMs virtualise all the hardware, so you can have a totally different guest and host operating systems; whereas because a container is using the host kernel, it must use the same kind of operating system and accesses the host’s hardware through the kernel.
The big advantage of that approach, over VMs, is that containers are much more lightweight and performant because they don’t have a virtual kernel/hardware/etc. I find its best to think of them as a process wrapper, kind of like chroot for a specific application - you’re just giving the application you’re running a box to run in - but the host OS is still doing the heavy lifting.
Interesting. Thanks both for the replies. I do run Plex, Sonaar, Radaar, etc but I just have them all installed in a straightforward way on a windows pc. If I’m okay with the software (not just trying it out) am I missing out by not using dockers?
not really no. Docker can make it easier to set up weird network configurations or in some cases make updating things easier but if what you have is working and fits your needs there’s not really anything you’re missing out on.
In a weird way, for most people Docker is just used to compensate for problems that Windows used to have but doesn’t really anymore. Often on Linux when you install something it gets dumped into a shared prefix like /usr or /usr/local or has dependencies on libraries that are installed into /lib or /usr/lib or /usr/local/lib. If the libraries are versioned correctly, it’s usually not a big problem that the applications are sharing components, but sometimes shared files conflict with each other and you end up with something similar to the old Windows DLL hell, especially if applications are not officially packaged for the distro you’re running. Using a container image avoids this because only the correct libraries and support files are in the image, and they’re in a separate location so they can easily be swapped without impacting other applications that might be using similar files.
However, on Windows these days it’s highly discouraged for programs to install things into common directories like that. Usually when you install an application it installs everything it needs into its own directory. For the things that Microsoft puts into shared directories, there’s a system called SXS that’s supposed to prevent conflicts with incompatible versions. It’s not perfect because there are still cases where you can get interactions, but it’s pretty uncommon now.
That’s a good point. I run all my server type apps on FreeBSD which avoids dependency issues by versioning things that aren’t compatible. for instance you can install php7.4 or 8.1 as packages php74/php81 and different things that require those are compiled to look for the right library. I kinda wish linux would consider the same thing but idk if individual distro maintainers would want that kind of extra work
If I’m okay with the software (not just trying it out) am I missing out by not using dockers?
No, I think in your use case you’re good. A lot of the key features of containers, such as immutability, reproduceability, scaling, portability, etc. don’t really apply to your use case.
If you reach a point where you find you want a stand-alone linux server, or an auto-reconfiguring reverse proxy to map domains to your services, or something like that - then it starts to have some additional benefit and I’d recommend it.
In fact, using native builds of this software on Windows is probably much more performant.
Containers utilise the host’s kernel - which is why there needs to be some hoops to run Linux container on Windows (VM/WSL).
That’s one of the most key differences between VMs and containers. VMs virtualise all the hardware, so you can have a totally different guest and host operating systems; whereas because a container is using the host kernel, it must use the same kind of operating system and accesses the host’s hardware through the kernel.
The big advantage of that approach, over VMs, is that containers are much more lightweight and performant because they don’t have a virtual kernel/hardware/etc. I find its best to think of them as a process wrapper, kind of like chroot for a specific application - you’re just giving the application you’re running a box to run in - but the host OS is still doing the heavy lifting.
Interesting. Thanks both for the replies. I do run Plex, Sonaar, Radaar, etc but I just have them all installed in a straightforward way on a windows pc. If I’m okay with the software (not just trying it out) am I missing out by not using dockers?
not really no. Docker can make it easier to set up weird network configurations or in some cases make updating things easier but if what you have is working and fits your needs there’s not really anything you’re missing out on.
In a weird way, for most people Docker is just used to compensate for problems that Windows used to have but doesn’t really anymore. Often on Linux when you install something it gets dumped into a shared prefix like
/usror/usr/localor has dependencies on libraries that are installed into/libor/usr/libor/usr/local/lib. If the libraries are versioned correctly, it’s usually not a big problem that the applications are sharing components, but sometimes shared files conflict with each other and you end up with something similar to the old Windows DLL hell, especially if applications are not officially packaged for the distro you’re running. Using a container image avoids this because only the correct libraries and support files are in the image, and they’re in a separate location so they can easily be swapped without impacting other applications that might be using similar files.However, on Windows these days it’s highly discouraged for programs to install things into common directories like that. Usually when you install an application it installs everything it needs into its own directory. For the things that Microsoft puts into shared directories, there’s a system called SXS that’s supposed to prevent conflicts with incompatible versions. It’s not perfect because there are still cases where you can get interactions, but it’s pretty uncommon now.
That’s a good point. I run all my server type apps on FreeBSD which avoids dependency issues by versioning things that aren’t compatible. for instance you can install php7.4 or 8.1 as packages php74/php81 and different things that require those are compiled to look for the right library. I kinda wish linux would consider the same thing but idk if individual distro maintainers would want that kind of extra work
No, I think in your use case you’re good. A lot of the key features of containers, such as immutability, reproduceability, scaling, portability, etc. don’t really apply to your use case.
If you reach a point where you find you want a stand-alone linux server, or an auto-reconfiguring reverse proxy to map domains to your services, or something like that - then it starts to have some additional benefit and I’d recommend it.
In fact, using native builds of this software on Windows is probably much more performant.
Funnily enough containers are fundamentally apparmor+ a chroot under the hood
Funnily enough containers are fundamentally apparmor+ a chroot under the hood