Most of my talks are either talks about commandline basics (Commandline Helpers about GNU Coreutils and Findutils usage; Understanding Shell Quoting) or collections of small tips and tricks, e.g. about SSH, History Expansion, or commandline tools. Valentin Haenel called this second type of talks nugget talks . I like that term. My newest talk (German only so far, next occasion at the LUGS meeting in Zurich on 16th of December 2010) is such a nugget talk and is about useful but unknown tools. While preparing that talk I noticed that the amount of neat but less known tools I collected for possible inclusion into that talk would be enough for a whole day or so. I noticed that I ll never be able to give a talk about all that stuff. To not letting these tips rot in that file uncommented, I decided that I ll write (more or less) short blog postings about these tools, similar to and inspired by Myon s blog postings about Cool Unix Features as well as the no more existing or at least broken Debian Package of the Day and Debian Package a Day. While Myon mostly posted long-time but still unknown features, my postings will mostly cover useful but unknown packages available in Debian and most debian-derived distributions like grml and Ubuntu. Some postings may also just highlight some features of common tools or packages like e.g. GNU Coreutils. You can subscribe to these tips via RSS or just view all of them in your web browser at http://noone.org/blog/English/Computer/Debian/CoolTools/.

My telco Three have just offered me a deal on getting a new phone a couple of months earlier than my contract was supposed to expire, presumably they have some competition and want to get me locked into another 2 year contract a couple of months before anyone else has the chance.My current phone is a LG U990 Viewty [1] which I am reasonably happy with for the regular phone and camera functionality (apart from it being too slow to take a photo), it s on a $29 per month plan. I also have a 3G modem which is on a $15 per month plan for 1G of data per month for a total cost of $44 per month. As new phones have advanced client functionality (ssh, IMAP, etc) and have Wifi support for providing net access to a laptop there seems to be less need to have a separate phone and modem. So I am considering getting a high-end phone to replace the phone and modem, so while I don t want to pay a lot more than I currently pay, a $49 contract would be quite affordable and a $59 contract is something I can consider.What I need is a system with a good ssh client implementation, a high resolution screen (800*480 or better), preferably a slide out keyboard and an option to use a Bluetooth keyboard.The best option for the OS seems to be Android as it s based on Linux, it s moderately open, and it has a good range of applications. The Nokia N900 has been recommended based on features but a friend had a bad experience with a N900 that broke and didn t get good warranty support. Also the N900 doesn t have a digital compass (so can t do augmented reality). While I m primarily buying a phone for making phone calls, using the net, and being a ssh client I want to be able to do cool things like do Google searches on things that I photograph and have an annotated star map when I point my phone at the sky. Also as I m not using Windows or Apple phones for obvious reasons that leaves Android phones as the only suitable phones that are on offer from my Telco.I have checked some options for buying a grey-market phone, given that I need to get a more expensive phone contract to have the voice and data access I need the cost of buying a grey-market phone and having a no-phone contract would be unreasonable. So selecting a phone that s on offer by Three/Vodaphone seems to be the best option. Moving to another telco would be inconvenient as I would have to convince the relatives that I call often to switch as well (I get free calls to other Three/Vodaphone customers).I previously listed some phones that seemed good without regard as to where I could buy them [2] and some people wrote some really interesting and informative comments (thanks a lot!). But after considering all the options it seems that the costs of the various options force me to choose something that Three offers.Currently the best option from Three for an Android phone seems to be the HTC Desire HD [3]. It has a 800*480 screen, an 8MP camera with face-detection and geo-tagging, wifi, an accelerometer, GPS, and a digital compass. It also runs Android 2.2 (the latest release). Generally it has everything I want apart from a slide-out keyboard. It seems that Bluetooth keyboards are about $100 each, so I could buy such a keyboard and have options of taking just the phone, the phone and keyboard, or phone and laptop depending on how much I can carry and what I expect to be doing.Three PricesThe Desire HD is free on a $59 plan, or costs $15 per month on the $29 plan. So for $44 per month (the same as what I spend now) I can get a Desire HD! The down-side is that the $29 plan only allows 200MB of data per month and has an excess data fee of $0.50 per meg. My average usage has been about 300MB per month, I could reduce this a bit but I do occasionally have a month where I need a lot of data transfer. For an extra $8 per month I can get an additional 500MB of data transfer. That would give me a total cost of $52 per month for my phone, and I could get the same phone for my wife for $44 per month (I doubt that she would use the 200MB of data included). That would take a typical Three bill from $73 to $96.I might just wait a few months. The Viewty and 3G modem combination is working reasonably well, presumably there will be some better deals if I wait a while. At least now after considering all the options I could find and determining that a Desire HD from Three is the best option for me I can now evaluate any new options by comparing them to that.

