planet.freedesktop.org
March 28, 2011
I am going to write about my most recent contributions to libattica. Libattica, is a library in KDE implementing a client for the Open Collaboration Services protocol (OCS). OCS is a Free Desktop specification, with the purpose of integrating web communities and web based services into desktop applications. This is very general though, more specifically, [...]

I’d like to point any potential Google Summer of Code applicants to a post on DOs and DON’Ts for students over on the Google Open Source blog that I wrote with Lydia Pintscher and Kevin Smith. They’re fellow admins from two other long-time GSoC participants, KDE and the XMPP Standards Foundation. Here’s a quick summary of the points; you’ll have to read the original post for details:

DO DON’T
Be on your best behavior. Make a bad first impression: SMS speech, extremely poor English, rudeness/hostility, etc.
Read all the documentation, so you submit a useful application. Submit a useless application.
Be transparent about other commitments. Disappear.
Make Google Summer of Code your top priority. Hold another major commitment.
Be realistic about your skills. Over- or under-rate your abilities.
Commit and publicize your code frequently. Make last-minute (or later) code drops.
Submit code that’s ready to integrate. Finish the summer with code that’s “almost ready” but will take forever to ship.
Complete your project design before writing a line of code. Start coding before finalizing design.
Use your resources wisely. Refuse to ask for help.
Remember that you’re part of a community. Consider it a solo project, like it often is in college.

Tagged: communication, community, gentoo, gsoc
March 27, 2011

libxklavier was originally hosted in CVS on sourceforge.net. At some point, it was moved to CVS hosted on freedesktop.org.

CVS is out of fashion for quite a while – but I did not see any reason to switch to git (standard de-facto for freedesktop.org). Now, I made the move. Here it is: git+ssh://git.freedesktop.org/git/libxklavier. All future changes are going to be made in git. I just made last commit to CVS. So long, old friend!

March 26, 2011

After months of envy, I decided that since GNOME 3 is to be released in almost two weeks, it was time to try it out. I must say that is is pretty damn cool. Yes, it has a few annoying bugs and glitches, but nothing out of the ordinary for a first release. It is definitely going in the right direction.

That said, we’re in 2011, and it’s still impossible to use OpenGL on two monitors without tearing. How incredible is that! The thing is, my second monitor is a 50″ Plasma TV and I really hate tearing there when I watch a movie. So when I have two monitors, I want the VSync to be on the second monitor. Luckily NVidia (yea sorry) has an environment variable to select which monitor an OpenGL application syncs on, the annoying thing is that this has to be set before the application is started. So after a little messing around with Looking Glass (which is pretty amazing), I was able to set the variable into the shell and have it re-exec itself. After getting that to work, I couldn’t resist writing an extension to do it for me. Be warned that if you switch screens at runtime, you also want to apply the patch from bug #645408 for now.

thereifixedit.com - Euro Ipod Charger
see more There I Fixed It

I try to fairly regularly build recent git checkouts of all the upstream modules from X.Org (at least all those listed in the current build.sh) on Solaris. Normally I do this in 32-bit mode on x86 machines using the Sun compilers on the latest Solaris 11 internal development build, but I also occasionally do it in 64-bit mode, or with gcc compilers, or on a SPARC machine. This helps me catch issues that would break our builds when we integrate the new releases before those releases happen. (Ideally I'd set up a Solaris client of the X.Org tinderbox, but I've not gotten around to that.)

Anyways, recently I finally decided to track down an error that only shows up in the 64-bit builds of the xscope protocol monitor/decoder for X11 on Solaris. The builds run fine up until the final link stage, which fails with:

ld: fatal: relocation error: R_AMD64_PC32: file audio.o: symbol littleEndian: value 0x8086c355 does not fit
ld: fatal: relocation error: R_AMD64_PC32: file audio.o: symbol ServerHostName: value 0x8086b4fe does not fit
ld: fatal: relocation error: R_AMD64_PC32: file decode11.o: symbol LBXEvent: value 0x808664c3 does not fit
(and over 150 more symbols that didn't fit)

A google search turned up some forum posts, a blog post, and an article on the AMD64 ABI support in the Sun Studio compilers. And indeed, the solutions they offered did work - building with -Kpic did allow the program to link.

But is that really the best answer? xscope is a simple program, and shouldn't be overflowing the normal memory model. Once it linked, looking at the resulting binary was a bit shocking:

% /usr/gnu/bin/size  xscope
   text	   data	    bss	    dec	    hex	filename
 416753	   5256	2155921980	2156343989	808732b5	xscope

% /usr/bin/size -f xscope

23(.interp) + 32(.SUNW_cap) + 5860(.eh_frame_hdr) + 27200(.eh_frame)
 + 2964(.SUNW_syminfo) + 5944(.hash) + 4224(.SUNW_ldynsym)
 + 17784(.dynsym) + 14703(.dynstr) + 192(.SUNW_version)
 + 1482(.SUNW_versym) + 3168(.SUNW_dynsymsort) + 96(.SUNW_reloc)
 + 1944(.rela.plt) + 1312(.plt) + 291018(.text) + 33(.init) + 33(.fini)
 + 280(.rodata) + 38461(.rodata1) + 1376(.got) + 784(.dynamic)
 + 1952(.data) + 0(.bssf) + 1144(.picdata) + 0(.tdata) + 0(.tbss)
 + 2155921980(.bss) = 2156343989

% pmap -x `pgrep xscope`
26151:	./xscope
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
0000000000400000        408        408          -          - r-x--  xscope
0000000000476000          8          8          8          - rw---  xscope
0000000000478000    2105388       1064       1064          - rw---  xscope
0000000080C83000         52         52         52          - rw---    [ heap ]
[....]
FFFFFD7FFFDF8000         32         32         32          - rw---    [ stack ]
---------------- ---------- ---------- ---------- ----------
        total Kb    2108668       3204       1300          -

Two gigabytes of .bss space allocated!?!?! That can't be right. Looking through the output of the elfdump and nm programs a single symbol stood out:

Symbol Table Section:  .SUNW_ldynsym
     index    value              size              type bind oth ver shndx          name
[...]
      [89]  0x00000000009ff280 0x0000000080280000  OBJT GLOB  D    1 .bss           FDinfo

[Index]   Value                Size                Type  Bind  Other Shndx   Name
[...]
[528]   |            10482304|          2150105088|OBJT |GLOB |0    |28     |FDinfo

Unfortunately, that wasn't one of the ones listed in the linker errors, since it's starting address fit inside the normal memory model, but everything that came after it was out of range.

So what is this giant static allocation for? It's defined in scope.h:

#define BUFFER_SIZE (1024 * 32)

struct fdinfo
{
  Boolean Server;
  long    ClientNumber;
  FD      pair;
  unsigned char   buffer[BUFFER_SIZE];
  int     bufcount;
  int     bufstart;
  int     buflimit;     /* limited writes */
  int     bufdelivered; /* total bytes delivered */
  Boolean writeblocked;
};

extern struct fdinfo   FDinfo[StaticMaxFD];

So it allocates a 32k buffer for up to StaticMaxFD file descriptors. How many is that? For that we need to look in xscope's fd.h:

/* need to change the MaxFD to allow larger number of fd's */
#define StaticMaxFD FD_SETSIZE

and from there to the Solaris system headers, which define FD_SETSIZE in <sys/select.h>:

/*
 * Select uses bit masks of file descriptors in longs.
 * These macros manipulate such bit fields.
 * FD_SETSIZE may be defined by the user, but the default here
 * should be >= NOFILE (param.h).
 */
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */

So this makes the buffer fields alone in FDinfo become 65536 * 32 * 1024 bytes, aka 2 gigabytes.

Thus in this case, while compiler flags like -Kpic allow the code to link, using -DFD_SETSIZE=256 instead, builds code that's a little bit saner, fits in the normal memory model, and is less likely to fail with out of memory errors when you need it most:

% /usr/gnu/bin/size -f xscope
   text	   data	    bss	    dec	    hex	filename
 409388	   3352	8449804	8862544	 873b50	xscope

% pmap -x `pgrep xscope`
         Address     Kbytes        RSS       Anon     Locked Mode   Mapped File
0000000000400000        404        404          -          - r-x--  xscope
0000000000475000          4          4          4          - rw---  xscope
0000000000476000       8248         20         20          - rw---  xscope
0000000000C84000         52         52         52          - rw---    [ heap ]
[...]
FFFFFD7FFFDFD000         12         12         12          - rw---    [ stack ]
---------------- ---------- ---------- ---------- ----------
        total Kb      11500       2136        232          -

Of course that assumes that xscope is not going to be monitoring more than about 120 clients at a time (since it opens two file descriptors for each client, one connected to the client and one to the real X server), and still wastes many page mappings if you're only monitoring one client. The real fix being worked on for the next upstream release is to make the buffer allocation be dynamic, and allocate just enough for the number of clients we actually are monitoring.

The moral of this story? Just because you can make it build doesn't mean you've fixed it well, and sometimes it's useful to understand why the linker is giving you a hard time.

March 25, 2011

I’m pleased to finally be able to announce that my CrystalHD support patches have been accepted into FFmpeg and MPlayer – if you grab the latest source from each of the projects, you’ll be good to go. As before, you’ll need the latest driver and userspace library from Jarod Wilson’s git tree. The driver that’s included in the Linux kernel’s staging directory, and the library on Broadcom’s website are both too old.

In terms of features, the merged code doesn’t differ a great deal from my original announcement – there’s now support for interlaced VC1 and MPEG4 Part 2, but interlaced H.264 remains problematic. I’ve got patches in my github tree that get very close to full support, but there’s still a corner case which can cause one type of file to play back incorrectly.

I have to say, I’ve learnt far more about interlaced encoding than I ever wanted to know, working on this project. I think it’s safe to say that I’ve spent at least 70% of my time working on it, and it’s still not perfect. With progressive content, it’s simple – you have a compressed frame going in one end, and an uncompressed one coming out the other end – there’s really no ambiguity (modulo the hardware’s odd treatment of packed b-frames where it will output the packed frame twice and you have to skip one of them).

But with interlaced content, on this hardware, you have to deal with multiple variations of input and output packing; check out wikipedia if you want a quick introduction to interlacing. When compressed video is packed into a container (like AVI or matroska), it is typically split up into packets, and those packets will correspond to compressed frames or fields, and this where the fun begins. With progressive content, a packet is obviously one frame, but with interlaced content, it could be one field or two fields – sometimes the container or video format will enforce that it is one or the other, and sometimes both are valid. On the output side, the hardware, in its infinite wisdom, will sometimes output individual fields or a full frame of two fields, without much rhyme or reason. And naturally, with h.264, all four combinations are possible. That’s bad enough; to add insult to injury, the flags that the hardware is supposed to set to identify the fields/frames is bogus – meaning that it’s simply not possible to distinguish three out of the four cases until it’s too late. With a little help from FFmpeg, I was able to identify one of those three formats, but for the last two, I had to use a method that relies on peeking ahead at the next frame/field – which is great when it works, but sometimes the hardware hasn’t decoded the next frame/field sufficiently to answer the question, and then I just have to guess.

It should come as no surprise that all the other projects that support CrystalHD have punted on interlaced support :-)

As for the future, I still need to get the improved interlaced support merged, and then I have to start looking at how to support the older 70012 hardware. This chip is very sensitive to the rate that frames are submitted to, and retrieved from, it; the code today will work enough that you should see frames most of the time, but the hardware will do odd things and drop frames or stall, so the experience isn’t good at all. I can at least take comfort from the fact that Broadcom’s gstreamer plugin and XBMC have both got it working.

Onward and upward, etc!

March 23, 2011
Couldn't help but laugh when I opened these (Paracetamol and Ibuprofen) as I usually buy a different brand of Ibuprofen which is your standard white pill.



That's why they are cost approximately 8 euros for 30 tablets! Damn, I don't need it decorated like an Easter egg, as long as it works...


Citizens! GNOMErs! Only two days are left and the GUADEC/Desktop Summit CFP is over (end date is Friday). Submit your presentation proposal now, or it is too late. Read the CFP.

Oh, and regarding the need for a KDE identity account: due to limited manpower we decided to reuse existing infrastucture instead of setting up a completely new one. We do acknowledge that this is not ideal and we'd like to ask for your understanding. (Creating a KDE identity account is unrestricted, and you can easily create one even if you never had anything to do with KDE in your life.)

Note that we are looking for both lightning talks and full-length presentations. If you are interested in doing a lightning talk (and we can only encourage you to), please use the same form to make your submission.

March 22, 2011

The Planning Committee for the Linux Plumbers Conference (LPC) is happy to announce that submissions to the “micro-conferences” portion of the conference is now open.  The micro-conferences are working session focused on specific infrastructural “plumbing” in the Linux system – kernel subsystems, core libraries, windowing system, etc. — which are half-day in length.

The potential topics for the working sessions can be found at Topics Page on the LPC Wiki and include (but are not limited to):

  • Audio
  • Bufferbloat
  • Cloud
  • Desktop
  • Development Tools
  • Early Boot and Init
  • Embedded Build Systems
  • File and Storage Systems
  • Mobile
  • Power Management
  • Real Time
  • Scaling
  • Virtualization

The topics that will actually have working sessions scheduled at the LPC will depend on the submissions to the Microconference and on the ability of its respective community to organize a successful working session; see the “Responsibilities of a working session leader” page on the LPC wiki for more details. The list of Microconferences above just reflects the current state of the conference.  If you have an idea for a new micro-conference, select the “Microconference Proposals” track in the proposals form to suggest it.  If the committee agrees, we’ll add it as its own Microconference.

Microconference submissions do not have to reflect finished work. In fact, proposals or proof-of-concepts of potential solutions to important problems are encouraged, so they can be discussed and debated during the microconference.

Proposals for presentations at a microconference may be submitted on this web site.  In addition to the micro conference, the Linux Plumbers Conference has open calls for papers and BoFs.

