About this time last year, I spent a while talking about how Barnes and Noble were failing in their GPL obligations. It took them about two months to release some source code that didn't actually correspond to the hardware - they finally provided it in March, more than three months after shipping the device.

The Nook Color is now shipping. Guess what Barnes and Noble aren't providing yet?

The flood of generic Chinese Android devices with no source code makes it very easy to think that GPL adherence is something that's only problematic with devices sourced from countries with poor records in IP enforcement. In reality, it's a problem everywhere. Barnes and Noble are a US company and the contractors for the Nook were based in Canada. They're aware enough to include the GPL notice in their documentation, but not concerned enough to make sure that they actually posses the source code that they're legally obliged to provide.

I'm glad to see that the Linux Foundation are providing resources to ensure compliance, but it's likely that this is going to continue being a problem until we start engaging in more visible efforts to educate companies about their legal obligations. The idea that a company like Barnes and Noble would ship copies of Windows without paying the appropriate license fees is pretty implausible, but they seem perfectly happy to engage in for-profit copyright violation if nobody's going to chase them down. It'll be interesting to see if this trend continues, or if we start making a sincere effort to remind vendors of their obligations.

In other GPL violation news - Fusion Garage have promised me that they'll provide the source code to their GPLed components on Monday. Given that the device has been end of lifed this is obviously pretty inept. Investors should realise that they're putting money into a company that has knowingly been engaging in criminal behaviour for over 6 months. We'll see how they manage compliance for their Android devices.

Most Debian packages are managed with a version control system (VCS) like git, subversion, bazaar or mercurial. The particularities of the 3.0 (quilt) source format are not without consequences in terms of integration with the VCS. I ll give you some tips to have a smoother experience. All the samples given in the article assume that you use git as version control system. 1. Add .pc to the VCS ignore list .pc is the directory used by quilt to store its internal data (list of applied patches, backup of modified files). It s also created by dpkg-source so that quilt knows that the patches are in debian/patches (and not in patches which is the default directory used by quilt). For that reason, the directory is kept even if you unapply all the patches. However you don t want to store this directory in your repository, so it s best to put it in the VCS ignore list. With git you simply do:

$ echo ".pc" >>.gitignore
$ git add .gitignore
$ git commit -m "Ignore quilt dir"

The .gitignore file is ignored by dpkg-source, so you re not adding any noise to the generated source package. 2. Unapply patches after the build If you store upstream sources with non-applied patches (most people do), and if you don t build packages in a temporary build directory, then you probably want to unapply the patches after the build so that your repository is again in a clean status. You can do this by adding unapply-patches to debian/source/local-options:

$ echo "unapply-patches" >>debian/source/local-options
$ git add debian/source/local-options
$ git commit -m "Unapply patches after build"

svn-buildpackage always builds in a temporary directory so the repository is left exactly like it was before the build, this option is thus useless. git-buildpackage can also be told to build in a temporary directory with --git-export-dir=../build-area/ (the directory ../build-area/ is the one used by svn-buildpackage, so this option makes git-buildpackage behave like svn-buildpackage in that respect). 3. Manage your quilt patches as a git branch Instead of using quilt to manage the Debian-specific patches, it s possible to use git itself. git-buildpackage comes with gbp-pq ( Git-BuildPackage Patch Queue ): it can export the quilt serie in a git branch that you can manipulate like you want. Each commit represents a patch, so you want to rebase that branch to edit intermediary commits. Check out the upstream documentation of this tool to learn how to work with it. There s an alternative tool as well: git-dpm. Its website explains the principle very well. It s a more complicated than gbp-pq but it has the advantage of keeping the history of all branches used to generate the quilt series of all Debian releases. You might want to read a review made by Sam Hartman, it explains the limits of this tool. 4. Document how to review the changes One of the main benefit of this new source format is that it s easy to review changes because upstream changes are kept as separate patches properly documented (ideally using the DEP-3 format). With the tools above, the commit message becomes the patch header. Thus it s important to write meaningful commit messages. This works well as long as your workflow considers the Debian patches as a branch that you rebase on top of the upstream sources at each release. Some maintainers don t like this workflow and prefer to have the Debian changes applied directly in the packaging branch. They switch to a new upstream version by merging it in their packaging branch. In that case, it s difficult to generate a quilt serie out of the VCS. Instead, you should instruct dpkg-source to store all the changes in a single patch (which is then similar to the good old .diff.gz) and document in the header of that patch how the changes can be better reviewed, for example in the VCS web interface. You do the former with the --single-debian-patch option and the latter by writing the header in debian/source/patch-header:

$ echo "single-debian-patch" >> debian/source/local-options
$ cat >debian/source/patch-header <<END
This patch contains all the Debian-specific
changes mixed together. To review them
separately, please inspect the VCS history
at http://git.debian.org/?=collab-maint/foo.git
<put details="details" here="here" more="more">
END

Subscribe to this blog by RSS, by email or on Facebook.

11 comments Liked this article? Click here. My blog is Flattr-enabled.

I have long been in Bruce Schneier s camp, thinking that the TSA is a joke: nothing but security theater. A few recent examples come to mind:

• In the famous recent event, a man refuses to go through the backscatter machine, and then refuses to be groped. They tell him he can t board the plane, take a report, and say he is free to leave. Then they say he has to go back to the screening area and be screened before leaving the airport, despite his wishes. Obviously they don t believe he really had a bomb, because if he did, would they really want him in a cramped area surrounded by hundreds of civilians? So why make him go back?
• Reading about these screenings, one of my thoughts was, I sure wouldn t want to have my kids have to go through that, or a millimeter wave machine whose health effects are completely unknown! Then I read the TSA s bulletin, intended to calm people like me: don t worry, kids under 13 will never be patted down. OK TSA, so either your patdowns are completely ineffective or you are so naive that you think that nobody under 13 could ever be an attacker. If the latter, why fuss with making them go through security in the first place?

I don t get it. They have been completely reactionary since they began. They have a complete failure of institutional imagination. Something happens, and then a new rule comes out to prevent the thing that everybody is now expecting. And what happens about the thing that people aren t expecting yet? Nothing. So we now have to take off our shoes because one guy tried to use them for something nefarious. OK, fine, but the next guy is probably going to try something other than shoes. Which is why, I m sure, many people are pointing out that the TSA is over-reliant on technology and device detection and completely underemphasizing evildoer detection as, we are repeatedly reminded, the Israelis excel at. The TSA s attempt to remedy that was foolish at best, and, according to a recent report, not grounded in science. Which is why I am heartened that, almost a decade after 9/11, Americans are starting to let go of their fear and be ready to reclaim some sense of intelligence at the security line. The fact that politicians think there is something to be gained by being tough on TSA s invasive screening procedures, rather than risk looking soft on terrorism, is evidence of this. So, what I haven t yet worked out is this: What gives, TSA? Are they:

• Stupid or incompetent? Do they really, deep down, actually believe it when they say this is excellent, best in the world security? Do they really not see how stupid it is?
• Afraid? Are they afraid that if they don t deploy every possible technological solution, and then there is an attack, that they will be fired? (This surely doesn t explain the botched behavioral screening program though)
• Pressured? Are the vendors of security technology getting at them directly or indirectly via politicians forcing them to deploy this stuff?
• Apathetic? They simply have a job, don t really care about it at all, and are just doing the minimum necessary to bring home a paycheck?
• Stuck in a culture of rigidity? Unable to come up with any sort of process that gives screeners the ability to use discretion, they insist that everyone be treated equally and that those that aren t are treated differently on a completely random basis. Some bureaucrats probably spent years on the plan, which is totally useless.

(Note: this criticism is directed mostly at the upper levels of TSA management; I do not believe the people most of us see have the ability to change the system, even if they wanted to.) One final word: I also get annoyed at all the people that grouse at the TSA checking 80-year-olds as thoroughly as everyone else. An 80-year-old could be wearing a hidden device just as much as anyone else could, and if we don t check them, then someday they probably will. The key is to be smart about who we check carefully. Use data, behavioral analysis, simple questioning, etc it works, and is a lot better than exempting people under 13 and over 80 from screening on arbitrary grounds. Also, it might help anyone with a blurry groin. And it might just save a bunch of us from getting cancer.

