Warp – self-contained, single binary applications • Hacker News Board

Re: Warp – self-contained, single binary applications

#51

Post by Koshkin » Fri, Oct 12, 2018, 9:59 PM UTC

weberc2 wrote: post #40

Koshkin wrote: post #32

Earlier quoted context omitted.

Things are more complicated than that. (Depending on the pricing scheme, you might end up paying per gigabyte per hour, for example; which may or may not include transfer/storage of actual data; a faster "drive" could be much more expensive than a slower one, etc.)

Sorry, I'm not following. Granted pricing schemes have changed, but adjusting for that, are you claiming that disk is not dramatically cheaper than it was ~20 years ago? Not trying to be a dick, just not following your point.

Point is, "disk" in the cloud is not the same thing as the disk in your PC.

Re: Warp – self-contained, single binary applications

#52

Post by the8472 » Fri, Oct 12, 2018, 10:05 PM UTC

wildmusings wrote: post #9

From 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…

Yes, on linux you could do this with FUSE, in principle you would still need one empty temporary directory as mountpoint, but that can be placed in a tmpfs, e.g. under /run/user/ by convention.

Re: Warp – self-contained, single binary applications

#53

Post by GordonS » Fri, Oct 12, 2018, 10:06 PM UTC

rictic wrote: post #47

monocasa wrote: post #27

Earlier quoted context omitted.

There's something to be said for the fact that these are native binaries. Like under windows you'd be able just call CreateProcess with the file. Jars never did that and intrinsically needed an interpreter to run them.

This. A .jar file could be anything. Is it a library or an executable? When I run it, do I need to make sure its dependencies are on my classpath? What're the java command line flags I need? Do I have the right version of java on this machine? There's something to be said for an entirely self-contained native binary, at least as an easy on-ramp for users.

Unfortunately, it turns out this is not a completely self contained binary - it's more of a packer. So if you pack a Java app, you're still going to need the JRE, and if you pack a .NET Framework app, you're still going the .NET Framework, etc.

Re: Warp – self-contained, single binary applications

#54

Post by jungler » Fri, Oct 12, 2018, 10:07 PM UTC

tomatocracy wrote: post #36

IanCal wrote: post #17

Earlier quoted context omitted.

> This is not take anything away from this project, just making an observation. The programming field often feels like it's in a giant loop constantly re-discovering what went before. I think part of this comes from various tradeoffs becoming more or less important at different times. Processing power goes up so you move to fat clients, then people move to battery powered devices and heavy lifting makes more sense on…

It's not really processing power so much as storage and RAM that used to be seen as the disadvantages of static binaries. The advantages of the static binary model are that it avoids "DLL hell" and makes sourcing dependencies a bit better, which are indeed laudable aims. But nowadays it has terrible security (and to some extent reliability) trade-offs - if everything is a static binary and there's a security issue in…

From the POV of folks working around massive server farms, all the servers are disposable, so having one binary is convenient, and the short lifespans mean they avoid the downsides.

