This is primarily a bug-fix release, cleaning up some issues introduced in 2.3.0. Specifically, it fixes collection of the contents of *.a files, fixes the severity of spelling errors in man pages, properly parses Depends starting with a newline for weak-library-dev-dependency, and fixes the spurious display of archive areas in some cases in the HTML reports. This release also includes Raphael Geissert's work to eliminate unpack level two (which means having a full unpacked copy of the package) in favor of a collection script that does this and a new type of collection that's automatically removed after processing. This is the first step towards eliminating the internal Lintian distinction between unpack and collection scripts and implementing both using the same mechanisms. As usual, there are a variety of other fixes and improvements, but there shouldn't be any major user-visible changes in this release. Note that, following advice from Joey Hess, Lintian now warns about missing $ misc:Depends dependencies for any package that uses debhelper, since any debhelper script may start adding dependencies there. This was already mostly in place in 2.3.0, but is the source of a large number of new warnings in the archive.

Most readers probably have installed Debian version 5.0 (Lenny) or an older version and are using shadow passwords with the md5 hash algorithm. This is not bad but not good enough. You can find out the details by looking at /etc/passwd and /etc/shadow (as root). The second column in these files should be a simple character x in /etc/passwd and a string like

$1$biMft/Pr$Lo3zPpiItdLZrzx8t/mTy0

in /etc/shadow. The number 1 between the 1st and 2nd $ sign means md5, the following string biMft/Pr is the salt and the last string Lo3zPpiItdLZrzx8t/mTy0 is the actual hash for the password ('testmd5' in this case). The salt is used to avoid attacks based on precomputed hash tables.

The package pam has switched to the stronger sha512 algorithm in version 1.1.0-2 on 31st august 2009. Look for a line like

password        [success=1 default=ignore]      pam_unix.so obscure sha512

in file /etc/pam.d/common-password if you have installed at least version 1.1.0-2. After changing the password I have the new password string

$6$qjc5gFgK$vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjN/lenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

in /etc/shadow. The number 6 means sha512 and the hash

vaz/gLKMyDuhsVOU2oVIkDZrD0.reJM.2Ft3CMEoAsjNlenvHC2ls6g/MY1ZaYaYBP3HHDOxel1dvTerl17q1

is much longer than before.

The pam_unix module in combination with the sha algorithms allows specifying the number of rounds for hashing the password with the argument rounds=... which defaults to 5000. My current machine needs about 20 milliseconds to hash my password. That can be tested with the command

/usr/bin/time -f %U su testmd5 -c true

I have changed the number to 1 million

password        [success=1 default=ignore]      pam_unix.so obscure sha512 rounds=1000000

to make brute force attacks more difficult. After changing the password again the string is

$6$rounds=1000000$Va4plzLi$EtixueZQ1ZQlzQa7eHHsG6UcNvu.EnuCqM79kIyUe82eAZ.JNegn4SBY1RduYlACs0RWLFHD4d//PzQXMsCqk0

with the number of rounds embedded. The su command needs 1.79 seconds now which is an acceptable delay for the login process considering the improved security.

Don't forget to change the root password too if you have set one.

My first RC Bug-squashing Day (or rather night):

• bug #552791 acorn-fdisk Copyright file does not contain verbatim copy of the license or a pointer to one
• bug #562647 gidentd Does not work with ipv4 after recent change in netbase
• bug #558812 dietlibc incorrect license in debian/copyright
• bug #531937 autossh FTBFS on mipsel due to missing -fPIC

I picked all of them mostly randomly from the list Zack gave me, and except dietlibc they are packages I had not even heard of before. The first one begun easily (track down licencing information, pimp debian/copyright, but I ended up fixing compiler and lintian warnings and even wrote a manpage for it while there (but for this one, I didn t bump the Standards-Version). The second one was only the second one to complete because the others took longer; it s basically a change of a d mon to use two instead of one listening socket, to work with a doble stack OS instead of just a dual stack OS by not using v4-mapped IPv6 addresses (I considered if to use select(2) or poll(2), or to just fork and have two d mons running, but that seemed too ressource-consuming to me so I chose the less-complicated poll(2) method, looking at popa3d(8) s source code (inherited from OpenBSD) in the MirBSD tree since I could not find my network programming book. The third one was basically communicating with upstream; the bug can be blosed with no change to the package. The fourth one took me a while; luckily I have qemu 0.11.0 on MirBSD, and aurel32 s mipsel qemu images helped a great deal; however, cowbuilder --create failed for me, so I ended up waiting almost the entire night for a-g d-u to finish; in the end, it was simply a bug in upstream s configure.ac which is only exposed due to a toolchain bug on mips(el). To do: my AM Zack needs to upload the NMUs (after checking, of course); I need to communicate some of the fixes upstream (the gidentd upstream is NXDOMAIN ), produce a very small testcase for the mipsel toolchain bug, maybe fix some more mipsel FTBFSen as I have a working qemu instance now, but maybe I ll do that at the BSP when I can t find IPv6 bugs or so that I feel I can fix (I also want to do an mksh release which has to be prepared first RSN, and there s still the need to formally publish the MirBSD-current bi-arch snapshot and make another ISO out of it for BT and prepare the multi-BSD USB stick for allbsd.de ). Annoyances: a-g d-u could ask me things at the start before working for some four+ hours instead of in the middle, and the same questions several times (PAM restart). The sid kernel doesn t boot today but did yesterday, the lenny kernel produces this:
Starting the hotplug events dispatcher: udevdudevd[320]: udev: missing sysfs features; please update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED option; udev may fail to work correctly
(I hate udev.) And, worst of all, these annoying fireworks (some sounded like originating from inside our staircase, I pity the neighbour s cats) when one wants to hack Finally, I *loathe* CDBS. Debhelper v5 rules! Oh, and I also was under the impression that Firstname LASTNAME was a French thing, and to a much lesser extent Asian. (@bubulle)

This has been a big decade for me. Ten years ago, I was living in Sunnyvale, in the heart of Silicon Valley; VA had just had its crazy IPO; my unvested options were worth over a million dollars on paper. I remember sitting in first class[1] on the way out of Atlanta after the holidays and wondering what one did with a million dollars. Avoid working too much? Have a lot of interesting computers? Build a distributed house[2]? Mostly I decided to not count my chickens, which turned out to be the right choice. Six months later, I started debian-installer, in many ways my biggest project to date. In spring of '01, VA was crashing; I was sick of the Valley; gloom was everywhere. I took the hint and quit, cashed in my options for five figures, not seven, bade forewell to the many people I'd come to know, and moved back east. By reading my old journal, I can tell that subconciously, I had long before decided what to do when it was time to leave the Bay Area. So without really thinking too much about why I was able to do this, about how not just my own family, but others were indirectly making it possible, I moved to a 150 acre wooded "farm", and mostly went off and did mostly my own thing for three years. This was such a huge life change. I lived in a building affectionatly called "the shack". It was renovated from a chicken coop in the 70's and leaked during heavy rain, but I preferred it to the main house (warmer). I went back to dialup for internet. I hauled groceries and most everything half a mile in by hand. There was an outhouse and washwater hauled from a creek. I cut barely enough firewood and readapted my body from California to cold. My main tech project during this time was mooix. In some ways my largest failed project, but it was neat to be able to go off and do such a thing. This was a blissful, reflective, peaceful, amazing time. Parts were a second childhood. Somewhere in there I properly confronted my mortality. And learned to use a chainsaw. And over the course of three years, I dug myself into a rut, a hole. I wasn't going anywhere. (Except for a month in Honduras, and my first DebConf in Oslo.) In '04, I found myself talking on the phone to a cosmonaut in a house that had been without power for days in a hard winter. I realized I was ready to leave the farm if I could figure out how to do it, and I almost took him up on the job working on his new Linux distro -- but at the last minute Oslo connections suggested I work for SkoleLinux instead, and so I did. Soon after moving into a rented house in town, I was jaunting off to Brazil for a month, a great time. Followed by a productive year where I got heavily back into debian-installer, started Debian's testing security tream, and generally worked a lot. The next summer I fooled around with an RV, and sort of fell into a job with ADS. But my time on the farm had changed me, I think. I ended up going back to the farm for a year and working part time from there. During this time I also started ikiwiki and other smaller projects. One day I came back from a camping trip and found the kitchen had been torn down in my absence. Reminded unsubtly that I was not the only one with a claim to the place, I got out, though I somehow suspect not for good. For the last four years, I've been more outwardly settled, buying a house in town, continuing to work at the same job, starting little projects like pristine-tar, mr, and etckeeper. About two years in I began to feel antsy sometimes (and had a minor medical scare), and set up the yurt as a relief valve so I can have crazy adventures in the cold woods again. Still, I sometimes feel that a big change is building up. From here, this decade feels like it contained endless changes, important decisions, interesting projects, strong experiences. The 90's, containing only little things like college and moving to California, pale in comparison. Maybe the naught's will be the decade I always remember.. or maybe not. Anything could be around the corner.

---

1. Bumped up due to an airline scheduling snafu, not because I was throwing money around.
2. Concept of mine perhaps not worth explaining here although it was oddly similar to how I ended up living at the farm. Good ol' subconcious..

I can hear the question now: What kind of guy puts The Iliad and War and Peace on a list of things to read for fun? Well, me. I think that reading things by authors I ve never read before, people that take positions I haven t heard of before or don t agree with, or works that are challenging, will teach me something. And learning is fun. My entire list for 2010 is at Goodreads. I ve highlighted a few below. I don t expect to read all 34 books on the Goodreads list necessarily, but there is the chance. The Iliad by Homer, 750BC, trans. by Alexander Pope, 704 pages. A recent NPR story kindled my interest in this work. I m looking forward to it. The Oxford History of the Classical World by Boardman, Griffin, and Murray, 1986, 882 pages. It covers ancient Greece and Rome up through the fall of the Roman empire. The Fires of Heaven (Wheel of Time #5) by Robert Jordan, 1994, 912 pages. I ve read books 1 through 4 already, and would like to continue on the series. War and Peace by Lev Leo Nikolayevich Tolstoy, 1869, 1392 pages. Been on my list for way too long. Time to get to it. Haven t read anything by Tolstoy before. The Politics of Jesus by John Howard Yoder, 1972, 2nd ed., 270 pages. Aims to dispel the notion of Jesus as apolitical. An Intimate History of Humanity by Theodore Zeldin, 1996, 496 pages. Picked this up at Powell s in Portland on a whim, and it s about time I get to it. The Myth of a Christian Nation: How the Quest for Political Power Is Destroying the Church by Gregory A. Boyd, 2007, 224 pages. An argument that the American evangelical church allowed itself to be co-opted by the political right (and some on the left) and argues this is harmful to the church. Also challenges the notion that America ever was a Christian nation. Daily Life in Ancient Rome: The People and the City at the Height of the Empire, by Jerome Carcopino, 2003, 368 pages. I ve always been fascinated with how things were on the ground rather than at the perspective of generals and kings, and this promises to be interesting. Slavery, Sabbath, War, and Women: Case Issues in Biblical Interpretation (Conrad Grebel Lectures) by Willard M. Swartley, 1983, 368 pages. Looking at how people have argued from different Biblical perspectives about various issues over the years. To the Lighthouse by Virginia Woolf, 1927, 252 pages. I can t believe I ve never read Woolf before. Yet another one I m really looking forward to. Tales of the Jazz Age by F. Scott Fitzgerald, 1922, 319 pages. Per Goodreads: This book of five confessional essays from the 1930s follows Fitzgerald and his wife Zelda from the height of their celebrity as the darlings of the 1920s to years of rapid decline leading to the self-proclaimed Crack Up in 1936. Ulysses by James Joyce, 1922 (1961 unabridged version), 783 pages. The Future of Faith by Harvey Cox, 2009, 256 pages. Per Goodreads, Cox explains why Christian beliefs and dogma are giving way to new grassroots movements rooted in social justice and spiritual experience. Heard about this one in an interview with Diane Rehm. Being There by Jerzy Kosi ski, 1970, 128 pages. Jesus: Uncovering the Life, Teachings, and Relevance of a Religious Revolutionary by Marcus Borg, 2006, 352 pages. Whether or not you agree with Borg, this has got to be a thought-provoking title. The Three Musketeers by Alexandre Dumas, 1844, 640 pages. The Book of Tea by Kakuzo Okakura, 1906, 154 pages. Per Goodreads: In 1906 in turn-of-the century Boston, a small, esoteric book about tea was written with the intention of being read aloud in the famous salon of Isabella Gardner. It was authored by Okakura Kakuzo, a Japanese philosopher, art expert, and curator. Little known at the time, Kakuzo would emerge as one of the great thinkers of the early 20th century, a genius who was insightful, witty and greatly responsible for bridging Western and Eastern cultures. Nearly a century later, Kakuzo s The Book of Tea is still beloved the world over. Interwoven with a rich history of tea and its place in Japanese society is poignant commentary on Eastern culture and our ongoing fascination with it, as well as illuminating essays on art, spirituality, poetry, and more. More of my list is at Goodreads.

Wouter (and Faidon on IRC too) suggest I'm influenced by my (supposedly bad) French habits for writing names and suggest that capitalizing names is a French habit (which is of course bad, just like all French ways to do things...:-)). Well, sorry to disagree, but there's nearly nothing true in this, IMNSHO. I have never noticed that family name capitalization is more widespread in my own country (which I pretend to know in details, when it comes at its culture) than it is elsewhere. This is more personal habits than anything else. The only thing I can see where one is instructed to use capitals are manually-filled forms, where capitals are often the best way to avoid misreadings. I though my main point was clear: I don't like name capitalization. I just see it as a practical way to silently tell people "*this* is my family name and *that* is my first name". Actually, this is exactly what several Asian contributors are doing on a daily basis and, from what I've been told, for that exact purpose. So, my "proposal" is just returning them the favor and give them a chance to call me "Dear Christian" and call you "Dear Wouter". Let's say this is a way to show them some consideration. This is somewhat ugly but unless someone has a better proposal, I'll stick with it. And, on that matter, well, I think that Wolf's proposal to do the opposite would probably lead to weird results. Though let's admit that Gunnar has a point: there's often more than just "first" and "family" names in many places (including mine as my full name is "Christian Jean Antoine Perrier") and that make things pretty more complicated. Maybe we should all call ourselves "dude" or "pal", after all..:-)...but that again is "western" style habits. In some places, that would obviously be considered very rude...even in our friendly free software community. I just had the case 10 minutes ago, by the way. Had to answer by mail to the Khmer translator of D-I whose name is "Khoem Sokhem". And it just took me quite a while to dig into my archives and find out that I should use "Dear Sokhem" (plus another 10 minutes to confirm that he is a "he".... as I previously worked for months with the former translator before learning that "he" was indeed a "she"...quite a shame for someone who pretends to have some awareness about gender considerations in free software, sin't it?). Anyway, thanks for this "conversation" and Happy New Year to all my friends around. At least for those who celebrate a new year in the upcoming hours..:-)

On the train to my parents' house for Christmas I finished up a wild run through the book Coders at Work. The book isn't even mine, but I'd been borrowing it very often, sometimes to the chagrin of its owner, because I could barely put it down. The book is a collection of interviews with 15 great programmers of our time, starting with Jamie Zawinsky and ending with Donald Knuth. It's written in an interview style each interview starts with a brief introduction to the person being interviewed, summarizing what the person is known for and what he or she has accomplished and a few of the highlights of the interview, and then a transcript of the interview follows, with the author/editor, Peter Siebel, will saying something or asking a question, and the interviewee responding. I was skeptical about this format at first because I feel like it can be an easy way out of good editing and make the reader have to do the work of the editor, but on finishing I think that Siebel uses the format to his advantage in this case. For one, the speech format allows the reader to really form a picture of how the person being interviewed speaks and would act in a conversation. Jamie is somewhat bitter and pretty informal. Brad Fitzpatrick is flippant and energetic, his speech littered with profanity and colloquialisms. Others seem more stately and verbose Joe Armstrong's responses can go on for a page or more. In this way, not only do readers learn something about what these greats have learned about programming, but we also feel a bit more like we've met or know them, and can connect to them more as people. I always have this problem where I want to read computer books, but often computer books seem inextricably tied to the computer, so there's this dynamic of reading a bit and then wanting to get on a machine and try something out, write some code, play around especially with books focused on a specific language. Coders at Work retains some of this computer-book dynamic in that I constantly encountered things that I want to investigate or play around with more: Erlang, OCaml, various papers and essays, Knuth's literate programs, and books such as Higher Order Perl and others. Siebel makes a point to ask each person what her short-list of books and papers programmers should read are, so this book is a great source of pointers to other reading material. Unlike a more specific book, however, keeping a list in a notebook was enough to settle the mind to read away-from-a-computer for chapters at a time. It's obvious that despite the interview format, Siebel has done some serious editing. None of the prose is boring to read, and I can't imagine that the text is a straight transcript of how the interviews went. He also has arranged the interviews in an order such that different interviews play off each other. In Branden Eich's interview, for example, he disparages the book Design Patterns:

I never bought the Gamma book. Some people at Netscape did, some of Jamie Zawinski's and my nemeses from another acquisition, they waved it around like the Bible and they were kind of insufferable because they weren't the best programmers.

In the next chapter, Joshua Bloch names it as a book he thinks programmers should read:

Another one, which I have slightly mixed feelings about but I still think everyone should read, is Design Patterns. It gives us a common vocabulary. There are a lot of good ideas in there.

Similar plays, such as Ken Thompson and Fran Allen disagreeing on the badness of C, happen in later chapters, tieing together the different chapters and illustrating how even really good programmers disagree on the Right Thing all the time. Clearly the craft of programming is no settled thing. Besides the general structure of the book being well thought-out, the material is generally thought-provoking and interesting. One thing that stood out to me was Joshua Bloch describing what he called the "empathy gene", which is what a programmer has to have if he's going to be able to design good APIs and programming languages he has to be able to put himself in the shoes of the person who will be using the language or API. This is one thing that differentiates how different programmers can be good at different things. Another thing that stood out to me is that many of those interviewed stated that they don't use much in the way of modern tools and IDEs Joshua Bloch and Simon Peyton-Jones both touch on this, just to name a couple examples, even though some say that they think using these tools would make them more productive, especially when it comes to refactoring. This is a testament to the power of inertia sometimes there is just no chance to be unproductive now in order to be more productive later. Or perhaps just a sign that a programmable text-editor can stand on the same level as a heavier tool in terms of productivity in the right hands. I could go on with examples, but the conclusion here is that I thoroughly enjoyed Coders at Work, and I think it is a book that is well-worth the time spent reading the entire thing.

It seems strange to me. I don't think I know people as aware of internationalization issues as Bubulle, a.k.a. Christian PERRIER, and I have the feeling his last post regarding how he shall address himself is somewhat short-sighted. That might just mean I am in an even worse position. First, I recognize Christian's concern, but not only when dealing with people from around the globe It happens in my everyday life. When you show an ID stating Gunnar Eyal Wolf Iszaevich, the first reaction is a blank stare of disbelief, only to be followed by a question: So, what is your name? So I understand Christian wants to make it easier for people to guess what his name is in the least obtrusive way possible. I have seen the convention he suggests (uppercasing the family name) AFAICT used by French and Japanese people. But for me, it is intuitively backwards. If I were to emphasize a part of my name, it would be the part by which I expect people to address me with I would write GUNNAR Wolf. And yes, I usually leave out my second given name and my mother's family name, as it is customary here. Well, anyway... Reading my name, few people would guess I live in Mexico. Even fewer will believe I was born here. And if somebody calls me by the wrong part of my name, I won't feel at all offended. I strongly prefer my name to be used, as I like to be addressed casually, but quite often I am introduced as Dr. Wolf, in what at most would be an ex-profeso honoris causas doctorate, or at least an ignoratis causas one.

Ouch! This is the second time I am running into this so I ll write it up this time. I used libtool via automake for building a python module. Quite unhelpfully, libtool happens to build only the static library. It does that even though I passed the -module option, which should make it clear that a static library does not help at all. There is also no mention why it skips the shared library. After some research, my memory came back: libtool requires to pass the -rpath option to actually build shared libraries. I did not want to pass that options, since it is considered harmful where multiple variants of a library are available. It is even less useful in my specific case, as the module is only used inside the source tree for unit testing. Solution: I changed the Makefile.am to use Interestingly, the same scheme (apart from the wording) is used in libtool s own source.

I recently tried to improve my way to interact with people by mail, in my free software work. Particularly, my intent is to be "better" in using other people names and specific politeness rules. As many of my readers may guess, being involved in internationalization means interacting with people of different cultures. And, when it comes at names, this is just a nightmare..:-) Most so-called "westerners" (western of what, by the way?) are used to the common tradition we share to use people's "first" name....at first...followed by what is most often the "family" name (the one we usually get from our parents). As a consequence, it is fairly easy for me to guess that, interacting with someone named "Barack Obama", I can use "Dear Barack" if I'm in position to use his first name and "Mr Obama" if I need to show some respect distance whatever. Also, as most "western" names are quite familiar in my ears (international culture, blah blah), I can easily guess what is a first name and what is a family name (though, here, "Barack" is probably not the best example). Gender may become a little bit trickier in several cases, but, thankfully, in English, "Dear" does not change with gender (but the third person does whic sometimes leads to problems). The problem arises when interacting with many other culturally different people such as my friends in Japan, China, India, Africa, etc. Here, dammit, the habits might vary a lot and things get harder. Should I call my friend "Kenshi Muto" as "Dear Kenshi", "Kenshi-san", "Muto-san" or whatever? From my readings, I see that most Japanese people do put their family name at first. So, I should then call him "Dear Muto" if I'm very close to him (oh, maybe it's 'her', by the way, who knows?)...or maybe "Kenshi-sensei" because he (oh...or she) is a respected figure in the Japanese FLOSS community...or whatever. Damn! Thankfully, I know Kenshi for years, we're good friends and I know that he's using the "western" way to write his name. I also know he's a man : after 5 or 6 Debconfs, you know everything about people! But, of course, it becomes harder when it comes at people I never had contacts before.....and I don't want to appear as impolite, or silly so, then we jump into my daily "nightmare". Using Wikipedia for hints about Chinese, Indian (the many ones) or even Icelandic or Indigenous peoples of the Americas helps a lot, still. I can only encourage my various friends in free software to do the same. We probably all deeply appreciate when someone shows some knowledge of our culture or at least tries to do his her best to understand our culture. That is probably also part of the mutual enrichment we get in our free software activities. As a tribute for this, I now write my own name as "Christian PERRIER" in my email headers, so that people have a slightly better clue that "Perrier" is my family name and that someone who wants to be familiar with me should call me "Dear Christian". I can probably ncourage my friends all around the world to do the same. For once, using capitals is not about 'shouting' but more about helping other people to figure things out. Next blog writing about the interesting challenge we all face in free software meetings and conferences: shake hands, kiss, hug or just wave? :-)

