A lot of Java software is "(1) download the jar file, (2) java -jar thefile.jar". Agree it's good for the user, but when people talk about distributing a statically-linked program the "what about security updates" question invariably comes up.
As long as it's behind and simple interface and it works, I don't care what it actually does.
A minimum amount of care when installing things (checking signatures/checksums, reading install scripts, etc) should be common sense and not doing that is grossly negligent.
At the minimum I want to know what it does and where it puts stuff.
This assumes that the software package itself is trusted, which is (still?) a reasonable assumption to make for open-source and big name companies.
By the way, it's poor form to downvote someone just for disagreeing with them.
Security is about defense in depth, not just "don't run anything you haven't read in detail" - have you read the code of the web browser you posted with?
(2) run bin/whatever which is a 500 line bash script for setting up the jvm environment that has a 50% chance of not working if you are on a distro that's not Ubuntu or RHEL, and probably also fails if it takes a filename and you give it a filename containing a space.
"Make sure you're running Gogs 1.64.2 or above"
"Make sure you're running Gogs 1.64.2, OpenSSL 1.2e, libcrypt 3.73, leftpad 2.0..."
Especially when the deployment of said binaries doesn't involve anything installed on the host OS.
"Make sure you update to OpenSSL 1.2e and restart all services."
If you think of more than one program using the same module, shared libraries make a lot of sense.
Of course, if the user chooses to install software outside of the package manager, it is their responsibility to upgrade dependencies accordingly.
You'd be surprised how many users have no idea whether they are running the 32bit or 64bit version of their OS. For them, running a Go binary will be anything but easy.
How operating systems handle updates is unrelated to Java, and affects other applications on the system as well. Think about other "run anywhere" technology like Flash, PDF (Adobe Reader), Microsoft Office, Browsers -- they also don't have a great security story and need constant updates. Adobe and Sun decided to ship their software with "Update Managers". Everybody loved them (not), but at least they fulfilled their purpose. 10 years later, Google added background updates with binary patching to Chrome on Windows and Mac OS (not needed on Linux). They decided to just install updates without the user's consent, because that will at least keep them safe. Google can get away with it because everybody expects them to know what they're doing. But I certainly don't want downloading code at runtime to become the norm.
That's why distributing updates for third-party apps should be an operating system feature, as it is in all popular Linux distributions. Microsoft and Apple, please feel free to copy.
That's exactly what I meant when I said
> Yeah, the missing bit is that this should be done by OS vendors which sadly is not true.
Usually you get the option to use the bundled one or whatever is available if one is detected already on the system.
To the point that is one of the options of the new Java application packer introduced with Java 8.
Also in all server deployments that we do for our customers, Java is just another configuration of the whole application packaging.
Also many companies don't mind paying for commercial Java AOT compilers to native code, which then puts their Java code in the same league as Go.
Because some Salesforce product required a specific version of Java and Oracle's PMS software required a specific, different version of Java. And both vendors only support their products by having it run with only the correct version of Java installed.
And then I have this VM with this ancient version of Java I can't even find for download any more so that I can use the management interface for Brocade FC switches.