Review: American Gods, by Neil Gaiman

Publisher:	HarperTorch
Copyright:	July 2001
Printing:	May 2002
ISBN:	0-380-78903-5
Format:	Mass market
Pages:	588

At the start of American Gods, Shadow is in prison. He's done three years of a sentence of six and is about to get released on parole. He has a wife and a job waiting for him and every hope of getting back to a good life. None of that happens. The day he's released, he finds out his wife died in a car accident. The job is gone too; it was an offer from his best friend, who died in the same accident. Numb, an ex-con, with no job prospects, he's recruited by a strange man named Wednesday, with the help of a leprechaun named Mad Sweeney, to drive Wednesday around the country, run errands for him, hurt people if absolutely necessary, and hold his vigil if he dies. And that's how Shadow is drawn into the conflict between old gods and young, between the gods that immigrants brought to America from the old world and the flashy new gods of technology and media that America is creating for itself. With native American gods and cultural legends watching around the edges. I first read American Gods shortly after it came out and before I started writing reviews, so this is a re-read. It's a book I'm glad I re-read before reviewing. The first time I read it, I was thoroughly engrossed and thought it was excellent. This time, I was entertained, but surprised at how slowly it moved, how disconnected it sometimes felt, and how little substance there was to the plot. Reading American Gods involves spending lots of time with Shadow, and I think one's reactions to this book will vary a lot based on how much one likes him as a character. Shadow is very withdrawn, very detached from the world, and quietly matter-of-fact in how he goes through his life. He's been through some major shocks and has been severed fairly thoroughly from society by three years in prison, and he doesn't reconnect easily. To some readers, such as myself, this comes across as taciturn competence and quiet observation, two things that I greatly enjoy reading about. I liked Shadow, liked reading between the lines for hints at his feelings, and sympathized a lot with his emotional state. But I can easily see an alternative reading that makes him a cipher or, worse, a blank spot in the book into which the reader has to insert themselves. One has to work at seeing Shadow's character and finding some sympathy for the degree to which he stays separate from the world. American Gods does have a plot, but it's the sort of plot that allows for endless digressions, background stories, and side meetings. In that, it reminded me less of Gaiman's other novels and more of several arcs of Sandman. I think it's worthwhile to think of this less as a novel and more as an extended ramble through the world as Gaiman sees it, full of mythology, stories, quirky people understanding the world in their own ways, and upwellings of the sacred and significant in the most unexpected of places. For example, the holy places of America in American Gods, analogous to the multiple small sacred places and old ruins in Europe, are roadside attractions, via a line of argument that makes much more sense than it has any right to and demonstrates a canny understanding of the expression of American entrepreneurial culture. As with much Gaiman, reading with Wikipedia or another mythological resource at hand is a good idea. Even if you have a good general knowledge of the most common mythology studied in the US, you probably won't recognize many of the figures Gaiman draws on: Czernobog, for example, or Wisakedjak. Part of the fun of this book is seeing Gaiman humanize them and embed them in modern culture and modern concerns while retaining their mythological edge and strangeness. As any reader of Sandman can tell you, this is one of Gaiman's strengths as a writer, and he does it well here. The bits with the undertakers Mr. Ibis and Mr. Jacquel (Thoth and Anubis) are absolutely brilliant and probably the best sections of the book (although Sam's exchange with the Men in Black is a strong contender).

"Back in my day, we had it all set up. You lined up when you died, and you'd answer for your evil deeds and for your good deeds, and if your evil deeds outweighed a feather, we'd feed your soul and your heart to Ammet, the Eater of Souls." "He must have eaten a lot of people." "Not as many as you'd think. It was a really heavy feather. We had it made special. You had to be pretty damn evil to tip the scales on that baby."

Like so much of Gaiman's work, this is the sort of book that contributed a half-dozen quotes to my quote file during my first reading. Gaiman always impresses me by not only managing to portray gods as human without losing the numinous edge, but sustaining that portrayal through very extended contact with the same god. And despite the interlude with the undertakers, the long interlude in small-town life in Lakeside, and the numerous other digressions and meanderings of a book that's not in much of a hurry to get anywhere, there is a plot and a definite conclusion, and Gaiman has some interesting twists in store at the end of that road. There's a lot of philosophical currents going on under the surface, not all of which cohere, but Gaiman does pull a lot of them together. The resolution can be a bit of an anticlimax, but I think it's a fitting one that's true to the nature of the story. I didn't enjoy this as much on the second reading as I did on the first. It didn't feel quite as coherent as I'd remembered it, and the meandering pace occasionally made the story feel stretched. But I do like Shadow, I love spending time in Gaiman's head and with his portrayals of deities, and American Gods is a treasure of great quotes. If you enjoy Gaiman's other work and aren't looking for a lot of plot and forward-moving energy, this is definitely recommended. Rating: 7 out of 10

Review: Emissaries from the Dead, by Adam-Troy Castro

Series:	Andrea Cort #1
Publisher:	Eos
Copyright:	March 2008
ISBN:	0-06-144372-7
Format:	Mass market
Pages:	387

