Hacker News

> 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=34377674

BTW just for giggles opened hub.docker.com with Network Tools opened:

368 requests, 9.62MB, Finish: 4.50s.

For a thing which should be a static cached copy with everything bundled. Sure, it's a progress from the previous iterations when it could hang for 30 seconds before actually loading... but this is still ridiculous.

[0] 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

> Like they told you 9 months ago, the terminology is exactly right

Oh, well. I guess you ride to your work on wheels, right? Because while you sit in the car/bus/train it's the wheels what actually rides on the road/track, right?

And if you bothered to look at that comment then why do you ignore what 'macvlan' - which is an actual bridge both in terms of a Linux device and the functionality - is not called 'bridge'?

Because you don't understand the problem. More so, you ignore the actual question there about the broadcast domains.

No, if even if you use a bridge internally when your container is on a isolated network which is invisible to anyone on your network and the container access the network behind your host through the NAT - this can't be called a bridge.

You see, if they just called it as it should, ig:

   bridge  => hostnatnetwork // or internalbridgenatnetwork or whatever else 
   macvlan => bridge

then they would be both named correctly and be the technically correct - and 99% of Docker users couldn't tell a difference - because they are not net or sys administrators.

But the last 1% is the people who actually makes the workspaces for these developers where they actually do run their fancy-shmancy containers. And for that 1% it surely pays naming this as they are.

And there is also that dumb decision to silently rewrite 127.0.0.1 to Google DNS without a question. Especially when 98% of Docker users are incapable to diagnose it by themselves.

So it's not only the naming of a network functions.

But hey, I'm just knowledge lacking guy without experience at all, just yesterday saw a computer a first time in my life, sure, sure.

> RUN command has had heredoc support for 5 years now

So ten years late? Adoption is off the limits, as you can see - that snippet is from the official Docker image.

And if I need to run multiple commands and not just one RUN statement? Like the people are asking for years? And you so knowledgeable person of course do know the reason for that, right?