This feed does not validate.

In addition, interoperability with the widest range of feed readers could be improved by implementing the following recommendations.


  1. <?xml version="1.0" encoding="utf-8"?>
  2. <feed xmlns="" xml:base=""><title></title><subtitle>musings in human and machine language</subtitle><author><name>Aristotle Pagaltzis</name><email>[email protected]</email></author><link href=""/><id>urn:uuid:41632386-0f0d-11da-9fcb-dd680b0526e0</id><icon>/favicon.ico</icon><updated>2018-08-11T00:17:15+02:00</updated><entry><title type="xhtml"><div xmlns="">The <abbr>HTTPS</abbr> divide</div></title><summary type="xhtml"><div xmlns="">Eric Meyer on <abbr>HTTPS</abbr> under low development</div></summary><link href="/log/https-divide/"/><id>urn:uuid:6e7e0b5b-139c-4a2a-a6ad-a10a0f284052</id><published>2018-08-11T00:17:15+02:00</published><updated>2018-08-11T00:17:15+02:00</updated><content xml:base="/log/https-divide/" type="xhtml"><div xmlns="">
  3.  <p><cite><a href="" title="Securing Web Sites Made Them Less Accessible">Eric Meyer</a></cite>:</p>
  4.  <blockquote cite="">
  5.    <p>I saw a piece that claimed, “Investing in <abbr>HTTPS</abbr> makes it faster, cheaper, and easier for everyone.” If you define “everyone” as people with gigabit fiber access, sure. Maybe it’s even true for most of those whose last mile is copper. But for people beyond the reach of glass and wire, every word of that claim was wrong.</p>
  6.  </blockquote>
  7.  <p><a href="/log/privconf/" title="Privacy vs confidentiality in protocols">Someone who goes by Roy called this quite a while ago</a>: an <abbr>HTTPS</abbr>-only web is a web without intermediaries, built on a costlier protocol, and that has real costs. <em>This</em> (as opposed to the likes of Dave Winer’s <a href="" title="Google and HTTP">barely-sensical</a> <a href="" title="Questioning Google’s motives re the push to HTTPS">paranoia</a>) is why I am skeptical about the move to <abbr>HTTPS</abbr>, albeit acknowleding the necessity given the lack of better solutions in the near term. Non-benign network operators and universal surveillance are real problems that need to be addressed. We are not in a great place right now.</p>
  8.  <p>There <em>are</em> better options beyond the horizon, though. Don’t miss Eric’s comment section: several people mention ideas and proposals currently in the works. There is hope for… someday.</p>
  9. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title type="xhtml"><div xmlns="">Who knows an <abbr title="Extensible Markup Language">XML</abbr> document from a hole in the ground?</div></title><summary>Namespace droppings and bozotic aggregator developers</summary><link href="/log/376/"/><id>urn:uuid:6ac67b4a-862e-11da-9fcb-dd680b0526e0</id><published>2006-01-16T02:21:27+01:00</published><updated>2018-05-22T17:32:26+02:00</updated><content xml:base="/log/376/" type="xhtml"><div xmlns="">
  10.  <p>Hello back, everyone. (With a tip o’ the titular hat to <a href="" title="Phil Ringnalda: Who knows a &lt;title&gt; from a hole in the ground?">Phil Ringnalda</a>.) Some of you who’re seeing this will now be scampering to catch up on 20 of my entries, posted since the beginning of last December.</p>
  11.  <p>Reticent a person though I am, in general, I am not <em>that</em> reticent. For those of you who wondered why it’s gotten so silent around here, the reason is simple: because you didn’t notice that you need to file a bug report against the aggregator of your choice.</p>
  12.  <p>Yes, that’s right. The software you use is broken. And make no mistake, you’re not alone. There is a wide range of choices among bug trackers (or customer support forms), and their associated software, to file reports against.</p>
  13.  <p>This all happened because I tried to be a clever and good citizen and, in the process, save a bit of space in a smart way. But let’s backtrack a bit, and let me tell you what happened, and what the effect has been.</p>
  14.  <p>Until the beginning of December, the structure of my feed looked like this (and from today on looks like so again):</p>
  15.  <pre>&lt;feed xmlns=""&gt;
  16.  &lt;title&gt;;/title&gt;
  17.  &lt;!-- additional feed metadata elided --&gt;
  18.  &lt;!-- things such as subtitle, author etc --&gt;
  19.  &lt;entry&gt;
  20.    &lt;title type="xhtml"&gt;
  21.      &lt;div xmlns=""&gt;Foo&lt;/div&gt;
  22.    &lt;/title&gt;
  23.    &lt;summary type="xhtml"&gt;
  24.      &lt;div xmlns=""&gt;Bar&lt;/div&gt;
  25.    &lt;/summary&gt;
  26.    &lt;content type="xhtml"&gt;
  27.      &lt;div xmlns=""&gt;&lt;p&gt;Baz&lt;/p&gt;&lt;/div&gt;
  28.    &lt;/content&gt;
  29.    &lt;!-- additional entry metadata elided --&gt;
  30.  &lt;/entry&gt;
  31.  &lt;!-- more entries follow --&gt;
  32. &lt;/feed&gt;</pre>
  33.  <p>You can see that there are <code>xmlns=""</code> bits strewn everywhere; in practice the effect is less drastic than it appears here where I’m eliding a bunch of Atom tags and any sensible content.</p>
  34.  <p>This setup means that in the document at large, the default namespace is <code></code> – so tags like <code>&lt;feed&gt;</code> are to be interpreted according to <a href="" title="The Atom Syndication Format"><abbr title="Request for Comments">RFC</abbr> 4287</a> –, but for the <code>&lt;div&gt;</code> tags and their contents, the default namespace is <code></code> – so that the tags are to be interpreted according to the <a href=""><abbr title="Extensible Hypertext Markup Language">XHTML</abbr> Recommendation</a>.</p>
  35.  <p>This works perfectly in everything that claims support for Atom.</p>
  36.  <p>Then, in the beginning of December, I read an enlightening piece on <abbr title="Extensible Markup Language">XML</abbr> citizenship by <a href="">Joe English</a>, titled <a href="">A plea for Sanity</a>, whose focus is how to structure <abbr title="Extensible Markup Language">XML</abbr> documents with regards to namespaces such that software to process them can be kept simple, and which sets forth a few definitions on documents that are not sane. According to his definitions, my feed was <i>neurotic</i>: two different namespaces are mapped to the same prefix (<abbr title="that is,">i.e.</abbr> the null prefix) at different points in the document.</p>
  37.  <p>I chose the neurotic structure I outlined above because it seemed logical to choose the Atom namespace as the default namespace for an Atom document at large. Since I author my weblog by editing a master feed (which contains the entire archive of the log) by hand, however, I definitely want the <abbr title="Extensible Hypertext Markup Language">XHTML</abbr> namespace to be the default for the sections of the document which contain <abbr title="Hypertext Markup Language">HTML</abbr>: having to write namespace prefixes in every tag would make the already tiresome experience of hand-written markup truly painful.</p>
  38.  <p>An added bonus is that despite the frequent repetition of the default namespace declaration, it actually saves space on declaring a prefix to map to the namespace once at the top of the feed and then having to write <code>&lt;h:p&gt;Foo&lt;/h:p&gt;</code> everywhere. Across the whole feed, these two characters per tag easily add up to much more than the fixed cost of a namespace declaration in every text/content construct.</p>
  39.  <p>However, reading the plea for sanity inspired me to try something counterintuitive: declare the <abbr title="Extensible Hypertext Markup Language">XHTML</abbr> namespace as the default <em>for the entire document</em> and instead declare a prefix for the Atom namespace. This leads to a structure like so:</p>
  40.  <pre>&lt;a:feed xmlns:a="" xmlns=""&gt;
  41.  &lt;a:title&gt;;/a:title&gt;
  42.  &lt;!-- additional feed metadata elided --&gt;
  43.  &lt;!-- things such as subtitle, author etc --&gt;
  44.  &lt;a:entry&gt;
  45.    &lt;a:title type="xhtml"&gt;&lt;div&gt;Foo&lt;/div&gt;&lt;/a:title&gt;
  46.    &lt;a:summary type="xhtml"&gt;&lt;div&gt;Bar&lt;/div&gt;&lt;/a:summary&gt;
  47.    &lt;a:content type="xhtml"&gt;&lt;div&gt;&lt;p&gt;Baz&lt;/p&gt;&lt;/div&gt;&lt;/a:content&gt;
  48.    &lt;!-- additional entry metadata elided --&gt;
  49.  &lt;/a:entry&gt;
  50.  &lt;!-- more entries follow --&gt;
  51. &lt;/a:feed&gt;</pre>
  52.  <p>This is a <i>sane</i> <abbr title="Extensible Markup Language">XML</abbr> document. And according to <abbr title="Extensible Markup Language">XML</abbr> specifications, both this form of the document and the previous one are semantically exactly identical. They mean the exact same thing, and any compliant software which can process one of them will produce the exact same results given the other.</p>
  53.  <p>It’s also worth noting that the number of Atom tags within an Atom entry is small and varies very little. So even though I’m having to prefix every Atom tag, this actually saves space on redeclaring the <abbr title="Extensible Hypertext Markup Language">XHTML</abbr> namespace over and over. (Right now, the master feed, even though the savings are particularly diminished in it because it contains the entire archive and thus has a much higher <abbr title="Hypertext Markup Language">HTML</abbr>-to-Atom ratio than the newsfeed on the site, is about 1.2% smaller in its sane version than in the neurotic one. For the on-site feed, the ratio is a tad larger; not much, but with frequently requested documents like newsfeeds, a penny saved is a penny got.)</p>
  54.  <p>I was very pleased with myself for figuring out a way to improve my feed while reducing its size in the process.</p>
  55.  <p>Too pleased.</p>
  56.  <p>As a matter of fact, within a few days, Scott Arrington got in touch on <abbr title="Internet Relay Chat">IRC</abbr> and informed me that my feed was suddenly throwing an error in Safari: <q>Safari can’t open the page “feed://”</q>, it said, and misleadingly continued: <q>The error was: “unknown error” (NSURLErrorDomain:-1)</q> (after all, the problem has nothing to do with a domain in the internet sense; though maybe <i>error domain</i> is Apple framework lingo for <i>error type</i> or <i>error class</i>).</p>
  57.  <p>I shrugged. Surely, this was an outlier. Certainly, breakage like that wouldn’t go unnoticed. Likely, it would be fixed with the next batch of updates.</p>
  58.  <p>As a matter of fact, yes, it <em>is</em> nice to live with the illusion that the basics of <abbr title="Extensible Markup Language">XML</abbr> are at least moderately well understood, in this year 2006 of the Lord. Thanks for asking.</p>
  59.  <p>Until tonight delivered a rude awakening from Jagath Narayan to my inbox. He informed me that my feed failed to parse in a number of aggregators. So I got on <abbr title="Internet Relay Chat">IRC</abbr> and asked Scott’s assistance to test drive a few more Mac aggregators with the feed.</p>
  60.  <p>Here’s the list of known broken aggregators as of this writing:</p>
  61.  <ul>
  62.    <li>Safari 2.0.3</li>
  63.    <li>Firefox 1.5</li>
  64.    <li>Thunderbird 1.5</li>
  65.    <li><a href="">NewsFire</a> 1.2 (v45)</li>
  66.    <li><a href="">Feedreader</a> 2.90</li>
  67.    <li><a href="">BottomFeeder</a> 4.1</li>
  68.    <li><a href="">Bloglines</a> (big surprise…)</li>
  69.  </ul>
  70.  <p>What about the remaining major browser? Opera 8.51 is not broken – because it doesn’t support Atom 1.0 at all. (The upcoming version 9.0 will.)</p>
  71.  <p><strong>None</strong> of the major browsers with feed support are compliant in their latest version. How depressing.</p>
  72.  <p>Here’s a list of known working aggregators:</p>
  73.  <ul>
  74.    <li><a href="">Liferea</a></li>
  75.    <li><a href="">NetNewsWire</a></li>
  76.    <li><a href="">Google Reader</a></li>
  77.    <li><a href="">Universal Feed Parser</a></li>
  78.  </ul>
  79.  <p>And here’s <a href="/attic/atom-tests/nondefaultnamespace.atom" type="application/atom+xml">a test case</a>. Please <a href="mailto:[email protected]">mail me</a> further results, and of course, file bugs avidly.</p>
  80.  <p>So now my feed is back to its old, neurotic form, and works for a lot more people. It feels good to know I’m back, even though I never knew I was gone.</p>
  81. </div></content></entry><entry><title>Mutually assured intel</title><summary>A soundbite on the anti-parochial complexity of high-tech</summary><link href="/log/e-n-trust/"/><id>urn:uuid:84888867-eebd-4bbb-a80c-6235eb03b7ae</id><published>2018-05-10T19:18:44+02:00</published><updated>2018-05-10T19:18:44+02:00</updated><content xml:base="/log/e-n-trust/" type="xhtml"><div xmlns="">
  82.  <p><cite><a href="" title="Supply-Chain Security">Bruce Schneier</a></cite>:</p>
  83.  <blockquote cite="">
  84.    <p>Supply-chain security is an incredibly complex problem. [National]-only design and manufacturing isn’t an option; the tech world is far too internationally interdependent for that.</p>
  85.    <p>We can’t trust anyone, yet we have no choice but to trust everyone.</p>
  86.  </blockquote>
  87. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title type="xhtml"><div xmlns="">Doubly detached <abbr title="Internet Relay Chat">IRC</abbr></div></title><summary>Reaping Mosh’s full benefits for long-running terminal sessions</summary><id>urn:uuid:aaf421c6-fe58-4433-aba5-289ea30ed4b1</id><published>2018-02-08T05:13:25+01:00</published><updated>2018-02-08T05:13:25+01:00</updated><link href="/log/dtach-twice/"/><content xml:base="/log/dtach-twice/" type="xhtml"><div xmlns="">
  88.  <p>For long-running terminal sessions such as <abbr title="Internet Relay Chat">IRC</abbr>, I’ve long used <a href="">dtach</a> (or <a href="">Screen</a>, or <a href="">tmux</a>, it doesn’t matter) to be able to leave them running on a server without having to be connected to it… just like everyone else does. But recently I put together some simple facts in a retrospectively obvious way that I haven’t heard of anyone else doing, and thus achieved a little quality of life improvement.</p>
  89.  <p>I wrote before about <a href="/log/mosh/" title="Endorsing Mosh">how much I love Mosh when I need it</a>. And when I had the insight I am writing about, I was in a situation where I seriously needed it. (If you don’t know what <a href="">Mosh</a> is, read about it first, because ⓐ you’re missing out and ⓑ the rest of this article won’t make much sense otherwise.)</p>
  90.  <p>Here’s the thing about Mosh, though: it still has to go through regular <abbr title="Secure Shell">SSH</abbr> in order to bring up a Mosh session. And on a severely packet-lossy connection, that alone can be hell.</p>
  91.  <p>The real beauty of Mosh comes to the fore only if you keep the session around once it’s set up. As long as it’s up, then no matter how bad the packet loss, you get decent interactivity. But to fully benefit from that, you have to avoid tearing the session down.</p>
  92.  <p>My problem is that try as I might, I have never been able to break with my compulsion to close terminal windows once I am done with them. For <abbr title="Internet Relay Chat">IRC</abbr> that means sooner or later I’ll want to detach from a session I’m not actively chatting in. And because I use Mosh to run dtach on the remote end, detaching from <abbr title="Internet Relay Chat">IRC</abbr> means that the dtach client exits on the remote end… which tears down the Mosh session.</p>
  93.  <p>The simple fact that suddenly occurred to me is that I can <em>also</em> use dtach on <em>my</em> end of the connection, <em>in front</em> of Mosh:</p>
  94.  <pre><code class="ft-sh">dtach -A ~/.dtach/irssi mosh <i>hostname</i> dtach -A ~/.dtach/irssi irssi</code></pre>
  95.  <p>Now when I detach, it is only from my local dtach session, not the one on the server. So the Mosh session behind it sticks around – without me having to keep the terminal window open.</p>
  96.  <p>The upshot is a dtach ↔ Mosh ↔ dtach sandwich which gives me the full benefits of Mosh.</p>
  97.  <hr/>
  98.  <p>If you want to use this yourself, note the procedure to end the Mosh session in this case:</p>
  99.  <pre><code class="ft-sh">dtach -a ~/.dtach/irssi -E # and then press the detach shortcut</code></pre>
  100.  <p>The <code>-E</code> switch disables the keyboard shortcut for detaching in the local dtach client. This means when you press the shortcut it gets sent to the remote dtach client. What follows then is exactly the same chain of events as always when you detach from the remote dtach session: the remote dtach client exits, so Mosh exits. And therefore the local dtach session ends as well. Detaching from the remote end thus brings the whole edifice down, and the simplest way to trigger that is to disable detaching on the local end.</p>
  101. </div></content></entry><entry><title>Don’t be a problem-solver</title><summary>Resist tools and abstractions</summary><link href="/log/begets-complexity/"/><id>urn:uuid:a04e8b14-228b-4f3f-a7fa-de41b907cbe2</id><published>2017-12-24T12:45:28+01:00</published><updated>2017-12-24T12:45:28+01:00</updated><content xml:base="/log/begets-complexity/" type="xhtml"><div xmlns="">
  102.  <p><cite><a href="">halvarflake</a></cite>:</p>
  103.  <blockquote cite=""><p>The one rule of thumb is: If you allow complexity into a place that should be simple, more complexity will follow.</p></blockquote>
  104. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>Backoff</title><summary>A simple, robust algorithm for backoff</summary><link href="/log/backoff/"/><id>urn:uuid:3011239c-7f24-43f9-b0bc-af63ff8ab2cd</id><published>2017-09-15T03:12:06+02:00</published><updated>2017-09-19T09:11:58+02:00</updated><content xml:base="/log/backoff/" type="xhtml"><div xmlns="">
  105.  <p>Some time ago I had occasion to implement (mostly exponential) back-off in an application for the first time. This is not a hard problem, but at the outset I expected it to be one of those annoying cases where the code is only clear to read when you are immersed in the problem it solves.</p>
  106.  <p>Not so. It turns out there is a trivially simple algorithm if you pick the right form of stored state – namely, a pair of timestamps: <code>(last_success, next_retry)</code>. The essential form of the algorithm goes like this:</p>
  107.  <pre><code>if succeeded { last_success = now }
  108. next_retry = last_success, i = 0
  109. until next_retry &gt; now {
  110.  next_retry += step_size(i)
  111.  i += 1
  112. }</code></pre>
  113.  <p>Because this recalculates the scheduling for the next retry by starting over from the previous success, every time, it is totally resilient against all fluctuations in the environment. Belated or missing retry attempts have no effect on its output. Even swapping the <code>step_size</code> function for an entirely different one mid-flight just works!</p>
  114.  <p>At the same time, it is trivial to reason out and verify that this algorithm works correctly.</p>
  115.  <p>I was quite pleased.</p>
  116.  <hr/>
  117.  <p>(In practice you will likely not have a separate <code>step_size</code> function and <code>i</code> counter but rather some kind of <code>step</code> variable iterated along with <code>next_retry</code>. But here I wanted to abstract away from the specific formula used.)</p>
  118.  <ins datetime="2017-09-19T09:11:58+02:00">
  119.    <p><b>Update</b>: As prompted by a question from Matthew Persico, let me clarify that my use case is scheduling polls that succeed only intermittently, meaning that I always want to wait at least once between attempts, which is why I used “<code>until next_retry &gt; now</code>”.</p>
  120.    <p>If instead you want to add backoff to an operation that only <em>fails</em> intermittently (e.g. draining a buffer to I/O) then you’ll want to use “<code>while next_retry &lt; now</code>” for your loop, so you can have zero-delay back-to-back attempts.</p>
  121.  </ins>
  122. </div></content></entry><entry><title type="xhtml"><div xmlns="">Useful GitHub Issues overviews</div></title><link href="/log/myghissues/"/><id>urn:uuid:25d510b2-e34e-432a-8109-48a829234ccf</id><published>2016-04-24T14:06:46+02:00</published><updated>2017-08-28T16:00:42+02:00</updated><content xml:base="/log/myghissues/" type="xhtml"><div xmlns="">
  123.  <p>I’ve always found the default, easily available views of GitHub Issues inadequate for my purposes. I want to separate issues by the kind of action I’ll want to take, but the interface is fundamentally oriented around a single list of issues, and by default that is just a big dump of every issue that involves you in some way. Luckily all the buttons are just <abbr title="User Interface">UI</abbr> over a query language, and the query language turns out to be just barely powerful enough to allow me to get the overviews I really want.</p>
  124.  <p>So here are the queries I arrived at. Together they approximate a basic dashboard. Unfortunately there is not, to my knowledge, a keyword in the query language to refer to “whoever the currently logged in user is”, so I cannot demonstrate them as effectively as I’d like: you will have to manually edit them to subsitute your username for mine.</p>
  125.  <ul>
  126.    <li>
  127.      <h3><a href="">is:open user:ap</a></h3>
  128.      <p>This shows all issues filed by anyone against any repositories that I own.</p>
  129.      <p>Semantically, this one is “stuff waiting for me to fix”.</p>
  130.    </li>
  131.    <li>
  132.      <h3><a href="">is:open author:ap -user:ap</a></h3>
  133.      <p>This shows all issues I have filed against repositores I do not own.</p>
  134.      <p>Semantically, this one is “stuff I need to keep bugging others about”.</p>
  135.    </li>
  136.    <li>
  137.      <h3><a href="">is:open commenter:ap -author:ap -user:ap</a></h3>
  138.      <p>This shows all issues filed by others against repositories I do not own, which I have nevertheless commented on.</p>
  139.      <p>Semantically, this one is “stuff I care about as a bystander”.</p>
  140.    </li>
  141.    <li>
  142.      <h3><a href="">is:open involves:ap -commenter:ap -author:ap -user:ap</a></h3>
  143.      <p>This shows all issues filed against repositories I do not own, which I have been mentioned in but have not commented on. There can be dross in here; I have a short username, and people importing content into GitHub sometimes trigger bogus mentions by having <code>@ap</code> somewhere in it. By isolating the things passively attached to me, I gain more use of the other queries.</p>
  144.      <p>Semantically, this one is “stuff someone considers me relevant to (or maybe spam)”.</p>
  145.    </li>
  146.  </ul>
  147.  <p>That collection gives me a reasonable handle on everything I need to take care of one way or another, which I could not get from GitHub’s own built in views.</p>
  148.  <ins datetime="2017-08-28T16:00:42+02:00"><p><b>Update</b>: I’ve split the last query, “<code>involves:ap -author:ap -user:ap</code>”, in two. Now it is divided on the source of my involvement as a bystander: myself or others.</p></ins>
  149. </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>2017-08-23T11:41:08+02:00</updated><content xml:base="/log/6debug/" type="xhtml"><div xmlns="">
  150.  <style type="text/css">
  151.  #sixdebug { margin-left: 0 }
  152.  #sixdebug li { font-size: 1.5em; font-weight: bold; margin-left: -.7em }
  153.  #sixdebug li p { font-size: 0.766667em /* 1.15/1.5 */; font-weight: normal }
  154.  </style>
  155.  <ol id="sixdebug">
  156.    <li><p>That can’t happen.</p></li>
  157.    <li><p>That doesn’t happen on my machine.</p></li>
  158.    <li><p>That shouldn’t happen.</p></li>
  159.    <li><p>Why does that happen?</p></li>
  160.    <li><p>Oh, I see.</p></li>
  161.    <li><p>How did that ever work?</p></li>
  162.  </ol>
  163.  <p>[<i>This is not mine. I posted it in the interest of personal archival because the oldest mention I could track down on the web appeared <a href="" title="Hard core debugging">on a now-defunct weblog</a>. In the meantime, Mike W. Cremer (who bills himself </i>The Newton™ Scapegoat <span class="smiley">☺</span><i>) <a href="">has claimed credit</a> for coining it <q cite="">after a particularly frustrating <abbr title="Direct Memory Access">DMA</abbr> debugging session</q> <q cite="">while slaving away on Dante</q> (Newton <abbr title="Operating System">OS</abbr> 2.0). <a href="" 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>.</i>]</p>
  164. </div></content></entry><entry><title>Fixing a Google Chrome failure to save passwords</title><link href="/log/chromepwstore/"/><id>urn:uuid:5a088add-b78a-48db-bc02-bfd9c9470753</id><published>2017-07-02T00:33:41+02:00</published><updated>2017-07-02T00:33:41+02:00</updated><content xml:base="/log/chromepwstore/" type="xhtml"><div xmlns="">
  165.  <p>This is a kind of post that people used to write back in the heady early days of blogging and a more communal web: putting something out there to help Google help other people.</p>
  166.  <h2>The problem</h2>
  167.  <p>For some time I had been having an irritating persistent failure with Google Chrome that I could not find an answer for:</p>
  168.  <ul>
  169.    <li>After logging into some website, it would offer me to save the password, as usual.</li>
  170.    <li>I would click on the save button.</li>
  171.    <li>Chrome would not show any kind of error.</li>
  172.    <li>But the password would not be saved:</li>
  173.    <li>It was not filled in automatically next time I went to the same site.</li>
  174.    <li>No password at all showed up in the list on <code>chrome://settings/passwords</code> – the list just stayed blank no matter what I did.</li>
  175.  </ul>
  176.  <p>Mysteriously, a handful of passwords did get stored, somehow, somewhere. Chrome could fill those in, even as it woudn’t list them on the settings screen. I checked the <abbr>MacOS</abbr> keychain and did not find them there, so they had to be stored by Chrome, even though it refused to show them to me.</p>
  177.  <h2>The quest</h2>
  178.  <p>Searching the web about my problems, almost all answers I could find related to the case of people who are logged into Google within Chrome and use its password syncing service… which I don’t. I simply want my passwords saved locally.</p>
  179.  <p>The few answers I did find that seemed to relate to my situation invariably suggested resetting one’s profile. Now, that approach does appear not to be mere superstition: of the people I found who had this problem, the ones who reported back all wrote that resetting their profile fixed the problem. So I had a way of making the problem go away – but I also have a lot of data in my profiles. It’s not just my bookmarks. I have tweaked many of the settings, individually for each profile (the whole point of using profiles, after all), and I also use a number of extensions, many of which themselves have extensive configurations. Recreating that all is a big task.</p>
  180.  <p><strong>I want password auto-fill fixed while keeping my profiles intact. I am only willing to lose my stored passwords.</strong> (Because I save them in a password manager first anyway.)</p>
  181.  <p>So I went poking around in the directories where Chrome stores its profiles and other user data. There’s no need to look far: there’s a file called <code>Login Data</code>. This is an <abbr>SQ</abbr>Lite database (like most of Chrome’s user data files). It can be opened using the <code>sqlite3</code> command line utility and examined using <abbr title="Structured Query Language">SQL</abbr> queries. I did that, and there they were, my mysteriously saved passwords… plus a bunch more.</p>
  182.  <p>I also discovered that some of the data in those tables is scrambled in some form. Presumably there are several separatedly stored pieces of data required to unscramble that data, and some of those pieces somehow become mismatched on my system – I don’t know how nor why, and was too lazy to research. All I cared was that this looked like the right vicinity.</p>
  183.  <p>As an experiment, I moved the <code>Login Data</code> file and its <code>Login Data-journal</code> pair out of one profile… and bingo, password auto-fill started working there as expected. After saving a password, Chrome would subsequently successfully auto-fill it as well as list it on the saved passwords screen.</p>
  184.  <p>Good enough for me.</p>
  185.  <h2>The solution</h2>
  186.  <p>Deleting the files <code>Login Data</code> and <code>Login Data-journal</code> from a profile fixes password saving in that profile – without affecting any other data in it. A full profile reset is not necessary – you can reset just the password storage by deleting just the files that it uses.</p>
  187.  <p>This does mean you lose any passwords you had stored previously, unfortunately. But since you cannot really access them any more anyway, that data loss has effectively already happened by the time you delete the files.</p>
  188.  <h2>Instructions</h2>
  189.  <ol>
  190.    <li><p>Quit Chrome.</p></li>
  191.    <li>
  192.      <p>Go to the directory where Chrome stores its user-specific data, below your user home directory:</p>
  193.      <dl style="display: grid; grid-auto-columns: min-content 1fr; grid-auto-flow: column">
  194.        <dt style="grid-column: 1">Mac</dt><dd><code>~/Library/Application Support/Google/Chrome</code></dd>
  195.        <dt style="grid-column: 1">Linux</dt><dd><code>~/.config/google-chrome</code></dd>
  196.        <dt style="grid-column: 1">Windows</dt><dd><code>%UserProfile%\AppData\Local\Google\Chrome\User Data</code></dd>
  197.      </dl>
  198.    </li>
  199.    <li><p>From there, go into the directory called <code>Default</code> if you want to fix your main profile, or into <code>Profile 1</code> or <code>Profile 2</code> <abbr title="et cetera">etc.</abbr> to fix one of your extra profiles.</p></li>
  200.    <li><p>Delete the files <code>Login Data</code> and <code>Login Data-journal</code>.</p></li>
  201.    <li><p>Repeat for other profiles as necessary.</p></li>
  202.  </ol>
  203. </div></content></entry><entry><title>Drunk driving on the information superhighway</title><summary>Metaphor of the year, by Ev Williams</summary><link href="/log/webdui/"/><id>urn:uuid:6a624c03-fcb9-4d67-8471-e2a5270158c8</id><published>2017-05-23T21:12:44+02:00</published><updated>2017-05-23T21:12:44+02:00</updated><content xml:base="/log/webdui/" type="xhtml"><div xmlns="">
  204.  <p><cite><a href="" title="‘The Internet Is Broken’: @ev Is Trying to Salvage It">The New York Times</a></cite>:</p>
  205.  <blockquote cite=""><p>The trouble with the internet, Mr. [Evan] Williams says, is that it rewards extremes. Say you’re driving down the road and see a car crash. Of course you look. Everyone looks. The internet interprets behavior like this to mean everyone is asking for car crashes, so it tries to supply them.</p></blockquote>
  206. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>My dependence on Big Tech</title><link href="/log/bigtechdeps/"/><id>urn:uuid:6f227947-d678-4e28-ac82-e176a2bf4594</id><published>2017-05-06T18:13:54+02:00</published><updated>2017-05-06T18:13:54+02:00</updated><content xml:base="/log/bigtechdeps/" type="xhtml"><div xmlns="">
  207.  <p><cite><a href="">Farhad Manjoo</a></cite>:</p>
  208.  <blockquote cite=""><p>What’s the order in which you would drop Apple, Amazon, Google, Facebook from your life, if forced to — from first to last.</p></blockquote>
  209.  <ol>
  210.    <li><p>Facebook is already not part of my life. (That’s a lie, but it’s at a minutes-a-month level. And they are most reluctant minutes.)</p></li>
  211.    <li><p>Apple… I would greatly miss the quality of various aspects of their products, but using them already requires compromise. So I would make do.</p></li>
  212.    <li><p>Amazon is mostly of use to me in terms of research: I use it to browse reviews and to find niche products I wouldn’t know how to search for otherwise. It’s not a big part of my life and I try to keep it that way, but losing it would be painful on those occasions where I have come to rely on it.</p></li>
  213.    <li><p>Google’s loss would be painful every single day. I wish I <em>could</em> sever my dependence on their web search and their maps, so I’ve looked for alternatives repeatedly and in anger. None come close.</p></li>
  214.  </ol>
  215.  <p>(The distances are nowhere near even. Facebook trails the pack by a very large gap; Google leads it with a significant one.)</p>
  216. </div></content></entry><entry><title>My scraped feeds are now my scrapped feeds</title><link href="/log/eolfeeds/"/><id>urn:uuid:7faad6a4-0978-4f00-9841-17ca320e715d</id><id>urn:uuid:e8ea5b70-1637-40f2-8925-d993d428ebb0</id><published>2016-10-16T21:54:43+02:00</published><updated>2016-10-16T21:54:43+02:00</updated><content xml:base="/log/eolfeeds/" type="xhtml"><div xmlns="">
  217.  <p>I used to host a handful of scraped newsfeeds here at <code>/feeds/</code>. Over the years, their number shrank as most scraped sites set up their own feeds, then excitement over feeds evaporated. While I wasn’t looking, subscribers bled away, then disrepair set in.</p>
  218.  <p>This is the end of the line. It was time. So it goes.</p>
  219. </div></content></entry><entry><title type="xhtml"><div xmlns=""><code>templates.vim</code></div></title><link href="/log/211/"/><id>urn:uuid:e762d79a-acec-11da-9fcb-dd680b0526e0</id><published>2005-01-06T23:45:54Z</published><updated>2016-01-03T19:23:14+01:00</updated><content xml:base="/log/211/" type="xhtml"><div xmlns="">
  220.  <p>I finally packaged up my <a href="">templates.vim</a> script for public consumption. It lets you use filetype-dependent templates for new files in <a href="">Vim</a>, using a simple but effective mechanism.</p>
  221. </div></content></entry><entry><title>Good Mail Sorting</title><summary>Processing mail is hard(ly difficult)</summary><link href="/log/mailsort/"/><id>urn:uuid:a5ee3024-7c37-458b-8376-e72673618c9f</id><published>2015-12-21T05:45:37+01:00</published><updated>2015-12-21T05:45:37+01:00</updated><content xml:base="/log/mailsort/" type="xhtml"><div xmlns="">
  222.  <p>When I started writing this, 13 months ago or so, I had been frenetically hacking my mail rig for a couple days. I sat and wrote, because it had been a revelation.</p>
  223.  <h2>Setting</h2>
  224.  <p>For years I used a setup on my home server where cron would kick off <a href="">fetchmail</a> (since replaced by <a href="">mpop</a>), which would in turn invoke <a href="">procmail</a> to deliver each received mail, putting it somewhere in my set of folders. Then I read that mail in <a href="">mutt</a> over a <abbr title="Secure Shell">SSH</abbr> connection.</p>
  225.  <p>I love mutt.</p>
  226.  <h2>Act Ⅰ</h2>
  227.  <p>My first impetus to do something was frustration over my <abbr title="Voice over IP">VoIP</abbr> telephony voicebox notifications. Those come as mail with the voicemail attached as a sound file. Because I can’t well play them in a mutt running on another machine, I have to get the attachment out and onto my laptop.</p>
  228.  <p>Previously I tried to automate this by having procmail send these mails to a script that would extract the attachment and discard the mail itself. I never quite got this working right, so I never actually used it.</p>
  229.  <p>This time I succeeded – by the choice of having the script scan my inbox for new mail <em>after</em> delivery. (It looks for voicebox mail, plucks out the sound file, then deletes the mail.) Since my inbox is a <a href="">Maildir</a>, this is easy code: a <code>readdir</code> to list the mails, an <code>open</code> to scan them, an <code>unlink</code> to delete the matching ones. So now I never deal with voicebox mails directly any more, I just run this script against the network share when I’ve missed calls, and up pop some files on my laptop, which I can play. Convenient.</p>
  230.  <p>(Not as convenient as clicking a play button in a <abbr title="Graphical User Interface">GUI</abbr> or web mail client, granted. But using one of those would be far more inconvenient on other counts. Tradeoffs. (Have I mentioned I love mutt?))</p>
  231.  <h2>Act Ⅱ</h2>
  232.  <p>So I then realised that I could use the exact same approach to write another script I’ve unsuccessfully attempted once before – namely, to mark some mail as read before I’ve even seen it.</p>
  233.  <p>I used to have a program that I wrote for this – again, invoked from my procmail configuration, delivering mail in procmail’s stead and marked the way I wanted – but I stopped using it when I noticed that it would drop mail, rarely, under circumstances I never managed to pinpoint.</p>
  234.  <p>Now I have this functionality again, and now I can completely trust the code never to lose mail again, because all it does this time around is <code>readdir</code> and <code>rename</code>.</p>
  235.  <p>I forgot how nice this setup is when it works. I have mutt set up to show only threads with new mail when I open a mailing list folder, so if the noisy notification traffic I don’t care about is already marked as read, it is essentially invisible to me. (I don’t want to killfile the chaff. I like correct threading so much, and there are sometimes replies to these mails, long chains of them even. I don’t want those floating about with no context.)</p>
  236.  <h2>Anagnorisis — When mail processing is hard</h2>
  237.  <p>Here’s the problem: the period during which a mail exists only in main memory, before it is delivered and on disk, is quite high-stakes. Code that handles mail during this period must be absolutely solid, reliable at all times without exception without fail, in order to avoid dropping mail on the floor. You can afford no errors. Any typo that aborts program execution will cost you mail. Any bug that manifests someday in the future will cost you mail. Editing the code and saving it in half-finished form before you’re done will cost you mail if cron kicks off a fetch at that moment. In short, a mistake of any kind tends to default to costing you mail. And so every possible error condition must be covered by failsafes and rescue measures. This is a very hard environment, grim and unforgiving.</p>
  238.  <p>However. Once the mail is on disk, and once it’s in a Maildir in particular, things get incomparably relaxed: the likelihood of losing the mail to a small mistake drops precipitously. You have to screw up very hard to manage to lose data. At that point, scripts processing mail just deal with files to move around. It’s not by any means impossible to write data loss bugs then too – but mistakes default to leaving your mail where it was. That’s a stress-free situation.</p>
  239.  <p>(Indeed with the Maildir-based scan-and-move approach, the mark-as-read program was basically trivial.)</p>
  240.  <h2>Act Ⅲ</h2>
  241.  <p>Now I had to figure out when to run this program. It had to have a way to specify rules for what messages to mark as read, and so it took rules as command line arguments. Then, because different folders need different rules, I wrote a shell script that invoked the program first on one folder with some rules, then another with others, <abbr title="et cetera">etc.</abbr></p>
  242.  <p>Now when would I invoke that shell script, though? By hand, like the voicemail extractor? One thing I realised while writing the script was, I could also put the mpop invocation inside it, and then kick off that script from cron instead of invoking just mpop itself. Because of course the best time to run the script is right after new mail has (potentially) arrived.</p>
  243.  <p>It took a day until it dawned on me what I had just done.</p>
  244.  <p>If I have cron kick off a script that fetches mail and then only afterwards moves some of it around…</p>
  245.  <p><em>… then why do I need procmail at all?</em></p>
  246.  <h2>Synthesis — Mail filtering can be easier and better</h2>
  247.  <p>See, over the years, I have forever wanted to get rid of procmail, because its configuration syntax is so awful. But I have been putting it off ever since I <a href="">read about Mail::Audit</a> back in… yes, 2001. (Later along came <a href="">Email::Filter</a>, and later still some aid for dealing with the harsh environment in the form of <a href="">Email::Pipemailer::DieHandler</a>.)</p>
  248.  <p>But I knew the data loss default cost of mistakes, so I stuck with procmail grudgingly instead of trying to replace it with some custom code, because I trusted procmail with my mail’s arrival on disk – if not fully then at least to an extent that I wouldn’t trust my own attempts. I’m only a dilettante at mail-handling code (not being familiar with the ground it has to have covered), and in any case procmail is battle-tested in a way my own attempts will never ever be.</p>
  249.  <p>What I didn’t realise is that I don’t need to write code to do what procmail does. I can just have mpop deliver all of my mail to a transit folder, then invoke a script that scans this transit folder and kicks any mail it finds in there over to its destination.</p>
  250.  <p>This has some very attractive properties. Unconditional delivery to disk makes it very robust against losing mail, dwarfing even procmail. Code that enumerates files and then moves them around is much harder to screw up catastrophically than code that is responsible for data that only exists in main memory. And thus I get to write the code that does the rule-checking and file-moving in a real programming language, rather than crappy procmail syntax.</p>
  251.  <h2>Reflection</h2>
  252.  <p>For over a decade, I was so fixated on doing the mail processing during delivery that I was blind to the much simpler approach that was staring me right in the face. After all, every tool that I considered using is designed this way: Mail::Audit; Email::Filter; Courier’s <a href="">maildrop</a>; common <a href="">Sieve</a> implementations; <abbr title="et cetera">etc.</abbr> So I never even made the connection that another approach was possible. It seemed like the obvious natural and sole way of doing it.</p>
  253.  <p>Until I finally did realise it. And kicked myself for days. To think: all the automation I could have set up years ago (<abbr>cf.</abbr> voicemail extractor); all the mail I could’ve not lost (not very much, all told, but all of it avoidable). Just the friction of trying to use the misshapen language of an ill-fitting tool, for years on end.</p>
  254.  <p>Don’t pick the wrong problem to fight with. Life is better that way.</p>
  255. </div></content></entry><entry><title>Rates</title><summary type="xhtml"><div xmlns="">André Weil on ego and mastery</div></summary><link href="/log/rate123/"/><id>urn:uuid:54f90011-e9d5-43c0-9835-cbe65689cba2</id><published>2015-12-03T17:12:34+01:00</published><updated>2015-12-03T17:12:34+01:00</updated><content xml:base="/log/rate123/" type="xhtml"><div xmlns="">
  256.  <p><cite>André Weil</cite>:</p>
  257.  <blockquote><p>First-rate mathematicians choose first rate people, but second-rate mathematicians choose third rate people.</p></blockquote>
  258.  <p>(Filed here for reference.)</p>
  259. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>On business data processing needs</title><summary type="xhtml"><div xmlns="">A consultant on Excel <abbr title="versus">vs</abbr> databases</div></summary><link href="/log/xlvsdb/"/><id>urn:uuid:d4658cdf-3a77-4d1f-bb81-3c198d4a32f3</id><published>2015-07-22T18:26:38+02:00</published><updated>2015-07-22T18:26:38+02:00</updated><content xml:base="/log/xlvsdb/" type="xhtml"><div xmlns="">
  260.  <p><cite><a href="" title="Office, messaging and verbs">Ben Evans</a></cite>:</p>
  261.  <blockquote cite=""><p>I spoke on Twitter a while ago to a consultant who told me that half his jobs were telling people using Excel to switch to a database and the other half were telling people using a database to switch to Excel.</p></blockquote>
  262. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title type="xhtml"><div xmlns="">Privacy <abbr title="versus">vs</abbr> confidentiality in protocols</div></title><summary type="xhtml"><div xmlns="">Roy Fielding on “<abbr title="Transport Layer Security">TLS</abbr> everywhere”</div></summary><link href="/log/privconf/"/><id>urn:uuid:2d9bce35-a488-491e-b7c3-258c137ee7b7</id><published>2015-06-07T19:55:29+02:00</published><updated>2015-06-07T19:55:29+02:00</updated><content xml:base="/log/privconf/" type="xhtml"><div xmlns="">
  263.  <p><cite><a href="" title="Re: Proposed Statement on “HTTPS everywhere for the IETF”">Roy T. Fielding</a></cite>:</p>
  264.  <blockquote cite="">
  265.    <p><abbr title="Transport Layer Security">TLS</abbr> does not provide privacy. What it does is disable anonymous access to ensure authority. It changes access patterns away from decentralized caching to more centralized authority control. That is the opposite of privacy. <abbr title="Transport Layer Security">TLS</abbr> is desirable for access to account-based services wherein anonymity is not a concern (and usually not even allowed). <abbr title="Transport Layer Security">TLS</abbr> is <strong>not</strong> desirable for access to public information, except in that it provides an ephemeral form of message integrity that is a weak replacement for content integrity.</p>
  266.    <p>[…] <abbr title="Transport Layer Security">TLS</abbr> everywhere is great for large companies with a financial stake in Internet centralization. It is even better for those providing identity services and <abbr title="Transport Layer Security">TLS</abbr>-outsourcing via <abbr title="Content Delivery Network">CDN</abbr>s. […]</p>
  267.    <p>If the <abbr title="Internet Engineering Task Force">IETF</abbr> wants to improve privacy, it should work on protocols that provide anonymous access to signed artifacts (authentication of the content, not the connection) that is independent of the user’s access mechanism.</p>
  268.  </blockquote>
  269.  <p>[<i>Slightly reordered for the purposes of quoting.</i>]</p>
  270. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>Endorsing Mosh</title><link href="/log/mosh/"/><id>urn:uuid:77f33d06-4618-4659-9f02-b0d9facb05f6</id><published>2015-03-31T09:39:03+02:00</published><updated>2015-03-31T09:39:03+02:00</updated><content xml:base="/log/mosh/" type="xhtml"><div xmlns="">
  271.  <p><a href="" title="My preliminary views on mosh">Chris Siebenmann is skeptical about Mosh</a>, which spurred me to write down my own feelings about it:</p>
  272.  <center><p><big>I <abbr title="love">♥</abbr> <a href="" title="The mobile shell">Mosh</a>!</big></p></center>
  273.  <p>When I’m traveling, I generally go online through hotel and conference networks. They almost always exhibit precipitously fluctuating latencies and often-miserable throughput. Occasionally they have tragic levels of packet loss. Just using Screen/Tmux/dtach over a <abbr title="Secure Shell">SSH</abbr> connection (<a href="">as a commenter on Chris’ entry suggested</a>) doesn’t come close to cutting it, because <abbr title="Secure Shell">SSH</abbr> itself is utterly unusable under such circumstances. I’ve had situations where it took dozens of timeouts before any connection would succeed, only to drop within seconds. On such a network, <abbr title="User Datagram Protocol">UDP</abbr> is of the essence to get even an inkling of a usable connection. And only protocol-integrated predictive terminal emulation (i.e. Mosh) allows making full use of the benefits that the application of <abbr title="User Datagram Protocol">UDP</abbr> to this scenario permits. So if you have to operate in a miserable networking environment, Mosh is indispensable.</p>
  274.  <p>Then, I embark on the journey back, and I throw Mosh out of my setup the minute I step off my return flight (or whatever else I am travelling on). If I can afford not to use Mosh, if I have a network connection worth calling that (and that really doesn’t take a lot), then the way Mosh operates – built-in non-optional detaching, inability to support <abbr title="Secure Shell">SSH</abbr>’s various forms of forwarding, and server-side per-session dæmons that never go away on error conditions – is <em>grating</em>. I can’t stand using it when I’m back in my usual haunts where <abbr title="Secure Shell">SSH</abbr> works well.</p>
  275.  <p>So there you go. I’m very glad it exists, because when I <em>need</em> it, it’s a sanity lifeline. But it cannot do its job unseen, and you’re in a real bad place if you need it. So however grateful I may be, I much prefer to neither need nor use it.</p>
  276.  <p>If you think this sounds schizophrenic, that’s because it is. Indeed this is a strange endorsement, I realise that. But let me assure you: when I need Mosh, I am <em>so</em> happy it exists.</p>
  277. </div></content></entry><entry><title>Three Gigahertz Forever</title><link href="/log/3ghz4ever/"/><id>urn:uuid:acba7e75-928d-49ee-834e-91dec7b7fc53</id><published>2015-03-09T15:18:26+01:00</published><updated>2015-03-09T15:18:26+01:00</updated><content xml:base="/log/3ghz4ever/" type="xhtml"><div xmlns="">
  278.  <p>I hear people occasionally mention that <abbr title="Central Processing Unit">CPU</abbr> clock rates have been stuck around 3 <abbr title="Gigaherz">GHz</abbr> for a while. They say that multicore instead of higher clock rates is a trend. But it seems few realise how far this while has stretched.</p>
  279.  <p>The last time <abbr title="Central Processing Unit">CPU</abbr> clock rates went up was when the Pentium 4 Prescott <abbr>LGA</abbr> 570J came out and hit 3.8 <abbr title="Gigaherz">GHz</abbr> – in 2005.</p>
  280.  <p>It’s been a <em>decade</em> that <abbr title="Central Processing Unit">CPU</abbr> clock rates have been frozen. Exponential increases in single-threaded performance are well and truly over.</p>
  281.  <p>We now live in the titular era: the era of <i>Three Gigahertz Forever</i>.</p>
  282.  <p>Meanwhile, Moore’s Law has continued to apply, so we have still been getting ever faster chips despite the new situation. But the gains have moved sideways into multi-threaded performance. That’s not a “trend” any more, it’s the status quo.</p>
  283.  <p>Even with that, we have arrived on the outskirts of the era of Dark Silicon. An end to Moore’s Law itself is within sight. While it’s unclear how far off it really is – it’s hard to tell the distance of something you don’t know the size of –, we now find the eventual end of Moore’s Law to be a tangible inevitability.</p>
  284.  <p>What’s more, power consumption has increasingly gained importance as an optimisation target. Now of course optimising for power consumption largely has the same basic shape as optimising for speed – try to achieve the goal with less work, try to avoid needing to achieve the goal at all. Where power consumption differs is that it can be sensitive to wasted work even in non-hotspot areas of the code.</p>
  285.  <p>So not only can the “just wait for hardware to catch up” approach no longer cover for slow code, but power consumption now demands caring about wasteful work even where it previously never mattered.</p>
  286.  <p>The free lunch is over.</p>
  287. </div></content></entry><entry><title>Endorsing Scan Tailor</title><summary>Feels like magic</summary><link href="/log/scantailor/"/><id>urn:uuid:8cc68913-73da-4871-b349-2ef355fab8cf</id><published>2015-03-09T14:50:02+01:00</published><updated>2015-03-09T14:50:02+01:00</updated><content xml:base="/log/scantailor/" type="xhtml"><div xmlns="">
  288.  <p>I can never quite believe how phenomenal <a href="" title="Scan Tailor">this application</a> is. <em>It feels like magic</em>. Like what using computers should be like.</p>
  289.  <p>This is what it’s for:</p>
  290.  <blockquote><p>An <em>interactive</em> post-processing tool for scanned pages. It performs operations such as page splitting, deskewing, adding/removing borders, and others. You give it raw scans, and you get pages ready to be printed or assembled into a <abbr title="Portable Document Format">PDF</abbr> or <code>DJVU</code> file.</p></blockquote>
  291.  <p>Emphasis mine.</p>
  292.  <p>It doesn’t try to create perfect documents automatically. It does an astonishing first pass, actually, but that still has many so-so guesses – far from perfect. The automation is not magic. (Or maybe, is only minor magic.) Even so, this first pass is very valuable, because you get to edit a passable starting point, rather than having to do the entire job from scratch. For this editorial work, the program gives you a range of image processing algorithms tailored very specifically for the job, using <abbr title="User Interface">UI</abbr> controls that are cast exactly in terms of your senses.</p>
  293.  <p>And therein lies the magic. If you have ever whittled away at some menial task using an inadequate tool, then switched to the right one for the job, you’ll know the feeling – suddenly it gets easier so much, it’s as though you were cheating. But the outcome is still entirely of your doing. This is what’s going on here – just drastically amplified by the fact that the material used to fashion the tool is not simple wood or metal but a general purpose computer.</p>
  294.  <p>A bicycle for the mind… <em>and</em> the hands of a craftsman.</p>
  295.  <p>You start with a dog’s breakfast of a scan, and you get yourself a document that looks like it came out of a vector graphics program – because that’s what the computer makes you capable of doing.</p>
  296.  <p>Magic.</p>
  297. </div></content></entry><entry><title>For Mozilla</title><summary type="xhtml"><div xmlns="">Stuart Langridge on Mozilla supporting <abbr title="Digital Rights(?) Management">DRM</abbr> in Firefox</div></summary><link href="/log/holdthedoor/"/><id>urn:uuid:b53d923f-6536-4df9-ac83-1386a0a3d7d2</id><published>2014-05-20T22:37:46+02:00</published><updated>2015-02-08T04:03:20+01:00</updated><content xml:base="/log/holdthedoor/" type="xhtml"><div xmlns="">
  298.  <p><cite><a href="" title="Mozilla add HTML5 DRM, sadly but inevitably">Stuart Langridge</a></cite>:</p>
  299.  <blockquote cite=""><p>Mozilla have stood on principle in the past, by refusing to implement H.264 format video. It made no difference. […] There’s always been an edge of, well, they’re doing the right thing which means that I don’t have to. Firefox should stand on principle here and refuse to play <abbr>DRM</abbr>ed videos… but of course I’m not going to <em>stop</em> using <abbr>DRM</abbr>ed video, I’ll just use Safari for that. […] If you dislike Mozilla doing this (which I do, too), then where’s the outcry against Apple and Microsoft and Google for doing the same thing? Where’s the outcry against them for doing it <em>first</em>? Mozilla helps keep the web open for us, but in return we have to help keep the web open for Mozilla. And we aren’t.</p></blockquote>
  300.  <ins datetime="2015-02-08T04:03:20+01:00"><p><b>Update</b>: <a href="" title="Youtube Ditches Flash, and it Hardly Matters: Meet the New Boss, Same as the Old Boss">we have moved away from a priopriety plugin from Adobe by means of a proprietary binary blob from Adobe</a>.</p></ins>
  301. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>Communal software through communal funding</title><summary>Support Free Software charities: a Bradley Kuhn appeal</summary><link href="/log/librefunding/"/><id>urn:uuid:47ec952b-68d1-42d6-9927-986e2ad6afd4</id><published>2014-12-14T00:53:21+01:00</published><updated>2014-12-14T00:53:21+01:00</updated><content xml:base="/log/librefunding/" type="xhtml"><div xmlns="">
  302.  <p><cite><a href="" title="Help Fund Open-Wash-Free Zones">Bradley M. Kuhn</a></cite>:</p>
  303.  <blockquote cite="">
  304.    <p>Our community suffers now from regular and active cooption by for-profit interests. […] The primary mechanism of cooption [is to] encourage funding only from a few, big sources so they can slowly but surely dictate project policy. […] Open Source became a fad, and now it's “cool” for for-profit companies to release code, or channel funds through some trade associations to get the code they want written and released [more slyly than <a href="">traditional open-washing</a>]: picking a seemingly acceptable license for the software, but “engineering” the “community” as a proxy group controlled by for-profit interests.</p>
  305.    <p>This cooption phenomenon leaves the community-oriented efforts of Free Software charities underfunded and (quite often) under attack. These same companies that fund plenty of Open Source development also often oppose copyleft. […] Unless we change our behavior, the larger Open Source and Free Software community may soon look much like the political system in the <abbr title="United States of America">USA</abbr>: where a few lobbyist-like organizations control the key decision-making through funding.</p>
  306.    <p>[…]</p>
  307.    <p>Just pick the 501<span style="font-family: 'Hiragino Kaku Gothic Pro', 'Arial Unicode MS'">ⓒ③</span> non-profit charity in the Free Software community that you like best and donate.</p>
  308.  </blockquote>
  309. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>Introducing Buftabline</title><link href="/log/buftabline/"/><id>urn:uuid:9d0f806c-66d0-49e9-8bb4-8fca55a4a898</id><published>2014-11-15T10:10:53+01:00</published><updated>2014-11-15T10:10:53+01:00</updated><content xml:base="/log/buftabline/" type="xhtml"><div xmlns="">
  310.  <p>Almost ever since I started using Vim, I have been in search for a satisfactory persistent visualisation of the buffer list. I have used many hacks over the years, some written by others, some of my own attempt. None ever felt right.</p>
  311.  <p>Roughly a year ago, I had a sudden moment of clarity: Vim has already had for a while the functionality required to build this feature, it just usually serves a different purpose. Namely, ever since Vim has supported tabs, it has been able to render them both in text mode and as <abbr title="Graphical User Interface">GUI</abbr> tabs. Their text mode rendering is exactly what a buffer list would need as well. Why not re- (or ab-)use the <code>tabline</code> for buffer tabs?</p>
  312.  <p>I implemented a first stab at this but it had several severe deficiencies. It scratched my own itch just well enough, however, so I dragged my feet for a year.</p>
  313.  <p>To my chagrin, I cannot even claim to have had this idea first, much less (in my tardiness) claim first implementation: <a href="">Airline</a> <em>shipped</em> an implementation of this exact idea at the time it occurred to me independently. Oh well. (Subsequently I discovered several more plugins, all of which seem to be younger than Airline’s implementation.)</p>
  314.  <p>But recently I finally got around to finishing up my own script to the point where it is actually releasable. So without further ado:</p>
  315.  <div align="center"><a href=""><img src="/log/buftabline/screenshot.png" width="667" height="501" alt="" style="padding: 10px 20px 0"/><br/>Buftabline</a></div>
  316.  <p>It is designed with the ideal that it should Just Work, and has no configurable behaviour: drop it into your configuration and you’re done. Needless to say I like my own take better than the competitors; but I have also contrasted it with each of them in <a href="">the documentation</a>, so you can make your own call on that.</p>
  317.  <p><a href="">Share and enjoy</a>.</p>
  318. </div></content></entry><entry><title>“Get ready to party!”</title><summary>Perl 6 in 2015</summary><link href="/log/fosdem15lw/"/><id>urn:uuid:0946c511-88b8-430f-adbb-5f1c334f95df</id><published>2014-11-11T22:51:57+01:00</published><updated>2014-11-11T22:51:57+01:00</updated><content xml:base="/log/fosdem15lw/" type="xhtml"><div xmlns="">
  319.  <p><cite><a href="" title="FOSDEM 2015: Get ready to party!">Larry Wall</a></cite>:</p>
  320.  <blockquote cite="">
  321.    <p>The last pieces are finally falling into place. After years of design and implementation, 2015 will be the year that Perl 6 officially launches for production use.</p>
  322.    <p>In this talk, the creator of Perl reflects on the history of the effort, how the team got some things right, and how it learned from its mistakes when it got them wrong. But mostly how a bunch of stubbornly fun-loving people outlasted the naysayers to accomplish the extraordinary task of implementing a language that was so ambitious, even its designers said it was impossible. Prepare to be delightfully surprised.</p>
  323.  </blockquote>
  324. </div></content><category scheme="" term="seen" label="Seen"/></entry><entry><title>Lingua programmatica</title><summary>On English as the language of source code</summary><link href="/log/linguaprog/"/><id>urn:uuid:bfc260e8-2d74-46c9-a890-ed72bef06ebd</id><published>2014-09-17T07:44:40+02:00</published><updated>2014-09-17T07:44:40+02:00</updated><content xml:base="/log/linguaprog/" type="xhtml"><div xmlns="">
  325.  <p>I program in English and always have because builtins and the standard library of (asymptotically) every programming language are named based on English. If you try to choose identifiers by another language, your source will inevitably be a mishmash of English plus that other language. I find the resulting jumble to be alternately jarring and grating by equal measures.</p>
  326. </div></content></entry></feed>
Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda