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

141–150 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#141

Post by justincormack »

rkeene2 wrote: post #94
IshKebab wrote: post #91

Earlier quoted context omitted.

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…

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…

It is now with Musl libc

Re: Why would anyone choose Docker over fat binaries?

#142

Post by curun1r »

pmoriarty wrote: post #109
luord wrote: post #82

This article failed to mention the most important thing: An actual advantage of fat binaries. The closest he comes is saying that he feels the docker way is "old"... As compared with fat binaries, which is how desktop applications have been shipped for decades. Hell, size, the only clear would-be advantage, is only mentioned in a throaway sentence. > Yes, the network can be very powerful, but trying to use it for eve…

"I have a feeling he doesn't know the distinction between kubernetes and docker. They don't actually compete with each other, I don't even understand the comparison. Kubernetes uses docker." Docker (the company) is itself responsible for this confusion. They're redefined what "docker" means a whole bunch of times.

I had this discussion [0] with their CTO a while back and, suffice it to say, there's a profound lack of understanding of what early adopters like me had to do to lobby for the use of their products in enterprises.

[0] https://news.ycombinator.com/item?id=13775732

Re: Why would anyone choose Docker over fat binaries?

#143

Post by geofft »

gcb0 wrote: post #92
lightedman wrote: post #87

Earlier quoted context omitted.

"Why is it not good?" Because it still allows the base problem of crap coding practice to proliferate.

and don't forget that crap code == insecure code. but nobody have to worry about it. just start a container the last guy left. /sarcasm

> and don't forget that crap code == insecure code.

I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment, and you probably want to have your "good" code in a well-written sandbox anyway.

Re: Why would anyone choose Docker over fat binaries?

#144

Post by pmoriarty »

betaby wrote: post #67
jamespo wrote: post #32

Earlier quoted context omitted.

Some would say the orchestration layer is quite important

And people were running cfengine inside FreeBSD jails and Linux vservers in early 2000 already.

Wow, and I thought I was the only one who remembers Linux vservers. Whenever I tell people I was using them 15 years ago, people look at me like I'm crazy. I was beginning to think I dreamed it all.

Now here's Docker getting mountains of press for seemingly reinventing the wheel. But, to be fair, cgroups didn't exist back in the days of Linux vservers, so there was no easy way to constrain per-vserver resource use as there is now, the isolation wasn't as complete as with Docker, and there was no use of layered filesystems so you couldn't build up a Linux vserver layer by layer as you can a Docker container.

It was still very useful back then, though. Way ahead of its time, and it's a shame most people never knew it even ever existed.

Re: Why would anyone choose Docker over fat binaries?

#145

Post by shrimpx »

A typical service has many types of dependencies including filesystem layout, the presence of specific executables at specific versions, rpm/deb packages at specific versions. Different services make different assumptions and evolve at incompatible paces. Docker can isolate an assumption about FS layout as well as an assumption that a deb is at a specific version.

This article is confusing in its focus on docker. It really proposes a much more restricting way to build apps, in which all assumptions except linking-level dependencies should be portable. Its answer to filesystem isolation: don't rely on the filesystem being a certain way. Or, rely on it being a certain way and push the complexity into your deployment layer.

Re: Why would anyone choose Docker over fat binaries?

#146

Post by xorcist »

mschuster91 wrote: post #60
neilwilson wrote: post #20

Earlier quoted context omitted.

It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. We just didn't have a massive PR budget

> It's just a process with a fancy chroot. Don't believe all the docker hype. Sensible admins have been doing something similar for years. You can easily break out of a chroot jail: http://pentestmonkey.net/blog/chroot-breakout-perl Thats not possible in Docker (okay, it is if you're running a container in privileged mode but that's another can of worms and you shouldn't do it unless absolutely neccessary). Also, Doc…

> Thats not possible in Docker

Believe this at your own peril.

Re: Why would anyone choose Docker over fat binaries?

#147

Post by kemitche »

notyourday wrote: post #90
Spooky23 wrote: post #77

Earlier quoted context omitted.

It pushes thinking up to the app/middleware stack and away from server instances.

The odds are you are running on VMs in AWS, GCS, Azure or even DO. If that's the case, why on earth is your building block not a VM?

I can run a dozen containers on my laptop a lot more easily than I can run a dozen VMs.

Re: Why would anyone choose Docker over fat binaries?

#148

Post by rco8786 »

notyourday wrote: post #61
friend-monoid wrote: post #48

* 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. * We have a whole lot of HTTP services in a range of languages. Managing them all with fat…

> * 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?".

Re: Why would anyone choose Docker over fat binaries?

#149

Post by r0fls »

awirth wrote: post #57
Lazare wrote: post #38

I admit: I find the argument for "fat binaries"[1] over containers compelling. There's just one problem... ...let's say I'm working on an existing code base that has been built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js. Let's say we're well aware of the shortcomings are are looking for a migration path to move into the future. I can just about see how we c…

But here's the thing: You can dockerise a PHP app. How am I meant to make a fat binary out of one? For years Facebook (reportedly) did this with hPHPc. Not a very good idea these days, but it's certainly within the realm of possibilities for large companies.

I think the author's retort would be that PHP is one of these "outdated" languages like Python and Ruby. I tend to disagree, but overall enjoyed their opinion anyway. I came to criticize the article, but I think this comment already does that well: https://news.ycombinator.com/item?id=15578147

Re: Why would anyone choose Docker over fat binaries?

#150

Post by dullgiulio »

rkeene2 wrote: post #94
IshKebab wrote: post #91

Earlier quoted context omitted.

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…

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.
Post reply on HN