3 ms·
I think the author raises some excellent points, but it still feels somehow wasteful to me.
by ohCh6zos 5y ago
I think the author raises some excellent points, but it still feels somehow wasteful to me.
- closeparen 5y agoI think the opaque and esoteric nature of packaging, which makes is so damn hard to build packages like this, actually prompts incredible amounts of waste when companies need to deploy their own code on their own machines. You get ridiculously overpowered solutions - container schedulers and the like - when all that was really wanted was binary packaging + init scripts or service units.
- brimble 5y agoI'm in the camp that uses Docker almost entirely as a cross-platform (cross-distro, at the very least), very clean (i.e. everything ends up in one place and the location of all data & config is very well documented and easily configured in a standard way for pretty much all packages) package manager. I could probably get similar benefits from learning, say, dpkg and systemd really, really well... but then that'd only work on dpkg-using Linux distros. Meanwhile, docker commands, docker-based shell scripts, and docker-compose files work just about identically ~everywhere, and can even work nearly-transparently on systems that don't actually support linux containers, like macOS and Windows, via virtualization and some command shims. I hardly even care that it uses containers. The parts of it I like don't actually require that—though they do encourage people packaging for Docker to document things well and to cut through a certain amount of various packages' config bullshit. Take Samba—it's like 100x easier to configure & manage for common use cases using Docker than most distros' default packages & config files. There's no actual reason that needs to be the case, it's just that the process of containerizing it brought that as a side-effect, but that's one of the main reasons I'm using Docker, not the containerization per se.
- ComradePhil 5y agoI really wish Microsoft doesn't discontinue wsl1 and instead develops it further to make it the "Wine" equivalent (for running Linux apps on Windows without emulation or virtualization). Wsl2 relies on a hypervisor (i.e. it has to run a Linux VM underneath) so running docker apps on Windows comes with all kinds of problems from poor performance to file permissions being messed up. A mature wsl1 would be able to run almost any Linux app on Windows natively.