As a small child, Andrea Cort was a colonist on Bocai, part of a utopian project to create a mixed human and Bocaian community. Until, that is, all the members of the community woke up one day and started horrifically murdering each other for reasons that none of the survivors could ever explain. Now, she's protected from extradition by a life contract with the Diplomatic Corps and serves them as a special investigator. The scene of the investigation of this book is the strange habitat One One One. The habitat was created by the AIsource, an alliance of artificial intelligences now independent of their original creators. It's in deep space, far from any sun, and would have remained entirely unknown to the other inhabitants of the galaxy if the AIsource hadn't announced its presence. The choice to announce it was baffling, since it contains a sentient species entirely under the control of the AIsource, something that's against the shared rules of all the other species, but which they wouldn't have known about if the AIsource hadn't drawn their attention to it. After extensive negotiations, one unofficial human research group has been allowed access, and now two of the members of that group have been murdered. That's where Andrea comes in. This is Castro's first original solo novel, but he has a background in short fiction in the SF, fantasy, and horror genres and some previous collaborations and shared universe writing. The horror shows through a bit more than I'd personally prefer: the preface briefly describing Andrea's past would have been sufficient, but Castro goes back and shows it in horrific and gruesome detail as a flashback. His fight scenes are also strangely and disturbingly detailed. If you have a sensitive stomach, be aware that you may want to skim some parts of this. The overall construction of this novel, though, is not horror. It's an SF murder mystery, about halfway between a procedural and a noir detective story. Andrea does follow a coherent procedure and uses an investigative technique more sophisticated than stirring the pot and seeing what jumps out, making it not quite noir, but it has the noir tendency towards story progress via attacks on the detective and quite a lot of ongoing tension. It also involves quite a lot of setup; be aware going in that we get over a hundred pages of description of the various research group members, the details of the crimes, possible motives, and the details of the artificial habitat without a lot of forward progress on understanding the crime. Castro puts a lot of work into the design of the habitat despite leaving it mostly in the background. It could easily serve as the backdrop of a more typical Big Dumb Object SF novel. The habitable zone where the research team is and where all of Andrea's investigations take place is the effective "top" of the habitat, covered in dense foilage to which the native sentient species clings and crawls its entire life. Below is an effectively infinite fall into crushing acidic atmosphere. Castro managed to not set off my dislike of heights too badly, in part because he focuses more on Andrea's own dislike of heights rather than vividly describing the drop, but it's a constant presence throughout the novel and adds a persistant background tension. It also leads to some minor but neat clashes of perspective in conversations with the native species. For most of the book, I would have described Emissaries from the Dead as an enjoyable but not horribly original detective novel with a neat science fiction background. But there are several interesting ending twists that I won't spoil and some decisions that quite surprised me. They don't have a large effect on the plot of this book, but they make for a fascinating hook and setup for later books in the series (and I see there is a sequel). It's definitely not the sort of thing that you want spoiled before reading this book, so avoid reading blurbs and details about the sequel before reading this one. I wouldn't go out of my way to hunt down this book, but it's solid, enjoyable detective SF with a surprisingly good ending. I can see why it won the Philip K. Dick award (for best SF paperback original). Mildly recommended. Followed by The Third Claw of God. Rating: 7 out of 10

The Free and Open successor to the Clonk computer game series OpenClonk is now available in Debian sid and Ubuntu raring: just use sudo apt-get install openclonk to install it (backports to Ubuntu precise and quantal can be found in the OpenClonk Releases PPA).


It's still under development, but as you can see it's also already quite functional. The engine was made available freely under the ISC license after the original author of Clonk was no longer interested in creating new successors. Many of the old volunteer contributors then picked it up. Be aware that same computer multiplayer, which was available in the older parts of the series, is gone. If you play on the network, you need to ensure that both of you have the same version of the game.

Yesterday I was discussing in an online board how to break a decision deadlock in life. There are real deadlocks, but I don t think they are very frequent most of the time, doing a pros and cons analysis is enough to decide what to do. Sometimes our judgement is impaired by lack of objectivity or by our inability to see things from a different point of view (it s hard to think straight when everything seems to be falling apart around you); talking to a friend or relative can help in these situations. But there are times when nothing helps. When you are really stuck and nothing seems to break the deadlock. At these times I give it one or two days, sleep on the issue and if I cannot come up with a decision I assume the alternatives are equivalent to me and just flip a coin. Of course, this will do if you can postpone the decision, giving yourself (and your inner self) time to decide on a course-of-action. But is there some way to speed up the process? During the discussion, someone came up with a rather smart quote by Rothstein character in Boardwalk Empire TV series:

Flip a coin. When it s in the air, you ll know what side you re hoping for.

I found it an interesting way to give your inner self an ultimatum: decide or luck will decide instead. I ve never did it like that, for I would not flip a coin unless it s my last resort. Being such a clever psychological idea, I doubted it originated in the TV series itself, so I went on pursue of the original idea. I found a Danish poet and mathematician called Piet Hein, who wrote a poem about it circa 1969:

A PSYCHOLOGICAL TIP Whenever you re called on to make up your mind,
and you re hampered by not having any,
the best way to solve the dilemma, you ll find,
is simply by spinning a penny.
No not so that chance shall decide the affair
while you re passively standing there moping;
but the moment the penny is up in the air,
you suddenly know what you re hoping.

And also, there are a Donald Duck comic called Flip Decision circa 1953 that introduces Flipism philosophy, which supports a rather radical anecdotal variant: make all decisions by flipping a coin. Piet Hein or Rothstein character idea is much better than Flipism, of course. Does anyone knows any older sources of the same idea?

