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

91–100 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#91

Post by IshKebab »

pjmlp wrote: post #65
Lazare wrote: post #39

Earlier quoted context omitted.

I assume you knew this and were just making a point, but: OP is using the term "fat binary" in a totally different and incompatible way to how your wikipedia link defines it. > every compiled language has that. It is not exclusive to Go. I don't think the article claimed it was. But it is a lot harder with C than Golang for various technical reasons, and it's much, much harder still with most scripting languages.

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 they eventually gave up due to the effort required.

The story on Windows is much better of course, but even there making a proper dependency-free (as much as possible) binary is much easier with Go than any other language. It's possible in Go because they don't depend on the C standard library and wrote their own linker.

Re: Why would anyone choose Docker over fat binaries?

#92

Post by gcb0 »

lightedman wrote: post #87
geofft wrote: post #59

Earlier quoted context omitted.

Why is it not good? It is in line with the robustness / Worse-is-Better ethos, and importantly, it lets you get on with delivering business value , which is what we're supposed to be doing. (At least in a business context. If you want to rewrite code to perfection on weekends, for fun, so do I, I am all for that, but that's almost never what my employer needs.)

"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

Re: Why would anyone choose Docker over fat binaries?

#93

Post by tedunangst »

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…

Pretty sure pjmlp knows how hard life is with glibc. Possibly even knows a bit about other systems that aren't linux.

Re: Why would anyone choose Docker over fat binaries?

#94

Post by rkeene2 »

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…

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 for further information: https://stackoverflow.com/questions/3430400/linux-static-lin...

However, in 1992 it was entirely possible to statically link an application to libc4 and have it have no run-time dependencies other than the kernel ABI.

Re: Why would anyone choose Docker over fat binaries?

#95

Post by [deleted] »

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…

[deleted]

Re: Why would anyone choose Docker over fat binaries?

#96

Post by Sevii »

danmaz74 wrote: post #88
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…

> built in the old-style scripting paradigm using a scripting language like Ruby, PHP, or (god help us) node.js I feel like I didn't get the memo... is the new-style we're all supposed to use microservices?

Microservices have won so hard that the fortune 500 are making it standard.

Re: Why would anyone choose Docker over fat binaries?

#98

Post by Spooky23 »

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?

No idea. I’m not advocating that position.

There are enterprise use cases where docker makes sense if the app support people are less impossible to deal with than the SAs. But you don’t have that issue in cloud.

Re: Why would anyone choose Docker over fat binaries?

#99

Post by sigjuice »

notyourday wrote: post #73
anilakar wrote: post #70

Earlier quoted context omitted.

I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.

In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.

Yes. Each time you start a container, you are basically saying “make clean” as well.

Re: Why would anyone choose Docker over fat binaries?

#100

Post by 2trill2spill »

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 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.

Post reply on HN