With today regular update from unstable an update to desktop-base package has brought the SpaceFun theme to Debian. This change made my feel like a child with a new shiny toy (: Take you Valessio Brito for this theme it looks great. p.s. As Rapha l mentioned, help is needed to integrated the rest of the theme to other packages.
Filed under: Debian GNU/Linux

So, I've had a Nokia 5800 for just on 18 months now. As I've discovered in the past few days, the device has 87Mb of internal memory. At the moment, after checking the device memory profile, 64Mb of that is "in use" by 'other' files. Nothing on the device, nor the OVI suite, can tell me what though. That means that various functions of the device are not working / working incorrectly. This morning, the phone started beeping telling me that 'it had run out of memory in order to receive messages'. So - if you have my alternative contact numbers; use them for now. I'm actually writing software possibly because I can see some of the source code to rectify this. Aside from this, and the fact that it runs Symbian, it was actually not a bad effort for a first-generation touch screen phone. I am waiting for a MeeGo device to become available (or be announced even). Otherwise I'll probably go for a Nexus Two or Nexus S or whatever it is called.

I finally got around to clearing out my ~/Programming and publishing a number of the silly toy projects I've built up over the years that might be useful to someone, somewhere. A brief overview of what I've basically thrown over the wall to GitHub:

flickrest

A Python/Twisted library for the Flickr API. This was written for use in Postr, although I suspect now that I don't maintain Postr any more they have forked. Maybe now this is in Git we can merge any changes.

evo-known-contact

A small tool I wrote for someone years ago that takes an RFC2822-formatted email on stdin, extracts the sender, and sets the exit code depending on whether that email address is in the address book.

feednotify

Display notifications when a RSS feed is updated.

Zebu

A tool to manage Debian chroots using cowbuilder.

Tumblrss

Screen-scrape your Tumblr dashboard and generate a RSS feed. This has bitrotted but was very useful.

gupnp-scrobbler

Listen to announcements over UPnP of music being played and submit the tracks to Last.fm.

ephy-gupnp

Dynamically generate bookmarks from UPnP devices that expose a web interface. Probably doesn't work with recent Epiphany releases because I've switched to Chrome.

ephydeli

An action to add the current page to Delicious.com. Probably doesn't work with recent Epiphany releases because I've switched to Chrome and Pinboard.

eds-tools

Some tools I wrote when working on EDS such as a dummy addressbook backend and command-line access to the libebook API.

cdscrobbler

Submit the current CD (or an arbitrary MusicBrainz album ID) to Last.fm as if you'd just finished playing it.

Out of all of these hacks I only actively use flickrest and Zebu now, so I wouldn't be surprised if there is some serious bitrot in the others. Hopefully something here is useful to someone, somewhere though!

The bug webinterface of the Universal Debian Database currently knows about the following release critical bugs:

In Total:	679
Affecting Squeeze:	261
Squeeze only:	56
Remaining to be fixed in Squeeze:	205

Of these 205 bugs, the following tags are set:

Pending in Squeeze:	17
Patched in Squeeze:	41
Duplicates in Squeeze:	23
Can be fixed in a security Update:	12
Contrib or non-free in Squeeze:	6
Otherwise fixed in Squeeze:	21

Ignoring all the above (multiple tags possible), 126 bugs need to be fixed by Debian Contributors to get Debian 6.0 Squeeze released. However, with the view of the Release Managers, 165 need to be dealt with for the release to happen. Please see Interpreting the release critical bug statistics for an explanation of the different numbers.

It looks like the desktop team has selected the artwork (including wallpaper and GDM theme) for the upcoming Debian 6.0 release. The winner of the small contest is SpaceFun by Valessio Brito. Included below is the splash screen, click here to see all the pictures. The other options in the poll were Nightly, Ciel and Lisp Machine. Thanks to the artists who participated in this contest! But the work is not over yet: while the artwork has been selected, it still needs to be integrated in the system. If you feel like helping by creating a theme for a display manager (GDM/KDM/SLIM) or for the Grub boot loader, please drop a mail to debian-desktop@lists.debian.org (subscribe here).

Be informed early by following me on Identi.ca, Twitter or Facebook.

16 comments Liked this article? Click here. My blog is Flattr-enabled.

I decided recently to publish interviews from Debian contributors and I picked Joey Hess as my first target. He s one of the few who have heavily influenced Debian by creating software that have become building blocks of the project, like the debian-installer (Joey uses the shorthand d-i to refer to it). My questions are in bold, the rest is by Joey (except for the additional information that I inserted in italics). Who are you? Hello, I m Joey Hess. I m one of the oldtimers in Debian. Actually, I just checked, and there are still up to nineteen active Debian Developers who joined the project before I did, in 1996. I got started fairly young, and am just 34 years old. I spend part of my time working with Lars Wirzenius, another Debian oldtimer, on Branchable. It makes it dead-easy for anyone to make a website that is built from Git, using my Ikiwiki engine to do wiki and blog style things. These days I spend the rest of my time working on free software, when I should really be looking for work to pay the bills. What s your biggest achievement within Debian or Ubuntu? I guess I m mostly known by Debian developers for writing debhelper and perhaps debconf. Probably founding the Debian Installer project has been a bigger impact for users. I m fairly equally proud of all three projects. But while it might sound corny, I am more proud of the accumulation of all the smaller things done in the context of Debian. It s more of a deep connection to the project. All the bugs fixed, and filed, and packages uploaded, and late night discussions, and just being a part of the larger project. What are your plans for Debian Wheezy? Hmm, I stopped thinking of Debian releases by code names back around Slink. So, few specific plans for Wheezy. The main thing I would like to help make happen in Debian next is Constantly Usable Testing, and it transcends releases anyway. The only specific plans I have for Wheezy are that there will probably be a new debhelper compat level, and I hope d-i will finally switch to using git. RH: You can learn more about Constantly Usable Testing in my article Can Debian offer a Constantly Usable Testing distribution?. If you could spend all your time on Debian, what would you work on? Getting Debian on all these computers that we carry around in our pockets and can t easily run apt-get on and hack on. Phones that is. It s a bigger problem than just Debian, but I think Debian needs to find a way to be part of the eventual solution. The FreedomBox concept at least hints at a way around the current situation with embedded computers in general. What s the biggest problem of Debian? I believe that the biggest problem is institutional, social and technological inertia. Every specific case of something that frustrates me about Debian today can be traced back to that. You contribute regularly to Debian mailing lists, yet I don t remember any aggressive/frustrated mail of you. How do you manage that? Are you avoiding heated discussions? Rats, sounds like all my wonderful flames of years past have been forgotten! Seriously though, after I noticed thread patterns, I started trying to avoid participating in the bad patterns myself. Now I limit myself to one expression of an opinion, and I don t care who gets the last word. If people can t be convinced, it s time to find another approach to the problem. Also, code talks. Most of the programs you wrote for Debian are in Perl. Do you regret this choice? I love that question! No, no regrets. My only concern is whether the language limits contributors or users. I have not seen Perl significantly limiting the use of anything except for debconf (we had to rewrite it in C for d-i). And I do not notice fewer contributions to my Perl-based code than to other code. I do sometimes regret when someone tells me they had to learn or re-learn Perl to work on something I wrote. But while I m enjoying writing new things in Haskell now, and while I hope it will mean less maintenance burden later, I don t think using Haskell will make it easier for others to contribute to my programs. Anyway, for me the interesting thing about writing a program is the problem it solves and the decisions made doing it. Choice of language is one of the less interesting decisions. Is there someone in Debian that you admire for his contributions? Well, lots. You re tempting me to throw a dart at a map. So arbitrarily, I ll say Anthony Towns. We could all learn something from how he s approached making big, fundamental changes, like introducing Testing, and making Debian Maintainers happen.

---

Thank you to Joey for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter and don t miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook. PS: If you want to suggest me someone to interview, leave a comment or mail me.

3 comments Liked this article? Click here. My blog is Flattr-enabled.

It seems like VServer is not something for long run because it does not seem to want to be upstream and there is also no good future for having it as patch in Debian for long run. So I should look for alternatives and probably migrate to some other solution while upgrading my server to Squeeze (once it is released or really close to the release). There are various options, starting with OpenVZ, through Linux Containers (LXC) up to full virtualization (probably KVM based). With OpenVZ the situation won't be much better, so it is not a real option. For various reasons I don't want to go to full virtualization, I simply thing containers are good enough and avoid too much overhead in some situations. So the only remaining solution seems to be LXC. There even seem to be some people who managed to migrate from VServer, which is good and will be definitely helpful. Now it's time to play with lxc a bit before I will try to implement it for real.

Filed under: Linux 4 comments Flattr this!

On the 13/14 November 2010 there is a nice event in the so called Ruhrpott : OpenRheinRuhr. And I d like to invite YOU :)What should you expect from heading to the RIM in Oberhausen and paying 5 entry-fee? You get a nice program full of great talks (like mine about bley ;), mikas about OpenSource management, tokkees about Git and XTarans about cli-helpers and unknown tools), a bunch of nice people showing you their distro, software, etc (Debian is there too), a social event, a keysigning party and a lot of hacking and fun. So if you are somewhere nearby, join us and enjoy the event!

