Archive | dumb shit

Software trends that puzzle me: today, it’s ‘one-line installations’

Maybe my UNIX neckbeard is showing, but the trend of one-line installations confuses me. I guess it’s not fundamentally different than installing whatever random packages you found from some no-name repository, and no admin should be installing things blindly (packaged or otherwise). But it just seems like such an invitation to disaster because if you follow these methods to the letter then you’re executing unread scripts live across the wire. It seems like the sort of thing a developer would whip up for convenience, but I see a ton of admins embracing them now that the trend is loose in the wild.

How about some examples? With pictures!


Here’s an example from Docker, which maybe I’m interested in using for a project at $DAYJOB:

curl | sh -x


OK, so that’s a thing… at least it’s going run that shell in debug mode so you will see what it’s doing.

Ruby Version Manager

Here’s how RVM suggests you install it:

\curl -L | bash


Another instance of “Grab this straight across the wire, and dump it directly into a shell! Do not pass go! Do not bother running this through any sort of sanity check!” I do like that this at least uses the slash in front of curl to make sure you’re not inheriting any aliases when you run it. I guess that that’s considerate of the maintainers?


Over in OS X land, Homebrew also has a one-line installation:

ruby -e "$(curl -fsSL"


I like this one! “Run this curl mess in a subshell, and then feed that into Ruby. Install away!”

What’s the big deal, guy? Just runs them scripts and shuts up.


Inner monologue, you’re a jerk. None of this is a big deal. But these things bug the hell out of me. For starters, I don’t know which irks me more about all of these methods: the use of UNIX-style non-descriptive short flags instead of GNU-style descriptive long flags1, or the fact that there’s no immediately visible validation in these pipelines.

The docs for these tools always say you’re welcome (encouraged!) to download the installation scripts and read them for yourself (which I do — they’re actually very well written and they usually accommodate a lot of the sanity checks and edge cases well) but I know that there’s many, many admins and developers who don’t.

And that’s horrifying.

And it seems like part of a broader trend towards super-dickery2. Along similar lines but without falling victim to the one-line installation trend,RBenv is just sort of dickish (in a short pants, school-boy kind of way) about wanting to know what your shell is doing3.

So what?

YOU GUYS, I can’t run this stuff as-is at $DAYJOB. For any one of these examples I’m going to have to fetch that installation script and save it locally. Then I’m going to have to inspect it and work out what remote resources that script is running. Then I have to figure out how to shove these tools into packages because we version EVERYTHING through packages at $DAYJOB. Science forbid these tools make naive assumptions about their target environment (Hey RVM, storing everything in my home directory is a problem if that home directory is a space-constrained network share; let’s not even talk about I/O if there’s network congestion or disk contention on the remote filer…).

And if there’s any releases/changes/improvements made to these one-line installation scripts between when I ran them in my development environments and when someone (WHO ~~DOESN’T LISTEN~~ IS ILLITERATE) runs them in my production environments then I’ll never see them until/unless I use the one-line method (which then silently introduces the dread environment drift). Put another way, one-line installations make installing the same version of a tool across multiple environments just a little bit trickier.

But I guess that the biggest concern I have is “why did someone think this would be OK?”

  1. GNU-style long flags & options are probably my favorite contribution from the whole of old man Stallman’s GNU project. They’re fantastic when editing/reviewing old shell scripts since they save me/you/everyone we know the hassle of looking up an array of arcane short flags. 
  2. I think of super-dickery as being the act of being an asshole without provocation, based solely on the assumption that the other party is not as smart as you think you are; I am guilty of this more often than not. Also, you know, Superman is a dick. 
  3. I like a good tongue-in-cheek README and I like a strong editorial voice, but this README actually comes across as slightly derisive if you’re trying to take admin-fu seriously. I think that the line “Skip this section unless you must know what every line in your shell profile is doing” is needlessly dismissive, and that’s pants. YMMV, caveat lector, etc. 

Interviewing pro-tip: the Candidate is not the enemy

Or, how to get your Candidates to give you their very best voluntarily

Anyone who has ever interviewed anyone for an open req. has experienced a Candidate bombing the interview for one reason or another1, and we’ve certainly all bombed an interview. Now, I don’t know shit about hiring outside of technical fields, specifically for web administrators and UNIX admins. But in that realm, I’ve been on both sides of the process for a little while, and these are the things that I think tend to be the most common reasons for Candidates to do anything less than shine (… or at least these are the things I’m most guilty of):

  • Fixating on the negative aspects of past experiences:

    Where I am now? We have this fucking guy, you know? He eats rice from a plate with a spoon, and it’s disgusting, he’s disgusting, and I can’t stand things that are disgusting!

  • Fixating on the positive aspects of where you’re currently working; put another way, apologizing for having the gall to consider leaving where you are now:

    No, no, it’s really great at ConGloMo! The air rifles only sting a little! I’m really very lucky to have a job at all! The dogs aren’t usually hungry so they don’t maul us when they chase us or anything!

  • It’s also come to my attention that sometimes this manifests in the form of comparing your current employer to your prospective employer too much:

    This place is just like where I am now, except it’s different. I mean, I hate where I am now but I’d love it here, even though it’s the same. But also different.

If you talk down to Candidates, you're gonna have a bad time.

But I also think that these are often a side-effect of a small handful of conditions: being overly familiar or comfortable with the Interviewer (that’s not a bad thing), outright desperation (yellow flag) or excitement (which you should be selecting for), or just plain being damaged (dare I say shell shocked?) by whatever circumstances caused a Candidate to start working the market (and that can be bad, right now, for you; they might get better if the pressure is eased off them). Or if they’re a non-local Candidate, maybe the travel took more out of them then expected and they are still adjusting to being anywhere except home. I am guilty of every single one of those myself, and that’s led me to think that any one of those missteps could have probably been turned into a positive pivot if Interviewers just tried talking to Candidates as if they already had the job.

Continue Reading →