Warp – self-contained, single binary applications
1–10 of 157 posts
Re: Warp – self-contained, single binary applications
#2This sounds like a much less general binctr [0].
I don't see how warp handles the most trivial case of a dynamically linked executable; I see no references to patchelf or other such tricks to ensure it looks within the application's cache directory for dynamically linked libraries, nor do I see any mount namespaces.
Does warp do that? Why would I use warp if it doesn't when there are more generic solutions that can handle such a case, namely binctr, docker, guix pack, nix....
Re: Warp – self-contained, single binary applications
#3Beautiful
Re: Warp – self-contained, single binary applications
#4Very 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
#5This sounds like a much less general binctr [0]. I don't see how warp handles the most trivial case of a dynamically linked executable; I see no references to patchelf or other such tricks to ensure it looks within the application's cache directory for dynamically linked libraries, nor do I see any mount namespaces. Does warp do that? Why would I use warp if it doesn't when there are more generic solutions that can h…
> This sounds like a much less general binctr.
binctr is Linux-only, and appears to need Docker as a runtime requirement? This has neither constraint, apparently?
Re: Warp – self-contained, single binary applications
#6Based on the readme, this is basically an SFX archive, which runs a binary upon completion of extraction to temporary folder, much like winzip & the like have created for ages.
Re: Warp – self-contained, single binary applications
#7This sounds like a much less general binctr [0]. I don't see how warp handles the most trivial case of a dynamically linked executable; I see no references to patchelf or other such tricks to ensure it looks within the application's cache directory for dynamically linked libraries, nor do I see any mount namespaces. Does warp do that? Why would I use warp if it doesn't when there are more generic solutions that can h…
> This sounds like a much less general binctr. binctr is Linux-only, and appears to need Docker as a runtime requirement? This has neither constraint, apparently?
> appears to need Docker as a runtime requirement
binctr does not require any runtime component other than a modern linux kernel with unprivileged usernamespace support.
Targetting OSX / Windows does make warp distinct from what I mentioned, though I don't use those OSs so I admit I didn't think about that possible issue.
Anyway, I thought this was a solved problem on both Windows and OSX since they both have conventions for self-contained applications, while linux does not.
Re: Warp – self-contained, single binary applications
#8Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.
I wish also had this. However, containers work. Not sure why they do java though, i thought java has been happy with jars so far.
Re: Warp – self-contained, single binary applications
#9From the README, it looks like this unpacks the application and dependencies into a local cache in the user's home directory on first run.
Is it possible to instead execute the compressed application code directly and present to the resulting process a virtualized file system that decompresses the dependencies on the fly too? Then you could run the single binary without giving it any filesystem access. One way to do it would be to have have the parent process provide some routine that the kernel can call for reading a particular "file". Or perhaps just have standard embedding and compression methods that the kernel supports, so you would just provide the offsets to the kernel.
I guess what I mean is: do any platforms provide the necessary syscalls to pull that off?
Re: Warp – self-contained, single binary applications
#10Earlier quoted context omitted.
> This sounds like a much less general binctr. binctr is Linux-only, and appears to need Docker as a runtime requirement? This has neither constraint, apparently?
> appears to need Docker as a runtime requirement binctr does not require any runtime component other than a modern linux kernel with unprivileged usernamespace support. Targetting OSX / Windows does make warp distinct from what I mentioned, though I don't use those OSs so I admit I didn't think about that possible issue. Anyway, I thought this was a solved problem on both Windows and OSX since they both have convent…
Anyway, I thought this was a solved problem on both Windows and OSX since they both have conventions for self-contained applications, while linux does not.
This is mistaken for Windows. Even if programs are run from Program Files, they will often source their DLLs from other locations.