17 ms·

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from

by blfr 12y ago

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. (The neckbeard in me blames the popularity of OSX on dev machines.) [1] https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesource-linux-repositories https://nodesource.com/blog/nodejs-v012-iojs-and-the-nodesou...

deleted 12y ago
[deleted]
hurin 12y ago
> Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. While I agree with the articles main points - the GNU build system is far from simple. Basically an arcane syntax limited to unix-based systems and 5 or 6 100+ page manuals to cover. It doesn't excuse it - but I think it's easy to see why people turn to curl | sudo bash as the author puts it.
- pjc50 12y ago
  Maintaining autoconf/automake stuff is a pain. Using it is usually as simple as "configure;make;make install". It doesn't do dependency management though, which is an externalised cost. But that's what rpm/deb do. I see the attraction of containers and disk image based management. It's much less time consuming. But it's very much the opposite of ISO9001-style input traceability.
  - sltkr 12y ago
    > Using it is usually as simple as "configure;make;make install". "Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.
    - Jare 12y ago
      That's the same for "wget|sh", apt-get, npm or any other system. Now, if the argument is that configure tends to break more often and for more obscure reasons, I can tentatively agree with that.
      - deong 12y ago
        This is the reason why all these standalone things bundle everything into their installation process. The problem is installing 206 different pythons on my system just makes it more likely that something else is going to break.
        garthk 12y ago
        … which is one of the pressures driving Docker adoption. Each process tree gets its own root filesystem to trash with its multitude of dependencies. DLL hell, shared library hell, JDK hell, Ruby and Python environment hell… a lot of it can be summed up as "userland hell". Docker makes it easy to give the process its own bloody userland and be done with it.
        deong 12y ago
        I think this falls under the heading of "I'm old", but I already have one machine to maintain. Replacing it with N machines to maintain doesn't feel like a win to me.
      - lmm 12y ago
        I'd actually disagree with that. Auto* breaks less often than wget or npm, IME.
    - bd_at_rivenhill 12y ago
  - gthank 12y ago
    Somebody has to build the containers and/or images, and it's on them to make that an automated, repeatable process.
  - shanemhansen 12y ago
    Sorry, I don't know what ISO9001 is, but isn't deploying an image extremely conducive to traceability? No non-deterministic scripts are ran on production servers.
    - pjc50 12y ago
      http://www.askartsolutions.com/iso9001training/Identification-and-Traceability.html http://www.askartsolutions.com/iso9001training/Identificatio... ISO9001 often turns into its Dilbert parody of bureaucracy, but the core ideas are sound: if you have some sort of failure of production, it's useful to know what went into the production process and where it came from. So in the case of deploying images, then yes: you get repeatable copies of the image. Provided you know where the image came from. Images themselves aren't usually stored in a version control or configuration management system. It may not be obvious where the image came from. And, if an image is made up of numerous "parts" (ie all the installed software), you need to know what those parts are. If an SSL vulnerability is announced, what is the process for guaranteeing that you've updated all the master copies and re-imaged as necessary?
      - lmm 12y ago
        Have you ever seen it implemented in a way that added value? I agree that in theory ISO9001 makes sense, but it's been a slow-motion disaster everywhere I've seen it actually tried.
        pjc50 12y ago
        I haven't seen it successfully implemented in the software industry. Manufacturing are much more OK with it. I'm not arguing for iso9001 itself, just that reproducibility and standardisation of "parts" are things we should consider.
