On the 5th of November Jono Bacon wrote a blog post titled MAKING OUR WORLD MORE RESPECTFUL [1]. He then registered the domain OpenRespect.org for his manifesto [2].Aaron Siego supports the general concept of being more respectful while listing some of the practical problems that occur in a multi-cultural world [3]. If you read nothing else about this issue I recommend reading Aaron s post (which I summarised very poorly, I can t think of a good one-sentence explanation).Sam Varghese wrote an article suggesting that it was an attempt to deflect criticism from Ubuntu [4]. I think that Ubuntu receives a lot of unfair criticism, but don t think it s really relevant to the issue at hand. Sam criticises some of the Open Respect supporters for failing to show respect in the past.Jono wrote a follow-up blog post titled REFLECTIONS ON RESPECT [5], in that post he said Sometimes we were disrespectful, and frankly, sometimes we were also inadvertently assholes. We never set out to be assholes, but we did set out to be edgy in a satirical way, but we sometimes went too far and I apologize for that. But you know what, we all grow and mature in different parts of our lives about his past LugRadio work. Maybe instead of focusing on being respectful of others it would give more benefit to focus on how to apologise, back down, and move on after being disrespectful. It seems that the situations of epic disrespect tend not to be one-off incidents but are instead arguments of greatly expanded scope that arose from someone refusing to admit any error after doing something that is considered to be offensive. [Someone has registered OpenApology.org, just in case you were wondering.]Maybe advocating Rogerian Argument would be another way of reducing some of the problems in the community.Finally Kirrily wrote an insightful post about the ineffectiveness of discussing offensive things [6]. In terms of issues such as Feminism (which Kirrily uses as an example and which is also a matter of significant interest for her) discussions about offense apparently tend to end up being about the person who was offended rather than the person who might be described as acting in an offensive manner. She suggests using terms such as marginalised, belittled, stereotyped, frustrated, humiliated, threatened, patronised, silenced, intimidated, misrepresented, etc instead. It seems to me that there may be a similar issue with respect . Objective claims about people being dismissed, ignored, patronised, etc can be evaluated more easily than a claim about being disrespected.

• [1] http://www.jonobacon.org/2010/11/05/making-our-world-more-respectful/
• [2] http://openrespect.org/
• [3] http://aseigo.blogspot.com/2010/11/commonality-and-community.html
• [4] http://www.itwire.com/opinion-and-analysis/open-sauce/43196-openrespectorg-a-bid-to-deflect-criticism-of-ubuntu
• [5] http://www.jonobacon.org/2010/11/17/reflections-on-respect/
• [6] http://infotrope.net/blog/2009/08/05/action-and-reaction-on-avoiding-offense/

Recently, I was considering the following set of statements: Vector graphics are great, especially in print. Program documentation needs screenshots. Usual screenshots are not bitmaps. Some programs use gtk. Gtk uses Cairo to render most of its display. Cairo can generate PDF. PDF is a vector graphics format.
And while I was doing so, for some reason, I thought: Wouldn t it be great if I my gtk programs could generate vector PDF files of their screen content? And after some experimentation, I was able to extract this PDF file from the buttonbox example program (see here if you do not see anything below): This works without any modification to the original program. Instead, I am loading some code using LD_PRELOAD that overrides the cairo_xlib_surface_create function and creates a PDF surface instead. It also monitors calls to XCopyArea to observe where on the window gtk (gdk actually) paints the resulting image. Then I combine these PDF files (6 in this example, theoretically a lot more) using a latex document and I must say, the result is pretty good for a start: All lines are vector lines, the text really is text (and not just rendered pixels), so you can actually copy n paste from it. Of course this is but a proof of concept and has several problems:

• You can not use the program with my library loaded, as all output is redirected. A solution would be to create a proxy cairo surface that renders both on-screen and to the PDF file, or to make the library react to a signal and only start intercepting the calls when the image has arrived.
• You need a gtk theme with a cairo-using engine such as Murrina, because
  
• any drawing done directly with gdk is lost. This includes icons, but also the clearing of parts of the screen. At the moment, all is just put on top of each other.
• It is not a turn-key tool.

I don t think I ll fix that myself, as I had my fun. But maybe it can inspire a more useful tool exploiting this idea, and maybe there are cleaner approaches (for example special gtk theme engines, or by patching gtk).

I have travelled quite a lot this year. Quite literally around the world, and more. Also, I've lived in three countries this year. All of this has resulted in my subconscious being quite unsure of where I am. At various times this past week I have felt, just for a moment, I was back in Finland, or in Wellington, or New York, or Los Angeles. Most of the time I feel like I'm in Edinburgh, of course. It's just that in those brief moments I am quite convinced I'm somewhere else. For example, Soile brought home some flowers the other day. For a second I was happy that spring had arrived, because we were in Wellington. I wonder if there's a name for this? (I should not ask such questions in public. "Insanity" is going to be the most common suggestion.)

You may wonder how I manage to write one Useful but Unknown Unix Something blog posting per day. Well, I don t. I write them in bursts, but don t want to flood Planet Debian and Planet Symlink with more than one such posting a day. The first bunch of postings were mostly slides (or part of a slide plus what I tell while showing the slide) from my Unknown but Useful Unix Tools talk and written somewhen last week. And this blog posting and yesterday s blog posting were written in a row, too. What does that have to do with Unix commandline tools? Well I use Blosxom as blogging engine and it s based on simple text files lounging around in some directories, and the last modification time stamp is the posting s date which is cached after first time seen by the entries_index plugin so that I can fix typos without resetting the posting s release date. Postings with a modification date in the future won t be shown before that time. So how do you set the last modification date to a date in the future? With touch from GNU Coreutils of course. Like date , touch also knows the option -d to explicity set a date and time instead of using the current date and time. Now in my humble opinion the cool feature is that you can easily describe dates by giving touch values like now + 1 hour , 12:00 tomorrow or so:

$ touch bla
$ ls -l
total 0
-rw-r--r-- 1 abe abe 0 2010-11-23 22:59 bla
$ touch -d 'now + 1 day + 23 hours - 42 minutes' bla
$ ls -l
total 0
-rw-r--r-- 1 abe abe 0 2010-11-25 21:17 bla
$

To see all the possibilities you have to describe relative dates with touch , date , and maybe other GNU Coreutils tools, check that you have info installed and call:

$ info '(coreutils.info.gz)Relative items in date strings'

Oh, and this whole story about setting modification dates manually to arbitrary values also means that the Tattletale Statistics: Blogtimes November 2010 image in my blog s side bar is absolute nonsense, at least this month. Well, never trust any statistic you haven t faked yourself. ;-) But on the other hand, the dates in the example may give a hint when I really wrote that blog posting. Or not. ;-) And I wonder what my backup tools think about last modification times in the future. Well, they probably only check for modification dates newer than last backup and therefore should be fine. *phew*

Since people seem to like it, I ll be trying to publish some news about ongoing work on the XSF side, on a (possibly) regular basis. Let s have a look at what happened since last time I blogged about X in Debian, mostly by checking what appeared in my =debian-x mailbox. Debian XSF News #1

• mesa 7.9 was uploaded to experimental by Julien Cristau.
• Jurij Smakov uploaded a bunch of xserver-xorg-sun* drivers to experimental for us.
• I started a debian/xsf-tools.git repository to gather some tools for people wishing to work on X-related packages. For now it contains the usual tagging script, an mrconfig file to ease downloading/updating all XSF packages, thanks to the mr tool, and some bits of documentation. I also added the git URL to the upstream repositories to debian/watch* for all packages.
• Christopher James Halse Rogers started a discussion about the Ubuntu plans for Natty release. This is mostly about DRI, and unfortunately, I haven t digged into mesa yet, but thankfully we had some answers from upstream there.
• I uploaded many xfonts-* packages, prepared by Julien Cristau.
• I uploaded many x11-* bundles as well. Why are we creating bundles? Because there are many tiny applications, which (from the distribution point of view) don t deserve their own package. For example x11-apps contains toys like xclock, xeyes, or xlogo.
• I uploaded many lib* packages, plus pixman. When there were no fundamental changes (as in: no need for an shlibs bump, which could prevent some packages from migrating), those were uploaded to unstable, others went to experimental.
• Some cherry-picked patches were added to libx11, from a stable branch. The 2:1.3.3-4 version has been unblocked for squeeze, and brings support for Compose O A and for Compose \ o /.
• I also reverted the removal of the (famous?) apple:badmap and apple:goodmap options for macintosh keyboards in xkeyboard-configuration (which produces the xkb-data binary package), thanks to a bugreport from Yves-Alexis Perez; it s been unblocked for squeeze as well. If someone notices an inversion of those keys after the upgrade, that s probably because one of those options was added at some point, was ignored and unnoticed, and finally taken into account. Depending on the case, it s sufficient to switch to the other one, or to remove it entirely.
• Many bug submitters were pinged by Julien Viard de Galbert. But another report should appear soon, following TXBW1 and TXBW2.
• More drivers were updated to their latest upstream versions, and uploaded to experimental.
• Thanks to an xserver-xorg-video-mga user (Ferenc W gner), we were able to extract and apply a patch from launchpad s #292214 to fix the dual head breakage. Since we haven t seen any complains since then, we ll probably ask for an unblock for squeeze.

What are the XSF plans?

• Keep close track of upstream work, possibly contributing there. We re mostly up-to-date with the RC1 for X11R7.6 and it d be nice to keep it that way, but that requires time/work.
• Keep on answering new bug reports quickly, before bug reporters vanish or switch to another system (a broken X can trigger this kind of reaction).
• Keep on pinging older bug reports. Anyone is welcome to join and help, there s no high profile required to do so, as confirmed by Julien Viard de Galbert.
• To make it easier, it would be nice to have some documentation written down, instead of relying on everyone s own memory. There s a lot of wiki pages about X in Debian, but they might be outdated, incomplete, or inaccurate. Building up some consistent documentation should help people understand how they can contribute, and how to do so.
• It d be nice to have some documentation targeted at users as well, so refreshing the old XSF FAQ would be welcome, as well as shipping it in some package for offline use.

Colin Watson is not a high-profile Debian figure, you rarely see him on mailing lists but he cares a lot about Debian and you will see him on Debconf videos sharing many thoughtful comments. I have the pleasure to work with him on dpkg as he maintains the package in Ubuntu, but he does a lot of more interesting things. I also took the opportunity to ask some Ubuntu specific questions since he s worked for Canonical since the start. Read on. My questions are in bold, the rest is by Colin. Who are you? Hi. I m 32 years old, grew up in Belfast in Northern Ireland, but have been living in Cambridge, England, since I was 18. I m married with a stepson and a daughter. I became interested in Debian due to the critical mass of Debian work happening in Cambridge at the time (and perhaps more immediately because my roommate was running Debian: hey, what s that? ), started doing random bits of development in 2000, and joined as a developer in 2001 (a really exciting time, with lots of new people joining who became integral parts of the project). I d only really been intending to do QA work and various bits of packaging around the edges, and maybe some work on the BTS, but then Fabrizio Polacco died and I took over man-db from him, and it sort of snowballed from there. I graduated from university shortly before becoming a Debian developer. I worked for a web server company (Zeus), then a hardware cryptography company (nCipher), before moving to work for Canonical in 2004, since when I ve been working full-time on Ubuntu. By this point, I suspect that going back to work in an office every day would be pretty tough. What s your biggest achievement within Debian or Ubuntu? One thing I should say: I rarely start projects. Firstly I don t think I m very good at it, and secondly I much prefer coming on to an existing project and worrying away at all the broken bits, often after other people have got bored and wandered off to the next new and shiny thing. That s probably why I ended up in the GNU/Linux distribution world in the first place, rather than doing lots of upstream development from the start I like being able to polish things into a finished product that we can give to end users. So, I ve had my fingers in a lot of pies over the years, doing ongoing maintenance and fixing lots of bugs. I think the single project I m most proud of would have to be my work on the Debian installer. I joined that team in early 2004 (a few months before Canonical started up) partly because I was a release assistant at the time and it was an obvious hot-spot, and partly because I thought it d be a good idea to make sure it worked well on the shiny new G4 PowerBook I d just treated myself to. I ended up as one of the powerpc d-i port maintainers for a while (no longer, as that machine is dead), but I ve done a lot of core work as well: much of the work to put progress bars in front of absolutely everything that used to have piles of text output, rescue mode, the current kernel selection framework, a good deal of udev support, several significant debconf extensions, lots of os-prober work, and I think I can claim to be one of the few people who understands the partitioner almost top to bottom. d-i is the very first thing many of our users see, and has a huge range of uses, from simple desktop installs to massive corporate deployments; it s unspeakably important that it works well, and it s a testament to its design that it s been able to trundle along without actually very much serious refactoring for the best part of five years now. I have a soft spot for man-db too. It was my first major project in Debian, starting out from an embarrassingly broken state, and is now nice and stable to the point where I recently had time to spawn a useful generic library out of it (libpipeline). What are your plans for Debian Wheezy? d-i has a lot of code to deal with disks and partitions. Of course a lot of it is in the partitioner, and for that we use libparted so we don t have to worry very much about the minutiae of device naming. But there are several other cases where we do need to care about naming, mainly before the partitioner when detecting disks, and after the partitioner when installing the boot loader. Back in etch, we introduced list-devices , which abstracted away the disk naming assumptions involved in hardware detection. In wheezy, I would like to take all the messy, duplicated, and error-prone code that handles disk naming in the boot loader installers, and design a simple interface to cover all of them. This has only got more important following the addition of the kFreeBSD and Hurd d-i ports in squeeze, but it bites us every time we notice that, say, CCISS arrays aren t handled consistently, and it s a pain to test all that duplicated code. I d also like to spread the use of libpipeline through C programs in the archive, which I think has potential to eliminate a class of security vulnerabilities in a much simpler way than was previously available. If you could spend all your time on Debian, what would you work on? I would love to systematically reduce the need for the current mass of boot loaders. There s a significant cost to having so much variation across architectures here: it s work that needs to be done in N different places, the wildly differing configuration means that d-i has to have huge piles of code to manage them all differently, and there are a bunch of strange arbitrary limitations on what you can do. The reason I m working on GRUB 2 is that, in my view, it s the project with the best chance of centralising all this duplicated work into a single place, and making it easier to bring up new hardware in future (in a way that doesn t compromise software freedom, as many proprietary boot loaders of the kind often found on phones do). Of course, with flexibility tends to come complexity, and some people have a natural objection to that and prefer something simpler. The things I don t quite have time to do here are to figure out a coherent way to address the specific over-complexity problems people have with the configuration framework while still keeping the flexibility we need, and to do enough QA and porting work to be able to roll out GRUB 2 at installation time to all the Debian architectures it theoretically supports. What s the biggest problem of Debian? Backbiting, and too much playing the man rather than the ball. With one or two honourable exceptions, I ve largely stopped reading most Debian mailing lists since it just never seems a productive way to spend time compared to writing code and fixing bugs; and yet I m conscious that they re one of the primary means of communication for the project and I m derelict in not taking part in them. I do find it a bit frustrating that people are seen primarily in terms of their affiliations. I suppose it s natural for people to see me as an Ubuntu guy , but I don t really see myself that way: I ve been working on Debian for nearly twice as long as I ve been working on Ubuntu, and, while I care a great deal about both projects, I ve put far more of my own personal time into Debian and I try to make sure that a decent number of the things I m involved with there aren t to do with work. Work/life separation is a good thing, not that I m very good at it. Generally speaking, when I m working on Debian, I m doing so as a Debian developer, because I want Debian to be better. When that s not the case, if it matters, I try to indicate it explicitly. You re working for Canonical since Ubuntu s inception. If you were Mark Shuttleworth, is there something that you would have done differently? We had many good intentions when we founded Ubuntu. We also had a huge amount of work to deliver, to the point where it wasn t at all clear whether it would be possible (the warty release was named based on the expectations of it, after all, and came out much more usable than we d dared to hope). In hindsight, it might have helped to be quieter about our good intentions, so that we could exceed expectations rather than in some cases failing to meet them. That might have set a very different tone early on. (Personally, I m happy I m not Mark. The decisions in my office are much easier to take.) It seems to me that the community part of Ubuntu is much more eager to cooperate with Debian than the corporate part. It s probably just that more and more Canonical employees are not former Debian contributors. Do you also have this feeling? Are there processes in place to ensure everybody at Canonical is trying to do the right thing towards Debian cooperation? Just to be clear, I m wearing my own hat here which, ironically, is a fedora rather than a company hat. It makes sense for Canonical to be taking on more non-Debian folks; after all, we can t simply hire from the Debian community forever, and a variety of backgrounds is healthy. As you say, it may well be natural that Ubuntu developers who don t work for Canonical are more likely to have a Debianish background, as it tends to take something significant to get people to switch to a very different family of GNU/Linux distributions, and changing jobs is one of the most obvious of those things. Certainly, there was a definite sense among the early developers that we were all part of the Debian family and cared about the success of Debian as well. As Ubuntu has developed its own identity, people involved in it now tend to care primarily about the success of Ubuntu. At the same time, pragmatically, it s still true that getting code changes into Debian is one of the most economical ways to land them; changes made in Debian or upstream land once and tend to stay in place, while changes made only in Ubuntu incur an ongoing merge overhead, which is not at all trivial. In many ways it s human nature to try to fulfil your immediate goals in the most direct way possible. If your goal is to deliver changes to Ubuntu users, then it s natural to concentrate on that rather than looking at the bigger picture (which takes experience). Debian developers often fail to send changes upstream for much the same reason, although there s more variation there because they re normally working on Debian of their own volition and thus tend to have wider goals; the economics are more or less parallel though. Thus, I think the best way to improve things is to make it the path of least resistance for Ubuntu developers to send changes to Debian. We re already seeing how this works with the Ubuntu MOTU group; if you send a patch for review, or work on merging a package from Debian, very often the response includes have you sent these changes to Debian? . We re working on both streamlining our code review through a regular patch pilot programme and requiring more code review for changes in general, so I think this will be a good opportunity to ask more people to work with Debian when they propose changes to Ubuntu. For myself, this may be obvious, but I notice that I m much better at getting changes into Debian when I already have commit access to the Debian package in question. All the work on improving collaborative maintenance in Debian can only help, for Ubuntu as well as for everyone else. It doesn t make so much difference for large changes that require extensive discussion, but there are lots of small changes too. Canonical is upstream of many software projects (unity, indicators infrastructure, etc.). Why aren t those software immediately packaged in Debian? Do you think we can get this to change? I m not sure what the right approach is here, particularly as I haven t been involved with much of that on the Ubuntu side. I suspect it would be helpful to look at this in a similar way to Ubuntu changes in general. It s understandable that those developers have getting changes into Ubuntu as their first goal. And yet, having code in Debian offers a wider, and often technically adept, audience, and most developers like having their code reach a wider audience even if it s not their first priority, particularly if that audience is likely to be able to help with finding problems and fixing bugs. It should be seen as something beneficial to both distributions. The hardest problems will be with things that aren t merely optional add-ons (which should generally be fairly non-controversial in Debian, given the breadth of the archive in general the existence of things like bzr and germinate as Debian packages was never a hard question), but which require changes in established packages. For example, gnome-power-manager in Ubuntu is built with application indicator support, and that s an important part of having a good indicator-based panel: a lot of the point of indicators is consistency. Since I do very little desktop work myself, I don t know exactly what would be involved in making it possible to choose this system based on a Debian desktop, but I think it s probably a bit more complicated than just making sure all the new packages exist in Debian too. Obviously you have to start somewhere. Is there someone in Debian that you admire for his contributions? Christian Perrier is absolutely tireless and has done superb things for the state of translations in Debian. And Russ Allbery, even aside from his fine ongoing work on policy, Lintian, and Kerberos, is a constant voice of sanity and calmness. Release management is incredibly hard work, as I know from my own experience, and anyone who can sustain involvement in it for a long period is somebody pretty special. Steve Langasek and I got involved at about the same time but he outlasted me by quite a few years. He deserves some kind of medal for everything he s done there.