---

German version (sorry planet debian readers ;)):Am 13/14 November findet im Pott die OpenRheinRuhr statt, zu der ich euch alle herzlichst einladen moechte.Was kann man erwarten, wenn man den Weg ins RIM in Oberhausen gefunden hat und die 5 Eintritt bezahlt hat? Euch erwartet ein Programm voller Talks (zB meiner ueber bley ;), mikas ueber OpenSource Management, tokkees ueber Git und XTarans ueber Helfer auf der Kommandozeile and anderere unbekannte Tools), viele Aussteller, die die eigene Distro, Software oder was auch immer anpreisen (Debian ist natuerlich auch da), ein Social Event, eine Keysigning Party und natuerlich viel Rumgehacke und Spass. Also, jeder der grad irgendwie in der Naehe ist oder in die Naehe kommen kann: ab nach Oberhausen und geniesst ein freies Wochenende! :)

So I studied the SWF 8 iPlayer a little - there are some simple rendering issues with Gnash that I'd like to come back to, but the biggest problem is obviously the media not playing. Looking at the network requests, wireshark says something about malformed packets - Gnash is getting as far as making RTMP requests, but the connection dies pretty quickly. My working theory is that there is a bug in the Gnash RTMP client code. This code was forked from rtmpdump, and has since been converted from C to C++, and a whole bunch of other stuff. It's quite possible that there is some change deep in the code which hasn't been copied back into Gnash - therefore, it makes sense to get Gnash building against librtmp properly, which is now a separate library. This, of course, means actually writing code. Eurgh. I try to avoid that when I can, but sometimes it is inevitable. :) When writing larger changes, I find it takes me longer to get acquainted with the existing code base - in this case, two code bases, since I have to understand librtmp at some level, as well. I'm not expecting to produce anything before the weekend, which is frustrating. It is also risky to write about stuff before you have completed it, because it can be a very public failure if you don't manage it!

