Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why would anyone choose Docker over fat binaries?

smashcompany.com

Post reply on HN
Print view View original

151–160 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#151

Post by Silhouette »

Johnny555 wrote: post #138
Silhouette wrote: post #76

Earlier quoted context omitted.

If a company has existing in-house systems that are working well, why should they care about "valuable experience that would be usable outside the company"? Unless you think it's their responsibility to train people so those people can then leave and take the benefit of that training to some other, possibly competing, business?

The company may not care about building skills for employees that are transferable elsewhere (though good companies do), but they do care about being able to hire people with skills that are applicable to their systems. While a very large company can get away with building a custom in-house ecosystem that takes months for a new employee to come up to speed on, most companies find it more palatable to use industry sta…

The company may not care about building skills for employees that are transferable elsewhere (though good companies do), but they do care about being able to hire people with skills that are applicable to their systems.

Of course, but who would you rather hire, someone with solid fundamentals who can get up to speed quickly with anything, or someone who job-hops to use the latest buzzword library/framework/language that may have a useful lifetime of just a few years or even less? Given an either/or decision with other things being equal, I would almost always prefer to hire the former, and then use whatever tools worked best for the job regardless of whether they were built in-house or imported. A job-hopping resume full of trendy buzzwords is a big red flag for me.

While a very large company can get away with building a custom in-house ecosystem that takes months for a new employee to come up to speed on

This argument gets made all the time in discussions about frameworks, but I just don't see it. In my entire programming career, I have yet to encounter this hypothetical nightmare architecture that takes months before you can become productive and has no useful documentation or examples even though the entire application is built around it. (YMMV, obviously.)

Being able to get up to speed quickly on a new framework or library is an essential skill for a working professional developer. Whether that is the latest shiny Web World buzzword or something internal in your new employer's environment makes little difference, as long as the internal design is also sensible and reasonably documented -- and if it's not, you have much bigger problems than who you're thinking about hiring next.

Re: Why would anyone choose Docker over fat binaries?

#152

Post by depr »

pmoriarty wrote: post #104
2trill2spill wrote: post #100

Earlier quoted context omitted.

> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container. Don't group all container implementations into one category. You could certainly use FreeBSD Jails and Illumos Zones for isolating apps.

Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they? The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

What makes you say that? VM's get exploited as well http://venom.crowdstrike.com so what makes you think VM's are better than e.g. zones?

Re: Why would anyone choose Docker over fat binaries?

#153

Post by Silhouette »

dwaltrip wrote: post #135
pfranz wrote: post #122

Earlier quoted context omitted.

Resume Driven Development can be just as bad for everyone involved.

That's a slanted take. Skills and experience that are only useful inside of one specific company are more likely to be less meaningful and effective (almost by definition). Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Of…

Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing.

Right, but to those people, whether you use Docker or Kubernetes or custom scripting or a unicorn whose horn magically creates new instances when you need them is mostly just an implementation detail. It's no more interesting than exactly which compiler or DB you use; these are just tools, means to an end. If the differences are significant for your use case, sure, you evaluate and choose accordingly, but then you use the tools to get on with the job. The deep, interesting stuff is almost always in what you can build once you're into that territory.

Re: Why would anyone choose Docker over fat binaries?

#154

Post by pjmlp »

IshKebab wrote: post #91
pjmlp wrote: post #65

Earlier quoted context omitted.

It is super easy to do static binaries with C, I was already doing it in 1992, the first time I actually used C on my life. It only hard if one happens to mix glibc, a specific implementation of the ANSI C standard library, with any implementation of it.

Hahaha that is soooo wrong. You might think you make a static binary with C by passing -static but trust me you do not. I believe it is still actually impossible to link with glibc statically. It's only been possible to do a static binary on Linux since Musl was written and that was not in 1992. In the 2000's there was an attempt to make true static binaries possible on Linux (think it was called Autopackage) but the…

In 1992, we were using Xenix, Aix, HP-UX, Tru64, SGI, Solaris, DG/UX, MS-DOS, AmigaOS, Atari, OS/2....

All of them allowed for static linking, and only a few supported dynamic linking.

Regarding Linux, the very first version to properly support dynamic linking was kernel 1.0.9, which introduced ELF support. Slackware 2.0 was one of the first distributions supporting it.

