← Back to context

Comment by shykes

8 hours ago

This is incorrect.

Docker in its earlier incarnations was based on openvz, which predates lxc. The lxc project was initially a kernel development project: a collection of kernel patches to add container support. The userland tool was just a companion. When it became apparent that these patches would "win" the race to be upstreamed even though openvz was much more mature, we switched our tooling to lxc. The patches matured over time, but the userland tool (what we now know as "lxc") was finicky.

The original open-source release of Docker wrapped lxc for low-level container operations. But it was just too unreliable and we swapped it out for an in-house Go implementation called "libcontainer".

As for "commercializing": Docker was famously bad at commercializing anything, we open sourced so much (maybe too much) and still people complained that we were not open enough.

10 comments

shykes

Reply
stingraycharles  8 hours ago

“Docker was famously bad at commercializing anything, we open sourced so much (maybe too much) and still people complained that we were not open enough”

Developers are a tough market to please, especially when your business revolves around open source software.

Unless you have an option to do private cloud hosting (like all these databases and other platforms do), it’s incredibly difficult to monetize.

In the case of docker, I think it’s in the nature of the product that it’s difficult to monetize. Best you can do is enterprise support contracts, but those aren’t good enough to justify all that VC funding.

  • dralley  7 hours ago

    I don't think it's necessarily that difficult to monetize, they just ignored a lot of the needs of enterprise users (rootless, not punching holes in the firewall, not fighting with systemd, private registries) for long enough that other projects (e.g. Podman, Quay) filled the void.

    • shykes  1 hour ago

      None of those things were obstacles to commercialization. None of them were common requests from enterprise customers except private registries, which Docker did build.

      Podman has never been commercialized.

      Docker's difficulties in commercializing were self-inflicted. Enterprise and open source teams were culturally siloed and as a result the enterprise products were not "native". There was a lack of focus and a "checkbox" approach to building product. There was no singular "dictator" who could enforce a coherent product design and vision, and it showed. etc.

  • justsomehnguy  5 hours ago

    > Docker was famously bad at commercializing anything

    That's because there was never a proper sysadmin on your team to slap some sense in your decisions.

    You've got too opinionated[0], too tied on yourself[1] monster which required too much resources what you can handle alone.

    And your market is not the developers but the companies where whose developers have a daytime jobs: https://news.ycombinator.com/item?id=46739153

    [1] Eg: the syntax to point the image to a specific registry is something... bad. So bad I just abandoned running my own registry, it wasn't worth it.

    PS there is still (AFAIK) no support for a transaction-like image building in Compose. So instead of something like this:

        TRANSACTION START
        RUNBATCH set -eux
        # TODO find a better userspace architecture detection method than querying the kernel
            arch="$(uname -m)"
            case "$arch" in \
                aarch64) gosuArch='arm64' ;
                x86_64) gosuArch='amd64' ;
                *) echo >&2 "error: unsupported architecture: '$arch'"; exit 1 ;
            esac
            curl -fL -o /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$gosuArch.asc"
            curl -fL -o /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$gosuArch"
            export GNUPGHOME="$(mktemp -d)"
            gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4
            gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu
            rm -rf "$GNUPGHOME" /usr/local/bin/gosu.asc
            chmod +x /usr/local/bin/gosu
            gosu --version
            gosu nobody true
    TRANSACTION END

    people need to write these one-liner abominations:

        RUN set -eux; \
    # TODO find a better userspace architecture detection method than querying the kernel
        arch="$(uname -m)"; \
        case "$arch" in \
            aarch64) gosuArch='arm64' ;; \
            x86_64) gosuArch='amd64' ;; \
            *) echo >&2 "error: unsupported architecture: '$arch'"; exit 1 ;; \
        esac; \
        curl -fL -o /usr/local/bin/gosu.asc "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$gosuArch.asc"; \
        curl -fL -o /usr/local/bin/gosu "https://github.com/tianon/gosu/releases/download/$GOSU_VERSION/gosu-$gosuArch"; \
        export GNUPGHOME="$(mktemp -d)"; \
        gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4; \
        gpg --batch --verify /usr/local/bin/gosu.asc /usr/local/bin/gosu; \
        rm -rf "$GNUPGHOME" /usr/local/bin/gosu.asc; \
        chmod +x /usr/local/bin/gosu; \
        gosu --version; \
        gosu nobody true

    EDIT: to add on [1]: https://news.ycombinator.com/item?id=35312087

    • dns_snek  1 hour ago

      > You've got too opinionated [0]

      >>[0] 'Bridge' was and still is an established network term for joining two broadcast domains into one. Why the hell you decided to name your NAT'ed network layer a 'bridge'?

      Like they told you 9 months ago, the terminology is exactly right. They're called "bridge" networks because they use Linux `bridge` devices to bridge `tap` adapters of all containers attached to the same Docker network.

      There's nothing exotic about this terminology at all and complaining about it betrays your own lack of knowledge.

      > PS there is still (AFAIK) no support for a transaction-like image building in Compose. So instead of something like this:

      Do you mean Dockerfiles? RUN command has had heredoc support for 5 years now.

      https://docs.docker.com/reference/dockerfile/#run

      1 reply →

bijmtir  8 hours ago

[flagged]

  • shykes  8 hours ago

    Earlier incarnations of the project (2008-2011) were python based on openvz+aufs, with the very first prototypes (2007-08) wrapping vserver. We started the transition to lxc+aufs in 2011. Open-sourced the lxc wrapper in 2013. Replaced it with libcontainer in... 2014 I believe?