For further announcements about LPC, please watch our blog or subscribe to our LPC announcements mailing list.

I find the recent posts from Jeff quite entertaining, it's actually pretty good exercise to sometimes stop and look back to see the path you've done instead of focusing on the path you have ahead. It makes you think about why are you here and where you want to go. Besides, I always find Jeff writing quite entertaining and motivational, I miss it.

Motivated by a tweet from Miguel I am going to try to explain why I got involved in GNOME and why I am still excited about what this community is trying to accomplish. I am not sure Miguel is going to like the length of it :-)

75623499_e7f7420173_z

Just a month before I started university, I attended my first major FOSS event. The HispaLinux congress in 2003. HispaLinux was the main Spanish FOSS non-profit organization and it was very active, this was at the same time that Extremadura and Andalusia made the move to Linux for their IT deployments in education. FOSS was a hot topic in Spain.

During this event Miguel gave a talk on GNOME and Mono, to be honest I didn't put much attention on the Mono stuff, I was quite new to software development and I didn't quite understand the point of it at the time.

3189944608_8c1b521216

On the other hand, I fell in love with the values and goals of the GNOME project as he exposed them. Usability, design, accessibility... computing for everybody. At that point it became clear to me that GNOME was to free software what Apple was for computing back in the 80s. It was a truly open community. It was a project worth contributing to.

In this congress I was also introduced to the GNOME Hispano guys by Juanje Ojeda. The names are familiar and still very relevant: Alvaro Lopez, Carlos Garnacho, Carlos Garcia, Alvaro del Castillo, Roberto Majadas, Rodrigo Moya, Chema Casanova, Jose Angel. How can you not want to spend more time with them?

I had such a great time with that bunch. They were  not only cheerful and fun but passionate about trying to push FOSS mainstream. They were geeks indeed, but a special breed of geeks anyway.

Since then, I've been following d-d-l and Planet GNOME daily, blog posts from Jeff, Vincent, Federico, Elijah, Carl, Seth made me excited about the future of the project, and eventually I started contributing code.

So this is my story, what's yours?

Google Summer of Code (GSoC) is an amazing program for college students that enables them to spend their summers working with open-source projects. Google chips in the money, and FOSS projects provide the mentorship and expertise. In the end, we benefit by gaining both new code and (more importantly) new developers.

I’m very excited this year because both Gentoo and X.Org were accepted for their 6th years in GSoC! Last year, Gentoo had 19 students working on diverse projects including webapps, package management, NetworkManager, the Dracut initrd framework, and more. X.Org, a more specialized project, had 5 students working on various aspects of open-source graphics.

If you’re a college student, I’d like to encourage you to apply for GSoC, whether it’s to Gentoo, X.Org, or another project altogether. It’s great real-world experience where you can prove your expertise to future employers (since the code is freely available), and you can become the world’s expert in your topic. The money doesn’t hurt, either.

To get more info, go to the Gentoo or X.Org GSoC homepages and check out the project ideas. If none of them strike your fancy, propose your own! We love original ideas, but please discuss them with us first to ensure they’ll be realistic and high-priority.


Tagged: communication, gentoo, gsoc, x.org
Thanks largely to Bastien, Gnome Bug 635486 just got committed, in time for GNOME3.

It adds is the ability for custom configuration of input devices from within GNOME, especially for settings that are not handled by the GNOME UI tools. It's principle is quite simple. A new gsettings key hotplug-command in the org.gnome.settings-daemon.peripherals.input-devices schema points to an executable. This executable is called at gnome-settings-daemon startup, whenever a device has been added and whenever a device has been removed. Something like this:


$HOME/executable -t added -i 12 My device name


So the device with the ID 12 and the name "My device name" just got added. Other types are "removed" and "present" for those device that are already present when g-s-d starts up. It's quite simple to configure any device to your liking now. Have a look at the input-device-example.sh script shipped with gnome-settings-daemon. I'll give you two examples of what you could add to the script and the rest should be easy enough to figure out:


# Map stylus button 1 to button 8
if [ "$device" = "Wacom Intuos4 6x9 stylus" ]; then
xsetwacom set "$device" Button 1 8
fi

# map tapping to LMR instead of default LRM
if [ "$device" = "SynPS/2 Synaptics TouchPad" ]; then
xinput set-prop $id "Synaptics Tap Action" 0 0 0 0 1 2 3
fi
March 19, 2011

I knew it was a matter of time till somebody would decide to continue development of GNOME2, “tried and true”. Here it is, EXDE. There was a number of GNOME forks before – none of them had anything close to some form of real life. I wish this project all the luck – just because too many people find GNOME3 … well … “too different to be acceptable” (putting it mildly).

And, above all, I hope that some good ideas from EXDE (if they are going to happen) could be fed upstream. That would be win-win scenario.

We’ll see…

March 18, 2011
Phoronix just posted a link to an interview with Ryan Gordon who says
Also, I find it completely ridiculous that we're shipping open source OpenGL drivers without S3TC support because of patent concerns. Today, that's like shipping a web browser without .jpg support!
Why does so many people think that breaking the law is not only acceptable but mandatory? I don't understand why would you castigate others for following the law. Yes, every single patent is despicable, there's not one of them that's ethically valid but the solution can't be pushing someone else to be breaking the law for you.

Legally there's nothing stopping anyone from licensing s3tc or floating point patents, forking Mesa3D and shipping closed source version of it with code handling both.
It's simply that you can't reconcile Free Software with patents. You just can't add what amounts to arbitrary restrictions to your software and claim freedom. There's absolutely nothing we can do here. There were teams of lawyers looking at this stuff and the conclusion every single time was "you just can't get away with this". Jose and Brian spent a lot of time looking at ways of getting around it as well.

I don't even think we could claim that we're taking a moral stance because it's not us but the distributors who would get sued and would lose. Pushing others under the train just doesn't seem like a moral high ground. Plus all the "I'm not a lawyer but /* bad advice follows */" are just not helpful at all. It's only meaningful if you work for a company that distributes Mesa3D code and your lawyers decided that you'll fight this in court or you'll go around this using some technical quirk. Everything else is back seat driving, without even having the decency to get in the car.

Thanks to my recent promotion allowing me to commit directly in Org-mode, I've moved Org-contacts into the contrib directory of the Orgmode distribution.

Flattr this
March 17, 2011

I'd like to remind everybody that only one week is left until the Desktop Summit (aka GUADEC 2011) Call for Participation ends. We want your talk proposals, and that quickly, before it's too late!

Berlin in summer is fantastic. You wouldn't want to miss that, would you?

So, read the CFP again, and then submit something.

The CFP ends next friday. So hurry!

Thank you,       Lennart

March 16, 2011

We are now accepting proposals for presentations and BoF sessions to be given at the Linux Plumbers Conference.

Submissions close: 30 April 2011
Speakers notified: 15 May 2011
Final paper/slides due: 29 August 2011
Conference: 7-9 September 2011 in Santa Rosa, CA, USA

The Linux Plumbers Conference (LPC) is a developer conference for the open source community. The LPC brings together the top developers working on the “plumbing” of Linux — kernel subsystems, core libraries, windowing systems, etc. — and gives them three days to work together on core design problems. The conference is divided into several working sessions focusing on different “plumbing” topics, as well as a general paper track.

A good topic will cut across community boundaries, and should generate vigorous discussion leading to beneficial change. One excellent example from a past LPC was “From Naught to Sixty in 5 Seconds” back in 2008. This topic involved a sizable fraction of the Linux-related software stack, and required coordinated changes to many components. It set the goal of booting a netbook in five seconds, and within a few months actually achieved a three-second boot. That said, talks describing lessons learned during an already-completed implementation effort are also welcome, as long as they are likely to generate good discussion and to help others avoid similar pitfalls in future implementation efforts.

Submission format

LPC invites paper proposals in the form of extended abstracts. All proposals will be reviewed by the LPC Technical Program Committee. The extended abstract may be up to 500 words and should include your qualifications to speak about the topic, an overview of the topic, and why the topic will appeal to a technical audience.

Proposals are due by April 30th, and should be submitted via:

http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011/proposals/new

Please note that proposals will be subject to an open peer review; that is, the proposals are public, and anyone may make comments to the technical program committee regarding any of the proposals.

Acceptance notifications will be sent during the week of May 15th.

Final Papers (or Slides) are due on August 29, 2011.

— The 2011 LPC Committee

March 15, 2011

One of my key goals for Ubuntu 11.04 has been to introduce full multitouch support through X.org. In technical terms, this means adding touch support to the XInput protocol. You may see others refer to multitouch in X.org as simply XInput 2.1. We hatched our plan back at UDS-N to push hard on developing the XInput 2.1 protocol and implementing it as best as possible in 11.04. The idea was that Ubuntu would be a test bed for the protocol before it is adopted by X.org upstream.

We’re now past feature freeze for Ubuntu 11.04 and nearing the beta release. How well has the plan worked? I believe we’ve been mostly successful. 11.04 includes a pre-release version of XInput 2.1, and we’ve even got support for multitouch through Qt! However, working around issues in the existing X protocol has provided many challenges that became visible only after the initial implementation was developed. In 11.04 we have support for the major pieces of XInput 2.1, but we have since encountered a few corner cases that require a bit more work to get right. I will be writing another post about these challenges to give a better overview of the issues we are facing.

That said, what we have in Ubuntu 11.04 works pretty well. However, we need to set some boundaries so people aren’t caught off guard by changes from the XInput 2.1 implementation in Ubuntu 11.04 and what ends up in X.org’s X Server 1.11 and Ubuntu 11.10 later this year.

First, boundaries for developers. The XInput 2.1 protocol is still under review and has changed quite a bit since the version that has landed in Ubuntu 11.04. Most of the changes are cosmetic, such as renaming the macro XITouchOwnerReject to XITouchReject. However, there may be one or two major changes that affect protocol event handling. We suggest that developers eager to begin developing multitouch applications use Qt as its touch API is stable and will not change. Developers may use the XInput 2.1 implementation in 11.04, but they need to be aware that the protocol will change before it is officially released by X.org

Second, boundaries for users. The multitouch implementation in 11.04 covers most of the major use cases for multitouch. However, there are some corner cases that are not handled properly yet. As an example, the behavior in Ubuntu 11.04 is incorrect if you have multiple touches on a touchpad and then use a second mouse to move the cursor to a different window. That said, we believe that all typical multitouch usage will work fine. As a side note, OS X doesn’t handle atypical multitouch input in a reasonable or even predictable way, so we’re at least up to their standard!

I encourage anyone with multitouch hardware to play with the Qt touch examples. I find fingerpainting to be rather fun! You can run the examples by installing qt4-demos and then manually running them from the terminal:

$ sudo apt-get install qt4-demos
$ /usr/lib/qt4/examples/touch/fingerpaint/fingerpaint

There are three other demos: knobs, pinchzoom, and dials.

Thank you to all those who have provided feedback for XInput 2.1! I am looking forward to new touch support in Ubuntu applications!

March 11, 2011
Marek Olšák has made some bug fixes to the libtxc_dxtn library (a library for mesa to allow S3TC). First of all you can download the updated version from http://people.freedesktop.org/~cbrill/libtxc_dxtn/libtxc_dxtn-1.0.0.tar.gz. Next to that the source code location changed (the code can be found at http://cgit.freedesktop.org/~mareko/libtxc_dxtn/). Marek also replaced the build system of the library by autotools, but this is not released yet.

A recent discussion about if this library should be added to mesa shows that this is not a desired option. This is because it would require the end user to recmpile the whole mesa instead of this single package.

I'll be at the OrgCamp April 2011 in Paris next month. However, I'm not yet sure of what I'll talk about this time.

Flattr this
March 10, 2011

I was not blogging here for a while. But the project is still live.

The major event for all of us is going to be GNOME 3 release. There was a lot of changes in the keyboard configuration GUI (now it is search-based, wow!). There was a mockup of what the Regional/Language configuration could look like – and GNOME is very close to it. In order to facilitate that change, some fixes in xk-c would have to be done. Most important, the layout/variant descriptions have to be changed.

In GNOME2, the full variant description was composed of the layout description (usually country name) and the variant description itself. For example, “USA – International”. That schema does not allow creating variants like “Engish (US)”.

Now, the descriptions for variants are full and self-contained. That allows putting there any lines, for example “English (US)”. That is a better approach – but it requires someone to take the latest base.xml.in, walk through it and fix the descriptions. to make them user-friendly If this is done before GNOME3 release – I’ll try to make extra (out of schedule) release of xkeyboard-config. Volunteers, anyone?

PS Last couple of days I got another set of traditional enjoyment, related to Crimean Tartar variant. Here and here. The guy does not get something important…

Over the past few months, I've been working on a new server for Minecraft, called Bravo. I haven't made any blog posts about it, mostly because I haven't been blogging, but also because, frankly, there hasn't been much to say about it. Bravo is very featureful and robust, but is not at the level of the nicer servers, like Mineserver. However, I mention Bravo and Minecraft because I am going to outline a Minecraft server exploit which has a familiar moral which I have been championing lately.

March 09, 2011

We had two track proposals submitted that were omitted due to an editorial oversight:

  • Adam Jackson – Graphics/desktop
  • John Linville – Buffer bloat

We’ll be letting track owners know if their track has been selected next week.  Those who are selected will be able to use our paper tracking system to track topic owners and discussion agendas for the conference.

Our group is now in HackWeek 6, quite a few weeks delayed after all other groups at SuSE. I will use the time to (finally!) continue work on RAnsrID - see also my initial blog entry. The project source is hosted on gitorious.

The basic redundancy routines are all working already, next is a usable test suite, then run-time configuration management (live adding and removing disks, live reconstruction w/o repair in the read error case).

I doubt I will reach a final version 1.0 I can recommend to use, but it will hopefully be close.