Before that, binutils had a set of patching tools to make dynamic loading work in the a.out format.

GNU/Linux is just one OS among many supported by C compilers.

Re: Why would anyone choose Docker over fat binaries?

#155

Post by rkeene2 »

dullgiulio wrote: post #150
rkeene2 wrote: post #94

Earlier quoted context omitted.

It is not impossible to link glibc statically, and in older versions of libc this did occur. However, the Linux community at the time decided that the tradeoff of disallowing the system NSS to be modular was too great -- Go developers disregard this and don't believe anyone does anything other than the defaults. Even still, it's possible to compile glibc such that those NSS modules are statically linkable. See here f…

Go doesn't disregard anything. It tried to parse NSS configuration, if there is no Go implementation available for the user conf it parsed, it falls back to glibc.

Only if you use "cgo", otherwise it doesn't have access to the run-time linker.

Re: Why would anyone choose Docker over fat binaries?

#156

Post by notyourday »

rco8786 wrote: post #148
notyourday wrote: post #61

Earlier quoted context omitted.

> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write. Of course you do, you just moved the logic into the "orchestration" and "management" lay…

You argument seems to be "why use Docker when you can do all of these things by hand?". It's kind of the Devops corollary of "why use Java when you could write everything in C?".

No, my argument is "if you are using docker without understanding what you are doing, you are not only not solving your problem but complicating your stack"

Don't get me wrong I love people doing this. It makes my skills in uncomplicating needlessly complicated systems extremely valuable.

Re: Why would anyone choose Docker over fat binaries?

#158

Post by derimagia »

SOLAR_FIELDS wrote: post #128
supermatt wrote: post #6

Its INCREDIBLY naive of the author to be slamming docker usage because they think everything should be a fat binary - and what are they even calling a fat binary? How do I make my node app a fat binary? Would they be happier if we wrapped up docker + images in an executable and called that a fat binary? Also, I think the author is simply confused about what docker itself is, complaining about its lack of network orch…

This is not intending to diminish your point because I agree with you, but you can in fact make a fat binary with Node: https://github.com/nexe/nexe I have used it when I cannot guarantee to have Node.js installed on location I am deploying app to. It works pretty well, but the C compilation of all the Node bindings took quite awhile when I was using it (about 2 years ago). I think a build of a small project took aro…

This would copy the runtime for every app you need.. Pretty sure if you used docker this wouldn't be the case but I'm 100% sure. Obviously space isn't the biggest of deals, just mentioning it.

Re: Why would anyone choose Docker over fat binaries?

#159

Post by dwaltrip »

Silhouette wrote: post #153
dwaltrip wrote: post #135

Earlier quoted context omitted.

That's a slanted take. Skills and experience that are only useful inside of one specific company are more likely to be less meaningful and effective (almost by definition). Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Of…

Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Right, but to those people, whether you use Docker or Kubernetes or custom scripting or a unicorn whose horn magically creates new instances when you need them is mostly just…

This is definitely true for many people.

However, I do think it's likely there are some fundamental principles at play that make tool 1 better than tool 2 in specific contexts, and I think it is valuable and interesting to explore that.

Perhaps we are getting into the scientist vs. engineer mindset. I would guess, though, that the best engineers undoubtedly have some scientific curiousity helping them excel in their craft.

Re: Why would anyone choose Docker over fat binaries?

#160

Post by Yeroc »

cobookman wrote: post #72

Fat binaries solve only for dependency. Containers also deal with isolating environment variables and filesystem. Each program doesn't have to worry about what else is running on the machine. It also helps you deal with the differences between say Ubuntu and redhat. Not all nix os have the same filesystem directory setup.

Containers are overkill if you're just trying to isolate environment variables and filesystems. I mean really, if that was your problem and you came up with containers as the solution I'd say you over-engineered the solution. Environment variables -- trivial -- set them in the wrapper script used to launch the binary and you're done. Filesystem -- use separate nix accounts for your binaries and set appropriate permissions, for additional security use tools like se-linux if needed. Somehow, somewhere along the line it seems like there's this huge echo-chamber of 'containers for all things' and we have thrown out all we ever new about basic nix.

Contrarian views like the one in the article are healthy!

Post reply on HN