- mauricemir 12y ago
  I have never under stood why some many people are not ok with using the command line. A few years back we had an issue where a mysql script was over the limit for phpmyadmin - my fairly experienced colleague he was unaware that you could log into the cli and use mysql from the cli.
  - deleted 12y ago
    [deleted]
  - gregor7777 12y ago
    I'd like to think this post is an exaggeration.
    - mauricemir 12y ago
      Unfortunately not there are a lot of developers can only use phpmyadmin or thier CMS's gui - and from what I am told being able to code basic sql joins is not something you can take for granted.
      - gregor7777 12y ago
        Insanity.
      - dba7dba 12y ago
        Crazy talk. And these 'developers' are pulling in six-figure?
  - PopsiclePete 12y ago
    Could be a generational thing as well. I work with some devs who've always used Windows/OS X GUI exclusively for everything and are terrified of commmand-line anything. Either there's a GUI for it, or it might as well not exist. Younger guys usually.
  - admyral 12y ago
    Command line is modern day voodoo. There are ton of commands, each with a specific use, each with own their specific incantation, which can mixed in extremely powerful ways. But my theory is the main reason people would prefer not use it, is that improper usage can be harmful and sometimes destructive. The same reason people prefer to use garbage collected and dynamically typed programming languages.
- creshal 12y ago
  > the GNU build system is far from simple Which is why there's alternatives – cmake, waf, …
  - bandrami 12y ago
    > Which is why there's alternatives – cmake, waf Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...) Personally I like make. I understand it. I've used it for something like 20 years now. If there are problem domains it doesn't work for, they aren't problem domains I encounter. (Like so much of Linux software in the past 5 years or so, I find myself saying "this seems like an interesting way to solve a problem I simply don't have".)
    - creshal 12y ago
      > Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...) Each their own poison. Personally I don't like them either, but pretending it's autoconf or curl|sh is an oversimplification.
mauricemir 12y ago
:-) I managed to get haddoop running on a small cluster from scratch Michael Nolls turtorial is a good starting point. Full stack should mean you can and have used a soldering iron in anger and also have at least a CCNA level of networking.
- stephenr 12y ago
  When you say anger, do you mean to threaten the developer who wants to run `chmod 777 /var/www` when their just-installed php app released in 2003 won't allow uploads? Edit: Maybe I should have added a /sarcasm to my comment?
  - bbrazil 12y ago
    "in anger" means used in a real-life situation, not just playing around.
    - jacquesm 12y ago
      I think he got that.
  - kpcyrd 12y ago
    alias fix-permissions="chmod -R 777 /"
    - hurin 12y ago
      > alias fix-permissions="chmod -R 777 /" function sudo if not test (count $argv) -gt 3 command sudo $argv; return; end if not contains $argv[4] "/" (ls / | awk '{print "/"$1}') command sudo $argv; return; end if test $ $argv[1] = chmod $ -a $ $argv[2] = '-R' $ -a $ $argv[3] = 777 $ command sudo reboot -f else command sudo $argv end; end;
  - mauricemir 12y ago
    I think branding them is going a bit to far ... For a first offense
stephenr 12y ago
I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment, when a decision about something like "how do we get a reliable build of X for our production server deployment system" needs to be made or a system needs to be supported, no idea is "bad", because no one has the experience or confidence to be able to say "that's a stupid idea, we are not making `curl http://bit.ly/foo http://bit.ly/foo | sudo bash` the first line of a deployment script"[1] [1] yes this is an exaggeration, but there are some simply shocking things happening in real environments, that are not far off that mark. Edit: to make it absolutely clear about what I was referring to with [1]: The specific point I was making was running something they don't even see (how many people would actually look at the script before piping it to bash/sh ?) from a non-encrypted source, and relying on a redirection service that could remove/change your short url at any time. Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2] [2] http://stackoverflow.com/questions/5421800/rvm-system-wide-install-script-url-broken-what-is-replacement http://stackoverflow.com/questions/5421800/rvm-system-wide-i... -
- tribaal 12y ago
  > I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management" I'm totally stealing this :)
- yAnonymous 12y ago
  >[1] yes this is an exaggeration No, it's not :(
  - tormeh 12y ago
    It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.