• [1] http://etbe.coker.com.au/2009/05/31/lg-u990-viewty/
• [2] http://etbe.coker.com.au/2010/10/08/choosing-an-android-phone/
• [3] http://en.wikipedia.org/wiki/Desire_HD

For the last few years, I ve been a mostly happy customer of Sivit (now bought by Nerim). But recently, technical problems have become more frequent, and today, for the first time, a crash made me lose some data which was rather painful to restore from backups. Also, they are still stuck on with an ancient 2.6.16 kernel. So, I m looking into alternatives, and a promising one is Gandi hosting, based on virtual machines like Sivit.

• Would you recommend it for a mission-critical server?
• What s your uptime? When was the last time your server had an unscheduled outage?
• When was the last time you lost data because of Gandi?
• What are the limits due to the Xen-based hosting? Can you run your own kernel (like the squeeze one)? Can you build additional modules (like tun)?
• What else should I know?

Thanks!

I'm considering replacing our 5 year old 32" TV with a 40" Sony Internet TV, largely "just because" it has Google TV. That and I have spousal approval to get a new, bigger TV (it just has to be wall mounted). The dilemma is MythTV. It's currently still running on the Dell Dimension 3100 that I bought years ago, and connected via VGA to the TV. The Sony Internet TV is HDMI or nothing, so at the very least, I need to get a DVI-capable video card in my MythTV box. The more or less natural choice would be an NVIDIA card, despite them having a closed-source driver. At least it's well supported under Linux. The problem is, as far as I can determine, NVIDIA cards require at least a 300 watt power supply, and the Dimension 3100 has only a 230 watt power supply. So now I'm looking at having to replace the MythTV box. I'm currently running the front end and the back end on the same box, so it'd be a fairly simple case of splitting the back end from the front end, and just getting something new to be the front end. So now I'm in the market for something small, low-power, has a HDMI (or DisplayPort) interface, and enough grunt for HD playback. I'm wondering if the Boxee Box is the solution. Interface-wise, it has HDMI, so I'm good there, and I believe the marketing claims it can do HD playback. I just don't know how hackable it is. I think it's running Linux, so in theory this should be doable, so long as there isn't some weird hardware in it with a binary-only driver. For the price, it's probably worth just getting one to see. The annoying thing is, I have nothing in the house that is DVI or HDMI capable, so I have no way of testing this out prior to buying the TV.

During the weekend, I've found some time to improve documentation for Gammu. One of user accessible things which did lack documentation are native file formats used by Gammu. There is not that much of them as Gammu supports standard formats for most data (like vCard, vCalendar, iCalendar), but there are things where standard simply does not exists and we need to store that data as well. This is the case for backups (both data and SMS), where SMS backup format is used as well for files backend in Gammu SMSD. So I went through the SMS backup internals and wrote the documentation. While reading the code I of course discovered quite obvious bug, which was for some reason undiscovered for very long time.

Filed under: Gammu 0 comments Flattr this!

Having studied librtmp over the weekend, it doesn't drop into gnash as neatly as I'd hoped. Gnash already has classes to implement NetConnection and NetStream, which it makes sense to use - but librtmp is designed to replace the need for such classes to exist. So it implements certain higher-level responses to various calls from the server, that are necessary when downloading a stream. Gnash probably needs to hook in instead, and let the flash application decide what to do in these cases. So more work required, and possibly changes to librtmp in future - but I've started fixing up Gnash's RTMP code instead, for now, and have sent a couple of initial patches to Savannah. I don't think YouTube exercises these code paths, so they're a little rusty - I hope to make more progress through the week.

