Time for another ftpmaster blog. It s not like we stopped doing things. :) It seems we, somehow, got a pretty active coder (yay), Michael Casadevall. In the last few days I merged multiple code changes from him. The first was a different output format for our NEW queue overview page. It is now also available in 822 Format for all those people that want to use the data in their tools. Like QA for example. Today got a second change touching this, we now not only list NEW/BYHAND in there, but also our incoming (accepted) and Proposed-Updates queue. There is also a patch waiting to fix up the pretty weird code thats around the DM stuff. Will fix some of the many bugs and weirdnesses in the current implementation. And it seems he is right now trying to get rid of apt-ftparchive, the beast that makes our dinstall run take so long. Oh we will be so happy when we got rid of it. :) Also, we do have two new people as trainees for ftpteam. If that works out, we will have yet another 2 new members in our team. Yay.

I've started using Lua some months ago, while looking for a more powerful way to configure awesome. At this time, around March 2008, Lua seemed to be the best language to integrate inside the core system of awesome. I still think that Lua was a good choice, but after 8 months, it shows some important drawbacks. I'll try to keep my explanation simple and to make you understand everything, even if you do not know Lua. I refer here to Lua 5.1 Design flaws Length operator Lua has a length operator on its objects, known as #. It can be used to get the size of various objects.

return #"lol" 3

This operator works for table, string, etc It's possible to define this operator by setting a __len meta-method on a userdata value. The problem is that you cannot redefine it on string or table objects, see:

> a =   "hello", "world"  
> return #a
2
> setmetatable(a,   __len = function () return 18 end  )
> return #a
2

Indeed, looking at the Lua core code:

     case OP_LEN:   
       const TValue *rb = RB(i); 
       switch (ttype(rb))   
         case LUA_TTABLE:   
           setnvalue(ra, cast_num(luaH_getn(hvalue(rb)))); 
           break; 
             
         case LUA_TSTRING:   
           setnvalue(ra, cast_num(tsvalue(rb)->len)); 
           break; 
             
         default:    /* try metamethod */ 
           Protect( 
             if (!call_binTM(L, rb, luaO_nilobject, ra, TM_LEN)) 
               luaG_typeerror(L, rb, "get length of"); 
           )   
             
           
       continue; 
      

You clearly see that tables and strings always use the internal length operator, never the __len meta-method. That's for me a design problem, which will cause more trouble. We'll see later. __index and __newindex metamethods Lua defines two useful metamethods, which are __index and __newindex. Both can be set on a table or any other object. __index will be called upon each read access to an undefined key on an object, and __newindex upon each write access. Example

> a =  
> setmetatable(a,   __index = myindexfunction, __newindex = mynewindexfunction  ) -- function are not defined, this is just an example
> a[1] = "hello" -- This will call __newindex metamethod
> return a[2] -- This will call __index metamethods
> return a[1] -- This will NOT call __index

The last line does not call __index meta-method because a[1] does exists. This is a problem when you want to use table as object, because sometimes you want to monitor access to the table elements. This can be easily worked around using a proxy system: you don't store things in the table you manipulate, but in another table.

> a =  
> realtable =  
> setmetatable(a,   __index = myindexfunction, __newindex = mynewindexfunction  ) -- function are not defined, this is just an example

Where meta-methods are something like:

function myindexfunction(table, key)
   return realtable[key]
end

function mynewindexfunction(table, key, value)
   realtable[key] = value
end

This way, our a table will always be empty, and realtable will have the data. At every read or write access to a, the meta-methods will be called. This is very convenient and widely used hack. But this has serious drawbacks: as we saw before, the length operator (#) cannot be redefined on a table. That means #a will always be 0, and you cannot get the table length anymore, except by defining another method or a special attribute. Also, Lua has several functions in the table library that are used to manipulate table in a easy way. The problem is that standard functions like table.insert or table.remove do raw accesses to the table. Meaning that if you do table.insert(a, 1, 1) it will insert the value 1 at the key 1 into a, without calling the __newindex meta-methods, breaking all your beautiful object-oriented model. Another solution is to use a userdata object, like done in the Lua newproxy function (which is under-documented). The problem is that it breaks all the other functions that are waiting for a table as argument, because they see a userdata, not a table. So this time table.insert is now more usable, which somehow fixes the problem, but not in the right way IMHO. However, this allows to use the __len meta-method. Development model The development model of Lua is, from my point of view, non-existent. There is no public version control system repository available, so there's no chance to really contribute to Lua. It seems only a defined set of people work on it and therefore, the development system is very closed to my eyes, in comparison of usual projects. Conclusion I still think Lua is a good choice, because it is very easy to integrate into any C program, and to expand to fulfill your needs. However, some bad design choices were made, and the poor and closed development model chosen does not allow to have a good overview of the future of Lua. This has been well stated by the authors themselves.

Given the recent brouhaha in Debian, and General Resolution regarding Lenny s Release policy as it relates to Firmware and Debian s Social Contract, which has led to the resignation of Manoj Srivastava from the position of Secretary for the Debian Project, I m reminded of the following passage from Gordon Dickson s Tactics of Mistakes (part of Dickson s Childe Cycle, in which he tells the story of the rise of the Dorsai):

No, said Cletus. I m trying to explain to you why I d never make an Exotic. In your calmness in the face of possible torture and the need to kill yourself, you were showing a particular form of ruthlessness. It was ruthlessness toward yourself but that s only the back side of the coin. You Exotics are essentially ruthless toward all men, because you re philosophers, and by and large, philosophers are ruthless people. Cletus! Mondar shook his head. Do you realize what you re saying? Of course, said Cletus, quietly. And you realize it as well as I do. The immediate teaching of philosophers may be gentle, but the theory behind their teaching is without compunction and that s why so much bloodshed and misery has always attended the paths of their followers, who claim to live by those teachings. More blood s been spilled by the militant adherents of prophets of change than by any other group of people down through the history of man.

The conflict between idealism and pragmatism is a very old one in the Free and Open Source Software Movement. At one end of the spectrum stands Richard Stallman, who has never compromised on issues regarding his vision of Software Freedom. Standing at various distances from this idealistic pole are various members of the Open Source Community. For example, in the mid-1990 s, I used to give presentations about Linux using Microsoft Powerpoint. There were those in the audience that would give me grief about using a non-free program such as MS Powerpoint, but my response was that I saw no difference between driving a car which had non-free firmware and using a non-free slide presentation program. I would prefer to use free office suite, but at the time, nothing approached the usability of Powerpoint, and while dual-booting into Windows was a pain, I could do a better job using Powerpoint than other tools, and I refused to handcap myself just to salve the sensibilities of those who felt very strongly about Free Software and who viewed the use of all non-Free Software as an ultimate evil that must be stamped out at all costs. It is the notion of Free Software as a philosophy, with no compromises, which has been the source of many of the disputes inside Debian. Consider, if you will, the first clause of the Debian Social Contract:

Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.

This clause has in it no room for compromise. Note the use of words such as 100% free and never make the system require the use of a non-free component (emphasis mine). In addition, the Debian Social Contract tends to be interpreted by Computer Programmers, who view such imperatives as constraints that must never be violated, under any circumstances. Unfortunately, the real world is rarely so cut-and-dried. Even the most basic injunctions, such as Thou shalt not kill have exceptions. Few people might agree with claims made by the U.S. Republican Party that the war in Iraq qualified as a Just War as defined by Thomas Aquinas, but rather more people might agree that the July 20, 1944 plot to assassinate Hitler would be considered justifiable. And most people would probably agree most of the actions undertaken by the Allied Soldiers on World War II battlefields that involved killing other soldiers would be considered a valid exception to the moral (and for those in the Judeo-Christian tradition, biblical) injunction, Thou shalt not kill . As another example, consider the novel and musical Les Mis rables, by Victor Hugo. One of the key themes of this story is whether or not Thou shalt not steal is an absolute or not. Ultimately, the police inspector Javert, who lived his whole life asserting that law (untempered by mercy, or any other human considerations) was more important than all else, drowns himself in the Seine when he realizes that his life s fundamental organizing principle was at odds with what was ultimately the Right Thing To Do. So if even the sixth and eighth commandments admit to exceptions, why is it that some Debian developers approach the first clause of the Debian Social Contract with a take-no-prisoners, no-exceptions policy? Especially given the fourth clause of the Debian Social contract:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

This clause does not have the same sort of absolutist words as the first clause, so many Debian Developers have held that the needs of the users is defined by 100% free software . Others have not agreed with this interpretation but regardless of how needs of the users should be interpreted, the fact of the matter is, injuctions such as Thou shalt not kill are just as absolute and yet in the real world, we recognize that there are exceptions to such absolutes, apparently unyielding claims on our behavior. I personally believe that 100% free software is a wonderful aspirational goal, but in particular with regards to standards documents and firmware, there are other considerations that should be taken into account. People of good will may disagree about what those exceptions should be, but I think one thing that we should consider as even higher priority and with a greater claim on how we behave is the needs of our users and fellow developers as people. For those who claim Christianity as their religious tradition, Jesus once stated,

Thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind. This is the first and great commandment. And the second is like unto it: Thou shalt love thy neighbour as thyself. On these two commandments hang all the law and the prophets.

Even for those who do not claim Christianity as their religious tradition, most moral and ethical frameworks have some variant on the Golden Rule: Do unto others as you would have them do unto you . I would consider, for example, that the Golden Rule is at least a high priority claim on my behavior as the notion of free speech, and in many cases, it would be a higher priority claim. The recent controversy surrounding Josselin Mouette was started precisely because Joss has taken a something which is a good thing, namely Free Speech, and relegated it to a principle more important than all else, and claiming that any restraint on such a notion was equivalent to censorship. I think the same thing is true for free software, although it is a subtler trap. Philosophical claims than 100% free software as most important consideration is dangerously close to treating Free Software as the Object of Ultimate Concern or in religious terms, idolotry. For those who are religious, it s clear why this is a bad thing; for those who aren t if you are unwilling to worship a supernatural being, you may want to very carefully consider whether you are willing to take a philosophical construct and raise it to a position of commanding your highest allegiance to all else, including how you treat other people. Ultimately, I consider people to be more important than computers, hardware or software. So over time, while I may have had some disagreements with how Mark Shuttleworth has run Canonical Software and Ubuntu (but hey, he s the multimillionaire, and I m not), I have to give him props for Ubuntu s Code of Conduct. If Debian Developer took the some kind of Code of Conduct at least as seriously as the Social Contract, I think interactions between Debian Developers would be far more efficient, and in the end the project would be far more successful. This may, however, require lessening the importance of philosophical constructs such as Free Speech and Free Software, and perhaps becoming more pragmatic and more considerate towards one another.

Back a while I created an updated mutt package which builds upon the previous work with mutt-ng. The package which I had constructed had two new features, well if you're generous. I guess there was only technically one new feature:

• The ability to cause the sidebar to only display folders with new mail in them.
• + Updated navigation to make next/prev work correctly with only new mail-containing folders.

I still hate quilt with a passion, but I've synced my patches with the current unstable Mutt - and there are now source & binary packages (x86 + amd64) in my apt-get repository for Etch. I can rebuild for Lenny if there is any interest. But it might take me a while to setup lenny chroots. As a graphical example this is what you will end up with:

• The sidebar with all folders visible (the default).
• The sidebar listing only folders with unread messages.

OK I've tweaked the settings a little, but only a little:

# set up the sidebar, default to being visible
set sidebar_width=45
set sidebar_visible=yes
set sidebar_delim=' '
color sidebar_new red default
# ctrl-n, ctrl-p to select next, prev folder
# ctrl-o to open selected folder
bind index \CJ sidebar-scroll-down
bind index \CK sidebar-scroll-up
bind index \CP sidebar-prev
bind index \CN sidebar-next
bind pager \CO sidebar-open
bind index \CO sidebar-open
# Remap bounce-message function to "B"
bind index B bounce-message
#
#  Toggle visability of the sidebar.
#
macro index b '<enter-command>toggle sidebar_visible<enter><refresh>'
macro pager b '<enter-command>toggle sidebar_visible<enter><redraw-screen>'
#
#  Show folders with new mail only
#
macro index E '<enter-command>toggle sidebar_newmail_only<enter>'
macro pager E '<enter-command>toggle sidebar_newmail_only<enter>'

ObFilm: Joan of Arc

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless. The problem: session management has flaws Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol I won t explain why here, you will find tons of better explanations on the intarweb. The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable that s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code. The solution: remove session management! When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let s bring the session preferences: The UI of this dialog hasn t changed since 2.22. However, I do not resist the urge to show you the code behind the Remember Currently Running Applications button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
 
        g_debug ("Session saving is not implemented yet!");
 

As for the check box on top of it, it sets a GConf value that is never read anywhere. If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager! Backwards compawhat? The surprises don t stop here. I also noticed that logout was much faster instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn t need them to register for saving the session, it also saves the time to ask them to close cleanly. The result is that you will see a lot of such dialogs: It s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let s be realistic, it s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.) Release management at its best Wait aren t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

• is unable to restore applications;
• kills applications without letting you save your work.

It s good to see such improvements on the session manager coming, and I m really thankful to the gnome-session developers to work on it. What I wonder is:

• How could it slip into a stable GNOME release?
• How could two major distributions let it slip into a so-called stable release?

It definitely looks like we re not the only ones who could improve our release management processes. So what? This is a very good example of a lack of big picture thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user s point of view the kind of regressions that make people fly away. If there s one thing that I ve learned from working in IT, it s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

I just found out about hacker spaces. For a nice example of a hack space, see The Metalab. Such places seem quite suitable for work on individual public projects and for growing teams by sorting out the wheat from the chaff. It's a pity there are no hacker spaces east of Vienna. I wonder if one could be set up in Vilnius. There probably are enough people around. but quite a bit of organising work (see Hackerspace Design Patterns [PDF]) needs to be done to establish a hacker space. I would do it, but I am overbooked as it is. Any takers?

A while ago, I wrote an initrd script and hook that would allow one to run a system with root on a Network Block Device (NBD), that I maintain both upstream and in Debian. Since then, Laurent Vivier submitted a kernel patch that got merged, and which will allow one to partition an NBD device. I had a patch for my initrd script that would support running root off a partitioned NBD device, but did not yet have the time to test and debug it. Until today, that is. Well... not really. I made the time, but I didn't really have it. For reference, the time is 07:25 right now, and yes, I did stay up all night. But, well, who cares, right? Right. I'd really love to get this into lenny still, but since we're in deep freeze... not keeping my breath. We'll see, I guess. The upload is going to unstable, anyway after this one final test. So how does it work? Unfortunately, no d-i support as of yet. I'd been working on that, but then it turned out that in order to support root-on-NBD, I'd have to somehow, somewhere, teach partman that NBD is this strange thing which can be formatted, but not partitioned. I was way far in my research (but nowhere in code, yet) on that when Laurent sent in his partitioning patch, so it got postponed then, and I didn't get a chance to pick it up anymore in time. But if you're willing to use debootstrap manually, it's really simple to set up:

# apt-get install nbd-client
# nbd-client server port /dev/nbd0
# fdisk /dev/nbd0
[... create partitions ...]
# mkfs -t ext3 /dev/nbd0p1
# mkdir /mnt/tmp
# mount /dev/nbd0p1 /mnt/tmp
# debootstrap --include=nbd-client sid /mnt/tmp
# echo KILLALL=false >> /mnt/tmp/etc/nbd-client

The "KILLALL" is necessary, since otherwise the nbd-client initscript will do nasty things with your root filesystem. Note that you still need nbd-client installed and run the initscript, even if it only uses nbd-client inside the initrd; because the initscript writes the nbd-client PID to /lib/init/rw/sendsigs.omit.d, which is also required if you don't want sendsigs to shoot the root filesystem from under your nose. This might see some changes in the future. Now boot with your kernel and initramfs, and boot it with the following arguments:

nbdroot=server,port root=/dev/nbd0p1

Obviously, in the above two examples, you should replace 'server' by the IP address or hostname of your server, and 'port' by the port number on which your nbd-server is running. It is of course also possible to use nbd1p2 or nbd0p4, should you want that. And that's all there is to it. Well, almost; due to the way the network configuration is written in initramfs, I had to choose between reinventing the wheel, or hardcoding the NIC name to 'eth0'. I chose the latter. What this means is that if you want to boot off an NBD blockdevice that is only available on eth1 or wlan0 or some such, you lose. Other than that, go ahead and try. Should be on a DMNY (Debian Mirror Near You) RSN. Update: fill in the link to git.kernel.org, and mention the KILLALL thing. Oops.

I switched to git from mercurial about 4 months ago. As Matt Mackall (the main author of mercurial) has pointed out, my arguments were partially just excuses for the switch, because everything could be fixed in mercurial as well (eventually). On the other hand, I really wasn't expecting to switch when I invested time and energy to learn mercurial. Also because I thought that git doesn't have such a nice documentation, has a steep learning curve and the community is hostile, because it is developed by the kernel people who are famous for sometimes being not so nice on the mailinglists (as I now found out, none of these are true). I was getting annoyed by small things one by one, after finally I said to myself enough is enough, let's just switch.