collyw 12y ago
I have found a lot of these platform as a service providers are way more complicated than doing things from scratch.
VLM 12y ago
Many people have enormous amounts of experience with anti-patterns yet very little self reflection to identify them. This is an obvious example: http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect Obviously a config / deployment system, like any other system, will start small and simple and "save a lot of time" but after an infinity of features are bolted on, it'll be infinitely worse than just using a bash script. Even worse, you probably figure out your deployment by hand on one system using bash, then need to translate what worked on a command line into crypto-wanna-be-bash config system (probably creating numerous bugs in the translation) then using wanna-be-bash to slowly poorly imitate what you'd get if you just used bash directly... The last straw for me was trying to integrate some freebsd servers and /usr/ports had like six versions of cfengine none of which worked perfectly with the three versions on the legacy linux boxes. Screw all that, instead of translating bash command line operations into psuedo-bash I'll just use bash directly. IT is an eternally rotating wheel and the baroque inner platform deployment framework has had its day... and being an eternally rotating wheel it'll have its day again in a couple years. Just not now. Not throwing the baby out with the bathwater, a strict directory structure, and modularity and library approach to error handling and reporting and logging which you can steal from the deploy systems is a perfectly good idea. Unix philosophy of small perfect tools means I'm using git instead of my own versioning/branching system, and using ssh to shove files around rather than implementing and static linking in my own crypto and SSL system.
- wtbob 12y ago
  I agree with you in principle, but in practice shell scripts are really not the best tool for this sort of job: they tend to be write-only (in the sense that they can be difficult to read months or years later) and can become very hairy and difficult to maintain. I'd prefer something like scsh (or a Common Lisp or elisp version thereof) for this sort of work: access to a full-fledged programming language and easy access to the Unix environment.
  - VLM 12y ago
    "can become very hairy and difficult to maintain." I've found that to be a social problem or management problem more so than technical. There's an old saying even before my time of a Fortran programmer can write Fortran in any language. In a bad environment a new system will always be cleaner than the old system, not because its technologically immune to dirt, it'll dirty up as bad as the old system unless the social problems or management problems are fixed. You really can write read only Puppet scripts. Or you can write readable bash. Or even Perl. Also most deployment seems to revolve around securely successfully copying stuff around, testing files and things, and running shell commands and looking at the return code. Shells are pretty good at running shell commands like those in a maintainable easily readable and troubleshootable fashion. Its possible that a deployment situation that more closely resembles a clojure koan than the previous, might have some severely blurred lines. And there's always the issue of minimizing the impedance bump between the automated deployer and the dude writing it (probably running commands in a shell window) and the dude troubleshooting it at 2am (by looking at the deployment system in one window and running commands in a shell window next to it to isolate the problem). I would agree that cleaner library/subroutine type stuff in shell would be nice. And you are correct, scsh is really cool but two jobs later some random dude on pager duty at 2am is more likely to know bash or tcsh. Principle of least surprise. I suppose if only scsh guys are ever hired... Then again as per above most deployment is just lots of moving stuff around and running things so its pretty self explanatory. But if the work is trivial, don't deploy a howitzer to swat a fly. Maybe another way to look at it is if you're doing something confusing or broken, plain common language will clear things up faster and more accurately than using an ever more esoteric domain specific language. Or some folk saying like "always use the overall simplest possible solution to a complex problem". There is the "don't reinvent the wheel" argument. I have a really good network wide logging system, a really good ssh key system for secure transfer of files, a strong distributed version control system to store branches and versions, a strong SSL infrastructure, a stable execution environment where upgrading bash probably won't kill all my scripts, a strong scheduled execution system... I don't need a tight monolithic collection of "not so good" reimplementation of the above, running that is more painful that rolling my own glue between the strong systems I already have. And using the monolith doesn't mean I get to abandon or ignore the "real" strong infrastructure, so the only thing worse than running one logging/reporting system is having to admin two, a real enterprise grade one and a deployment-only wanna be system. I did the puppet thing for many years. So sick and tired of that.
hultner 12y ago
I've seen people copy pasting stuff along the lines of `wget --no-check-certificate | sudo sh` into their terminals from some random internet source. I'm pulling my hair saying are you even aware of what you're doing?
- rimantas 12y ago
  What do you expect them to do, download .tar.gz, extra, read every line of code and them make; make install? Or just make; make install? How is that any different?
  - brohee 12y ago
    You can usually get PGP signed hashes for tarballs distributed by serious entities. If someone is distributing software and provides no way to check that it is genuine, you shouldn't run it...