Back when Linux kernel 2.6 was released, one of the immediate benefits that I noticed was how beautifully responsive my desktop had suddenly become. As it turned out, Linus figured out that he would create a buzz to accompany kernel 2.6's release by having a default clock rate of 1000Hz. However, the excitement was short-lived and kernel defaults were soon brought back down to a more conservative rate of 250Hz, allegedly because some peripheral chips could not handle such a high frequency bump without producing an increased amount of processing errors. Adding insult to injury, Ubuntu defaults eventually dropped another responsiveness enhancement, kernel preemption, allegedly because the goal was to have a one-size-fits-all kernel shipping with Ubuntu and preemption was detrimental to the kernel performance when the host is used as a server, which was a problem because Ubuntu had somehow decided to shift its focus from the desktop market towards the more lucrative server market. While there is nothing wrong with universally-safe kernel defaults or with a corporate decision to shift a distribution's focus towards more lucrative markets, it nonetheless left me pondering what would be the best way to get a 1000Hz kernel with preemption on my desktops, without constantly having to crank out my own kernel packages. As such, I was wondering if there would be enough traction from desktop users to justify producing such a kernel and to make it available as a post-install option from the Ubuntu repository? PS: I'm already aware that a specialized Ubuntu kernel is available to cater for the needs of audio production, but my understanding is that it has power management disabled, because it can interfere with the real-time operation of MIDI devices, while normal desktop users would definitely want to have power management enabled.

State of X in experimental What happened since last month? The video drivers we were previously lacking were built against X Server 1.9, with a tiny exception: xserver-xorg-video-nouveau. This one is particularly annoying because the ABI is not stable, and it requires a particular version of the kernel to be usable. The same seems to happen with the nouveau part of the libdrm library. As a consequence, I ve demoted it from Depends to Recommends for the xserver-xorg-video-all metapackage. The same happened to the xserver-xorg-input-wacom driver (for the xserver-xorg-input-all metapackage this time), since it isn t maintained by debian-x@, and since it didn t look too bad to have it only recommended (after all, we re only targeting experimental right now). In addition, all drivers were updated to the last upstream releases. Bottom-line, the following is now possible on (at least) both amd64 and i386 architectures:

apt-get install -t experimental xserver-xorg

As a side note: Intel users probably want to upgrade their libdrm-intel1 package to 2.4.22-2 (in experimental as well), they could run into X.Org Bug #31443 otherwise. Dependency handling for X packages in Debian Previously, dependencies were quite fun:

• Drivers used to provide a given virtual package: xserver-xorg-input-$ABI and xserver-xorg-video-$ABI. One shall note that the ABI is evolving independently for input and video drivers, see SET_ABI_VERSION in server s hw/xfree86/common/xf86Module.h for curious people.
• The xserver-xorg metapackage depended on xserver-xorg-core (the server itself) with a minimal version, and on those virtual packages. More precisely, for example in the input case: xserver-xorg-input-all xserver-xorg-input-$ABI so that by default one gets everything for autodetection to work, but one can pick a specific driver instead.
• The drivers only depended on the server, with a minimal version as well.

So what did we do to ensure the server and drivers were all using the same ABI? When the server was updated to a new ABI, one had to add the previous virtual packages to Conflicts (and keep a list of all of them, yay!). Needless to say, asking a package manager to upgrade at a same time many packages (several dozens for all drivers) declaring conflicts, especially during a mass dist-upgrade from a stable release to the next stable was no fun. So what s the current situation now?

