22 Mar 2011
(updated 27 Jun 2011 at 22:09 UTC) »
This entry was posted using Chromium as packaged for Debian. Thus far, Chromium has been much, much nicer than Chrome, mainly because Chrome ignores my fontconfig settings (which specify Linux Libertine serif fonts everywhere), while Chromium obeys them. I even have hope that I can make the ^A and ^E text edit keys work right. After that, maybe getting it to render standard ligatures (such as "ffi", "Qu", and "Th", and on my system, "st" and "ct") might even be possible. Firefox does it.
As far as I have been able to determine, Intel Arrandale support (needed for the Dell Latitude e6510 with 1920x1080 display) in the drm-intel-next branch off 2.6.38-rc7 is now fully functional, including suspend/resume, gnome-display-properties, XVideo, GL, and DPMS blanking. Apparently it's all expected to end up in 2.6.39, none too soon. Maybe Sandy Bridge support will be a little more timely. I'm guessing that the reason it's so hard is that the win32 driver writers were able to pester the hardware people when the docs were ambiguous, but by the time the Linux drivers are to be written, they've all moved on to other projects, and anyway can't remember what-all bugs their design shipped with.
I was almost won over by Apenwarr's encomium for Etherpad, and I asked about getting it installed at work to use instead of Google Docs, which is getting increasingly hard to tolerate. Unfortunately, it appears to be implemented in Java and Scala, which (for very good and sound reasons!) they would prefer not to put on their nice clean, well-functioning servers. So, now I'm looking for an Etherpad workalike written in something reasonable, e.g. C++. Then LWN spills the beans on something called "Fossil", an integrated bug-tracker, wiki, and distributed version control system, and I start to think I need that too. But maybe what I really need is a fork of Fossil with an Etherpaddy wiki, a Traccy bug tracker, and a Git back end. In the meantime, I struggle with Review Board's intolerance of Git diffs. Apparently you have to pipe
Git's diff output through
-e "s/^--- a\/\(.*\)/--- \1 (revision $*)/" \
-e "s/^+++ b\/\(.*\)/+++ \1 (working copy)/" \
-e "s/^diff --git [^[:space:]]* .\//Index: /" \
with $1 the old svn revision number.
Speaking of Avery, I'm mystified why he thinks rigorously defensible parsing of arithmetic expressions is somehow difficult or messy. Just about every yacc or recursive-descent example I've ever seen included a clean and complete arithmetic parser, with nice term-and-factor precedence handling. What am I missing? Am I improperly presuming sanity?