Khaine 12y ago
Some of this is self inflected. Go look up how you install snort or bro on centos. You have to either install from source, or install from a rpm from there website which may or may not have issues. This means you lose dependency management, and update management. Pure madness
- shanemhansen 12y ago
  I've decided that unless you're ok with running a very restricted set of ancient applications, don't even try to use CentOS. I've seen multiple billion dollar companies who can't seen to avoid f'ing up the yum repos on CentOS. I'm not able to go full docker on my machines @work, but I do have some statically linked tarballs. There is a reason apps that deploy in hostile environments (skype, chrome, firefox) bundle most of their dependencies.
- danielweber 12y ago
  Choose your method of death: 1. Run this totally opaque command which might DTRT, and might completely pwn your system. 2. Prepare for 4 hours of dependency hell.
  - contingencies 12y ago
    Alternatively, learn Gentoo.
legulere 12y ago
There's nothing wrong with curl | sudo bash style setups as long as it's over https and the certificate gets checked. The advantages are that it's easy and you can make it work on almost all unix-like systems out there. The only disadvantage is that you have one additional weak point: The server can get contaminated. Before you had to contaminate one of the many developer machines / build machines. The situation hasn't been better before. Install media always got downloaded without ssl encryption or any certificate checks. This is still the same, but at least you won't get a hacked kernel today if you use secure boot.
- mbreese 12y ago
  No, it's just plain bad. To pick one example why... Just because it's easy to run doesn't mean it's easy to support or maintain. Chances are `curl | bash` scripts aren't designed for your particular OS, so it's yet another form of software that you have to learn how to update, as opposed to using the OS-level update mechanism, such as yum, apt, or even brew to some extent. Being a good sysadmin doesn't stop at installing the software. Most of the hard (boring) work is in maintaining systems and keeping them updated and secure. Blind install scripts make this job impossible. There is a very big difference between installing something on your dev machine to just get it started and deploying something into production. `curl | bash` is okay for setting something up on a dev machine where the only one that needs to use it is you. For productions machines, it's completely inappropriate[1]. [1] This is somewhat mitigated by things like Docker, but I'd still argue that you don't want to have an ephemeral installation method for containers either. You should have fixed versions that are installed by either a package manager or at least a Makefile.
  - wang_li 12y ago
    Not to mention that in plenty of environments production systems don't have access to the internet to begin with, so curl/wget | bash is a non-starter.
- contingencies 12y ago
  There's nothing wrong with curl | sudo bash style setups as long as it's over https and the certificate gets checked. Even assuming the URL's publisher is trustworthy (which is a poor assumption to make, ever), you forget SSL / HTTPS is broken, that the NSA has established MITM on the entire internet, that your installation process (which should be both versioned and repeatable) now has zero versioning and all the entropy of the network plus bonus entropy.
kylegordon 12y ago
I posted a slightly provocative tweet about this, and the CEO of NodeSource took exception... sad days. https://twitter.com/kylegordon/status/590860756075294721 https://twitter.com/kylegordon/status/590860756075294721
- reitanqild 12y ago
  He seems to be way nicer and more professional than you..?
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
  - teddyh 12y ago
    If by “nicer and more professional” you mean “super condescending”.
    - reitanqild 12y ago
      What? Only after two hours did he tell kylegordon that he (kylegordon) was cute. And at that point kylegordon had earned it.
gaius 12y ago
Many people have this weird aversion to doing basic sysadmin stuff with Linux Like developers who won't write SQL and insist on an ORM.
grn 12y ago
I'm guilty of using this method in my side project (https://github.com/grn/bash-ctx https://github.com/grn/bash-ctx). My goal was to solve the installation problem quickly. I absolutely would love to offer proper installation methods. However my experience with building *.deb packages makes me think that it's not something that I'd like to do (especially it's a side project). The question, therefore, is: what is the simplest alternative installation method for OS X and Linux?