Today, I officially got approved by the Debian Account Managers as a Debian Developer (still waiting on keyring-maint and DSA). Over the years, I have seen many people complain about the New Member Process. The most common complaint was with regards to the (usually) long amount of time the process can take to complete. I am writing this blog post to provide one more perspective on this process. Hopefully, it will prove useful to people considering starting the New Member Process. The most difficult part about the New Member Process for me had to do with getting my GPG key signed by Debian Developers. I have not been able to attend any large conferences, which are great places to get your key signed. I also have not been able to meet up with the few Debian Developers living in/around Chicago. As a result, I was forced to patiently wait to start the NM process. This waiting period lasted a couple of years. It wasn't until this October, at the [Association for Computing Machinery at Urbana-Champaign's Reflections Projections Conference], that this changed. Stefano Zacchiroli was present to give a talk about Debian. Asheesh Laroia was also present to lead an OpenHatch Workshop about contributing to open source projects. Both of these Developers were more than willing to sign my key when I asked. If you look at my key, you will see that these signatures were made on October 7 and October 9, 2012. With the signatures out of the way, the next step in the process was to actually apply. Since I did not already have an account in the system, I had to send an email to the Front Desk and have them enter my information into the system. Details on this step, along with a sample email are available here. Once I was in the system, the next step was to get some Debian Developers to serve as my advocates. Advocates should be Debian Developers you have worked closely with, and usually include your sponsor(s). If these people believe you are ready to become a Debian Developer, they write a message describing the work you have been doing with them and why they feel you are ready. Paul Tagliamonte had helped review and sponsor a number of my uploads. I had been working with him for a number of years, and he really helped encourage and help me to reach this milestone. He served as my first advocate. Gregor Herrmann is responsible for getting me started in contributing to Debian. When I first tried to get involved, I had a hard time finding sponsors for my uploads and bugs to work on. Eventually, I discovered the Debian Perl Group. This team collectively maintains most of the Perl modules that are included in the Debian repositories. Gregor and the other Debian Developers on the team were really good about reviewing and sponsoring uploads in a very timely manner. This allowed me to learn quickly and make a number of contributions to Debian. He served as my second advocate. With my advocations taken care of, the next step in the process was for the Front Desk to assign me an Application Manager and for the Application Manager to accept the appointment. Thijs Kinkhorst was appointed as my Application Manager. He also agreed to take on this task. For those of you who might not know, the Application Manager is in charge of asking the applicant questions, collecting information, and ultimately making a recommendation to the Debian Account Managers about whether or not they should accept the applicant as a Developer. They can go about this in a variety of ways, but most choose to utilize a set of template questions that are adjusted slightly on a per-applicant basis. Remember that period of waiting to get my GPG key signed? I had used that time to go through and prepare answers to most of the template questions. This served two purposes. First, it allowed me to prove to myself that I had the knowledge to become a Debian Developer. Second, it helped to greatly speed up the New Member process once I actually applied. There were some questions that were added/removed/modified, but by answering the template questions befrehoand, I had become quite familiar with documents such as the Debian Policy and the Debian Developer's Rerference. These documents are the basis for almost all questions that are asked. After several rounds of questions, testing my knowledge of Debian's philosophy and procedures as well as my technical knowledge and skills, some of my uploads were reviewed. This is a pretty standard step. Be prepared to explain any changes you made (or chose not to make) in your uploads. If you have any outstanding bugs or issues with your packages, you might also be asked to resolve them. Eventually, once your Application Manager has collected enough information to ensure you are capable of becoming a Debian Developer, they will send their recommendation and a brief biography about you to the debian-newmaint mailing list and forward all information and emails from you to the Debian Account Managers (after the Front Desk checks and confirms that all of the important information is present). The Debian Account Managers have the actual authority to approve new Debian Developers. They will review all information sent to them and reach their own decision. If they approve your application, they will submit requests for your GPG key to be added to the Debian Keyring and for an account to be created for you in the Debian systems. At this point, the New Member process is complete. For me, it took exactly 1 month from the time I officially applied to become a Debian Developer until the time of my application being approved by the Debian Account Managers. Hopefully, it will not be long until my GPG key is added to the keyring and my account is created. I feel the entire process went by very quickly and was pain-free. Hopefully, this blog post will help to encourage more people to apply to become Debian Developers.

Review: Fables: Legends in Exile, by Bill Willingham, et al.

Series:	Fables #1
Penciller:	Lan Medina
Inker:	Steve Leialoha
Inker:	Craig Hamilton
Colorist:	Sherilyn van Valkenburgh
Letterer:	Todd Klein
Publisher:	Vertigo
Copyright:	2002
ISBN:	1-56389-942-6
Format:	Graphic novel
Pages:	127