• xserver-xorg depends on a minimal server version, and on drivers. The alternatives are now written like this: xserver-xorg-input-all xorg-driver-input. Notice there s no ABI mentioned here anymore. It s just about having the server, at least an input driver, and at least a video driver.
• xserver-xorg-core now provides an input ABI and a video ABI. In experimental for example: xorg-input-abi-11.0, xorg-video-abi-8.0
• Drivers now depend on the ABI they were built against. For example, xserver-xorg-input-evdev in experimental depend on xorg-input-abi-11.0

So one might think everything is now fine, except there are some conflicts still declared, to ensure one can transition from packages using the former (bad) logic to the new state of affairs. And those conflicts were still causing headaches to package managers. Fortunately, David Kalnischkies came up with a proposal to replace Conflicts with Breaks, which turned out to ease things. Yatta! All of that is implemented in experimental. squeeze is the transition period where the metapackage stills the depends on xserver-xorg- input,video -$ABI virtual packages, but where drivers now depend on the appropriate server ABI. (Thanks to Alexander Kurtz for his feedback.)

It ain t what you don t know that gets you into trouble. It s what you know for sure that just ain t so
attributed to Mark Twain

There is a lot that I don t know about what goes on in my organization. This isn t only because I can t observe everything, or because it s too complex, or because I make mistakes. These are all true, of course, but they re also obvious. Much more devious is the way the flow of information to me is distorted. It s distorted by me, and by the people around me, whether any of us are aware of it or not. This is most apparent in considering how people feel about their managers: this is why I have a deeply flawed view of what it s really like to work for me. My theory is that power bends information like gravity bends light. The effect is more pronounced with people of greater mass (more authority), and lessened with distance (less direct influence). The more directly you influence someone else s fate, the more it is in their self-interest to be guarded around you. This means that the people closest to you, who you receive the most information from, may have the most difficulty being open with you, especially if it s bad news. It also means that the higher your standing in the corporate hierarchy, the more influence you wield, the more people are affected by this. Pretty scary, right? Some managers respond to this terrifying reality by trying to collect more information. They ll quietly cross-check what people are telling them, asking people in different levels of the organization, routing around managers, hoping to get the real story . This usually backfires, because it signals distrust to the people involved and makes the distortion worse. Another common response is to check in constantly, trying to monitor and control the work as closely as possible (so-called micro-management). This is even worse; not only does it signal distrust, but managers who do this become more personally attached to outcomes, and lose perspective on progress and quality due to information overload, self-enhancement bias, and neglect of managerial work. The more it becomes your work rather than the team s, the harder it is to see it objectively. So what s a better way to respond to this phenomenon? Here s what I try to do:

• Accept it You ll never have certainty about what s happening, so get used to it, and don t let it paralyze you. Learn decision making strategies which cope well with information noise, and allow you to experiment and adapt.
• Admit it Everyone else knows that you have this distortion field around you. If you pretend it isn t there, you ll appear deluded. Acknowledge that you don t know, don t understand, and can t control.
• Trust The more you trust someone, the more they trust you. The more someone trusts you, the more confident they can be in telling you what they think. Be grateful for bad news, and never shoot the messenger.
• Delegate Enable people with a less distorted view of the situation to make local decisions. Don t make people wait for information to propagate through you before acting, unless there is a clear and sufficient benefit to the organization.

I was inspired to think and write about this today after listening to Prof. Robert Sutton s speech at the California Commonwealth Club, which Lindsay Holmwood shared with me.

A few months after starting the NM process, I have just been accepted as a Debian Developer. My account name is simply: julien I have been a Debian user for about 10 years now, and have begun contributing to Debian in 2005. I have then been accepted as a Debian Maintainer in 2007. This post is mainly to thank:

• all my sponsors: Christoph Haas (haas) , Lo c Minier (lool), Free Ekanayaka (freee), Maximiliano Curia (maxy) and Micah Anderson (micah),
• my advocate: Matthijs M hlman (matthijs)
• my AM (who actually make it happen in a really short time frame, thanks a lot to him): Xavier Oswald (xoswald)
• all people who helped me during the process, to name a few: Christoph Berg (myon), Enrio Zini (enrico), Peter Palfrader (weasel)

Also thanks to all people who have already sent their congratulations, it makes me very proud!

