
Docker: Not Even a Linker - nkurz
http://adamierymenko.com/docker-not-even-a-linker
======
btrask
Fantastic article. We need more deconstruction of "fads" (which I don't mean
in a pejorative sense) so that we can quickly understand them without
sacrificing tens of thousands of man-hours slowly coming to terms with each
one. It would be much better if we could reason about the exact differences
and benefits instead of getting bogged down in new terminology, etc.

More examples I've been thinking about:

\- Goroutines (fibers are equivalent to threads, but coroutines are different)

\- Safety and the unsafe keyword in Rust (not sure but the effective
difference seems to be default-allow versus default-deny)

~~~
pjmlp
Regarding those two examples, more than having explanations about them, it
would help if people cared about IT history and it was more accessible.

Coroutines are easily explained in Modula-2 literature.

Safe keyword in Rust goes back at very least to Ada and Modula-2. Also in
Oberon and its derivatives, Modula-3 (which inspired C#). The literature for
those systems also has lots of examples.

Being an old IT dog, that started when those technologies were new it is
sometimes hard to me to see how new generations fail to find such information,
even though it is available on the web. I guess the main cause is thatbone
needs to know what to search for.

~~~
pjc50
Tech is strangely ahistorical. Not just practitioners not reading the
literature, but it seemingly being forgotten entirely. Possibly this is a side
effect of so many of us being self-taught.

In another thread I've just been arguing with someone who thought that the
DOOM code should have been thread-safe.

~~~
wslh
I would say cyclical. Every day we read about a similar framework working in a
popular language when that solution already existed for long time.

But this happens in other areas outside computer science. For example, modern
medicine rediscovering old medicine "recipes".

The problem in our field is when people talk all day about Docker while
surpressing LXC from the discussion.

~~~
digi_owl
I think it happens for different reasons though.

With medicine it boils down to a dismissal of folk remedies as placebo.

But with computing its because the old ways were developed on mainframes and
minicomputers in an environment that current generation may only have heard
stories about.

This because the micro-computer era was pretty much a mental reboot for
computing, as little if any software crossed over (until fairly recently).

------
vezzy-fnord
It's been said several times before that a large incentive for Docker's
adoption was to get around the dynamic linking hell that is present in most
modern Unix-likes.

It's funny the author mentions a "world without linkers" with my posting of an
article about the TAOS operating system today. Go look there if you want some
primers on achieving that.

That said, the author greatly oversells Docker's novelty.

~~~
Galanwe
> "the dynamic linking hell that is present in most modern Unix-likes"

WTF are you talking about...

There has never been a "hell" of dynamic linking problems on Unixes, this used
to be a Windows problem. Even the "most modern unix-likes" doesn't make sense,
since "most modern unix-likes" do not even use similar linking models.

~~~
fapjacks
We have dependency management built into the package managers which hides that
from us these days. Unix and Linux before package managers was kind of a pain.
Now, I will totally give you that it was nothing like the "DLL hell" of
Windows.

~~~
reidrac
Then how can be that an incentive for Docker's adoption? Honest question; if,
as you say, this is a solved problem thanks to package managers.

I can't even remember the last time I had a real dependency problem deploying
an application (using Debian; and CentOS before that), other than myself not
doing things right (read: installing RPMs I found online and I shouldn't
install).

~~~
fapjacks
Well I wasn't originally speaking wrt Docker, but Docker doesn't magically
lose all the hard work done by package managers. You have total access to them
in your containers.

------
amirouche
> Had their developers known what they were actually writing, perhaps we'd
> have a lean and mean solution that did the right thing.

I am surprised nobody mentionned nix, nixos and guix.

~~~
pron
Can you explain what those are and what they do?

~~~
davexunit
Nix and Guix are purely functional package managers, meaning that software
builds are treated like a mathematical function: Input the same source code +
dependencies and receive the same build as output. They have features such as
reproducibile (often bit identical) builds, transactional package upgrades and
rollbacks, and unprivileged package management. They solve the dynamic linking
problem by allowing each package to refer _precisely_ to the dependencies that
it was built with. With this mechanism in place, it becomes very easy to use
applications that require different versions of some C library, or a different
Ruby/Python interpreter, or whatever else. Furthermore, it can do this without
relying on a specific type of file system, and without requiring that
applications be run inside containers or virtual machines. This makes it very
composable and general-purpose.

[https://nixos.org/](https://nixos.org/)

[http://www.gnu.org/software/guix/](http://www.gnu.org/software/guix/)

------
riquito
> Instead of building and filing away heaps of immutable (read: security
> nightmare) containers [...]

Is there a consensus on what is(are) the best method(s) to handle security
patches automatically in Docker? For example, the official images at
[https://registry.hub.docker.com/](https://registry.hub.docker.com/) are fixed
in time and you should apply security patches before using them?

~~~
amouat
The official images aren't fixed in time, assuming you're pulling using a tag
e.g redis:3.0. That image may be updated at any point and should be updated
with minor patches and security updates. Rather than manually apply patches,
just pull the image again to get the updates. If the image hasn't been
updated, complain loudly.

If you want your image to be "fixed in time", pull by digest instead.

~~~
riquito
Thank you very much

------
craneca0
Very interesting. I'm not convinced this captures the core value of containers
though. Or at least not the only core value. Calling containers an evolution
of configuration management tools seems like an oversimplification just to
make a point. This may be one aspect of building a micro-service driven
architecture that containers make easier, but there are other very important
ones. Portability comes to mind. It's not just that you can build your stack
once and save it, but that you can then run that stack anywhere, and it
becomes much easier to share/borrow bits and pieces of other people's stacks.

~~~
falcolas
> you can then run that stack anywhere

Anywhere that runs Linux, at least.

> it becomes much easier to share/borrow bits and pieces of other people's
> stacks.

At the cost of not knowing what's really in them.

~~~
andybak
To a certain degree I don't _want_ to know what's in them. If I want to add
search to my stack - initially I'd rather not have to have an intimate
knowledge of Elastic Search, a task queue and whatever other moving parts
there are. In many cases a black box that just works would be a fantastic
option.

The reason hosted services are popular is for exactly this reason.

A wide understanding of different technologies is a wonderful thing but
sometimes you just need to ship.

------
bgilroy26
For any 'Early coders' like my self who want to learn more about linkers and
loaders based on this write up, Programming from the Ground Up by Jonathan
Bartlett is a good book.

~~~
vezzy-fnord
As well as Ian Lance Taylor's 20-part blog series on linkers:
[https://lwn.net/Articles/276782/](https://lwn.net/Articles/276782/)

------
twblalock
Shared libraries were considered a bad idea in Plan 9, and I really wish that
point of view had made it into commercial Unix and Linux.

~~~
davexunit
Shared libraries are a fantastic idea. Static linking wastes system resources
and makes system-wide library updates problematic. Docker's approach to things
is essentially a higher level form of static linking, which is to say that
it's not a very good approach. It's papering over the package management
problem. We need general-purpose package management systems that allow for
different applications to use different versions of shared libraries without
interference. Luckily, the Nix and GNU Guix projects solve this problem very
well, if only they could get some more "mindshare."

~~~
e40
Yeah, having to rebuild every app that uses OpenSSL when a new advisory is
issued... wow, that would be expensive!

~~~
adricnet
Thousands of mobile app developers feel this pain now, from that particular
library.

Not updating these applications is not acceptable to most organizations /
device operators.

Just in case anyone thought the parent was sarcasm or theory, some refs:

[http://www.digitaltrends.com/mobile/heartbleed-bug-apps-
affe...](http://www.digitaltrends.com/mobile/heartbleed-bug-apps-affected-
list/)

[http://blog.trendmicro.com/trendlabs-security-
intelligence/b...](http://blog.trendmicro.com/trendlabs-security-
intelligence/bundled-openssl-library-also-makes-apps-and-
android-411-vulnerable-to-heartbleed/)

------
berzemus
What's with the light-grey-text-on-white-background styling ? It may look
good, but it's a pain to read.

~~~
cthor
It looking "prettier" is pretty arguable.

The body text is as close to black as it is white. #444 is borderline
acceptable. #888 is absurd.

------
kstenerud
Sorry, no. I don't want a dynamic linker for my software stacks. I want a
complete, ready-to-deploy chunk of code, FROZEN IN TIME, that has a known and
predictable state that I can trust.

If I need to apply security fixes, I'll rebuild the chunk of code, also frozen
in time, and deploy.

Ideally, I want no dependencies between container and host, or container and
container. Or at least I want them kept to an absolute minimum.

Even more ideally, I want isolation to be so complete that I'd be able to run
my built stack 100 years from now and have it operate exactly the same as it
does today. That's a bit hyperbolic, of course.

Docker is not a linker; it is a system from which you build deployable code.
In fact, there's no reason why in theory you couldn't add support to deploy
Windows or BSD stacks (other than the fact that Windows and BSD kernels
haven't been added yet).

------
BurritoAlPastor
This is an interesting take, but it doesn't entirely make sense. Ierymenko's
'save your work' metaphor is a little misleading, since (I certainly hope)
nobody is creating docker images manually. But I like his idea that dockerfile
creation, by which you set up a stack in a way that's automatically
reproducible, is equivalent to the role of a linker in a compiled program.

Where he loses me is when he suggests that Puppet et al are closer to a 'pure'
linker. Configuration management systems are doing the _same thing_ as a
Dockerfile: instead of setting up your XYZ stack by hand, you write a Puppet
manifest that calls the modules for XYZ and sets them up the way you need.
Your final result isn't a server with the XYZ stack: it's an _abstracted
process_ that will _reproduce_ your XYZ stack. The main difference is the
implementation; Docker reproduces your stack in an isolated environment, and
configuration management tools reproduce your stack on an arbitrary platform.

But nobody thinks of Docker as a configuration management tool, and for the
most part I don't think people even think of Docker as a _competitor_ to
configuration management. Hell, Docker is a core component of many Puppet CI
workflows.

So there's something else going on here. What's the secret sauce? Is Docker
just two great things (config management + virtualization) glued together so
cohesively that it becomes greater than the sum of its parts?

------
d2xdy2
That's a very clever metaphor for that aspect of Docker. I hadn't considered
looking at it that way before.

------
williamsharkey
The author writes:

"Sometimes (unless I am writing in Go) I don't want to bundle all my code
together into one giant hulking binary."

I am unfamiliar with Go - can someone please offer why this technique might
especially desirable/feasible with Go?

~~~
agrover
Go only supports static linking. No dynamic linking means no linking issues
when deploying the same binary across a billion machines in the Googleplex.

------
glifchits
Is "gerschnorvels" really a word in any language?

~~~
digi_owl
My first though was that it was some sort of compound word.

------
leephillips
According to this article, Docker is a way to save your work after configuring
your server. Can't I do that with

    
    
        rsync -a /etc /whatever backupserver:/backups/server1
    
    ?

~~~
fragmede
First off,

    
    
        rsync -a / backupserver:/backups/server1
    

would be a better comparison; full server state never properly stays in /etc.

Do you actually do that though? Multiple times a day? How easy is it to roll
back to a previous state?

Given Dockerfiles, a better comparison would be rsnapshot, since intermediate
steps are important, and maybe that last "yum upgrade/apt-get update/whatever"
broke something (on dev, of course) and you want to roll back.

How do you compare two related file system images? Is there something more
advanced than "diff -u"? How does that handle binaries? Will that map
backwards and say what command resulted in changed binaries? Can I submit a
code review for the changes between the two states like I could for a
Dockerfile which is plain text?

Docker isn't quite a configuration management system like Chef or Puppet, but
there's a lot of overlap.

------
ForHackernews
> perhaps some quantum superposition of those that has yielded a New Thing.

Ugh. That's not what quantum superposition means.