The characters of human fairy tales are all real. Real, but hidden: they have been driven from their ancestral homelands by some force referred to here only as the Adversary, and have fled to the mundane world to escape his notice. Specifically, New York, where those characters who can pass as human blend into the streets of New York City, and those who can't (referred to only in passing in this story arc apart from one pig) stay at a farm upstate. That's the brilliant premise of Fables, an ongoing comic series from Vertigo that's up to 121 issues plus numerous spinoffs as of this writing. This is the first trade paperback, collecting issues 1 through 5 plus a prose story. Legends in Exile is, in underlying form, a murder mystery. It opens with Jack reporting a murder to Bigby Wolf, who is what passes for law enforcement among the Fables. Rose Red's apartment has been discovered covered in blood, and her body is missing. "No more happily ever after" is written on the wall in blood. Jack, despite being the one to report the crime, is Rose's lover and an obvious suspect. So is Snow White, the effective leader of the Fables (King Cole is a figurehead) and Rose's estranged sister. And, perhaps coincidentally, Prince Charming, Snow White's philandering and stunningly narcissistic ex-husband, has just turned up in town again. The basic plot plays out like a typical murder mystery, complete with a grand reveal in the last chapter and a reconstruction of events. It's diverting but nothing special in itself; it's primarily a hook on which to hang an introduction to the major characters and an exploration of Fables politics and history. And that part is excellent. Like most fractured fairy tales, the characters are more complex and nuanced than they are allowed to be in the canonical stories; unlike most fractured fairy tales, nearly all of that development is allowed to happen after the original stories. The original stories happened, largely as we all remember them, but then the characters kept living and changing. Wolf and his relationship with one of the three pigs is one of the highlights, but I think the odious Price Charming is the best bit of characterization. Willingham takes the idea of a charming seducer and layers in the rest of the womanizing associations that come to mind, while retaining a slick surface charm that is hard not to like at some level. I'm not the best at critiquing art. I read graphic novels for the story, with the art as a nice bonus if it's fairly good. But I can say that Medina's pencils tell the story well, with a few larger panels that were quite impressive. I particularly liked Snow White's office, early in the collection. Detail is reasonably good throughout, there aren't too many panels featuring only talking heads, and Medina does a wonderful job with the pig. (Significant credit probably also goes to Steve Leialoha and Craig Hamilton, the inkers. I'm not a good enough art critic to distinguish between the quality of the pencil work and what was added by subsequent inking.) The largest problem for me with Legends in Exile is my standard problem with graphic novels and the reason I don't buy many of them: the cover price is $10 for what is effectively a short story that builds an interesting world. If one really loves art in stories, graphic novels may be a good value. If, like me, one mostly cares about the story and would be almost as happy with straight prose, the value becomes questionable given the brief length of the material. That said, Legends in Exile does add a quite good prose short story by Willingham, "A Wolf in the Fold," which in several ways is better than the main story of the collection. It tells the story of the original exile and the covenant that settled all past grudges (mostly) from the perspective of the wolf. Willingham does a great job here both striking a more mythic tone than the main story but still tying it back to the sarcastic and practical tone of the rest of the collection. Although the main story itself is not particularly memorable, the background and concept make this one of the better graphic novels I've read. I can see why it's won so many awards, and I'll probably keep reading, despite the high graphic novel price tag. Followed by Fables: Animal Farm. Rating: 7 out of 10

As you may know, when Phil Zimmermann published PGP, his goal was to counter the wide spying possibilities the development of electronic communications offered to the authorities, by promoting the general use of encryption so that 1. governments would not be able to restrict it afterwards and 2. it becomes possible to encrypt messages for privacy without drawing suspicion. Now, cryptography has made its way and is widely use, but mostly for commercial website and only sparsely for mail. Indeed, contrary to signing, encrypting a message requires that the recipient has a crypto key and is able and willing to use it to decrypt your message. To alleviate this problem, I thought that it would be useful to have a way, when sending a message, to tell your recipients that you would like that they encrypt their answers, because you are able and willing to get encrypted mail. I think the most relevant way to do that would be by adding a dedicated header field:

Encryption-Desired: PGP

In that header, one would be able to indicate what protocols he accepts. I suggest a comma-separated list, with the following possible values: PGP (or PGP/MIME and PGP/traditional for people that only accept one of these two PGP formats), S/MIME. For instance:

Encryption-Desired: PGP/MIME, S/MIME

It may be useful to be able to indicate that you either always wish your messages to be encrypted, or that it is only for this message's replies. If this is really relevant, it would take two distinct headers: Encryption-Desired and Reply-Encryption-Desired. Any thought about that proposal? Next thing to do, determine how to have that standardized at IANA and how to promote it.

It's quite some time since I didn't report about Debian Installer localization. Indeed, thanks to the tireless activity of Cyril Brulebois, we focused on releasing D-I and I indeed stopped harassing translators for updates around July 2012. Why July? Well, you probably know we have "something" to release as soon as we can and most, if not all, Debian energies should be focused on this! Or, more precisely speaking, I only focused on getting the newly introduced material translated: we had several changes recently in D-I, mostly focused on important features, such as IPv6 support (thanks to Phil Kern who worked on this), better wireless networking support (thanks to Sorina Sandu) and EFI boot support (thanks to Steve McIntyre). And, of course, when people change code in D-I, they want to add questions to users, display error and informative messages, etc, etc. And these need translations..:-) Most translators coped with all this (sometimes with /me hitting them hard on the head to get updates) and D-I beta2 was released with 37 complete translations out of 73 supported languages. Yesterday, I just resumed the activity of trying to get more updates not only for those recent changes, but also for other older changes...or for languages that never got completed in the past. As a result, we bumped from 37 compelte languages up to 45 this morning: look for level 1 here (level 2 has been hit by a change in iso-codes, but that change doesn't really affect D-I). If you language is not 100% in the leftmost column on the stats page, you can probably help. Just get in touch with me and we'll check if somebody is already working on this or not.

I wondered how to properly maintain an OpenWRT installation that needs to track trunk for one reason or another. For instance the OpenWRT release pace is quite slow and "new" devices or various fixes are only available in this particular branch.

Now the OpenWRT project does offer snapshot builds. These are images built with the default config for the particular device type. You can even upgrade most models using sysupgrade, which preserves a list of configuration files you specify when flashing the new image, instead of doing a dreadful tftp upload. But you still lose all the packages you installed and accumulate a bit of cruft when reinstalling them. If you do not flash new images, you will be unable to install kernel modules after a while, because the kernel version they're based upon was updated.

So what's suggested is this:

• You checkout the trunk from svn. You enable all the feeds you need (e.g. packages and luci) and install the packages you want. (See scripts/feeds.)
• Run make menuconfig and select the target system type and the device profile.
• make defconfig will now give you the default configuration for the selected profile. It is important to use this as the starting point.
• Again invoke menuconfig and select all the packages you need. You can get the current list of packages installed on your device with opkg list_installed. You can search in menuconfig as you would in a kernel build config screen.
• If you're happy with the configuration, save the difference to the default configuration to a file: scripts/diffconfig.sh > my-own-config
• Now start the build with make. With the package configuration I picked I need about 5 GB of disk space. It will start off compiling a toolchain, the kernel and then the packages you selected. If something seems to go wrong, you probably want to restart the build with make V=s to see the build messages (the default is pretty quiet). Some -jX option for parallel building might shorten your waiting time.
• Finally you will get an image in bin/<system type>. You want to grab the squashfs & sysupgrade image.
• Check /etc/sysupgrade.conf on the live system if files are missing. /etc/config, passwd, shadow and some other files are preserved even if they are not listed. Those are then the only files that are copied into a temporary ramdisk during upgrade and written back to the filesystem post-flash. You need to keep this file up-to-date if you include new packages that have non-UCI configuration.
• For actually executing the upgrade process, you can either use the luci web interface or start sysupgrade over SSH. For the latter you will have to copy the image yourself. If you go via luci, you should check the md5 hash presented to you against the one of the image on your disk.
• If you want to update your image, just svn update (in the hope that the OpenWRT developers did not break anything in trunk), get the new defconfig, append your saved configuration delta (the file "my-own-config" above) to .config and run make oldconfig. This will keep track of feature changes in the default configuration (like shadow password support).

The advantage of building an image that includes all the packages is that you don't get to reinstall them and due to the use of squashfs, all files provided by those packages are actually kept in compressed form in flash. The image I built has a size of about 7 MB and contains "heavyweight" packages like isc-dhcpd, bind, openvpn (using openssl), bash, vim-tiny, tcpdump-mini, luci, and a webserver with TLS support.

As always: Take great care when you're flashing devices. The devices I bought cannot be bricked, but this might not be true for all devices that run OpenWRT. You might need and go doing a tftp image upload if something goes wrong. Check the OpenWRT wiki for instructions and possibly make your computer ready for them before starting to play with your box. For my Buffalo WZR-HP-AG300H the sysupgrade procedure is stable.

Well this weeks log comes bit late as my week got extended till today ;-). I had working day at office on Saturday and Sunday due to 2nd Quarter end and instead today is declared as compensatory holiday and tomorrow any how is Gandhi Jayanti. So here it goes. Debian Related Most of my work this week was done for Debian-IN team

