Warp – self-contained, single binary applications
121–130 of 157 posts
Re: Warp – self-contained, single binary applications
#122 tVQhhsFFlGGD3oWV4lEPST8I8FEPP54IM0q7daes4E1y3p2U2wlJRYmWmjPYfkhZ0PlT14Ls0j8fdDkoj33f2BlRJavLj3mWGibJsGt5uLAtrCDtvxikZ8UX2mQDCrgE
Anyone know what this magic is all about?Honestly not feeling warp-packer downloading executable blobs during runtime either.
Re: Warp – self-contained, single binary applications
#123Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.
Re: Warp – self-contained, single binary applications
#124Earlier quoted context omitted.
I'm ambivalent about this. It is cool to distribute a single binary, but years ago there was serious vulnerability in a very common open source library library whose name escapes me (it wasn't libgcc, someone help a brother here). It was used in multiple programs in both Windows and Linux. On Windows there was a rush of individual updates as each application was fixed... on Linux, simply upgrading that library fixed…
I think the inverse argument can be made against shared libraries: if an update introduces a vulnerability, now all programs which depend on that library become vulnerable.
Rather than making all of those applications vulnerable at the same time, they slowly become vulnerable as the release binaries are linked against bugged code. If it's not linked at runtime, or recompiled, it'll be vulnerable forever.
Re: Warp – self-contained, single binary applications
#125tVQhhsFFlGGD3oWV4lEPST8I8FEPP54IM0q7daes4E1y3p2U2wlJRYmWmjPYfkhZ0PlT14Ls0j8fdDkoj33f2BlRJavLj3mWGibJsGt5uLAtrCDtvxikZ8UX2mQDCrgE Anyone know what this magic is all about? Honestly not feeling warp-packer downloading executable blobs during runtime either.
This is a known and established technique. I don't have the link right now (mobile) but .NET Core does something similar for their native deployment, for example.
Re: Warp – self-contained, single binary applications
#126Earlier quoted context omitted.
You can build "fat jars" that contain all dependencies. IMO, this is how most Java apps should be deployed.
You still have issues of needing a JVM. The JVM is not a small runtime considation. I'm in the process of converting to GO since I have more time than money. 1 JVM in Docker uses 512 MB to sit still. A Go version is around 16.
Is that 512 the lowest you can get it with command line options?
Re: Warp – self-contained, single binary applications
#127Earlier quoted context omitted.
Yes, I remember when it was such a big deal that we could finally use dynamic libraries on Amiga OS, MS-DOS protected mode and Windows 3.x. Even GNU/Linux made such a big deal of moving from a.out to ELF binary format, due to easier support for dynamic linking, which quite cumbersome with a.out. Now almost 30 years later it is a big deal to support static linking, go figure.
Technology goes in cycles, like humans do :)
Re: Warp – self-contained, single binary applications
#128Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.
By the way, if you are looking for a tool to embed resource files in Go binaries you might find these interesting: - https://github.com/benbjohnson/genesis - https://github.com/go-bindata/go-bindata
- https://github.com/gobuffalo/packr
I like that it allows you to `go run` without changing any code.
Re: Warp – self-contained, single binary applications
#129Re: Warp – self-contained, single binary applications
#130It's fascinating how self-contained binaries are now coveted as such a desirable feature. Dozens of languages (if not more) were capable of this decades ago. In fact, some of them could generate self-contained binaries that allowed you to bundle app assets like icons and images inside the executable - no additional add-ons needed. And they were native executables, not complicated wrappers with layer upon layer of dif…
It's understandable due to RAM, disk, and network being way less of a constraint than it used to be (which necessitated dynamic linking and shared libraries), and the modern need to ship around binaries to hundreds or thousands of servers and have them run predictably everywhere.