By any other name ♠
It turns out Paul Graham runs a “startup accelerator” located on 320 Pioneer Way in Mountain View, CA called Y-Combinator. Y-Combinator makes micro investments into very early stage companies and then helps these companies raise venture capital. Thousands apply for a few slots in two “classes” per year. AirBnB, Dropbox, and Reddit are among its alumni.
The accelerator takes small amounts of risk and offloads that aggregate risk onto a market of investors (the VCs). Its Demo Day, which first showcases its companies, is a coming out event, like an IPO. And it attracts top young graduates, like my cousin, from across the world. I spent nearly a decade on Wall Street, and let’s be clear: that’s our model. Employing Type A personalities to shuffle around amorphous blobs of questionable value is not called a “startup accelerator”; it’s called Investment Banking.
Real as can be, after all? ♠
It is possible to consider that the value of π is not infinite because it is recursively enumerable. You can make as many correct digits as you like using finite means. I think some scientists are thinking this means that π doesn’t “actually” have an infinite number of digits, because there are simple rules for getting as many as you need, without limit.
However, there is another arena well known to physicists where an “actual infinity” is much harder to exorcise, and that is the randomness that seems to be built in at a basic level in quantum mechanics. It is now known, thanks to recent results, that it is possible to certify that a sequence of bits produced by quantum processes are truly, irreducibly random. It is also known that it is not possible to compute an irreducibly random sequence of indefinite length using a program of finite size. So as far as I can see, this means that the universe is not any sort of computer, because if it were it would not be possible to physically certify that a random sequence is random.
If my layman’s understanding is correct, the result is essentially that the Kolmogorov complexity of the universe was shown to be at least “equivalent” to the “size” of the universe, which rules out the possibility of it being the result of computation. (Contrasting with the fact that π can be computed because, even though it is an non-repeating infinite series in the decimal system, its Kolmogorov complexity is yet very modest. (That is not hard to conceive. A trivial way to create a non-repeating infinite series is to emit a series of 1s separated by an always-increasing number of 0s. Cycle length: ∞; Kolmogorov complexity: ~0.))
If this is correct, and true, I find it very exciting. I always found the concept of the universe as a kind of simulation profoundly unsatisfying, due to the infinite regress that is immediately invoked: is that computer itself simulated, in turn? If so, does the chain end? If it does, why/how there? It seems like multiplication of entities that achieves nothing in exchange for opening up unlimited arbitrariness potential.
djb has a weblog ♠
Remember when “starting to blog” was a thing? Well, djb just did it.
“Not Crying Over Old Code” ♠
If you join a team that plays a sport you’ve never played before, you can expect to get a “Most Improved” trophy at the end of the year. That’s a good sign… unless you keep getting it every year. […] If you’ve been programming in the same language for half a decade, but still consistently find yourself hating your old code, something is wrong. […] When evaluating how good or bad some code is, it’s important to keep in mind how familiar you are with it. […] Old code will always seem less understandable than you remember, because it’s not as fresh in your mind anymore. Comparing stale old code against fresh new code can create the illusion that you’re constantly improving.
(A seminal moment for me was going back to an old project, fully intent on ripping out a feature in order to simplify and clean up the related part of the code… and finding that I really couldn’t find fault with any of the choices older me had made. It was not at all messy as it had been in my vague recollection. I was left without any changes whatsoever that I still felt compelled to make. I had written good code.)
Productivity porn ♠
This is hilarious to me, that somehow I am getting credit for making an X on a calendar with the Seinfeld productivity program. It’s the dumbest non-idea that was not mine, but somehow I’m getting credit for it.
Monday, Dec 30, 2013, 14:50
Sunday, Dec 22, 2013, 00:32
Hypothesis: ideal line length is in the range where you can peripherally glance the end of the line while fixating on its start, because (further hypothesis) this allows your focus to travel toward a fixed point rather than carefully trying to stay in the narrow track of the line.
(From this would follow that large leading only helps by mitigating the difficulty of tracking an over-long line, but leaves the underlying problem of a missing destination fix point unaddressed.)
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.