My cur­rent devel­op­ment setup revolves mainly around Vim and GNU Screen. I use Screen only to keep ses­sions run­ning between work days or in case I get dis­con­nected, but lately I’ve been tempted to try using dif­fer­ent win­dows inside Screen. In order to make this eas­ier, I wanted one of those sta­tus lines that shows you all your win­dows as “tabs”.

Con­fig­ur­ing this sta­tus line (the “hard­ware sta­tus line” or, as I’ll call it, “hard­sta­tus”) is done with a sin­gle, often long string of char­ac­ters in ~/.screenrc that at first can look entirely baffling:

hardstatus string "%{= KW} %H [%`] %{= Kw}|%{-} %-Lw%{= bW}%n%f %t%{-}%+Lw %=%C%a %Y-%M-%d"


To my dis­may, almost every­thing I can find about hard­sta­tus through Google are just dumps of other people’s strings, with lit­tle to no expla­na­tion about why they do what they do – it’s easy to imag­ine that the peo­ple who post them hardly know why they do what they do, either. GNU’s offi­cial doc­u­men­ta­tion isn’t ter­ri­bly helpful.

After finally deci­pher­ing a lot of what goes on in these strings, I wanted to spell it out to any­body else who might be hunt­ing around for half a clue about this voodoo. There are (more than?) a few things I haven’t cov­ered here, of course – trun­ca­tion and con­di­tion­als, namely – but this should be enough to get you started.

Con­tinue reading →

Hav­ing just stum­bled across an arti­cle advo­cat­ing against AdBlock Plus (via Lea Verou), I decided to revisit my set­tings for rel­a­tively nuisance-free brows­ing in Firefox.

For a long time I’ve done devel­op­ment work and writ­ing for a site that keeps its lights on through adver­tis­ing, so I sym­pa­thize with content-creators’ need for (and frus­tra­tion with) ads. It’s a nec­es­sary evil, and I’ve always found it a bit dis­heart­en­ing to see AdBlock Plus at the top of every “Pop­u­lar Plu­g­ins” list (whether for Chrome, Fire­fox, or Safari). Worse, there seems to be a sense of enti­tle­ment among savvy inter­net users, telling them that they shouldn’t have to endure ads. Com­monly this might be veiled as being “anti-corporate” or some other such vague excuse, but the real rea­sons are usu­ally the same as those behind piracy: it’s just nice not to have to pay for things, whether through eye­balls, band­width, or dollars.

(None of this is to say that I am entirely inno­cent on these points.)

Still, there are some trou­bling com­mon prac­tices among the more insid­i­ous of these JavaScript embeds, and I think there is some jus­ti­fi­ca­tion in cir­cum­vent­ing them. But one doesn’t need to block every adver­tise­ment to severely dimin­ish adver­tis­ers’ abil­ity to, say, keep track of one’s brows­ing habits.

Here are the things you can do to make your brows­ing a lit­tle more pri­vate and safe, while still (mostly) allow­ing the sites you love to pay their bills. These tips will be writ­ten for Fire­fox users (though the equiv­a­lent plu­g­ins are read­ily avail­able in Chrome and Safari), and won’t include things that read­ers of this site will prob­a­bly already know about (e.g., avoid­ing “watch movies free” sites and their ilk, and dis­abling pop-ups).

Con­tinue reading →

I don’t claim to be any kind of Apple pun­dit, but I have some hunches about what their watch will be like if and when they release one.

The two fac­tors I see as being vital are price and simplicity.


The Galaxy Gear starts at $299, which is a lot more, I think, than the aver­age per­son (i.e., non-Android zealots) are will­ing to spend on a watch that they have to charge every night. A suc­cess­ful watch, one that gets into the hands of mil­lions of peo­ple, will have to be closer to the “Apple impulse buy” price of the iPods Nano — at most $249, but I think they could do it for $199. (The Peb­ble E Ink watch is $150.) To reach that price point, an Apple watch will lack, for instance, a cam­era and a speaker, which are included in the Galaxy Gear.

Con­tinue reading →

Despite not agree­ing with all of it, “Just Use Sub­lime Text” (an invec­tive against Vim — or, more accu­rately, against rec­om­mend­ing Vim to any­one who isn’t already indoc­tri­nated by it) by Andrew Ray is an inter­est­ing read. The sec­tion deal­ing with indent­ing in par­tic­u­lar struck a chord with me:

Paste this into an empty buffer:


:set ft=html and then gg=G. Let me know what you get. In all seri­ous­ness, never, ever tell me what you get.

As I said in a tweet, what I got didn’t offend me too much. But many peo­ple would argue that the <span> tag should be indented inside the <p> tag. I’d prob­a­bly do this myself, actu­ally — and there have been aspects of Vim’s indent­ing that irk me. So I set about find­ing a solution.

