<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:at="http://purl.org/atompub/tombstones/1.0" xml:base="http://plasmasturm.org/feeds/plasmasturm/"><title>plasmasturm.org</title><subtitle>musings in human and machine language</subtitle><author><name>Aristotle Pagaltzis</name><email>pagaltzis@gmx.de</email></author><link href="http://plasmasturm.org/"/><id>urn:uuid:41632386-0f0d-11da-9fcb-dd680b0526e0</id><icon>/etc/favicon.ico</icon><a:updated xmlns:a="http://www.w3.org/2005/Atom">2014-03-17T04:09:04+01:00</a:updated><entry><title>A message of hope</title><summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">The past <em>and</em> future web?</div></summary><link href="/log/feedsmatter/"/><id>urn:uuid:3238a2c7-ceb0-47f2-8082-77599ce8ee5a</id><published>2014-03-17T04:09:04+01:00</published><updated>2014-03-17T04:09:04+01:00</updated><content xml:base="/log/feedsmatter/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://blog.feedbin.com/2014/03/11/feedbins-first-year/" title="Feedbin’s First Year">Ben Ubois</a></cite>:</p>
<blockquote cite="http://blog.feedbin.com/2014/03/11/feedbins-first-year/"><p><abbr title="Really Simple Syndication">RSS</abbr> is one of the last holdouts of a more open web and it’s been gratifying to see that there’s enough interest in it to sustain some great independent services that care more about the product than eyeballs.</p></blockquote>
<p>It used to be that the web was a platform – not just its technical underpinnings, but the content itself that was on the web. Then it was gradually reduced to a substrate for supporting a bunch of oil rigs, each isolated. Or so it seems; it is easy to forget that the web still has the platform nature. The magic of the hyperlink has survived, in fact has even been preserved with some care by the new barons. Even Facebook or Google+ ain’t <abbr title="America On-Line">AOL</abbr>. But how much promise has been lost (<a href="http://dashes.com/anil/2012/12/the-web-we-lost.html" title="Anil Dash: The Web we lost"><abbr>cf.</abbr></a>). Yet with the nature of the web never having gone anywhere, maybe what was can be again.</p>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>Sensible Git mail for the occasional user</title><summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">A convenient manual <code>git format-patch</code> workflow</div></summary><link href="/log/gitmail/"/><id>urn:uuid:9c078d61-88b3-4506-9037-55af4f8f7975</id><published>2014-03-11T05:21:50+01:00</published><updated>2014-03-11T05:21:50+01:00</updated><content xml:base="/log/gitmail/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>This entry is mostly for my own benefit, since – being an occasional user – I keep having to figure this out from scratch. What I was aiming for is a workflow that gives me both convenience and full control.</p>
<p>I don’t like <code>git send-email</code>. The command assembles and sends mail all in one go, so you have to know what it will do blindly. Running <code>git format-patch</code> manually first only helps a little, since <code>git send-email</code> still performs its own mail assembly on top of its input. It needs practice – using it frequently for a while and looking at the results. I don’t use it enough for that.</p>
<p>Unfortunately the patchmail I do send every once in a while goes to places with many subscribers, and I’m unwilling to rattle their inboxes with my (repeat!) learning process. I want to be sure I’ll send exactly the mail I mean to, on the very first try. Of course I could dry-run my patchmails by sending them to myself first – fiddly and always one command line typo away from making any mistake public.</p>
<p>I also have <a href="http://msmtp.sourceforge.net/">msmtp</a> set up on my home server with all the details of my <abbr title="Simple Mail Transfer Protocol">SMTP</abbr> accounts and really don’t want to maintain another copy of that information on my laptop, especially on a per-repository basis.</p>
<p>So for me, the answer is to avoid <code>git send-email</code> entirely.</p>
<p>The key realisation is that once a mail is properly formatted, sending it is nothing more than piping it to <code>/usr/bin/sendmail</code> (or whatever equivalent you employ) – so you actually need only <code>git format-patch</code>.</p>
<p>There is just one little wrinkle to take care of: the “<code>From </code>” line it generates needs to be removed before its output can be piped to <code>sendmail</code>. This is easily done using <code>formail</code>, which can also split mboxes, making it a convenient companion to <code>git format-patch --stdout</code>.</p>
<p>Bottom line, this replicates <code>git send-email</code>:</p>
<pre><code class="ft-sh">git format-patch --stdout <i>origin</i> | formail -I 'From ' -s sendmail -t</code></pre>
<p>(Obviously, you season it with <code>--to <i>whomever@example.net</i></code> <abbr title="et ceterea">etc.</abbr> to taste.)</p>
<p>Here, <code>git format-patch</code> produces an mbox-format mail folder, which <code>formail</code> splits into individual mails (“<code>-s …</code>”), and for each mail, deletes the <code>From</code> line (“<code>-I 'From '</code>”) and then pipes the mail to <code>sendmail -t</code>.</p>
<p>But note what I gained here:</p>
<p>I can omit the pipe.</p>
<p>That allows me to inspect the exact mail that will be sent. In fact, if you don’t pipe the output anywhere, Git will invoke the pager for you and even highlight the diffs within the attachments: excellent. Then if I’m satisfied, I add the pipe and out go the patches. (This is much like sending a dry-run to myself first, then sending for real, except with all the friction removed.) I know <em>exactly</em> what is being mailed out. There is no blackbox.</p>
<p>And if there was a cover letter I needed to edit? Then I just pipe to a file first, before piping to <code>formail</code>. In between those steps, I can edit the file – whether in Vim directly, or using <code>mutt -f <i>mbox</i></code>.</p>
<p>Of course, this isn’t necessarily for everyone. You need a machine with procmail installed (for <code>formail</code>) and a <code>sendmail</code>-compatible <abbr title="Mail Transport Agent">MTA</abbr> set up. You also need to be comfortable working with mail in the raw. There is, after all, no blackbox.</p>
<p>But it works for me. Sending patchmail is no longer something I put off.</p>
</div></content></entry><entry><title>By any other name</title><summary>Amit Chatwani summarises Paul Graham</summary><link href="/log/bookofpg/"/><id>urn:uuid:a2024e0e-97af-4d03-b9a2-23221da0d5d5</id><published>2014-02-20T18:27:40+01:00</published><updated>2014-02-20T18:27:40+01:00</updated><content xml:base="/log/bookofpg/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://www.leveragedsellout.com/2014/02/the-book-of-graham/" title="The Book of Graham">Amit Chatwani</a></cite>:</p>
<blockquote cite="http://www.leveragedsellout.com/2014/02/the-book-of-graham/">
<p>It turns out Paul Graham runs a “startup accelerator” located on 320 Pioneer Way in Mountain View, <abbr title="California">CA</abbr> 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.</p>
<p>The accelerator takes small amounts of risk and offloads that aggregate risk onto a market of investors (the <abbr title="Venture Capitalist">VC</abbr>s). Its Demo Day, which first showcases its companies, is a coming out event, like an <abbr title="Initial Public Offering">IPO</abbr>. 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.</p>
</blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>Real as can be, after all?</title><summary>The universe is not computed (apparently)</summary><link href="/log/kolmoguni/"/><id>urn:uuid:ac3e6672-4241-42c0-9512-ccdee29bfb91</id><published>2014-02-13T05:15:54+01:00</published><updated>2014-02-13T05:15:54+01:00</updated><content xml:base="/log/kolmoguni/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://www.math.columbia.edu/~woit/wordpress/?p=6681&cpage=1#comment-206426"> Michael Gogins</a></cite>:</p>
<blockquote cite="http://www.math.columbia.edu/~woit/wordpress/?p=6681&cpage=1#comment-206426">
<p>It is possible to consider that the value of π is <em>not</em> infinite because it <em>is</em> 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.</p>
<p>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.</p>
</blockquote>
<p>If my layman’s understanding is correct, the result is essentially that the <a href="https://en.wikipedia.org/wiki/Kolmogorov_complexity">Kolmogorov complexity</a> 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 a 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.))</p>
<p>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 <em>that</em> computer <em>itself</em> simulated, in turn? If so, does the chain end? If it does, why/how <em>there</em>? It seems like multiplication of entities that achieves nothing in exchange for opening up unlimited arbitrariness potential.</p>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><abbr title="Dan Bernstein">djb</abbr> has a weblog</div></title><link href="/log/djblog/"/><id>urn:uuid:4d9ed64f-d9b8-4d17-9e80-3deb708cc516</id><published>2014-02-07T08:03:11+01:00</published><updated>2014-02-07T08:03:11+01:00</updated><content xml:base="/log/djblog/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>Remember when “starting to blog” was a thing? Well, <a href="http://blog.cr.yp.to/" title="cry.yp.to: blog"><abbr title="Dan Bernstein">djb</abbr> just did it</a>.</p>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>“Not Crying Over Old Code”</title><summary>Craig Gidney on programmer self-evaluation</summary><link href="/log/devgrowth/"/><id>urn:uuid:a7be3b22-d0de-446d-ac98-d9b312e1818e</id><published>2014-01-27T16:21:23+01:00</published><updated>2014-01-27T16:21:23+01:00</updated><content xml:base="/log/devgrowth/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://twistedoakstudios.com/blog/Post8000_not-crying-over-old-code" title="Not Crying Over Old Code">Craig Gidney</a></cite>:</p>
<blockquote cite="http://twistedoakstudios.com/blog/Post8000_not-crying-over-old-code"><p>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… <em>unless you keep getting it every year</em>. […] 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.</p></blockquote>
<p>(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.)</p>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>Productivity porn</title><summary>Jerry Seinfeld on the “Seinfeld method”</summary><link href="/log/nonsein/"/><id>urn:uuid:e249d043-64e5-46c6-b9ab-be4317a9f5f6</id><published>2014-01-15T21:31:59+01:00</published><updated>2014-01-15T21:31:59+01:00</updated><content xml:base="/log/nonsein/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://www.reddit.com/r/IAmA/comments/1ujvrg/jerry_seinfeld_here_i_will_give_you_an_answer/ceiugt5">Jerry Seinfeld</a></cite>:</p>
<blockquote cite="http://www.reddit.com/r/IAmA/comments/1ujvrg/jerry_seinfeld_here_i_will_give_you_an_answer/ceiugt5"><p>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.</p></blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>“Prosumer”</title><link href="/log/prsmr/"/><id>urn:uuid:8b4ac1be-3e76-481a-8659-15c1a9a81253</id><published>2013-12-30T14:50:55+01:00</published><updated>2013-12-30T14:50:55+01:00</updated><content xml:base="/log/prsmr/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><br/></div></content></entry><entry><title>Ideal line length</title><link href="/log/linelen/"/><id>urn:uuid:1688fbcc-4686-40a7-8fad-10c910d42c1e</id><published>2013-12-22T00:32:40+01:00</published><updated>2013-12-22T00:32:40+01:00</updated><content xml:base="/log/linelen/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>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.</p>
<p>(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.)</p>
</div></content></entry><entry><title>Six Stages of Debugging</title><link href="/log/6debug/"/><id>urn:uuid:7dda2d30-7650-11e1-aae4-f2348ec7b0b6</id><published>2012-03-25T09:59:47+02:00</published><updated>2013-11-21T10:52:33+01:00</updated><content xml:base="/log/6debug/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<style type="text/css">
#sixdebug { margin-left: 0 }
#sixdebug li { font-size: 1.6em; font-weight: bold }
#sixdebug li p { font-size: 0.625em; font-weight: normal; margin-left: -.444em }
</style>
<ol id="sixdebug">
<li><p>That can’t happen.</p></li>
<li><p>That doesn’t happen on my machine.</p></li>
<li><p>That shouldn’t happen.</p></li>
<li><p>Why does that happen?</p></li>
<li><p>Oh, I see.</p></li>
<li><p>How did that ever work?</p></li>
</ol>
<p>[<i>This is not mine.</i>]</p>
<ins datetime="2013-11-21T10:52:33+01:00"><p><b>Update</b>: I posted this in the interest of personal archival because the oldest mention I could track down on the web appeared <a href="http://web.archive.org/web/20051027173148/http://www.68k.org/~jrc/old-blog/archives/000198.html" title="Hard core debugging">on a now-defunct weblog</a>. In the meantime, Mike W. Cremer (who bills himself <i>The Newton™ Scapegoat</i> <span class="smiley">☺</span>) <a href="https://news.ycombinator.com/item?id=6477752">has claimed credit</a> for coining it <q cite="https://news.ycombinator.com/item?id=6477752">after a particularly frustrating <abbr title="Direct Memory Access">DMA</abbr> debugging session</q> <q cite="http://mwcremer.blogspot.com/2007/06/six-stages-of-debugging.html">while slaving away on Dante</q> (Newton <abbr title="Operating System">OS</abbr> 2.0). <a href="http://mwcremer.blogspot.com/2007/06/six-stages-of-debugging.html" title="The Six Stages of Debugging ">According to his account</a>, this took place in Apple’s building at 5 Infinite Loop (nicknamed <abbr>RD5</abbr> or <abbr>IL5</abbr>). The list was later to be found taped to Mike Engber’s door in <abbr>IL2</abbr>.</p></ins>
</div></content></entry><entry><title>Write just enough</title><link href="/log/writenough/"/><id>urn:uuid:21f02eda-2888-42b8-9452-fc3e3d3940c4</id><published>2013-10-07T09:11:53+02:00</published><updated>2013-10-07T09:11:53+02:00</updated><content xml:base="/log/writenough/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://getnashty.com/write-less" title="Write less.">Elliot Nash</a></cite>:</p>
<blockquote cite="http://getnashty.com/write-less">
<p><del><b>v1</b> 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 <em>do</em> 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.</del></p>
<p><del><b>v2</b> 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.</del></p>
<p><del><b>v3</b> Reading takes time. The less reading you force someone to do, the more time you save them.</del></p>
<p><b>v4</b> Fewer words create a more powerful message.</p>
</blockquote>
<p>(Excuse the full-quote – I will refer to different parts repeatedly, so I thought it necessary.)</p>
<p>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 <em>even worse</em>. 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 <em>idea</em>. 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.</p>
<p>But all of my criticism so far is too myopic. Step back and you’ll notice the real blunder: Elliot <em>missed his own point!</em> He went for brevity above all else, and his message suffered for it. People <em>do</em> 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…</p>
<p>Fine, that was the wrong direction. What might be a better one? How do you nudge the text toward conveying <em>ideas</em>? 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:</p>
<blockquote><p><b>v2</b> 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.</p></blockquote>
<p>And that is where I’d stop.</p>
<p>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 <em>powerful</em>? (V4’s own words!)</p>
<p>You decide.</p>
<p>Oh, and if Elliot really wanted to be serious about it?</p>
<blockquote><p><b>v5</b> Short is powerful.</p></blockquote>
</div></content></entry><entry><title type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">A minimax <abbr title="Secure Shell">SSH</abbr> key regime</div></title><link href="/log/sshkeys/"/><id>urn:uuid:6a6027d9-114e-48eb-ad3a-52559728eb63</id><published>2013-06-28T22:38:57+02:00</published><updated>2013-08-21T06:17:26+02:00</updated><content xml:base="/log/sshkeys/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>Recently it occurred to me that I had been using the same main <abbr title="Secure Shell">SSH</abbr> 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 <abbr>DSA</abbr> keys, which turns out to have <a href="http://meyering.net/nuke-your-DSA-keys/" title="Non-weak DSA key? oxymoronic, perhaps">a systematic weakness</a>. (Plus, <a href="http://security.stackexchange.com/questions/5096" title="RSA vs. DSA for SSH authentication keys">old versions of the FIPS standard only permitted 1024-bit <abbr>DSA</abbr> keys</a>.)</p>
<p>This had to be fixed. And I wanted an actual regime for my keys, so I wouldn’t repeat this.</p>
<p>Naturally, my new keys are all <abbr>RSA</abbr> and 8192 bit strong. Yes, 8192 – why not? I worried about that slowing down my <abbr title="Secure Shell">SSH</abbr> connections, but I knew adding key length only increases the cost of the handshake phase, and if my <abbr title="Secure Shell">SSH</abbr> connections are taking any longer to set up now, I haven’t noticed. Even if I did notice, <abbr title="Secure Shell">SSH</abbr> 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 <a href="http://www.harding.motd.ca/autossh/">autossh</a> 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.</p>
<p>So how many keys does it make sense to have?</p>
<p>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.</p>
<p>I spent a while reading and thinking.</p>
<p>In terms of private key security, my situation is that on every machine on which I work at a physical console, I run a <abbr title="Secure Shell">SSH</abbr> 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 <abbr title="Secure Shell">SSH</abbr> keys for different servers from the same client. But it does make sense for each client to have its own private keys.</p>
<p>A simple way to encapsulate this as a rule is: <strong>never copy a private key to another machine</strong>.</p>
<p>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.</p>
<p>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 <abbr title="Secure Shell">SSH</abbr> 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.</p>
<ins datetime="2013-08-21T06:17:26+02:00"><p><b>Update</b>: see also <a href="http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html">Improving the security of your <abbr title="Secure Shell">SSH</abbr> private key files</a> by Martin Kleppmann.</p></ins>
</div></content></entry><entry><title>Presented without further comment</title><summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">How Node.js does <abbr title="Hypertext Transfer Protocol">HTTP</abbr> methods</div></summary><link href="/log/njsmethheads/"/><link rel="via" href="http://www.chmod777self.com/2013/08/sigh.html" title="James Snell: Sigh…"/><id>urn:uuid:1180b397-6007-40ba-a0d6-fbe5dcd68447</id><published>2013-08-21T06:06:50+02:00</published><updated>2013-08-21T06:06:50+02:00</updated><content xml:base="/log/njsmethheads/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="https://github.com/joyent/node/blob/85d6b783432e1c58084c3bdebf15cf45384f6572/deps/http_parser/http_parser.c#L891" title="deps/http_parser/http_parser.c">Node.js</a></cite>:</p>
<blockquote cite="https://github.com/joyent/node/blob/85d6b783432e1c58084c3bdebf15cf45384f6572/deps/http_parser/http_parser.c#L891"><pre><code class="ft-c">parser->method = (enum http_method) 0;
parser->index = 1;
switch (ch) {
case 'C': parser->method = HTTP_CONNECT; /* or COPY, CHECKOUT */ break;
case 'D': parser->method = HTTP_DELETE; break;
case 'G': parser->method = HTTP_GET; break;
case 'H': parser->method = HTTP_HEAD; break;
case 'L': parser->method = HTTP_LOCK; break;
case 'M': parser->method = HTTP_MKCOL; /* or MOVE, MKACTIVITY, MERGE, M-SEARCH */ break;
case 'N': parser->method = HTTP_NOTIFY; break;
case 'O': parser->method = HTTP_OPTIONS; break;
case 'P': parser->method = HTTP_POST;
/* or PROPFIND|PROPPATCH|PUT|PATCH|PURGE */
break;
case 'R': parser->method = HTTP_REPORT; break;
case 'S': parser->method = HTTP_SUBSCRIBE; /* or SEARCH */ break;
case 'T': parser->method = HTTP_TRACE; break;
case 'U': parser->method = HTTP_UNLOCK; /* or UNSUBSCRIBE */ break;
default:
SET_ERRNO(HPE_INVALID_METHOD);
goto error;
}
parser->state = s_req_method;</code></pre></blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>On corporations</title><link href="/log/255/"/><id>urn:uuid:e2cb92da-acec-11da-9fcb-dd680b0526e0</id><published>2005-03-08T09:26:08Z</published><updated>2013-08-19T17:14:31+02:00</updated><content xml:base="/log/255/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><a href="http://www.woolamaloo.org.uk/">Joe Edinburgh</a>’s <a href="http://www.woolamaloo.org.uk/2005/01/those-who-profess-to-favor-freedom-and.htm">account of his getting laid off by his 11-year employer</a> is a perfect example of why I’m weary of working in a corporation – a weariness rooted not primarily or even secondarily in that they will want to “own you body and soul like a serf” as Joe exasperatedly protests, huge reasons as these may be.</p>
<p>No, my main objection is that a corporation is not a family. Not only is it not a family, it is not even an entity in any sense other than the legal. To talk of a company having loyalty or trustworthiness is undue humanisation; a company is not a hivemind that takes unified decisions. Even if the superior you report to has a particular opinion of you and takes his decisions according to it, his say may still be overthrown by <em>his</em> superior. Each individual forming the corporation ultimately pursues their own goals, even as the fact that they are all employed by the same company may give them a shared general direction. Therefore, you cannot ultimately count on anything, regardles of your prior performance. In times of adversity, your good deeds or your personal engagement in furthering the company’s cause may be neither valued nor remembered.</p>
<p>Inevitably, investing yourself in a corporate job is a waste of soul. Taking such a job as something that puts food on the table is fine, but don’t get attached to it. Anyone not personally known in the upper echelon is expendable and exchangable, as Joe’s example demonstrates.</p>
<ins datetime="2013-08-19T17:14:31+02:00"><p><b>Update</b>: David Brady makes the same point in <a href="http://www.heartmindcode.com/blog/2013/08/loyalty-and-layoffs/">Loyalty and Layoffs</a>.</p></ins>
</div></content></entry><entry><title>Cargo Cult Simplicity</title><summary>Eevee on copying the wrong lesson</summary><link href="/log/cargnome/"/><id>urn:uuid:09230568-a2aa-4ec1-9c3f-0c29440da965</id><published>2013-06-28T22:41:44+02:00</published><updated>2013-06-28T22:41:44+02:00</updated><content xml:base="/log/cargnome/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://me.veekun.com/blog/2013/06/27/i-bought-a-new-laptop/" title="I bought a new laptop">Eevee</a></cite>:</p>
<blockquote cite="http://me.veekun.com/blog/2013/06/27/i-bought-a-new-laptop/">
<p>In the quest to make the default exposed settings [<i>of <abbr title="GNU Network Object Model Environment">GNOME</abbr></i>] simple, it has become remarkably complicated to actually change any settings I suspect exist but cannot see. So far today I have played with:</p>
<ul>
<li>compizconfig-settings-manager</li>
<li>gnome-tweak-tool</li>
<li>unity-tweak-tool</li>
<li>ubuntu-tweak</li>
<li>dconf-editor</li>
<li>gnome-color-chooser</li>
<li>gtk-theme-config</li>
</ul>
</blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml"><code>rename</code> 1.600</div></title><link href="/log/rename16/"/><id>urn:uuid:68899211-6056-46e0-8dff-6e5c3c502b2b</id><published>2013-06-10T23:53:20+02:00</published><updated>2013-06-10T23:53:20+02:00</updated><content xml:base="/log/rename16/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>I just cut a new release of <a href="/code/rename/" title="rename">rename</a>: 1.600. The headline feature of this version was <a href="http://www.leancrew.com/all-this/2013/03/renaming-files/" title="Dr. Drang: Renaming files">inspired by Dr. Drang</a>: a built-in <code>$N</code> variable for easily numbering files while renaming them. It is accompanied by a <code>--counter-format</code> switch for passing a template, so you will be spared the fiddling with <code>sprintf</code> for padded counters.</p>
<p>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.</p>
<p>In more minor notes, there is now a negatable <code>--stdin</code> switch you can use to explicitly tell <code>rename</code> 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 <code>rename</code> is passed computed arguments that may evaluate to nothing (e.g. with the <code>nullglob</code> shell option).</p>
<p>And lastly, I extracted a new <code>--trim</code> switch from <code>--sanitize</code>, mostly for consistency’s sake.</p>
<p><a href="/code/rename/" title="rename">Share and enjoy</a>.</p>
</div></content></entry><entry><title>Together we can end this destructive conflict</title><summary>Editor ecumenism</summary><link href="/log/vimacsiansunited/"/><id>urn:uuid:a125b43f-58c2-4f91-87d9-69b9e77cddbd</id><published>2013-05-10T03:59:19+02:00</published><updated>2013-05-10T03:59:19+02:00</updated><content xml:base="/log/vimacsiansunited/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://quotes.burntelectrons.org/6905">The irc.mozilla.org qdb</a></cite>:</p>
<blockquote cite="http://quotes.burntelectrons.org/6905">
<pre style="clear:left"><jesup> There is no CapsLock. There is only Ctrl. ;-)
<jesup> First thing I config on any new machine. Can you tell I use emacs?
<mbrubeck> It's the first thing I configure too, and I'm a vi user.
<mbrubeck> Maybe we've found the common ground that can unite a war-torn planet!</pre>
</blockquote>
<p>(<a href="http://www.emacswiki.org/emacs/TabsSpacesBoth">Related.</a>)</p>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>A quote for the ages</title><summary>Jamie Zawinski explains Debian</summary><link href="/log/nutjobs/"/><id>urn:uuid:81726bb6-f6c9-4852-9713-2a097b8f5113</id><published>2013-04-10T22:29:41+02:00</published><updated>2013-04-10T22:29:41+02:00</updated><content xml:base="/log/nutjobs/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://www.jwz.org/blog/2003/05/no-good-deed-goes-unpunished/#comment-81773">jwz</a></cite>:</p>
<blockquote cite="http://www.jwz.org/blog/2003/05/no-good-deed-goes-unpunished/#comment-81773"><p>I tried to explain to <a href="http://rzr-grl.livejournal.com/">rzr_grl</a> what Debian was, and the best I could come up with was that they’re like the Radical Fundamentalist nutjob faction of Linux: people for whom Red Hat is <em>insufficiently extremist</em>. At this point she looks at me as if to say, “you mean the nutjobs have <em>their own</em> nutjobs??” I suspect she thought I was making the whole thing up.</p></blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>EarPods</title><summary>A short review of Apple’s new headphones</summary><link href="/log/earpods/"/><id>urn:uuid:0b869030-1fb4-11e2-b5eb-e51f140530a7</id><published>2012-10-26T23:28:12+02:00</published><updated>2012-10-26T23:28:12+02:00</updated><content xml:base="/log/earpods/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>Curiosity got the better of me: I succumbed to the hype and bought a set of Apple’s new <a href="http://store.apple.com/us/product/MD827LL/A/apple-earpods-with-remote-and-mic">EarPods</a>. These are my thoughts on them after a week.</p>
<p>Basically, they sound OK. They are most certainly a <em>huge</em> improvement on the buds Apple used to make, but the sound quality is not amazing. More noteworthy is that I find them comfortable to wear for any length of time. They also maintain a good fit to the ear by themselves, twisting only slightly out of the optimal position when not held manually. (The old buds were <em>rubbish</em> in both these regards.) Quantitatively speaking they are fine value for the money (they don’t cost much!) but not a brilliant shopping choice.</p>
<p>There is one thing about them however that I have not seen remarked on anywhere else, which makes me not regret this purchase at all.</p>
<p>Maybe it is only owing to a peculiarity of my ears, but somehow the EarPods manage to imbue the low bass range with that <em>subterranean</em> quality of a great bass listening experience on large high-fidelity speakers.</p>
<p>I have never experienced headphones manage to reproduce this before. Circumaural speakers tend to make that bass range sound purely ærial; intra-aural, sealing buds tend to jackhammer it directly against the ear drums; non-sealing buds (of which I have only used cheap ones, admittedly) lack almost all punch. The EarPods somehow manage to drive the bottom end of music with respectable oomph while at the same time being subtle and understated about it.</p>
<p>They aren’t closed, so noisy environments will drown out their bass delivery efforts. But that seeming weakness yields a great upside: it is very comfortable for me to turn the volume up loud <em>and keep it there</em> for quite a stretch without ever getting fatigued by a relentless onslaught of bass – even though it is anything but weak or tinny. Part of that is also the consistently open and transparent sound at any volume level.</p>
<p>Their mediocre crispness at the top end can be distracting when you pay attention, however.</p>
<p>All in all, I am enjoying these as a workhorse set I can pop in to keep myself happy while preoccupied.</p>
<p>In conclusion: buy these not for the exceptional quality they are advertised for, but for their great comfort.</p>
</div></content></entry><entry><title>Glasnost Lives!, or: All Nations Under The Source, or: Linux</title><summary>Alan Cox on spanning political divides with libre software</summary><link href="/log/fsdiplomacy/"/><id>urn:uuid:408e457e-194d-11e2-8c24-ca23140530a7</id><published>2012-10-18T19:57:16+02:00</published><updated>2012-10-18T19:57:16+02:00</updated><content xml:base="/log/fsdiplomacy/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://marc.info/?i=20121004122444.3ff5b099@pyramind.ukuu.org.uk">Alan Cox</a></cite>:</p>
<blockquote cite="http://marc.info/?i=20121004122444.3ff5b099@pyramind.ukuu.org.uk"><p>If you look at Linux contributions they come from everywhere. The core of the network routing code was written by Russians […] who worked at a nuclear research instutite […]. We have code from government projects, from educational projects (some of which are in effect state funded), from businesses, from volunteers, from a wide variety of non profit causes. Today you can boot a box running Russian-based network code with an <abbr title="National Security Agengy">NSA</abbr>-written ethernet driver.</p></blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>Tweet on, tweeter</title><summary>Twitter says Goodbye</summary><link href="/log/twtf/"/><id>urn:uuid:19a15440-e948-11e1-8a0a-1e1e2dc43bb1</id><published>2012-08-18T17:19:27+02:00</published><updated>2012-08-19T03:40:35+02:00</updated><content xml:base="/log/twtf/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><a href="https://dev.twitter.com/blog/changes-coming-to-twitter-api" title="Changes coming in Version 1.1 of the Twitter API">Twitter effectively say quoting a tweet on one’s site as a plain quotation is henceforth outlawed</a>. Idiotic. I doubt they have a legal leg to stand on anyway, but that they would even want to do this is galling just the same. Even more galling to me is that by all I can tell, it appears that even my own tweets would technically be subject to these limitations if I myself chose to quote them elsewhere.</p>
<p>It’s not like I was very active on Twitter in recent times, but this move has completely soured me on the service.</p>
<p>When Twitter killed the ability to see <em>all</em> @-replies from your followees in your stream, even those to people you didn’t yourself follow, my enthusiasm dropped off a cliff. Remember that? As far as I’m concerned, that is when communal Twitter died. A lot of people quit in a huff. I stuck around, though the place was never the same again. Next, the client I was using (which was effectively unmaintained by then but had kept working) fell over dead when Twitter made OAuth a requirement. I never found a replacement both lightweight and inoffensive enough. (On Linux you could find either or, but not both. I have not tried again in a while.) So I’ve stuck around by using just the site, only poking in every once in a while because the site is not a convenient persistent client. My vague intention was to one day make a serious effort to find a new client and get back into it.</p>
<p>So much for that.</p>
<p>And their presumption in wanting to dictate to the world what they are allowed to do with, err, 140 characters of plain text makes me want to neither read nor write anything on Twitter any more.</p>
<p>So I am washing my hands of it.</p>
<ins datetime="2012-08-19T03:40:35+02:00"><p><b>Update</b>: <a href="http://venomousporridge.com/post/29593222426/bullshit-matrix" title="Dan Wineman: Bullshit Matrix">Hah! Ha ha.</a> Not the reason I am irritated per se, but illustrative nonetheless.</p></ins>
</div></content></entry><entry><title type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Code that <em>counts</em></div></title><summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">Tom DeMarco on how a project’s need for metrics and its value relate</div></summary><link href="/log/valueofcontrol/"/><link rel="via" href="http://fishbowl.pastiche.org/2012/07/02/you_cant_control_what_you_cant/" title="Charles Miller: “You can’t control what you can’t measure” revisited."/><id>urn:uuid:27497654-c922-11e1-9881-296e5ddeb8d9</id><published>2012-07-08T19:27:12+02:00</published><updated>2012-07-08T19:27:12+02:00</updated><content xml:base="/log/valueofcontrol/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p><cite><a href="http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf" title="Software engineering: An Idea Whose Time Has Come and Gone [PDF]">Tom DeMarco</a></cite>:</p>
<blockquote cite="http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf">
<p>My early metrics book, <cite>Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982)</cite>, played a role in the way many budding software engineers quantified work and planned their projects. […] The book’s most quoted line is its first sentence: “You can’t control what you can’t measure.” This line contains a real truth, but I’ve become increasingly uncomfortable with my use of it.</p>
<p>Implicit in the quote (and indeed in the book’s title) is that control is an important aspect, maybe the most important, of any software project. But it isn’t. Many projects have proceeded without much control but managed to produce wonderful products such as Google Earth or Wikipedia.</p>
<p>To understand control’s real role, you need to distinguish between two drastically different kinds of projects:</p>
<ul>
<li><p>Project A will eventually cost about a million dollars and produce value of around $1.1 million.</p></li>
<li><p>Project B will eventually cost about a million dollars and produce value of more than $50 million.</p></li>
</ul>
<p>What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.</p>
</blockquote>
</div></content><category scheme="http://plasmasturm.org/" term="seen" label="Seen"/></entry><entry><title>Magic</title><summary>Fred Brooks on the act of programming</summary><link href="/log/mythical/"/><id>urn:uuid:b161f7d2-a0bc-11e1-99e6-3ea65ddeb8d9</id><published>2012-05-18T09:40:08+02:00</published><updated>2012-05-31T02:31:44+02:00</updated><content xml:base="/log/mythical/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<blockquote>
<p>The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. […]</p>
<p>Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.</p>
<p>[…]</p>
<p>Not all is delight, however […] One must perform perfectly. The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Human beings are not accustomed to being perfect, and few areas of human activity demand it.</p>
</blockquote>
<p style="text-align: right">—<cite>Fred Brooks, The Mythical Man-Month</cite></p>
<p>There I am, tattered-robed old man standing alone, beard whipping in the wind, with a distant stare (slightly mad), intently murmuring an unintelligible ramble under his breath… until <em>something happens</em>. To read this passage the first time was an arresting moment of revelation of a truth I had known without knowing, all along.</p>
</div></content></entry><entry><title>An orphan olive branch to Mercurial</title><summary>A merge-less Git release process</summary><link href="/log/gitnb/"/><id>urn:uuid:e38c8314-9638-11e1-93a5-119e5ddeb8d9</id><published>2012-05-05T00:31:27+02:00</published><updated>2012-05-05T19:00:30+02:00</updated><content xml:base="/log/gitnb/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p class="set-stage">Git repository browsers have universally awful graph drawing algorithms.</p>
<p>For the longest time, one of my repositories has had two main branches, <code>master</code> and <code>release</code>. For a release, I would <code>git merge --no-ff master</code> into <code>release</code>. (Using <code>--no-ff</code> forces a commit on <code>release</code> even if <code>release</code> could be fast-forwarded to the current state of <code>master</code>. That way the act of cutting a release is always recorded in the repository.) Development happens on <code>master</code>, sometimes on branches. Topic branches are rebased before merging them back to <code>master</code>, once again using the <code>--no-ff</code> switch to record that a certain stretch of commits belonged to one topic together.</p>
<p>Essentially, this is a two-track history, with occasional short parallel side tracks on one side:</p>
<pre> o--o--o--o
/ \
-o---o---o---o---o---o------------o---o---o---o---o---o---o---o master
\ \ \ \ \ \ \
-------o---o-----------o--------------------o---o-------o---o release</pre>
<p>You would think that this would be easy to draw in a sane way.</p>
<p>And most of the time it is. But sometimes repository browsers decide to to draw <code>release</code> on the other side of <code>master</code>. And as it happens, sometimes a topic falls by the wayside for a while. When these conditions coincide, drawing the stray heads from these topic branches and at the same time drawing <code>release</code> in such a way that the merge direction (<em>from</em> <code>master</code> <em>into</em> <code>release</code>) is correct suddenly requires snaking each <code>release</code> commit around all the previous ones. The result is a marshalling yard of parallel tracks (which I will not try to give an ASCII diagram of…) for representing what in reality is a very simple history. That makes it very difficult to make heads or tails of what really happened in the repository: a whole Black Forest out of just two trees.</p>
<p>There are some ordinary options to suppress this. The most obvious one would be to do a fast-forward merge of <code>release</code> back into <code>master</code> before picking up again. Doing so yields a triangular structure like this:</p>
<pre> o--o--o--o
/ \
-o---o o o---o---o /------------o---o---o o o---o o---o master
\ / \ / \ / \ / \ / \ / \
-------o---o-----------o------------------------o---o-------o---o release</pre>
<p>Here there are no parallel tracks: the only unbroken track is the <code>release</code> branch, so no matter when and how any algorithm tries to draw this graph, it will be forced to string the commits into short side tracks alongside the <code>release</code> track. There is no likely way to turn this into a funhouse of illusory complexity.</p>
<p>Any solution that merges <code>release</code> into <code>master</code> in any way will have a very annoying drawback, however: you can no longer read the history of <code>master</code> without getting all of the release merges interspersed into it. This is all the worse if you never gave you those merge commit messages much thought, because that means the history of <code>release</code> by itself consists of nothing but an endless row of “Merge 'master' into release”. And if that was bad enough by itself, it gets <em>really</em> irritating during periods when most commits are released immediately: the noise takes up a major part of your commit log.</p>
<p>Then an epiphany disrupted my long-standing dissatisfaction with the situation.</p>
<p>This is what the history in my repository looks like now:</p>
<pre> o--o--o--o
/ \
-o---o---o---o---o---o------------o---o---o---o---o---o---o---o master
-------o---o-----------o--------------------o---o-------o---o release</pre>
<p>That’s right: no merges.</p>
<p>Yet again, <code>release</code> is a single unbroken track. But now so is <code>master</code>. And since the branches are unconnected, it is never necessary to arrange them relative to each other, so they will always be drawn properly. And the <code>master</code> commit log remains clean and readable.</p>
<p>What I have done is make <code>release</code> an orphan branch that shares no history with <code>master</code> (created with <code>git checkout --orphan</code>). To cut a release, I check out <code>release</code>, then I get the tree from the commit I want to release and put that in a new commit on <code>release</code>. Obviously with this scheme I need to manually record the commit ID somewhere to be able to know what state of <code>master</code> a particular release corresponded to – there is no longer merge metadata to keep track of that. The commit message seems a natural place to record that information. I need to construct one in any case since Git does not know how to provide a default message for these commits like it does when merging a branch. Of course, the extended commit message is also a good place to put a list of commits that are hitching a ride on this release. I decided to put a release version (in my case, a simple incrementing integer) in the commit message subject as well, to make it easy to refer to a particular release.</p>
<p>Needless to say, I have the process automated. This is my release script:</p>
<pre><code class="ft-sh">#!/bin/bash
set -e
commit=`git rev-parse "${1-master}"`
read num junk oldcommit <<<`git log --no-walk --format=%s release --`
(
printf '%d @ %s\n\n' $((++num)) $commit
git log --reverse --oneline --abbrev=12 --no-decorate --no-color $oldcommit..$commit
) \
| git commit-tree $commit^{tree} -p release \
| ( read new ; git update-ref refs/heads/release $new )
git push -f origin master release</code></pre>
<p>Aside from the hard linkage by commit ID you also get a soft correlation by commit date if you ask <code>git log</code> and friends to use <code>--date-order</code>. This is sufficient for routine development work. Note that since the commit IDs are recorded, it is possible to use grafts to retrospectively (possibly temporarily) make the orphan <code>release</code> branch seem as though a mergeful branch.</p>
<p>A nice aspect of doing things this way is how easy it is to get a full diff of the total change represented by a release. With a merge-based <code>release</code> branch it takes fiddling to ask for that diff and enough knowledge to know how to.</p>
<p>And so I seem to have arrived at a poor (technically awkward, functionally very limited) reinvention of Mercurial’s named branches, using the plumbing provided by Git. This may be the only true use case for named branches that I can think of.</p>
<ins datetime="2012-05-05T19:00:30+02:00"><p><b>Update</b>: I’ve rewritten the script to use lower-level plumbing. It no longer even checks out the tree, it just directly creates a commit object based on the tree object of the released commit.</p></ins>
</div></content></entry><entry><title>D’uh</title><summary type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">A shell one-liner courtesy of <abbr title="GNU’s Not Unix">GNU</abbr></div></summary><link href="/log/binduh/"/><id>urn:uuid:ab00aa32-92b1-11e1-8de0-a5295ddeb8d9</id><published>2012-04-30T12:45:57+02:00</published><updated>2012-05-02T14:52:57+02:00</updated><content xml:base="/log/binduh/" type="xhtml"><div xmlns="http://www.w3.org/1999/xhtml">
<p>I recently discovered the <code>-h</code> switch of <abbr title="GNU’s Not Unix">GNU</abbr> <tt>sort</tt>, added in the coreutils 7.5 release from Aug 20, 2009. With this switch, <code>sort</code> will do a numeric sort of human-readable size numbers, <abbr title="that is,">i.e.</abbr> it will accept “42M” and “1.3G” as numbers and put them in the right order. This led to the following shell one-liner in my <tt>~/bin</tt>:</p>
<pre><code class="ft-sh">#!/bin/bash<br/>exec du "${@--xd1}" -h | sort -h</code></pre>
<p>It invokes <code>du</code> to print the disk space consumption of a directory tree, then sorts its output by size. If you pass any switches they will be passed on to <code>du</code>, else it will default to <code>-xd1</code> (<code>-x</code> = stay on one filesystem, do not cross mountpoints; <code>-d1</code> = do not print directories deeper than 1 level).</p>
<p>I gave this script the only name it could have – obviously, <code>duh</code>.</p>
<ins datetime="2012-05-02T14:52:57+02:00">
<p><b>Update</b>: turns out that the <code>-d</code> switch of <code>du</code> is even newer than <code>sort</code>’s <code>-h</code> switch. It was added for compatibility with Free<abbr title="Berkeley Systems Distribution">BSD</abbr> in the coreutils 8.6 release from Oct 15, 2010 – prior to that it had to be spelled <code>--max-depth</code>, which rather complicates matters. You would have to do this:</p>
<pre><code class="ft-sh">#!/bin/bash<br/>DEFAULT=(-x --max-depth=1)<br/>exec du "${@-${DEFAULT[@]}}" -h | sort -h</code></pre>
<p>That’ll win neither beauty nor concision contests.</p>
</ins>
</div></content></entry></feed>