Live data from Hacker News

Why would anyone choose Docker over fat binaries?

smashcompany.com

21–30 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#21

Golang didn't pioneer 'fat' binaries as the article claims. It may have made them popular again, but we have had compiled, self-contained, dependency-free executables for decades. If people are not aware of that, perhaps it's because scripting languages (or languages that use a VM) have come to so thoroughly dominate programming language discussions?

I guess so.

Usually everone that somehow thinks Go compilation model is inovative, never has used anything beyond scripting languages and possibily C in addition to them.

MS-DOS used to call them "XCopy installs", NeXTSTEP had its fat binaries with directory structure, Windows and MacOS(pre OS X) can store all dependencies inside the .exe file and so on.

In any case, fat binaries don't cover the dependencies with file system, other running servers or sandboxing.

Re: Why would anyone choose Docker over fat binaries?

#22
post #7

Containers are not only a solution for dependencies. It's also protection boundary.

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

chroot only protects the file system, sandboxes are much more than that.

Re: Why would anyone choose Docker over fat binaries?

#23

Earlier quoted context omitted.

its really not that naive, for the longest while that how google ran all its stuff through borg. This left the resource management to the scheduler, where it belongs.

Google ran all their stuff as fat binaries through Borg? Why would they change to containers with kubernetes if the borg approach is better?

Google runs things internally as fat binaries inside cgroups, which is a Linux kernel feature that implements resource limits like "only give this thing 2GB of memory"

Docker combines cgroups with a layered filesystem and a tarfile to copy everything around in. It's the total package that is meaningful; the article argues against just one aspect and thus fails to cover the whole picture.

Re: Why would anyone choose Docker over fat binaries?

#24
post #7

Containers are not only a solution for dependencies. It's also protection boundary.

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.

and also namespaces for file-system, network etc. etc.

Re: Why would anyone choose Docker over fat binaries?

#25
post #14

Not all developer tools and languages let you compile to fat binaries. Also I don't think that they were pioneered by Go. Java .jar files have been around long before Go even existed. Jar files are probably even better in fact because they can run on any operating system without any sort of virtualization. Docker standardizes containerization. Kubernetes relies on a standardized container platform like Docker in orde…

> Jar files are probably even better in fact because they can run on any operating system without any sort of virtualization. What did you think the V in JVM stood for?

Harsh tone for a comment that’s confusing OS virtualization with virtual ISA and its runtime.

Re: Why would anyone choose Docker over fat binaries?

#26

Not all developer tools and languages let you compile to fat binaries. Also I don't think that they were pioneered by Go. Java .jar files have been around long before Go even existed. Jar files are probably even better in fact because they can run on any operating system without any sort of virtualization. Docker standardizes containerization. Kubernetes relies on a standardized container platform like Docker in orde…

Regarding Jar files, wasn't it JVM that coined the term "compile once, debug everywhere"?

Re: Why would anyone choose Docker over fat binaries?

#27
post #14

Earlier quoted context omitted.

> Jar files are probably even better in fact because they can run on any operating system without any sort of virtualization. What did you think the V in JVM stood for?

Harsh tone for a comment that’s confusing OS virtualization with virtual ISA and its runtime.

I'm aware of the difference, I just don't think it matters here - in either case there's an additional level of indirection when compared to Golang fat binaries.

Re: Why would anyone choose Docker over fat binaries?

#28

Earlier quoted context omitted.

its really not that naive, for the longest while that how google ran all its stuff through borg. This left the resource management to the scheduler, where it belongs.

Google ran all their stuff as fat binaries through Borg? Why would they change to containers with kubernetes if the borg approach is better?

because in borg land, everything apart from the binary is controlled by the scheduler.

why is that good? because it means that the thing that knows about resource utilisation has control of what resources it give out. quite patch on the farm? give the low priority jobs more memory/cpu.

You also have to remember that borg is part of the secret sauce that makes google tick. Having a single interface to a smart, efficient, fast and scalable scheduler is invaluable at scale.

Kebernetes is nice, but its nowhere near as advanced or fully featured as slurm/gridengine/tractor etc. its also not that efficient or fast. (I worked in VFX with various schedulers some were able to dispatch 100k execution instructions a second)

Re: Why would anyone choose Docker over fat binaries?

#29
post #22

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

chroot only protects the file system, sandboxes are much more than that.

BSD Jails and Solaris Zones then.

Everything old is new again, this time with an orchestration layer.

Post reply on HN