41–50 of 180 posts
Fat binaries solve one of the problems which Docker containers solve. It doesn't solve the security isolation problem, or the resource control issue. That being said, there are many people who are using Docker primarily to solve the DLL hell problem of shared libraries. And containers don't really provide that great of a solution as far as security is concerned; VM's will also be more secure. And the statement that t…
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 fil…
On macOS / OS X, it’s actually a .app folder
Fat binaries solve one of the problems which Docker containers solve. It doesn't solve the security isolation problem, or the resource control issue. That being said, there are many people who are using Docker primarily to solve the DLL hell problem of shared libraries. And containers don't really provide that great of a solution as far as security is concerned; VM's will also be more secure. And the statement that t…
The "DLL hell" problem is not the only problem it solves, but it is the only problem that docker solves reasonably well.
Storage (and file system uids), networking, are all elements of the outer system that inevitably leak in the container. Using just Docker does not save you from having to deal with those, and IMHO, those are the really hard problems.
The article makes sense if portability was the only reason to use containers. Fat binaries solve the portability problem in a way that may or may not make sense for a given project, but fat binariries don’t address any of the other issues that container technologies provide solutions for (sandboxing, resource management, etc.). Either the author isn’t aware of these other issues, or is purposefully sweeping them unde…
> 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 serv…
(I'm replying to clarify - not sure if I agree. I'm a Python guy - I think everyone should switch to languages with significant white space ;-) )
It's a bit idealistic to think people can "just" use fat binaries; sure, Go mostly handles that (not completely; by default most nontrivial Go apps are dynamic, which you can fix but not that easily) but that's not exactly any comfort if I've got 30,000 lines of Python which I'm not keen on rewriting. Technologies like pex can help but in practice require some work, especially with a codebase that hasn't been written…
Why take an all-or-nothing approach when you could pick the best of both approaches and use them in tandem? :)
* We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me.
* sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server.
* Its possible for me to namespace everything myself with unshare(1) and "ip netns" and cgroups and chroot and iptables... but that would consume all my available time. Docker can do that for me.
* When you reach more then 20 or so services to keep track of, you need tools to help you out.
* load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier.
Isn't Kubernetes build around etcd?
I really don't get this blogpost, it seems like "I don't have this problem, so nobody else has."