• Integrated the KGB bot for Debian-IN team repository. Thanks to gregoa Tincho and dam for extending helping hand in getting it configured
• Updated the setup-repository to install a proper post-receive hook when creating new repositories.
• Copied the set-git-hook from pkg-ruby-extras team and modified it slightly to install post-receive hook for KGB integration for already existing repository. With this script I fixed few of the packages to use KGB which I own. Waiting for Kartik to fix remaining repositories as he is the DD for our team :-)
• Configured my personal instance of KGB which now stands in Debian-IN's channel (#debian-in). But bot is named RAW (Research and Analysis Wing) equivalaent of KGB and CIA in India :-P

Well most of this weeks work involved KGB ;-) Personal Works

• Attended the PyconIndia-2012 on Saturday, Got a NFC card :-) which I can't use as my phone is not NFC capable. Only handful of talks were nice rest were all newbie like talk which even lacked proper presentation skills hence didn't attend on second day. Looks like quality of conference in India is decreasing.
• Finally completed answering all questions on Philosophy and Procedures - 1 part of NM process :-). Phew it took me more time than I expected. Waiting for my AM's comment. Hopefully I will get next bunch of questions soon :-)

Misc Played Cricket after very long time (Guess after 10 long years). Well it was not official match or anything it was just another Gully Cricket. After the match it came to mind that I need regular physical workout :-P. Well that's it Cya till next week :-)

I was working on writing tests for gnome-settings-daemon a week or so ago, and finally got blocked on being unable to set up upower/ConsoleKit/etc. the way I need them. Also, doing so needs root privileges, I don t want my test suite to actually suspend my machine, and using the real service is generally not suitable for test suites that are supposed to run during make check , in jhbuild, and the like these do not have the polkit privileges to do all that, and may not even have a system D-Bus running in the first place. So I wrote a little test_upower.py helper, then realized that I need another one for systemd/ConsoleKit (for the system idle property), also looked at the mock polkit in udisks and finally sat down for two days to generalize this and do this properly. The result is python-dbusmock, I just released the first tarball. With this you can easily create mock objects on D-Bus from any programming language with a D-Bus binding, or even from the shell. The mock objects look like the real API (or at least the parts that you actually need), but they do not actually do anything (or only some action that you specify yourself). You can configure their state, behaviour and responses as you like in your test, without making any assumptions about the real system status. When using a local system/session bus, you can do unit or integration testing without needing root privileges or disturbing a running system. The Python API offers some convenience functions like start_session_bus() and start_system_bus() for this, in a DBusTestCase class (subclass of the standard unittest.TestCase ). Surprisingly I found very little precedence here. There is a Perl module, but that s not particuarly helpful for test suites in C/Vala/Python. And there is Phil s excellent Bendy Bus, but this has a different goal: If you want to thoroughly test a particular D-BUS service, such as ensuring that it does the right thing, doesn t crash on bad input, etc., then Bendy Bus is for you (and python-dbusmock isn t). However, it is too much overhead and rather inconvenient if you want to test a client-side program and just need a few system services around it which you want to set up in different states for each test. You can use python-dbusmock with any programming language, as you can run the mocker as a normal program. The actual setup of the mock (adding objects, methods, properties, etc.) all happen via D-Bus methods on the org.freedesktop.DBus.Mock interface. You just don t have the convenience D-Bus launch API. The simplest possible example is to create a mock upower with a single Suspend() method, which you can set up like this from Python:

import dbus
import dbusmock
class TestMyProgram(dbusmock.DBusTestCase):
[...]
    def setUp(self):
        self.p_mock = self.spawn_server('org.freedesktop.UPower',
                                        '/org/freedesktop/UPower',
                                        'org.freedesktop.UPower',
                                        system_bus=True,
                                        stdout=subprocess.PIPE)
        # Get a proxy for the UPower object's Mock interface
        self.dbus_upower_mock = dbus.Interface(self.dbus_con.get_object(
            'org.freedesktop.UPower', '/org/freedesktop/UPower'),
            'org.freedesktop.DBus.Mock')
        self.dbus_upower_mock.AddMethod('', 'Suspend', '', '', '')
[...]
    def test_suspend_on_idle(self):
        # run your program in a way that should trigger one suspend call
        # now check the log that we got one Suspend() call
        self.assertRegex(self.p_mock.stdout.readline(), b'^[0-9.]+ Suspend$')

This doesn t depend on Python, you can just as well run the mocker like this:

python3 -m dbusmock org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower

and then set up the mocks through D-Bus like

gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
      -m org.freedesktop.DBus.Mock.AddMethod '' Suspend '' '' ''

If you use it with Python, you get access to the dbusmock.DBusTestCase class which provides some convenience functions to set up and tear down local private session and system buses. If you use it from another language, you have to call dbus-launch yourself. Please see the README for some more details, pointers to documentation and examples. Update: You can now install this via pip from PyPI or from the daily builds PPA. Update 2: Adjusted blog entry for version 0.0.3 API, to avoid spreading now false information too far.

We just sent out a new call for testing for the next point release of Debian Squeeze. The last one was back in May, hence there are a bunch of updates. Please test the packages in squeeze-proposed-updates on some machines running squeeze if possible, so that we don't screw up your production machines with bad updates in a week. The point release is scheduled for September 29th, i.e. next Saturday. Don't forget to copy the debian-release mailing list when you encounter regressions. Thanks for your efforts.

If you want to receive these notices by mail, please subscribe to the debian-stable-announce mailing list.

The IPv6 patch set for netcfg (part of debian-installer) has landed in Debian unstable. In follow-up uploads I diverged from the Ubuntu patch set a little bit:

• I dropped the use of DUID-LL as the client identifier used by the DHCPv6 client. While basically a good idea, because it's predictable, it's also against the RFC to do that. We simply don't know if the network interface is permanently attached to the device. If the NIC that's used for DUID-LL generation is reused for installation in another box, the same identifier would be generated and stored on the machine. That's what DUID-LLT (the default in other software) avoids. As much as I loathe the replacement of the current MAC address-based scheme of DHCPv4 with DUID-LLT, it seems to be more correct to use that instead of DUID-LL, because that identifier is designed to be decoupled from the presence of the NIC. If you want predictable addressing, just enable SLAAC in your broadcast domain and use the EUI-64 address, which already contains the current MAC address.
• If SLAAC is used, netcfg will activate IPv6 privacy extensions in the installed system by default. They can be turned off by editing /etc/network/interfaces post-installation. This will only affect outgoing traffic, incoming traffic can be addressed at the stable EUI-64 address. (We don't use a randomized interface identifier like Windows does.)

Thanks to Michael Tokarev's recent upload of busybox, we now also have a more featureful ping and ping6 in debian-installer's environment.

Known bugs:

• As far as I can see, the DUID generated in the debian-installer environment is not copied into the installed system. Given the low prevalence of stateful DHCPv6 for servers I don't consider this a blocker, though.
• If stateful DHCPv6 is requested by the router advertisement (other config flag being set), the DHCPv6 client will not time out and continuously retry to get an address.
• According to Debian bug #688273 preseeding of netcfg/use_autoconfig does not work correctly. netcfg/disable_dhcp needs to be re-added as a deprecated preseeding option and mapped onto the use_autoconfig value until somebody comes up with a better scheme.
• We should state in the installation guide that ftp.ipv6.debian.org and http.debian.net can both be used for IPv6-only installation. The installer does not show in the mirror list if a mirror is IPv6-capable.

If you could take another look at a current d-i daily, install a system with it and look if the installed system has a correct network configuration, that would still be appreciated. I also need somebody to test the GNU/kFreeBSD image. I fixed it up to build there but the result might be entirely wrong.

My sincere thanks go to Bernhard Schmidt and Karsten Merker, who successfully completed installations over IPv6 in various environments!

What I have done (on my packages for Wheezy) in the last weeks? imvirt 0.9.4-3 and 0.9.4-4 adds two upstream patches to remove an applicable use of /proc in Perls procfs_read() method, which fixes LXC detection and another patch to not count the dmesg lines twice within the KVM detection module.
Much thanks to Thomas Liske! mlt The 0.8.0-4 upload also adds two upstream patches to fix an major memory leak in the mlt_cache function and a crash with LADSPA plugins on dlclose().
And here much thanks to Dan Dennedy!
I have also uploaded 0.8.2-1 to experimental. roaraudio 1.0~beta2-2 and 1.0~beta2-3 added a few upstream patches to fix security and major use problems. The debdiff was a bit huge so it took a bit more time to unblock/migrate.
1.0~beta5-1 is also available in experimental.
Much thanks for the patch support to Philipp Schafft! otrs2 With the 2.4.9+dfsg1-3+squeeze3 upload (DSA-2536-1) there was an security update for otrs2 on Squeeze which fixes a cross-site scripting issue and improved the e-mail filter to detect nested tags. Those with a few other fixes migrated with 3.1.7+dfsg1-5 to testing, while I also uploaded 3.1.10+dfsg1-1 to experimental.
Now I can focus on the upcoming 3.2.x packaging. :)

10 months ago I was given a Samsung Galaxy S Android phone [1] to replace my Sony Ericsson Xperia X10. I also installed Cyanogenmod on it (here is a more detailed comparison of the phones with a focus on liberty [2]). But now I m using the Xperia X10 again. Hardware Reliability Some time ago a friend told me that he bought a Sony phone in preference to a Samsung phone because he didn t think that Samsung phones were reliable enough. I assured him that Samsung phones would be fine if you used a gel-case, but now I m not so sure. My mother in law has a Samsung Galaxy S which now has a single crack across the face, it doesn t appear that her phone was dropped, maybe it just bent a bit it s a fairly thin phone. My Galaxy S started crashing over the last few months and now many applications will crash any time I use 3G networking. Currently my Galaxy S is working well as a small Wifi tablet and hasn t crashed since I replaced the SIM with one that has expired. I wish that phone designers would make mode solid products with bigger batteries. The fact that the Xperia X10 weighs maybe 20g more than the Galaxy S (according to Wikipedia) isn t a problem for me. Even with the Mugen Power 1800mah battery [4] to replace the original 1500mah battery it s still nowhere near the limit of the phone mass that I m prepared to carry. Sony Upgrades Some time ago Sony released an Android 2.3.3 image for the Xperia X10. There is no Cyanogenmod image for the Xperia X10 because it has been locked down which greatly limits what can be done. Also Sony has a proprietary backup program on their Android 2.1 image which isn t supported on Android 2.3.3 this inspired my post about 5 principles of backup software [3]. Due to this pain I didn t even try to upgrade the Xperia X10 phones for me and my wife until recently. Before upgrading the Xperia X10 phones I was unable to use my wife s phone. The phone didn t seem to like recognising my touch so long touch actions (such as unlocking the phone) were almost impossible for me. I think that this is due to the fact that I have fairly dry skin which presumably gives me a higher capacitance. After the upgrade both phones are usable for me, so presumably either Sony or Google upgraded the algorithms for recognising touch to work better with varying screen quality. Comparing the Galaxy S and the Xperia X10 When I first started running Cyanogenmod on the Galaxy S I noticed that it was a lot faster than the Xperia X10 but I didn t know why. It was documented that there had been performance improvements in Android 2.2. Now that I m running Android 2.3.3 on the Xperia X10 I know that the performance difference is not due to the Android version. It could be due to Cyanogenmod optimisations or Sony stupidity, but it s most likely due to hardware differences. The Galaxy S has more RAM and storage which allows installing and running more applications. Now that I m using the Xperia X10 for the bare minimum applications (phone calls, SMS, camera, email, ssh, and web browsing) it works quite well. I still play games on the Galaxy S and use it for more serious web browsing via Wifi. I think that the value I m getting from the Galaxy S as a tiny wifi tablet is greater than the money I might get from selling a partially broken phone that s been obsoleted by two significantly better models. Conclusion The camera on the Xperia X10 is significantly better than the one on the Galaxy S, so going back to a phone that has a great camera is a real benefit. But being slow and locked down is a real drag. I was tempted to buy a Samsung Galaxy Note or Galaxy S3, but it seemed like a bad idea to buy a phone given that my contract comes up for renewal in about 6 months which means I ll be offered a free phone which while not really free is still going to be cheaper than buying a phone outright. Also in future given the low opinion I m now getting of smart phone reliability I ll try and keep a small stock of spare Android phones to cover the case of broken phones.