In the last years I noticed a growing trend of people pushing for "new" rules about what is appropriate or not for single developers or for the project as a whole. In too many cases even just considering these ideas to be an obvious fact... I prefer to not give specific examples because these would divert the attention from the main topic and would be affected by my own biases. At this point I believe it is useful to remember that all ethical issues which are not explicitly covered by the Social Contract are just the developers' own opinions. It may even be a good idea, but other developers are not and should not be compelled to agree with it no matter how good or important you believe it is. You are entitled to having your own ethics and even ranting about it on Planet Debian, but I am entitled to not caring at all without this making me a worse Debian Developer. Let's try to be grown ups and not be excessively annoyed by other people's choices. This is why I want to convey this simple message to the people who keep preaching about what is proper for me or for Debian: please fuck you. If I want to receive lectures about what is right or wrong then I surely know where I can find a priest. For some reason, now I see fit to mention that I have an Amazon wishlist...

A while ago I wrote about the new distcheck tool upcoming in dose3. I've recently updated the proposal on the debian wiki to reflect recent changes in the yaml data structure. The idea was to remove redundant information, to make it easier to read and at the same time include enough details to make it easy to use from a script. I'll write down a small example to explain the format. A package can be broken because of a missing package or because of a conflict. For a missing package we'll have a stanza like this : The first part gives details about the package libgnuradio-dev, specifying its status, source and architecture. The second part is the reason of the problem. In this case it is a missing package that is essential to install libgnuradio-dev. missindep is the dependency that cannot be satisfied is the package libgruel0 , in this case: libboost-thread1.40.0 (>= 1.40.0-1). The paths component gives all possible depchains from the root package libgnuradio-dev to libgruel0 . Notice that we do not include the last node in the dependency chain to avoid a useless repetition. Of course there might be more then on path to reach libgruel0. Distcheck will unroll all of them. Because of the structure of debian dependencies usually there are not so many paths. The other possible cause of a problem is a conflict. Consider the following : This is the general case of a deep conflict. I use an artificial example here instead of a concrete one since this case is not very common and I was not able to find one. To put everything in context, this is the example I've used (it's in cudf format, but I think you get the gist of it): The first part of the distcheck report is as before with details about the broken package. Since this is a conflict, and all conflicts are binary, we give the two packages involved in the conflict first. Packages f and e are in conflict, but they are not direct dependency of package a . For this reason, we output the two paths that from a lead to f or e. All dependency chains for each conflict are together. Again, since there might be more than one way from a to reach the conflicting packages, we can have more then one depchain. Another important upcoming change is distcheck (to be implemented soon) it the ability to check if a package is in conflict with an Essential package. In the past edos-debcheck always check the installability of a package in the empty universe. This assumption is actually not true for debian as all essential packages should always be installed. For this reason, now distcheck will check the installability problem not in an empty universe, but in a universe with all essential packages installed. This check is not going to be fool proof though. Because of the semantic of essential packages, despite is not possible to remove a package toutcourt, an essential package can be replaced by a non essential package via the replace mechanism. For example, poking with this feature I noticed that the package upstart in sid replace sysinit and it is in conflict with it. This is perfectly fine as it gives a mechanism to upgrade and replace essential components of the system. At the same time this does not fit in the edos-debcheck philosophy of checking packages for installation problems in the empty universe (or in a universe with all essential packages installed). At the moment we are still thinking how to address this problem (the solution will be in the long term to add the replace semantic in distcheck), but for the moment we will just provide an option to check packages w.r.t essential packages conscious the this can lead to false positives. This work is of course done in collaboration with the mancoosi team in paris. Dose3 is still not ready for prime time. We are preparing debian packages and we plan to upload them in experimental in the near feature.

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.

*blows the dust off his blog*

It's been quite awhile since I last wrote anything in this thing, so I guess its a good time as any, off the tails of UDS-N, to finally sit down and write something down. Since my last blog posting in May, I've been travelling around the world, attending conferences, and trying to represent both Ubuntu and Debian itself, and Canonical in all my travels. I was recently posted to China for a full month where I lived and worked out of an office, made friends with fellow Ubuntu users, and tech enthusiasts, had a wonderful time meeting with people with the Beijing Linux User's Group, and worked hard within my team at Canonical, and the legions of Ubuntu Developers to help make one of the best releases we've ever had.

As I was writing specs and drafting work items, I came to the point that I was reflecting on my own personal goals and growth in life. Two years and change ago, I was a struggling junior at Rochester Institute of Technology, a little less than two years ago, I started working full time with Canonical, and this year, I've gone and traveled to many places I've only dreamed about; Anchorage & Barrow, Alaska; Tampere, Finland; Prague, Czech Republic; and Brussels, Belgium, just to name a few. I packed up and lived in China for a month (an amazing experience, and I look forward to going back and visiting again sometime in the near future). Had you told the me of two years ago what I would be doing now, I'd probably think you were smoking something good.

One thing I've discovered in my life is that if you want to do something, you need to get out there and just ****ing do it. This may seem simple, but I think of the dreams a lot of people have that never seem to come to fruition. When I have an opportunity, I take it; going to Alaska was a dream I harbored for many years, especially entering the arctic circle, and heading to Barrow. That entire trip was booked on roughly four days notice, and the side trip to Barrow was planned the day before it actually happen. I don't regret any of it; it was one of the best things I ever done.

It brings me to what I consider the flux of this blog posting. For those who know me, I've had a goal of visiting every state within the United States. At this time last year, this map looked like this

As of two weeks ago today, this map looked like this:



Now, by the end of the day today, it will look like this:



The point I'm trying to make is if you want to do something, do it the first chance you get, or just don't do it; I say this because you never know when you will be able to do it again.

As for completing a life goal, well, it feels pretty amazing :-). I may write about that in a future blog posting ...

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!