---

Thank you to Colin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

using GNOME with Awesome without die trying I'm an avid GNOME user, but I don't want to give up tiling due to that. After 1.5 years with xmonad+GNOME, I've decided it was about time to give Awesome another try. Last time I tried, integration with GNOME was really sub-optimal; in particular I've been it by the showstopping (for me) issue that it was not possible, back then, to disable Awesome systray in favor of GNOME's. Nowadays, GNOME+Awesome integration is much better. It's very easy to disable all you don't want of Awesome (including systray) to rely upon corresponding GNOME desktop components (check my rc.lua for an example). Still, by renouncing Wibox in favor of GNOME Panel, you (used to) lack some features: (1) the ability to monitor the current layout, (2) (GNOME) run application prompt, and (3) Lua code prompt. It is to overcome these limitations that I've hacked GNOME Awesome Applet. Version 0.1.0 is now available for download from the homepage. It's beta-quality and it's the first (hopefully last?) GNOME Applet I've ever written, you know the drill. Feedback, bug reports, features requests, and code patches are more than welcome. Enjoy!

Guy Deutscher wrote an interesting article for the New York Times about how language shapes how we think [1]. The example of people who have no language construct for self-sentered directions and how they describe things is particularly interesting.TED published an interesting interview with Shaffi Mather the founder of India s first organised ambulance service (with differential pricing based on ability to pay) [2]. He also talks about founding schools in small towns and his BribeBusters.com company.World Changing has an interesting article about a legislative change in California that allows car-sharing of personal vehicles [3]. The concept is that if you own a car that you don t use most of the time (as is usually the case) then you can contract with a car-share company to share it to others when you don t need it. This saves the car share company from the capital expense of owning cars and thus allows them to place cars in remote locations that wouldn t otherwise be financially viable (IE the street in front of random people who sign up). The person who owns the car may get about $2 per hour for the time when it s rented. The car owner gets to specify when the car may be available.Charles Stross wrote an entertaining and informative rant about Steam-Punk [4]. He cites Michael Moorcock s informative essay about Starship Troopers and other right-wing apologist themes in sci-fi [5] as well as China Mieville s essay about politics and The Lord of the Rings [6].Glenn Greenwald wrote an informative article about the New York Times defending torture by the US military [7]. I have unsubscrubed from the @Times mailout and will avoid citing NYT articles wherever possible. I sent the URL for Glenn s article to the NYT feedback address but I don t expect them to take any notice.Fate Of the World is a new computer game that s in beta where you have a simulation of the next 200 years of climate change [8]. It s currently in beta for Windows only, they hope to have a Mac version in March and have no stated plans for Linux support.Cory Doctorow wrote an interesting article for Locus about Sci-Fi fans and cosmopolitanism taking the best option after consideration rather than doing what s locally fashionable [9]. He uses the term Martian to refer to some of the viewpoints, but it seems to me that Vulcan would be more appropriate.The Wall St Journal has an interesting article about people who manufacture drugs that aren t yet illegal, every time one drug gets banned they market a new one [10]. This is yet another example of the War on Drugs doing more harm than good, instead of taking drugs which have well known effects (that can be treated by hospitals) people are taking weird new drugs and no-one knows what will happen to them.Mieke Meijer in the Netherlands has invented a new product known as newspaper wood [11], it involves gluing paper together to create a form of chip-board that keeps the layers of paper distinct to give a result like wood grain. The World Changing commentary suggests that this could give a heirloom quality to objects made with it, while I m dubious about that I think that the surface would be pleasing to look at in a kitchen or office environment.Ze Frank gave an interesting TED talk about unusual social projects that he s run on the Internet [12]. This includes an attempt to reconcile Red and Blue voters after the 2008 US presidential election, the creation of inspirational songs, and remixing the Whip Somebody s Ass song. This is really worth watching!The Chronicle Review has an interesting article by someone who is paid to complete academic assignments for other people [13]. The scope of cheating that is claimed is profound. Naturally we have to take claims by someone who admits acting unethically with a grain of salt, but if there is any truth to this then it s a serious matter. I m surprised that no-one has made a serious attempt to catch the customers of such people.David Brin (the famous sci-fi author) gave an interesting short lecture about the future of humanity [14]. He promotes the Lifeboat Foundation (of which he is a director) and describes his concern about the Fermi Paradox.Shimon Schocken gave an inspiring TED talk about his work rehabilitating juvenile prisoners through taking them mountain-bike riding [15]. This shows that anyone can do great things to help other people, he got this idea when riding past a prison, convinced the prison governor that it was a good idea and then started doing it.Conrad Wolfram gave an insightful TED talk about math education [16]. His claim is that the entire mathematical education system is wrong in it s focus on hand calculation, instead the aim should be to teach children how to use computers to solve problems which is what is mostly done in the real world.

• [1] http://www.nytimes.com/2010/08/29/magazine/29language-t.html
• [2] http://blog.ted.com/2010/10/15/fellows-friday-with-shaffi-mather/
• [3] http://www.worldchanging.com/archives/011668.html
• [4] http://www.antipope.org/charlie/blog-static/2010/10/the-hard-edge-of-empire.html
• [5] http://flag.blackened.net/liberty/moorcock.html
• [6] http://www.socialistreview.org.uk/article.php?articlenumber=7813
• [7] http://www.salon.com/news/opinion/glenn_greenwald/2010/10/25/nyt/index.html
• [8] http://fateoftheworld.net/
• [9] http://www.locusmag.com/Perspectives/2010/11/cory-doctorow-a-cosmopolitan-literature-for-the-cosmopolitan-web/
• [10] http://online.wsj.com/article/SB10001424052748704763904575550200845267526.html
• [11] http://www.worldchanging.com/archives/011709.html
• [12] http://www.ted.com/talks/ze_frank_s_web_playroom.html
• [13] http://chronicle.com/article/The-Shadow-Scholar/125329/
• [14] http://www.youtube.com/watch?v=JBmu6D5ZNPg
• [15] http://www.ted.com/talks/shimon_schocken_s_rides_of_hope.html
• [16] http://www.ted.com/talks/conrad_wolfram_teaching_kids_real_math_with_computers.html

Sometime you get an UTF-8 encoded text file you want to print. But most text to postscript converters (often invoked automatically by your print server) can only render ISO-Latin-1 text files properly and so you get the notorious et al on your printout. This is especially annoying at PGP/GnuPG keysigning parties where nowadays most people have the names in their UIDs encoded in UTF-8. Fortunately there is paps (Debian package), a Pango based commandline tool to convert UTF-8 encoded text files into PostScript. See the paps home page for a neat example. Update 02:10 (CET): Funnily the explicitly as HTML entities à and ¤ written above got rendered as in Liferea, but only in the Planet Debian and Planet Symlink feeds, and only until I put that ä in this paragraph, because both got converted to their ISO-Latin-1 8-bit equivalent bytes, so that without the ä , ä , converted to 8-bit ISO-Latin-1 characters looks also like an UTF-8 . And Liferea seems to guess the character set somehow and if it validates as UTF-8, it uses UTF-8 even if it isn t UTF-8. This is a strange Planet.

