Containers are popular right now for the same reason statically linking is. But it gives you something half way in between. Static linking is really hard to do right. Even go's "static link all the things" is incomplete. if you run ldd on a go binary, it isn't actually static. Containers ensure the stuff inside really is statically linked.
So these days, I'd rather use docker for gaining the static linking like functionality rather then try really hard to get a single ".exe" that has 0 dependencies. Its very hard. That being said, the distro's have a big point about deps being handled dynamically so that the problem of vulnerability/bug patching is tractable. At the moment, Docker or any statically linking thing doesn't have a good solution to the problem. The importance of this issue can't be understated. It can be fixed, but there isn't a project I'm aware of yet to commonly solve it. Building containers using distro packages I think is a part of the solution. You can then much more easily find which containers are out of date/have vulnerabilities. but you still need machinery to scan for updates, rebuild containers, and a way to push them out to all the places that need updating. Until those things are solved, or you have operators that very very carefully pay attention, traditional distro's have a strong thing going for them in the security realm. Go's statically linking everything is an anti-feature in my opinion, better left to systems like Docker. Thanks, Kevin ________________________________ From: Dean Troyer [dtro...@gmail.com] Sent: Friday, May 20, 2016 5:48 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [tc] supporting Go On Fri, May 20, 2016 at 5:42 AM, Thomas Goirand <z...@debian.org<mailto:z...@debian.org>> wrote: I am *NOT* buying that doing static linking is a progress. We're back 30 years in the past, before the .so format. It is amazing that some of us think it's better. It simply isn't. It's a huge regression, for package maintainers, system admins, production/ops, and our final users. The only group of people who like it are developers, because they just don't need to care about shared library API/ABI incompatibilities and regressions anymore. I disagree, there are certainly places static linking is appropriate, however, I didn't mention that at all. Much of the burden with Python dependency at install/run time is due to NO linking. Even with C, you make choices at build time WRT what you link against, either statically or dynamically. Even with shared libs, when the interface changes you have to re-link everything that uses that interface. It is not as black and white as you suggest. And I say that as a user, who so desperately wants an install process for OSC to match PuTTY on Windows: 1) copy an .exe; 2) run it. dt [Thomas, I have done _EVERY_ one of the jobs above that you listed, as a $DAY_JOB, and know exactly what it takes to run production-scale services built from everything from vendor packages to house-built source. It would be nice if you refined your argument to stop leaning on static linking as the biggest problem since stack overflows. There are other reasons this might be a bad idea, but I sense that you are losing traction fixating on only this one.] -- Dean Troyer dtro...@gmail.com<mailto:dtro...@gmail.com>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
