Archive for January, 2009

Getting ready for DNSSEC – One small step

DNSSEC is going to be a major PITA. So far it’s sufficiently painful to have almost no deployment. I’m reasonably confident that either someone will have an incredibly great idea for an easy to deploy alternative or any of us who have anything to do with DNS are going to have to suck up the pain and learn to love it.
Most of you already probably heard about the Kaminsky DNS cache poisoning attack. I had my own little part in cleaning up the mess. What I suspect fewer people know is that the ‘fix’ was not a fix in the true sense of the word at all. What the fix did was push the statistics away from a successful attack. I’ve read reports of successful attacks on patched systems, but I really have no way of knowing how accurate they are.
Some people claim the attack was over-hyped, but I’m not one of them. I think DNS had a near death experience that it can never fully recover from. I have no idea what the next attack will be, but I’m pretty sure it’s coming.
Doing my little bit to make the world a better place, I noticed that the latest major release of DKIM Milter included support for DNSSEC if the package was built with the Unbound DNS resolver. I’ve uploaded this change to Jaunty.
Additionally, I updated Unbound to the current release and configured it to be in a chroot (upstream default). So if you’re interested in DKIM or other email authentication technologies, here’s your shot to also play with DNSSEC and get a bit ahead of the power curve.


Usability, choices, and xorg

This blog entry isn’t meant to express an opinion about the current discussion surrounding the ctrl-alt-backspace changes for Jaunty. Since it’s a Gnome only discussion, it doesn’t actually affect me. I do think it’s an important discussion that people ought to be more broadly aware of, not just for this particular instance, but for the design principals in play.
Because upstream decided to change to disable this by default and there was a rough (very rough, IMO, but I keep reminding myself that’s not what I’m writing about …) consensus at UDS to follow their lead, by default in Jaunty, ctrl-alt-backspace will no longer restart X. Because of the controversy, the spec includes in the implementation plan, “GUI tools will be implemented that permit re-enabling this. Tools must be available for both GNOME and KDE”.
Alberto Milone went off and implemented that. It was merged into Kubuntu’s packaging of KDE 4.2 last week. When Alberto asked to have the Gnome change merged today, a long discussion followed.
As part of that discussion, Mark Shuttleworth pointed people to Matthew Paul Thomas‘s blog posting, Why Free Software has poor usability, and how to improve it and said he was, “happy to keep discussing it, and would like to use MPT’s commentary as the usability framework for that discussion.”.
So I’d invite people to read through it and bring their perspective to this in a useful way (I hope this counts).

Bug #254468 – momentary video garbage upon drawing new objects

This is likely going to be a bit controversial.
This bug is the result of what happens when good engineering practices are ignored.
In the xorg-server package in Intrepid, we have a patch called 107_fedora_dont_backfill_bg_none.patch. This is a hack that the author of the patch says is, “breaking protocol semantics that have been good for twenty years”. Now for some time, this was a good hack. It helps a lot with making Compiz go faster. I’m not sure how long it’s been around. The earliest I reference I found in the package’s debian/changelog was:
xorg-server (2:1.2.0-3ubuntu1) feisty; urgency=low

* dropped patches (comments from Michel Daenzer):
– 107_fedora_dont_backfill_bg_none.patch
“Breaks X semantics and thus can’t go in upstream. Apps/toolkits
need to be fixed not to use background none windows.”

— [redacted – it doesn’t really matter who uploaded it] Mon, 26 Feb 2007 09:36:38 +0100
So it’s been there at least two years. I don’t know how much longer than that.
Later it got put back because it helped with performance. Up until KDE4 appears, it’s all good. Unfortunately it appears no one ever told KDE or Qt about this and so they relied upon the established semantics of the protocol. Whenever a new object is drawn in KDE4, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay – perhaps 200ms – the garbage is properly replaced with the real object contents. This slows things down and is a major annoyance. I’ve had at least one user tell me they gave up Kubuntu because of it.
The good news is that the patch has been dropped (at least for now) in Jaunty, so there is hope for the future. I had a long discussion with some of the involved people on #ubuntu-devel yesterday about putting the same change in intrepid-updates, but lost out because dropping the patch now would be a performance regression for Compiz users in Ubuntu. For Intrepid KDE users we are going to provide alternate packages and see how it goes.
It is in the same PPA that we are using to provide experimental KDE 4.2 packages for Intrepid:
If you don’t want all of KDE 4.2, it’s also in my PPA:
Please note that PPAs are now signed. Follow the instructions to add the repository keys.
These packages are not official K(U)buntu packages. Do not file bugs against them and it’s not my fault if it does something bad to your computer (these are experimental). Let me know if you have problems though.
I’ve installed this on multiple Intel machines and got positive test reports from both Nvidia and ATI users.
So now we are stuck between a rock and a hard place between having xserver optimized for Compiz or Kwin.
I can understand why the hack was done and it looks like it’s a good idea. The real problem is that getting the protocol and documentation changes to get this upstream was not done and it wasn’t widely communicated through other means. I understand that changing the X protocol is not something to undertake lightly and a hard job to get done, but however long it takes, we’d be two years closer to being done if that work had been started at the same time the patch was written.
Hacks that solve problems are great, but you have to follow-up and do the hard engineering that gets them out of being a hack and into the way things are done.
There are more details in the actual bug.

Kubuntu evangelism for all ages

