6 ms·

For me personally, the security aspect isn't even the reason I dislike curl | bash installers. There's no standard behaviour for curl|sh, and it re-introduces m

by kenny_r 10y ago

For me personally, the security aspect isn't even the reason I dislike curl | bash installers. There's no standard behaviour for curl|sh, and it re-introduces many problems that were solved by package managers decades ago. Each time I'm about to run `curl https://install.newhotness.io|sudo https://install.newhotness.io|sudo sh` I'm left with the following questions: * Will it work? I'm on Arch Linux. This installer was probably tested on OSX and Ubuntu and deemed "portable". I've seen curl|sudo sh installers trying to apt-get installing dependencies. * Where does it place files? I've got a ~/.meteor folder that's 784MB. Why would you install software libraries and binaries to $HOME? I now have to tell my backup tool to ignore it when backing up my home partition, great. The FHS was established for a reason, people. * Correlary to the previous question: How do I uninstall it? Maybe all files were installed to a hidden folder in ~/, maybe there's some stuff in /opt, or /usr/local, or who knows where else. If the installer doesn't implement uninstall functionality itself, I now have to go hunt for the stuff it placed in my filesystem. I understand the need to be able to distribute your software without having to implement native packaging for OSX/Debian/Ubuntu/Red Hat/Fedora/Arch/... Docker solved this problem. If you're feeling lazy when it comes to distributing your app, just ship a Docker container and be done with it.

TeMPOraL 10y ago
> Correlary to the previous question: How do I uninstall it? Maybe all files were installed to a hidden folder in ~/, maybe there's some stuff in /opt, or /usr/local, or who knows where else. How does one uninstall stuff on Linux anyway? My Linux boxes are always like thrash cans - I add and add new stuff until it's time to upgrade either the system or the machine, so it gets wiped and replaced. Never figured out how to delete stuff in a way that will not leave a ton of things behind...
- dsp1234 10y ago
  The following generally works for me. It removes the installed files, including configuration files. Additionally it will remove any dependencies that were only used by packagename sudo apt-get purge --auto-remove packagename
- HappyTypist 10y ago
  Your package manager should have a remove operation.