Con­tinue reading →

First of all, it’s terrific.

I was sur­prised to find that the front­light can never be turned com­pletely off while the Kin­dle is awake.

Also regard­ing the front­light, I’m pleas­antly sur­prised that, when it’s set at a mod­est level in a dimly-lit room, it has the appear­ance of not being lit at all, but merely of being more “white” than it is and as a result reflect­ing more ambi­ent light, almost mag­i­cally so. I didn’t expect to want to leave the light on all the time, but for this rea­son, I do.

When set too high, or when in a too-dark room, there is an appear­ance of uneven­ness with the light­ing, but it’s not ter­ri­bly distracting.

What is a bit dis­tract­ing is how sur­real it can look when some­thing (like your thumb or head) is cast­ing a shadow on the sur­face in cer­tain light­ing; the area around the shadow looks mostly illu­mi­nated by the ambi­ent light, and the area under the shadow has an odd blue glow to it, since the frontlight’s effect is more appar­ent there.

Hav­ing fonts other than Cae­cilia is nice, although I can’t imag­ine any­body want­ing to read for any length of time in Futura or Hel­vetica. Baskerville is of course clas­sic for type­set­ting books, but because of its del­i­cate let­ter­forms and small x-height doesn’t really suit the (rel­a­tively) low-contrast and (rel­a­tively) low-resolution Kin­dle. There doesn’t seem to be an ideal “small” font size for Baskerville, at least not for my eyes. For these rea­sons I’ve so far stuck with Palatino, a font that I don’t really like very much, but which is less “artificial”-feeling than Cae­cilia, anyway.

The new UI ele­ments (and the font in which they’re set, some Futura-like geo­met­ric I can’t iden­tify) are really attrac­tive. You can tell a lot of time was spent here and it gives the device a lot more per­son­al­ity and finish.

As expected, I’m frus­trated by the lack of a hard­ware page-turn but­ton, par­tic­u­larly while read­ing in bed, where (with the face of the Kin­dle pointed slightly down­ward) my thumb becomes a cru­cial sup­port point, and is there­fore not free to tap the screen to turn pages. In other inter­ac­tions I’m also forced to use two hands quite a bit.

It was worth the upgrade even if only for the front­light, and despite its small and few draw­backs, the over­all improve­ment (over the Kin­dle 3, I should men­tion) make it a no-brainer.

One day while watch­ing Arrested Devel­op­ment, I noticed some­thing: The theme song is strik­ingly sim­i­lar to the Pac-Man theme.

I had to slow the Pac-Man theme down a bit to match these up, but otherwise:

Arrested Devel­op­ment / Pac-Man

Update: More at CelineThe­Fe­line

I began notic­ing recently that some­times when try­ing to send a file to the trash, I was told that it couldn’t be moved there and that I’d have to delete it entirely to get rid of it. I didn’t really think any­thing of this at first, until I began to sus­pect that it was only hap­pen­ing with files in my /home directory.

My /home direc­tory is on its own par­ti­tion on a stan­dard hard disk. The rest of the file sys­tem is on another par­ti­tion on an SSD. In order to fully reap the speed ben­e­fits of an SSD, I sym­bol­i­cally linked as many non-personal direc­to­ries as I could from /home to /var/jay on the SSD. These included ~/.local, ~/.cache, ~/.gconf, ~/.mozilla, etc.

I didn’t really know much about the way Linux/GNOME han­dles Trash. Files deleted from a third inter­nal hard disk or from USB sticks would be moved to /.Trash-1000 on that device, while appear­ing in “Trash” in Nau­tilus. Files from a user’s home direc­tory, how­ever, don’t go to /home/.Trash-1000, or even /.Trash-1000 — instead, they go to ~/.local/share/Trash. Because in my setup this direc­tory was on the SSD rather than the hard disk with the /home par­ti­tion, GNOME refused to move it there, since that would require copy­ing from one disk to another, which GNOME’s devel­op­ers (smartly, I think) believe would be alarm­ingly time-consuming for some­one who’s just try­ing to delete some files — they shouldn’t expect to see a copy dia­log grind­ing away.

In order to try to fix this, I made ~/.local/share/Trash into a sym­bolic link itself, back to the /home par­ti­tion at ~/Trash. After this change, things were get­ting trashed prop­erly — at least, I wasn’t asked to delete them entirely — but they weren’t show­ing up in Nautilus’s Trash view. I don’t know how Nau­tilus makes itself aware of all the trash fold­ers spread across dif­fer­ent devices, but for what­ever rea­son it wasn’t pick­ing up on this one, even after sev­eral reboot cycles.