We had a small party at our house last Friday. Our youngest (age 5) got quite attached to one of the guests (age 8) and had to show her just everything. At one point I looked into the room that has the kid’s computer (Kubuntu 8.10 with KDE 4.1.3) and saw that she had logged into her account and was giving her friend a tour. They were using Kolourpaint and making some very nice pictures together.
Due to this spontaneous act of Kubuntu evangelism, I had a chat with her dad and he left with one of my Kubuntu ShipIt CDs. Her dad uses Linux at work some, but had never considered it at home.

Quassel again …

For those of you running Jaunty, I’ve just updated the Quassel package to build with KDE4 integration. Also apachelogger added some goon postinst fun to create a certificate to use SSL between the client and the core if you are using the split architecture. Quassel comes with 4 package:
quassel – Use this if you don’t know what you need. It’s all in one like a traditional IRC client.
quassel-core – The sever component if you want to split quassel into a client/server system with the server elsewhere.
quassel-client – The client component for the split architecture.
quassel-data – This data package is needed for quassel and quassel-client.
Personally I use the split system (and most of the quassel developers do to). The current thinking is that it’ll be the monolithic package (quassel) that we consider for the Kubuntu CD. The split architecture is just too much for new people.
So, please test. The quassel devs have been very responsive to issues. I had a build issue with the split architecture packages yesterday and it was fixed today. Please file bugs.

Stuff I love about FOSS …. Quassel now gets activated from a notification

Yesterday I wrote about (among other things) wanting to be able to click on a notification of from Quassel and end up in that application. Today I find on #quassel:

[08:09:46] Quassel IRC: sputnick master * rb324a124e384 /src/ (8 files in 2 dirs):
[08:09:46] Quassel IRC: Notification backends now can emit a signal activated() that tells MainWin to raise itself
[08:09:46] Quassel IRC: For now, this signal is emitted by systray, dbus and knotify. Unfortunately, raise() does not seem
[08:09:46] Quassel IRC: to work with kwin and (according to docs) neither on Windows. Furthermore, my knotify seems
[08:09:48] Quassel IRC: to be broken and doesn’t signal a click at all. Thus, this whole thing got “limited” testing by me 🙂
[08:09:51] Quassel IRC: Take it as “might work under some circumstances in some environments”. Feedback welcome.
[08:10:19] ScottK: try this and see if it raises the mainwin for you – I have failed on my box, but code-wise it *should* work… guess those are WM restrictions

It works. Thanks.
Of course this is just the first step, but it’s great.

Notifications – What I’d like to see

It’s kind of an interesting coincidence that about a week before Mark Shuttleworth posted in his blog about Canonical’s plans for notifications, I had started experimenting with a new IRC client, Quassel, that provides a notification when you are highlighted or sent a personal message.
I’ve waited a bit to reply to his plans to gain more experience with notifications from Quassel and to think things through and not just give a knee jerk reaction. My initial reaction was very similar to Aaron Seigo’s. So I’ve spent a week or two thinking about it on and off and I really haven’t changed my mind.
Let me use Quassel’s notification as an example and give you an idea of what I want and why…
The proposal from Mark Shuttleworth has two key points:

– There should be no actions on notifications.
– Notifications should not be displayed synchronously, but may be queued.

To the first point, my experience with Quassel notifications is that I will have one of two reactions:
1. I read the notification and I both understand the context sufficiently I don’t need to look at the IRC channel and I have no immediate interest in responding. I get the notification, read it, and go back to what I was doing. This seems to fit the proposed model quite well. I want the information in the notification and I want it to hang around just long enough to read it and not require that I dismiss it.
This is how Quassel notifications work today. In some cases, it’s great and it’s a feature I really like that Konversation didn’t have. In other cases, it drives me nuts.
2. I either need more context to understand the message or I want to reply. In this case I inevitably click on the notification thinking it will take me to the Quassel window with the message, even though I know it doesn’t do that from repeated tries.
This is where I think the notifications proposal is off base. The idea of not requiring interaction (the notification just goes away after some period) is a good one. The idea of not allowing interaction is, I think flawed. I thought that perhaps I was misunderstanding the proposal and left a comment. It didn’t draw a response, but a similar comment did get a reply. I understand the reply and it does make things not quite as bad as I had feared, but it still doesn’t solve the problem.
For about a month now I’ve been using an application where I get regular notifications. I know that clicking on the notification doesn’t actually do anything and I need to click on the icon in the taskbar. I know this and still I click on the notification first every single time. Why, because it’s the thing that just flashed a message to me and it’s the most natural thing in the world for me to click on that message to get more information/act on it.
I don’t get stacks of notifications often enough to have a strong opinion about that bit, but Aaron Siego’s idea to reduce notifications and not just queue them seems sensible to me. If there are a lot of notifications, queuing them will just make them late and less useful.
So what would I like to see in notifications:
1. Clicking on the notification takes me someplace to act on it.
2. I’m not required to dismiss it.
3. It’d be nice if it picked up the desktop theme and didn’t give me Ubuntu standard colors on a Kubuntu desktop.
Fortunately, at least from my perspective, it doesn’t look like the chances of this getting implemented in Kubuntu for Jaunty. It’s not in any of the approved specs and I don’t know of anyone who is working on it (Note: If someone is working on an implementation of this aimed at Kubuntu Jaunty, use Kubuntu developers would be interested to know about it).
It’d be nice to see a follow-up post explaining why having clicking on the notification doing something useful is a bad thing? The lack of it is currently driving me nuts.