3 ms·
We already have that, it's called a package manager. The concept has a number of problems (multiple runtime versions for multiple programs, who pays for and con
by toyg 4y ago
We already have that, it's called a package manager. The concept has a number of problems (multiple runtime versions for multiple programs, who pays for and controls the repository, etc etc).
- luxoramonrising 4y ago> multiple runtime versions for multiple programs For Java, the latest one. Current latest java still runs 20 year old jars. > who pays for and controls the repository The OS distributor.
- adra 4y ago"For Java, the latest one. Current latest java still runs 20 year old jars." Not necessarily anymore. Many of the standard JVM features were removed in 11+ instances, so things like _some_ of the JVMs JMX APIs were removed for one reason or other. I'm not saying the removals weren't justified, simply clarifying that not all java applications written N years ago are still entirely supported.
- toyg 4y ago> Current latest java still runs 20 year old jars. Dude, I've been using Java since 1.2. Sure, all versions will try to "run" anything, but they'll do that with all sorts of slight differences and incompatibilities in behaviour - which make it effectively impractical for any serious program to run on anything but a small subset of tried and tested versions. > The OS distributor Careful what you wish for. Do you really want to hand Microsoft the power to decide which runtimes are allowed to run on Windows...?
- captainmuon 4y agoI don't know, my package manager doesn't let me download an application without runtime - say QBittorrent without Qt or Deluge without Gtk and Python - double click on an icon, and then say "It looks like you are trying to <strike>write a letter</strike> run an app that needs a library" and then proceeds to fetch it... from my package manager. I mean, 80/20 principle. You would only have to write code for the dozen or so runtimes, and then add metadata for a few hundred or so popular apps. Totally in reach for a volunteer community (like many distros, or stuff like PortableApps) and especially for a companies like Canonical or Microsoft. And then when it is going, people would add metadata to their apps themselves, and we would no longer have to ship the runtimes together with the apps. Think of the metadata it like a 21st century shebang line. Not `#!/usr/bin/env python`, but `#"§% require python>3.9 and gtk-stack>4.0` or `require java-xxx`.
- toyg 4y ago> my package manager doesn't let me download an application without runtime That's not true (most package managers have options to force downloads without dependencies), but anyway why would you even want to do that, considering you eventually have to download the runtime anyway...? > And then when it is going, people would add metadata to their apps themselves, and we would no longer have to ship the runtimes together with the apps. We had that too, it's Java Web Start and the current MS equivalent (clickonce or whatever it's called). Never worked particularly well for Java (which is why it was removed), works a bit better for Windows because, surprise surprise, the OS vendor made deployment conditions more predictable, as it controls both OS and runtimes. They would never have an incentive to provide the same to third-party runtimes. > Think of the metadata it like a 21st century shebang line. The problems of that approach are legion. The hard truth is that shared libraries (and hence shared runtimes) are an accident of history, meant to cope with a scarcity of storage and bandwidth that we've long overcome. The ideal program is a single static executable that Just Runs regardless of what is going on around it. Everything else is a source of unnecessary complexity for both user and developer.