I had been planning to write today about my great uncle Milt Goerzen. Milt passed away last Thursday after a long struggle with dementia, and his funeral was this morning. I was there, and was inspired by a few things I heard. But that will have to wait, because today brought one of those few moments in life that s a sense of an impending possible great loss. I can remember two others: one was when Terah passed out, and the other was when we heard that our place was on fire and our house had burned down (it turned out the house hadn t, but much of the rest had). I got a call during Milt s funeral. I didn t answer because I was, well, at a funeral, and the phone was on vibrate. When I had the chance to check the voicemail, it went something like this: I think we have an emergency with Jacob. He got run over by a tractor. He says he s OK, but I m taking him to the doctor right now. I tried to return the call, but cell phone reception wasn t cooperating. The most I got was he s OK . It s hard to describe how a moment like that feels. My mind jumped to telling Jacob I love you , and how lately when he hears that, he will snuggle in for a big hug, and say, Dad, I love you toooooooooo! On the one hand, I heard the he s OK part, and on the other hand I couldn t forget the tractor running over him part, and my mind leapt at the worst. It turns out that, while I was at the funeral, Jacob had been standing on his usual spot on the tractor, sort of to the side of the driver. He was enjoying himself like usual. The tractor hit a large hole that wasn t really visible. The combination of the jolt and the dip the tractor took towards Jacob s side knocked him off and he went directly under the big rear wheel before the tractor could be brought to a stop. I caught up with him and his grandpa after he had seen the doctor and just as he was being admitted to the hospital. He saw me and crawled over, making his sort of sad and scared sound he sometimes doesn t want to verbalize things when he s in that mood. I held him close and he seemed to appreciate it. He had to have blood drawn, and he was scared of that. I remembered his inquisitive mind, and reminded him how much he liked watching the tube fill up with blood last time he had a blood test (which he calls a blood shot ). That wasn t helping, until the actual blood test started. He cried when the needle went in, but then calmed down as the nurse, getting into the act, pointed out that there was blood filling up the tube. Hmmm! said Jacob. Then she gave him a band-aid. It has an airplane, said the nurse. Um-hmm! said Jacob. I pointed out that it looked like the airplane we were on when we flew home from New York. Jacob got a big smile and said, Yes, it IS that one! He got a sticker there too. Then it was off for an x-ray to check for broken bones and a CT scan to check for internal injuries the tractor had gone right over his abdomen. He had to get an IV at the CT scan, which he certainly didn t like. After it happened, however, he found it very interesting especially when the nurses explained that they would give him a drink through the hose attached to his hand. After that, we went to his room, with orders for him not to eat or drink anything until it was clear he didn t have digestive problems. While we waited at various steps along the way, Jacob wanted to sit on my lap and watch train videos on YouTube on my phone. He loves train videos, and brought my phone s battery nearly to depletion through the course of the afternoon. Jacob eventually seemed to get back to a bit of his usual self. At one point, while Terah had made a run home to pack an overnight bag and grandpa ran some errands of his own, Jacob wanted to leave the room. He had gone exploring in the hospital with me before: when Oliver was born, and when Terah had her thyroid surgery. So this was something he just associated with the hospital. That and lemonade, which is free any time of the day or night in the cafeteria. So we went exploring, even ventured outside into a courtyard for a bit. He was walking fast and seemed good. We had several visitors: grandparents and his aunt and uncle. Jacob got a stuffed rabbit and a colorful bug box with windows (for putting bugs inside for observation). Eventually the doctor came by and gave us the results: the x-rays showed no problems. The labs showed some elevated liver enzymes, which he expected, but no serious trouble. The CT showed contusions on his lung and bruising on his heart which would heal completely in time. He allowed Jacob to have a liquid supper (so I quickly got him the lemonade he had been wanting while the nurses got him some Jello). The doctor examined Jacob, pushing at various places, asking Does it hurt here? No. Does it hurt here? No. Here? No. Are you hungry? Yes. Does it hurt here? No. He gave me a look that said: really? It doesn t hurt ANYWHERE? What could I do but shrug my shoulders? Jacob has some abrasions on his face, arms, and back, which will probably eventually hurt (and sure enough, about 10 minutes later he started getting a little pain when he tried to move, which the doctor checked out) Then the doctor said, I hope you know you have a walking miracle today. This is just amazing. You have some thanking to whatever guardian angels you like tonight all I can say about this is that the Lord must have had some other plan for him. There s no way he could have survived that. Jacob s doctor is one that we really respect: he s scientific in his analysis, cites studies as a matter of routine, doesn t prescribe antibiotics for things that he knows they have a small chance of helping, is common-sense about not over-treating things and yet always engaged in an emergency. That little speech from him was something I d never expected to hear from him. He went on to add that I always visit my sickest patients first. You were my last visit this evening, so that should tell you something. Any other kid as healthy as he is, I might discharge already but I m just not justified doing that with a boy that s, well, been driven over by a tractor this morning. He also wanted to monitor Jacob s progress throughout the coming day, especially his digestive system. They wanted to measure his urine output, which he, predictably, found to be very interesting. Terah said I think it is about 150 ml. Jacob said, No mom, it is closer to the two hundred line. Me: Since when does Jacob know about the number 200? Terah: I don t know . he s 4, where would he have gotten it? Between that, and using every opportunity to tell people that there were not one but TWO red light switches in the x-ray room, Jacob s definitely himself in some ways already. So, that feeling of some impeding great loss is gone, replaced by being more than a bit overwhelmed by how fortunate we were today. We also appreciate all the help we ve had with Jacob and Oliver today.