Absolutely, but there are at least two workarounds:

1. Adding

   BINDMOUNTS="/var/cache/apt/archives"
   APTCACHE=""

   to your .pbuilderrc, in case you don t need any special separation of local and pbuilder caches (that s my case).
2. Using apt-proxy or the like, which has its overhead, but also its other advantages.

None of them seem all that bad to me, considering the sensible speed improvements to pbuilder, but the ultimate decision probably depends on the amount of disk-access the packages in question need.

Sometimes, the main task at any one time is simply going to take time and cannot be shortened. With my poor network connection, this tends to occur any time I need to do network tasks like multistrap and debootstrap tests, archive updates and the rest. The problem is that my network connection is so bad, most apt type tasks completely saturate all available bandwidth, especially when downloading a single large package like those built from gcc or OOo.

Thankfully, gpdftext has provided an intermittent task that is useful, intermittent, non-network dependent and relatively straightforward (so as not to be too distracting from the main task) without being sufficiently routine to make me think about automating it.
I've downloaded some 70 public domain novels as A4 PDF and I'm gradually working through them in gpdftext to tidy up the chapter headings and reformat as an A5 PDF, ready to be transferred back to my ebook reader.

This version of gpdftext isn't released yet (it's current SVN, 0.1.0) as it's in string freeze. However, it provides a fairly robust test of the next release.

