Sat 16 April 2016

So, case in point (since we love examples).

A couple of years ago, when I first started fiddling with Pelican, one of the first things in the docs was 'okay, set up virtualenv and do such a thing'. My initial reaction, as an old-skool sysadmin weenie who hasn't had to actually run a linux install that I care about in many years, was to go 'pfft', and just get python going on the machine I wanted to use pelican on (i.e. my macbook). This, of course, resulted in a world of hurt, as the first thing you do is pick between pip and easy_install, and your first step being to pick a package manager is never a good sign (I've used python for years, so I'm kinda familiar with its vagaries, but y'know. All the same.).

But, step one for me was to run into virtualenv, declare it to be newfangled, and do what I know. I don't feel like I'm a person who rejects things out of hand for being newfangled all on their own. However, that was my initial instinct.

So, when I decided I'd do a bit more writing a few weeks back, I threw ludditism to the wind, and said "OK, let's use virtualenv'. I was up and running in less than 5 minutes. Now I have a (kind of, I assume) idempotent virtual environment for python sitting in dropbox, that I assume will work on other OSX installs. Or maybe elsewhere. Have yet to test.

But the point is, it was quick, painless, and I probably could have done the same thing a few years ago and saved a bunch of hassle. But I didn't -- and I'm interested in why.

It may, of course, go back to one of the truisms I like to come out with, which is People enjoy things they remember. I remember how to install stuff from source, how ./configure && make && make install was the old curl blah | bash, and even though the logical brain knows that the thing that's had thousands of hours of work, and tens of thousands of hours of nerd scrutiny applied to it, and is what the software maintainer recommends will probably work, and may surprise you, you're still gonna go "Install packages? Yeah, I've done that. I'll take it from here, documentation". It's like following the first half of the IKEA instructions and then reckoning you can wing it from there.

Nothing like new ways of doing things to make you feel a bit left behind, eh?

But, it's hard to see what's actually a good way of doing things, and what's generally a bad idea. This varies by your risk aversion, and how bothered you are, and how much you like/trust/care for the community behind this stuff. You used to be able to get a good feel for what's a decent idea as far as sysadmin goes. Now it seems more like you have to be careful about picking your poison.

Other case in point! -- Docker Hub.

I've been playing a bit with Docker for a while, and I've been happy enough with how it functions so far. I haven't in any way stressed it as far as functionality goes (mainly I've been using it at home for Plex, Sonarr, SabNZBd, for, uh, reasons). However, one of the first things you get exposed to is docker hub -- which is basically a giant Makefile repository for docker images.

It gives me the fear.

I don't know why it gives me the fear in a more substantial way than, say, running any software, but I'm still kinda finding it hard in my brain to distinguish it from the sudo | bash school of package management, in terms of trusting your machine to a random thing from internet strangers.

But, we run software written by strangers all the time, right? There's no 'score' assigned to any of this software like docker images from docker hub, right? I've spent long enough reading occasional stories about how some prominent OSS people are deranged maniacs to know that the scrutiny leveled at, say, the sabnzbd or sonarr software itself is far less than the 111 stars and 100k+ pulls that the highest-rated plex Dockerfile has. Hell, Plex is closed source so who knows what it's doing?

You might trust the crowd. That's fine, too. It might result in just as simple a life as only trusting yourself, all things considered.

I guess it comes back to one of the key interests I have, that I've yet to tease out into an 'area of study', really -- the effect of human instinct, emotion and judgement on how we go about interacting with software, especially software we rely on to stay working. People mistake 'correct' for 'safe' or 'familiar' or 'comfortable' all the time, and there's very little acknowledgement of the basic emotions at play. People imagine it as a very dry, scientific discipline -- but some of the most strident arguments I've encountered have been over two perfectly fine methods, software elements, processes, or whatever you run into when dealing with these ridiculous computer contraptions we deal with.

Maybe you think vi is better than emacs because you have muscle memory, or because your girlfriend tought you to use it and that's a happy memory, or you personally have it set up just-so, and it's a classic nerd-brain trope to imagine everyone is just like you, because things are simpler that way?

Or maybe vi's better than emacs because it just is and I'm tired of this argument, so shut your damn hell mouth.

Category: Meta Tagged: meta writing brains