by blfr 12y ago

deleted 12y ago

[deleted]

hurin 12y ago

> Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. While I agree with the articles main points - the GNU build system is far from simple. Basically an arcane syntax limited to unix-based systems and 5 or 6 100+ page manuals to cover. It doesn't excuse it - but I think it's easy to see why people turn to curl | sudo bash as the author puts it.

pjc50 12y ago
Maintaining autoconf/automake stuff is a pain. Using it is usually as simple as "configure;make;make install". It doesn't do dependency management though, which is an externalised cost. But that's what rpm/deb do. I see the attraction of containers and disk image based management. It's much less time consuming. But it's very much the opposite of ISO9001-style input traceability.
- sltkr 12y ago
  > Using it is usually as simple as "configure;make;make install". "Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.
  - Jare 12y ago
    That's the same for "wget|sh", apt-get, npm or any other system. Now, if the argument is that configure tends to break more often and for more obscure reasons, I can tentatively agree with that.
    - deong 12y ago
      This is the reason why all these standalone things bundle everything into their installation process. The problem is installing 206 different pythons on my system just makes it more likely that something else is going to break.
      - garthk 12y ago
        … which is one of the pressures driving Docker adoption. Each process tree gets its own root filesystem to trash with its multitude of dependencies. DLL hell, shared library hell, JDK hell, Ruby and Python environment hell… a lot of it can be summed up as "userland hell". Docker makes it easy to give the process its own bloody userland and be done with it.
        deong 12y ago
        I think this falls under the heading of "I'm old", but I already have one machine to maintain. Replacing it with N machines to maintain doesn't feel like a win to me.
    - lmm 12y ago
      I'd actually disagree with that. Auto* breaks less often than wget or npm, IME.
  - bd_at_rivenhill 12y ago
- gthank 12y ago
  Somebody has to build the containers and/or images, and it's on them to make that an automated, repeatable process.
- shanemhansen 12y ago
  Sorry, I don't know what ISO9001 is, but isn't deploying an image extremely conducive to traceability? No non-deterministic scripts are ran on production servers.
  - pjc50 12y ago
    http://www.askartsolutions.com/iso9001training/Identification-and-Traceability.html http://www.askartsolutions.com/iso9001training/Identificatio... ISO9001 often turns into its Dilbert parody of bureaucracy, but the core ideas are sound: if you have some sort of failure of production, it's useful to know what went into the production process and where it came from. So in the case of deploying images, then yes: you get repeatable copies of the image. Provided you know where the image came from. Images themselves aren't usually stored in a version control or configuration management system. It may not be obvious where the image came from. And, if an image is made up of numerous "parts" (ie all the installed software), you need to know what those parts are. If an SSL vulnerability is announced, what is the process for guaranteeing that you've updated all the master copies and re-imaged as necessary?
    - lmm 12y ago
      Have you ever seen it implemented in a way that added value? I agree that in theory ISO9001 makes sense, but it's been a slow-motion disaster everywhere I've seen it actually tried.
      - pjc50 12y ago
        I haven't seen it successfully implemented in the software industry. Manufacturing are much more OK with it. I'm not arguing for iso9001 itself, just that reproducibility and standardisation of "parts" are things we should consider.
mauricemir 12y ago
I have never under stood why some many people are not ok with using the command line. A few years back we had an issue where a mysql script was over the limit for phpmyadmin - my fairly experienced colleague he was unaware that you could log into the cli and use mysql from the cli.
- deleted 12y ago
  [deleted]
- gregor7777 12y ago
  I'd like to think this post is an exaggeration.
  - mauricemir 12y ago
    Unfortunately not there are a lot of developers can only use phpmyadmin or thier CMS's gui - and from what I am told being able to code basic sql joins is not something you can take for granted.
    - gregor7777 12y ago
      Insanity.
    - dba7dba 12y ago
      Crazy talk. And these 'developers' are pulling in six-figure?