Finally I gave up and moved ~/.local back onto the same par­ti­tion as /home, and now everything’s back to nor­mal. But I’d still like to know if it’s pos­si­ble to keep ~/.local on a sep­a­rate disk while retain­ing GNOME’s and Nautilus’s ordi­nary trash behavior.

Bug report­ing sucks, it’s clear. How can it be better?

One idea that could alle­vi­ate a lot of the headaches of bug report­ing while pro­vid­ing increased func­tion­al­ity is a desk­top bug-reporting appli­ca­tion. I won’t pre­tend to be famil­iar with any APIs that are made avail­able by Launch­pad, GNOME, Bugzilla, Trac, etc., but I have to imag­ine that some exist. I also won’t pre­tend that I’m the first to have this idea — it’s entirely pos­si­ble that it’s been attempted and that those attempts have failed many times. But from where I’m sit­ting it seems like a near-perfect solu­tion. Here are the ben­e­fits we’d get from a desk­top bug-reporting application:

  1. It can man­age your bug tracker logins.
    Imag­ine hav­ing all your bug tracker logins stored in a lit­tle data­base for you on your desk­top. More than that, imag­ine being able to reg­is­ter at a new bug tracker with just a few clicks using the per­sonal infor­ma­tion kept by the application.
  2. It can iden­tify the bug tracker used by a given appli­ca­tion.
    This may actu­ally be a bit dif­fi­cult. It’s pos­si­ble that this could be done by hav­ing appli­ca­tions make this info avail­able in some way, although that puts a bur­den on appli­ca­tion devel­op­ers, and I assume there is no sys­tem cur­rently in place for some­thing like this. It’d require some creativity.
  3. It can iden­tify the pack­age in the appro­pri­ate bug tracker against which to file a bug.
    Launch­pad is prob­a­bly the bug tracker with which I’m most famil­iar, and there in par­tic­u­lar it seems to me to be plau­si­ble for a bug-reporting appli­ca­tion to eas­ily find the pack­age against which a bug should be filed. How many peo­ple even know that Ubuntu’s default PDF viewer is called “Evince,” or that its default image viewer is called “Eye of GNOME,” or espe­cially that the Eye of GNOME pack­age is called “eog”? Imag­ine instead being able to choose from a list of run­ning appli­ca­tions and hav­ing the bug-reporting appli­ca­tion do the rest.
  4. It can pro­vide bet­ter search for dupli­cates.
    Launch­pad only presents you with pos­si­ble dupli­cates after you’ve entered the title of your bug report. A desk­top appli­ca­tion, on the other hand, could con­tinue to search for dupli­cates as you’re elab­o­rat­ing on the bug in your descrip­tion, updat­ing on-the-fly and pre­sent­ing you with rel­e­vant excerpts from the poten­tial dupli­cates’ descrip­tions. And if it has a high enough con­fi­dence in a match, it can ask “Are you sure?” before allow­ing you to submit.
  5. It can col­lect and upload sys­tem logs.
    Not only could a desk­top appli­ca­tion attach basic sys­tem logs and hard­ware info, but it could cat­a­log which version(s) of your application’s depencenc(y/ies) you have installed, poten­tially sav­ing hours of work per bug.
  6. It can open an impromptu chat with oth­ers suf­fer­ing from the bug, or with pack­age main­tain­ers.
    By check­ing the online avail­abil­ity of other bug suf­fer­ers or pack­age main­tain­ers, this appli­ca­tion could inte­grate with Empa­thy, Pid­gin, or IRC to put you in con­tact with them, if they choose to make them­selves available.
  7. It can search exist­ing help avenues for poten­tial solu­tions to your prob­lem.
    Stack Exchange (Ask Ubuntu, Super User), Quora, Ubuntu Forums — search­ing all of these places takes time, and might not even occur to a large num­ber of users. Search­ing these places on-the-fly as bugs are being described might pre­vent unnec­es­sary bugs from being filed in the first place, or direct bug suf­fer­ers toward tem­po­rary workarounds.
  8. It can look for PPAs that con­tain updated pack­ages that might fix the bug you’re report­ing.
    Many times the appli­ca­tions in offi­cial repos­i­to­ries are out­dated, and many times the most com­mon bugs have been fixed in more recent releases. Given ade­quate safe­guards, this could be invalu­able for peo­ple des­per­ate for a solution.
  9. It could inte­grate with the mes­sag­ing menu.
    “Some­one just marked one of your book­marked bugs as ‘Affects me too.’ They are avail­able for chat. Would you like to con­tact them?“
    “The bug ‘[bug descrip­tion here]’ has a new comment.“

I’m sure with my lim­ited imag­i­na­tion I’ve not even scratched the sur­face of what a desk­top bug-reporting appli­ca­tion is capa­ble of. What else would you like to see in one? What would some of the pit­falls be? Is this prac­ti­cal or imprac­ti­cal, and why?