Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warp – self-contained, single binary applications

github.com

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Warp – self-contained, single binary applications

#131

Post by pbhjpbhj »

sandGorgon wrote: post #120

The best of breed here is zeroinstall - https://0install.net/ . The software catalog is here - http://0install.de/catalog/ comes with its own SAT solver for dependency resolution. zeroinstall is what Canonical was considering before it created Snap Packages.

Any idea why they went with snap instead? There seems to have been a recent proliferation of new packaging systems -- which is fine. But, from an Ubuntu perspective I don't think they should be included if they're not integrated with apt (perhaps it is and I missed the memo?).

Digikam moved to AppImage, which sounds cool but adds a further system one needs to update, and the automatic update never worked for me (I think their package didn't include the necessary metadata?).

Having all application updates available in one place, and official packages be recent, is the 'killer feature' for me. I used to be a Slackware user, but when I migrated to slapt-get I realised I was done with rolling my own packages and checkinstall-ing them and wanted system where things were more managed - not having half the apps installed ad-hoc.

When you have to install a new system to get just a few apps it feels like I might as well go back to ./configure;make;[check|make ]install.

Seems we need an xdg install record with a unified app that calls the sub-system (pip, 0install, AppImage, shell script, dpkg, whatever) to abstract all that away.

Re: Warp – self-contained, single binary applications

#132

Post by diggernet »

metaphor wrote: post #122

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

Good point about the downloading. Warp-packer should have all the warp-runners installed locally with it. Or at the very least they should be packages you install depending on your target platforms.

Re: Warp – self-contained, single binary applications

#133

Post by jobigoud »

tgtweak wrote: post #63

Latest .net core 3 apparently supports single-bibary packaging. It has been a often-requested feature for at least 2 years. https://github.com/dotnet/corefx/issues/13329 (The last comment referring to warp is indicative)

You can do this in regular .NET already using Costura Fody. It puts the DLLs (native or managed) as resources and load them at runtime.

https://github.com/Fody/Costura

Re: Warp – self-contained, single binary applications

#135

Post by jjnoakes »

wahern wrote: post #116
weberc2 wrote: post #37

Earlier quoted context omitted.

Your link cites "little thought to the inclusion of dependencies", _not_ static linkage, as the cause of this "hell".

The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system. If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fi…

Is this always true? If the shared library you linked to uses symbol versions and the bug fix requires a new version of a symbol, the application has to be relinked anyway. Same as static linking, except now it is not obvious you need to relink to get the bug fix.

Re: Warp – self-contained, single binary applications

#136

Post by shaan7 »

weberc2 wrote: post #15
open-source-ux wrote: post #11

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…

> The programming field often feels like it's in a giant loop constantly re-discovering what went before. It might feel that way, but this is driven by economics. Basically disk, memory, and bandwidth is far cheaper than it used to be so who cares if you waste a GB or so copying the same libraries all over if you don't have to solve for dependency hell?

> so who cares if you waste a GB or so

I wonder if that sounds arrogant to just me. As a user I DO CARE. Its frustrating to find applications shipping their own copy of libraries wasting precious disk space. When I was using a Mac, I had at least 4 applications shipping their own copy of Qt5.4 ... aaaarrgh

Back on the Linux desktop, package managers handle this beautifully. And for the cases where you need to skip the distro, Flatpak still lets you use system dependencies. Everyone wins.

And for whoever claims storage is cheap, please link me the magical place you're buying yours from. Thanks.

Re: Warp – self-contained, single binary applications

#137

Post by weberc2 »

wahern wrote: post #116
weberc2 wrote: post #37

Earlier quoted context omitted.

Your link cites "little thought to the inclusion of dependencies", _not_ static linkage, as the cause of this "hell".

The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system. If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fi…

> The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system.

I don't buy this argument; it's every bit as easy to `pip install` something as it is to `go get` something.

> If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fixed by a simple `apt-get upgrade` or `yum update`.

I think the fix is fairly trivial; package maintainers just need to introduce vuln scanning into their automation. As soon as a security issue pops up for one of their dependencies, their automation automatically compiles a new version and publishes it to the package registry so the end user can pull it down with their next `apt-get upgrade` or `yum update` or whathaveyou.

Re: Warp – self-contained, single binary applications

#138

Post by paulddraper »

salmo wrote: post #99
paulddraper wrote: post #96

Earlier quoted context omitted.

> I think it’s funny to use java as an example when jar files have been around forever. ? Jar files are not a self-contained, single binary (executable). I can't curl -o binary http://example.org/binary ./binary

In reality, you can't do that with these either. You have to have the runtime installed before your example works. It's really not much better than running a fat jar that contains all of its dependencies. curl -o binary.jar http://example.org/binary.jar java -jar binary.jar This is more like a self-extracting shell script, but more opaque.

You might be right, but documentation says "self-contained".

How is it self-contained if it's not self-contained?

Re: Warp – self-contained, single binary applications

#139

Post by AnIdiotOnTheNet »

shaan7 wrote: post #136
weberc2 wrote: post #15

Earlier quoted context omitted.

> The programming field often feels like it's in a giant loop constantly re-discovering what went before. It might feel that way, but this is driven by economics. Basically disk, memory, and bandwidth is far cheaper than it used to be so who cares if you waste a GB or so copying the same libraries all over if you don't have to solve for dependency hell?

> so who cares if you waste a GB or so I wonder if that sounds arrogant to just me. As a user I DO CARE. Its frustrating to find applications shipping their own copy of libraries wasting precious disk space. When I was using a Mac, I had at least 4 applications shipping their own copy of Qt5.4 ... aaaarrgh Back on the Linux desktop, package managers handle this beautifully. And for the cases where you need to skip th…

Package managers come with their own limitations. You can't have multiple versions of the same application, packages are often out of date, packages sometimes conflict, you can't choose where applications are installed, etc.

And storage is ridiculously cheap. You can get an 8TB HDD for $150[0]. Or a 1TB SSD for the same price[1].

[0]https://www.amazon.com/Seagate-Expansion-Desktop-External-ST...

[1]https://www.amazon.com/Blue-NAND-1TB-SSD-WDS100T2B0A/dp/B073...

Re: Warp – self-contained, single binary applications

#140

Post by virmundi »

flingo wrote: post #126
virmundi wrote: post #100

Earlier quoted context omitted.

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?

That was with Xmx set to 64 MB and a stack of 256k
Post reply on HN