A few weeks ago, I was looking at what was still using an old version of XULRunner in openSUSE, and one of the few applications that was left with no port to XULRunner 2 (the one that will be out with Firefox 4) was gnome-web-photo. In case you don't know gnome-web-photo, it's a small utility originally written by Christian Persch, to capture screenshots of a web page, which can also be used to generate a thumbnail for web pages. It's actually the main reason why we care about it in openSUSE: having a thumbnailer for HTML files is a nice little touch.

So I look at porting gnome-web-photo to XULRunner 2, and... I felt some pain. I asked Christian about his plans and if he thought porting this utility to WebKit could be a good idea. As Christian was not working on it actively, he was open to the idea. After a few hours of coding (WebKitGTK+ is really cool, with its easy-to-use API), a rewrite was ready.

I did some more cleanup and added the option to print directly a web page to a printer, and then released gnome-web-photo 0.10. The only real regression, as far as I know, is that it won't handle correctly very tall web pages (like this one): it will simply cut the web page, because we're hitting some limits in some libraries below us. This is probably fixable by scrolling the page and writing the resulting image ourselves, but I really wanted to get the rewrite out and I'm not even sure people would notice this regression ;-)

Enjoy!

March 07, 2011

Every once in a while, I fall into a trap that causes me to care about a specific topic. Last week, this happened for the Google Summer of Code 2011.

Twice.

I'm apparently going to be a GSoC co-admin for both GNOME and openSUSE, assuming the two organizations get accepted. But I'm not unhappy about that, since GSoC is one really amazing opportunity for free software projects to get useful contributions, but more importantly, to introduce new people to the projects. People who will stay as contributors later on, if we do a good job at making them feel welcome.

GNOME

GNOME has participated to all GSoC, and that's something we're very proud of. The best part is that past students have become highly involved in GSoC in later years, with some of them being the main admins for GNOME. We usually have a team of several admins (at least four), and everybody has experience of GSoC, so organizing our participation is probably easier than for many projects. We've put all of our GSoC documentation online, and that's really the place to visit if you want to be a mentor or student for GSoC on a GNOME-related project.

We've just started collecting project ideas. If you work on something GNOME-related (or a cross-desktop technology), don't hesitate to add your project ideas there. The admin team will triage the list of ideas later on, so don't worry if your idea seems to be lost in a big list of ideas :-) Christophe will send a proper request for ideas in the next few days (if he hasn't already, I haven't read all my mails).

With GNOME 3 just around the corner, there is without a doubt a good opportunity to attract students: those are exciting times for GNOME where a student could make a big difference for 3.2/3.4 with a single project, and become a core actor of the GNOME 3 development, and therefore of the GNOME community!

openSUSE

For openSUSE, things are different: we participated three times (2006, 2008 and 2009), and our application was unfortunately rejected last year. So a few people worked hard in the past few weeks to increase our chances to participate this year (special thanks to Manu who did a good part of the job).

We gathered all the relevant information on the wiki and our community already offered many different project ideas (roughly 40, as of right now). What's exciting is with openSUSE, we offer topics ranging from low-level C code to Ruby on Rails, from infrastructure tools to end-user features, from openSUSE-specific topics to cross-distribution ones, etc. Our list of ideas is extremely broad, and we believe the technologies we cover are exciting for students. Thanks to this preliminary work, we've already got several students contacting us about the projects. Isn't that cool?

As the openSUSE Foundation might not be setup in time to receive GSoC money, we're considering various options as to what to do with the money. The two main contenders are leaving the money to Google for future similar initiatives (GSoC or Code-In, for example), and giving the money to another non-profit organization that we believe is important. We welcome feedback on this, so raise your voice if you have an opinion :-)

March 06, 2011

We’re still accepting track proposals, but things have been filling up quickly lately, so if you have an idea for a track, please submit it soon to lpc-planning@linuxplumbersconf.org.  The submitted list so far:

  • Lennart Pottering – Boot/Init
  • Lennart Pottering – Audio
  • James Bottomley – Filesystems/storage
  • Daniel Stone – Mobile
  • Julia Lawall – Development tools
  • Darren Hart – Embedded build systems
  • Jes Sorensen – Virtualization
  • Thomas Gleixner (tentative) – Realtime
  • Paul McKenney – Scaling (both up & down)
  • (Various candidates) – Cloud
  • Rafael Wysocki – Power management

We’ll be notifying proposers about their tracks in the coming weeks (target date is March 15th), at which time we’ll open up registration and send out a call for papers, which will fill out the other half of the conference.

March 04, 2011

Andreas announced it yesterday: we're now all set for the release of openSUSE 11.4, with the final ISO being ready. The official release will occur next Thursday, on March 10th (we're giving a full week to mirrors so they can synchronize everything).Obviously we should all celebrate this release with a launch party!

There'll be such a party in Paris, at the Flam's near Châtelet on Saturday, March 19th at 19:30. This will be a great opportunity to meet other people from the openSUSE community in France! And if you can't come to Paris, then why not organize a party near your place?

If you want to attend the Paris launch party, please add your name to the wiki page so we can make an appropriate reservation.

If you wonder what comes next for the openSUSE-GNOME team, this answer is simple: GNOME 3 goodness! Frédéric already did most of the job, and we'll integrate that properly so that 11.4 users can enjoy GNOME 3 next month. Stay tuned...

So you think your favourite FOSS project is moving too fast? Easy, just DOS the developers. Here's a few tips on how to achieve this:

On IRC



  • If you have a problem, just state that you have a problem. Let the developer ask for what exactly it is. Then answer every question with the minimum amount of information possible and let the developer keep asking.

  • Wait 5 minutes before answering but keep asking why the developer doesn't answer immediately. That way you can maximise the context switching costs of the developer, ensuring he or she can't get anything else done while waiting for you.

  • If the developer asks for version numbers, be vague. Things like "whatever was in $DISTRO three days ago" is best because unless the developer is also the distro maintainer, you've answered the question without providing any information.

  • Don't stay on IRC. Just go offline whenever your computer goes to sleep and re-ask the question every time you reconnect. This way you ensure that those not monitoring the channel will try to answer the questions whenever you're currently offline. Never send email to the list, because others could answer it in their own time.



Via email



  • Send bug reports to the developers directly. That way you force them to reply with at least "please file a bug in $BUGZILLA". That takes 2 min of their time, not counting context switches. Make sure you reply with more than one "thank you" email so they need to deal with more email.

  • Randomly remove the CC from mailing lists during discussions. That way you make sure the developer has to answer twice if they didn't notice the CC was missing.

  • When taking discussions back onto the list, misquote (or purposely misinterpret) the results of the private discussion. Force the developer to justify themselves in public.

  • Be verbose. As verbose you can be. If you can say something in one sentence or three paragraphs (with three overlapping or identical examples), choose the latter. Searching for signal in lots of noise is a favourite pasttime of many developers.

  • If you change the subject of a discussion, leave the email subject as-is. This way you ensure that the email cannot easily be found later. Wait for a few weeks, then refer to this discussion, but not in the same thread.

  • Pastebin everything instead of including it in emails. Links to websites, backtraces, log files, patches, etc. Make sure the pastebin has a short expiry date.

  • If you must include something as attachment, make sure it's at least in a zipfile so no-one can look at it without a few mouse-clicks first.



Via code



  • When commenting on patches, reply with vague statements on how the patch doesn't work. This way, the patch is made to look bad and the developer now has to spend time making sure your vague statements weren't just unfounded.

  • When testing code, make sure you don't explain how a bug happend. Just say "after a while it crashed", that's enough information for anyone to figure out what's going wrong.

  • Read The Daily WTF and gain inspiration for your next open source project. If you ever get other people helping you, you maximise their pain.

  • Don't document anything. Just use arbitrary hardcoded values, with no explanation.

  • Never, ever, explain why you're doing something. Code is not meant to be self-explanatory.

  • Don't follow anything I said in on commit messages

  • Do everything as complicated as possible but don't explain why. Obfuscating that you're flipping the sign of a variable three to four times is a good example, anyone reading the code is sure to spend hours on it

  • Use numbers as both bools and numbers. C is great for that, you can return 2 and then use it as Boolean and as actual numeric value lateron. Hide any such usage as well as you can.

  • When sending patches, mix code changes with arbitrary whitespace changes. Fun minutes can be spend looking at two identical lines trying to find the difference that's missing.

  • When sending updated versions of a patch, don't tell anyone what has changed. That way, you force your reviewers to review the whole patch, every time you change a single character.

  • When sending patches, make sure that it only fixes the problem on your specific setup. That way you also can tell the developers off for not merging an important bugfix that clearly works when you tested it. And you force them to reply to you.



Those are just the immediate things that come to my mind. If the project is already low on manpower, any of these will have a high impact. If it has enough developers, you may need to use several of them at once to tie up the most resources. Of course all this requires developers that still think that communicating with users is worthwile and that other people generally tell the truth. If they have given up on humanity, they may just ignore you and keep improving the project. In that case, you can at least badmouth everyone on tech "news" sites forums and comments.

Oh, in case you're wondering why I don't get anything done lately, see above. I realise that probably none of it is intentional, though the net effect is the same.
March 02, 2011

It has been a while since the last installment of my systemd for Administrators series, but now with the release of Fedora 15 based on systemd looming, here's a new episode:

The Three Levels of "Off"

In systemd, there are three levels of turning off a service (or other unit). Let's have a look which those are:

  1. You can stop a service. That simply terminates the running instance of the service and does little else. If due to some form of activation (such as manual activation, socket activation, bus activation, activation by system boot or activation by hardware plug) the service is requested again afterwards it will be started. Stopping a service is hence a very simple, temporary and superficial operation. Here's an example how to do this for the NTP service:

    $ systemctl stop ntpd.service

    This is roughly equivalent to the following traditional command which is available on most SysV inspired systems:

    $ service ntpd stop

    In fact, on Fedora 15, if you execute the latter command it will be transparently converted to the former.

  2. You can disable a service. This unhooks a service from its activation triggers. That means, that depending on your service it will no longer be activated on boot, by socket or bus activation or by hardware plug (or any other trigger that applies to it). However, you can still start it manually if you wish. If there is already a started instance disabling a service will not have the effect of stopping it. Here's an example how to disable a service:

    $ systemctl disable ntpd.service

    On traditional Fedora systems, this is roughly equivalent to the following command:

    $ chkconfig ntpd off

    And here too, on Fedora 15, the latter command will be transparently converted to the former, if necessary.

    Often you want to combine stopping and disabling a service, to get rid of the current instance and make sure it is not started again (except when manually triggered):

    $ systemctl disable ntpd.service
    $ systemctl stop ntpd.service

    Commands like this are for example used during package deinstallation of systemd services on Fedora.

    Disabling a service is a permanent change; until you undo it it will be kept, even across reboots.

  3. You can mask a service. This is like disabling a service, but on steroids. It not only makes sure that service is not started automatically anymore, but even ensures that a service cannot even be started manually anymore. This is a bit of a hidden feature in systemd, since it is not commonly useful and might be confusing the user. But here's how you do it:

    $ ln -s /dev/null /etc/systemd/system/ntpd.service
    $ systemctl daemon-reload

    By symlinking a service file to /dev/null you tell systemd to never start the service in question and completely block its execution. Unit files stored in /etc/systemd/system override those from /lib/systemd/system that carry the same name. The former directory is administrator territory, the latter terroritory of your package manager. By installing your symlink in /etc/systemd/system/ntpd.service you hence make sure that systemd will never read the upstream shipped service file /lib/systemd/system/ntpd.service.

    systemd will recognize units symlinked to /dev/null and show them as masked. If you try to start such a service manually (via systemctl start for example) this will fail with an error.

    A similar trick on SysV systems does not (officially) exist. However, there are a few unofficial hacks, such as editing the init script and placing an exit 0 at the top, or removing its execution bit. However, these solutions have various drawbacks, for example they interfere with the package manager.

    Masking a service is a permanent change, much like disabling a service.

Now that we learned how to turn off services on three levels, there's only one question left: how do we turn them on again? Well, it's quite symmetric. use systemctl start to undo systemctl stop. Use systemctl enable to undo systemctl disable and use rm to undo ln.

And that's all for now. Thank you for your attention!

March 01, 2011

In case you haven't noticed yet: the Call For Participation for the Desktop Summit 2011 (aka GUADEC 2011, aka Akademy 2011) in Berlin, Germany is open since yesterday. Submissions will be accepted until March 25th, so make sure to submit your proposals quickly.

I spend too much time writing Emacs Lisp code these days. Unfortunately, the more I do the more I find new useful tools to improve my work-flow and save time for doing more Lisp. D'oh.

I did not work on any big thing these last weeks, so I'm thinking it's a good time to talk about the various code and patches I sent to multiple Emacs packages.

el-get

el-get, a fabulous tool that installs and handles all the external Emacs packages I use. A friendly war started on the development list about autoloads handling. The discussion was overall pointless, since we had a very hard time to communicate our ideas, and we did not understand each others several times.

In the end, el-get now supports autoload correctly and do not load automatically all your packages, improving the startup time, and using the Emacs way to do things. Which is always better, obviously.

git-commit-mode

I've started to use git-commit-mode some times ago. I usually use git-commit with the -v option to see what I'm committing. I though it would be useful to color the diff with diff-mode, so I wrote a patch just to do that, which was merged today by Florian.

magit

Some weeks ago, I decided to give a try to magit, and loved it. I am not always using it, but for basic operations it is very useful. But I really soon found some things I did not like and therefore send patches to enhance it.

First, I've added a patch to honor status.showUntrackedFiles which I use in my home directory. In the mean time, I've also added a patch to allow adding an arbitrary file.

Yesterday, I sent another pull request, not closed for now, which adds the possibility to visit files in another window from a diff file, and the support for add-change-log-entry directly from the displayed diff. Useful for these old projects still using ChangeLog files but accessible through git (hi Emacs & Gnus!).

Gnus

Nothing remarkable, but I write a couple of fixes and enhancements to the Sieve manage mode, to the Gravatar code and cleaned-up some very very old code. Also added the possibility to set list-identifier as a group parameter.