Current list includes: Little Women, Fairy Tales of Hans Christian Andersen, Lady Susan, Northanger Abbey, Pride and Prejudice, Sense and Sensibility, Peter Pan (Peter and Wendy), Lorna Doone: A Romance Of Exmoor, The Gap in the Curtain, The Thirty-Nine Steps, Through the Looking Glass (And What Alice Found There), Fanny Hill: Memoirs of a Woman of Pleasure, Moll Flanders, Robinson Crusoe, The Further Adventures of Robinson Crusoe, A Tale of Two Cities, David Copperfield, Great Expectations, Little Dorrit, Oliver Twist, The Life And Adventures Of Nicholas Nickleby, The Adventures of Sherlock Holmes, The Casebook of Sherlock Holmes, The Hound of the Baskervilles, The Memoirs of Sherlock Holmes, The Return of Sherlock Holmes, Cranford, The Wind in the Willows, King Solomon's Mines, Tess of the d'Urbervilles, The Hunchback of Notre Dame, Declaration of Independence, Just so Stories, Kim, The Jungle Book, The Man Who Would be King, The Arabian Nights, Lady Chatterley's Lover, Sons and Lovers, Women in Love, The Story of Doctor Dolittle, The Call of the Wild, The Game, White Fang, Moby Dick, Anne of Green Gables, The Well at the World's End, Pygmalion, An Inquiry into the Nature and Causes of the Wealth of Nations, East is West, Strange Case of Dr Jekyll and Mr Hyde, The Jewel of Seven Stars, Anna Karenina, The Adventures of Huckleberry Finn, The Adventures of Tom Sawyer, The Kama Sutra, 20,000 Leagues Under the Sea, The Aeneid of Virgil.

