I ve been asked by the Debconf 10 talks team to coordinate a Debian Enterprise track at the upcoming Debconf 10 conference. I m really excited about this, and I could use your help. From my standpoint, this all started with a BOF proposal looking at better coordination and what is missing in Debian enterprise integration. The track will also include talks and other events on what exciting things are happening with Debian in the enterprise. I need your help in the form of suggestions for talks, panels and the like (especially if you would be willing to give the talk or coordinate an activity). We re under a fairly tight deadline; ideally proposals would be in by May 1, but if they are not, it s still definitely worth discussing with me. From my standpoint, topics include:

• Managing groups of machines together
• Working with Active Directory
• Open source answers to the use cases of Active Directory if you aren t a Windows shop
• Responses especially in the form of working code or ideas for getting there to my concerns about how we re letting Microsoft drive the evolution in the enterprise
• Federated authentication, authorization and personalization
• Integrating with asset tracking, ERP, and other enterprise processes and how Debian fits in.
• Bringing enterprise players into the community as contributors to the project

Obviously, many other things could fit in and I d be interested in your ideas as well.

Getting close now. Sarah had another ultrasound yesterday, just to check things. Unfortunately I couldn't be there due to a self-inflicted scheduling screw up. Apparently you could see hair on the ultrasound, so I'm a bit bummed to have missed it. The baby has "dropped", so that's good. Her head's still down, and she's swallowing, so that's all good too. Weight-wise she's now in the 38th percentile. We're booked in for a C-section on the 14th, unless she comes of her own free will between now and then (which is what we'd prefer), in which case our OB will allow an attempt at a VBAC. Our OB is reluctant to allow the pregnancy to go past 39 weeks, given prior history and Sarah's heart, and they don't induce for VBACs, so it's going to require some planetary alignment to avoid a C-section. The whole heart thing still being an issue was only a fairly recent discovery for us. Sarah's cardiac surgeon had told us we could go forth and have as many kids as we wanted, but it turns out the fine print in that statement is that while the previous aneurysm has been repaired, she has an undiagnosed connective tissue disorder, so there's no telling what might happen with the rest of her aorta in the future. So her OB is just doing what a good high-risk OB should do, and being extra paranoid, on two fronts. So we've got a couple of weeks to try and convince our daughter to come more than a week and 2 days early. I don't think we have statistics on our side, unfortunately (although I had a surprisingly hard time finding concrete statistics on delivery dates relative to due dates for first-time deliveries versus subsequent deliveries).

Alex released another set of Radeon power management patches over the weekend, and I've been adding my own code on top of that (Alex's patches go on top of drm-next, mine go on top of there). I've left it stress-testing for a couple of hours without it falling over, which tells me that it's stable enough that I can feel smug. This is a pleasing counterpoint to the previous experiences I've been having, which have been rife with a heady mixture of chip lockups or kernel deadlocks. It turns out that gpus are hard.

There's a few things you need to know about gpus. The first is that if they're discrete devices they typically have their own memory controller and video memory. The second is that there's an impressive number of ways that you can end up touching that memory. The third is that they tend to get upset if something tries to touch that memory and the memory controller is in the middle of reclocking at the time.

The first and most obvious use of video memory is by the gpu itself. Accelerated operations on radeon are carried out by sending a command packet to the command processor. This is achieved by sharing a ring buffer between the cpu and the gpu, with the gpu reading packets out of that ring buffer and performing the operations contained within them. Many of these operations will touch video memory (that being the nature of most things you want a gpu to do), and if that happens bad things occur. Like the card locking up and potentially taking your PCI bus with it.

So, obviously, we don't want that to happen. The first thing we do is take a mutex that blocks any further accelerated operations from being submitted by userspace. Then we wait until we get an interrupt from the gpu telling us that the display engine has gone idle. The problem here is that we don't have a terribly good idea of how many more operations there are to complete and we don't know how long each of those operations is going to take, but this is less bad than some of the alternatives[1]. Jerome Glisse has some ideas on how to improve this to require less waiting, but the effects should still be pretty much invisible to the average user.

So we've stopped the command processor touching ram. Everything's good, right?

Well, not really. The obvious problem is that users typically want to display something, so there's a separate chunk of chip that's repeatedly copying video memory over to your monitor. That's got to go too. Thankfully, there's a convenient bit in the crtc registers that lets us turn that off, but the pretty unsurprising downside is that your screen goes blank while that's happening. So we don't want to do that. Instead, we try to perform the reclock while there's nothing being displayed on the screen - that is, while we're in the screen region where a crt's electron gun would be scanning back from the bottom of the screen to the top. It turns out that rather a lot of display assumptions depend on this happening even if there's no crt, no electron gun and no thick sheet of glass with a decent approximation of vacuum behind it, so we get to do this even if we're displaying to an LVDS. And we have about 400-500 microseconds to do it - an almost generous amount of time.

So we ask the hardware to generate an interrupt when we enter vblank and then we reclock. Except the hardware has an irritating habit of lying - sometimes we get the interrupt a line or two before vblank, sometimes we get it after we've already gone out the other side. Vexing, and not entirely solved yet - so sometimes you'll still get a single blank frame during reclock. But there are plans, and they'll probably even work.