Org-mode

I spent most of my time working on my jd/agenda-format branch, which is soon to be merged. I've also just got developer access to the Org-mode patch work and repository, so I'll be able to break things even more! ;-)

ERC

I fixed the bug that annoyed me for a long time. Now erc-track does not reset the last channel status on window visibility changes not made by the user.

Flattr this

Following is the census of 1.10 window for all X infrastructure – raw numbers here. I did it in a similar way as the previous version. Worth to mention that there’s almost no relation between the cycles of development from each of the components listed below, which can lead to some misunderstanding. Anyway, still a nice indicative to see and evaluate how the free desktop community behaved.

Numbers for X implementation (xserver, proto, lib and xcb repositories):

Processed 1258 csets from 93 developers
70 employers found
A total of 139275 lines added, 58982 removed (delta 80293)

Developers with the most changesets
Alan Coopersmith 243 (19.3%)
Gaetan Nadon 193 (15.3%)
Peter Hutterer 121 (9.6%)
Adam Jackson 94 (7.5%)
Jon TURNEY 43 (3.4%)
Keith Packard 37 (2.9%)
Jeremy Huddleston 36 (2.9%)
Jesse Adkins 34 (2.7%)
Pauli Nieminen 29 (2.3%)
Jamey Sharp 28 (2.2%)

Developers with the most changed lines
Matt Dew 57959 (35.7%)
Jeremy Huddleston 25002 (15.4%)
Fernando Carrijo 16739 (10.3%)
Gaetan Nadon 15750 (9.7%)
Alan Coopersmith 11850 (7.3%)
Adam Jackson 4273 (2.6%)
Keith Packard 2754 (1.7%)
Jesse Adkins 2516 (1.5%)
Peter Hutterer 2083 (1.3%)
James Jones 1876 (1.2%)

Developers with the most lines removed
Jeremy Huddleston 3726 (6.3%)
Adam Jackson 3617 (6.1%)
Jesse Adkins 2489 (4.2%)
Jamey Sharp 1497 (2.5%)
Søren Sandmann Pedersen 757 (1.3%)
James Cloos 187 (0.3%)
Adrian Bunk 184 (0.3%)
Tiago Vignatti 118 (0.2%)
Jon TURNEY 116 (0.2%)
Chris Wilson 72 (0.1%)

Developers with the most signoffs (total 1429)
Alan Coopersmith 315 (22.0%)
Peter Hutterer 191 (13.4%)
Gaetan Nadon 174 (12.2%)
Keith Packard 133 (9.3%)
Adam Jackson 96 (6.7%)
Jon TURNEY 52 (3.6%)
Jeremy Huddleston 36 (2.5%)
Jesse Adkins 34 (2.4%)
Pauli Nieminen 30 (2.1%)
Jamey Sharp 29 (2.0%)

Developers with the most reviews (total 882)
Alan Coopersmith 83 (9.4%)
Daniel Stone 78 (8.8%)
Peter Hutterer 76 (8.6%)
Julien Cristau 73 (8.3%)
Keith Packard 61 (6.9%)
Adam Jackson 49 (5.6%)
Mikhail Gusarov 41 (4.6%)
Jeremy Huddleston 38 (4.3%)
Colin Harrison 38 (4.3%)
Chase Douglas 35 (4.0%)

Developers with the most test credits (total 48)
Colin Harrison 16 (33.3%)
Gaetan Nadon 6 (12.5%)
Cyril Brulebois 5 (10.4%)
Alan Coopersmith 3 (6.2%)
Jeremy Huddleston 2 (4.2%)
Julien Cristau 1 (2.1%)
Aaron Plattner 1 (2.1%)
Luc Verhaegen 1 (2.1%)
Dirk Wallenstein 1 (2.1%)
Simon Thum 1 (2.1%)

Developers who gave the most tested-by credits (total 48)
Jon TURNEY 16 (33.3%)
Peter Hutterer 8 (16.7%)
Alan Coopersmith 7 (14.6%)
Dan Nicholson 4 (8.3%)
Michel Dänzer 2 (4.2%)
Gaetan Nadon 1 (2.1%)
Jeremy Huddleston 1 (2.1%)
Julien Cristau 1 (2.1%)
Aaron Plattner 1 (2.1%)
Luc Verhaegen 1 (2.1%)

Developers with the most report credits (total 21)
Julien Cristau 2 (9.5%)
Justin Mattock 2 (9.5%)
Peter Hutterer 1 (4.8%)
Aaron Plattner 1 (4.8%)
Cyril Brulebois 1 (4.8%)
Simon Thum 1 (4.8%)
Thierry Vignaud 1 (4.8%)
meng 1 (4.8%)
Sebastian Glita 1 (4.8%)
Bartosz Brachaczek 1 (4.8%)

Developers who gave the most report credits (total 21)
Peter Hutterer 7 (33.3%)
Julien Cristau 3 (14.3%)
Jamey Sharp 3 (14.3%)
Alan Coopersmith 2 (9.5%)
Eamon Walsh 2 (9.5%)
Michel Dänzer 1 (4.8%)
Gaetan Nadon 1 (4.8%)
Kristian Høgsberg 1 (4.8%)
Jesse Barnes 1 (4.8%)

Top changeset contributors by employer
Oracle 244 (19.4%)
Red Hat 225 (17.9%)
memsize@videotron.ca 193 (15.3%)
Nokia 122 (9.7%)
Intel 46 (3.7%)
jon.turney@dronecode.org.uk 43 (3.4%)
Apple 36 (2.9%)
jesserayadkins@gmail.com 34 (2.7%)
NVidia 30 (2.4%)
jamey@minilop.net 28 (2.2%)

Top lines changed by employer
matt@osource.org 57958 (35.7%)
Apple 27540 (17.0%)
fcarrijo.lists@gmail.com 16729 (10.3%)
memsize@videotron.ca 16611 (10.2%)
Oracle 14567 (9.0%)
Red Hat 8089 (5.0%)
Intel 4574 (2.8%)
Nokia 3153 (1.9%)
jesserayadkins@gmail.com 2528 (1.6%)
jon.turney@dronecode.org.uk 2110 (1.3%)

Employers with the most signoffs (total 1429)
Oracle 315 (22.0%)
Red Hat 293 (20.5%)
memsize@videotron.ca 174 (12.2%)
Intel 144 (10.1%)
Nokia 127 (8.9%)
jon.turney@dronecode.org.uk 52 (3.6%)
Apple 36 (2.5%)
jesserayadkins@gmail.com 34 (2.4%)
NVidia 29 (2.0%)
jamey@minilop.net 29 (2.0%)

Employers with the most hackers (total 96)
Red Hat 8 (8.3%)
Nokia 8 (8.3%)
Intel 7 (7.3%)
Canonical 3 (3.1%)
VMWare 3 (3.1%)
Oracle 2 (2.1%)
NVidia 2 (2.1%)
memsize@videotron.ca 1 (1.0%)
jon.turney@dronecode.org.uk 1 (1.0%)
Apple 1 (1.0%)

Development of X input drivers and input event processing tools (xf86-input-*, xkbcomp, xkeyboard-config repositories):

Processed 293 csets from 33 developers
29 employers found
A total of 34645 lines added, 26556 removed (delta 8089)

Developers with the most changesets
Peter Hutterer 152 (51.9%)
Sergey V. Udaltsov 32 (10.9%)
Alexandr Shadchin 21 (7.2%)
Alan Coopersmith 17 (5.8%)
Gaetan Nadon 12 (4.1%)
Trevor Woerner 6 (2.0%)
Nikolai Kondrashov 5 (1.7%)
Chase Douglas 4 (1.4%)
Simon Thum 4 (1.4%)
Joe Shaw 3 (1.0%)

Developers with the most changed lines
Sergey V. Udaltsov 30425 (79.0%)
Peter Hutterer 3377 (8.8%)
Alexandr Shadchin 1263 (3.3%)
Alan Coopersmith 806 (2.1%)
Chase Douglas 572 (1.5%)
Denis 'GNUtoo' Carikli 180 (0.5%)
Simon Thum 133 (0.3%)
Gaetan Nadon 110 (0.3%)
Bryce Harrington 99 (0.3%)
Nikolai Kondrashov 81 (0.2%)

Developers with the most lines removed
Alexandr Shadchin 1239 (4.7%)
Alan Coopersmith 739 (2.8%)
Chase Douglas 418 (1.6%)
Peter Hutterer 183 (0.7%)
Gaetan Nadon 61 (0.2%)
Peter Korsgaard 51 (0.2%)
Nikolai Kondrashov 35 (0.1%)
Jesse Adkins 16 (0.1%)
Javier Acosta 6 (0.0%)
Adam Jackson 6 (0.0%)

Developers with the most signoffs (total 304)
Peter Hutterer 197 (64.8%)
Alan Coopersmith 25 (8.2%)
Alexandr Shadchin 21 (6.9%)
Gaetan Nadon 11 (3.6%)
Trevor Woerner 6 (2.0%)
Nikolai Kondrashov 5 (1.6%)
Thomas Hellstrom 5 (1.6%)
Chase Douglas 4 (1.3%)
Simon Thum 4 (1.3%)
Joe Shaw 3 (1.0%)

Developers with the most reviews (total 126)
Trevor Woerner 37 (29.4%)
Alan Coopersmith 25 (19.8%)
Benjamin Tissoires 11 (8.7%)
Chris Bagwell 9 (7.1%)
Daniel Stone 9 (7.1%)
Chase Douglas 8 (6.3%)
Adam Jackson 7 (5.6%)
Cyril Brulebois 6 (4.8%)
Matt Turner 5 (4.0%)
Peter Hutterer 3 (2.4%)

Developers with the most test credits (total 25)
Alan Coopersmith 23 (92.0%)
Benjamin Tissoires 1 (4.0%)
Abdoulaye Walsimou Gaye 1 (4.0%)

Developers who gave the most tested-by credits (total 25)
Peter Hutterer 24 (96.0%)
Gaetan Nadon 1 (4.0%)

Developers with the most report credits (total 2)
Dave Airlie 2 (100.0%)

Developers who gave the most report credits (total 2)
Peter Hutterer 2 (100.0%)

Top changeset contributors by employer
Red Hat 155 (52.9%)
svu@gnome.org 32 (10.9%)
alexandr.shadchin@gmail.com 21 (7.2%)
Oracle 18 (6.1%)
memsize@videotron.ca 12 (4.1%)
twoerner@gmail.com 6 (2.0%)
Canonical 6 (2.0%)
spbnick@gmail.com 5 (1.7%)
simon.thum@gmx.de 4 (1.4%)
VMWare 3 (1.0%)

Top lines changed by employer
svu@gnome.org 30437 (79.1%)
Red Hat 4428 (11.5%)
alexandr.shadchin@gmail.com 1263 (3.3%)
Oracle 825 (2.1%)
Canonical 713 (1.9%)
gnutoo@no-log.org 180 (0.5%)
simon.thum@gmx.de 133 (0.3%)
memsize@videotron.ca 113 (0.3%)
spbnick@gmail.com 93 (0.2%)
jacmet@sunsite.dk 59 (0.2%)

Employers with the most signoffs (total 304)
Red Hat 199 (65.5%)
Oracle 26 (8.6%)
alexandr.shadchin@gmail.com 21 (6.9%)
memsize@videotron.ca 11 (3.6%)
Canonical 6 (2.0%)
twoerner@gmail.com 6 (2.0%)
spbnick@gmail.com 5 (1.6%)
VMWare 5 (1.6%)
simon.thum@gmx.de 4 (1.3%)
joe@joeshaw.org 3 (1.0%)

Employers with the most hackers (total 33)
Red Hat 3 (9.1%)
Oracle 2 (6.1%)
Canonical 2 (6.1%)
alexandr.shadchin@gmail.com 1 (3.0%)
memsize@videotron.ca 1 (3.0%)
twoerner@gmail.com 1 (3.0%)
spbnick@gmail.com 1 (3.0%)
VMWare 1 (3.0%)
simon.thum@gmx.de 1 (3.0%)
joe@joeshaw.org 1 (3.0%)

for userspace video drivers (libdrm, mesa and all xf86-video-*):

Processed 5223 csets from 131 developers
100 employers found
A total of 452414 lines added, 289531 removed (delta 162883)

Developers with the most changesets
Brian Paul 579 (11.1%)
Eric Anholt 512 (9.8%)
Vinson Lee 432 (8.3%)
Dave Airlie 357 (6.8%)
Marek Olšák 324 (6.2%)
Chia-I Wu 252 (4.8%)
José Fonseca 247 (4.7%)
Kenneth Graunke 210 (4.0%)
Luca Barbieri 210 (4.0%)
Ian Romanick 190 (3.6%)

Developers with the most changed lines
Brian Paul 70178 (13.0%)
Luca Barbieri 58946 (10.9%)
Kenneth Graunke 35433 (6.5%)
Chia-I Wu 34790 (6.4%)
Ian Romanick 30961 (5.7%)
Jerome Glisse 28641 (5.3%)
Eric Anholt 27906 (5.2%)
Christoph Bumiller 22352 (4.1%)
Dave Airlie 21625 (4.0%)
Alex Deucher 19210 (3.5%)

Developers with the most lines removed
Kenneth Graunke 19727 (6.8%)
Matt Turner 3052 (1.1%)
Henri Verbeet 1398 (0.5%)
Kristian Høgsberg 832 (0.3%)
Adam Jackson 248 (0.1%)
Jesse Adkins 161 (0.1%)
Nicolas Kaiser 43 (0.0%)
Andre Maasikas 34 (0.0%)
Pierre Allegraud 17 (0.0%)
Patrice Mandin 17 (0.0%)

Developers with the most signoffs (total 930)
Chris Wilson 181 (19.5%)
Jerome Glisse 99 (10.6%)
Brian Paul 82 (8.8%)
Dave Airlie 81 (8.7%)
Alex Deucher 59 (6.3%)
Tilman Sauerbeck 44 (4.7%)
Thomas Hellstrom 40 (4.3%)
Alan Coopersmith 30 (3.2%)
Jakob Bornecrantz 29 (3.1%)
Daniel Vetter 28 (3.0%)