• [1] http://etbe.coker.com.au/2011/11/21/galaxy-xperia-android-network/
• [2] http://etbe.coker.com.au/2012/05/06/liberty-mobile-phones/
• [3] http://etbe.coker.com.au/2012/02/07/5-principles-backup/
• [4] http://tinyurl.com/cyafvqq

Related posts:

1. Galaxy S vs Xperia X10 and Android Network Access Galaxy S Review I ve just been given an indefinite loan...
2. CyanogenMod and the Galaxy S Thanks to some advice from Philipp Kern I have now...
3. Liberty and Mobile Phones I own two mobile phones at the moment, I use...

I tried to continue netcfg's journey to support IPv6 in debian-installer. Matt Palmer wrote a large patch set many moons ago (kudos!) and Colin Watson polished it and included it into Ubuntu. The reason for it not being merged into Debian first was ifupdown. Version 0.7 finally supports IPv6 and only entered Debian unstable by the end of May. Due to a bunch of changes to netcfg, one reason being a Summer of Code project on it, I had to forward-port those 50 patches and add two bug fixes on top. Hence it's possible that I introduced some breakage, even if the result works well for me (apart from one DHCPv6 oddity that cannot be seen from within KVM). The tree can be found in the people/pkern/ipv6 branch. I was unable to check if Ubuntu has introduced any additional patches on top of the old patch set, as I'm not used enough to bzr.

This mini.iso (detached signature) netinst image contains a debian-installer current as of today and two additional patched udebs: netcfg with the aforementioned IPv6 patch set and busybox with ping6 enabled. I'd appreciate if you could go and test it in one (or more) of the following environments: IPv4-only (DHCPv4 / static), wireless (IPv4 / IPv6 as desired, there has been some refactoring), stateless IPv6 autoconfiguration (it even supports RDNSS and DNSSL), stateless IPv6 autoconfiguration with stateless DHCPv6, and stateful DHCPv6. It will try to configure dual stack if possible. Please note that many Debian mirrors are not yet IPv6-enabled. Even prominent ftp.CC.debian.org hosts like ftp.de.debian.org still do not support it. So you'll have to pick one carefully if you want to try IPv6-only installation. (Which worked for me!)

If you have any feedback for me, please leave it here as a comment or mail me at pkern@d.o. Thanks!

This is the result of an old meme, but it is still quite interesting:

What American accent do you have? Your Result: The Northeast Judging by how you talk you are probably from north Jersey, New York City, Connecticut or Rhode Island. Chances are, if you are from New York City (and not those other places) people would probably be able to tell if they actually heard you speak.
Philadelphia
Boston
The Inland North
North Central
The South
The West
The Midland
What American accent do you have? Quiz Created on GoToQuiz