At this point the acceleration hardware isn't touching the memory and the scanout hardware isn't touching the memory. Except it still crashes under some workloads. This one took me longer to track down, but the answer turned out to be pretty straightforward. Not all operations are accelerated. When they're not accelerated they have to be done in software. That means that the CPU has to write to the video memory itself. I'm sure you can see where this is going. This was fixed without too much trouble once I'd finished picking through the driver to work out every location where objects might be mapped into the CPU's address space, at which point it's a simple matter of unmapping them and blocking the fault handler from remapping them until the reclock is finished. Linux, thankfully, has lots of synchronisation primitives. And now everything works.

Except when it doesn't. This took a final period of head scratching, followed by the discovery that ttm (the memory allocator used by radeon) has a background thread that would occasionally fire to clean up objects. And by clean up objects, I mean change their mapping - which means updating their status in the gart, which means touching video memory. So, let's block that. And that tripped me off to the fact that even if it couldn't submit new commands, the CPU could still create or destroy objects - with the same consequences.

So, once all of these are blocked, video memory is quiescent and we can do what we want. And we do, at least once I'd sorted out the bits where I was taking locks in the wrong order and deadlocking. Depending on the powerplay tables available on your card we'll chose different rates and so your power savings will vary heavily depending on the values that your vendor provided, but the card I'm testing on sees a handy 30W drop at idle. Right now we're only changing clocks and not dropping voltage so there's potentially a little more to come.

While getting this stable was pretty miserable, the documented entry points for clock changing made a lot of this easier than it would otherwise have been. It's also probably worth noting that Intel's clock configuration registers are entirely missing from any public documentation and the dirver Intel submitted to make them work in their latest chips appeared to have been deliberately obfuscated, so thanks to AMD for making all of this possible.

[1] It's possible to insert various command packets that either indicate when they've passed or stall until a register value gets updated, but these either cause awkward problems with the cp locking or mean that the gui idle functionality never goes idle, so they're not ideal either.

When I first started using Free Software yes, that s quite some time ago I found it the right thing to do. It felt like I was first time ever really controlling what my computer does. Took just a bit of time to notice I really never knew anything about it. Well, almost at least. Then when I started contributing to Free Software this obviously changed. One of the freedoms is to learn from the code you re running. And I did it by reading, contributing, doing nonsense with it, reimplementing it you know the deal. Starting to work on Debian was something that just evolved out of it. Doing so gave me the opportunity to give back. I never achieved that actually, though. At least I don t consider my contributions even remotely sufficient to make up for the great deal of software that I use sometimes without noticing it. Still there s lots of stuff that I don t have a clue of and I rely on other developers to do their (volunteer) job. Otherwise my knowledge wouldn t help much. I could never continue kernel development if those kernel hackers all stepped back for instance. I guess, it s getting more and more difficult the closer the piece of code is to hardware. Another thought I had was about Free Software in general. It s more than just the code (although it might be the most important part), it s also a concept that needs to be communicated. Firefox on Windows shows how Free Software can have a big market share in an otherwise closed source environment. Yet I m not sure all users know about it being open source and what that means (hear them talk about Freeware instead). And who is dealing with this conceptual stuff? I decided to do something about all that. Now I don t really have money but a bit I thought I could share. And I could set yet another sign by publicly talking about it, or casually mentioning that I consider Free Software and Linux a good thing. So you will see a mail signature now below all my mails. I always wondered what one might gain with such and now I found a reason to include one. It reads:

Debian Developer                                 www.debian.org
Member of the Linux Foundation                    www.linux.com
Fellow of the Free Software Foundation Europe      www.fsfe.org

