4 ms·

> If you're virtualizing with qemu anyway then why containerize? You're exactly right. Docker does pretty much almost nothing here For real, dockerizing stuff

> If you're virtualizing with qemu anyway then why containerize? You're exactly right. Docker does pretty much almost nothing here For real, dockerizing stuff has become a meme lately What it (actually) does it simplifying dependencies. But you know, most of the time if you can run docker you can install stuff locally Docker has a significant performance penalty unless you're running Linux already

cmm 4y ago
dockerfiles (or even better but less popular, {default,shell,flake}.nix) are code that can be tracked in a repository and reasoned about, "stuff installed locally" isn't.
- encryptluks2 4y ago
  I don't see how Nix is better than Docker as they serve different purposes. While I agree using containers helps aid in automating build environments, you can also checkin shell scripts and Ansible roles into repos as well. I understand the criticism and hopefully people aren't going to be so thin-skinned to take offense, but at the same time if it works then it works.
  - Strum355 4y ago
    Nix and Docker share the same purpose in this context: declaring the dependencies needed for this environment. This can include shell scripts, system-level dependencies etc. If anything I would say Nix would be better here (logical middleground in filesystem separation between having access only to whats in the container vs having to juggle system-level dependency versions for the entire system), while also having better version pinning.
  - pxc 4y ago
    > I don't see how Nix is better than Docker as they serve different purposes Nix can build many things, among them whole operating systems on the metal, virtual machine images, and container images (including Docker images). When you use Nix to generate Docker images and deploy them in production using Docker, Nix is not functioning as an alternative to Docker, but your *.nix file is functioning as an alternative to your Dockerfile. Defining container images in terms of Nixpkgs rather than via a Dockerfile, and assembling it via Nix rathet than `docker build` does have some advantages. 1. It moves you from mere repeatability in the direction of true reproducibility— it makes your outcomes more predictable and reliable 2. Having the benefit of knowledge of the actual dependencies on the system down to the package (or subpackage) level, Nix knows how to generate minimal images when Docker can't. Plus there's the prospect of reuse, I guess; an environment you've defined in Nix for building Docker containers is easy to install and debug in other environments, without the extra complexity of Docker and filesystems exports/imports, port forwarding, etc. That can be nice, to be able to easily separate out what you're troubleshooting or learning as you're creating or modifying the image's environment. But yeah that doesn't mean that pairing Dockerfiles with imperative or convergent configutation management or provisioning tools can't also sometimes work well enough in a given situation.
sph 4y ago
A meme? You've said it simplifies dependencies and then go on saying you can install stuff locally, forgetting how much of a nightmare it is to maintain OS-level dependencies, especially when an app depends on a specific version and another app depends on another version. Containers solve real problems and are here to stay. Feel free not to use them, but saying they're a meme is just trying to be edgy. Keep on containerising applications. Sincerely, a sysadmin that has been fighting conflicting dependency requirements, deprecated packages and major distro upgrades for more than a decade.
- raverbashing 4y ago
  Containers are not a meme What's a meme is creating a container for any minor thing like npm + some js project. Or to run one Go binary. > a sysadmin Sure, for the deployment of stuff containers are very good. But you know people were using stuff like chroots before that right? I don't think I'm deploying this debugging system in a webserver.
  - calineczka 4y ago
    > creating a container for any minor thing like npm + some js project I am backend engineer with a non-JS background and to me that's a a very useful thing. I really don't want to install specific node version, yarn version, etc to run some node/JS application. If I can just docker-compose up that's much easier to me and I know it does not affect anything globally. So removing it after playing around is easy and non-risky.
    - rixthefox 4y ago
      I think the point he was making was too many people and projects are turning towards containers as a sort of "end all" where we're abandoning local system dependencies by shipping applications with their own bundled versions of libraries. My biggest problem with this shift is I'm seeing is people are running their distribution updates and containers are still shipping with vulnerable versions of libraries. So a server admin updates his servers thinking he's all good, No, No he's not because $DEV hasn't updated their container dependencies and now that server gets pwned because here's yet another layer of dependencies I have to deal with on top of the ones I'm maintaining with the OS. So no, please don't make containers on everything just because you can, because more often than not the container you never intended to be used in production WILL be used in production because someone was lazy and didn't want to deal with the dependencies. Additionally, to your point, specific node versions? specific yarn versions? Is it really that unreasonable to demand libraries be backwards compatible with warnings on software saying a method is being depreciated? Like I can understand for major revision changes but seriously. I should be able to run the latest version of node and that code still work with warnings telling me that the code I've written will eventually stop working in later versions due to changes in the underlying setup. My point being, don't weigh on containers as a crutch for badly coded software. Operating systems have moved towards rolling releases, it's about time libraries and programming languages followed suit.
EddySchauHai 4y ago
I like simplicity and for that reason the first thing I do on any project larger than a bash script is setup a container for it. It helps isolate my OS from the project, allows me to easily share it via dockerhub so others can run it, lets me have a sharable dev environment so people can just open it in vscode and edit the project, etc... I've yet to regret using a container and it takes barely any more time than setting it up once for the OS anyway.
BossingAround 4y ago
> Docker has a significant performance penalty unless you're running Linux already Ah yes, the famed Windows/macOS kernel developer... :) (Not that it's not possible of course, I just found it chuckle-worthy within the context of this article)