- PopsiclePete 12y ago
  Could be a generational thing as well. I work with some devs who've always used Windows/OS X GUI exclusively for everything and are terrified of commmand-line anything. Either there's a GUI for it, or it might as well not exist. Younger guys usually.
- admyral 12y ago
  Command line is modern day voodoo. There are ton of commands, each with a specific use, each with own their specific incantation, which can mixed in extremely powerful ways. But my theory is the main reason people would prefer not use it, is that improper usage can be harmful and sometimes destructive. The same reason people prefer to use garbage collected and dynamically typed programming languages.
creshal 12y ago
> the GNU build system is far from simple Which is why there's alternatives – cmake, waf, …
- bandrami 12y ago
  > Which is why there's alternatives – cmake, waf Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...) Personally I like make. I understand it. I've used it for something like 20 years now. If there are problem domains it doesn't work for, they aren't problem domains I encounter. (Like so much of Linux software in the past 5 years or so, I find myself saying "this seems like an interesting way to solve a problem I simply don't have".)
  - creshal 12y ago
    > Gah. Because I want to drop a metric ton of python code into my own source tree just to build. (gnulib is bad enough...) Each their own poison. Personally I don't like them either, but pretending it's autoconf or curl|sh is an oversimplification.

mauricemir 12y ago

:-) I managed to get haddoop running on a small cluster from scratch Michael Nolls turtorial is a good starting point. Full stack should mean you can and have used a soldering iron in anger and also have at least a CCNA level of networking.

stephenr 12y ago
When you say anger, do you mean to threaten the developer who wants to run `chmod 777 /var/www` when their just-installed php app released in 2003 won't allow uploads? Edit: Maybe I should have added a /sarcasm to my comment?
- bbrazil 12y ago
  "in anger" means used in a real-life situation, not just playing around.
  - jacquesm 12y ago
    I think he got that.
- kpcyrd 12y ago
  alias fix-permissions="chmod -R 777 /"
  - hurin 12y ago
    > alias fix-permissions="chmod -R 777 /" function sudo if not test (count $argv) -gt 3 command sudo $argv; return; end if not contains $argv[4] "/" (ls / | awk '{print "/"$1}') command sudo $argv; return; end if test $ $argv[1] = chmod $ -a $ $argv[2] = '-R' $ -a $ $argv[3] = 777 $ command sudo reboot -f else command sudo $argv end; end;
- mauricemir 12y ago
  I think branding them is going a bit to far ... For a first offense

stephenr 12y ago

I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment, when a decision about something like "how do we get a reliable build of X for our production server deployment system" needs to be made or a system needs to be supported, no idea is "bad", because no one has the experience or confidence to be able to say "that's a stupid idea, we are not making `curl http://bit.ly/foo http://bit.ly/foo | sudo bash` the first line of a deployment script"[1] [1] yes this is an exaggeration, but there are some simply shocking things happening in real environments, that are not far off that mark. Edit: to make it absolutely clear about what I was referring to with [1]: The specific point I was making was running something they don't even see (how many people would actually look at the script before piping it to bash/sh ?) from a non-encrypted source, and relying on a redirection service that could remove/change your short url at any time. Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2] [2] http://stackoverflow.com/questions/5421800/rvm-system-wide-install-script-url-broken-what-is-replacement http://stackoverflow.com/questions/5421800/rvm-system-wide-i... -

tribaal 12y ago
> I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management" I'm totally stealing this :)
yAnonymous 12y ago
>[1] yes this is an exaggeration No, it's not :(
- tormeh 12y ago
  It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

collyw 12y ago

I have found a lot of these platform as a service providers are way more complicated than doing things from scratch.

VLM 12y ago

