<<  Page 3 of 8  >>


It almost seems to be a rule: any time anyone talks about “cyber-“anything, it’s bullshit. I have little idea why. Maybe the word “cyber” appeals to people who read too much bad 1970s science fiction? But whatever the reason, from the heady dotcom bubble era talk of “cyberspace”, to today’s paranoid talk of “cybersecurity”, it’s bunk when looked at in detail. There are serious things to discuss, but somehow serious people use different words: “computer security”, for instance, or “network security”. The “cyber-“people are not all wrong — being 100% wrong is almost as hard as being 100% right — but there’s enough wrong to make them not worth taking seriously.

Of course this feature of the language is just a transitory thing; charlatans, once unmasked, shift to a different cover. After they abandon “cyber” it may even become respectable, eventually. In any case, no offense is intended to people who use the word in the context of debunking the prevailing “cyber”-nonsense, such as Bruce Schneier or Ralph Langner.

An RSS reader

A couple of years ago, I went looking for an RSS reader. For those not familiar with the concept, an RSS reader is a piece of software that maintains a list of blogs, pulls their RSS feeds, and displays a list of articles in them. And, if the blog maintainer puts the full text of his articles in the feed, it lets you read them. A decent RSS reader also remembers which articles you’ve read, and either marks them accordingly or only shows you the new ones. For subscribing to blogs that are only occasionally updated (like this one), an RSS reader is almost a necessity: it does the boring work of repeatedly checking for new articles when there seldom are any.

My criteria were:

  1. Good integration with the web browser. I don’t want to flip back and forth between two different programs, one to read the RSS feed, and another to read the things on the web that it points to. I also want hyperlinks in the RSS feed to have the usual color indicators of whether or not that I’ve already read them, which probably won’t work if the RSS reader is a separate program, unless someone makes extraordinary effort at browser integration. Thus the RSS readers I’d tried previously were Firefox extensions. But I didn’t particularly like any of them, because I wanted:

  2. Something better than the usual three-panel view (one panel for a list of blogs, another for a list of articles in a blog, and a third for the article itself). For one thing, that layout requires a lot of clicking: you typically have to click on each blog, then on each article. I can go through blogs faster than that just using the normal browser features: middle-click on each blog in a list to open it in a new tab, then hit Control-W to close each tab when I’m done with it. Also, the three-panel layout wastes a lot of screen real estate: I’m going to spend 99% of my time reading the articles, yet those appear in only one of the three panels. That’s annoying even on a desktop-sized screen, let alone tablets or phones.

  3. No web-based services. I prefer to be in control.

What I fairly quickly landed on was mtve‘s program RSSaggressor. This is a Perl script that takes a list of blogs (a plaintext file, one URL per line, containing the URL of an RSS or Atom feed), checks each, and spits out a long HTML file containing everything new in every blog. The user then views that HTML file in a web browser. This way, instead of all the mouse clicking one does with a three-panel reader, reading the updates is just a matter of scrolling. (Well, except if the blog chooses not to put the full text in the RSS feed; then it’s back to the ‘middle-click to open each article in a new tab’ procedure.) This way there are no browser integration issues, aside from running the program in the first place and then opening its output HTML file in the browser. The original author runs the program as a cron job; I run it whenever I feel like checking what people have to say.

I’ve also made several changes, the notable ones of which are:

1. It displays the author of each article, which is useful for multiple-author blogs.

2. It allows you to specify a condition which has to be met for each article to be added to the output HTML file. To use this, after each URL in the list you add a condition, which is distinguished from the URLs by being indented. For instance, to subscribe to the Volokh Conspiracy weblog, but only to posts by Orin Kerr or Eugene Volokh, not the twenty or so other “co-conspirators”, you can write:

        $author eq "Eugene Volokh" or
        $author eq "Orin Kerr"