Developers with the most reviews (total 69)
Jakob Bornecrantz 23 (33.3%)
Ian Romanick 10 (14.5%)
Eric Anholt 9 (13.0%)
Julien Cristau 6 (8.7%)
Mikhail Gusarov 4 (5.8%)
Brian Paul 2 (2.9%)
Alex Deucher 2 (2.9%)
Matt Turner 2 (2.9%)
José Fonseca 2 (2.9%)
Michel Dänzer 2 (2.9%)

Developers with the most test credits (total 6)
Guillermo S. Romero 1 (16.7%)
Michel Hermier 1 (16.7%)
Sitsofe Wheeler 1 (16.7%)
Bjørn Mork 1 (16.7%)
Michal Marek 1 (16.7%)
Manoj Iyer 1 (16.7%)

Developers who gave the most tested-by credits (total 6)
Chris Wilson 2 (33.3%)
Guillermo S. Romero 1 (16.7%)
Xiang, Haihao 1 (16.7%)
Xavier Chantry 1 (16.7%)
Jesse Barnes 1 (16.7%)

Developers with the most report credits (total 23)
Julien Cristau 2 (8.7%)
Matthias Hopf 2 (8.7%)
Jeff Chua 2 (8.7%)
Sitsofe Wheeler 1 (4.3%)
Bjørn Mork 1 (4.3%)
Michal Marek 1 (4.3%)
José Fonseca 1 (4.3%)
Daniel Vetter 1 (4.3%)
Cyril Brulebois 1 (4.3%)
Peter Clifton 1 (4.3%)

Developers who gave the most report credits (total 23)
Chris Wilson 19 (82.6%)
Xiang, Haihao 2 (8.7%)
Ian Romanick 1 (4.3%)
Kenneth Graunke 1 (4.3%)

Top changeset contributors by employer
VMWare 1582 (30.3%)
Intel 1292 (24.7%)
Red Hat 546 (10.5%)
maraeo@gmail.com 324 (6.2%)
LunarG 252 (4.8%)
luca@luca-barbieri.com 210 (4.0%)
e0425955@student.tuwien.ac.at 158 (3.0%)
AMD 156 (3.0%)
hverbeet@gmail.com 65 (1.2%)
currojerez@riseup.net 60 (1.1%)

Top lines changed by employer
Intel 132677 (24.5%)
VMWare 105087 (19.4%)
Red Hat 87373 (16.1%)
luca@luca-barbieri.com 67407 (12.5%)
LunarG 38973 (7.2%)
e0425955@student.tuwien.ac.at 22548 (4.2%)
AMD 19690 (3.6%)
maraeo@gmail.com 14329 (2.6%)
richard@richard-desktop3.(none) 12426 (2.3%)
noviktor@seznam.cz 11676 (2.2%)

Employers with the most signoffs (total 930)
Intel 235 (25.3%)
Red Hat 215 (23.1%)
VMWare 159 (17.1%)
AMD 59 (6.3%)
tilman@code-monkey.de 44 (4.7%)
Oracle 30 (3.2%)
daniel.vetter@ffwll.ch 28 (3.0%)
jesserayadkins@gmail.com 24 (2.6%)
currojerez@riseup.net 18 (1.9%)
mattst88@gmail.com 12 (1.3%)

Employers with the most hackers (total 138)
Intel 17 (12.3%)
VMWare 13 (9.4%)
Red Hat 7 (5.1%)
Canonical 4 (2.9%)
Novell 2 (1.4%)
AMD 1 (0.7%)
tilman@code-monkey.de 1 (0.7%)
Oracle 1 (0.7%)
daniel.vetter@ffwll.ch 1 (0.7%)
jesserayadkins@gmail.com 1 (0.7%)

Pixman library (pixman):

Processed 223 csets from 15 developers
12 employers found
A total of 10985 lines added, 6139 removed (delta 4846)

Developers with the most changesets
Søren Sandmann Pedersen 124 (55.6%)
Siarhei Siamashka 64 (28.7%)
Andrea Canciani 11 (4.9%)
Dmitri Vorobiev 5 (2.2%)
Rolland Dudemaine 4 (1.8%)
Cyril Brulebois 2 (0.9%)
Jon TURNEY 2 (0.9%)
Liu Xinyun 2 (0.9%)
Maarten Bosmans 2 (0.9%)
Benjamin Otte 2 (0.9%)

Developers with the most changed lines
Søren Sandmann Pedersen 6335 (45.3%)
Siarhei Siamashka 3119 (22.3%)
Liu Xinyun 1318 (9.4%)
Jonathan Morton 721 (5.2%)
Andrea Canciani 586 (4.2%)
Dmitri Vorobiev 62 (0.4%)
Benjamin Otte 62 (0.4%)
Maarten Bosmans 56 (0.4%)
Rolland Dudemaine 32 (0.2%)
Mika Yrjola 7 (0.1%)

Developers with the most lines removed
Liu Xinyun 1318 (21.5%)
Maarten Bosmans 11 (0.2%)
Rolland Dudemaine 2 (0.0%)

Developers with the most signoffs (total 7)
Cyril Brulebois 2 (28.6%)
Jon TURNEY 2 (28.6%)
Liu Xinyun 1 (14.3%)
Alan Coopersmith 1 (14.3%)
Chen Miaobo 1 (14.3%)

Developers with the most reviews (total 1)
Matt Turner 1 (100.0%)

Developers with the most test credits (total 0)

Developers who gave the most tested-by credits (total 0)

Developers with the most report credits (total 0)

Developers who gave the most report credits (total 0)

Top changeset contributors by employer
Red Hat 126 (56.5%)
Nokia 64 (28.7%)
ranma42@gmail.com 11 (4.9%)
Movial 7 (3.1%)
rolland@ghs.com 4 (1.8%)
jon.turney@dronecode.org.uk 2 (0.9%)
kibi@debian.org 2 (0.9%)
mkbosmans@gmail.com 2 (0.9%)
Intel 2 (0.9%)
Oracle 1 (0.4%)

Top lines changed by employer
Red Hat 7969 (57.0%)
Nokia 3156 (22.6%)
Intel 1318 (9.4%)
Movial 805 (5.8%)
ranma42@gmail.com 619 (4.4%)
mkbosmans@gmail.com 57 (0.4%)
rolland@ghs.com 40 (0.3%)
tml@iki.fi 7 (0.1%)
jon.turney@dronecode.org.uk 6 (0.0%)
kibi@debian.org 2 (0.0%)

Employers with the most signoffs (total 7)
Intel 2 (28.6%)
jon.turney@dronecode.org.uk 2 (28.6%)
kibi@debian.org 2 (28.6%)
Oracle 1 (14.3%)

Employers with the most hackers (total 15)
Movial 3 (20.0%)
Red Hat 2 (13.3%)
Intel 1 (6.7%)
jon.turney@dronecode.org.uk 1 (6.7%)
kibi@debian.org 1 (6.7%)
Oracle 1 (6.7%)
Nokia 1 (6.7%)
ranma42@gmail.com 1 (6.7%)
mkbosmans@gmail.com 1 (6.7%)
rolland@ghs.com 1 (6.7%)

X11 comformance’s XTS, taken from Peter’s repository:

Processed 36 csets from 2 developers
2 employers found
A total of 3114 lines added, 3339 removed (delta -225)

Developers with the most changesets
Peter Hutterer 21 (58.3%)
Aaron Plattner 14 (38.9%)

Developers with the most changed lines
Peter Hutterer 3242 (90.0%)
Aaron Plattner 136 (3.8%)

Developers with the most lines removed
Peter Hutterer 264 (7.9%)

Developers with the most signoffs (total 35)
Peter Hutterer 21 (60.0%)
Aaron Plattner 14 (40.0%)

Developers with the most reviews (total 4)
Joe Kain 2 (50.0%)
Adam Cheney 2 (50.0%)

Developers with the most test credits (total 0)

Developers who gave the most tested-by credits (total 0)

Developers with the most report credits (total 0)

Developers who gave the most report credits (total 0)

Top changeset contributors by employer
Red Hat 21 (58.3%)
NVidia 14 (38.9%)

Top lines changed by employer
Red Hat 3402 (94.4%)
NVidia 200 (5.6%)

Employers with the most signoffs (total 35)
Red Hat 21 (60.0%)
NVidia 14 (40.0%)

Employers with the most hackers (total 2)
Red Hat 1 (50.0%)
NVidia 1 (50.0%)

X documentation (doc repository):

Processed 108 csets from 7 developers
7 employers found
A total of 28556 lines added, 212807 removed (delta -184251)

Developers with the most changesets
Alan Coopersmith 57 (52.8%)
Gaetan Nadon 45 (41.7%)
Matt Dew 2 (1.9%)
Peter Hutterer 1 (0.9%)
Samuel Thibault 1 (0.9%)
Jesse Adkins 1 (0.9%)
Marc Balmer 1 (0.9%)

Developers with the most changed lines
Gaetan Nadon 146676 (67.0%)
Matt Dew 59191 (27.0%)
Alan Coopersmith 6927 (3.2%)
Samuel Thibault 7 (0.0%)
Jesse Adkins 7 (0.0%)
Peter Hutterer 3 (0.0%)
Marc Balmer 3 (0.0%)

Developers with the most lines removed
Gaetan Nadon 129581 (60.9%)
Matt Dew 52738 (24.8%)
Alan Coopersmith 1932 (0.9%)
Jesse Adkins 7 (0.0%)

Developers with the most signoffs (total 109)
Alan Coopersmith 59 (54.1%)
Gaetan Nadon 47 (43.1%)
Jesse Adkins 1 (0.9%)
Peter Hutterer 1 (0.9%)
Samuel Thibault 1 (0.9%)

Developers with the most reviews (total 28)
Alan Coopersmith 17 (60.7%)
Gaetan Nadon 4 (14.3%)
Peter Hutterer 2 (7.1%)
Daniel Stone 1 (3.6%)
Dan Nicholson 1 (3.6%)
Julien Cristau 1 (3.6%)
Matt Turner 1 (3.6%)
Adam Jackson 1 (3.6%)

Developers with the most test credits (total 0)

Developers who gave the most tested-by credits (total 0)

Developers with the most report credits (total 0)

Developers who gave the most report credits (total 0)

Top changeset contributors by employer
Oracle 57 (52.8%)
memsize@videotron.ca 45 (41.7%)
matt@osource.org 2 (1.9%)
Red Hat 1 (0.9%)
marc.balmer@arcapos.com 1 (0.9%)
samuel.thibault@ens-lyon.org 1 (0.9%)
jesserayadkins@gmail.com 1 (0.9%)

Top lines changed by employer
memsize@videotron.ca 152747 (69.7%)
matt@osource.org 59195 (27.0%)
Oracle 7088 (3.2%)
samuel.thibault@ens-lyon.org 7 (0.0%)
jesserayadkins@gmail.com 7 (0.0%)
Red Hat 3 (0.0%)
marc.balmer@arcapos.com 3 (0.0%)

Employers with the most signoffs (total 109)
Oracle 59 (54.1%)
memsize@videotron.ca 47 (43.1%)
samuel.thibault@ens-lyon.org 1 (0.9%)
jesserayadkins@gmail.com 1 (0.9%)
Red Hat 1 (0.9%)

Employers with the most hackers (total 7)
Oracle 1 (14.3%)
memsize@videotron.ca 1 (14.3%)
samuel.thibault@ens-lyon.org 1 (14.3%)
jesserayadkins@gmail.com 1 (14.3%)
Red Hat 1 (14.3%)
matt@osource.org 1 (14.3%)
marc.balmer@arcapos.com 1 (14.3%)

About Nokia and Microsoft alliance? I was deeply shocked yes, but well, I guess I’m cool and over it now. I’m sure MeeGo is not dead by any chance though… Nevertheless, Nokia’s contribution to X11 development will be obviously diminishing. It’s sad. Our Graphics Team were just feeling the first effects of the new introduced culture for pushing whatever work (well the ones we are allowed) to upstream and now all was cracked down. So, unfortunately this won’t happen with the same volume anymore and the collected numbers of 1.10 is definitely a mark for Nokia.


February 28, 2011

The latest drama sweeping across the open-source world is Canonical’s decision to redirect affiliate profits from music bought in the Banshee music player from 100% GNOME to a 25%/75% split (with Canonical receiving the majority). Nearly everyone has come out against this, but I disagree with parts of their argument. Also, everything I’ve seen has involved verbal wrist-slapping instead of concrete action, so I’m going to propose some possibilities.

“Open source” doesn’t mean “open source until someone makes a change you don’t like.” The whole premise of open source is that anyone can make any changes they want, they have the freedom to fork, and nothing restricts their actions besides copyright. Do we have a right to be angry at people who take advantage of the freedoms we’ve offered them? I don’t think so, but I see where people could disagree.

But what options does that leave anyone who wants to change the situation? Here’s a couple:

  • Banshee has a trademark; enforce it. Make Ubuntu change the name of its music player to something else. This would involve talking to lawyers and definitely takes this confrontation to the next level. If Banshee doesn’t already have legal contacts, its developers might contact the GNOME Foundation and work through them, or get in touch with SFLC or another legal team of their choice. If you want your code used in Ubuntu, maybe the name change is enough. But you’ll obviously lose the name recognition.
  • Banshee developers could treat Ubuntu as an unsupported configuration and refuse to work with affected users. For this to have any chance of working well for Banshee, it must require its developers to consistently place the blame on Canonical every time problems get reported, to preserve Banshee’s reputation. However, if you don’t support Ubuntu or its users, remember that most bugs aren’t specific to Ubuntu so you’re also hurting yourself. Furthermore, this could provoke Canonical to drop Banshee altogether and switch to a different player. I’d expect Canonical’s decisions to be based on a combination of usability, access to upstream support, and revenue, so its choices will likely try to find a balance of those factors.
  • Banshee developers could use rational approaches to convince Canonical its existing terms are inconsistent with the broader software world. OpenSUSE community manager Jos Poortvliet made a great point:  ”Even Apple doesn’t take more than a 30% cut from people who ship applications through their App Store.” However, this is the next level beyond that; Apple’s recent move to take a 30% cut of subscriptions, books, etc sold via App Store applications is far more equivalent. And this move, even by Apple, is seen as largely negative, but they’re staying the course much like Canonical. If I were Canonical, I’d ask myself how much my users love me compared to how much Apple users love Apple, and adjust my portion of the Banshee revenue accordingly.

