Monday, Oct 7, 2013, 09:11
v1 The less words you use to tell a story, the more effective its message will be, and a greater number of people will read it to completion. Anyone who cares about the user experience in regards to their software, will tell you “people don’t read.” Which while being somewhat accurate, really isn’t the case. People do read, they just value their time. That is just as important in blogging. Protect your reader’s time, and deliver the message as quickly as possible.
v2 Many designers will say users don’t read text, and therefore, you should have as little copy as possible. This is a lie. Users do read text. Users protect one thing above all: their time. The more text they have to read, the more time of theirs is lost. Protect their time by delivering strong messages with fewer words.
v3 Reading takes time. The less reading you force someone to do, the more time you save them.
v4 Fewer words create a more powerful message.
(Excuse the full-quote – I will refer to different parts repeatedly, so I thought it necessary.)
This is a perfect illustration of the effect that twitterization has on ideas: all nuance and tangent is brutally sawed off until only platitude survives into writing. Elliot’s v4 is so vacuous as to not be worth saying at all. Still, it is an improvement on v3 – because though longer, v3 somehow manages to be even worse. V1 may be unnecessarily long, but among these it is the only one worth writing, because the only one worth reading, because the only one containing an idea. Even in v2, the idea is already watered down: the writing is clumsier and more redundant than in v1, in spite of the reduction in length.
But all of my criticism so far is too myopic. Step back and you’ll notice the real blunder: Elliot missed his own point! He went for brevity above all else, and his message suffered for it. People do read, he asserted – they just value their time… which v4 is a waste of. Presumably the grim takeaway so far is that if you aren’t sure which parts of your writing can be removed and which need keeping, maybe you should go ahead and remove all of it…
Fine, that was the wrong direction. What might be a better one? How do you nudge the text toward conveying ideas? I admit that because I find the arguments here somewhat ill-matched (not in any way that can’t be fixed, mind you – just not without going into the matter at greater length), I am having some difficulty rewriting the text without altering the message. But if I restrain myself to just run with what’s there for the sake of this exercise, I arrive at something like this:
v2 Waste no words in telling a story and it will be effective and keep more readers’ attention until they finish it. Designers will often say that users don’t read; the reality is they just value their time. This is true in blogging too – because it is true everywhere. Don’t waffle.
And that is where I’d stop.
Purely in terms of metrics, this is notably shorter than Elliot’s v2. I think it also manages to retain all the ideas from v1 in spite of its brevity, though that is clearly subjective. Of course it isn’t (nor can be) anywhere near as short as v3 or v4. But is it more powerful? (V4’s own words!)
Oh, and if Elliot really wanted to be serious about it?
v5 Short is powerful.
Friday, Jun 28, 2013, 22:38 (updated Wednesday, Aug 21, 2013, 06:17)
Recently it occurred to me that I had been using the same main SSH key for almost 15 years. I had minted a second one for GitHub when I signed up there, but that was it. Worse, both of them were only 1024 bit strong! That may have been fine 15 years ago when I minted the first one, but it certainly isn’t now. They were also both DSA keys, which turns out to have a systematic weakness. (Plus, old versions of the FIPS standard only permitted 1024-bit DSA keys.)
This had to be fixed. And I wanted an actual regime for my keys, so I wouldn’t repeat this.
Naturally, my new keys are all RSA and 8192 bit strong. Yes, 8192 – why not? I worried about that slowing down my SSH connections, but I knew adding key length only increases the cost of the handshake phase, and if my SSH connections are taking any longer to set up now, I haven’t noticed. Even if I did notice, SSH now supports connection sharing (which I have enabled), so that only the initial connection to a host would even experience a meaningful delay. And since I combine that with autossh to set up backgrounded master connections to the hosts I shell into frequently, most of my connections are nearly instant, and always will be, irrespective of key strength.
So how many keys does it make sense to have?
My first impulse was to mint one key pair for each server I would be shelling into. But as I’ll explain, that isn’t what I ended up doing.
I spent a while reading and thinking.
In terms of private key security, my situation is that on every machine on which I work at a physical console, I run a SSH agent with most or all of my private keys loaded. I also have a few passphrase-less keys on other machines, for use by various scripts. (Logins using such keys are restricted to specific commands.) In all cases, an attacker who gained access to any one of these keys would almost certainly have access to all the other keys on the same machine. So there is no security to be gained from using different SSH keys for different servers from the same client. But it does make sense for each client to have its own private keys.
A simple way to encapsulate this as a rule is: never copy a private key to another machine.
In the trivial case, this means one private key for each client machine, with the public key copied to every server to be accessed from that machine. There is, however, a potential privacy concern with this: someone who can compare public keys between several systems can correlate accounts on these systems to each other. Because of this, I share public keys only between servers where I wouldn’t mind if they could be thus correlated.
The upshot is that I have one main key pair for use on my home network and on several other machines under my direct control; plus a few more key pairs (e.g. my new GitHub key) used for maybe 3 shell accounts each. (It so happens that I only have a single machine on which I run a SSH agent – my laptop –, but not long ago, there were 3.) Lastly, I have deleted all copies of any private keys I had distributed among my machines.
Monday, Jun 10, 2013, 23:53
I just cut a new release of rename: 1.600. The headline feature of this version was inspired by Dr. Drang: a built-in
$N variable for easily numbering files while renaming them. It is accompanied by a
--counter-format switch for passing a template, so you will be spared the fiddling with
sprintf for padded counters.
I also finally gave the documentation the huge overhaul it has needed and deserved for a long time. There is now a proper synopsis, the description is brief, and the tutorial that was previously in the description section is a separate much larger section adapted to all the new stuff added since my original version of this utility. Lots of things are now documented properly for the first time.
In more minor notes, there is now a negatable
--stdin switch you can use to explicitly tell
rename to read from stdin, rather than it just guessing that it’s supposed to do that based on the absence of file names on the command line. The purpose of this is more predictable behaviour in situations where
rename is passed computed arguments that may evaluate to nothing (e.g. with the
nullglob shell option).
And lastly, I extracted a new
--trim switch from
--sanitize, mostly for consistency’s sake.