The syntax for the condition is Perl syntax; the code uses Perl’s eval() function to evaluate it. The accessible variables are $author, $title, $link (a hyperlink to the web version of the post), and $text (its full text, if you’re lucky). And since the condition can be arbitrary Perl code, you can also do other things with it, including changing any or all of those variables. For instance, Twitter hashad an RSS API, until they decided that offering RSS wasn’t predatory enough, but in it they didn’t publish hyperlinks as hyperlinks, just as plain text. To enable such hyperlinks (or at least nine tenths of them), you can write, for instance (fill in the blank with the screen name of the person to follow):

        $text =~ s((https?://[a-zA-Z0-9_/.+]*[a-zA-Z0-9]))
           (<a href="$1">$1</a>)g ; 1

(If those last two lines look like gobbledygook, welcome to the world of regular expressions.)

This version of RSSaggressor, like the original, can be found on Github. If all my modifications seem to date from the last few days, that’s because I was using an older version of the program previously, and ported my changes to this newer version.

One odd thing about RSSaggressor is that it remembers whether you’ve read articles by storing their MD5 checksum. Thus if the author goes back and edits the article, you get to see it again in its entirety. This has good aspects (you get to see updates to articles you’ve already read) and bad ones (you get to see the whole article again just because the author corrected a typo). I’d prefer to see some sort of diff between the old and new articles, but haven’t found a good diff library that operates on HTML and plays well with Perl. (Suggestions are welcome; patches or pull requests are even more welcome.)

This program hasn’t been packaged up for the casual user who doesn’t know to pull programs from github or install Perl modules (or, on some systems, install Perl itself). Those are not complicated things to do, but instructions would vary depending on the system. (As regards Perl modules, this version of the program might not need any extra ones: the ones it uses are pretty basic, and might already be there.)

Linux web fonts

A couple of quick tips for improving the way the web looks under Linux:

1. Set your web browser’s default fixed-width font (“monospace font”) to Inconsolata. It is clean and highly readable. It first might be necessary to install the font, in which case hopefully your distribution has a package for it, as mine did. (Hat tip to commenters at Greg Kroah-Hartman’s Google+ page for this recommendation.)

2. For the “Georgia” font (one of Microsoft’s “core fonts for the web”, originally released as freeware, and used by a high proportion of websites), turn down the level of “hinting” with which the font is rendered. Most fonts seem best with “full” hinting, but this one I like better with “slight” hinting. This can be accomplished by inserting the following lines into one of your fontconfig files:

<!-- Slight hinting only, for "georgia" font -->
  <match target="font">
    <test name="family"><string>georgia</string></test>
    <edit mode="assign" name="hintstyle"> <const>hintslight</const></edit>
    <edit mode="assign" name="rgba">      <const>none</const> </edit>

(The second ‘assign’ line turns off subpixel rendering, which in this case seems to give the font too much color fringing.) This drastically alters the appearance of the font; before the change it looks like this:

and afterwards it looks like this:

It was the appearance of the uppercase D in the former that got me looking into this. This is of course a matter of personal preference, and others will no doubt prefer the first version in general, but that D is just wrong: it shouldn’t be blurred vertically like that. And to me, the whole change seems like an upgrade. (I still might prefer the first version if I were using a display where the pixels were larger.)

For completeness, here’s the entirety of my local fontconfig file:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
  <match target="font">
    <edit mode="assign" name="rgba" >     <const>rgb</const> </edit>
    <edit mode="assign" name="hinting" >  <bool>true</bool>  </edit>
    <edit mode="assign" name="antialias"> <bool>true</bool> </edit>
    <edit mode="assign" name="autohint" > <bool>false</bool> </edit>
    <edit mode="assign" name="hintstyle"> <const>hintfull</const> </edit>

<!-- Disable Autohinting for bold fonts -->
  <match target="font">
    <test name="weight" compare="more"><const>medium</const></test>
    <edit mode="assign" name="autohint">  <bool>false</bool></edit>

<!-- Slight hinting only, for "georgia" font -->
  <match target="font">
    <test name="family"><string>georgia</string></test>
    <edit mode="assign" name="hintstyle"> <const>hintslight</const></edit>
    <edit mode="assign" name="rgba">      <const>none</const> </edit>

I’m not an expert as to where, in general, this file should be placed, but “.fonts.conf” in your home directory is a good place to try. See the above-linked Wikipedia page for more possible locations.

<<  Page 3 of 8  >>