How many production servers have you been responsible for in your lifetime?
"There is no difference to running an executable. "
... There are these following differences.
1. That url, assuming no malicious 3rd-party/nation-state is spoofing the response, could return any different version of the installer resource at any given time.
2. That url might not always be available, for any number of reasons, and how is someone who wants to "discover" this software when they are looking through their available package list?
3. Who knows what that url is "suppose to do" ... there is no signing process, peer review process, nothing, you get whatever the apache server on the other side of that HTTP request wants to give you, and your gonna send that right into your root shell...
4. Unlike a package, sitting in my personal safe, self host, audited, self-verified debian package repository mirror ... this URL might not work tomorrow, it might not work at 3:35am when my primary server took a shit and i need to rebuild the whole stack... who knows what this URL will do in between subsequent runs... it could return 2 different things when I am trying to build a cluster of this product.
3. See 1, unspoken comparison to trusted package archives excepted.
4. Yes, getting your software into an official publishing channel is preferable, but not automatic, not immediate, and not without update latency.
I'm 110% with you on hating pipe to shell, however. Your arguments don't really address the issue.
And note also that you can just clone from github if you don't like piping to shell. And nothing prevents you from packaging it yourself in your own trusted repository. If you run serious infrastructure, you already do this.
"There is no difference to running an executable. "
... There are these following differences.
1. That url, assuming no malicious 3rd-party/nation-state is spoofing the response, could return any different version of the installer resource at any given time.
2. That url might not always be available, for any number of reasons, and how is someone who wants to "discover" this software when they are looking through their available package list?
3. Who knows what that url is "suppose to do" ... there is no signing process, peer review process, nothing, you get whatever the apache server on the other side of that HTTP request wants to give you, and your gonna send that right into your root shell...
4. Unlike a package, sitting in my personal safe, self host, audited, self-verified debian package repository mirror ... this URL might not work tomorrow, it might not work at 3:35am when my primary server took a shit and i need to rebuild the whole stack... who knows what this URL will do in between subsequent runs... it could return 2 different things when I am trying to build a cluster of this product.