The concern has more relevance to client applications, but then the cost becomes related to update strategy, and if every app is tied to an update manager process(whether it's an app store type of thing or a custom one) then the thinking becomes similar to the cloud server setup: Why bother, I'm going to blow it all away in the next update.

When the dependency management is exposed to users, there's a much bigger surface area for troubleshooting and support. It makes sense that devs favor static if they expect the whole environment to be disposable. It isn't like it was in the 90's, where patching was occasional but major new versions were essentially new products.

Re: Warp – self-contained, single binary applications

#55

Post by icedchai » Fri, Oct 12, 2018, 10:16 PM UTC

rictic wrote: post #47

monocasa wrote: post #27

Earlier quoted context omitted.

There's something to be said for the fact that these are native binaries. Like under windows you'd be able just call CreateProcess with the file. Jars never did that and intrinsically needed an interpreter to run them.

This. A .jar file could be anything. Is it a library or an executable? When I run it, do I need to make sure its dependencies are on my classpath? What're the java command line flags I need? Do I have the right version of java on this machine? There's something to be said for an entirely self-contained native binary, at least as an easy on-ramp for users.

You can build "fat jars" that contain all dependencies. IMO, this is how most Java apps should be deployed.

Re: Warp – self-contained, single binary applications

#56

Post by tedivm » Fri, Oct 12, 2018, 10:20 PM UTC

mychael wrote: post #46

What problem does this solve? How does it differ from Docker?

Docker isn't really used for desktop applications. Docker also requires a daemon (and on OSX a full virtual machine) to run.

A better analogy for this system would be jar files that allow more languages than just java.

Re: Warp – self-contained, single binary applications

#57

Post by ecnahc515 » Fri, Oct 12, 2018, 10:21 PM UTC

Koshkin wrote: post #51

weberc2 wrote: post #40

Earlier quoted context omitted.

Sorry, I'm not following. Granted pricing schemes have changed, but adjusting for that, are you claiming that disk is not dramatically cheaper than it was ~20 years ago? Not trying to be a dick, just not following your point.

Point is, "disk" in the cloud is not the same thing as the disk in your PC.

No, the point is it doesn't matter where the disk is, the overall price has gone down.

Re: Warp – self-contained, single binary applications

#58

Post by artursapek » Fri, Oct 12, 2018, 10:23 PM UTC

eeZah7Ux wrote: post #28

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?

Vendorizing libraries and static linking has become a security hell. Just an example: https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...

That doesn't mention linking at all.

Re: Warp – self-contained, single binary applications

#59

Post by ecnahc515 » Fri, Oct 12, 2018, 10:23 PM UTC

tomatocracy wrote: post #36

IanCal wrote: post #17

Earlier quoted context omitted.

> This is not take anything away from this project, just making an observation. The programming field often feels like it's in a giant loop constantly re-discovering what went before. I think part of this comes from various tradeoffs becoming more or less important at different times. Processing power goes up so you move to fat clients, then people move to battery powered devices and heavy lifting makes more sense on…

It's not really processing power so much as storage and RAM that used to be seen as the disadvantages of static binaries. The advantages of the static binary model are that it avoids "DLL hell" and makes sourcing dependencies a bit better, which are indeed laudable aims. But nowadays it has terrible security (and to some extent reliability) trade-offs - if everything is a static binary and there's a security issue in…

You can also see it as a security gain because you now can upgrade things independently without fear of how that may propagate to other applications. Being able to upgrade rapidly is the single best way to improve security. With DLLs people take a lot more time to upgrade because the risk is so high, meaning systems sit with older less-secure versions for longer.

Re: Warp – self-contained, single binary applications

#60

Post by TheDong » Fri, Oct 12, 2018, 10:24 PM UTC

weberc2 wrote: post #23

jpic wrote: post #8

Earlier quoted context omitted.

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.

We're struggling using containers for our Python and Javascript applications. I think we're using venvs and node_modules and we oughtn't (or we shouldn't keep them in our project directory where they sometimes--but not always--get overwritten by source code volume mounts).

It can be a little tricky to do things right here.

There are a few things of note:

1. The .dockerignore file can be used to prevent use of your `node_modules` folder during `docker build`, even if you have something like `COPY . .` in your Dockerfile.. This can let you create a new `node_modules` folder from your lockfile as part of the docker build process to create an image for testing/deployment.

2. You can maintain separate Dockerfiles and such for development and for release, so e.g. for development you might use volumes and not copy things in, but for release you wouldn't use volumes for source code.

I can't tell from what you said, but it seems like one of those two tips might be relevant.

It's okay to have a development setup which doesn't use containers and then use containers for deployment (so long as you have an integ or staging environment that uses containers) as well. It's quite reasonable to have a venv during development, but inside the docker image to not use a venv at all since things will already be reasonably isolated inside the container's fs.