Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Audacity of Piping Curl to Bash

yotam.net

Post reply on HN
Print view View original

21–30 of 111 posts

Re: The Audacity of Piping Curl to Bash

#21

Post by uuddlrlrbaba »

Dive into the details of what "clean" packaging entails, how much practices differs between distributions, how many distributions there are, how each dependency also needs to be packaged and maintained across upgrades...

And you'll quickly see why projects say fsck it -- we support installation via curl | bash. go and package it yourself it you want to.

It really highlights the need for a broadly adopted "homebrew for linux" type package manager that could safely manage software without conflicting with OS packages.

Re: The Audacity of Piping Curl to Bash

#22

Post by derefr »

mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro

I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some kind of medical/legal-like software-engineering bar association) that devs either properly package their apps, or don't release them at all.

I'm not saying it's a good idea; just saying that it's probably the solution brewing in the back of the minds of people who write things like this.

Re: The Audacity of Piping Curl to Bash

#23

Post by derefr »

simiones wrote: post #14
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork". Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even…

> but that actually asks your users for even more control of their systems

Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.

Re: The Audacity of Piping Curl to Bash

#24

Post by derefr »

uuddlrlrbaba wrote: post #21

Dive into the details of what "clean" packaging entails, how much practices differs between distributions, how many distributions there are, how each dependency also needs to be packaged and maintained across upgrades... And you'll quickly see why projects say fsck it -- we support installation via curl | bash. go and package it yourself it you want to. It really highlights the need for a broadly adopted "homebrew fo…

Homebrew is Homebrew for Linux. You can install and use brew(1) on Linux. The Homebrew github worker even generates linux/amd64 binary "bottles" for each Homebrew package to make it fast (as long as the package doesn't explicitly opt out of Linux support.)

Re: The Audacity of Piping Curl to Bash

#25

Post by simiones »

derefr wrote: post #23
simiones wrote: post #14

Earlier quoted context omitted.

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork". Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even…

> but that actually asks your users for even more control of their systems Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.

Sure, but there is plenty of software for which that doesn't make any sense, since the whole point is to interact with your system. ohmyzsh is a good example, as are most SDKs, as is plenty of specialty software.

Re: The Audacity of Piping Curl to Bash

#26

Post by spsesk117 »

Sakos wrote: post #20
spsesk117 wrote: post #10

Earlier quoted context omitted.

> I think what's missing is some standardization around what an installer is allowed to do I don't mean to be facetious, genuinely curios, but to the authors point, isn't that the point of the package management system? It's a standardized and encapsulated way to provide software, with sane defaults, in an auditable way, that respects the users system. I tend to agree with the author here, but I'm sympathetic to the…

> packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream I would say this is the primary pain point for maintainers, which is why we're suddenly seeing bash scripts instead. The technical complexity and the process of upstreaming and then doing this for a bunch of different distros. If they're alre…

> the solution isn't "well, why don't they just use existing package management systems"

Fair enough, I think I was more trying to unwrap the idea of "shell script standardization", which to me feels like a package management system.

To your point about the challenges of packaging for multiple distros, there are force multiplying tools I've used in the past that make this easier, but in my experience it is always a big challenge.

My hope is that things like Nix or even something like brew can help to further consolidate the installation process for software going forward, so that everyone can have the best of all worlds :D

Re: The Audacity of Piping Curl to Bash

#27

Post by mynameisvlad »

derefr wrote: post #22
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some ki…

I mean, that will just result in no software ever getting made outside of big companies who can afford entire departments of people specializing in packaging.

If someone were to impose restrictions to the hobby things I do, then those hobby things will just become private repositories that will never see the light of day, and I'm sure that rings true for most people.

Re: The Audacity of Piping Curl to Bash

#29

Post by halayli »

The title and the content don't match. The omzsh installer behavior is orthogonal to piping it from curl to bash.

On the other hand, It's often the case that your machine is running scripts that have been fetched online via apt and the like and it's definitely something to consider especially with all the hacks that have been happening in the last few years and the undisclosed vulnerabilities available in the wild.

Re: The Audacity of Piping Curl to Bash

#30

Post by mustache_kimono »

derefr wrote: post #22
mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some ki…

> "we the users" could mandate

Yuck. As I said:

> Instead, it is always someone else's problem.

"I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing.

Re: the parent, she/he shouldn't be downvoted for making an unpopular yet interesting point.

Post reply on HN