That should be enough for now.... (21 converted so far).

Everyone seems to be familiar with ebooks these days. I own a Kindle 2, and of course we ve spent weeks hearing how great the Nook will be, then weeks hearing how terrible it turned out to be. But nobody seems to be casting an eye back towards paper, so I thought I d rectify that here, especially since paper books have some serious stability issues that are often overlooked! Before I begin, I feel it wise to offer this hint to the reader: this review should not be taken too literally. If you have an uncontrollable urge to heave a volume of the Oxford English Dictionary at me as if I am some European prime minister, please plant your tongue more firmly in your cheek and begin again. Today I picked up a paper book to read just for fun The Happiest Days of Our Lives by Wil Wheaton. Long-time (since this spring!) Kindle user that I am, I immediately noticed the dashing use of color on its front cover, but when I opened it, I was disappointed that I couldn t scale the font size down from the default. It seems that paper books have only one font option what are all these Kindle forum posters complaining about with its six sizes of a single font? On the very first page, I encountered a word I wasn t familiar with (Namaste). I thought I knew what it meant from the context clues, and even had the thought that on the Kindle, I could just highlight it and confirm my guess. But my paper dictionary was in the basement, so I didn t bother looking it up until I wrote this post. (My hunch was reasonably correct.) Interface-wise, the paper book is solid, and crashes, lockups, or other malfunctions are rare. I have, however, noted severe stability problems when attempting to read outdoors, especially when it s windy (which, since I live in Kansas, is pretty much always). Pages start turning themselves, even without me making the turn page gesture. Sometimes the book will even lose its memory of my last page read. This is rather annoying, and might even involve a lengthy search for a suitable temporary replacement bookmark. Also, I haven t tried it, but I suspect that the trick of putting a Kindle in a ziplock bag to read at the beach or in the tub without risk of getting it wet would be impractical with a paper book. Paper does have its advantages. For one, it s faster to flip rapidly through pages on paper than on an ebook reader. If you know roughly where in the book something was written, but not the precise wording, searching can be faster on paper. On the other had, if you are looking for a particular word or phrase, the ebook reader may win hands-down, especially if the paper book has no index. Paper is so stable that some would argue that the extreme impracticality of making good backups isn t really a problem at all. But on the other hand, paper books degrade slightly each time they are used, and this condition can be aggravated by placement in bags for transport. Eventually, they will wear out. If my Kindle wears out, I can always restore David Copperfield from my backup copy to a new one. If my printed edition (all two volumes) of it wear out, then I have to hope that the used bookstore will still sell me another one for $10. Otherwise I d have to either drive 45 miles to find one for sale, attempt to deal with the DRM for paper books at a library, or wait a couple of days for Amazon to get it to my door. A fire or flood could be devastating. Paper books also have some advantages for showing photos; no ebook reader is close to the size and resolution of glossy paper photos books in a reasonable price. The contrast on most paper books is better than that of my Kindle, but some older ones are actually worse, smell dusty, and suffer from occasional display corruption as bits of them actually break off of the book device. As to cost, it is a mixed bag. Out of copyright classics are free as ebooks from Project Gutenberg and the like, while still costing money on paper. I have found that the accuracy of some of these paper editions can be rather questionable people have sometimes manually removed important bits of the story to save on printing costs, rather than let Google Books OCR mangle it for them automatically. On the other hand, used paper editions of more current works can be found for a fraction of the cost of the new ebook edition though you are often limited in selection of these bargains. But you can usually browse a paper book for a few minutes before buying it, which is rarely available for an ebook. What s more, libraries might let you borrow paper books for free. But you often have to expel greenhouse gases to get to them, and then they enforce DRM on you you only get to read it a certain amount of time before they start adding fees. You could easily wind up paying $2 if you keep it a week longer than you should have. With ebooks, of course, there is no free borrowing (and the Nook feature it too limited to count.) And you of course know that most libraries are run by the government, so they have your address. Trying to circumvent a library s DRM could wind up involving the police, so you had best comply. Making copies of a paper book is expensive and requires specialized equipment, even if you just want a copy for backup. Compatibility problems with paper books are rare, and are usually found among readers with poor eyesight. A few works can be found in large font editions, but most can t, so those readers are left needing expensive specialty magnifiers. All in all, I prefer reading books on my Kindle, but still read on paper when that s how I have a book.

