Here's a very distinctive-looking moth I photographed near Sat Tal lake in Uttarakhand in September 2009.
I don't know what species it is.
Update (2010-05-10): My friend Swati tells me it's a Cyana sp. (which means I still don't know what species it is :-).
Update (2017-06-02): Seven years later, Sanjay Sondhi of The Titli Trust identified my moth at a glance as Cyana belissima. Thank you, Sanjay!
Please don't bother to update copyright notices in your code to add each new year as time passes. It serves no useful purpose.
Here's how I set up a post-receive hook to maintain multiple mirrors of the main Archiveopteryx git repository.
We've always taken a very conservative approach to portability with Archiveopteryx. We run it ourselves under Linux and FreeBSD on x86 and x86_64 systems, and those are the only platforms we've ever claimed to support. Between the developers and our major users, we have access to enough systems of that description that we can be reasonably confident that the software will work without unpleasant surprises.
Beyond that, we've never been very ambitious. Once in a while, someone
would ask Does it work on NetBSD?
or Solaris or OS X. The
answer was usually yes, perhaps after a few (relatively minor) tweaks.
We would add #ifdefs and other portability patches to our
code only after someone suffered from an actual problem, never before.
If we couldn't (or didn't, regularly) test it, it wasn't supported.
This gloomy approach is in sharp contrast to the confidence encouraged by autoconf. Had we used it, we could have saved a few users the trouble of dealing with compile errors. We would have been testing our software only on the few systems we did anyway (which happen to be the commonest platforms in use), but autoconf would have helped us to feel more portable. I don't want to think about what that would have done to the number of unreproducable bugs we had to analyse; they were enough trouble as it was.
I was recently reminded of our curmudgeonly attitude in a conversation with Hassath, who did a project on FLOSS video editing software. One of her complaints was that it was hard to find out not just what the hardware and software dependencies of some program were, but also what configurations were known to work. The documentation usually implied that any Linux system would work fine, but in practice, people running a different distribution routinely encountered problems that the developers had never seen and had no idea how to address. This was the case even on her quite unremarkable Ubuntu and amd64 test system, and she found it extremely frustrating.
Try as I might, I can't see optimism as a good approach to portability.
I've noticed that a lot of people in the open source world have a negative opinion of Perforce, whether they've used it or not. Here is one recent example:
There's also Perforce, which I don't know much about, but I gather it's a crappy proprietary centralised VCS which is worse than Subversion in pretty much every way.
This kind of offhand dismissal by people who are not familiar with Perforce is very common. When we were switching from Perforce to git for the Perl 5 source code, a lot of people assumed we wanted to do it because Perforce wasn't good enough (but it was really because the open source licensing procedure was non-trivial, and the lack of anonymous repository access was seen as inhibiting contributors; there were also objections to depending on a free-but-not-Free program).
There are other people who have used Perforce and not liked something about it. Their opinions range from reasoned critiques to poisonous rants:
[Dear Perforce… ] Fuck you, you miserable, untrustworthy, misleading, overpriced bastard. I hope your office goes up in flames along with all your off-site backups. I pray that some open source product that actually works is embraced by all the major companies and drives you out of business. I hope that no other company is duped by your salespeople into thinking you have something even remotely close in quality to the ancient and craptastic product known as CVS. Never before have I experienced so much pain in the most simplistic of version control tasks as I have since starting to work at a company that made the mistake of considering you.
I used Perforce exclusively for many years, both for large projects with many other users and small personal projects, and my experience with it was very different. I loved Perforce. I found it refreshingly simple to learn, it worked fast and unsurprisingly and well, and it had excellent support and documentation (of the kind that few open source programs of any kind have, even now). I encountered only two or three minor bugs in it after several years of use, and I never once had to fix the repository (a welcome change from CVS).
There are, of course, many valid criticisms of Perforce, and my intention is not to defend it against those. I've suffered from some of its problems myself: its (mostly justifiable) dependence on the network was at odds with my very slow dialup link, p4p (the proxy) didn't work very well for me, some administrators I know had problems configuring their server the way they wanted, and so on. I switched to git myself a few years ago, and later helped other projects (Perl, Archiveopteryx) I cared about to move away from Perforce too. I haven't regretted the change.
But Perforce certainly did not suck, and there are some things I still miss about it. As non-distributed VCSes go, I think Perforce is vastly better than the (many) other programs I've used.
I've always enjoyed writing, but it's only in the past year or so that I've forced myself to write regularly. The practice is paying off, the principal difference being that I consistently write much faster than I could before. I've also been able to identify and correct a number of problems with my writing that may have otherwise gone unnoticed.
Thanks to some bad habits I've developed, however, there's still plenty of room for improvement. For example, I tend to rewrite things to make the right margin of the paragraph line up "nicely", which is an absurd waste of time. Sometimes, I get stuck at a particular sentence or paragraph and tweak it endlessly rather than moving onwards.
Years ago, I read about a program whose minimal interface was modelled on a typewriter. It presented a blank screen, with nothing to distract from the process of writing; and it had minimal editing capabilities, to avoid the temptation of rearranging text. I can't remember what that program was called, but there is more than one like it (e.g., Writeroom and OmniWriter for OS X, and a few clones). Most of them have more features than I can remember reading about.
I spent an hour or so writing a similar Qt program. It was surprisingly
easy (thanks to some advice from my Qt hacker friends Arnt and Brad): I
created a QWidget, called showFullScreen() on
it, gave it a QPlainTextEdit child displayed in the centre
of the screen, and wrote a few lines of code to load and save files. The
QPlainTextEdit class provides minimal editing capabilities,
which suits me fine. I named the program wry, and I've been using it for
some months now. (The source is at
github.com/amenonsen/wry
for the incurably curious.)
Digression: I'm very pleased that Unicode text "just works" in wry. I
can display Markus Kuhn's
UTF-8 demo
with none of the ugly problems I've had with xterm in the past. For
Unicode text input, I
set up ~/.Xcompose
so that I can compose any character I want, but I miss vim's
:digraphs command, which would show me the available
options.
Using wry was slightly frustrating at first, but once I got used to it, it worked very well. The enforced lack of distractions helped me to put down more text more quickly; and it was easier and faster to edit things later when I was looking at several paragraphs rather than one sentence. Since wry uses a proportional font and rewraps text as it likes, I could no longer waste time trying to align the right margin.
Someday, perhaps I'll be cured enough that I can write properly in vim without succumbing to the temptation of editing, but until then, wry is the perfect set of training wheels.
The first hiking boots I bought served me well for ten years.
I've noticed a strange quirk of Delhi English—people say "until" when they really mean "while", and are oblivious to the inverted meaning of the resulting sentence.
The TVS Gold is an all-plastic, entry-level keyboard with mechanical keys. It's definitely nicer to use than cheap membrane keyboards.
The Chief Justice of India asked Medha Patkar “not to have a cynical approach towards large irrigation projects” 🙄