Someone on Hacker News asks about the future of programming languages, and I realized that it's a pretty interesting topic. Here's my take on it: Programming languages are about people, and the compromises they may or may not make in order to communicate their intentions to computers. The technology in question may change, but there will likely always be people involved, and as long as that's true, looking at the problem through the lense of economics provides useful results. Therefore, looking at programming languages pretty much requires that you look at the economics of them:

• Network effects are important, but obviously don't squeeze out smaller languages entirely. I.e. it's good to be able to get libraries, find people to hire, books to read, friends to chat with about problems, etc... This means that future languages will have to seek out a critical mass of users.
• Since the times of Fortran, languages have been getting more efficient in terms of programmer time, because programmer time stays the same or gets more expensive, while computer time keeps getting cheaper, and language implementors keep getting better at making things fast under the hood. This means that languages of the future are likely to let you do more with less, all else being the same.
• Learning a programming language will continue to be a fairly involved process for most people, meaning that for many, it's more efficient to learn a few languages well and use them for as much as possible, rather than to try and find the 'perfect' language for each problem. This rewards general-purpose languages, compared to niche languages. This also rewards flexible languages that can be used in many different environments.
• Computers are only going to become more and more important, meaning that more people are going to want to develop the skills to work with them. Not all of them will be experts, and many may not know much, but have a vision for how a program could solve a particular problem in a field they are knowledgeable about. This means a low barrier to entry is important, because those novices will pick easier languages, become progressively more competent in them, and thus (network effects) contribute to their diffusion. Case in point: PHP. Future languages should be capable of solving hard problems, but should also make it easy to get started solving simple problems too.
• Working on languages is lots of fun, so even though there aren't necessarily monetary rewards, people will continue to play with and explore new ideas. I don't see there being a limited supply of new languages in the future.
• The costs of switching from established languages will continue to be high, so future languages will still need to interact with "legacy" languages like Cobol, Fortran, C, Java, and so on, that are so widely established in industry that systems written in them will be with us for a long time yet.

I wrote this in a hurry. Have I missed anything? How do these factors apply to languages you see emerging?

I've found some time to implement m-obex protocol based on documentation provided by samsyncro project. However I don't have any phone to test it, so any testers are welcome :-). The testing should be quite easy - just get current Git version of Gammu (either using git or use snapshots) and try to use commands which manipulate with contacts and calendar:

gammu getallmemory ME
gammu getallcalendar
gammu getmemory ME 1
gammu getcalendar 1
gammu addnew test.vcf
gammu addnew test.vcs

In case you have not yet used Gammu with your phone, the configuration for USB cable should look like:

[gammu]
device = /dev/ttyACM0
connection = at

And for Bluetooth:

[gammu]
device = address of the phone
connection = blueobex
model = mobex

Of course there is no guarantee that any of the commands will work, because all I could verify is that code compiles and looks correct. It might as well do something bad to your phone, so backup is recommended.

Filed under: Gammu 0 comments Flattr this!