Happy 19th birthday, Debian! The Debian project is 19 years old now. Following Francesca's invitation (and Rapha l's lead, and using Leandro's image, collaboratively as it always happens here), I will tell a bit of my memories: How I got to Debian. I am a Debian user since ~2000, and a Debian Developer since April 2003. But, just as Rapha l's, my history must go somewhat further back in time. In 1992, I got my first 1200bps modem, and almost immediately became an avid BBS user (what's that? Javier Matuk talks [in Spanish] about BBSes in his newspaper column back in 1994). By mid 1993 I started operating my own BBS, CatarSYS. One of the key points that defined CatarSYS is that my focus was large-scale communication. I started connecting to several BBS networks, allowing messages to be relayed to distant people, mainly in the USA and Spain, and getting some feeds that could be seen as the poor man's Usenet. At some point during the year I kept CatarSYS going, I got connected through a strange set of gateways to pure gold: A UUCP feed! This means, during some months, I operated the first (free, hobbyist) service that offered its users a free Internet mail address in Mexico. Yes, it was completely different to what we are used to today. I tried to connect to my provider at least three times a week, but this meant less than one week turnover time for messages sent to people anywhere in the world! But, back to Debian: Via this UUCP feed, I also got some real Usenet newsgroups Including several on the comp.os category. I remember reading about Linux back then, and learning some commands, but didn't really get hooked into it. I was in Israel from July 1994 to June 1995, doing completely non-computer-related tasks. Came back in 1995, and due to my father being an academic, got dialup internet access at home. WOW, *real* Internet! It didn't take me long to start downloading Linux information and floppy images. One failed after another. But before the end of the year, I found in a bookshop a book (that included a CD-ROM) called "Build your own web server with Linux". WOW again Remember this was still 1995! I bought it, and shortly afterwards, I had a Slackware system (Linux kernel 1.0.9) running. That meant many sleepless nights full of joy and frustration (as getting hardware to work was cloe to impossible). By 1996, I got (within one week) my two first real jobs: A systems administrator at a small ISP and a highschool teacher. At the ISP, I got a spare computer to play with Linux, as of course the Big Server was running with Windows NT 3.51. Poor little machine... By then I was already a part of the Mexican Linux User Group. This group had just printed a batch of Linux CDs RedHat 4.0. This was the first release that really made me happy and allowed me to do good work. Together with a friend I took to work with us, Juan Pablo Romero, we installed over a weekend a full replacement for our buggy NT machine, in much cheaper hardware. Of course, Linux was nowhere near corporate-recognition, and our project remained a project, not touching the Windows machine. Anyway... Several years passed, and I was happy with my RedHat choice. I won't mention the milestones and job changes, as it would get boring and leave the point completely aside. By the year 2000, I was quite more involved with the LUG, as well as with the computer security group in DGSCA-UNAM. I became also an OpenBSD user, and had got so hooked up in free software that I felt the need to collaborate: To be a little part of one of those Big Projects that had given me so much. But which one? I have never been much of a programmer Yes, I can solve my everyday needs and have fun with it, and sometimes a bit beyond that. I enjoy programming. But all of my projects have begun little and stayed little. I wanted to join OpenBSD, as it was a community I really believed in, but given my skillset (and given a flame-prone, aggressive developer community), I lost motivation to do so. By 2000, I had also lost faith in RedHat. I don't have the exact dates, so I might be some months off But after RedHat's IPO, I felt a sharp change. Version 7.0 was really demotivating It tried to offer a polished desktop experience, but was really buggy, unstable, and full of bad decisions. In Mexico, Pepe Neif had taken up the job of making a derivative distribution of RedHat (called LinuxPPP), pressing hundreds of CDs and making a teaching program I was part of several times. Talking with Pepe (who continued to release based on RedHat 6), he told me he was interested in switching over to become a Debian-based distribution, but the job of migrating his installed base made the project stall LinuxPPP reached only version 6.4. But I installed Debian in early 2000, and loved it. I started getting familiar with its social philosophy and foundation documents at the same time I started migrating my servers from RedHat to Debian This must have been by Spring 2000, as I installed Potato while it was frozen but not yet stable. By January 2002 I applied for NM. My process took a long time, as my AM got MIA when he had already approved me (but before sending the AM report), so basically I had to go through AM twice And by April 16, 2003, I got accepted as a DD. Contrary to what is acceptable today, I requested the full process to be done before starting to maintain any packages, as I didn't want to bother people with package sponsorship requests, so my whole process was done evaluating packages I would eventually upload. Since becoming a DD, my main involvement in the project has been in packaging groups (I was a pkg-perl founder and member for many years, and am currently working in the pkg-ruby-extras group). But, as I said, my main strength is not programming So my main involvement in Debian has been more social than technical: I have been a DebConf organizer since 2005, a very interesting, stressing, rewarding and (for some months) time-demanding role, and since 2009 I am part of the keyring maintainence team, which is much easier workload, although carries important ramifications. So, after 19 years of Debian, and after nine years of me being part of it, Debian is clearly my strongest link to the Free Software community, a project I have grown to love and whose way of being I share and enjoy studying and explaining. And it is a technically excellent product, and a great place to start and keep learning both about how every aspect and layer of an operating system works, and how human-to-human interaction works in such a diverse, almost impossible environment happens. Congratulations, Debian!

Attachment	Size
debian-19_500.png	149.81 KB

For Debian s birthday, Francesca Ciceri of the Debian Publicity team suggested that developers blog about their first experiences with Debian . I found this a good idea so I m going to share my own early experience. It s quite different from what happens nowadays Before speaking of my early Debian experience, I have to set some context. In my youth, I have always been a Windows user and a fan of Bill Gates. That is until I got Internet at home at that point, I got involved in Usenet and made some friends there. One of those made me discover Perl and it has been somewhat of a revelation for me who had only been programming in Visual Basic, Delphi or ObjectPal. Later the same friend explained me that Perl was working much better on Linux and that Debian Linux installs it by default so I should try this one. I had no idea of what Linux was, but given how I loved Perl, I was eager to try his advice. So I got myself a Tri-Linux CD with Debian/RedHat/Slackware on it and started the installation process (which involved preparing boot floppies). But I did not manage to get the graphical interface working despite lots of fiddling with Xfree86 s configuration file. So I ended up installing RedHat and used it for a few months. But since many of the smart guys in my Usenet community were Debian users, I persisted and finally managed to get it to work! After a few months of usage, I was amazed at everything that was available for free and I wanted to give back. I filed my first bug report in July 1998, I created my first Debian packages in August 1998 and I got accepted as an official Debian developer in September 1998 (after a quick chat over the phone with Martin Schulze or James Troup I never understood the name of my interlocutor on the phone and I was so embarassed to have to use my rusty English over the phone that I never asked). That s right, it took me less than 3 months to become a Debian developer (I was 19 years old back then). I learned a lot during those months by reading and interacting with other Debian developers. Many of those went away from Debian in the mean time but some of them are still involved (Joey Hess, Manoj Srivastava, Ian Jackson, Martin Schulze, Steve McIntyre, Bdale Garbee, Adam Heath, John Goerzen, Marco D Itri, Phil Hands, Lars Wirzenius, Santiago Vila, Matthias Klose, Dan Jacobowitz, Michael Meskes, ). My initial Debian work was centered around Perl: I adopted dpkg-ftp (the FTP method for dselect) because it was written in Perl and had lots of outstanding bug reports. But I also got involved in more generic Quality Assurance work and tried to organize the nascent QA team. It was all really a lot of fun, I could take initiatives and it was clear to me that my work was appreciated. I don t know if you find this story interesting but I had some fun time digging through archives to find out the precise dates if you want to learn more about what I did over the following years, I maintain a webpage for this purpose.

One comment Liked this article? Click here. My blog is Flattr-enabled.

With a current daily build of debian-installer you should now be able to install a VM with Debian s390x. I'm told that even installation within hercules works again. d-i's beta 1 for wheezy has a broken busybox and is hence unusable. But there were more issues:

• zipl-installer was blacklisted from building on s390x by Packages-arch-specific which caused nobootloader to be selected during installation.
• base-installer was unable to pick the correct kernel image due to it not having any rules for this architecture.
• A netcfg fix was needed that removes a 50s timeout while d-i tries to arping the configured gateway. This check seems to be pretty new and if it fails the link is still considered up and the installation continues. The network driver commonly used on s390(x) (qeth) uses layer 3 configuration by default, which means that ARP is meaningless. The IPv4 and IPv6 addresses are configured in the network adapter which then does all the ARP if necessary (i.e. not within the same machine).

The resulting installation even boots. But it shares some problems with squeeze's s390 port:

• udev's persistent network device naming is broken. It includes a volatile device ID that is incremented with each reboot. This is now tracked in Debian bug #684766.
• The TERM variable is set to linux during boot-up instead of dumb (the s390(x) terminals are either line- or form-based, except for one HMC ASCII terminal). Together with the new fancy coloured LSB init output in wheezy the screen gets even more noisy with all those escape sequences. It's yet unclear where this should be fixed. The kernel provides the init system with a TERM=linux default and it's not yet fixed up afterwards (either in initramfs-tools, or busybox, or sysvinit).

Tip of the day: If you see funny characters in x3270, then you maybe selected the wrong EBCDIC code page. If you use Linux you want to select CP1047 instead of the default CP037 in Options Character Set ( Euro). That's the target of the in-kernel ASCII to EBCDIC converter.