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

11–20 of 180 posts

Re: Why would anyone choose Docker over fat binaries?

#11

Post by jondubois »

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 order to be able to automate the running of different systems in a consistent and repeatable way.

Also, from the point of view of someone who has to provide support for software for multiple customers, it helps to know that the Linux environment between all customers is consistent... That way you don't get strange issues that only happen to one customer and not the others because of some slight OS level differences.

Re: Why would anyone choose Docker over fat binaries?

#12

Post by rljy »

papaf wrote: post #3

This works for one Go or Rust executable but any real system is a mix of technologies e.g A Go service talking to a Java application server proxied with a C webserver that was configured with a bash script. Once you have a mix of different technologies its easier to just say "everything in Docker". The ship container analogy on the old Docker website was a great illustration of this. Its a shame the new website is no…

Does it even work well for go or rust executables? I seem to recall that Docker itself was written in golang because "fat binaries1111", but now docker is one of the hardest to install applications that I know of, and certainly isn't simply one executable file to be copied onto the system.

Managing resource files in fat binaries is really problematic.

Re: Why would anyone choose Docker over fat binaries?

#13

Post by supermatt »

KaiserPro wrote: post #9
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…

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?

Re: Why would anyone choose Docker over fat binaries?

#14

Post by DC-3 »

jondubois wrote: post #11

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?

Re: Why would anyone choose Docker over fat binaries?

#15

Post by open-source-ux »

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?

Re: Why would anyone choose Docker over fat binaries?

#16

Post by pebers »

supermatt wrote: post #13
KaiserPro wrote: post #9

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?

They aren't changing to Kubernetes internally. It's more of an open-source reimplementation (and modernisation) of Borg, because they don't think it's practical to open-source Borg itself.

Re: Why would anyone choose Docker over fat binaries?

#17

Post by btown »

> Docker is a tool that allows you to continue to use tools that were perfect for the1990s and early 2000s. You can create a web site using Ruby On Rails, and you’ll have tens of thousands of files, spread across hundreds of directories, and you’ll be dependent on various environmental variables. What ports are in use? What sockets do you use to talk to other apps? How does the application server talk to the web server? How could you possibly easily port this to a new server? That is where Docker comes in. It will create an artificial universe where your Rails app has everything it needs. And then you can hand around the Docker image in the same way a Golang programmer might hand around a fat binary.

Anyone who thinks that all modern web applications are made in Golang or on the JVM is in a pretty weird echo chamber. Server-side rendering with React or Angular Universal practically requires you to be running Javascript on the server, and while you can theoretically statically link V8 to Golang, it's much easier to use Node and have native code-sharing. And the reference implementation for GraphQL is in Javascript as well. Web application servers never stopped moving towards scripting languages (though arguably the microservices split from them did move towards compiled languages). So there will continue to be, for the foreseeable future, an industry-wide need for deployment of non-fat binaries with these types of dependencies. And in that case, Docker is significantly more sane than trying to synchronize all those files.

Re: Why would anyone choose Docker over fat binaries?

#19

Post by neilwilson »

Just moves the problem rather than solving it. You now have a Go dependency management problem and all the fun that causes.

It won't be long before we see Go library distributions with versions in packages and security fixes rolled out to them...

What we've missed over the years is an agreed improvement to the Unix process abstraction that the kernel manages. IPC was never solved. So now we're trying to do ipc over http with JSON

Re: Why would anyone choose Docker over fat binaries?

#20

Post by neilwilson »

chmike wrote: 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
Post reply on HN