So as to the steep learning curve --- it took me a day or two to being able to do what I want, so it seems to me it's really easy to learn once you know some distributed vcs. I found out the documentation is much better than in mercurial --- in git one just types "git help command" and a full man page fires up with lot's of information and examples. In mercurial, one just gets a couple lines (compared to git) of help in the terminal, without examples. Also the first (actually second) thing I noticed is that "git log" (and other commands like "git diff") doesn't scroll out my terminal, but uses "less" automatically -- that's just great. The first thing I noticed is that git is superfast for almost every operation, especially it's noticeable with "git diff". As to the community, I only had a chance to send a few emails to the git list, so I cannot really say, but so far it's very responsive and friendly.

However, those are just little things that can (and I am sure they will) be fixed in mercurial as well. What is a big thing are branches, especially remote branches. One just fetches a remote repository and then works with it like with any other local branch, e.g. one can switch to it, or just "git log some_remote_branch" to see what is in there. One can easily compare them etc. With mercurial, I was using "hg out" and "hg in" commands to see what changes I will pull or push, but those commands require internet connection, so it really sucks and it's slow. In mercurial, I was using different directories for different branches, but that's just extremely inconvenient and also slow (creating a new branch is just a matter of adding one file, not copying the whole repository --- for example with the sympy hg repository, I often had to wait several seconds to clone a repo, while with the git repository it's just instant) and big (in terms of megabytes).

The bible of Mercurial, the hgbook says:

In most instances, isolating branches in repositories is the right approach.

But I think it's the wrong approach. The only argument for doing this that I accept is that sometimes you are not sure which branch you are in in git --- well, I use this trick (actually, just read the documentation of __git_ps1 in /etc/bash_completion.d/git), so my bash line always says which branch I am in using the red color. I never do any mistakes with this.

Anyways, I could continue like this (e.g. check out "git svn", "git rebase -i" and many other things), but you can read why git is better for example here, no need to repeat here. I am very happy now and I can only recommend to learn git.

So let me also say some things that are worse in git --- one thing that could be improved are URLs of the gitweb (hgweb urls are neat, gitweb urls use "?id=..." stuff). Another thing is that the debian package git is not git! You need to install git-core to get git (but this seems to be getting fixed).

There is also an interesting discussion happening right now in the debian-python mailinglist about switching the DPMT repositories to git. I think almost all opinions (for and against) were already stated, but if you have some opinion that wasn't yet said, please do so.

Previously I've posted a couple of running commentries describing how I've examined and gone about fixing a couple of bugs in Debian packages I use, enjoy, or have stumbled upon by accident. Each of these commentries has resulted in a change or two to the affected software to make the bug vanish. Fixing the bug is usually the hard part, but obviously it isn't the only thing that you need to do. While it is fun to have a locally fixed piece of software if you don't share it then the very next release will have the same bug again - and you'll spend your life doing nothing more than fixing the same bug again and again. Generally the way that I report my fixes is by sending email to the Debian bug tracker - because I usually only try to fix bugs that I see reported already. Specificially I tend to only care about:

• Bugs in packages that I maintain.
• Bugs that affect me personally. I'm selfish.
• Bugs in packages I use, even if they don't affect me.
• Segfaults. Because segfaults and security issues often go hand in hand.

This entry got a little bit long .. click to read more ObFilm: Ghostbusters 2

I don't know if Aaron is an Ubuntu Developer. I hope not. And I hope that no one of the commenters is one. But this post and especially the comments to it (because the article may have some justification) is certainly not a way to improve the relationship between projects like Ubuntu and the projects its based on.

Yes, it is true, that we have a rough tone in our mailing lists and yes it is sad that every now and then topics pop up that need to be discussed till somebody is hurt and leaves (the project). I certainly hope that this can be improved over the time, but most likely this is not something which breaks the project. Who knows what its worth. We have a large community, very much different opinions and therefore conflicts. Possibly it enhances the quality of our distribution, because things that certainly would make our product worse (e.g. lowering quality standards) won't get done, because they'll get a strong opposition.

But whats the point with the innovations, Aaron? Is it the job of a distribution to serve with innovations? A distribution that serves as a base for more then 10 other distributions? A distribution that is known to care a lot about freedom and is known (and appreciated) for a high quality standard. I don't think we need to serve innovations. We served innovations back in a time where it was needed. Where things were missing. Like a good package management, like conf.d directories. Apart from this I think there were enough innovations in the past years. Possibly not that user-visible and trendy as a graphical virtualization frontend. What about xen-tools for example?
Now its all about reinventing the wheel or developing frontends. Launchpad for example is just reinventing the wheel. Savannah exists, GForge exists. Bazaar is just reinventing the wheel. Git exists. So does Mercurial.

But whats most sad about your posts and the comments is that you (and your commentors) seem to share the opinion that all Debian does is packaging software and nothing more. According to you Debian developers do not fix bugs, forward patches, file (important) wishlist bugs, encourage upstreams to remove horribly broken licensed software, improve their own software and tools (dpkg, aptitude, apt-get, the devscripts, ....), do integration work (alternatives, $EDITOR usage, ...), documentation work (writing manpages). The reality is that there are many small and greater things driven by Debian Developers that serve the whole community. Additional to the ground work that your favorite operating system is based on and without which it could not exist.
Its just not beeing doped like it is done by companies with their marketing departments that actually earn money with what they do. Take the projects you named. They all have one. They all have paid developers.

In any way such a ranting (with no real constructiveness) will not serve the relationships between other projects and Debian.

I unsubscribed from -devel and -vote the other day, as the pain/gain ratio was just not worth it anymore (and -project is very much pending). Sadly, I still could not escape from what I wanted to escape from, as some people bring up those discussions and "their style" on planet.

Please show some fscking respect to your peers! Debian is not about freedom (whether you like it or not, and no matter how you define freedom), it's not about freedom of speech or being open minded, it's just about creating the greatest free operating system. The free operating system, that's why we are here.

I for one, disagree with many debian contributors ideas and believes, whether (those ideas are) Debian related or not. To give one example, I think religion is hillarious and believing in (a) higher being(s) is a sure sign of an ill (or weak, or both, or whatever) mind. (Quite similar to smoking btw, and for those who don't know, I do smoke.) But I'm not shoving this down all the time to anybody who makes a religious reference in Debian (nor in real life). Quite the contrary, I do admire quite some people who take motivation out of their religious believes to do things they think are good. I belive this is quite common the other way round too, eg when religious and human-rights motivated groups work together to help immigrants. They dont share (all) the same beliefs, and in some they have huge disagreements (eg. I think religion is the root and a means^wcontributor to many of the worlds evils) but they choose to respectfully disagree on these views to be able to work together on the common goal they share: help immigrants.

And in the same way I (try to) (dis)agree with my fellow Debian peers about their insane or great ideas. I try to respectfully disagree (or respectfully agree). And I do acknowledge that I sometimes fail, eg the above words about religion might have hurt some peoples feelings. I do give a damn about having hurt those people (so I ment to say sorry with that in cheek damn joke), even though I dont give a damn about religion. And I think the last sentence might have been too sharp to be respectful while I belive the above paragraph is fine. I also think its fine to be disrespectful (in or outside Debian) once in a while, since we are all humans and make mistakes once in a while, but I dont think it's fine to have those people in Debian who fail all the time (or too often), be it because they are incompetent to treat fellow peers with respect or because they dont care (or because they think they do something good with their kindergarten rhetoric).

Contributing to Debian is not a human right (and suppressing some voices (and esp. noise) in Debian is not censorship, for fucks sake!). We are only here, because we are standing on the shoulders of giants (except for the very few giants among us) and because we want to create/improve a great operating system. And thats why I think it's perfectly acceptable and desirable to not allow those messages here, which are distracting and/or blocking of from reaching this goal. An occasional outburst (and be that a 2-4 weeks long or a single big outburst) doesnt qualify in my book for being kicked out, no matter how harsh or unreasonable it was. Constant disruption IMO is. Where to draw the line is tricky (and I'm convinced there can't be a single written "line" covering everything in Debian), but not to draw any lines will result in only the vocal and thick-skin minorities to stay.

And with nice, respectful communities (which have policies quite a lot like the DFSG) like fedora and ubuntu available, failing to be(come again) a respectfull community might really contribute a lot to the end or slow decline of Debian. Sure, "the end of Debian!11" is a somewhat constant meme, but it is (sadly) not like Debian is undestroyable. Debian is very certainly much easier to destroy than to rebuild.

We need to take measures to prevent some peoples ideas of freedom from harming or destroying the project. And I don't mean some peoples ideas of Debian police state or Debian teletubby county - I'm very confident those ideas will not win here. But sadly I can see the results of poisonous people, or rather, their behaviour win.

And undoubtfully I also can see many great people in Debian making sure this will not happen.

The future is unwritten and I wish we show our fellows the respect they deserve. Debian wasn't made by you, more than 99,99999% of it was made by other people. And if you have to, attack ideas, not people. And usually it's also unneeded to _attack_ an idea (merely challanging it is usually enough), because usually the Debian person proposing it is not so stupid not to take your criticism into consideration.

That's why I'm still in favor of a social committee, even though I see very much the dangers of power abuse and the cultural norms in a world wide project. But I see much more danger in not stopping unrespectful assholes from urinating into our living rooms and work benches, using the waiver of "free speech" and "we all have different standards of whats acceptable."

Simpler said: either you respect the community or this community shall not be yours.

That said, I wish you all a very merry xmas, whether you celebrate and believe, or one of the two, or none. Be happy and let it be. And may we have a great 2009, despite we'll release lenny that late! ;-)
P.S.: I'll post this to -project as well, so you can reply more easily.

And there it is. We now can have Planet Debian in other languages than english. The first one is Spanish but the framework allows for any number. In case you do want to have Planet Debian in a different language, follow this steps: (2LETTER means the 2char ISO Code of your language. Like es for the spanish one, de for a german, etc.)

• Checkout svn://svn.debian.org/planet-debian/trunk/config and look at the config.ini.tmpl
• Rename it to config.ini.$2LETTER
• Edit the values in it that are marked to be edited. Feel free to translate the footext variables, they are used in the html template.
• Send this file to the Debian Planet Maintainers. No need to commit yet, it wont get automatically activated, we do have to take two steps on the host planet runs on before that happens.

You need to have 10 feeds ready and filled in in the file you send us. All the feeds should provide a category that has entries with only the language for this new instance. (Otherwise it won t make sense to create a Planet instance for a language ) Planet now features a link section called Planet I18N right above the Subscriptions. That will always list the currently active other language Planets. The various planets share the common files like CSS, graphics and all the hackergotchis.

---

It was a bit of work to get to the point where we are able to add multiple planets to the system. First I had to upgrade the code behind it to a newer one, Planet Venus instead of Planet Planet. Main advantage being that it uses multi-threading to fetch the feeds, greatly speeding up that part. And this weekend I had to rewrite all the templates, going away from old (and simple) htmltmpl format to one based on Django. Htmltmpl simply has no way to deal with our Planet now anymore, especially as it has no way to access all config file values. Which I need for the translated strings, or I would need one template per language. Which would be insane. Various other things in Django also make Django templates a way easier thing to deal with, for example simply saying

  % firstof var1 var2 var3 "nothing" % 

instead of having a huge if-then-elsif-elsif-lalala chain. And we do have that multiple times.

Seriously. It reads more like a worked example, without enough of the underlying theory. It doesn't help that I have a slightly more complicated situation, in that I have a filesystem on a logical volume that spans 6 physical volumes. So maybe writing all of this down will help... I know the disk with the problem: /dev/sdc I know the LBA of the sector where the rot starts: 754238963 I know that the physical volume is on /dev/sdc1 and that the partition starts at sector 63 (via sfdisk -luS /dev/sdc) Therefore, within /dev/sdc1, we're talking about block number 754238899 (754238963 - 64) I know the physical extent size is 4096 Kb (via pvdisplay -c /dev/sdc1 awk -F: ' print $8 '). In LBA block size this becomes 8192 (2 x 4096) I know the physical extents start 192K (into the partition, presumably) (via pvs -o+pe_start /dev/sdc1) This is where the Bad block HOWTO starts to quicken the pace a bit on me... I'm supposed to take the physical partition's bad block number (754238899) and divide it by the size of the physical extent (in LBA block size) (8192). So that'd be 92070. This is where I think I end up completely departing the HOWTO, because my filesystem spans multiple physical volumes. Here's my general musings... lvdisplay --maps /dev/data/srv tells me this about /dev/sdc1:

  Logical extent 272326 to 391559:
    Type                linear
    Physical volume     /dev/sdc1
    Physical extents    0 to 119233

So I'm inferring from this, given that I know I want physical extent 92070 of this device, that this corresponds to logical extent 92103 (again, I'm expressing this in LBA block size, so that's (272326 / 8192) + 92070 So now I supposedly know the logical extent (in LBA size) of the bad block. Now what? I think I'm wandering up too many layers, closer to the physical filesystem, but I'll continue wandering around... So presumably at this point, I just want to convert the logical extent to an actual filesystem block number. Maybe the logical extent number divided by the extent filesystem block size divided by the LBA block size? 92070 / (4096 / 512) = 11508. That feels awfully low though. The dd test suggests this is incorrect. At this point I'm feeling fairly lost. If someone out there is reading this, and they've done this before, I'd love to hear from you.

Many people ask me why there are such few female hackers. While I think this is an important/interesting question (that is also extraordinarily hard to answer), there is another one which has captivated me for much longer, which is the followingL why are there such few females represented in the academic/activist world of free software/free culture, etc.? It seems like every turn I take, there are books galore, talks galore, essays galore being written by men with females sprinkled on top, like some confectionery after thought. Take for example Joi Ito s recent photograph collection, Free Souls (women are represented in the beautiful array of photographs) but in the essays which reflect on freedom/free culture/the souls of freedom, there is (I think, correct me if I am wrong), not a single female voice, despite the fact that there were clearly females authors/activists that could have potentially contributed.

Essays 1. Lawrence Lessig
Foreword by Lawrence Lessig
2. Christopher Adams
Share this book
3. Joi Ito
Just another free soul
4. Howard Rheingold
Participative Pedagogy for a Literacy of Literacies
5. Lawrence Liang
Free as in Soul: The Anti-image Politics of Copyright
6. Cory Doctorow
You Can t Own Knowledge
7. Yochai Benkler
Complexity and Humanity
8. Isaac Mao
Sharism: A Mind Revolution
9. Marko Ahtisaari
Intelligent Travel

Now, am I overreacting here; or is this reason for worry?

I'm watching paint dry while e2fsck does its thing on a ~2TB filesystem (the one with all the good stuff on it on mirror.linux.org.au). I'd seen a spate of kernel errors during the week about "attempt to access beyond end of device" so I figured it was due for one. Let's take this output for example:

apollock@disco:~$ sudo e2fsck -y /dev/data/srv
e2fsck 1.40-WIP (14-Nov-2006)
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 209158151 has illegal block(s).  Clear? yes
Illegal block #12 (1620503259) in inode 209158151.  CLEARED.
Illegal block #13 (2992116621) in inode 209158151.  CLEARED.
Illegal block #14 (1657577172) in inode 209158151.  CLEARED.
Illegal block #15 (1168774619) in inode 209158151.  CLEARED.
Illegal block #16 (993415032) in inode 209158151.  CLEARED.
Illegal block #18 (1611893880) in inode 209158151.  CLEARED.
Illegal block #20 (2939071693) in inode 209158151.  CLEARED.
Illegal block #21 (1714919190) in inode 209158151.  CLEARED.
Illegal block #22 (1450852455) in inode 209158151.  CLEARED.
Illegal block #23 (3482149179) in inode 209158151.  CLEARED.
Illegal block #24 (4143923374) in inode 209158151.  CLEARED.
Too many illegal blocks in inode 209158151.
Clear inode? yes
Restarting e2fsck from the beginning...
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
.
.
.

How much more work would it be to tell the administrator the name of the file associated with inode 209158151? That'd be a lot more useful to most mere mortals than the inode number. I suppose if the filesystem is in a really bad state, ascertaining that information may be difficult... Time to play with debugfs while I continue watching paint dry...

(Inaugurating a new category which will be kind of my own dailty wtf) A pretty well known matter is how some tools can be abused. Usually, it is cat or grep. Typical examples include the following two:

cat foo grep bar

grep bar foo awk ' print $2 '

Obviously, the first one can be reduced to:

grep bar foo

and the second, to:

awk '/bar/ print $2 ' foo

awk and sed are often part of the reason grep gets abused, because a lot of people don t know the latter form above or its sed equivalent. They don t know they could restrict the match on a specific column, too, which could be important in some cases. Anyways, a few months ago, I saw the most beautiful short piece of combined useless use of something I ve ever seen, which also happens to be a pretty unusual type:

more $file wc awk ' print $1 '

Not only does it use more where even cat, while still being useless, would be a better choice, but it also manages to use awk where wc could take an option to achieve the same goal. Yes, the above can be simplified as:

wc -l < $file

We never found who was responsible for this nicety.

Currently, varnishlog does not support very advanced filtering. If you run it with -o, you can also do a regular expression match on tag

• expression. An example would be varnishlog -o TxStatus 404 to only show log records where the transmitted status is 404 (not found).

While in Brazil, I needed something a bit more expressive. I needed something that would tell me if I had vcl_recv call pass and the URL ended in .jpg.

varnishlog -o -c   perl -ne 'BEGIN   $/ = "";  print if
(/RxURL.*jpg$/m and /VCL_call.*recv pass/);'

fixed this for me.

So I replaced my Latitude D410 with a shiny new Latitude E4300 (Intel Core 2 Duo SP9400 2.4 Ghz with 4 Gb RAM). Here are some notes about this laptop that might be interesting for others. SSD disk I now use an SSD drive for my main disk (Dell Ultra Performance SSD, it s the second generation of Samsung SSD) and I m satisfied with that choice, I can boot (an unmodified Debian desktop install) from the SSD in less than 30 seconds while the same system booting from a traditional hard-disk takes more than 45 seconds. X server The Intel GM45 graphic card is not auto-recognized by Xorg 7.3 (or rather by xserver-xorg-video-intel 2.3.2 which is in lenny) so you end up with the vesa driver by default. It s possible to force the usage of the intel driver by adding a Driver intel line in the device section of xorg.conf but I have opted to use Xorg 7.4 (available in experimental). With this version, I can successfully use the DVI output in the associated dock and I have working suspend/resume. It does create some interesting problems however since that version of the xserver relies on HAL to detect the keyboard layout and doesn t use the Keyboard section of xorg.conf. You have to create /etc/hal/fdi/policy/10-keymap.fdi by using /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi as template and reload HAL then restart X. Wifi support The Intel 5100 Wifi chipset requires Linux 2.6.27 at least for the new iwlagn driver. This driver also needs a new firmware (the iwlwifi-5000 one) that is not yet integrated in the non-free package firmware-iwlwifi (see #497717). Sound support It works ok with alsa and the version integrated in linux 2.6.27 but it still has some rough edges when used in combination with the dock. Using the output jack connector on the dock doesn t stop the output in the integrated loudspeakers and the volume on that connector is so low that you could think that it doesn t work at all if you don t pay attention. Using the microphone works fine. For reference, if you play in the mixer, Front mic means the microphone connected on the dock while Mic means the one connected on the laptop. Each Analog loopback X option goes pairwise with the corresponding Input source X setting. In order for the recording to work, I have to set Digital Input Source to Analog Input , Digital must be activated and Input source 1 defines the default input used for the recording. Bluetooth support Contrary to the previous laptop, Dell offered no choice on the bluetooth chipset, they only propose the Dell 365 Bluetooth Card so I took it but it doesn t seem to work out of the box. In fact I can t even see it with lspci or lsusb so I wonder if they did something wrong during the assembly. Googling on the topic didn t gave me any good result, let me a comment if you know how to get this working. Update: so apparently the bluetooth component is there (ID 0a5c:4500 Broadcom Corp.), it just appears as an USB hub so it s somewhat difficult to guess that it s effectively a bluetooth card. Freezes, in particular with an amd64 installation I first installed the system in 64 bits mode (amd64 architecture) but I had very regular freezes of the system (I couldn t finish a single kernel compilation for example). Since I switched to an i386 installation, the system is more stable but I still get an occasional freeze every other day. It might be that a more recent kernel fixes this or maybe it will be fixed with a future Dell Bios update we ll see, but it s my biggest complaint with this laptop so far. Links Lucas Nussbaum bought the same laptop, you might want to read his remarks as well. More details Load the full article only if you want to see the lspci and lsusb output on this laptop.


rhertzog@rivendell:~$ lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07)
Kernel driver in use: agpgart-intel
Kernel modules: intel-agp
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03)
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 [8086:2946] (rev 03)
Kernel driver in use: pcieport-driver
Kernel modules: shpchp
00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 03)
Kernel driver in use: uhci_hcd
Kernel modules: uhci-hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 03)
Kernel driver in use: ehci_hcd
Kernel modules: ehci-hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 93)
00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface Controller [8086:2917] (rev 03)
00:1f.2 RAID bus controller [0104]: Intel Corporation Mobile 82801 SATA RAID Controller [8086:282a] (rev 03)
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 03)
Kernel driver in use: i801_smbus
Kernel modules: i2c-i801
02:01.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05)
Kernel driver in use: firewire_ohci
Kernel modules: firewire-ohci
02:01.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22)
02:01.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12)
0c:00.0 Network controller [0280]: Intel Corporation Wireless WiFi Link 5100 [8086:4232]
Kernel driver in use: iwlagn
Kernel modules: iwlagn
$ lsusb
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 019: ID 046d:c03d Logitech, Inc. M-BT69a Pilot Optical Mouse
Bus 004 Device 018: ID 0424:2228 Standard Microsystems Corp. 9-in-2 Card Reader
Bus 004 Device 017: ID 0424:2602 Standard Microsystems Corp.
Bus 004 Device 016: ID 0424:2502 Standard Microsystems Corp.
Bus 004 Device 007: ID 045e:00dd Microsoft Corp.
Bus 004 Device 006: ID 0c45:63fe Microdia
Bus 004 Device 004: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 003: ID 413c:2513 Dell Computer Corp.
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 005: ID 413c:8162 Dell Computer Corp.
Bus 001 Device 004: ID 413c:8161 Dell Computer Corp.
Bus 001 Device 003: ID 0a5c:4500 Broadcom Corp.
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0a5c:5800 Broadcom Corp.
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Partagez cet article / Share This

