One of the annoying features of reading several planets, is that you end up reading entries from people you otherwise respect, who seem to have various complexes about nonsensical issues. We all saw the month in which half of Debian decided it was cool to rip on Ubuntu, and now apparently it's the new cool thing to do if you work on Fedora.

According to a particularly obnoxious entry, the quality or otherwise of Ubuntu's kernel[0] does 'damage to the free software community'. Now, they've focussed on binary drivers. Which is fair enough: I am personally quite uncomfortable with binary drivers, and extremely unimpressed with Ubuntu's recent move towards binary drivers by default. While I respect the fact that they still encourage users to install free drivers, providing them by default is not a winning move, in my opinion. But I'm not going to discuss this further right now, because if I do, the terrorists win.

The reason the terrorists win, is because some people like to furiously handwave and make strawmen. Apparently now, everyone who's ever touched Ubuntu is rabidly for binary drivers, but the problem here is the handwave from criticism of Fedora's alleged community into yet another ramble about the kernel tree and binary drivers.

I certainly hope the Fedora community is more mature than this, both in general, and in their ability to have a constructive debate about the level of its community involvement. Right now, it is not even disputed that there is effectively none. At first glance, they may appear similar, but if you look further, the similarities vanish. Anyone can come in and get involved in the decision making in Ubuntu, but more important than that, the process is at least completely transparent, so you can see what's going on, on public lists, at every step. Fedora does not have this: decisions magically appear On High from RHEL types. This is not necessarily a bad thing, and does not necessarily result in a lower-quality distribution, but if everyone could just accept this as being true and move on, rather than bitterly baiting a successful community distribution about it, I think everyone would be a lot happier.

The biggest difference is -- yes, basically all the Ubuntu core developers are employed by Canonical. These people were handpicked from the Debian community originally, and now a great deal of them start as Ubuntu community members, and are employed by Canonical because having them work full-time on this stuff would be awesome. The process is still entirely transparent: being employed is a mark of recognition (sorry), and a request to continue working on this even more, rather than a pre-requisite to being able to do anything. Witness Fedora Core vs. Fedora Extras, for example: there are quite a few packages that non-Red Hat employees are prevented from meaningfully contributing to.

So, the summary in a nutshell: binary drivers bad (and Ubuntu moves towards promoting same even worse), Fedora 'community' not at all, handwaves bad, refusal to get involved with a meaningful debate about community governance and structure without engaging in petty mudslinging and pointless handwaves inexcusable.

(Disclaimer: I am not involved with any distributions, nor do I have any professional affiliation with them either. I'm just an irritated observer.)

[0]: I don't claim to have any insider knowledge here; the only point at which its quality or otherwise has become an issue for me lately, is a random hang in gettimeofday() in a corner case recently, which I've been too lazy to isolate and report as a proper bug; I worked around it in the X server anyway.

(Please note, I didn't write this: I just fixed a couple of bugs and put it in a patch. All credit to the original author, Tommie Gannert.)

Tired of the sucktitude of automake command lines? Find it incredible that people could seriously claim to prefer command output so verbose that you actually miss all the warnings?

if /bin/bash ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../GL/mesa/swrast -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I/home/daniels/x/mesa/Mesa/include -I../X -I../array_cache -I../glapi -I../main -I../math -I../shader -I../shader/slang -I../shader/slang -I../swrast -I../swrast_setup -I../tnl -I.. -I../../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXFree86Server -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -g -O2 -MT s_masking.lo -MD -MP -MF ".deps/s_masking.Tpo" -c -o s_masking.lo s_masking.c; \
then mv -f ".deps/s_masking.Tpo" ".deps/s_masking.Plo"; else rm -f ".deps/s_masking.Tpo"; exit 1; fi
gcc -DHAVE_CONFIG_H -I. -I../../../../GL/mesa/swrast -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I/home/daniels/x/mesa/Mesa/include -I../X -I../array_cache -I../glapi -I../main -I../math -I../shader -I../shader/slang -I../shader/slang -I../swrast -I../swrast_setup -I../tnl -I.. -I../../../../hw/xfree86/os-support -DHAVE_DIX_CONFIG_H -DXFree86Server -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -g -O2 -MT s_masking.lo -MD -MP -MF .deps/s_masking.Tpo -c s_masking.c -fPIC -DPIC -o .libs/s_masking.o

Prettify Automake finally fixes this. I've put up a deb that at least works on Edgy (but has some pretty shady changes; getting it to build was, um, interesting) here; re-autoreconf with that, then run configure with --enable-pretty-cmds to get much more sensible output:

  [C ] fbbits.c
  [C ] fbblt.c
  [C ] fbbltone.c
../../fb/fbbltone.c: In function "fbBltOne":
../../fb/fbbltone.c:354: warning: left-hand operand of comma expression has no effect
  [C ] fbbstore.c

Warnings! Visible! Amazing!

So, I finally merged the input-hotplug branches on master. Basically, this means that instead of attempting to hide behind one device (/dev/input/mice, the console keyboard), and hacking around it with gash and tape when we actually expose multiple devices[0], we finally expose multiple devices in a useful way. This is consistent through out the Xorg and KDrive servers; Xnest and Xvfb also have support, but that's not the most useful thing ever.

This required a huge overhaul of the old input code, much of which dates back to the mid-80s; the bits that don't were sticky-taped on the side, working more in spite of our core input code than with it. So, in addition to being generally useful and providing things like multiple keymaps on different keyboards and different acceleration (and so) on different pointer devices, it also actually caused a net removal of code.

So, once you've set yourself using evdev for the drivers, you can also now dynamically add and remove devices. Last night, not long before I released all the components, I removed all the input devices from my configuration file, told X not to add any, and added 'respeclaration --daemon' to my session: completely dynamic input. I've been using the core bits (the whole input API rework) for quite a long time, along with Zepheniah's evdev driver, but this is the first time I've been using a session with completely hotplugged input, as opposed to adding and removing devices every now and then to test the hotplug capabilities, which was actually a piece of cake, compared to reworking all our core input code to deal with devices appearing and disappearing.

Still, this all needs good desktop integration. Keyboard and mouse applets need to become aware of multiple devices[1], and allow people to configure them separately. The desktop should also take over the role currently filled by respeclaration, which works perfectly well, but shouldn't be generally deployed; management of input devices thus turns into a session management issue, which leaves the desktop to dictate policy.

There are still some nits in the D-BUS policy to sort out (right now, only root can reconfigure the devices), but I believe it's fundamentally the right model: it's machine-oriented, rather than session-oriented. There are still some minor changes that need to be made, but working out who should be trusted to add input devices was more or less impossible in the X security model.

xserver 1.3 (for Xorg 7.3) should be good fun.

[0]: Key presses/releases from your second device will just magically appear from your first device. Useful, huh?
[1]: In brief: check for inputproto 1.4 at build time, check DEVICE_CORE on whatever appears as the core pointer, and if 'iscore' is 1, then you have a virtual core pointer. Anything that sets status to 1 for DEVICE_CORE will also generate core events. Setting controls on the core keyboard or pointer will propagate those changes down to all the devices which also send core events. I'm going to document this soon.