I favor the third approach, but you should always keep in mind the best alternative to negotiation, so everyone on both sides of the conflict knows what will happen if negotiation fails.


Tagged: business, communication, community, gentoo, pr

Quoting code from Banshee:

    // We ask that no one change these affiliate codes. ALL (100%) revenue
    // generated by these affiliate IDs is sent directly to the GNOME
    // Foundation. The GNOME Foundation controls/owns these affiliate IDs.
    // Please help support Free Software through the GNOME Foundation!

I've been resisting blogging or talking about this topic publicly, but I'm so frustrated with how Canonical dealt with the whole topic that I can't resist more... If you don't want to read my stuff, I encourage you to go read Zonker's articles about the story.

Very short summary for those who didn't follow:

  • the Ubuntu community decided to switch to Banshee as default music player.
  • Canonical offers the Ubuntu One Music Store in the default Ubuntu music player to let people buy music online. Referral fees go to Canonical (as far as I know).
  • Banshee comes with an Amazon MP3 Store plugin to let people buy music online. Referral fees go to the GNOME Foundation.
  • with the switch to Banshee by default in Ubuntu, Canonical proposed two options to the Banshee developers: disable the Amazon MP3 Store plugin by default, or changing the affiliate code for the Amazon MP3 Store and giving 25% of the referral fees to the GNOME Foundation (the other 75% would be going to Canonical). Banshee developers chose to keep the money going to the GNOME Foundation, and to have the plugin disabled by default.
  • a few days later, Canonical changed their mind and decided that the Amazon MP3 Store would stay enabled, and that 25% of all referral fees (Amazon MP3 Store and Ubuntu One Music Store) would go to the GNOME Foundation.

There are a few things that are wrong with this story, and I've read a few things that made me wonder if some of the people standing for Canonical's decision in the comments I've read have a good understanding of everything (and maybe they do; everybody is entitled to his own opinions after all). It's worth pointing out first that I'm annoyed at Canonical, and not at Ubuntu, and my first two items below explain this:

Money does not go to Ubuntu. It goes to Canonical. I'll start with that, because I feel this was neglected by most. I would be much less annoyed if the money went to Ubuntu instead of Canonical. This way I would know that the money would be used for Free Software; I would still not be completely happy (see other points below), but that would make me feel better. But it turns out there is no active Ubuntu Foundation (the Ubuntu Foundation does exist, but is nowhere near active or alive), which means there is no real way for Ubuntu, as a project, to collect money. The result is that we have no idea how the money will be used, in concrete terms; and this raises accounting questions.

This is not an Ubuntu decision, this is a decision from Canonical. As far as I can tell, this decision was not discussed in any way inside the Ubuntu community, and I have serious concerns that such a decision that does affect Ubuntu is not taken by the Ubuntu community. I've added an agenda item to the next Community Council meeting (tomorrow, March 1st, at 21:00 UTC, in #ubuntu-meeting). To be blunt, though, I have absolutely no hope of open discussion there: I've yet to heard of anything that is agreed by the Community Council that goes against the interests of Canonical. I believe that is a serious flaw in the Ubuntu governance, and it's certainly not the first time this is highlighted.

It is legal, but it is not necessarily right. Of course it is legal because of Banshee's license. Nobody is arguing about that. However, the will of the Banshee developers is to donate money to the GNOME Foundation. They've expressed this will twice: when they first chose to donate the money to the GNOME Foundation, and when they chose one of the two options proposed by Canonical. So Canonical's decision is explicitly going against the will of the developers. It is legal, but going against the will of the developers is definitely wrong.

Releasing Banshee as free software doesn't mean Banshee developers don't care about how their software is changed or used. I've read several times that Banshee developers could simply have chosen another license to avoid this issue. That's an extremely dangerous slope: many free software developers choose a free software license because they believe in freedom and they believe that releasing their software under these terms will help improve the world in some way. That's our contribution to making the world a better place. We also believe that, usually, people will understand what we want to achieve and will respect that. Canonical's decision, and how it was taken, doesn't show any such respect. Should we stop contributing to making the world a better place because a company is doing things wrong? I don't think so. We should try to make that company a better citizen, and keep making the world a better place. Suggesting that we can simply choose a non-free license is suggesting that we stop trying to achieve our dreams. Sure, we could do that, but that's certainly not the right solution.

A 75%/25% deal does not reflect what Canonical brings to Banshee. I've read this several times: people think it's actually a fair deal because Ubuntu does most of the job, by integrating Banshee in Ubuntu and by exposing it to many more users. I'm disturbed when I read this. The fact is that Ubuntu chose to adopt Banshee by default because it was the best solution. If it was the best solution already, then somehow, the Banshee developers did a hell of a great job and Banshee actually improves Ubuntu. And that part is certainly more than 25% of the whole job, isn't it? I mean, if that's not the case, then certainly Ubuntu would be shipping with something better already. Also, this way of thinking gets me wondering: do people seriously suggest that Ubuntu would exist and be successful without great upstream developers? The work done to build Ubuntu is integration. It is not easy, there's no need to argue about that and I know this because I work on a distribution. So I know it's far from trivial. But compared to actually writing the applications upstream... Most of the hard work lives upstream, and integration, while key, is only a small percentage of the work. Even the argument that Ubuntu will bring more users falls apart for me because Ubuntu brings more users to applications, but only because those applications themselves are great. Ubuntu can only bring something to the applications because the applications bring something to Ubuntu.

No, a 75%/25% deal is not necessarily a better deal for the GNOME Foundation, money-wise. Several people mentioned that 25% of referrals fees of the plugin enabled by default is higher than 100% of referrals fees of the plugin disabled by default. How can we know? We can't. We simply don't know. I've heard that the Ubuntu One Music Store is... suboptimal, so I think it's also a fair position to assume that many people would have found on the web that there's a great Amazon MP3 Store plugin, and would have switched to it. It could therefore turn out that in the end, maybe, even if the plugin would have been disabled by default, it would have brought more money to the GNOME Foundation. Who's right? Let's be honest and agree that we don't know.

No, even if it's a better deal money-wise, a 75%/25% deal is not necessarily a better deal for the GNOME Foundation. You know what? Please don't put words in the mouth of the GNOME Foundation, and leave the GNOME Foundation decide for itself. The GNOME Foundation is a non-profit organization and while the GNOME Foundation could use more money, it's certainly not the goal of the Foundation. As a past Foundation Board member, my informed guess is that most members of the GNOME Foundation would agree that respecting the will of authors is more important than money. If the GNOME Foundation decided to take a public position about what is best for itself, it could well be something as simple as this deal is not in our best interests. I'm of course not saying this is the position of the GNOME Foundation since that's not my job, but I hope this helps people understand that more money doesn't make the deal a better one for the Foundation.

There is now no way to make the money go to the GNOME Foundation. With the current decision, there is no way for the user to choose to leave the money to the GNOME Foundation. I've seen at least a comment from Jono suggesting that Banshee could distribute a new plugin for that. I can certainly understand that Canonical doesn't want to do that itself, but Ubuntu people could. Is there any reason that Ubuntu can't ship this small plugin (17 KB) itself, on the CD, or even in a package in the Ubuntu repositories? If people would do the job, would the package get accepted on the CD? I don't want to guess, so I'll leave the question open.

The whole decision process is just alarmly broken. Canonical came with two options, and one was chosen by Banshee developers. There was some reaction in blog posts, news articles and comments about the two options, that were already negative about the proposed choice. And then Canonical came back with what I understand is a unilateral decision, that does not respect the previous explicit choice of Banshee developers. Sure, there's now 25% of the referrals fees from the Ubuntu One Music Store, but did some people really think that would make Banshee developers change their mind? How can this sound right?

I'm sure I could go on and on, if I'd take more time, but I'm not sure it's worth it. If the deal was something like 25%/75% or even 50/%50, I think I'd feel a bit better but I'd still want the money to go to Ubuntu instead of Canonical, especially as Canonical did absolutely nothing to develop this Amazon MP3 Store plugin. I'd be surprised if the Ubuntu community would have no use for money that it could decide how to spend.

The bottom line is that I'm highly annoyed. It's just yet another illustration that, even though some parts of Canonical care (or try to care) about upstream, in the end, what matters to Canonical is money. I'm even more annoyed because I have many good friends at Canonical, and that makes me not want to dislike their company.

Canonical, you're breaking my heart: I thought you understood the spirit of Free Software, but you're just another normal company that is first going after money.

February 26, 2011
I have a spleen for rather - say - exotic weekend activities (remember the R8 tour?). This time, two friends of mine and I went close to the middle of nowhere to the local blacksmith in Hallerstein (his web page is German only), for a two days forging course .
The event was fantastic, apart from some major problems with the local power supply (the whole village went dark three times), so we had to setup a mobile power generator in order to power the fan for the smith's hearth. It went well, apart from the starter breaking on the first attempt to start up the generator (it was brand new ), but we were able to improvise.
After a lot of hammering (also involving a pneumatic hammer we used for pattern welding for our Damascus steel knifes), and hours of grinding and polishing, every one of us was the proud owner of two self-forged knives, one of monosteel and one of Damascus steel.

It was an amazing experience, but you definitely need the help of an experienced blacksmith like our Axel, in order to get good results even on the first forging attempt. I guess I'll do it again, in the future. Maybe I will come home with a fully sized Katana next time .
February 23, 2011

git-annex is a recent tool allowing to manage files with git without having theirs contents checked into git. I've been looking at it with some interest in the past few weeks in order to use it to handle my music collection on the various computers I use.

My laptop just got a new SSD drive which is quite small and cannot handle the whole collection. By using git-annex, I'm now able to only check out part of my music collection and keeping it synchronized with all my others computers.

Using git-annex is pretty trivial once you understand the concepts.

I've set up a a git repository in my Music directory, like that:

% git init
Initialized empty Git repository in /home/jd/Music

Then I initialized git annex:

% git annex init "Music on keller"

So now I'm able to import all my date into git annex. git-annex offers several backends to store data. WORM is the default, but is not a good choice for file that could be modified, and music files can be, at least when editing the metadata. Therefore, I chose the slow but more reliable SHA1 backend.

% git annex add --backend=SHA1 .

That can be long, so you should be patient. Then you should commit the fact you annexed files:

% git commit -a -m "Imported my music collection"
[master 82d060f] Imported my music collection

Now, it's done. You can go on another computer and clone the repo:

% git clone ssh://keller/~/Music
% cd Music
% git annex get "Incubus - Light Grenades"

And then let the magic happens. It will retrieve the whole directory for you. Do not forgot to commit the fact that you got those album on that machine!

The concept used by git-annex is quite simple. All files are replaced by symlinks pointing to .git-annex/SHA1:filechecksum.log. This file contains lines, whose format is:

retrieval-timestamp is-file-present uuid-of-the-repository

Indicating if the file is present in a repository. This logs file are commited into the repository, whereas the real content is stored in the .git/annex directory and therefore not commited.

I recommend to take a look to the walkthrough page to get more idea and what you can and cannot do with git-annex.

Flattr this

Hi Folks, as of today https://bugs.freedesktop.org/ should now no longer give any warnings in a browser. The SSL certificate being provided by StartCom for free. Manythanks to StartCom for their Free SSL certificate service!


Donations keep this site alive

February 22, 2011
Related to yesterday's bling post, I wanted to mention that PolicyKit also has a textual authentication agent (video):

This is useful in PolicyKit applications running in a non-graphical environment. It's simple to use: simply use PolkitAgentTextListener if the response from PolicyKit indicates that authorization can be obtained if more information is provided. Here are the changes that was needed for pkexec(1) command. An obvious candidate for this would be the pkcon(1) command.

