Live data from Hacker News

Warp – self-contained, single binary applications

github.com

121–130 of 157 posts

Re: Warp – self-contained, single binary applications

#124
post #76

Earlier 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.

Security problems often exist for years at a time.

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

#125

tVQhhsFFlGGD3oWV4lEPST8I8FEPP54IM0q7daes4E1y3p2U2wlJRYmWmjPYfkhZ0PlT14Ls0j8fdDkoj33f2BlRJavLj3mWGibJsGt5uLAtrCDtvxikZ8UX2mQDCrgE Anyone know what this magic is all about? Honestly not feeling warp-packer downloading executable blobs during runtime either.

It's a placeholder in the final binary that gets replaced by the target application executable file name so Warp knows what to run.

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

#126

Earlier 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.

Java is somewhat like chrome in that it pre-emptively gets some RAM, because it's managing memory allocation to programs itself. (and because the speed increase of not doing system-calls offsets some of the performance hits from running a JIT)

Is that 512 the lowest you can get it with command line options?

Re: Warp – self-contained, single binary applications

#127
post #34

Earlier 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 :)

Yeah, like renaissance rediscovering Roman and Greek tech.

Re: Warp – self-contained, single binary applications

#128
post #4

Very 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

I've not used those two but have always had success with

- 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

#130
post #21

It'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.

Maybe it better to use DLL and ship to tens of thousands of servers instead.
Post reply on HN