DebConf newbies: we want you! You've probably already read a nice blog post by Joey about the DebConf Newbies initiative. Let me recap in case you didn't: Debian will invest some money to explicit sponsor DebConf10 attendance for "non-regulars", i.e. for those that have not attended DebConf ever, or quite in a while. If you are interested you should check the wiki page and mail Joey as requested. (Including a big thank you to him would be more than appropriate, given that he'll be taking care of most gory details.) Why are we doing this and why is it separate from the regular DebConf sponsorship process? Answering the latter is rather easy. The initiative has sponsoring criteria different than regular DebConf sponsoring (which is well oiled and taken care of by the DebConf orga team) and it didn't seem fair to mix the two, possibly keeping out from regular sponsoring requests some people, just because of this new initiative. Also, as we're well past the deadline for requesting regular DebConf sponsoring, it wouldn't have been nice to induce extra work to the DebConf sponsoring team (and Joey has been kind enough to volunteer anyhow, so ... ). Answers to the former question (why are we doing this in the first place?) are possibly subjectives. My personal belief is that attending DebConf increases the enthusiasm of attendees and ultimately will make them better Debian citizens. It surely happened to me years ago: in the beginning of my Debian membership (as DD, since DMs did not exist back then) I just cared about my pet packages. It was only after meeting the Debian crowd in person at a FOSS event (LinuxTag 2004, IIRC) that I got really enthusiastic about Debian, gradually increasing my involvement in the project. I've never regretted it. I hope it can happen to some of you too, possibly starting with DebConf10.
See you in New York!

Even though I do not understand the whole European campaign-period concept, I kept my mouth shut even though it was at odds with trying to answer every question, no matter how stupid. I give props to Jeroen for his efforts in question-answering that year, even though the electorate obviously never cares about that. I wanted to answer all questions directed to all candidates (excluding replies for the same reason that I only responded on-list to questions directed explicitly at me), but did not. Quite a bit of the encouragement I have received after the fact has been from people who are not DDs. I find this strange since most of what I have said has been about the enfranchisement of DDs, and nothing about non-DDs. I could speculate about why this might be the case, but I will refrain. We now return you to your regular program.

I have been looking at writing a program with XCB today. I seem to pick projects that are an exercise in undocumented frustration.

I spent the whole last week in bed with an acute case of pharyngitis, so I haven't been able to gather my thoughts in a blog post up to now. I'd like to congratulate zack on winning the election, and I have faith that he will be a great DPL. I'm happy with my second place, I'd like to thank everybody that supported me and I think that I'll probably try again in the future, although not necessarily next year. Since zack is probably not going to have time to keep up with his bug squashing campaign, I'm going to try and continue that myself. And, if time permits I'm also going to try to put some of the ideas in my platform into action. Finally, last friday both Maxy and me were granted the US visa that we needed to go to DC10, so we finally can say:

A new package - a set of hooks and wrappers to extend pbuilder and pdebuild for cross-building support - is heading to Debian experimental soon. Support depends on replacing debootstrap with multistrap when creating the cross building chroot and includes an svn helper to use alongside svn-buildpackage to cross-build directly from SVN.

There are limitations - apt-cross being the main one. Once these rough edges are smoothed over, pdebuild-cross could possibly migrate into pbuilder.

The reason to ditch debootstrap is so that the cross-building chroot can collect packages from multiple repositories (in this case, the emdebian toolchain repository). The package scripts support no options directly but will pass options down to the underlying tools. Other configuration happens in /etc/pdebuild-cross/pdebuild-cross.rc which is an extended pbuilder.rc file. I see this as a better option than bulking out the scripts with option support - especially at this stage of development.

Initially, pdebuild-cross will be a binary package built from the emdebian-crush source package (which itself replaces the emdebian-tools source package) and pdebuild-cross will depend on the version of multistrap also in Debian experimental.

Coming to Debian NEW soon....

SVN: http://www.emdebian.org/svn/browser/current/host/trunk/emdebian-tools/branches/2.2.0

I found myself with a problem: trying to linearly edit a movie clip with a non-linear editor isn't very simple, nor is it meant to be. Case at hand: I have about 1 hour and 40 minutes of film material that was recorded with dvswitch, and which is 90% fine; but given what we wish to do with it, we really wish to remove the errors from the recording things like failed transitions, rogue camera movements, and so on. This is why we recorded the individual video streams on tape too, so that we could indeed do some retouching afterwards. Cinelerra, however, is not really made for that. If you want to create a transition, you need to have two segments of clips that are stuck together on the timeline, and the transition is then applied to the border between the two. You can create multiple video tracks, but you cannot cut from one track to another; you really have to add a clip to the timeline. Doing that has obvious issues if you have multiple video streams that were recorded on the same time and that can be time-synced on multiple tracks. You would prefer to just select one track or the other on a certain point in time, but cinelerra just doesn't do that. So the workflow that I found is the following: Add all video streams to the time line, each on a separate track. Make sure the to-be-touched-up stream is on top; when multiple tracks are in use, and the are not faded to 50% or so, cinelerra will only show the top stream in the final rendition. Synchronize the streams: first, create a rough alignment by moving them with the mouse. Then, press arrow-down until you can see the streams on a frame-by-frame basis. Now for each of your camera streams, do the following:

1. In the 'main' stream, search a section that was filmed by the camera which we are trying to align.
2. Hit 'l' to create a label
3. Search for the exact same frame in the camera stream. It may help to disable playback for the 'main' stream temporarily to visually verify that the frame is the same in the compositor window.
4. Move the cursor to that frame, and create another label.
5. If the streams are indeed desynced, then one of the tracks will lead, and the other will follow. If the leading track is the 'main' track, arm the main track and any tracks that you have already synced before, and make sure to remember the audio tracks. If, on the other hand, this is the camera track, then only arm that camera track. At any rate, make sure to disarm the track(s) that are following.
6. Use the control and arrow keys to select the first label. Use control, shift, and the arrow keys to select the section up to the second label.
7. At the bottom right of the program window, you can see three entry boxes with time indexes. The first is the time index to your first label; the third the time index to your second label; an in between those, the second is the length of the interval from the first label to the second label. Set the contents of the first box to all-zeroes, to move the selection to the beginning of the time line; then press tab (to move to the second entry box) and enter (to confirm that you wish to create a selection of that length at the beginning of the timeline).
8. Press Shift-Space to insert silence at the location of the selection. This will move the armed tracks to the right, and not touch the not armed tracks.
9. If you did everything right, the two tracks should now be aligned. Move the cursor to the second label, and verify that this is true by disabling 'play' for the main track and any tracks in between the main track and the track you're syncing. The frame in the compositor window should not change if you re-enable the main track. If it does, use 'z' for undo, remove your labels and try again.

Once your video tracks are aligned, you need one final video track that comes all the way on top. This is an empty, 'override' track. Anything you put in this track will override the main track. This way, you do not have to cut from the main track to another camera; instead, you just copy from a camera track and paste on the override track. It is, of course, possible to paste onto the main track, but that has the disadvantage that you cannot easily undo such edits after a 'save' operation. Using a separate 'override' track does allow that. To copy from one track to another track without moving in time, use the following method:

1. Select the region where you wish to select another camera.
2. Arm the camera track that you wish to copy from, and make sure not to arm any other track.
3. Hit 'c' to copy the clip at that point.
4. Disarm the camera track, and arm the 'override' track
5. Without moving or removing the selection, hit 'v' to paste onto the override track.

All this may be basic knowledge for people who are more flexed in nonlinear editors than me; but I couldn't find this procedure on the Internet, so I thought I'd put it out there so that the next person who tries this doesn't have to try for days on end to come up with this, as I had to do.

Haskell provides type classes to support polymorphism. A type class defines a few methods, which can then be implemented for a concrete type in the type class instance. This is a powerful system, but it also has it drawbacks. Most notably, each type can have at most one implementation of the type class. But sometimes you need to use a different implementation. If, for example, you used the Binary class to store data on disk. Now you changed your data type and the binary instance, and you can not read the old data any more. One solution is to re-name your type using newtype and implement another type instance for that. Often, this is enough. But still, instances are not first-class-citizens. You can not pass them around or modify them, as you can pass around and modify data and functions. Under the hood of the compiler, things look different. The ghc puts the methods of the instance in a dictionary and passes that implicitly to any functions having a (Class a) constraint. (Other implementations exist though) If one could make that behavior explicit, one could easily modify the instance before passing it to the function. But this is unfortunately not possible. But it is possible to pass an explicit dictionary along the data. I use the Monoid class as an example, and define a representation of the dictionary to-be-passed, as well as the dictionary of the default instance:

data MonoidDict a = MonoidDict
    ed_mempty :: a
  , ed_mappend :: a -> a -> a
   
monoidDict :: Monoid a => MonoidDict a
monoidDict = MonoidDict mempty mappend

(For conciseness, I ignore the mconcat method.) My first idea was to pass this instance along with data: (MonoidDict a, a). But this would not work because there are methods, such as mempty, who need the dictionary without getting passed a value to use. Therefore, I need to put the dictionary both in the covariant and the contravariant position:

newtype WithMonoidDict a = WithMonoidDict (MonoidDict a -> (MonoidDict a, a))

We need functions to clamp a dictionary to a value, and to extract it again:

wrapWithCustomMonoidDict :: MonoidDict a -> a -> WithMonoidDict a
wrapWithCustomMonoidDict dict val = WithMonoidDict $ const (dict, val)
extractFromCustomMonoidDict :: MonoidDict a -> WithMonoidDict a -> a
extractFromCustomMonoidDict dict (WithMonoidDict f) = snd (f dict)

Note that both expect the dictionary, so that it can be fed into WithMonoidDict from both sides . For convenience, we can define variants that use the standard instance:

wrapWithMonoidDict :: Monoid a => a -> WithMonoidDict a
wrapWithMonoidDict = wrapWithCustomMonoidDict monoidDict
extractFromMonoidDict :: Monoid a => WithMonoidDict a -> a
extractFromMonoidDict = extractFromCustomMonoidDict monoidDict

We want to be able to pass the wrapped values as any other value with a Monoid instance, so we need to declare that:

instance Monoid (WithMonoidDict a) where
  mempty = WithMonoidDict (\d -> (d, ed_mempty d))
  mappend (WithMonoidDict f1) (WithMonoidDict f2) = WithMonoidDict $ \d ->
  let (d1,v1) = f1 d
  (d2,v2) = f2 d
  in  (d1, ed_mappend d1 v1 v2)

Note that mappend has the choice between three dictionaries This is not a good sign, but let s hope that they are all the same. Does it work? Let s see:

listInstance :: MonoidDict [a]
listInstance = monoidDict
reverseInstance :: MonoidDict [a]
reverseInstance = monoidDict   ed_mappend = \l1 l2 -> l2 ++ l1  
examples = do
  let l1 = [1,2,3]
  let l2 = [4,5,6]
  putStrLn $ "Example lists: " ++ show l1 ++ " " ++ show l2
  putStrLn $ "l1 ++ l2: " ++ show (l1 ++ l2) 
  putStrLn $ "l1  mappend  l2: " ++ show (l1  mappend  l2) 
  putStrLn $ "Wrapped with default instance:"
  putStrLn $ "l1  mappend  l2: " ++ show (
  extractFromMonoidDict $ wrapWithMonoidDict l1  mappend  wrapWithMonoidDict l2)
  putStrLn $ "Same with reversed monoid instance:"
  putStrLn $ "l1  mappend  l2: " ++ show (
  extractFromCustomMonoidDict reverseInstance $
  wrapWithCustomMonoidDict reverseInstance l1  mappend 
  wrapWithCustomMonoidDict reverseInstance l2)

Running examples gives this output:

Example lists: [1,2,3] [4,5,6]
l1 ++ l2: [1,2,3,4,5,6]
l1  mappend  l2: [1,2,3,4,5,6]
Wrapped with default instance:
l1  mappend  l2: [1,2,3,4,5,6]
Same with reversed monoid instance:
l1  mappend  l2: [4,5,6,1,2,3]

Indeed it works. Unfortunately, this approach is not sufficient for all cases. It is perfectly valid to have functions with signature (Monoid a => Int -> Int). Obviously, this function would have no access to the explicit dictionary, because no value of type a is passed to or from it.<monoid a="a"> I wonder if it would be possible to extend the syntax somehow to be able to properly pass an alternative dictionary to such functions. But given that not all compilers use dictionary passing, my hopes are low.

Haskell provides type classes to support polymorphism. A type class defines a few methods, which can then be implemented for a concrete type in the type class instance. This is a powerful system, but it also has it drawbacks. Most notably, each type can have at most one implementation of the type class. But sometimes you need to use a different implementation. If, for example, you used the Binary class to store data on disk. Now you changed your data type and the binary instance, and you can not read the old data any more. One solution is to re-name your type using newtype and implement another type instance for that. Often, this is enough. But still, instances are not first-class-citizens. You can not pass them around or modify them, as you can pass around and modify data and functions. Under the hood of the compiler, things look different. The ghc puts the methods of the instance in a dictionary and passes that implicitly to any functions having a (Class a) constraint. (Other implementations exist though) If one could make that behavior explicit, one could easily modify the instance before passing it to the function. But this is unfortunately not possible. But it is possible to pass an explicit dictionary along the data. I use the Monoid class as an example, and define a representation of the dictionary to-be-passed, as well as the dictionary of the default instance:

data MonoidDict a = MonoidDict
    ed_mempty :: a
  , ed_mappend :: a -> a -> a
   
monoidDict :: Monoid a => MonoidDict a
monoidDict = MonoidDict mempty mappend

(For conciseness, I ignore the mconcat method.) My first idea was to pass this instance along with data: (MonoidDict a, a). But this would not work because there are methods, such as mempty, who need the dictionary without getting passed a value to use. Therefore, I need to put the dictionary both in the covariant and the contravariant position:

newtype WithMonoidDict a = WithMonoidDict (MonoidDict a -> (MonoidDict a, a))

We need functions to clamp a dictionary to a value, and to extract it again:

wrapWithCustomMonoidDict :: MonoidDict a -> a -> WithMonoidDict a
wrapWithCustomMonoidDict dict val = WithMonoidDict $ const (dict, val)
extractFromCustomMonoidDict :: MonoidDict a -> WithMonoidDict a -> a
extractFromCustomMonoidDict dict (WithMonoidDict f) = snd (f dict)

Note that both expect the dictionary, so that it can be fed into WithMonoidDict from both sides . For convenience, we can define variants that use the standard instance:

wrapWithMonoidDict :: Monoid a => a -> WithMonoidDict a
wrapWithMonoidDict = wrapWithCustomMonoidDict monoidDict
extractFromMonoidDict :: Monoid a => WithMonoidDict a -> a
extractFromMonoidDict = extractFromCustomMonoidDict monoidDict

We want to be able to pass the wrapped values as any other value with a Monoid instance, so we need to declare that:

instance Monoid (WithMonoidDict a) where
  mempty = WithMonoidDict (\d -> (d, ed_mempty d))
  mappend (WithMonoidDict f1) (WithMonoidDict f2) = WithMonoidDict $ \d ->
  let (d1,v1) = f1 d
  (d2,v2) = f2 d
  in  (d1, ed_mappend d1 v1 v2)

Note that mappend has the choice between three dictionaries This is not a good sign, but let s hope that they are all the same. Does it work? Let s see:

listInstance :: MonoidDict [a]
listInstance = monoidDict
reverseInstance :: MonoidDict [a]
reverseInstance = monoidDict   ed_mappend = \l1 l2 -> l2 ++ l1  
examples = do
  let l1 = [1,2,3]
  let l2 = [4,5,6]
  putStrLn $ "Example lists: " ++ show l1 ++ " " ++ show l2
  putStrLn $ "l1 ++ l2: " ++ show (l1 ++ l2) 
  putStrLn $ "l1  mappend  l2: " ++ show (l1  mappend  l2) 
  putStrLn $ "Wrapped with default instance:"
  putStrLn $ "l1  mappend  l2: " ++ show (
  extractFromMonoidDict $ wrapWithMonoidDict l1  mappend  wrapWithMonoidDict l2)
  putStrLn $ "Same with reversed monoid instance:"
  putStrLn $ "l1  mappend  l2: " ++ show (
  extractFromCustomMonoidDict reverseInstance $
  wrapWithCustomMonoidDict reverseInstance l1  mappend 
  wrapWithCustomMonoidDict reverseInstance l2)

Running examples gives this output:

Example lists: [1,2,3] [4,5,6]
l1 ++ l2: [1,2,3,4,5,6]
l1  mappend  l2: [1,2,3,4,5,6]
Wrapped with default instance:
l1  mappend  l2: [1,2,3,4,5,6]
Same with reversed monoid instance:
l1  mappend  l2: [4,5,6,1,2,3]

Indeed it works. Unfortunately, this approach is not sufficient for all cases. It is perfectly valid to have a function with signature (Monoid a => Maybe a -> Maybe a), whose behavior depends on the instance of a, even when being passed Nothing and returning Nothing. Such a function woul<monoid a="a">d have a problem here, because the dictionary would not be passed to the function.
</monoid> I wonder if it would be possible to extend the Haskell language somehow to be able to properly pass an alternative dictionary to such functions. But given that not all compilers use dictionary passing, my hopes are low.

While I normaly don t care much about Ubuntu, I m subscribed to lauchpad.net for the packages I m involved within Debian.
Sometimes apears informative stuff there, which reminds me about my todos or just pointing me to real problems. Most of the time, I m just ignoring the reports, as the are useless or just unrelated to me packages in Debian.
But in some cases the reports are just making my day.

If you re convinced that cloud is a useless buzzword, being used to describe everything under the sun, old and new, then well, you re right that is, except for the useless part. It s true that this word is being (ab)used in many different products, services and technologies, which do not seem to relate to each other in any concrete way. Cloud in the abstract is being defined in many different ways, based on different fundamental characteristics of cloud technology . Nonetheless, there is something genuinely important going on here, and this is my view of what it s about. The hype Countless business which only had web sites or web applications in 2008 now call them cloud services . They aren t delivering any new benefits to their users, and they haven t redesigned their infrastructure. What do they mean by this? Cloud is defined, some say, by where your data is kept, and cloud means storing your data on remote servers instead of internal ones. Millions of Gmail and Flickr users have been in the cloud without even knowing it, and so has everyone who reads their mail over IMAP, or uses voicemail. In short, cloud is just data that is somewhere else. Last September, I watched a presentation on Cloud computing where Symantec pitched their anti-virus product as having something like three different cloud computing technologies. These, it turned out, all involved downloading files over the Internet. In this view, cloud is essentially about the network, derived from our habit of using a drawing of a cloud in our network diagrams for so many years. Wikipedia currently shares this view, as its Cloud computing article opens with Cloud computing is Internet-based computing . No Internet, no cloud. Maybe cloud is just SaaS, and any service provided on a pay-per-use basis over the Internet is a cloud service. It would seem that cloud is about paying for things, especially on a utility basis. The cloud is computing by the hour; it s something you buy. Others maintain that cloud is just virtualization, so if you re using KVM or VMWare, you ve got a cloud already. In this view, cloud is about operating systems, and whether they re running on real or virtual hardware. Cloud means deploying applications as virtual appliances, and creating new servers entirely in software. If your servers only have one OS on them, then they re not cloud-ready. If this vagueness and contradiction irritates you, then you re not alone. It bugs me, and a lot of other people who are getting on with developing, using and providing technology and services. Cloud is not just a new name for these familiar technologies. In fact, it isn t a technology at all. I don t think it even makes sense to categorize technologies as cloud and non-cloud , though some may be more cloudy than others. Nonetheless, there is some meaning and validity in each of these interpretations of cloud. So what is it? A different perspective Cloud is a transition, a trend, a paradigm shift. It isn t something which exists or not: it is happening, and we won t understand its essential nature until it s over. Simon Wardley explains this, in presentation format, much better than I could in this blog post, so if you haven t already, I suggest that you take 14 minutes of your time and go and watch him do his thing. This change doesn t have a clear beginning or an end. Early on, it was a disconnected set of ideas without any identity. We re now somewhere in the middle of the bell curve, with enough insight to give it a name, and sufficient momentum to guess at what happens next. In the end, it will be absorbed into the way things are . What s going on? So, what is actually changing? The key trends I see are:

1. People and organizations are becoming more comfortable relying on resources which do not exist in any particular place. Rather than storing precious metals under our beds, we entrust our finances to banks, which store our data and provide us with services which let us use our money . In computing terms, we re no longer enamored with keeping all of our programs and our data on our hard drive: as it turns out, it s not very safe there after all, and in some ways we can actually exercise more control over programs and data out there than in here . We can no longer hoard our gold, or drive off would-be thieves with a pistol, but that wasn t a productive way to spend our energies anyway. While we can t put our hands on our money, we can know exactly what s happening with it from minute to minute, and use it in a variety of ways at a moment s notice.
2. IT products are ceding ground to services. In many cases, we no longer need to build software, or even buy it: we can simply use it. As computing needs become better understood, and can be met by commodity products, it becomes more feasible to develop services to meet them on-demand. This is why we see a spike in acronyms ending in aaS . Simon explains the progression in detail in his talk, linked above.
3. Hardware, software and data are being reorganized according to new models, in order to provide these services effectively. Architectural patterns, such as hardware/OS/framework/application are giving way to new ones, like hardware/OS/IaaS/OS/PaaS/SaaS/Internet/web browser/OS/hardware . These are still evolving, and the lines between them are blurry. It s a bit early to say what the dominant patterns will be, but system, network, data and application architecture are all being transformed. No single technology or architecture defines cloud, but virtualization (at the infrastructure level) and the web (at the application level) both seem to resonate strongly with cloudy design patterns.

These trends are reinforcing and accelerating each other, driving information technologies and businesses in a common direction. That, in a nutshell, is what cloud is all about. So what? This transformation is disruptive in many different ways, but the angles which most interest me at the moment are:

• Operating systems Cloud seems to indicate further commoditization of operating systems. We will have more operating systems than ever before (thanks to virtualization and IaaS), but we probably won t think about them as much (as in software appliances). I think that the cloud world will want operating systems which are free, standard and highly customizable, which is potentially a great opportunity for Ubuntu and other open systems.
• Software freedom As Eben Moglen and others have pointed out, this trend has significant consequences for the free software movement. As the shape of software changes, our principles of freedom must evolve as well. What does it mean to have the freedom to run a program in the cloud? To copy it? To change it? What other protections might people need in order to exercise these freedoms in the future?
• DevOps I see a strong resonance between cloud which is blurring the lines between hardware and software, infrastructure and applications, network and computer and DevOps, which is bringing together the people who currently work in these different categories. Cloud means that we can no longer afford to treat these elements separately, and must work together to find better approaches to developing and deploying software, knocking down barriers and mapping new territory. Fortunately, cloud also means developing powerful new tools which will power this revolution.
• Clients A majority of cloud related activity seems to be focused on what happens to back-end servers, but what about the computers we actually touch, on our desks, and in our pockets? How will they change? Will we end up reverting to a highly centralized computing model, where clients are strictly limited to front-end user interface processing (e.g. a web browser)? Will clients join the cloud and be providers of computing resources, not only consumers? What new types of devices will we need in order to make the most of cloud?

I d like to explore some of these topics in future posts.

Once again, I was invited by several different groups to be present at FLISOL, a quite interesting phenomenon: FLISOL (Latin-american Free Software Installation Festival) is s very large-scale, very loosely coordinated thing put together for five years already in over 200 cities in basically every Latin American country. Go to the FLISOL page, it is quite interesting to try to understand it! Now, I don't like FLISOL. I managed to avoid it in 2005 and 2006; in 2007, I was present at a FLISOL, although I didn't know beforehand it was the reason for the conference I was invited to. In 2008 and 2009 I took part for reasons I should not go into right now. This year, again, I will not be part of any of its activities (regardless of rumors to the contrary I was invited to be present at a panel on ACTA, but I have not followed the topic enough to be aware of anything besides the very basic aspects, I have no authority to speak about it; I told the organizers I would like to be there as part of the audience, but not present the topic. And I am quite work-stressed, so I doubt I'll make it). Why am I against FLISOL? FLISOL itself, as I said, is a positive and interesting phenomenon, and I have enjoyed the conference cycles which often happen together with it. What I am against is installfests In my opinion, in the stage we are at today, instead of promoting Free Software, an install-fest just works against it. Free Software Linux-based distributions at least is widely known already, as a concept, even though most people dare not come anywhere close to it. Few people outside our already consolidated groups recognize programs such as the Mozilla and OpenOffice suites as being also Free Software, and valuable, quality alternatives for their everyday needs in the environments they currently use. If we need to show how to install and understand the GNU/Linux ecosystem to people who have not got close, it is not IMHO to end users. Installing a GNU/Linux system is easy enough for anybody interested in doing it, or at least, for him to request a one-on-one help session, handholding and understanding the basic ideas. We need, in any case, for the computer corner shop technicians to be somewhat acquinted, at least with the basics, at least with one popular distribution (and with the fact that there are many, and that they are different). People who have not had the curiosity and courage to try to install Linux by themselves do not need to be evangelized (a verb that should be out of our vocabularies by now, as that phase in our movement should be over by now) End users have simple needs: Things should work, and be as surprise-free as possible. They don't want to depend on a specific time-starved person (or even on a small group of people, all of which have a sanctity delirium/aura). When they go to technical support, they expect the problem to be solved Not even understanding what was wrong. End users are willing to pay a small fee to anybody to help them solve their problems. The key word is anybody. If we (myself, or me and my 10 friends who were there at the gathering, or any sufficiently defined small group) are the only support point for the OS, it is no good. Online support forums are not good either, in my experience, as the end user will prefer just lugging the computer to the nearest technician and get it fixed. Even if fixed means just installing one more readily-available package (not to mention, of course, when an update breaks something). I have witnessed, after an install fest, people walk very happy with their new system as a new toy. After a week or two, they cannot install the latest virus^Wscreen saver, or a legitimate program they need for their work. As it does not work, they take the computer to the technician... Who will end up formatting his system and installing something more usual. On the other hand, some people prefer installing a dual-boot system That guarantees the user will feel he is carrying some kind of moral superiority on his computer, and will often remember he has something Not Evil. This will often happen, of course, at boot time When they see GRUB at boot time, and rush to select Windows before That Strange Thing starts up. Anyway... Go ahead, install Free Software, enjoy the day. The conference cycles are usually interesting, and are the best part of it all I'm not saying you should stop doing it. But I'd urge you to take the focus away from the mass-installs, which become often just lost work (even detrimental to furthering Free Software). Try to see things as a non-technically-interested user would. Try to design ways to get corner shop technicians interested. Maybe that can be useful in the long run.

When I got my Mac Mini, one of the very first things I did was to test the Debian build of rEFIt on the machine, given the EFI firmware is x64 on the newer machines whereas it s ia32 on my MacBookPro; it was the very first time I could test the x64 build. And the results weren t good: some images couldn t be loaded, and it all seemed to be random. Disabling optimization in both GNU EFI and rEFIt for the x64 builds helped somewhat, at least it made rEFIt reliable enough to be usable. Now, with this new release, I started getting error messages, requiring a key press before the menu would be displayed. It s annoying but it s also very helpful as I now had an error message to work with, and even if the error message wasn t reliable, it would still point me to some part of the code. The message was: Invalid argument. On x64, the use of a call wrapper is mandatory because the EFI x64 calling convention doesn t match the calling convention of the ELF executables we re building and later disguising as EFI executables. The call wrapper has always been the prime suspect in this issue, it d be an obvious candidate for anyone looking at this issue. Today, digging into the issue with some new data, I realized what the problem was: when using the call wrapper, all arguments need to be of the UINT64 type. That s the type the call wrapper uses when extracting the arguments from its va_list. Introduce some more macros on top of the call wrapper, build, test: voila, it s fixed! That was tricky one. Let s sum it up for the search engines: all the arguments to the EFI interface called through uefi_call_wrapper() in GNU EFI need to be cast to UINT64. rEFIt 0.14-1, available in unstable in a couple hours. Next, I ll see if I can reenable optimization in both GNU EFI and rEFIt.

One day a very well known Internet theorist writes a rant on women. The rant generates controversy, controversy lands theorist on WYNC on the media , despite the fact the he does not really work on the politics of gender. If this is so, why then give him more air time and focus on the NPR show? There are three lessons that precipitate from this social fact that are worth highlighting: 1.The fact that NPR chose him to pontificate and not a woman nullifies Shirky s thesis that behavior is one of the most important factors in keeping women behind, unless of course NPR asked a bunch of women but they were too meek to be on the air (not likely). If they wanted to keep the star power that is Shirky, the very least they could have done is had a woman respond. The solutions to get more women in the limelight are so easy to implement but they do require some thoughtfulness and foresight. 2.So what I am saying, it is about networks and Shirky, isn t he a theorist of networks and behavior? It seems to be to more controversial, he really did not address how important networks are for the politics of visibility, instead he focused on individual behavior. If famous highly networked folks, most of them men, don t highlight women in their blog posts, their twitter feeds, and don t invite them to conferences, it is going to make very little difffernce whether a woman is meek or confident. So if there are more guys that are visible, which is certainly the case, it is as much their job to help engender change, not so much by pontificating but acting. 3. I realized that though I first thought his rant was a reflection of his personality (at least his public persona, I am sure he is a nice guy), in fact the rant is valuable to an anthropologist interested in digital media because it is an auto-ethnographic snapshot of web 2.0 punditry culture. It often comes across as smarmy and snarky, which is due in part, to how difficult it is to get your message heard in the sea of many voices. Just like there is an aesthetic of audaciousness in a lot of Internet memeology, for example, the pundits too must often act in extreme ways to get attention which might inf fact be one of the reasons why they are reluctant to share the stage once they have worked hard to get there.

One day a very well known Internet theorist writes a rant on women. The rant generates controversy, controversy lands theorist on WYNC on the media , despite the fact the he does not really work on the politics of gender. If this is so, why then give him more air time and focus on the NPR show? There are three lessons that precipitate from this social fact that are worth highlighting: 1.The fact that NPR chose him to pontificate and not a woman nullifies Shirky s thesis that behavior is one of the most important factors in keeping women behind, unless of course NPR asked a bunch of women but they were too meek to be on the air (not likely). If they wanted to keep the star power that is Shirky, the very least they could have done is had a woman respond. The solutions to get more women in the limelight are so easy to implement but they do require some thoughtfulness and foresight. 2.So what I am saying, it is about networks and Shirky, isn t he a theorist of networks and behavior? It seems to be to more controversial, he really did not address how important networks are for the politics of visibility, instead he focused on individual behavior. If famous highly networked folks, most of them men, don t highlight women in their blog posts, their twitter feeds, and don t invite them to conferences, it is going to make very little difffernce whether a woman is meek or confident. So if there are more guys that are visible, which is certainly the case, it is as much their job to help engender change, not so much by pontificating but acting. 3. I realized that though I first thought his rant was a reflection of his personality (at least his public persona, I am sure he is a nice guy), in fact the rant is valuable to an anthropologist interested in digital media because it is an auto-ethnographic snapshot of web 2.0 punditry culture. It often comes across as smarmy and snarky, which is due in part, to how difficult it is to get your message heard in the sea of many voices. Just like there is an aesthetic of audaciousness in a lot of Internet memeology, for example, the pundits too must often act in extreme ways to get attention which might inf fact be one of the reasons why they are reluctant to share the stage once they have worked hard to get there.

I'm changing jobs! From June 1st, I will be team leader of the Computing Support team for the School of Computing Science at Newcastle University. I will be leaving my current job as a Computing Officer within the central IT department's UNIX infrastructure team (ISS). My professional career began within ISS nearly 6 years ago. I have made many friends and will miss working with them as closely as I have. I am really looking forward to getting stuck into my new role. Working within a school means I will be a lot closer to the University's business of teaching and learning. As a Computing Science graduate I've always had an interest in computing research and my new role will have me up close and personal with world-class researchers.

The Android developers seem to feel that they have been singled out for a level of criticism which few other embedded vendors including those demonstrating much worse community behavior have to deal with.

This is from Jonathan Corbet's coverage of the Collaboration Summit and matches my impression. I guess what some Google folks don't necessarily see is that they work for a company that has a big sign outside that effectively says we are not Microsoft or Apple or Sony or the RIAA/MPAA (implied: we're the good guys.) If you put up such a sign, and then disappoint people's expectations, you got to live with the consequences. (Google's marketing was once more successful with their recent actions in China. Get lots of good press coverage, get rid of quite a few critics, and pull out of a market where you didn't make big money in any case.)