I use exetel for a number of services in Sydney. I have always found them to be the cheapest, even if their ability to support their service is sub-optimal. An example is right now, they are currently totally offline.

a2@eve:~$ dig +trace exetel.com.au
; <<>> DiG 9.5.0-P2 <<>> +trace exetel.com.au
;; global options:  printcmd
.           338458  IN  NS  G.ROOT-SERVERS.NET.
.           338458  IN  NS  H.ROOT-SERVERS.NET.
.           338458  IN  NS  I.ROOT-SERVERS.NET.
.           338458  IN  NS  J.ROOT-SERVERS.NET.
.           338458  IN  NS  K.ROOT-SERVERS.NET.
.           338458  IN  NS  L.ROOT-SERVERS.NET.
.           338458  IN  NS  M.ROOT-SERVERS.NET.
.           338458  IN  NS  A.ROOT-SERVERS.NET.
.           338458  IN  NS  B.ROOT-SERVERS.NET.
.           338458  IN  NS  C.ROOT-SERVERS.NET.
.           338458  IN  NS  D.ROOT-SERVERS.NET.
.           338458  IN  NS  E.ROOT-SERVERS.NET.
.           338458  IN  NS  F.ROOT-SERVERS.NET.
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 58 ms
au.         172800  IN  NS  ADNS2.BERKELEY.EDU.
au.         172800  IN  NS  AUDNS.OPTUS.NET.
au.         172800  IN  NS  NS1.AUDNS.NET.au.
au.         172800  IN  NS  NS2.AUDNS.NET.au.
au.         172800  IN  NS  DNS1.TELSTRA.NET.
au.         172800  IN  NS  SEC1.APNIC.NET.
au.         172800  IN  NS  SEC3.APNIC.NET.
au.         172800  IN  NS  ADNS1.BERKELEY.EDU.
;; Received 413 bytes from 2001:503:ba3e::2:30#53(A.ROOT-SERVERS.NET) in 620 ms
com.au.         259200  IN  NS  ns1.ausregistry.net.au.
com.au.         259200  IN  NS  ns2.ausregistry.net.au.
com.au.         259200  IN  NS  ns3.ausregistry.net.au.
com.au.         259200  IN  NS  ns3.melbourneit.com.
com.au.         259200  IN  NS  ns4.ausregistry.net.au.
com.au.         259200  IN  NS  dns1.telstra.net.
com.au.         259200  IN  NS  au2ld.CSIRO.au.
com.au.         259200  IN  NS  audns.optus.net.
com.au.         259200  IN  NS  ns1.audns.net.au.
;; Received 354 bytes from 2001:dc0:2001:a:4608::59#53(SEC1.APNIC.NET) in 1302 ms
exetel.com.au.      3600    IN  NS  ns2.exetel.com.au.
exetel.com.au.      3600    IN  NS  ns1.exetel.com.au.
;; Received 99 bytes from 128.242.113.189#53(ns3.ausregistry.net.au) in 193 ms
dig: couldn't get address for 'ns2.exetel.com.au': not found

