111–120 of 293 posts
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 reason the have them sandboxed personally.
Docker is intimately tied to Linux. It it only "cross platform" in that it can use a VM (Mac, WSL2) or flaky compat layers (FreeBSD). If software embraces Docker, it effectively excludes other OSes, like Windows, BSDs, Haiku, Fuschia, etc.
And even then trying to run Docker on Fedora will prompt you to turn off Security-Enhanced Linux features or use Podman instead. So it’s really like, what, 1/2 or 2/3 or Linux support
Earlier quoted context omitted.
I am so glad I can read something like this in public. When I say stuff like this in job interviews, I get eye rolls and don't end up getting a job. The industry is so far up its ass lately, no one even dare stating the facts in public. /rant
Now talk about deploying something NOT using Kubernetes. The double whammy. Now you're looking like an insane 100 year old graybeard fossil.
Earlier quoted context omitted.
Absolutely. Most Dockerfiles I come across are very much not written in a robustly reproducible way. The stacking filesystems model is really not very flexible (if you want to compose two docker images with dissimilar bases to be used together you have to resort to manually specifying which files to copy across from each base). Use of OS features to achieve its ends means the docker daemon itself requires far more pr…
Yeah, any Docker file that starts with `apt update; apt dist-upgrade` is an instant fail. You might be interested in this fascinating exploration of attempting to bend Docker into better caching and composition by injecting blocks of Nix packages as individual layers: https://grahamc.com/blog/nix-and-layered-docker-images
The thing the upstream Linux distributions are missing are a lockfile with the hashes of installed packages. Programming languages figured this out (go.sum, package-lock.json, etc.) but distributions have not. Thus, people are often running "whatever" in production, because they simply don't have the ability to lock dependencies properly.
I assume Nix solves this problem, and people should pay attention to how important it actually is.
In my opinion, this is a big enough issue as to throw the whole idea of “Docker as cross-platform platform/target” into major question.
When running more than a few containers on macOS, the performance is so bad it becomes almost unusable.
Earlier quoted context omitted.
Now talk about deploying something NOT using Kubernetes. The double whammy. Now you're looking like an insane 100 year old graybeard fossil.
Or overuse of microservices
The next time I have to copy/paste the same utility to a new microservice because [insert corporate reason] I’m going to scream.
For end user devices, I much prefer Nix/NixOS [1] for this kind of thing. With Flakes [2] (experimental feature), you get full reproducibility. The documentation is spotty and there is a considerable learning curve, but I've switched to NixOS on my laptop and desktop early this year and am mostly very happy with it. That doesn't cover sandboxing though. I would actually agree that sandboxing / restricting application…
Absolutely. Most Dockerfiles I come across are very much not written in a robustly reproducible way. The stacking filesystems model is really not very flexible (if you want to compose two docker images with dissimilar bases to be used together you have to resort to manually specifying which files to copy across from each base). Use of OS features to achieve its ends means the docker daemon itself requires far more pr…
Are solutions like source2image, jib, or the nix dockerTools.buildImage method gaining steam?
I wish there were real / usable Windows containers out there. I'd love to spin up a quick sandbox to run a MSVC / MSBuild, but the smallest "image" in Windows-land for that is 12Gb. Still use Docker alongside WSL2 for purely-Linux stuff like some node.js scripts or python things that don't need GPU.