Nearly implemented in one evening (Friday evening, before the UI freeze), and a day (well, a long day, it's 4:30 AM).

The only thing not implemented is the hardest part, the "active" button, which needs to take into account whether there are Bluetooth devices at all, if one is the default and powered, and handle hardware killswitches as well as software ones (software-based airplane modes for example).

Yay, I can wiggle my mouse

As per usual, refer to the design documents for more information on the changes made.
February 21, 2011
The past couple of days I've been working on implementing the GNOME 3 Authorization Dialog. The implementation uses PolicyKit to achieve this and is conceptually very simple: the Shell process itself just implements the org.freedesktop.PolicyKit1.AuthenticationAgent interface to handle authentication requests from the system-wide authority (video).

For authentication, the Shell is using the existing code that in turn uses PAM. This means that the Authorization Dialog will work out-of-the-box with e.g. fingerprint readers, provided, of course, that the PAM stack has been set up correctly (video).

Additionally, the code has been tested with pam_rps - a PAM module whereby you authenticate by proving that you are smart enough to win in Rock-paper-scissors. The idea is that if your application works with pam_rps, then there's a good chance that it will work with any PAM module (video).

One major difference - and something I've been wanting to do for a while - is that the dialogs are now system-modal. In addition to fixing a lot of focus problems, this also makes the dialogs look more trustworthy since they are part of the actual shell. They're also way prettier.

(Bonus chatter: Of course, there's an emphasis on look in the above paragraph because any random app can still go full-screen to fool the user to give them their password. To do this in a more secure way, we need to use the Secure Attention Key and run the dialog in another security context etc. It's an open question whether it's even worth it to do this. But I digress.)

You can find the current code drop in this bug.

As all members of X.org should have noted in the meantime, it's election time again! After some efforts we actually do have more candidates than seats for the board of directors .

Some community members have asked a (rather large) number of questions, I have consolidated the answers I received in this wiki page. So far only three candidates replied, so for me at least the top three candidates are clear - it's better to vote for persons that do have an opinion and voice it, than for persons who prefer to stay quiet .

So go to members.x.org and vote!
February 20, 2011
Thanks to Marek Olšák for having a backup copy of my Git repository online! The hard drive containing much of my personal code which was on people.freedesktop.org (until those directories were lost) is half way around the world.

Revenge now has a new home on http://gitorious.org/omcfadde/revenge.

I have bumped the version to 2.0.0, which introduces some minor configure.ac fixes: mostly PKG_CHECK_MODULES for libpci, sdl, and zlib. I have also updated email addresses and revenge.sh for non-developers.

Honestly I do not expect this code to get much interest now that we have documentation from AMD; but it's useful for historical/nostalgic reasons.

If I were to do it over again today: I would start with the kernel MMIO tracer (which would deal with the fglrx kernel module) then extend this to handle dumping MMIO access from a userspace process too. The kernel is the perfect place to do so, and would be far more reliable than userspace.

If you have any questions or bug reports, feel free to ask them here and I will try to provide you with timely answers/fixes.


February 19, 2011
Preamble for planet.freedesktop.org

Sorry about the poor formatting on planet.freedesktop.org; it seems it and BlogSpot don't quite get along, therefor you won't see any color hilights. It looks much better (and easier to read) on my actual blog page, honest!

Updated version includes float-to-int optimization and comments; sorry if this bumps this rather long post to the top again; this is not my intention. planet.freedesktop.org admins: is there some way to disable bumping when a post is updated? (Perhaps selectively, in case the bump is important. e.g. updated dates for an event.)


This analysis was performed using a modified version of Chris Lomont's inverse square-root testing code. The accompanying publication is worth reading before looking at any of this data.

I've started looking into whether there would be any performance difference in a few optimized math functions should -fstrict-aliasing be enabled. I did not believe strict-aliasing would have much of an effect on these optimized functions (and it turns out I was correct) but the benefit is seen when compiling other code which includes these inline functions.

Without strict-aliasing compatibility, including the header file containing the incompatible functions/macros taints the entire file, meaning you cannot use -fstrict-aliasing where it may be helpful for your general code.



Here are the results for the standard 1.0 / sqrt(x) frequently used in graphics engines. Even though today's renderers typically use carefully crafted SIMD functions for the critical path, this is still useful for quickly normalizing vectors in game code, etc.

The Lomont version of the function is a tiny bit faster and a tiny bit more accurate, but nothing to write home about.

Clearly it can be seen that this micro-optimization is an excellent for x86 and x86_64. Don't try it on ARM; it's far slower than just taking the hit on 1.0 / sqrt(x)

I don't know whether this optimization could be modified for ARM; any assembly experts out there?
Timing Exact function
1752 ms used for 100000000 passes, avg 1.752e-05 ms
Timing Carmack function
463 ms used for 100000000 passes, avg 4.63e-06 ms
Timing Carmack function (strict-aliasing)
455 ms used for 100000000 passes, avg 4.55e-06 ms
Timing Lomont function
453 ms used for 100000000 passes, avg 4.53e-06 ms
Timing Lomont function (strict-aliasing)
455 ms used for 100000000 passes, avg 4.55e-06 ms

The absolute value function is mostly used for comparisons (e.g. fabs(y - x) > epsilon and some other specialized functions: finding on which side of a plane an AABB resides, it's distance from said plane, AABB radius, etc. Therefor it's useful to optimize this function where possible...
Timing Exact fabsf function
268 ms used for 100000000 passes, avg 2.68e-06 ms
Timing Bit-Masking fabsf function
304 ms used for 100000000 passes, avg 3.04e-06 ms
Timing Bit-Masking fabsf function (strict-aliasing)
305 ms used for 100000000 passes, avg 3.05e-06 ms
However, apparently it's quite a bit faster to just call libc's fabsf function! I saw this originally in the Quake 3 Arena source code, so maybe things were different with the compilers and hardware of the time.

These macros/functions are used when you want to know the sign of a float (i.e. is the value positive or negative) without performing any comparison (for performance reasons.) It seems that the strict-aliasing versions perform about identical to the macros.
Timing Exact float sign bit not set function
327 ms used for 100000000 passes, avg 3.27e-06 ms
Timing FLOATSIGNBITNOTSET macro
313 ms used for 100000000 passes, avg 3.13e-06 ms
Timing Bit-Masking float sign bit not set function (strict-aliasing)
312 ms used for 100000000 passes, avg 3.12e-06 ms

Timing Exact float sign bit set function
342 ms used for 100000000 passes, avg 3.42e-06 ms
Timing FLOATSIGNBITSET macro
305 ms used for 100000000 passes, avg 3.05e-06 ms
Timing Bit-Masking float sign bit set function (strict-aliasing)
305 ms used for 100000000 passes, avg 3.05e-06 ms

Don't use "d = (int) f" if you want fast code. fld and fistp work nicely on x86 and x86_64.
Timing Exact float-to-int function
1252 ms used for 100000000 passes, avg 1.252e-05 ms
Timing Fast float-to-int function
336 ms used for 100000000 passes, avg 3.36e-06 ms

Done. By Chris Lomont 2003. Modified by Oliver McFadden 2011
These measurements were taken on my laptop with an Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz processor and the test program compiled with gcc version 4.4.5 (Debian 4.4.5-6)



Whether this makes any huge difference in frames-per-second is debatable, really I had a bit of time and was bored. :-) Anyway, I wouldn't say anything until testing under real-world conditions.

It does look like the bit-masking fabs can be thrown away, though, and the fast float-to-int is a major win (although beware of possible rounding differences.)


Dear Lazyweb,

If anyone happens to have a copy of the Revenge (Radeon Reverse-Engineering Tool) Git repository, tarball, or code in any format, please comment on this post.

I know one released tarball was named "revenge-1.0.1.tar.gz", but it is unfortunately lost due to the home directories being lost on people.freedesktop.org. I believe there were newer versions, too.

I am reasonably (~90%) sure that I have the Git repository stored on one of my computers, unfortunately the computer in question is currently half the world away, and not online.

Perhaps this post will serve as a reminder to backup your code in more than one location (excluding your workstation.) Yeah, my bad. :-(


I'm currently looking for a bit of a combination hardware and software project to fill the boredom, so I've been thinking about underwater ROV's. Traditionally these use a surface tether for command communication (presumably with some basic protocol) and a feed from the camera and sensors.

I'm wondering what kind of distance I could get with modulated ultrasonic transducers?

I am quite sure how to design a suitable protocol; in fact I can reuse a lot of the bit-message code used in Quake 3 (there are lots of gems in there.) That provides me with compact messages, and with Huffman compression and an optimized table (based on either simulated or real-world packet capture) the compression ratio becomes pretty good. I think it would even be possible to send the surface a low-resolution/low-FPS video feed, while recording the high-resolution real-time feed to a solid-state drive.

The challenging part would be modulating the data; I have no idea how to choose a carrier frequency and modulation scheme for low-frequency (longer range, less ambient noise) ultrasonic transducers.

Furthermore, assuming the ROV and surface use the same frequency, the link would be half-duplex. This should be fine in theory as the protocol could be designed around this, but ultrasonic is still sound, so picking up an echo is a definite possibility (less so in open water.) I don't see this being too much of a problem (famous last words) because the protocol would be designed to be inherently unreliable: packet sequence number checking, CRC check, sanity check on values.

Far more concerning would be the potential to output too much power and thus be damaging to divers ears underwater. I guess that would just be a matter of capping the output power at the maximum exposure limit for the length of the dive, minus an N percent safety margin.

At least those Full Face Mask underwater communication systems seem to work very well for voice, and do not have any exposure limits that I know about. Quick Google search shows one rated for "50 to 500 meters depending on Sea Conditions and noise levels." Of course, this is voice which is much higher bandwidth than a simple command stream and perhaps 640x480 compressed 1 FPS video.

Anyone out there know about modulation schemes? There's a little on Google, but not too much; possibly I don't know what I'm looking for, though.

Just a random brain-dump idea I've been thinking over; at least writing this post breaks the boredom somewhat and might even motivate me to work on code for the sinking ship that is Nokia. Last I checked the stock was down ~20% and dropping since Stephen Elop's announcement. Ah, back to my general state of pessimistic realism.


February 18, 2011

Canonical has kindly sponsored some of my time at Codethink to bring one of the major missing pieces of the Unity user experience in Ubuntu. As you may know the Unity features a global menubar for applications. Integration with standard Gtk+ applications and Firefox/Thunderbird is already in place.

 

 

LibreOffice is the default office suite for Ubuntu 11.04 and its menus were not shown on the Application Menubar... until now:

I just rolled the first release. It has plenty of bugs and memory leaks, and kenvandine just told me it crashes on 64bits, but it's a start and the basic info publishing and command dispatching is there.

I expect to get it into shape in the upcoming weeks. I'm focusing on avoiding memory leaks and covering some corner cases with window handling at this point. Then I'll take care of shortcuts and getting some missing information of each item.

Hacking with UNO has been... interesting... the one good thing is that pretty much everything is either documented or there's some code around to look at. I had some deja vu moments when I worked on StarOffice/OpenOffice.org and Firefox extensions for APOC. Thanks god for Google Codesearch.

I also hope this code becomes useful for environments other than Unity such as GNOME Shell. If you have any questions about it just ask!

I am a candidate for the elections 2011 of the board of directors :) Following are my answers based on the questionnaire formulated by the members. You can check other candidates answers here.

1) In the last year, the membership gained a lot more insight in the activities of the board. What is your opinion on this new-gained transparency? Do you see options for improvement?

What happened in the recent past when people started to demand logs and open meetings from X.Org was great and should be always supported. The board reacted relatively quickly which was nice also. As a open organization, the Foundation has to work to improve more this, specially regarding the financial aspects which is being subject of discussions lately.

2) In the past, X.org financials have been dealt with in a less than optimal way, but in the last year a lot of effort has been put into creating solid financial records for the last 5 years, so that incorporation can happen. This work is still underway. What is your opinion about this, where do you see room for improvement?

As I elaborated before a bit, this is a must. I believe the current directors made already the necessary effort to dig the past records. At the same time, and obviously, mistaken happened there due not finding all of those, so there is room for improvement. Therefore, all we can do now is to focus on the current and next financial logs and for that not only the directors but also members can help guaranteeing everything is going well.

3) As stated in the X.org Foundation bylaws, only a maximum of 2 of the 8 board seats can be taken by employees of the same company. In the past there was a situation where there were more than two of the same company on the board, after some board member changed affiliation. What is your opinion about this, how would you prefer to resolve such a situation?

Although is entirely board’s fault, all members must help when the bylaw is not being followed correctly and some aspects are interpreted wrongly.

4) What is your opinion about the past and the current X.org board elections. Do you have any suggestions for improvement?

Lately the elections have chose candidates with a known background in X.Org community. This is enough to say that the election process works.

5) This years X.org conference was held in Toulouse, France. Did you have the chance to visit this, or any previous conferences? For 2011 one proposal was already made to hold the conference in Chicago. Opinions/Suggestions/Proposals?

Conferences have to be hold in countries where is affordable to fly, the bureaucracy with foreigns visiting is okay and where we have a good host setting up the organization. Fortunately I never experienced anyone failing in this last point, but I saw already people not going for conferences because of lack of visa. Although USA is not a visa friendly country, I honestly believe that Michael Larabel can influence this, expediting invitation letters for instance in an eventual Chicago’s conference. Oh, of course that all attendees want also to have fun, which is very important!

6) A big chunk of spending goes to travel sponsorship. When he learned about the practices of the more recent years, the current treasurer voiced that, when the X.org foundation was formed, travel was usually not sponsored for those gainfully employed to work on X.org related topics. What is your opinion on this?

Anyone doing any work related with and surrounding X should be eligible. For a conference for instance, we define a given budget based on the donations we get and current available money, and then set priorities to see who deserves it given the involvement of such the person.

7) Now, a topic quite close to the heart of the author of this questionnaire: FOSDEM. 4-5000 free software users and developers over a weekend in winter, join up in the center of Europe. X.org used to have a hugely popular Developers Room there. But the interest from the X.org community has dwindled now. Why do you think this is so? Should this be different? Do you have any suggestions?

The interest for X was never that big. Just a few geeks are interested in hacking on drivers or spending hours debugging a complex code of a compositor manager interacting with a X server and its non-trivial window stack. The past experience shown that is not easy to attract developers for X development and very likely a newbie will rather go learn a SDK high level before.

X conferences have been very small, with deep and long technical discussions in which several times hardly more than 3 persons in the room can talk about. Although these discussions are good and productive, they also tend to be boring for someone not involved in the subject. One alternative to improve this is to bring the annual conference of X.Org co-located with big events such as FOSDEM.

8) The topics of an X.org trademark and a new X.org logo have been talked about since the formation of the current X.org foundation. Are these really important topics for the X.org board? What is your opinion, do you have any suggestions?

To promote X.Org trademark is for sure very desired by the board. This topic is considered “important” but not “really important”, I would say, so that is the reason why the current directors are not paying much attention at this moment. But then again, this is something that with just a little kick from the board, the members and the community could do the rest of the work. A more proactive director could do this.

9) Coordinating Google Summer of Code is another initiative supported by the X.org board. There have also been follow-up initiatives started by the board. What is your opinion about these initiatives and their results? Any suggestions?

I guess it is not fair to myself talk about this because I was one that got leveraged by Summer of Code within X community :) So obviously it is important to ramp up newcomers and the Foundation’s Vacation of Code, although without not being that popular still, was a brilliant initiative from the board. We should advertise it better though.