I finally took some time to finish my color contrast corrector. It's now able to compare two colors and to tell if they are readable when used as foreground and background color for text rendering. If they are too close, the code corrects both colors so to they'll become distant enough to be readable. To do that, it uses color coordinates in the CIE L*a*b* colorspace. This allows to determine the luminance difference between 2 colors very easily by comparing the L component of the coordinates. The default threshold used to determine readability based on luminance difference is 40 (on 100), which seems to give pretty good results so far. Then it uses the CIE Delta E 2000 formula to obtain the distance between colors. A distance of 6 is considered to be enough for the colors to be distinctive in our case, but that can be adjusted anyway. That depends on reader's eyes. If both the color and luminance distances are big enough, the color pair is considered readable when used upon each other. If these criteria are not satisfied, the code simply tries to correct the color by adjusting the L (luminance) component of the colors so their difference is 40. Optionally, the background color can be fixed so only the foreground color would be adjusted; this is especially handy when the color background is not provided by any external style, but it the screen one (like the Emacs frame background in my case). Here is an example result generated over 10 pairs of random colors. Left colors are randomly generated, and right colors are the corrected one. <style type="text/css"> </style>

bg: DarkSeaGreen4 fg: gray67 ->                             fg: #4a6b4b bg: #cccccc
bg: SlateGray4 fg: forest green ->                          fg: #9faec0 bg: #005700
bg: grey13 fg: grey36 ->                                    fg: #131313 bg: #6c6c6c
bg: MediumPurple2 fg: honeydew ->                           fg: #9e78ed bg: #f0fff0
bg: grey43 fg: chartreuse3 ->                               fg: #5e5e5e bg: #79de25
bg: linen fg: DeepPink2 ->                                  fg: linen bg: DeepPink2
bg: CadetBlue4 fg: blue1 ->                                 fg: #6c9fa4 bg: #0000e1
bg: gray33 fg: NavajoWhite3 ->                              fg: #525252 bg: #cfb58c
bg: chartreuse1 fg: RosyBrown3 ->                           fg: #9cff38 bg: #b28282
bg: medium violet red fg: DeepPink1 ->                      fg: #9c0060 bg: #ff55b9

All this has been written in Emacs Lisp. The code is now available in Gnus (and therefore in Emacs 24) in the packages color-lab and shr-color. A future work would be to add support for colour blindness. As a side note, several people pointed me at the WCAG formulas to determine luminance and contrast ratio. These are probably good criteria to choose your color when designing a user interface. However, they are not enough to determine if displayed color will be readable. This means you can use them if you are a designer, but IMHO they are pretty weak for detecting and correcting colors you did not choose.

Next article highlighting some new features which will come in phpMyAdmin 3.4 is about more little changes. You can try them it out on our demo server. Or just wait few hours for first alpha release of 3.4. The user interface cleanup is partly connected with previous changes, because some functionality simply required more Javascript (for example editor for ENUM/SET fields). Besides these there were major changes in export and import pages, which now should be easier to understand, hiding advanced options from unexperienced users, while still providing ability to change them. This feature was implemented by Lori Lee during Google Summer of Code 2010.

Filed under: Phpmyadmin 0 comments Flattr this!

I have been asked how Ubuntu relates to Debian, and how packages flow from one to the other. So here s my attempt at clarifying the whole picture.

Where do the packages come from? Most packages are created by Debian contributors and they are uploaded in Debian unstable (or Debian experimental). New packages are reviewed by the Debian ftpmasters before being accepted in the official archive. The packages are held in the NEW queue until the review is over, and the time spent there varies between a few hours and a few months (usually they are processed within one week or two). Ubuntu imports all the official Debian packages, but they also add some packages of their own. About 7% of the Ubuntu packages are third-party software that have been packaged for Ubuntu but not for Debian. What are the changes made by Ubuntu? From all the source packages coming from Debian, 17% have additional changes made by Ubuntu. Many of them are part of the main repository, which is actively maintained by Canonical and Ubuntu core developers. The universe repository is usually closer to the official Debian packages. Many of the changes made by Ubuntu are the results of the decisions taken during the Ubuntu Developer Summit in order to reach specific goals: provide a better user interface, offer faster boot times, become a better platform for third-party software developers, offer a good integration with their online services (Launchpad, Ubuntu One), etc. Other changes are simply the result of fixing bugs reported by Ubuntu users. Note that even non-modified source packages will result in different binary packages for Ubuntu. That s because Ubuntu has made changes to the build environment. They only support Intel-based computers with a 686-class (or newer) CPU, they enable some compiler options that Debian doesn t, etc. And all binary packages are modified by a program called pkgbinarymangler. Ubuntu s release cycle and the relation with Debian Ubuntu releases every 6 months (that s what time based releases is about). Debian has a very different schedule. How does Ubuntu manage to reuse Debian s work? Ubuntu imports packages from Debian unstable (even experimental sometimes) to get the newest packages. If the Ubuntu package already has Ubuntu-specific changes, they merge their changes in the updated Debian package. Otherwise the Debian package is simply grabbed and rebuilt in Ubuntu. This works well because Debian unstable is much more usable than the name suggests. And this process only goes on during the first 2 months of the cycle (until the Debian Import Freeze), so there s plenty of time afterward to fix the biggest problems. In the third and fourth month, it s still possible to pick updated packages from Debian but it must be requested by a developer, it won t be done automatically. At the end of the fourth month, the feature freeze is put in place. The 2 months left are dedicated to bug fixing and polishing the distribution. There are various sub-freezes that happen in this period, you can check the Natty release schedule as an example. Picking updated packages from Debian is now the exception, it will only be allowed if the update on the Debian side is a bug-fix only release. Credits: some figures taken from a talk of Lucas Nussbaum, they were collected based on the packages available in the Lucid Lynx release of Ubuntu. Click here to subscribe to my newsletter and get my monthly update on what s going on in Debian and Ubuntu.

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