Many people have enormous amounts of experience with anti-patterns yet very little self reflection to identify them. This is an obvious example: http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect Obviously a config / deployment system, like any other system, will start small and simple and "save a lot of time" but after an infinity of features are bolted on, it'll be infinitely worse than just using a bash script. Even worse, you probably figure out your deployment by hand on one system using bash, then need to translate what worked on a command line into crypto-wanna-be-bash config system (probably creating numerous bugs in the translation) then using wanna-be-bash to slowly poorly imitate what you'd get if you just used bash directly... The last straw for me was trying to integrate some freebsd servers and /usr/ports had like six versions of cfengine none of which worked perfectly with the three versions on the legacy linux boxes. Screw all that, instead of translating bash command line operations into psuedo-bash I'll just use bash directly. IT is an eternally rotating wheel and the baroque inner platform deployment framework has had its day... and being an eternally rotating wheel it'll have its day again in a couple years. Just not now. Not throwing the baby out with the bathwater, a strict directory structure, and modularity and library approach to error handling and reporting and logging which you can steal from the deploy systems is a perfectly good idea. Unix philosophy of small perfect tools means I'm using git instead of my own versioning/branching system, and using ssh to shove files around rather than implementing and static linking in my own crypto and SSL system.

wtbob 12y ago
I agree with you in principle, but in practice shell scripts are really not the best tool for this sort of job: they tend to be write-only (in the sense that they can be difficult to read months or years later) and can become very hairy and difficult to maintain. I'd prefer something like scsh (or a Common Lisp or elisp version thereof) for this sort of work: access to a full-fledged programming language and easy access to the Unix environment.
- VLM 12y ago
  "can become very hairy and difficult to maintain." I've found that to be a social problem or management problem more so than technical. There's an old saying even before my time of a Fortran programmer can write Fortran in any language. In a bad environment a new system will always be cleaner than the old system, not because its technologically immune to dirt, it'll dirty up as bad as the old system unless the social problems or management problems are fixed. You really can write read only Puppet scripts. Or you can write readable bash. Or even Perl. Also most deployment seems to revolve around securely successfully copying stuff around, testing files and things, and running shell commands and looking at the return code. Shells are pretty good at running shell commands like those in a maintainable easily readable and troubleshootable fashion. Its possible that a deployment situation that more closely resembles a clojure koan than the previous, might have some severely blurred lines. And there's always the issue of minimizing the impedance bump between the automated deployer and the dude writing it (probably running commands in a shell window) and the dude troubleshooting it at 2am (by looking at the deployment system in one window and running commands in a shell window next to it to isolate the problem). I would agree that cleaner library/subroutine type stuff in shell would be nice. And you are correct, scsh is really cool but two jobs later some random dude on pager duty at 2am is more likely to know bash or tcsh. Principle of least surprise. I suppose if only scsh guys are ever hired... Then again as per above most deployment is just lots of moving stuff around and running things so its pretty self explanatory. But if the work is trivial, don't deploy a howitzer to swat a fly. Maybe another way to look at it is if you're doing something confusing or broken, plain common language will clear things up faster and more accurately than using an ever more esoteric domain specific language. Or some folk saying like "always use the overall simplest possible solution to a complex problem". There is the "don't reinvent the wheel" argument. I have a really good network wide logging system, a really good ssh key system for secure transfer of files, a strong distributed version control system to store branches and versions, a strong SSL infrastructure, a stable execution environment where upgrading bash probably won't kill all my scripts, a strong scheduled execution system... I don't need a tight monolithic collection of "not so good" reimplementation of the above, running that is more painful that rolling my own glue between the strong systems I already have. And using the monolith doesn't mean I get to abandon or ignore the "real" strong infrastructure, so the only thing worse than running one logging/reporting system is having to admin two, a real enterprise grade one and a deployment-only wanna be system. I did the puppet thing for many years. So sick and tired of that.

hultner 12y ago

I've seen people copy pasting stuff along the lines of `wget --no-check-certificate | sudo sh` into their terminals from some random internet source. I'm pulling my hair saying are you even aware of what you're doing?

rimantas 12y ago
What do you expect them to do, download .tar.gz, extra, read every line of code and them make; make install? Or just make; make install? How is that any different?
- brohee 12y ago
  You can usually get PGP signed hashes for tarballs distributed by serious entities. If someone is distributing software and provides no way to check that it is genuine, you shouldn't run it...