According to the man page, there are three ways to exclude files from being tracked by git.

Shared list of files to ignore The most well-known way of preventing files from being part of a git branch is to add such files in .gitignore. (This is analogous to CVS' .cvsignore files.)

Here's an example:

*.generated.html
/config.php

The above ignore list will prevent automatically generated HTML files from being committed by mistake to the repository. Because this is useful to all developers on the project, .gitignore is a good place for this.

The next line prevents the local configuration file from being tracked by git, something else that all developers will want to have.

One thing to note here is the use of a leading slash character with config.php. This is to specifically match the config file in the same directory as the .gitignore file (in this case, the root directory of the repository) but no other. Without this slash, the following files would also be ignored by git:

/app/config.php
/plugins/address/config.php
/module/config.php

Local list (specific to one project)For those custom files that you don't want version controlled but that others probably don't have or don't want to automatically ignore, git provides a second facility: .git/info/exclude

It works the same way as .gitignore but be aware that this list is only stored locally and only applies to the repository in which it lives.

(I can't think of a good example for when you'd want to use this one because I don't really use it. Feel free to leave a comment if you do use it though, I'm curious to know what others do with it.)

Local list (common to all projects)Should you wish to automatically ignore file patterns in all of your projects, you will need to use the third gitignore method: core.excludesfile

Put this line in your ~/.gitconfig:

[core]
excludesfile = /home/username/.gitexcludes

(you need to put the absolute path to your home directory, ~/ will not work here unless you use git 1.6.6 or later)

and then put the patterns to ignore in ~/.gitexcludes. For example, this will ignore the automatic backups made by emacs when you save a file:

*~

This is the ideal place to put anything that is generated by your development tools and that doesn't need to appear in your project repositories.

With the Lintian 2.3.0 saturday-after-christmas release (by the way, over here if it s done twice it ll really become tradition) I ve run its spelling tests over all of MirOS CVS repository. The result: 293 kinds of typos in 35857 souce files. (Although there are the case things too. Without them, I have 51 typos in 7206 files. Asides from false positives (I used fgrep -rwl[i], and -i and -w don t play well together, and -w mis-catches GTK+ as GTK ) I probably can t (API, source code) or won t fix all of them though.) However, I have some rather hot asia-style food to eat right now, and will need to get up early tomorrow for work, so I am not applying/fixing them right now. (bsiegert@ and gecko2@ however are enjoying themselves at 26C3, see their wlog entries.) Note that all of today s fixes will not make it into the next MirBSD snapshot already, since it s built (i386) and building X11 already (sparc). On the other hand, the next bunch of WTF *.deb files will have them. I also need to fix makefs upstream for Hurd and continue the T&S questionnaire *sigh* Update: I suppose this is my Hello, Pl net Debian! posting (thanks aptituz!) well, my packages in the archive were already lintian clean, in case someone wonders (I did recheck with 2.3.0 though). My point was, why not use checking tools from one universe for another one, viceque versa? (Similar to synergy effects from knowledge.)

I recently bought myself a Canon EOS 500D also known as EOS Rebel T1i, and EOS Kiss Digital X3. I also got myself a Canon EF 50mm f/1.4 USM lens. One of the new things about the 500D, compared to my previous 400D, is that it has live view. So I wanted to see if that's useful or not. I'm not that happy with it. If you want to let it auto focus normally you would half press the release button but instead you need to press the AE lock (*) button, half pressing the release button doesn't have any effect. The live view auto focus is also very slow, takes about 5 seconds on average. It's also has a habit of not focusing it all, or going in the wrong direction to find the focus. I sometimes suddenly feel the focus ring vibrate on the 50 f/1.4 USM while it normally never moves. There is also some weird clicking noise on my zoom lens, it appears to keep trying to send it beyond the smallest focus range while the object is meters away. There is also a "quick" focus mode, so that if you press the AE lock button the mirror goes down, temporary turning live view off, doing the focus the normal way, and then the mirror goes up again. In that mode the auto focus takes about 2 seconds instead. The only thing live view seems useful for is that you can zoom in to see if something is in focus. I'm also seeing some weird behavior when using the flash. When using the 50mm f/1.4 it really seems to prefer using f/2.8, sometimes f/1.4 or f/4.0, and you can't select anything else in the auto, CA or P mode. Sometimes the depth of field is just too small, so I tried to set it to Av mode and manually select the one I want. What I didn't expect in that case is that it's calculating the shutter time like it won't be using the flash, and you suddenly get shutter times of 5 seconds. Other modes have similar problems, only setting everything manual seems to work properly.

RCBW - week #16 ... and here are christmas (for those who care) RC squashes, by yours truly (for those who care too):

• bug #530527 - ipsec-tools - gcc 4.4 strict-aliasing, patch by peter green
• bug #539010 - opensrs-client - stop using deprecated Perl module MD5, patch by Ansgar Burchardt
• bug #539542 - libnsgif - gcc 4.4 strict-aliasing, patch by peter green
• bug #531715 - gcin - gcc 4.4 missing include, patch by Martin Michlmayr (+ lintian overrides for appropriate use of rpath)
• bug #504873 - im-sdk - gcc 4.4 missing include, patch by Martin Michlmayr (bonus: package orphaning, misc QA, kfreebsd patches applied)
• bug #540681 - beast - cast to volatile pointer, patch by Jakub Wilk
• bug #560499 - beast - gcc 4.4 missing includes

and here are the usual notes:

• most of them come from Luk, which this week provided me with a looong list (and of course I was not able to empty it) ...
• ... that list has probably entered the radar of others: let's thank Christoph Egger, gregor hermann, and David Paleino, which contributed quite a lot of RC-fixing NMUs in the past few days (probably others did too, but these 3 got into my way the most )
• I got annoyed by bug #562518 (zlibg b0rkage) for a while: while my main system got saved by apt-listbugs, my cowbuilder environment was not that lucky
• I've tried following a wise advice to speed up pkg building, but it does not work w/ cowbuilder, which insists in creating hard links and hence fail due to cross-device linking. I need to investigate whether this can be fixed without loosing APT cache sharing with the host system
• "thanks" to im-sdk, I discovered yet another patch management system: dbs: how many others are still out there?
• how dumb is a BTS instance which is not accessible by default w/o registration even for read-only purposes?

Hint/request of the week: please add +pending when you do DELAYED/ NMUs, that way filtering out already taken care of bugs gets easier and refreshing a bug log page in the browser will immediately show the new tag at the top.
(Yes, I agree that nmudiff should offer that when passed --delay, I intend to propose a patch for that, but feel free to beat me at it :-P) In other news, christmas vacations are awesome to catch up with books you planned to finish reading months ago ... Update: the patch for nmudiff I've mentioned has been kindly provided by gregor hermann, thanks!

My parents needed a new printer, and after some research I decided to recommend them an HP OfficeJet Pro 8000. Today I gave it a try, by printing some CD covers for a CD to give away for christmas to some friends.HP failed in a very subtle way: I had printed the covers, cut them, produced the CDs for them. Then I wanted to put the printed covers into the CD cases.Despite the graphics being 12cm x 12cm in size, HP managed to print them in 12cm x 11.4cm. Without any notice (or giving me a choice) it had decided to scale them on the y axis. Which makes them completely unusable, since they don't fit the 12cm height of the CD case now.After some more experiments, I decided to retry without duplex, and voila: 12cm x 12cm.Duplex on HP OfficeJet Pro 8000 is only usable for draft printing, since it will distort your pages!(See also this devidence in the HP forums, of people with the same issue, an attempt to investigate the margin messup happening, a report that the DJ990c driver can print duplex on this printer without messing with the margins, but is slower and offers less print quality. So it seems that this is an HP driver problem. And technically, it must be caused by the driver; at least it should be able to compensate for this!)I also noticed another issue with the print. The bottom right corner of the graphic didn't get enough ink, it looks like the printer stopped printing a bit too early. I don't know if this also happens in non-duplex, since I worked around this by adding a header and footer to the page.Seriously, we should send back the printer. On my first try to use it, I already encountered two bugs. I wonder how many bugs I would see if I'd use it every day?

Somehow, I'm still lacking the optimal media player application. Many popular ones are totally overloaded (e.g. amarok). Others like totem seems to be just a minimalistic frontend for a particular backend.My current choice:

• Single-shot playback: to view a random song or video I usually open them with Totem (the GNOME default) and that works okay
• Library: I use MPD as player because it just seems to be rock stable. As UI I currently use Sonata, but I don't use it for much more than choosing a song from the currentl playlist.
• Editing: ExFalso seems to have the best ID3v4 support, in particular it also allows multiple genre fields. (Note that Vorbis even suggests you should use multiple artist fields instead of the common "Arist A & Artist B" way of filling the fields)

However, there is one thing I'm really not satisfied with: when putting together a CD compilation for friends (say, as Christmas present), they are quite useless. A key issue here is the total playlist length. Guess what, I want to make sure it fits on a single CD. So I really need to know the total playlist length. Why do so many media players (e.g. totem, alsa-player-gtk, xfmedia4, vlc, mplayer, ...) not show you the total playlist length? They did read all the files to get artist and title. Many even have the individual song lengths, just not the total sum.In the past I've been using old XMMS1 to check for the total length, or a CD burning application like K3B by repeatedly importing my current folder.Right now, I'm using Quod Libet (since I like the tag-editing component exfalso a lot) to arrange the playlist. It also gives me the total length, albeit I belive I've had incorrect song lengths in it before (broken VBR files?), and it's not perfect, too: being database-driven it has really long startup times for occasional users (because of updating the database) and is much more heavyweight. I also believe I've lost some playlists because I had moved my files around once ... so I'm a bit sceptical.Anyway, there are still hundreds of media players I havn't looked at. Don't bother me to send me an email about one I havn't mentioned!But if you are developing a media player, please consider the use case of putting together a music CD for your friends. In particular, for users that do not use your player all day.

Being stuck at home because of my stepfather's health condition becoming worse and therefore family meeting plans being changed, I just made the Debian project a small Christmas gift by fixing an RC bug on December 25th for the first time in my Debian life. Apparently, after TeXLive packages changes, this one will not be the only one discovered by Lucas automated archive rebuilds. Anyway, Merry Christmas to those of you who celebrate it.