Yesterday and today I attended Ruxcon the leading technical security conference in Australia [1]. The first lecture I attended was Breaking Linux Security Protections by Andrew Griffiths. This included a good overview of many current issues with Linux security. One thing that was particularly noteworthy was his mention of SE Linux policy, he cited the policy for the FTP server as an example of policy that can be regarded as too lax but also noted the fact that to get SE Linux used the policies had to be more liberal than we might desire. There is probably scope for someone to give a good lecture about how we are forced to make uncomfortable choices between making security features stronger and making them more usable.The next lecture I attended was Breaking Virtualisation by Endrazine. It makes me wonder how long it will be before someone cracks one of the major cloud hosting services such as EC2 it s not an appealing thought.Billy Rios gave a really interesting lecture titled Will it Blend? about blended exploits. The idea is to try and find a few programs which do things that are slightly undesired (arguably not even bugs) but which when combined can result in totally cracking a system. One example was a way of tricking IE into loading a DLL from the desktop and a way of tricking Safari into saving arbitrary files to the desktop, combine them and you can push a DLL to a victim and make them load it. Learning about these things can really change the way you think about misbehaving programs!Ben Nagy gave an interesting lecture about Prospecting for Rootite . His systematic way of finding test cases that cover a large portion of the code of a large application such as MS-Word seems quite effective. Once you have test cases that cover a lot of code then you can use fuzzing to find flaws.Edward Farrell gave an informative lecture about RFID Security , I didn t really learn that much though, he confirmed my suspicions that RFID implementations generally suck.Mark Goudie gave a very informative lecture titled We ve been Hacked! What Went Wrong and Why . Mark works for Verizon and often with the US Secret Service in investigating security breaches. He presented a lot of information that I have not seen before and made some good arguments in support of companies being more proactive in protecting their systems from attack.Stephen Glass and Mark Robert gave a lecture titled Security in Public Safety Radio Systems which mainly focussed on digital radios used by the Australian police. It would be good if the police got people like them to test out new kit before ordering it in bulk, it seems that they will be using defective radios for a long time (it s not easy or cheap to replace them once they are deployed).Edward Farrell gave an interesting lecture titled Hooray for Reading: The Kindle & You about hacking the Kindle. Unfortunately they haven t worked out how to get GUI code going on a hacked Kindle yet so there are some limitations as to what can be done.I think that the most interesting lecture of the conference was This Job Makes you Paranoid by Alex Tilley of the Australian Federal Police. He gave some interesting anecdotes about real cases to illustrate his points and he advocated the police position really well. I ve attended several lectures by employees of law enforcement agencies, but none of them demonstrated anywhere near the understanding of their audience that Alex did.The last lecture I attended was Virtualisation Security State of the Union by David Jorn of Red Hat. He gave an interesting summary of some of the issues including mentioning how SE Linux is being used for confining KVM virtual machines.Ruxcon was a great conference and I definitely recommend attending it. I have to note that even though there are police attending and lecturing it s not entirely a white-hat affair. One thing that I hope they do next year is to get a bigger venue. The foyer was rather crowded and because it had a hard floor was really noisy between lectures. Space and carpet are two really important things when you have lots of people in one room!

• [1] http://www.ruxcon.org.au/

I'm in the process of setting up a mail server, which will eventually accept mail for a given domain. I am also changing name servers for said domain (to make use of zoneedit.com). So far, I have the new server accepting mail for the domain, and the new name server serving records for the domain, including an MX pointing at the new server. However, I haven't updated the domain record, so the authorative nameservers haven't changed. Despite this, somehow, spammers are already attempting to submit mail for the domain in question to the new MX server. Not only that, but it's targetted at particular users with non-obvious local parts. The new MX advertises itself as "a-sub-domain.example.org", for values of "example.org", so it's possible in theory to derive "example.org" from the banner. But unlikely. Are they psychic? Or is a spammer somehow getting notified of new MX records hosted at zoneedit (no matter whether glue records point at them)?

On Thursday, I gave a packaging tutorial for Debian-Women. The logs are now available on the Debian wiki, and also on the meetbot site. This was similar to the Ubuntu Developer Week sessions I've participated in the past. Giving these tutorials is fun. It's also a great way to share your knowledge and skills. While most of the session is going to be uni-directional, with the teacher speaking and everyone else listening, IRC is an interactive medium, so whenever there is something unclear, the students can ask questions or make comments. And that's what makes these sessions different from people just reading a web page on their own: the chance to interact with the teacher. It would be great to see other Debian people do their own sessions. There are a lot of topics, and they don't even have to be about teaching. For example, a session where the Debian kernel team answers questions from the audience might be nice. Or the X team, or the DPL, or whoever. Debian's done these things for DPL elections on several years. The election sessions are hectic and pretty stressful for the participants, but that's because they're elections, not because of the sessions themselves. Any other Debian people up to this?

Cython is now considering options where to move the main (mercurial) repository, and Robert Bradshaw (one of the main Cython developers) has asked me about my experience with regards to Google Code and GitHub, since we use both with SymPy.