cmm 4y ago

dockerfiles (or even better but less popular, {default,shell,flake}.nix) are code that can be tracked in a repository and reasoned about, "stuff installed locally" isn't.

encryptluks2 4y ago
I don't see how Nix is better than Docker as they serve different purposes. While I agree using containers helps aid in automating build environments, you can also checkin shell scripts and Ansible roles into repos as well. I understand the criticism and hopefully people aren't going to be so thin-skinned to take offense, but at the same time if it works then it works.
- Strum355 4y ago
  Nix and Docker share the same purpose in this context: declaring the dependencies needed for this environment. This can include shell scripts, system-level dependencies etc. If anything I would say Nix would be better here (logical middleground in filesystem separation between having access only to whats in the container vs having to juggle system-level dependency versions for the entire system), while also having better version pinning.
- pxc 4y ago
  > I don't see how Nix is better than Docker as they serve different purposes Nix can build many things, among them whole operating systems on the metal, virtual machine images, and container images (including Docker images). When you use Nix to generate Docker images and deploy them in production using Docker, Nix is not functioning as an alternative to Docker, but your *.nix file is functioning as an alternative to your Dockerfile. Defining container images in terms of Nixpkgs rather than via a Dockerfile, and assembling it via Nix rathet than `docker build` does have some advantages. 1. It moves you from mere repeatability in the direction of true reproducibility— it makes your outcomes more predictable and reliable 2. Having the benefit of knowledge of the actual dependencies on the system down to the package (or subpackage) level, Nix knows how to generate minimal images when Docker can't. Plus there's the prospect of reuse, I guess; an environment you've defined in Nix for building Docker containers is easy to install and debug in other environments, without the extra complexity of Docker and filesystems exports/imports, port forwarding, etc. That can be nice, to be able to easily separate out what you're troubleshooting or learning as you're creating or modifying the image's environment. But yeah that doesn't mean that pairing Dockerfiles with imperative or convergent configutation management or provisioning tools can't also sometimes work well enough in a given situation.

sph 4y ago

A meme? You've said it simplifies dependencies and then go on saying you can install stuff locally, forgetting how much of a nightmare it is to maintain OS-level dependencies, especially when an app depends on a specific version and another app depends on another version. Containers solve real problems and are here to stay. Feel free not to use them, but saying they're a meme is just trying to be edgy. Keep on containerising applications. Sincerely, a sysadmin that has been fighting conflicting dependency requirements, deprecated packages and major distro upgrades for more than a decade.

raverbashing 4y ago
Containers are not a meme What's a meme is creating a container for any minor thing like npm + some js project. Or to run one Go binary. > a sysadmin Sure, for the deployment of stuff containers are very good. But you know people were using stuff like chroots before that right? I don't think I'm deploying this debugging system in a webserver.
- calineczka 4y ago
  > creating a container for any minor thing like npm + some js project I am backend engineer with a non-JS background and to me that's a a very useful thing. I really don't want to install specific node version, yarn version, etc to run some node/JS application. If I can just docker-compose up that's much easier to me and I know it does not affect anything globally. So removing it after playing around is easy and non-risky.
  - rixthefox 4y ago
    I think the point he was making was too many people and projects are turning towards containers as a sort of "end all" where we're abandoning local system dependencies by shipping applications with their own bundled versions of libraries. My biggest problem with this shift is I'm seeing is people are running their distribution updates and containers are still shipping with vulnerable versions of libraries. So a server admin updates his servers thinking he's all good, No, No he's not because $DEV hasn't updated their container dependencies and now that server gets pwned because here's yet another layer of dependencies I have to deal with on top of the ones I'm maintaining with the OS. So no, please don't make containers on everything just because you can, because more often than not the container you never intended to be used in production WILL be used in production because someone was lazy and didn't want to deal with the dependencies. Additionally, to your point, specific node versions? specific yarn versions? Is it really that unreasonable to demand libraries be backwards compatible with warnings on software saying a method is being depreciated? Like I can understand for major revision changes but seriously. I should be able to run the latest version of node and that code still work with warnings telling me that the code I've written will eventually stop working in later versions due to changes in the underlying setup. My point being, don't weigh on containers as a crutch for badly coded software. Operating systems have moved towards rolling releases, it's about time libraries and programming languages followed suit.

EddySchauHai 4y ago

I like simplicity and for that reason the first thing I do on any project larger than a bash script is setup a container for it. It helps isolate my OS from the project, allows me to easily share it via dockerhub so others can run it, lets me have a sharable dev environment so people can just open it in vscode and edit the project, etc... I've yet to regret using a container and it takes barely any more time than setting it up once for the OS anyway.

BossingAround 4y ago

> Docker has a significant performance penalty unless you're running Linux already Ah yes, the famed Windows/macOS kernel developer... :) (Not that it's not possible of course, I just found it chuckle-worthy within the context of this article)