- serf 10y ago
  >How does one uninstall stuff on Linux anyway? with a package manager suited for your system, or with the knowledge of what files the software in question touches.
  - RijilV 10y ago
    It's a best effort though, you're relying on the package maintainer to have tracked all the installed files and clean up anything they might have modified, which hopefully you or something else hasn't modified after the package was installed. The packages authored by distributions tend to be pretty good, but I've seen RPMs with nothing more than tar zxf in them and no tracking of the files installed. The major package managers expect the package to manage the artifacts installed, this works if everyone plays nice and does their job...
    - alphapapa 10y ago
      You're right that this requires well-maintained packages, and this is one of the strengths of Debian: its policies that require well-maintained packages. If you install a package that's part of Debian, you can count on it being well-maintained, as opposed to one put out by a random web site or developer, which may install but may not integrate well or clean up after itself.
    - dsmithatx 10y ago
      One point I'd like to make is that this is the fault of the developer(s) and not Linux. I've seen this problem in OSX and Windows as well.
    - khedoros 10y ago
      Package formats each have their own expectations. RPM likes being pointed to a source tarball, given the steps to build the project, and being given a list of the just-built files to include in the package. Those are the artifacts that RPM will manage (and they can be marked things like "doc", "config", or given specific attributes). Deb is broadly similar, but I feel like the framework is a little less controlled than the RPM one. The manager basically just defines a framework. Packages can abuse that framework in various ways (I haven't even mentioned install triggers, to execute code when other named packages are added or removed). There are a lot of ways to get it wrong, but when the dev builds a good package, it's almost magic how nicely it works.
- viraptor 10y ago
  Package managers deal well with files which they installed. What the app creates is your business... and for a good reason. You don't want random package upgrade / conflict to remove your data just because there's something changing about the binary.
- lisivka 10y ago
  Open package manager and remove checkbox at a package, then press "Apply".
- mbrock 10y ago
  If you're on NixOS, you just remove the package from your configuration file and run the "rebuild" command.
- SixSigma 10y ago
  /usr/local exists for a reason
  - Spivak 10y ago
    And /opt for self-contained packages.
- alphapapa 10y ago
  I just don't understand this. I've used Debian and Ubuntu for many years, and I've never had to reinstall a single installation for any reason. I use packages whenever possible, and when installing unpackaged software, I use checkinstall to make a package from it. When I move to a new system or disk, I rsync the filesystem over and boot from the new disk. There is no accumulated cruft; or if there is, it's limited to e.g. tiny config files in /etc from older package versions, which aren't a problem or even noticeable. The closest to cruft is hidden directories in my homedir from software I don't use anymore. That isn't a problem either: they don't take up much space, and it's easy to manually delete them if I ever feel like it. If not, they are compressed and deduplicated by backup software, and they're hidden by default, so who cares?
  - bpchaps 10y ago
    I wish I had your luck... A lot of fixes on forums constantly suggest to uninstall first. Which sometimes actually fixes issues. Other times it makes things worse. Either way - buying a lottery ticket soon?
    - alphapapa 10y ago
      > A lot of fixes on forums constantly suggest to uninstall first. A lot of people seeking and offering help on forums are former Windows users, who are used to doing that to fix problems. They just don't what else to do, so that's what they do. And, sure, if you break a configuration file or package dependency, wiping the disk and reinstalling will fix that--but so would fixing the file or dependency. In my experience, the nuclear option is never necessary with Linux. Worst case, you boot off a CD or USB drive, mount the partition, chroot if necessary, fix it, and reboot. > Other times it makes things worse. That is very strange, indeed. D: > buying a lottery ticket soon? Haha, nope, been having this "luck" for years now, but it only seems to affect my Linux installs. :(
      - TeMPOraL 10y ago
        To be honest, I've solved many more problems with Linux by reinstalling (usually a different distribution) than with Windows. And just yesterday my Linux did what I've never seen an OS do before - it losts it UI clock display. The solution was simple and typical for Linux - it involved killing a random process. But at that moment I realized that we used to laugh that rebooting stuff is the Windows way of doing things. Not anymore, apparently. ;).
- nksjndfdf 10y ago
  > How does one uninstall stuff on Linux anyway? Pretty much every linux package manager can uninstall anything it installs...
- mioelnir 10y ago
  > How does one uninstall stuff on Linux anyway? My Linux boxes are always like thrash cans... That is called sedimentary data storage, ie. piling new files on top of the old ones.
crdoconnor 10y ago
>For me personally, the security aspect isn't even the reason I dislike curl | bash installers. There's no standard behaviour for curl|sh, and it re-introduces many problems that were solved by package managers decades ago. Every time I've seen it used, curl | bash is simply a way to deal with the fact that the users all have different package managers (often with outdated software) and quite complicated workflows to get stuff set up with them because there were problems that the package manager didn't solve. >Docker solved this problem. Ironic. Docker is one of those applications. And they used to ask for it to be installed with a curl pipe. They seem to have replaced it with what is effectively a script executed with human hands. Not really an improvement.
- kenny_r 10y ago
  I was genuinly confused with regards to your last point. There's a section on their website[0] there are installation instructions for various distributions using repositories and package managers. In other words, the right(tm) way of doing software distribution on Linux. But then on a different part of their website I found the curl | sh instructions you allude to[1]. Bizarre that they still support that installation method. To make matters worse, the big orange "Get Started" call to action button actually leads to the curl|sh installation instructions. In light of that I certainly can't blame you for not knowing about the proper distribution packages. [0] https://docs.docker.com/engine/installation/ https://docs.docker.com/engine/installation/ [1] https://docs.docker.com/linux/step_one/ https://docs.docker.com/linux/step_one/
  - crdoconnor 10y ago
    That curled script actually installs the 'proper' distribution packages. It has a lot of clever stuff to figure out which environment it's running on and then does whatever commands are necessary - including, e.g., adding keys so that the external repos where docker is hosted are trusted. Point being that even if you install "the right way" on linux using package managers it's still a multi-step complicated process that benefits from being automated in a bash script.
    - 10y ago
lgessler 10y ago
FWIW, this is Meteor's justification in /usr/local/bin/meteor: # This is the script that we install somewhere in your $PATH (as "meteor") # when you run # $ curl https://install.meteor.com/ | sh # It's the only file that we install globally on your system; each user of # Meteor gets their own personal package and tools repository, called the # warehouse (or, for 0.9.0 and newer, the "tropohouse"), in ~/.meteor/. This # means that a user can share packages among multiple apps and automatically # update to new releases without having to have permissions to write them to # anywhere global.
- TallGuyShort 10y ago
  I used to do Linux packaging full-time and constantly hit limitations in what Linux packaging formats support or allow. There's still a lot of progress that could be made in that area, but unfortunately any attempt to improve will likely become that 15th competing standard XKCD refers to...
- pbhjpbhj 10y ago
  They could be in ~/.local/share/meteor following "XDG Base Directory Specification" (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... - seems well used on my Kubuntu but it's a case of "pick a standard" I guess).
alphapapa 10y ago
For dealing with this problem, as well as anything that's not already packaged, the checkinstall utility is very helpful. It intercepts filesystem calls and builds deb/rpm/tgz packages that you install with your distro's package manager. It's been packaged in Debian for a long time. Highly recommended.
nksjndfdf 10y ago
> Why would you install software libraries and binaries to $HOME? Why not? It makes more sense than global installations sometimes.

by kenny_r 10y ago

TeMPOraL 10y ago

> Correlary to the previous question: How do I uninstall it? Maybe all files were installed to a hidden folder in ~/, maybe there's some stuff in /opt, or /usr/local, or who knows where else. How does one uninstall stuff on Linux anyway? My Linux boxes are always like thrash cans - I add and add new stuff until it's time to upgrade either the system or the machine, so it gets wiped and replaced. Never figured out how to delete stuff in a way that will not leave a ton of things behind...

dsp1234 10y ago
The following generally works for me. It removes the installed files, including configuration files. Additionally it will remove any dependencies that were only used by packagename sudo apt-get purge --auto-remove packagename
HappyTypist 10y ago
Your package manager should have a remove operation.
serf 10y ago
>How does one uninstall stuff on Linux anyway? with a package manager suited for your system, or with the knowledge of what files the software in question touches.
- RijilV 10y ago
  It's a best effort though, you're relying on the package maintainer to have tracked all the installed files and clean up anything they might have modified, which hopefully you or something else hasn't modified after the package was installed. The packages authored by distributions tend to be pretty good, but I've seen RPMs with nothing more than tar zxf in them and no tracking of the files installed. The major package managers expect the package to manage the artifacts installed, this works if everyone plays nice and does their job...
  - alphapapa 10y ago
    You're right that this requires well-maintained packages, and this is one of the strengths of Debian: its policies that require well-maintained packages. If you install a package that's part of Debian, you can count on it being well-maintained, as opposed to one put out by a random web site or developer, which may install but may not integrate well or clean up after itself.
  - dsmithatx 10y ago
    One point I'd like to make is that this is the fault of the developer(s) and not Linux. I've seen this problem in OSX and Windows as well.
  - khedoros 10y ago
    Package formats each have their own expectations. RPM likes being pointed to a source tarball, given the steps to build the project, and being given a list of the just-built files to include in the package. Those are the artifacts that RPM will manage (and they can be marked things like "doc", "config", or given specific attributes). Deb is broadly similar, but I feel like the framework is a little less controlled than the RPM one. The manager basically just defines a framework. Packages can abuse that framework in various ways (I haven't even mentioned install triggers, to execute code when other named packages are added or removed). There are a lot of ways to get it wrong, but when the dev builds a good package, it's almost magic how nicely it works.
viraptor 10y ago
Package managers deal well with files which they installed. What the app creates is your business... and for a good reason. You don't want random package upgrade / conflict to remove your data just because there's something changing about the binary.
lisivka 10y ago
Open package manager and remove checkbox at a package, then press "Apply".
mbrock 10y ago
If you're on NixOS, you just remove the package from your configuration file and run the "rebuild" command.
SixSigma 10y ago
/usr/local exists for a reason
- Spivak 10y ago
  And /opt for self-contained packages.
alphapapa 10y ago
I just don't understand this. I've used Debian and Ubuntu for many years, and I've never had to reinstall a single installation for any reason. I use packages whenever possible, and when installing unpackaged software, I use checkinstall to make a package from it. When I move to a new system or disk, I rsync the filesystem over and boot from the new disk. There is no accumulated cruft; or if there is, it's limited to e.g. tiny config files in /etc from older package versions, which aren't a problem or even noticeable. The closest to cruft is hidden directories in my homedir from software I don't use anymore. That isn't a problem either: they don't take up much space, and it's easy to manually delete them if I ever feel like it. If not, they are compressed and deduplicated by backup software, and they're hidden by default, so who cares?
- bpchaps 10y ago
  I wish I had your luck... A lot of fixes on forums constantly suggest to uninstall first. Which sometimes actually fixes issues. Other times it makes things worse. Either way - buying a lottery ticket soon?
  - alphapapa 10y ago
    > A lot of fixes on forums constantly suggest to uninstall first. A lot of people seeking and offering help on forums are former Windows users, who are used to doing that to fix problems. They just don't what else to do, so that's what they do. And, sure, if you break a configuration file or package dependency, wiping the disk and reinstalling will fix that--but so would fixing the file or dependency. In my experience, the nuclear option is never necessary with Linux. Worst case, you boot off a CD or USB drive, mount the partition, chroot if necessary, fix it, and reboot. > Other times it makes things worse. That is very strange, indeed. D: > buying a lottery ticket soon? Haha, nope, been having this "luck" for years now, but it only seems to affect my Linux installs. :(
    - TeMPOraL 10y ago
      To be honest, I've solved many more problems with Linux by reinstalling (usually a different distribution) than with Windows. And just yesterday my Linux did what I've never seen an OS do before - it losts it UI clock display. The solution was simple and typical for Linux - it involved killing a random process. But at that moment I realized that we used to laugh that rebooting stuff is the Windows way of doing things. Not anymore, apparently. ;).
nksjndfdf 10y ago
> How does one uninstall stuff on Linux anyway? Pretty much every linux package manager can uninstall anything it installs...
mioelnir 10y ago
> How does one uninstall stuff on Linux anyway? My Linux boxes are always like thrash cans... That is called sedimentary data storage, ie. piling new files on top of the old ones.

crdoconnor 10y ago

>For me personally, the security aspect isn't even the reason I dislike curl | bash installers. There's no standard behaviour for curl|sh, and it re-introduces many problems that were solved by package managers decades ago. Every time I've seen it used, curl | bash is simply a way to deal with the fact that the users all have different package managers (often with outdated software) and quite complicated workflows to get stuff set up with them because there were problems that the package manager didn't solve. >Docker solved this problem. Ironic. Docker is one of those applications. And they used to ask for it to be installed with a curl pipe. They seem to have replaced it with what is effectively a script executed with human hands. Not really an improvement.

kenny_r 10y ago
I was genuinly confused with regards to your last point. There's a section on their website[0] there are installation instructions for various distributions using repositories and package managers. In other words, the right(tm) way of doing software distribution on Linux. But then on a different part of their website I found the curl | sh instructions you allude to[1]. Bizarre that they still support that installation method. To make matters worse, the big orange "Get Started" call to action button actually leads to the curl|sh installation instructions. In light of that I certainly can't blame you for not knowing about the proper distribution packages. [0] https://docs.docker.com/engine/installation/ https://docs.docker.com/engine/installation/ [1] https://docs.docker.com/linux/step_one/ https://docs.docker.com/linux/step_one/
- crdoconnor 10y ago
  That curled script actually installs the 'proper' distribution packages. It has a lot of clever stuff to figure out which environment it's running on and then does whatever commands are necessary - including, e.g., adding keys so that the external repos where docker is hosted are trusted. Point being that even if you install "the right way" on linux using package managers it's still a multi-step complicated process that benefits from being automated in a bash script.
  - 10y ago

lgessler 10y ago

FWIW, this is Meteor's justification in /usr/local/bin/meteor: # This is the script that we install somewhere in your $PATH (as "meteor") # when you run # $ curl https://install.meteor.com/ | sh # It's the only file that we install globally on your system; each user of # Meteor gets their own personal package and tools repository, called the # warehouse (or, for 0.9.0 and newer, the "tropohouse"), in ~/.meteor/. This # means that a user can share packages among multiple apps and automatically # update to new releases without having to have permissions to write them to # anywhere global.

TallGuyShort 10y ago
I used to do Linux packaging full-time and constantly hit limitations in what Linux packaging formats support or allow. There's still a lot of progress that could be made in that area, but unfortunately any attempt to improve will likely become that 15th competing standard XKCD refers to...
pbhjpbhj 10y ago
They could be in ~/.local/share/meteor following "XDG Base Directory Specification" (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-... - seems well used on my Kubuntu but it's a case of "pick a standard" I guess).

alphapapa 10y ago

For dealing with this problem, as well as anything that's not already packaged, the checkinstall utility is very helpful. It intercepts filesystem calls and builds deb/rpm/tgz packages that you install with your distro's package manager. It's been packaged in Debian for a long time. Highly recommended.

nksjndfdf 10y ago

> Why would you install software libraries and binaries to $HOME? Why not? It makes more sense than global installations sometimes.