Google Code is older, and it was the first service that provided free (virtually unlimited) number of projects that you could easily and immediately setup. At that time (4 years ago?) that was something unheard of. However, the GitHub guys in the meantime not only made this available too, but also implemented features, that (as far as I know) no one offers at all, in particular hosting your own pages at your own domain (but at GitHub's servers, some examples are sympy.org and docs.sympy.org), commenting on git branches and pull requests before the code gets merged in (I am 100% convinced that this is the right approach, as opposed to comment on the code after it gets in), allow to easily fork the repository and it has simply more social features, that the Google Code doesn't have.

I believe that managing an opensource project is mainly a social activity, and GitHub's social features really make so many things easier. From this point of view, GitHub is clearly the best choice today.

I think there is only one (but potentially big) problem with GitHub, that its issue tracker is very bad, compared to the Google Code one. For that reason (and also because we already use it), we keep our issues at Google Code with SymPy.

The above are the main things to consider. Now there are some little things to keep in mind, that I will briefly touch below: Google Code doesn't support git and blocks access from Cuba and other countries, when you want to change the front page, you need to be an admin, while at GitHub I simply add push access to all sympy developers, so anyone just pushes a patch to this repository: https://github.com/sympy/sympy.github.com, and it automatically appears on our front page (sympy.org), with Google Code we had to write long pages (in our docs) about how to send patches, with GitHub we just say, send us a pull request, and point to: http://help.github.com/pull-requests/. In other words, GitHub takes care of teaching people how to use git and figure out how to send patches, and we can concentrate on reviewing the patches and pushing them in.

Wikipages at github are maintained in git, and they provide the webfrontend to it as opensource, so there is no vendor lock-in. Anyone with github account can modify our wiki pages, while the Google Code pages can only be modified by people that I add to the Google Code project, which forced us to install mediawiki on my linode server (hosted at linode.com, which by the way is an excellent VPS hosting service, that I have been using for couple of years already and I can fully recommend it), and I had to manage it all the time, and now we are moving our pages to the github wiki, so that I have one less thing to worry about.

So as you can see, I, as admin, have less things to worry about, as github manages everything for me now, while with Google Code, I had to manage lots of things on my linodes.

One other thing to consider is that GitHub is only for git, but they also provide svn and hg access (both push and pull, they translate the repository automatically between git and svn/hg), I never really used it much, so I don't know how stable this is. As I wrote before, I think that git is the best tool now for maintaining a project, and I think that github is now the best choice to host it (except the issue tracker, where Google Code is better).

The documentation on ld's symbol versioning syntax is a little bit vague on "dependencies", which it talks about but doesn't give many details on. Let's construct a small example: In words, we create two libraries; a version 1 and a version 2, where we provide a new version of foo in the version 2 library. The soname is set in the libraries, so v1 and v2 can distinguish the correct library to use. In the updated 2.ver version, we say that VERSION_2 depends on VERSION_1. So, the question is, what does this mean? Does it have any effect? We can examine the version descriptors in the library and see that there is indeed a relationship recorded there. Looking at the specification we can see that each version definition has a vd_aux field which is a linked list of, essentially, strings that give "the version or dependency name". This is a little vague for a specification, however it appears to mean that the first entry is the name of the version specification, and any following elements are your dependencies. At least, this is how readelf interprets it when it shows you the "Parent" field in the output above. This implies something that the ld documentation doesn't mention; in that you may list multiple dependencies for a version node. That does work, and readelf will just report more parents if you try it. So the question is, what does this dependency actually do? Well, as far as I can tell, nothing really. The dynamic loader doesn't look at the dependency information; and doesn't have any need to it is looking to resolve something specific, foo@VERSION_2 for example, and doesn't really care that VERSION_1 even exists. ld does enforce the dependency, in that if you specify a dependent node but leave it out or accidentally erase it, the link will fail. However, it doesn't really convey anything other than its intrinsic documenation value.

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.

i've been on an IPv6 kick recently, getting dual-stack systems up and working for a bunch of folks.I'd like to make some of these services reachable by IPv6-only clients. this suggests that i need a range of details sorted out, but i think the one piece left for me is the glue records for the nameservice. i use in-bailiwick nameservers for DNS where possible, which means i want mandatory glue records. that is, the primary namserver for example.org is probably something like ns0.example.org, which means that the org nameservers themselves need to store not only the NS record, but an A record that corresponds to the name pointed to by the NS. But for IPv6-only clients that do their own name resolution, i need AAAA glue records, and i haven't yet found a registrar that will push AAAA glue records for the same names as the existing A glue into the org zone. Do you know of a registrar that will do this?I've tried:

dotster

Dotster seems to only allow IPv4 glue to be entered on their Register Nameserver config page (needs a dotster login to see it). They haven't yet yet responded to my query through their support web form about submitting AAAA glue

gandi

gandi at least offers the opportunity to enter AAAA glue, but apparently can't let me have both AAAA and A glue for the same name. A note to their support team got me a response that this is planned for Q1 or Q2 of 2011.

Any suggestions for reasonable registrars that offer this today? Am i being silly in wanting AAAA and A glue for the same names? i note that the root zone and the org zone both offer A and AAAA records for each of their dual-stack nameservers. You can check for yourself:

 dig @a.root-servers.net ns org
 dig @a.root-servers.net ns .

if i don't go for dual records, i could instead use gandi and go with distinct names for the v6 and v4 servers, like this:

;; QUESTION SECTION:
;example.org.				IN	NS
;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
example.org.      172800	IN	NS	c.ns.example.org.
example.org.      172800	IN	NS	d.ns.example.org.
;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
b.ns.example.org. 172800	IN	A	192.0.2.4
c.ns.example.org. 172800	IN	AAAAA	2001:db8::3
d.ns.example.org. 172800	IN	AAAAA	2001:db8::4

But of course what i really want is this:

;; QUESTION SECTION:
;example.org.				IN	NS
;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
a.ns.example.org. 172800	IN	AAAAA	2001:db8::3
b.ns.example.org. 172800	IN	A	192.0.2.4
b.ns.example.org. 172800	IN	AAAAA	2001:db8::4

My concern about this is if some IPv4-only system gets a list like the first one, and decides to use c.ns.example.org or d.ns.example.org, which doesn't have an A record at all. That would be a silly implementation, of course. but uh, we have a lot of silly implementations of things out there.Feedback welcome!Tags: dns, ipv6