6 ms·
It wasn't about making apps difficult to distribute at all, that's a later side effect. Originally distros were built around making a coherent unified system of
by antod 1y ago
It wasn't about making apps difficult to distribute at all, that's a later side effect. Originally distros were built around making a coherent unified system of package management that made it easier to manage a system due to everything being built on the same base. Back then Linux users were sysadmins and/or C programmers managing (very few) code dependencies via tarballs. With some CPAN around too.
For a sysadmin, distros like Debian were an innovative godsend for installing and patching stuff. Especially compared to the hell that was Windows server sysadmin back in the 90s.
The developer oriented language ecosystem dependency explosion was a more recent thing. When the core distros started, apps were distributed as tarballs of source code. The distros were the next step in distribution - hence the name.
- IshKebab 1y agoRight but those things are not unrelated. Back in the day if you suggested to the average FOSS developer that maybe it should just be possible to download a zip of binaries, unzip it anywhere and run it with no extra effort (like on Windows), they would say that that is actively bad. You should be installing it from a distro package!! What about security updates of dependencies?? And so on. Docker basically overrules these impractical ideas.
- graemep 1y agoI would say those are good point, not impractical ideas. You make software harder to distribute (so inconvenient for developers and distributors) but gain better security updates and lower resource usage.
- IshKebab 1y agoThe success of Docker shows that this is a minority view.
- graemep 1y agoI was replying to a comment comparing the distribution of self-contained binaries to Linux package management. This is a much more straightforward question Containers are a related (as the GP comment says) thing, but offer a different and varied set of tradeoffs. Those tradeoffs also depend on what you are using containers for. Scaling by deploying large numbers of containers on a cloud providers? Applications with bundled dependencies on the same physical server? As a way of providing a uniform development environment?
- IshKebab 1y ago> Those tradeoffs also depend on what you are using containers for. Scaling by deploying large numbers of containers on a cloud providers? Applications with bundled dependencies on the same physical server? As a way of providing a uniform development environment? Those are all pretty much the same thing. I want to distribute programs and have them work reliably. Think about how they would work if Linux apps were portable as standard: > Scaling by deploying large numbers of containers on a cloud providers? You would just rsync your deployment and run it. > Applications with bundled dependencies on the same physical server? Just unzip each app in its own folder. > As a way of providing a uniform development environment? Just provide a zip with all the required development tools.
- graemep 1y ago> Those are all pretty much the same thing. I want to distribute programs and have them work reliably. Yes, they are very similar in someways, but the tradeoffs (compared to using containers) would be very different. > You would just rsync your deployment and run it. If you are scaling horizontally and not using containers you are already probably automating provisioning and maintenance of VMs, so you can just use the same tools to automate deployment. You would also be running one application per VM so you do not need to worry about portability. > Just unzip each app in its own folder. What is stopping people from doing this? You can use an existing system like Appimage, or write a windows like installer (Komodo used to have one). The main barrier as far as I can see is that users do not like it. > Just provide a zip with all the required development tools. vs a container you still have to configure it and isolation can be nice to have in a development environment. vs installing what you need with a package manager, it would be less hassle in some cases but this is a problem that is largely solved by things like language package managers.
- skydhash 1y agoIt’s still actively bad. And security updates for dependencies is easy to do when the dependencies developer is not bundling those with feature changes and actively breaking the API.
- man8alexd 1y agoDocker was the tool for those who couldn't create a deb or rpm package.
- pjmlp 1y agoIf only handling Dockerfiles were as easy.
- man8alexd 1y ago"Dockerfile is simple", they promised. Now look at the CNCF landscape.
- pjmlp 1y agoI stopped listening to cloud related podcasts, because it started to feel like it was just PR for whatever product the guest came up with.
- theamk 1y agowhy would you do this? If you are considering bare-metal servers with deb files, you compare them to bare-metal servers with docker containers. And in the latter case, you immediately get all the compatibility, reproducibility, ease of deployment, ease of testing, etc... and there is no need for a single YAML file.
- man8alexd 1y agoIf you need a reliable deployment without catching 500 errors from Docker Hub, then you need a local registry. If you need a secure system without accumulating tons of CVEs in your base images, then you need to rebuild your images regularly, so you need a build pipeline. To reliably automate image updates, you need an orchestrator or switch to podman with `podman auto-update` because Docker can't replace a container with a new image in place. To keep your service running, you again need an orchestrator because Docker somehow occasionally fails to start containers even with --restart=always. If you need dependencies between services, you need at least Docker Compose and YAML or a full orchestrator, or wrap each service in a systemd unit and switch all restart policies to systemd. And you need a log collection service because the default Docker driver sucks and blocks on log writes or drops messages otherwise. This is just the minimum for production use.