4 ms·

> It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. No it wouldn't. Dockerfiles are stupid si

> It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Plus, find me a modern build system (CI/CD system, rather) that doesn't natively support Docker. It's become a lingua franca at this point. I just wish it was faster on its own without me having to do all the legwork of maintaining lower layer containers etc. to avoid lengthy package install times.

com2kid 6y ago
I had a problem yesterday where I had so many docket images laying around from builds that starting a new container pegged my CPU at 100% and slowed everything in a docker container to a crawl. A colleague predicted the problem and I learned about one more bit of random fragility that exists in today's ecosystem.
- rumanator 6y ago
  > I had a problem yesterday where I had so many docket images laying around from builds $ Docker system prune It makes as much sense to complain about Docker because you let images accumulate in your system as it would make to criticize file systems because you never emptied your system's trash bin.
  - com2kid 6y ago
    My file system doesn't peg my CPU when it gets 10% full. Why the hell should the very existance of unused docker images cause the single image I am using to peg multiple cores? And no warning was given. Heck if my hard drive gets close enough to full that it's gonna be a problem my OS tells me.
ori_b 6y ago
> No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Yes. And the code sitting beside them starts to make assumptions -- so when I try to port it to Android so that I can run it under the NDK, for example, it turns into a shitshow because I discover that the code depends on the quirks of the docker environment, and I need to untangle a whole bunch of issues to just get it to build on anywhere. Containers -- dockers, jails, zones, etc -- are useful tools, but I'd rather see them left up to the people doing deployment, rather than the people shipping libraries. As a library author, I don't know where people want to run my code, so I serve them better by keeping the code portable.

com2kid 6y ago

I had a problem yesterday where I had so many docket images laying around from builds that starting a new container pegged my CPU at 100% and slowed everything in a docker container to a crawl. A colleague predicted the problem and I learned about one more bit of random fragility that exists in today's ecosystem.

rumanator 6y ago
> I had a problem yesterday where I had so many docket images laying around from builds $ Docker system prune It makes as much sense to complain about Docker because you let images accumulate in your system as it would make to criticize file systems because you never emptied your system's trash bin.
- com2kid 6y ago
  My file system doesn't peg my CPU when it gets 10% full. Why the hell should the very existance of unused docker images cause the single image I am using to peg multiple cores? And no warning was given. Heck if my hard drive gets close enough to full that it's gonna be a problem my OS tells me.

ori_b 6y ago

> No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Yes. And the code sitting beside them starts to make assumptions -- so when I try to port it to Android so that I can run it under the NDK, for example, it turns into a shitshow because I discover that the code depends on the quirks of the docker environment, and I need to untangle a whole bunch of issues to just get it to build on anywhere. Containers -- dockers, jails, zones, etc -- are useful tools, but I'd rather see them left up to the people doing deployment, rather than the people shipping libraries. As a library author, I don't know where people want to run my code, so I serve them better by keeping the code portable.