I would tell you about the phone call I had with a company where the CEO acknowledged that they were behaving in criminal activity in multiple jurisdictions but promised that they'd probably stop in a few weeks and so I shouldn't worry, but it seems that in the modern Internet I'm not allowed to because there were no independent witnesses and I haven't called the police, and also if I wanted people to respect my copyright I shouldn't have put my software on the internet where I'm just begging for it to be taken advantage of. Also, in future I won't be fixing any bugs unless they happen to me because you might just be making them up make my code look bad, and also you shouldn't accept any patches from me because I might by lying about things just to inflate my patch count and make myself look better at the expense of competing companies.

(for anyone missing the point: THIS IS A SERIES OF ANALOGIES INTENDED TO INDICATE THAT THIS ARGUMENT IS FACILE)

You re probably manipulating Debian packages everyday, but do you know what those files are? This article will show you their bowels Surely they are more than file archives otherwise we would just use TAR archives (you know those files ending with .tar.gz). Let s have a look! 1. It s two TAR file archives in an AR file archive! A .deb file is actually an archive using the AR format, you can manipulate it with the ar command. This archive contains 3 files, you can check it yourself, download any .deb file and run ar t on it:

$ ar t gwibber_2.31.91-1_all.deb
debian-binary
control.tar.gz
data.tar.gz

debian-binary is a text file indicating the version of the format of the .deb file, the current version is 2.0 .

$ ar p gwibber_2.31.91-1_all.deb debian-binary
2.0

data.tar.gz contains the real files of the package, the content of that archive gets installed in your root directory when you run dpkg --unpack . But the most interesting part which truly makes .deb files more than a file archive is the last file. control.tar.gz contains meta-information used by the package manager. What are they?

$ ar p gwibber_2.31.91-1_all.deb control.tar.gz   tar tzf -
./
./postinst
./prerm
./preinst
./postrm
./conffiles
./md5sums
./control

2. It contains meta-information defining the package and its relationships The control file within the control.tar.gz archive is the most fundamental file. It contains basic information about the package like its name, its version, its description, the architecture it runs on, who is maintaining it and so on. It also contains dependency fields so that the package manager can ensure that everything needed by the package is installed before-hand. If you want to learn more about those fields, you can check Binary control files in the Debian Policy. Those information end up in /var/lib/dpkg/status once the package is installed. 3. It contains maintainer scripts so that everything can just work out of the box At various steps of the installation/upgrade/removal process, dpkg is executing the maintainer scripts provided by the package:

• postinst: after installation
• preinst: before installation
• postrm: after removal
• prerm: before removal

Note that this description is largely simplified. In fact the scripts are executed on many other occasions with different parameters. There s an entire chapter of the Debian Policy dedicated to this topic. But you might find this wiki page easier to grasp: http://wiki.debian.org/MaintainerScripts. While this looks scary, it s a very important feature. It s required to cope with non-backwards compatible upgrades, to provide automatic configuration, to create system users on the fly, etc. 4. Configuration files are special files Unpacking a file archive overwrites the previous version of the files. This is the desired behavior when you upgrade a package, except for configuration files. You prefer not to loose your customizations, don t you? That s why packages can list configuration files in the conffiles file provided by control.tar.gz. That way dpkg will deal with them in a special way. 5. You can always add new meta-information And in fact many tools already exploit the possibility to provide supplementary files in control.tar.gz:

• debsums use the md5sums file to ensure no files were accidentally modified
• dpkg-shlibdeps uses shlibs and symbols files to generate dependencies on libraries
• debconf uses config scripts to collect configuration information from the user

Once installed, those files are kept by dpkg in /var/lib/dpkg/info/package.* along with maintainer scripts.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

19 comments Liked this article? Click here. My blog is Flattr-enabled.