If you want to see a really big Google Calendar, check out this calendar. Essentially, it is all the events from over 100 other calendars (all containing swing dancing events) merged into one, resulting in often more than 50 events every day, occasionally over 20 at the same time). The data is approximately the same that can be seen on this map; in fact I'm trying to move the data keeping from a custom database (which has superior filtering capabilities such as synonyms in text search) to just having Google keep the data for me (meaning it will eventually not require me to have an own web server for this). I'm doing some filtering such as removing events that don't have parseable geo information (I'm adding GeoRSS:where elements, in fact), some text to html conversion of the entry contents and filtering out inappropriate events via some regular expressions (e.g. only including "Swing" not "Ballroom" events from a calendar) There are still a couple of things to resolve. I'm not sure that recurrence exceptions are propagated properly to the combined calendar; the updates could work more incrementally, and I have to resolve some timezone issues due to the global nature of the calendar: I need to make sure the timezone information is preserved, since usually it makes more sense to give the events in local (to the event) time. P.S. sorry, the code is too specialized and needs cleanup, I won't share it yet.

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.

Now that we have KMS, it happens things go bad enough that when X goes down, one can no longer access any console to see what happened. Mainly, one can distinguish between two cases.

• The good one: the machine is still accessible over the network. Unfortunately, that requires having a spare machine to ssh into the first machine, but that means one can run dmesg, look into X logs, possibly run X inside gdb and see where it breaks (because glibc s backtrace isn t exactly an excellent tool to get the idea of what s going on and that s the tool used in X to print a backtrace in the log through a signal handler).
• The bad one: the machine is no longer accessible over the network. Likely, the kernel is in such a bad shape that one is never going to know what happened. Usually, writing logs to disc didn t happen, so logs won t magically show up at next reboot.

I m going to discuss the second case. There s a nice tool in the kernel which makes it possible to send kernel logs over the network. It s called netconsole. As far as limitations are concerned, one shall note that it s UDP only, and over Ethernet (in other words: no wireless). The good news is that it can usually make the last crucial lines available. Let s call the crashy machine a patient and the logging machine a doctor. One should keep in mind that if something goes wrong while configuring the netconsole module, it can be unloaded at anytime through:

sudo modprobe -r netconsole

Easy case: on a local network Here s an example: Patient s IP is 192.168.0.1, doctor's IP is 192.168.0.2. Doctor setup What one needs on the receiving side: only netcat. A tiny warning, there are several implementations. Here s the appropriate syntax:

# netcat-traditional:
nc -l -u -p 6666   tee ~/netconsole.log
# netcat-openbsd:
nc -l -u 6666   tee ~/netconsole.log

The nc command is handled through the alternatives system, one can use update-alternative --config nc to pick the appropriate one if several netcat-* packages are installed. To list the current one, an easy way is readlink -f $(which nc). Using tee means that incoming messages are going to be printed, both to the standard output and to the specified file. Running as non-privileged user is sufficient. Patient setup Now, to have the patient send stuff to the doctor, a simple modprobe is needed:

sudo modprobe netconsole netconsole=@/,6666@192.168.0.2/

What happens here? One requests the netconsole module to be loaded, and one specifies the parameters. Details can be read in the Linux kernel documentation (Documentation/networking/netconsole.txt), but concentrating on the points of interest here:

• 192.168.0.2: The doctor s IP.
• 6666: The UDP port to which packets are sent. 6666 is the default and can be omitted.

That s all! On the doctor side, one should see something along those lines:

[2920549.188090] console [netcon0] enabled
[2920549.188102] netconsole: network logging started

Slightly harder case: over internet Because one might not have a second machine handy, it s also possible to go through a router and send stuff across the internet. Here s an example: Patient s IP is 192.168.0.1, connecting to internet through a router, which IP is 192.168.0.254. The doctor, available over the internet, is 192.0.32.10. Doctor setup Exactly the same as in the previous case. The main issue one can run into is firewalls at this point. That s why one may want to switch from the default 6666 port to another one which wouldn t be filtered. One can think of 53 (DNS), but that means running nc as root since it s a privileged port (below 1024). Patient setup Routing is also possible, but that requires an extra parameter: the MAC address of the router. To obtain it, one can use the arp command:

/usr/sbin/arp 192.168.0.254

