> slight startup delay
On a mac this is a complete deal breaker for anything you need to run frequently. It is more than slight.
Run More Stuff in Docker
251–260 of 293 posts
Re: Run More Stuff in Docker
#252This reminded me of a proof of concept thing I wrote months ago, that facilitates this kind of work.
https://github.com/casidiablo/macondo
I don't even know what it is I built, but it has been useful in some contexts.
It basically allows you to easily wrap and distribute scripts (or more complex apps) that have specific dependencies that might not always be installed in the host. It does so by wrapping the script in a docker image.
It also automates the annoying part of docker: mounting local paths for apps that need to interact with the host's file system.
I need to write a blog post on this if anything to gather feedback. I'm still not 100% sold on the idea and there are some edge cases. Still, a fun experiment.
Re: Run More Stuff in Docker
#253Earlier quoted context omitted.
> curl | jq | grep | less OK I didn’t know about this. Does each one of the piped commands cause the creation of a new container? And why?
Assuming you've bound an alias to these commands to run them individually, each in their own container
Thank you. Why on earth would one wish to bind these commands to their own containers? Or was that just a trivial example for illustrative purposes that I’m obsessing over?
Re: Run More Stuff in Docker
#254Earlier quoted context omitted.
Whats the alternative?
Fix the dependencies story in what concerns Ruby and Python. Native binaries can easily do with static linking (fix glibc or replace it with proper libc like musl). Other platforms are doing quite fine without containers.
I kind of agree with you.
But in the Linux world no one has the intention to fix the package distribution problem except for that AppImage guy.
Re: Run More Stuff in Docker
#255Ugh at work the edit-compile-run loop only needs to be ~1 second (it's a fairly small go project), but our build system uses docker for everything, so now it's ~1 minute a 60x increase to pay for the constant costs associated with docker.
Docker has tradeoffs.
Re: Run More Stuff in Docker
#256Earlier quoted context omitted.
I've examined this a number of times over the years for deploying a ROS (Robot Operating System) workspace to robots and laptops. Some of our competitors use snaps or various container technologies for this, but I've always felt that the isolation/sandboxing would be more of a barrier than a help— it's one more layer of udev rules and other indirection to have to punch through with another set of config files (and to…
I also suspect OS package managers are underused when it comes to deployments. I am guilty of that too, some irrational wariness of end-user tools being fit to deal with developer workflows. That aside, there is one slight possible pitfall in discarding one tech because it is less mature than the other: if we assume maturity only increases with time, the oldest product (e.g. apt/dkpg) will always be “best”. Made a no…
I think for apt/dpkg, the system definitely does benefit from decades of careful, thoughtful design— for example you're pretty unlikely to come up with a version constraint between your packages which isn't expressible using the existing Debian scheme. And when I look at various modernish packaging systems, I often see a lot of this thrown out as unneeded complexity, only to be cobbled back in later when it's discovered how essential it really is (see for example Homebrew's long transition from being a dirt simple wrapper around "configure; make; make install" to becoming a full binary package manager).
There's also the ecosystem benefit of having loads of helpers and supplementary tooling applicable to the formats— even stuff like having first-class support in proprietary binary stores like Artifactory, vs Nix where it's basically a shrug and "well... it works with any WebDAV server, so take your pick I guess?"
The main complaint I have overall with Apt is the reliance on postinstall scripts, which means that even if you download and extract your packages in parallelized blocks, you still have a long serialized step when every single package needs to spawn a shell and run arbitrary commands, even if in most cases, the commands actually originate from a semi-declarative format (debhelpers, either invoked explicitly from the rules file, or implicitly by the presence of a corresponding debian/xyz file in the metadata). Anyway, if it were possible to somehow flag packages as atomic or configure-less, it might be possible to significantly speed up these operations, especially in environments like CI where you have everything mirrored in-network or possibly even on-machine so the overall install time is dominated by the package configure step.
Re: Run More Stuff in Docker
#257I find that the time taken to get everything working means I have less time to get work done. The busywork does give me a sense of achievement, but that is not the achievement that matters. It's premature optimization to sandbox an application by default unless there is a pressing reason to do so. For e.g. zoom and hugo don't really change the filesystem or OS settings beyond the folders they output to. I don't see a…
Isn’t that precisely a use case for sand boxing? If I know zoom doesn’t need file system, I can deny it access and guarantee it doesn’t use the file system without me knowing about it.
If you don't trust an application, sandboxing is one way to go. But that goes all the way down. If you don't trust docker and the OS, run them in a VM. If you don't trust the VM, run it on a spare computer. If you don't trust that computer's hardware, then use minecraft to make a PC with your own instruction set :) Same with networking. Use HTTPS. No? Also use a VPN. No? Make your own VPN. No? Use smoke signals with one-time pad encryption..
In the end you decide at what point are you willing to delegate responsibility for things working as they say they should.
Re: Run More Stuff in Docker
#258Earlier quoted context omitted.
The problem isn't 500 MB disk footprint, it's all the RAM memory going to waste when loading in redundant libraries. Chrome already is a memory hog on its own, imagine all applications suddenly bringing in their versions of their libraries.
RAM is the same situation as disk for me — I have plenty to waste. Again, not advocating Chrome in a container, I don’t even run Chrome outside of a container. I just think it’s odd to get hung up on these sorts of resource requirements given the state of computing.
You may have plenty of resources but there are many that have to "make due" with 8 GB, 4 GB or even less RAM.
Re: Run More Stuff in Docker
#259Earlier quoted context omitted.
Docker needs Linux to work. On Mac/Windows containers run in a Linux virtual machine.
I thought so too, but apparently support for native Windows containers has existed for a while now. e.g. https://poweruser.blog/lightweight-windows-containers-using-...
Neat! I had no idea this was a thing, thanks for sharing.
Re: Run More Stuff in Docker
#260Earlier quoted context omitted.
Totally agree that Docker is made for deploying to servers. But the disk space critique doesn’t hit for me. Even very nice SSD’s are cheap enough that 500 MB is negligible. My internet connection also makes downloading a large docker image no bigger of a deal than downloading Chrome, YMMV. I think the necessity of a VM when using Docker on Mac and Windows is the primary reason that running your “normal” apps in a con…
> Even very nice SSD’s are cheap enough that 500 MB is negligible. However a nice SSD with a respectable TBW value is not still cheap. a 860 Pro is almost twice the cost of a 860 Evo. Pro provides twice the TBW value. > My internet connection also makes downloading a large docker image no bigger of a deal than downloading Chrome, YMMV. Not everyone of us has pipes that fat to our homes which provide sub 10ms pings an…
> However a nice SSD with a respectable TBW value is not still cheap. a 860 Pro is almost twice the cost of a 860 Evo. Pro provides twice the TBW value.
TBW is almost never a concern for desktop users. The Evo has 600 TBW endurance per TB of storage, that would be a full disk rewrite every day for two years.
You will never download enough Docker images for personal use to burn out your 860 Evo before you would have replaced it anyway. (For those unfamiliar with Docker, spinning up a 500MB image ten times doesn't write 5GB to disk!)