91–100 of 286 posts
If somebody missed it, apple/container is a good replacement for Docker for Mac on macOS. I have been using it for the last 6 months, there are issues, but also team is actively developing it. https://github.com/apple/container
Earlier quoted context omitted.
Really? I work across multiple vscode projects (locally), some use dev-containers and others don't. I have never noticed any difference in experience across the two. I have also used them remotely (ssh and using tailscale) and noticed a little lag, but nothing really distracting.
Most likely a Windows or MacOS user, where docker runs in a linux VM. Optimized as much as possible and lightweight, but still a VM.
First of all it supports containers natively, Windows own ones, and Linux on WSL.
Secondly, because Microsoft did not want to invent their own thing, the OS APIs are exposed the same way as Docker daemon would expect them.
Finally, with the goal to improving Kubernetes support and the ongoing changes for container runtimes in the industry, nowadays it exposes several touch points.
https://learn.microsoft.com/en-us/virtualization/windowscont...
Earlier quoted context omitted.
Most likely a Windows or MacOS user, where docker runs in a linux VM. Optimized as much as possible and lightweight, but still a VM.
No, on Windows it is very quick too. On WSL2 compiling Rust programs are almost as fast as Linux on bare metal. However the files need to live inside the Linux filesystem. Sharing with Windows drives actually compiles slower than native Windows.
One thing that really hurt them from my PoV was how they acted when they changed their licensing structure with respect to revenue generating companies. I’m fine with the idea that licensing Docker and Docker Desktop is a good thing to do. However, I think they just made people distrust their motives with their approached to this. At two places I worked their reps reached out to essentially ensnare the company in a s…
Due to the usual “mid size software company not micromanaging the developers” standard You didn't have a device management system or similar product managing software installs (SCCM in Windows land)? That's table stakes for any admin.
What I hate about docker and other such solutions is that I cannot install it as nonroot user, and that it keeps images between users in a database. I want to move things around using mv and cp, and not have another management layer that I need to be aware of and that can end up in an inconsistent state.
There's a rootless [0] option, but that does require some sysadmin setup on the host to make it possible. That's a Linux kernel limitation on all container tooling, not a limitation of Docker.
> and that it keeps images between users in a database.
Not a traditional database, but content addressable filesystem layers, commonly mounted as an overlay filesystem. Each of those layers are read-only and reusable between multiple images, allowing faster updates (when only a few layers change), and conserving disk space (when multiple images share a common base image).
> I want to move things around using mv and cp, and not have another management layer that I need to be aware of and that can end up in an inconsistent state.
You can mount volumes from the host into a container, though this is often an anti-pattern. What you don't want to do is modify the image layers directly, since they are shared between images. That introduces a lot of security issues.
One thing that really hurt them from my PoV was how they acted when they changed their licensing structure with respect to revenue generating companies. I’m fine with the idea that licensing Docker and Docker Desktop is a good thing to do. However, I think they just made people distrust their motives with their approached to this. At two places I worked their reps reached out to essentially ensnare the company in a s…
Due to the usual “mid size software company not micromanaging the developers” standard You didn't have a device management system or similar product managing software installs (SCCM in Windows land)? That's table stakes for any admin.
But outside of 'make sure the oracle lawyers never contact us' they dont want us policing them and they are admins on their own devices. For a lot of businesses their computer network has separate production and business zones and the production zone is a YOLO type situation.
"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value." No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own…
It didn't help them that they rejected the traditionally successful ways of monetizing open source software. Which is, selling support contracts to large corporate users. Corporate customers didn't like the security implications of the Docker daemon running as root, they wanted better sandboxing and management (cgroups v2), wanted to be able to run their own internal registries, didn't want to have docker trying to f…
"The problem is that Docker the technology became so successful that Docker the company struggled to monetize it. When your core product becomes commoditized and open source, you need to find new ways to add value." No, everything was already open source, other had done it before too, they just made it in a way a lot of "normal" users could start with it, then they waited too long and others created better/their own…
It didn't help them that they rejected the traditionally successful ways of monetizing open source software. Which is, selling support contracts to large corporate users. Corporate customers didn't like the security implications of the Docker daemon running as root, they wanted better sandboxing and management (cgroups v2), wanted to be able to run their own internal registries, didn't want to have docker trying to f…
Corporate customers do not care about any of the things you mentioned. I mean, maybe some, but in general no. That's not what corps think about.
There was never "no interest" at Docker in cgv2 or rootless. Never. cgv2 early on was not useable. It lacked so much functionality that v1 had. It also didn't buy much, particularly because most Docker users aren't manually managing cgroups themselves.
Docker literally sold a private registry product. It was the first thing Docker built and sold (and no, it was not late, it was very early on).
What I hate about docker and other such solutions is that I cannot install it as nonroot user, and that it keeps images between users in a database. I want to move things around using mv and cp, and not have another management layer that I need to be aware of and that can end up in an inconsistent state.
What I hate about docker and other such solutions is that I cannot install it as nonroot user, and that it keeps images between users in a database. I want to move things around using mv and cp, and not have another management layer that I need to be aware of and that can end up in an inconsistent state.
> I cannot install it as nonroot user Sure you cannot install docker or podman as a non-root user. But take your argument a bit further: what if the kernel is compiled without cgroups support? Then you will need root to replace the kernel and reboot. The root user can do arbitrarily many things to prevent you from installing any number of software. The root user can prevent you from using arbitrary already installed…
Depends on what you mean by "install software".
If your definition is "put an executable in a directory that is in every other user's standard $PATH", then yes, this is an absurd complaint. Of course only root should be able to do this.
If your definition is "make an executable available to run as my user", then no, this is not absurd. You absolutely should not need root to be able to run software that doesn't require root privileges. If the software requires root, it's either doing something privileged, or it's doing it wrong.