This is something I reported (ticket #853640) to them around Oct 2008 (when they last had a failure), that the auDA has no in-balliwick glue for their DNS. I was told by their support supervisor, Dylan Friedewald, via email:

The DNS for helpdesk.exetel.com.au is operational and valid, I do not see the point in discussing that further.

It is interesting to note that Steve Waddington has blogged many times about customers being unable to identify issues, but it is even more interesting that when a customer does it is explicitly denied as being a problem and then ignored. Apart from no in-ballwick DNS glue, their nameservers are also open recursive ones. Great if you would like to perform a DoS attack against some unsuspecting person. I have raised other issues with them that warrant further investigation and corrective action, lest they affect all their customers. But I no longer have the time to continually ping them about things.

Well, following some other posts on Planet debian, I decided to also publish my vote on the GR regarding Firmware blobs in Debian. Here is my vote:
V: 7112113
In other words, I rank the first option as low as possible (7, below further discussion), ranked all options I think make sense above further discussion (which is at rank 3) and put all other options (except for the one empowering the release team to decide the issue) at the same, highest rank. The option empowering is ranked at the second level. My priority really is to get Lenny released. While I think we should do as much as we can removing non-free stuff from Debian, I really don t think it is sensible to delay Lenny because of this. Lenny has far less non-free bits in it than Etch, and I m also not really sure wether I really want to consider firmware (which doesn t run on the CPU Debian is for) as software in the sense of the DFSG. The reasoning here is that I don t see any difference between a hardware manufacturer A who embeds a (non-free) firmware in the hardware (for example in the sense of storing it in a flashable memory) and a hardware manufacturer B who allows us to distribute the firmware blob (and avoids storing it in the hardware). In my opinion, both are equally (non-)free. And following this, I don t see why we should support hardware created by A natively while not directly supporting hardware made by B. One could of course argue that we are providing more of a service for B (as we are distributing the firmware for them, while they save some money otherwise spent for the flash memory), but I would like to remind everyone that our foundation documents also include the following: Our priorities are our users and free software This puts free software and our users at the same level. So to cater for one, we might have to make sacrifices on the other priority. In my opinion, the best compromise here is to not consider firmware blobs as software in the sense of the DFSG, but alternatively, I would accept saying we want to remove all such firmware from Debian, but not to delay Lenny because of this process. Additionally, we should make it easy for users to add all effected drivers/firmwares before/during installation of a system (or even include them on our installation media as some proposed, with a short question to the user wether he wants those firmware blobs to be installed). Apart from my opinion on the subject itself, I must also mention my concerns about how this vote was written in a very manipulative way. Additionally, those wanting to get Lenny released were proposing too many different options. This is generally a bad idea.