Supposing it returned the 01:02:03:04:05:06 address, loading the module becomes:

sudo modprobe netconsole netconsole=@/,6666@192.0.32.10/01:02:03:04:05:06

Now, if you re running into firewall-related issues, you can change the source for the UDP packets. The default is 6665, but assuming you want to send from an unfiltered 1234 port, that becomes:

sudo modprobe netconsole netconsole=1234@/,6666@192.0.32.10/01:02:03:04:05:06

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.

I've always loathed cheap particle board and peg bookcases, and when I broke one while reorgaising the living room at the Hollow today, I finally found a good use for them. They're great fun to chop up with an axe, and make for a very hot fire in the stove later. I released git-annex 0.03 today. The main improvements are being able to configure the backend to use on a per-extension basis in .gitattributes, a fsck subcommand that will find dangling annexed content, and bugfixes, including massive memory use savings. The big feature under development next is an idea Josh Triplett and I batted around; a way to checkout annexed files to edit their contents. Today I also got the radio working well here. Set up a car radio with a 40 foot wire for an antenna, and I finally got it almost static free. Pity that running a nslu2 on the same power circuit causes interference, so I am not able to use that to feed in music via the radio's AUX jack yet, which is the eventual plan. And the radio's powered USB outlet is wasted, I had hoped to run the nslu2 from that. Seems I can run the radio for 9 hours and still have plenty of solar power, even this time of year. Wish it were colder..

I blogged back in August about my frustration in finding a new laptop that had everything I was looking for. I'd figured I would eventually end up with the Toshiba R700, given my positive experiences with the R200. The lack of stock proved a problem, and the differing specs between the US and UK models also annoying. I started trying to source the Sony and finally found the HD model in stock from Vizik, but the helpful people there talked themselves out of a sale by saying the Full HD was too much for 13" (they also failed to have a 3G Full HD model).

I'd only brought the EEE 901 to the US with me, so after a month of that as my only machine at home I was starting to get a bit fed up; the keyboard is too small for constant use and it crawls when subjected to my normal usage patterns rather than just used as a lightweight network terminal. So it became obvious I was going to have to compromise on what I wanted. And if I was doing that I wanted something a lot cheaper, as I thought I may potentially want to upgrade sooner than usual.

In the end I've gone with an Acer Aspire TimelineX 1830T. It cost about a third of what the more fully featured laptops I was looking at were going for, which was a considerable bonus. The 2 things I ended up compromising on were the SSD and 3G support. And the name; I wasn't entire sure about what the build quality would be like.

As it turned out I needn't have worried; it appears to be perfectly well constructed - no noticeable flex while typing, solid enough, yet still fairly light. The keyboard is pleasant to use (admittedly I'm coming from the EEE, but it's a good size and responsive enough for me). I'm a bit uncertain about the touchpad, which has no physical separation from the rest of the case, but it's been ok so far. I miss the multitouch of the EEE, but it looks like there are some patches for Synaptics multitouch flying around that might eventually lead to useful support. I've ended up with a Core i5 470UM at 1.33GHz - what I ordered was the i5-430UM at 1.2GHz (and that's what the box/label on the laptop said), but I'm not complaining at the slight speed bump. It's fine for my needs. The 1366x768 screen is lovely, even in 11.6". Bright, if sometimes a little too shiny..

Installing was of course fun; it reminded me of when I got the R200 - neither the wifi nor wired interfaces were supported by the Debian installer, even from testing. I found a patch to get the (Atheros) LAN working (and have filed #599771 about potentially getting the support into squeeze's kernel) and that got me up and going. The wifi is a Broadcom BCM43225; too new for the old Free driver and the recently released Broadcom Free code causes the machine to instantly crash (I understand it has some SMP issues). So I'm stuck with the binary blob wl driver from broadcom-sta for now. I have hopes the Broadcom driver will improve though; it seems to be getting active love in the staging tree. The graphics are Intel, so well supported. And I'm getting at least 4 hours of battery life out of it, which I think could be improved with some tweaking.

So, er, yeah. Not what I set out looking for, but considerably cheaper and actually seems to meet my needs pretty well - it had its first weekend away trip this weekend and performed admirably; not too heavy in my hand luggage, decent battery life and no worries about it being too flimsy to survive. I'm still surprised it's an Acer...