4 ms·

>curl -sSL https://hyper.sh/install https://hyper.sh/install | bash Seriously? Developers need to stop sprouting this crap as an install method. Nobody in the

>curl -sSL https://hyper.sh/install https://hyper.sh/install | bash Seriously? Developers need to stop sprouting this crap as an install method. Nobody in their sane mine should curl a script into bash to install a product.

quesera 11y ago
That can be fixed in 30 seconds. The product is impressive, and it would be respectful to communicate your valid message respectfully.
jaytaylor 11y ago
I think it would've been cooler if the url were https://install.hyper.sh https://install.hyper.sh ;)
- gnawux 11y ago
  you can try it now ;) cheers
Meai 11y ago
There is no difference to running an executable. In fact, this is the BEST way to offer installation to users. He is literally showing you the source code so you can decide whether you actually want to run it or not. This stupid meme of not wanting to run scripts is just that: a meme.
- panhandlr 11y ago
  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.
  - quesera 11y ago
    0. Thousands. Tens of thousands, probably. 1. True of any download link as well. 2. See 1. 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.
- tbronchain 11y ago
  Hi, you can view, download, and install from source code by checking out our github https://github.com/hyperhq/hyper https://github.com/hyperhq/hyper
- eropple 11y ago
  Even if you buy that encouraging users to uncritically pipe code to bash is a good idea - and I do not - this method of doing the curl/bash thing will very happily execute only a partial script if curl is interrupted in the middle. So, no, it's very unambiguously not the "best" option, and maybe you should chill out a whole bunch, yeah?
- tlrobinson 11y ago
  While I'm not in the "'curl | sh' is evil" camp, it's certainly not as secure as installing a cryptographically-signed package (assuming you verify the signatures). HTTPS helps, but doesn't protect against a compromised server.
zobzu 11y ago
to be honest, without a one liner install method you don't reach people. most will blindly click this even thus its quite terrible. certainly a better method is needed, but none of the alternatives provide "1 click install" like curl | bash, and as long as it's the case we'll see that..
- resouer 11y ago
  After read through the install scripts, I admit I really like this method. Doesn't know why guys argues about that. If you need specific version or release, just checkout it out from github, after all, it's opensource man.
panhandlr 11y ago
"Nobody in their sane mine should curl a script into bash to install a product" This, so much this. I was actually extremely excited over a similar product "flynn"... but they have also lost their mind when it comes to installation: https://flynn.io/docs/installation https://flynn.io/docs/installation > sudo bash < <(curl -fsSL https://dl.flynn.io/install-flynn https://dl.flynn.io/install-flynn) Seriously? How is that any easier than just providing a package for any given distro? I mean, for fucks sake, just give me the URL to a tarball with a fucking Makefile in it. I can handle the rest, thank you very much. The security concerns alone should force any sane system engineer to never pipe curl to sudo'ed bash process.
- icebraining 11y ago
  Would a zip with a Makefile do? Here: https://github.com/flynn/flynn/archive/master.zip https://github.com/flynn/flynn/archive/master.zip They have the source on Github, you're never forced to pipe curl to bash, it's just the default. Not a great default, admittedly, but hardly deserving all the hate. How about contributing a PR with a script that produces OS packages, instead of complaining that the free cake doesn't come with a cherry on top?
  - pekk 11y ago
    I guess people are upset that this is the "officially sanctioned" way of installing the tool.
VieElm 11y ago
That's a serious bash script. That's the craziest bash script I've ever seen. It's like a full program. It is terrifying.
- quesera 11y ago
  Just to counterbalance your fear: it's really nothing special or weird. It looks pretty straightforward, honestly.
sagichmal 11y ago
Like it or not, this has become the canonical way of installing infrastructural software onto your development machine in the Docker (container) ecosystem. Of course, a competent ops dev would never do this in a production system. But for splash intros on marketing websites, yeah — this strom und drang about how it's incorrigible is getting a bit long in the tooth.

quesera 11y ago

That can be fixed in 30 seconds. The product is impressive, and it would be respectful to communicate your valid message respectfully.

jaytaylor 11y ago

I think it would've been cooler if the url were https://install.hyper.sh https://install.hyper.sh ;)

gnawux 11y ago
you can try it now ;) cheers

Meai 11y ago

There is no difference to running an executable. In fact, this is the BEST way to offer installation to users. He is literally showing you the source code so you can decide whether you actually want to run it or not. This stupid meme of not wanting to run scripts is just that: a meme.

panhandlr 11y ago
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.
- quesera 11y ago
  0. Thousands. Tens of thousands, probably. 1. True of any download link as well. 2. See 1. 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.
tbronchain 11y ago
Hi, you can view, download, and install from source code by checking out our github https://github.com/hyperhq/hyper https://github.com/hyperhq/hyper
eropple 11y ago
Even if you buy that encouraging users to uncritically pipe code to bash is a good idea - and I do not - this method of doing the curl/bash thing will very happily execute only a partial script if curl is interrupted in the middle. So, no, it's very unambiguously not the "best" option, and maybe you should chill out a whole bunch, yeah?
tlrobinson 11y ago
While I'm not in the "'curl | sh' is evil" camp, it's certainly not as secure as installing a cryptographically-signed package (assuming you verify the signatures). HTTPS helps, but doesn't protect against a compromised server.

zobzu 11y ago

to be honest, without a one liner install method you don't reach people. most will blindly click this even thus its quite terrible. certainly a better method is needed, but none of the alternatives provide "1 click install" like curl | bash, and as long as it's the case we'll see that..

resouer 11y ago
After read through the install scripts, I admit I really like this method. Doesn't know why guys argues about that. If you need specific version or release, just checkout it out from github, after all, it's opensource man.

panhandlr 11y ago

"Nobody in their sane mine should curl a script into bash to install a product" This, so much this. I was actually extremely excited over a similar product "flynn"... but they have also lost their mind when it comes to installation: https://flynn.io/docs/installation https://flynn.io/docs/installation > sudo bash < <(curl -fsSL https://dl.flynn.io/install-flynn https://dl.flynn.io/install-flynn) Seriously? How is that any easier than just providing a package for any given distro? I mean, for fucks sake, just give me the URL to a tarball with a fucking Makefile in it. I can handle the rest, thank you very much. The security concerns alone should force any sane system engineer to never pipe curl to sudo'ed bash process.

icebraining 11y ago
Would a zip with a Makefile do? Here: https://github.com/flynn/flynn/archive/master.zip https://github.com/flynn/flynn/archive/master.zip They have the source on Github, you're never forced to pipe curl to bash, it's just the default. Not a great default, admittedly, but hardly deserving all the hate. How about contributing a PR with a script that produces OS packages, instead of complaining that the free cake doesn't come with a cherry on top?
- pekk 11y ago
  I guess people are upset that this is the "officially sanctioned" way of installing the tool.

VieElm 11y ago

That's a serious bash script. That's the craziest bash script I've ever seen. It's like a full program. It is terrifying.

quesera 11y ago
Just to counterbalance your fear: it's really nothing special or weird. It looks pretty straightforward, honestly.

sagichmal 11y ago

Like it or not, this has become the canonical way of installing infrastructural software onto your development machine in the Docker (container) ecosystem. Of course, a competent ops dev would never do this in a production system. But for splash intros on marketing websites, yeah — this strom und drang about how it's incorrigible is getting a bit long in the tooth.