10) X.org hosting infrastructure has had its hiccups over the past few years. The loss of all users home directories on freedesktop.org and the breach of trust through defamation of a driver repository by former board members come to mind. What is your opinion about the current situation, how would you want to improve it?

The situation is not good. There are room for improvements throughout the whole infrastructure: management of machines, creation and handling of repositories, administration of accounts and all other activities.

For the repositories, one problem I noticed is that freedesktopers are not seeing us with good eyes, sometimes even abandoning and going instead for gitorious, linaro.org, google, github and many others. These services mostly have the same interests in open-source and I am sure we could centralize the efforts in one single place, thus reducing the overall maintenance costs.

11) The membership of the X.org foundation is not completely representative with respect to its contributing audience, and it is hard to motivate people to become a member of the X.org foundation. Some people suggest linking commit access with membership. What is your opinion, and do you have any further suggestions?

We are doing good already. We are trying to create a culture of development process where the “commit access” is irrelevant. There is one or a few numbers of people only responsible to the final commit; this final commit is based on the reviews that got from the mailing list by any other hacker. It’s truly open and focusing in stability. So, in short, everyone should be able to create repositories at freedesktop, but patches are pushed to repositories upon review only. Membership is a bit different.

12) Are there any topics that were overlooked in this questionnaire? Is there something else that you would like to talk about now and/or work on during your term on the board?

Pretty much covered good points. Thank you for elaborating.

13) What do you think about this questionnaire? Should this initiative be repeated, and do you have any suggestions for such future repeats?

My suggestion is that it should get opened and announced before the elections to all members discuss a bit the best questions. Also, to limit the number of questions would be better.

14) How do you feel about the size of the Xorg board?  Should it be changed?

I don’t have the experience inside the board to tell this, but it seems to be working okay from outside.

15) Some have argued that the current election process is flawed.  Do you agree?  What do you think is flawed and how can it be improved in the future?

It is not flawed.

16) The Xorg Foundation has been working on getting 501(c)3 non-profit status for a while now.  Would you be interested in getting involved with this work?

I am pretty sure there are other directors or even members with more expertize in this kind of paper work, specially the ones living in USA. If needed, I could help of course.

17) It has been brought up in several board meetings that we should donate some money to the SFLC (Software Freedom Law Center) for their help various legal matters.  Do you agree with this?

I honestly don’t see much difficulties lately happening where lawyers should be involved. But of course, both X.Org and SFLC are sister organizations and they should help each other anyway. It all depends of the current cash of Foundation.

18) Non-profit corporations have certain requirements with respect to where their funding comes from depending on the type of non-profit they are. Should the Xorg Foundation actively solicit donations from the community to fund it’s activities (developer conferences, travel expenses, infrastructure expenses, etc.)?

Other open-source organizations are doing this repeatedly. We should invest some time on it also.

19) If you agree with the soliciting funding from the community, would you be interested in taking on a role to help reach that end?  If so, what ideas do you have for soliciting these donations?  If you don’t agree, where should the Xorg foundation look to get it’s funding?

Yes, definitely I’m willing to help. Last year, when I was trying to raise up funds from my company, I asked the Board for a formal letter that I could emit asking for budget contribution. There was none. We could start from this idea for instance.

20) With new platforms such as android and programs like wayland, some would say X is becoming less relevant.  Do you agree with that statement?  Where do you see X going in the future?

X evolved a lot through the years already with its protocol extensions. Everyone is amazed to see a protocol completing one fourth of century of birthday, where initially was designed for a much simpler environment with different hardware requirements. At the same time, we haven’t been deprecating unused parts of the protocol and this led us to a very big open source implementation that we have nowadays. The productization of it is not practical and the development happens quite slowly. So we have to move on and I guess that is the big technical challenge the board will have to face next.

Although the Foundation states explicitly the support for X, it also supports all siblings technologies such as DRI, Mesa, Linux kernel, now Wayland and a dozen of others. So it is important to emphasize that the community remains the same, i.e., of hackers shaping the core of graphics towards a free and open-source desktop experience.


evtest, that little program that displays kernel input events and information about input devices now has a home on freedesktop.org. I hope this helps to reduce the number of different upstreams and distro-specific patches that float around.

Code: http://cgit.freedesktop.org/evtest/

Bugzilla: https://bugzilla.freedesktop.org/enter_bug.cgi?product=evtest
February 17, 2011

If you have already watched my presentation on systemd I gave at linux.conf.au 2011 then this video of my talk on the same topic which I have gave at FOSDEM 2011 in Brussels, Belgium will probably not be all new to you, but the questions from the audience (and hopefully my responses) might answer a question or two you might still have. So do watch it:

Hmm, seems p.g.o strips the video from the blog post. So either read the original blog story or watch it directly on YouTube.

Oh, and FOSDEM rocked, like every year!

February 15, 2011

Linux Plumbers Conf 2011 will take place in Santa Rosa, CA, September 7-9, 2011.

To get announcements about LPC 2011 you can subscribe to our announce list. Additional details will be made available as the conference date nears at this URL. See you in wine country!

If you have any questions or suggestions for this year’s conference, please do send in your comments to us at contact@linuxplumbersconf.org.

February 11, 2011

GStreamer was originally hosted on Sourceforge when the project started up 10 years ago. As time went by we migrated most of our stuff over to freedesktop.org, except our bugzilla which ended up on gnome.org.

The one thing that stayed on Sourceforge was our mailing lists, until today that is. Thanks to the hard work of Tim-Philipp Müller all our lists are now migrated to freedesktop.org. There are a few advantages we see with this move, one being getting nicer archives, another being not needing to maintain an administrator list on SF anymore and finally I guess it makes the mailing lists feel a bit more authentic that they are on freedesktop.org, just like the website.

All this of course means that in the coming Months the 10 year old SF project will get gradually shut down, and maybe we end up deleting it completely. So a thanks to SF for the last 10 years of hosting :) Feels strangely nostalgic for some reason :)

And if anyone wonders if we will move bugzilla too, I don’t think that is in the cards anytime soon. Many of the most popular GStreamer applications, like Totem, Banshee, PiTiVi and so on use the GNOME bugzilla and the option to easily re-assign GStreamer bugs to GStreamer is atm more valuable than what we perceive the value of having everything on freedesktop.

One of the recurring questions about to input event handling is how relative and absolute devices are handled in X. Surprisingly, the answer is "that's complicated" and it took me a while to wrap my head around this.

Back in the days of yonder, devices had no mode. X (the coordinate, not the window system) was x, y was usually y unless bugs intervened and we all had mice, computers the size of fridges and fridges the size of, well, fridges. Such was the lore, blah blah (those of us who are old enough to actually remember those days, which excludes myself for example, may remember them fondly).

In 1994, the new kid on the block (not one of the singing ones, they disbanded that same year1, presumably for other reasons. Though that'd be one thing I'd love to be credited with...), the X Input Extension protocol added support for device mode and the notion of relative and absolute devices was born (within the Xiverse, anyway). Fast-forward half a lifetime of something that lives for 30 years and XI2 added to that per-valuator modes. i.e. a device may have an absolute X axis and a relative Y axis.

But: the device mode in X describes the behaviour of a device only. On an absolute device, the pointer is expected to jump to the position the device tells it. On a relative device, the pointer is expected to move by the coordinates provided, based on the current pointer position (and accounting for pointer acceleration).

However, there are no requirements for how to send coordinates and absolute devices may send relative data and vice versa. So inside the server, the mode of a device (or a valuator) has no meaning. It's merely a flag sent to the client.

Which makes mode processing a bit tricky because the only time we know if an event was relative or absolute is when we receive the actual event (events include a absolute/relative flag). An absolute device may calculate deltas based on the previous position and then submit the new position as absolute coordinate - and thus feel like a relative device to the user. For whatever reason you'd want to do this, I don't think any driver does it atm (though I have vague recollections of having done this in the past). But it just adds to the insanity that is input in X.

Either way, we cannot rely on the device mode for anything in the server, and the actual device mode is just a hint to the client.

1I had to wikipedia this. I wonder what that does to my reputation when the admins see the logs.
February 10, 2011
It's incredibly rewarding to see videos like this one. I think working on the Wikipedia activity might be the most important thing I've ever done:


Web: La Selva
Uploaded by WebFilm.

(via Jimmy Wales)

Update, 2010-02-10: The video on Vimeo became password-protected, so I've switched the embedded video over to a copy on Dailymotion.

Just saw the White House putting out this page asking for input on innovation. I recommend every US citizen reading this making sure to fill out the form explaining how the current US patent regime is not helping innovation, but hindering it. How the patent system, due to the volume and low quality of patents granted, and the unbalanced and painful process of getting them revoked, has turned the patent system into a mafia style protection racket where it costs more to fight the extortion than to just pay up. There is a great article on techdirt on this.

February 08, 2011
Following on from the region panel, we now have an updated “Screen” panel for the control-center. Richard worked on the initial version (which you can see in older revisions of the control-center for GNOME 3), and I finished hooking it up this week.

Not much to say about this, except that the lock screen timeout preference now changes the underlying preferences for both “on AC” and “on battery”, as well as the idle time (which is used by a number of desktop components like your IM application).

I'm also very glad that we managed to get rid of the brightness levels based on whether on battery or mains power. This usually worked exactly as you didn't want it to. Now, just use your keyboard shortcuts for those instead of hoping to gouge somebody's eyes out every time you changed power source.

See also the design page for more information about the changes made.

When I started to use Emacs, I got hooked by many stuff like Gnus and Org-mode. One thing I quickly started to hate is how the Lisp code can be old and unmaintained. That especially applies to BBDB, which has been unmaintained for years, and has very very very old and obsolete code.

Therefore I've decided to develop my own BBDB replacement based on my lovely Org-mode. It's called org-contacts, and it allows you to handle your contact like anything you would handle in Org. This way you can manage them the way you want, without any preset fields or any assumptions like BBDB has.

I had the chance to present it at the Paris OrgCamp a couple of weeks ago, and due to the enthusiastic audience I had, I'm now releasing it to the wide Internet.

Flattr this
February 07, 2011

So I went down to FOSDEM this weekend. One of the things I was able to do while there was sit down with Edward Hervey and figure out how to use the new encodebin element with Transmageddon. The goal of the new encodebin element is to make encoding a much easier task with GStreamer, where you basically pass it a GStreamer caps value for your container format and audio and video streams, and encodebin figures out which elements it needs to create output with those caps. I have a minimal example below:

import sys
import os
import gobject; gobject.threads_init()
import gst
import pygst
import glib
import gst.pbutils
import gtk

class Transcoder:
   def __init__(self):
       # create GStreamer pipeline object
       self.pipeline = gst.Pipeline("TranscodingPipeline")
       self.pipeline.set_state(gst.STATE_PAUSED)

       self.uridecoder = gst.element_factory_make("uridecodebin", "uridecoder")
       self.uridecoder.set_property("uri", "file:///home/cschalle/Videos/gravity.mpg")
       self.uridecoder.connect("pad-added", self.OnDynamicPad)
       self.pipeline.add(self.uridecoder)

       self.containerprofile = gst.pbutils.EncodingContainerProfile ("ogg", None , gst.Caps("application/ogg"), None)
       self.videoprofile = gst.pbutils.EncodingVideoProfile (gst.Caps("video/x-dirac"), None, gst.caps_new_any(), 0)
       self.audioprofile = gst.pbutils.EncodingAudioProfile (gst.Caps("audio/x-vorbis"), None, gst.caps_new_any(), 0)
       self.containerprofile.add_profile(self.videoprofile)
       self.containerprofile.add_profile(self.audioprofile)

       self.ebin = gst.element_factory_make ("encodebin", None)
       self.ebin.set_property("profile", self.containerprofile)
       self.pipeline.add(self.ebin)

       print "self.ebin is " + str(self.ebin)
       self.ebin.set_state(gst.STATE_PAUSED)
       self.uridecoder.set_state(gst.STATE_PAUSED)
       self.filesink = gst.element_factory_make("filesink", None)
       self.filesink.set_property("location", "/tmp/test.ogg")
       self.pipeline.add(self.filesink)
       self.filesink.set_state(gst.STATE_PAUSED)
       self.ebin.link(self.filesink)

       self.pipeline.set_state(gst.STATE_PLAYING)

   def OnDynamicPad(self, uridecodebin, src_pad):
       c = src_pad.get_caps().to_string()
       print c
       sinkpad = self.ebin.emit("request-pad", src_pad.get_caps())
       print "action signal returned", sinkpad
       src_pad.link(sinkpad)

if __name__ == "__main__":
	hwg = Transcoder()
	gtk.main()

The most important thing to notice about this code is the creation of the profiles, the adding of the audio and video profile to the container profile and then finally the setting of that profile onto the encodebin element. In my example I have extremely simple caps statements, basically just the codecs names, but you could add further things here like video height and width, framerate, audio bitrate, audio channels and so on, and encodebin would be able to give you the correct output.

We did find a couple of Python binding bugs though, which Edward fixed promptly, so if you want to try this code now, you need to grab gstreamer-python from git master.

February 05, 2011

A while ago I spent some time hacking on a little python library to query JSON or YAML objects paths using a language inspired in XPathPython JPath. I thought it could be useful to share it with people out there.

This allows for simple access to elements included in repetitive structures such as twitter feeds. I have very basic support for the language implemented (as I only need a few features).

Here's a little example of how it works:

a = {'a': [{'b': {'x': {'x': {'x': True}}}},{'b': True, 'a': False},{'b': "foo"}]}

BaseQuery ('/a/*/*').execute (a)    

This snippet executes the /a/*/* query (all childs of all childs of the value stored in the 'a' key of the root object) and returns a list of all matches:

[{'x': {'x': {'x': True}}}, False, True, 'foo']

I do not intend to do a 1-1 match of all the XPath language, only pick the features that makes sense in the JSON/YAML context. The project is hosted in github, merge requests are welcome!