Hacker News Reader

Comment by djsumdog | Hacker News Reader

Yea, I agree. I personally think that this is a huge step backwards.

Look at Android and MacOS. You have these self contained packaging things that contain all their dependencies. You have the same dependencies in each package. You have a TON of wasted space with packages that have the exact same built-in libraries and jar files.

Especially with Android, they could have made a real package dependency system, with slotted installs of all the jar/jar-versions from the official maven repos. When you install and app, it could install all its dependent jars. You'd still be able to do multiple versions of each of those jars, probably easier than it is with standard .so/.dll libraries.

Projects like this are a huge step backwards is terms of DRY principals and general package management.

View on HN

Is space really an issue in most non-mobile user devices nowadays? Consider the tradeoffs: a bit of space vs. packaging nightmare which results in old, buggy and insecure packages. This was posted a few days back on hn: https://statuscode.ch/2016/02/distribution-packages-consider...

I am not sure if the whole jar package dependency management would work under ART.

I wastes memory too, having multiple copies of the same shared libraries loaded.

Memory spend on executables isn't a bottleneck even on mobile. You are getting into embedded territory for this to become an issue.

I really hate that people have this idea. It's why people create apps which consist of a built in web server their own copy of chrome that connects to said server.

In the end something that ought to have taken 10mb of space and 20mb of ram requires 100mb of space and half a gig of ram and still manages to be slow on a new system at operations that ought to have been fast on a ten year old machine.

Down with the Javascript generation.

I've been spending a lot of time in the embedded area lately (sub-200Mhz 32k RAM automotive systems, firmware and fpgas) and I agree with you. But there's always tradeoffs. In this case you're trading some memory (which is cheap nowadays) for up-to-date, secure, usable apps, which seems to be a pretty complex thing to do. Nobody solved it so far. The people using node-webkit are offloading the library compatibility issues to the people who built Chromium and are provided with a consistent container to run their application in.

Or in other words, they use a poor man's Java vm, except bigger and more fragile.

To be honest, chrome-"native"-packaged-webapps, or what you wanna call them, feels a whole lot better to use than any java based GUI app I have ever used, including JetBrains products.

I hate to use any of these chrome-"native"-packaged-webapp, though. I just hate java based GUI apps more.

The software that we build tends to gain layers. In theory, each layer adds new functionality that couldn't be done on a lower layer. The problem comes when someone unnecessarily implements lower functionality in an upper layer (like reading local files through a web server). It happens because systems are too complex now for a specific dev to know every layer, and new hardware is fast enough that it doesn't matter that you're taking an order of magnitude more resources than you actually need to do the task.

Not so. This matters at scale too. Multiplied by ten thousand nodes, a 50MB wasted RSS becomes half a terabyte of unnecessarily procured silicon. I don't want to pay that tax.

Android and MacOS each have a lot more users than desktop Linux, a lot more applications packaged, and applications get updated in a more timely fashion. Obviously that's not all down to a difference in packaging, but it does seem like the inefficiency of duplicated dependencies isn't all that big a problem.

Android also runs on phones that still mostly have less storage and less RAM than our desktops, so you'd expect saving space to be even more important for Android.

Reply on news.ycombinator.com