Khaine 12y ago

Some of this is self inflected. Go look up how you install snort or bro on centos. You have to either install from source, or install from a rpm from there website which may or may not have issues. This means you lose dependency management, and update management. Pure madness

shanemhansen 12y ago
I've decided that unless you're ok with running a very restricted set of ancient applications, don't even try to use CentOS. I've seen multiple billion dollar companies who can't seen to avoid f'ing up the yum repos on CentOS. I'm not able to go full docker on my machines @work, but I do have some statically linked tarballs. There is a reason apps that deploy in hostile environments (skype, chrome, firefox) bundle most of their dependencies.
danielweber 12y ago
Choose your method of death: 1. Run this totally opaque command which might DTRT, and might completely pwn your system. 2. Prepare for 4 hours of dependency hell.
- contingencies 12y ago
  Alternatively, learn Gentoo.

legulere 12y ago

There's nothing wrong with curl | sudo bash style setups as long as it's over https and the certificate gets checked. The advantages are that it's easy and you can make it work on almost all unix-like systems out there. The only disadvantage is that you have one additional weak point: The server can get contaminated. Before you had to contaminate one of the many developer machines / build machines. The situation hasn't been better before. Install media always got downloaded without ssl encryption or any certificate checks. This is still the same, but at least you won't get a hacked kernel today if you use secure boot.

mbreese 12y ago
No, it's just plain bad. To pick one example why... Just because it's easy to run doesn't mean it's easy to support or maintain. Chances are `curl | bash` scripts aren't designed for your particular OS, so it's yet another form of software that you have to learn how to update, as opposed to using the OS-level update mechanism, such as yum, apt, or even brew to some extent. Being a good sysadmin doesn't stop at installing the software. Most of the hard (boring) work is in maintaining systems and keeping them updated and secure. Blind install scripts make this job impossible. There is a very big difference between installing something on your dev machine to just get it started and deploying something into production. `curl | bash` is okay for setting something up on a dev machine where the only one that needs to use it is you. For productions machines, it's completely inappropriate[1]. [1] This is somewhat mitigated by things like Docker, but I'd still argue that you don't want to have an ephemeral installation method for containers either. You should have fixed versions that are installed by either a package manager or at least a Makefile.
- wang_li 12y ago
  Not to mention that in plenty of environments production systems don't have access to the internet to begin with, so curl/wget | bash is a non-starter.
contingencies 12y ago
There's nothing wrong with curl | sudo bash style setups as long as it's over https and the certificate gets checked. Even assuming the URL's publisher is trustworthy (which is a poor assumption to make, ever), you forget SSL / HTTPS is broken, that the NSA has established MITM on the entire internet, that your installation process (which should be both versioned and repeatable) now has zero versioning and all the entropy of the network plus bonus entropy.

kylegordon 12y ago

I posted a slightly provocative tweet about this, and the CEO of NodeSource took exception... sad days. https://twitter.com/kylegordon/status/590860756075294721 https://twitter.com/kylegordon/status/590860756075294721

reitanqild 12y ago
He seems to be way nicer and more professional than you..?
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- teddyh 12y ago
  If by “nicer and more professional” you mean “super condescending”.
  - reitanqild 12y ago
    What? Only after two hours did he tell kylegordon that he (kylegordon) was cute. And at that point kylegordon had earned it.

gaius 12y ago

Many people have this weird aversion to doing basic sysadmin stuff with Linux Like developers who won't write SQL and insist on an ORM.

grn 12y ago

I'm guilty of using this method in my side project (https://github.com/grn/bash-ctx https://github.com/grn/bash-ctx). My goal was to solve the installation problem quickly. I absolutely would love to offer proper installation methods. However my experience with building *.deb packages makes me think that it's not something that I'd like to do (especially it's a side project). The question, therefore, is: what is the simplest alternative installation method for OS X and Linux?