So if you were sad, depressed and crying in despair without having a chance of reading about what was going on with the Intel Graphics for the past days, rejoice!

Those past few days were quite busy on all the projects, and with thousands of emails to keep track of it is hard to select the most relevant news – all of them are! But I’ll try to summarize the most interesting stuff that happened for the past few days.

Starting with kernel, as you all already know, we are living in the post-3.1 era now, with the release of Linux 3.2-rc1. It brings lots and lots of fixes and improvements all around, and much more are yet to come.

On Intel Graphics side, the following items caught my attention for the past days:

• Keith Packard sent yet more eDP-related patches, allowing eDP displays connected to the PCH to, well, work . The main issue came from the fact that the driver incorrectly was treating a PCH-connected eDP panel like a CPU-connected one, setting the wrong bits in the wrong places.
• Daniel Vetter has sent out a series of patches for simulating GPU hangs. As you all know, GPU hangs are an (unfortunate) part of a GPU driver life, and there are many factors which could cause them, ranging from incorrect GL instructions to out-of-bounds variables somewhere in the stream of commands and down to hardware failures. Prior to Daniel’s patches, the only way to see a GPU hang was by having a hung GPU, so most of them were not easy to reproduce and investigate. Now, it is possible to stop the GPU at will, and see the effects. This is particularly interesting at least for me, because I was working on some tools for doing heuristics analysis of the root-causes of GPU hangs. Now, I can do this task with much more ease.
• Jesse Barnes sent out a new round of planes support, and support for SNB and IVB video sprites. The video sprites support different video formats natively and can do scaling as well, and their support was added to the DRM overlay code with this patchset.
• Ken and Daniel did a bit of cleanup of code specific to some pre-production SNB systems. Now that Sandy Bridge is out there, those bits are not necessary anymore, so they were wiped out.
• Daniel has sent a 13-patch series of pwrite/pread reworking. This patchset fixes some spurious -EFAULTS issues which could lead to kernel issues, improves the performance of pread/pwrite calls on LLC machines and cleanups unused code, replacing them with faster execution paths.
• Also on kernel, I’ve found an issue which can cause division-by-zero in kernel when accessing power-related registers from userspace, and sent a small patch fixing it. Apparently, the very same issue was already found back in July by Konstantin Belousov. It is a small fix for a potential kernel crashing issue, and let’s hope it will be picked up in one of the next kernel pull requests.
• And Jesse Barnes sent out some documentation and cleanup patches for the drm subsystem.
• Still on kernel, but outside of our team’s area, one big news for Linux Graphics will certainly make some people out there happy. Yes, I am speaking about Alan Cox moving of basic GMA500 driver out of staging. This driver support accelerated console and non-accelerated KMS on Poulsbo, Oaktrail, Cedarview and Medfield hardware. Note that medfield support in this initial patchset is left out on purpose, as it needs considerable rework to be ready to enter main kernel.

One particular issue worth highlighting is that a long-standing issue on GL-based applications (among which Unigine Tropics and Sanctuary are probably the most notable examples, among many others) was finally fixed, thanks to an amazing work by Eric Anholt, Kenneth Graunke and Keith Packard. This issue can be described as ‘small moving ants on top of image edges’ or ‘flickering pixels‘. So if you have had this issue, make sure to check out the patches!

Going to Mesa, out of hundreds of emails and commits, it is hard to choose the most interesting ones. Work on GL 3.0 support proceeds quickly, and new mesa stability release, 7.11.1 is almost out of the door. Our Q&A team did a full testing of this bugfixing release, and haven’t found much issues. So prepare yourself, as in few weeks we’ll have MESA 7.11.1 out there. Stay tuned for Ian’s announcement in nearby future.

But as for mesa master branch, the following patches called my attention the most:

• Eric sent a patch series to add support for GL_EXT_texture_integer on i965 driver.
• More work towards EXT_transform_feedback was done by Dan McCabe and Paul Berry, and Marek from the community side.
• And we had lots of fixes for potential segmentation faults, safety checks, better hardware specification compatibility, piglit-based fixes and other issues from Yuanhan, Eric, Ken, Chad and Ian.

On Wayland side of the force, lots of patches went in those days. Among those, there was an interesting proposal for the screen locking protocol by Pekka Paalanen, and some bugfixing patches from Juan Zhao.

Going to the other components, we had a release of xorg-xserver 1.11.2 RC2, with several crashes and correctness fixes; and new stable pixman 0.24.0 which brings many performance improvements and usage of architecture-specific instructions to improve overall performance over a number of different operations (such as bilinear scaling for example).

And finally, for the intel-gpu-tools, I was working on a new intel_gpu_analyze application, which I was using to tracing and analyzing CPU and GPU performance data during workloads, and also checking on the corresponding power consumption. This is a very experimental code yet, and it lives at my freedesktop.org git for now. But still, I can already do some nice performance analysis like this one.

Since last update, we had a very productive weekend , and 2 days of work on all the projects. In this time span, on intel-gpu-tools front, we had some interesting commits:

• One from myself, to add non-interactive logging of GPU activity, parseable by other scripts and applications
• Several from Daniel, improving the debugging facilities of the tools
• A new intel_reg_checker application from Eric Anholt, which attempts to discover possibly incorrect settings which could lead to the crash/hang/issue.
• And I’ve sent some heuristics patches for intel_error_decode and intel_decode which attempt to identify the root cause of the problem (e.g., if it came through mesa codepath, or 2D driver, or VA). After discussion on both mail and IRC with Chris and Daniel, we came to the conclusion that this approach should be better approaches from a separate script or app, which would do the analysis of the trace.

On Kernel, we had some nice news too:

• QA has carried out the performance and functionality testing for my edid patch, and it gave a really nice performance boost in all cases. After sending the final version of the patch, we had some comments from Jean Delvare and Alex Deucher about possible issues this could bring to radeon-based cards, if the fix would be implemented inside DRM. So I am still not sure about what to do here – I have two versions of the same fix, both are working, but I don’t know which one will be the final one.
• Lots of activity and discussion on SNA, VA and RC6-related issues took place from Daniel, Ben, Chris and myself. Some of the reported issues have been isolated (well.. mostly ), and some have some patching attempts. The root cause of the problems is not clear yet. But on the bright side, apparently, we don’t have any crash or hang-related issues coming via RC6, only some rendering corruptions. So hopefully RC6-by-default will see the light of day again in some point in the future .
• Some (possibly) final patches from Ben Widawsky and David Woodhouse arrived, attempting to fix the VTd-related problem on Ironlake chipsets.

Meanwhile, Mesa has had lots of activity too:

• Chad Versace sent out some dozens of patches which added support for HiZ infrastructure in core mesa, adding new driver hooks and small changes all around. Note that HiZ is supposed to be supported by i965 family of the chips (e.g., 5th (Ironlake) generation onward).
• Lots of piglit and conformance patches arrived from Eric, Yuanhan and Chad.
• Stencil buffer support has received some updates from Chad as well.
• And an improved math performance patch was sent by Ken. It should improve math-related operations by a nice margin on Ivybridge, and also allows it to work in a workaround-free way .

On DDX front, as usually, we had an impressive number of patches from Chris for SNA. On a related note, past weeks had given us lots and lots of feedback about SNA and how people are using it. This is great – it means that it works (despite some issues, many of which are already filed as bugs, or being investigated right now)! I’ve been using SNA by default on all my machines for a couple of months, and it works just fine for me. Only faster .

And finally, on Xserver-related work, we had a new Glamor pull request from Zhigang Gong, lots of man and documentation-related patches, Xinput and evdev development, and a small patch which drops support for the bsdi. I am actually quite curious about this one – it has been a really, really long time since I’ve seen a bsdi system out there. Does anyone still has one around? It would be nice to play with it those days…

EDIT: Update from Daniel Vetter – HiZ is available in hardware starting from Ironlake. I updated the post accordingly.

There was much activity all around those days, so I decided not to wait until next week and do this update earlier. Certainly until next week lots of things will still happen.

But let’s get started. And first of all, I’d like to thank you all for the feedback I had on this blog – both by emails and comments and IRC and bugzilla – I was really and truly pleasantly surprised with your comments. Looks like this sort of information I am putting here is interesting to many people out there, so I’ll try to keep up to the task.

And one important reminder which somehow slipped out from the previous posts in the series – if you want to report an issue related to the Intel Graphics stack, there is a comprehensive guide on what you need to report here. For debugging suspend-resume issues, there is a separate guide as well. And, of course, if you want to build the latest versions of the drivers (or their snapshots) as well, there is a tutorial to get you started. Those links are hidden deep in the Intel Linux Graphics web page, so they are not easy to find sometimes – so I hope they will be useful to you.

But let’s go to the development progress on the components of the stack for this 2nd week of October.

• I sent out yet another round of my EDID fixes. Thanks to the testing by Mike Lothian (thanks!!), the i915-specific fixes gave no visible regressions (however, no visible improvements improvements either), but the drm-specific fix managed to do something wrong with the Radeon adapter. So I switched the focus to the i915-specific version for now, as I don’t have non-intel hardware to do the debugging, and put it on my fd.o repository. Hopefully I’ll have more testing results next week, or maybe other comments on this patch. At least on all my machines, it managed to improve the monitor detection timing by a considerable margin.
• Also on Kernel, Adam Jackson from RedHat sent out a nice patch that work around the limitations of active dp->any connectors. Quoting his patch description, ” Many such (including all DP->VGA chips I can find on the market) come equipped with only 2 DP lanes, which clips your dotclock to 144MHz at8bpc.  Of the standard DMT modes, that means you lose 1600×1200@60 and above.  Since these adaptors are marketed as supporting 1920×1200, we might as well make that work, otherwise it’s the driver that comes out looking bad.”.
• Still on Kernel, Jesse Barnes had sent new iterations of his 3-display-pipes patches, which have evolved into more than that by now, improving lots of display handling aspects within the driver. Also within this context, Paulo Zanoni has worked around a bug with multiple VGA outputs by using some intel_reg_dumper/intel_reg_write magic , and came with a kernel patch for fixing such problems. This patch was further adapted according to Chris and Jesse’s comments, and is floating around the intel-gfx mailing lists at the moment.
• Also on kernel, Daniel Vetter and (by a much smaller margin) myself were been doing lots of investigation for GPU hangs, corruptions, suspend-resume and rendering problems. Some of the problems has possible patches, some of them are still out in the wild. For the currently alive suspend-resume issues, looks like they happen when the Kernel Mode Setting (KMS) is being used, and go away with the nomodeset kernel parameter. So if you are affected by any of those, it would be worth trying that parameter in grub or kernel command line to see if it helps.
• On development side of kernel, Jesse Barnes sent out a modeset verification patch, which could help identifying modeset-related problems; and Ben and Daniel Vetter did many code cleanups, sent out patches on hangcheck robustification, and overall were working on improving the debugging facilities of the driver.

Moving to the DDX (a.k.a., 2D display driver, usually known by its friendly nickname of xf86-video-intel), there was quite an activity as well:

• Chris has sent out lots of SNA-related patches.
• Daniel Vetter has sent some Sandy Bridge-specific fixes, and was also investigating SNA-related bug reports.
• And I’ve managed to find a new GPU hang which only happens when SNA is active on an Ivy Bridge system. Somehow I suspect not many people out there besides myself are affected by it though .

On Mesa front, there were some new patches from Chad on Stencil Buffer development; lots of patch reviews by Eric Anholt and Ian, some Ivy Bridge-specific fixes from Ken, many code cleanups and refactoring by Ken again, and some patches from Yuanhan Liu for bug fixing, improved Ivy Bridge functionality, and better GL conformance. Besides Intel-specific development, there were some interesting patches from VMware developers (Thomas Hellstrom, José Fonseca and Brian Paul) which landed into master branch as well.

About Xserver, lots of emails on most different areas have been floating around, as usual, but not much Intel-specific activity took place. Among the discussions and patches which caught my attention the most were an interesting discussion about patches which allow X server to run without root user; a patch which adds support for running a backtracer in case of fault; a new round of Xinput fixes, a patch for setting a default DPI value from EDID data by Michal Suchanek, and more bus cleanups by Jeremy Huddleston. On a related note, Xserver 1.11.2 RC1 release is approaching fairly quickly.

Moving to Wayland, we had lots of x11-specific patches from Kristian, and some compositor bugfixes from Benjamin Franzke.

And finally, on LIBVA there was a one bugfixing patch from Gwenole for proper driver name detection with fglrx-powered cards.

Besides those news, we also have had a new pixman release, which added some nice optimizations by using SSE2 instructions on x86 platforms, and iwMMXt ones on ARM.

So yeah, quite some changes so far.

So this is the end of this semi-periodic-update about the state and news from the Intel Linux Graphics (and related) world – see you in the next one.

P.S.: On a slightly related note – I have received some comments which say that this kind of posts, when they do not directly mention Mandriva or Mageia, should not belong to the respective planets. However, I also received some posts saying that the Graphics-related news affect pretty much all the distributions out there. So I am open for opinions – what do you suggest, should such post be excluded from the syndication to Planet Mandriva and/or Mageia feeds, or they could fit there as well?

another week, another update .

Lots of major things happened for the past week over all the Intel Linux Graphics-related projects. Let me highlight some of them for you.

• On kernel side, the major feature is, certainly, the enablement of the 3rd display pipe for the Ivy Bridge architecture in the intel-gfx mailing list, by Jesse Barnes. Lots of things were already said about Ivy Bridge, which will arrive next year to your favorite reseller, and the Open Source drivers for it will be ready by the time it gets there. The enablement of the 3rd display pipe – and, therefore, the possibility of having 3 independent displays up and running on Linux – certainly is a major step forward. And having those patches in the open-source world early, months before the hardware will arrive to the vast majority of the users, is certainly a big plus for everyone (and specially for the open-source community)!
• Lots of work for next stable release of mesa (7.11.1) was done, resulting in cherry-picking hundreds of commits to the stable branch.
• MRT rendering support in OpenGL ES 2.0 was added to Mesa by Ian Romanick. This change brought the GL_NV_draw_buffers and GL_NV_fbo_color_attachment OpenGL extensions to ES 2.0.
• Lots of internal shaders cleanup was also done by Ian Romanick.
• Paul Berry has sent yet more patches for gl_Clip_Distance and gl_ClipVertex to mesa-dev mailing list. Also, a (possibly final) version of clipping series of patches for Gen6 is floating around mesa-dev mailing list now.
• Also on mesa side, some work on GLES 1.1 conformance was done by Kenneth Graunke, together with new patches for HiZ support by Chad Versace and some GLSL 1.30 fixes by Carl Worth. Speaking on GLSL 1.30, it has received lots of commits from Eric Anholt, Kenneth Graunke and Paul Berry as well. The OpenGL 3.0 and GLSL 1.30 support is getting closer and closer now.
• On intel-gfx mailing lists, irc and bugzilla, lots of discussion and possible fixes for the RC6-related problems I mentioned in the previous post took place by myself, Daniel Vetter, Chris Wilson and many others. So far, a workaround for bug 38567 seems to be found, while the bug 41226 is still playing tricks with us. Those are the only rc6-related bugs we are aware of at the moment, so hopefully they will be solved pretty soon.
• Also on kernel side, some patches from Daniel Vetter and Ben Widawsky landed in the intel-gfx mailing list, which enable more verbose per-ring information collection. This would result in a much more accurate problem diagnosis – as newer GPU hardware has multiple rendering rings, the crash dumps not always provided all the necessary information. Now they should.
• Some more timing and display detection-related patches from Keith Packard arrived to the intel-gfx mailing list, which greatly improve the monitor detection timings and provide support for new MacBook Air displays. They should probably get into the Kernel 3.2, but can already be used to testing with the 3.1 (and, with some adaptations 3.0) kernel series.
• And finally, I’ve finally sent my patches for fixing the long display discovery issues to intel-gfx mailing list. According to the tests, they should improve the display detection timing by 30%–300%, by giving up earlier on non-working output ports. The effects should be more visible on machines which has lots of such ports – which is becoming quite common those days with the DisplayPort, HDMI, VGA, S-Video, and all the others connections we have out there.

On a related note, Mageia kernel was updated to 3.1-rc9 – so all the Mageia Cauldron users should experience a nice performance improvements with their Intel graphics cards. Mandriva kernel is at 3.1-rc9 as well, both distributions are on a similar page now.

As you already know, since August I am working at Intel, within the Intel Linux Graphics group. And, as many of you know as well, the news about Intel Linux graphics out there vary a lot, but usually just between the “it just works” and “nothing works” states, with few intermediate points in between (many of which are usually covered by phoronix news).

So to fill those empty spots, I thought on getting back into the habit of semi periodic write-ups I got while at Mandriva – just giving out some insights, overviews and overall updates about what is going on with Intel Linux Graphics and related open-source projects from time to time.

But first of all, let me do a quick review about what Intel Linux Graphics is all about. Unlikely other drivers project, the Linux Graphics does not consists from a single and unique driver. By the contrary, it has a lot of ground to cover, working directly on the upstream projects which compose the graphical stack – ranging from the i915 driver in kernel to the entire MESA 3D/GL stack, passing through libdrm and vaapi and all the way up to x11-server, cairo and wayland – among others. So when you read about an Intel Linux Graphics release, it considers a snapshot version of each of those components.

Of course, each of those projects has a different release goals and timelines, different sets of features to cover, and so on. And, of course, there is a matrix of different generations of graphical hardware, different variations of the models and revisions, and a multitude of OEM platforms to cover.

So, in short, “it’s complicated” .

In this sense, the Intel Linux Graphics project so far was doing quarterly releases of the entire stack, as one could see at 2011Q3, 2011Q1, 2010Q4 and all the previous ones. However, one of the problems with the quarterly releases, specially over such a big and varying stack, is that they don’t fit all the situations. So starting with the next release, we’ll be changing our process to carry out more specific releases, based on pre-defined release criteria for each of them. And the next release will be focused specifically on performance and stability enhancement over our current code.

What do I mean by performance and stability? While most of the people out there do not experience any issues with the drivers (e.g., “they just work” category I mentioned out there), we are by no means perfect, and yes, we have bugs which affect different users, operating systems and hardware components (all the way to that “nothing works” category of people – which is thankfully quite small, and of course we hope to promote it to the “just work” category of the people ASAP). And we are trying to get better and better for each release, at the same time trying to maintain the same level of openness as one would expect from open-source projects.

If you look at the freedesktop bugzilla, for intel graphics-specific issues, there is a quite complete list out there. Of course, many of those bugs are old, or do not apply to the current state of the code anymore, but some of those are valid – and they don’t get the level of attention they need. Specially considering the large number of reports, it is really hard to keep track of all of them, and it is specially easy to get lost among all of them. So if your bug is not getting enough attention – just go over to it, and ping us. We do not ignore you, but sometimes we lose track of specific issues out there, and we’ll be happy to be reminded either when an issue is fixed, or whether it is still out there and needs some love .

So, as I said previously, I’ll try to cover up the details of each part of our drivers stack, and try to keep updated the list of the current work and goals we have in mind. So I’ll start with this first post, and will try to cover a bit about the areas we’ve been focused the most for the past months – specially considering the “performance” and “stability” criteria, and the most interesting features we have out there.

RC6

The first feature which I’d like to mention, which is probably unknown to most of you out there, is the support for RC6 technology. This is a feature which allows the GPU (in other words, the graphical adapter) to enter an extremely low power-consuming state while the graphical card is idle. This feature has drastic effects on the power usage of the system – up to 26% power usage improvements according to Phoronix testing. So in theory, having this feature enabled by default would allow a much better battery life for a casual system out there equipped with an Intel graphical card.

However, one drawback to the rc6 is that in some very rare cases, it results in different set of issues. The good part is that very few systems are affected by this bug, and none of the machines either the developers or QA team has managed to reproduce the problems, so chances are very high that it could just work for your by adding a ‘i915.i915_enable_rc6=1′ parameter to the kernel. The bad part is.. well.. the same as the good part – we could not reproduce the issues on any of the machines we had. So by a chance, if you enable this feature and hit some unexpected behavior or issue – please, let us know! We would be really interested in fixing this for all the systems out there. But, with all the magnitude of different x86-based machines, it is virtually impossible to test them all. So we need your help to help of us fix this issue, in case it affects your machine. All the details, such as the vendor, model, installed OS, whether the issue happens with a new install from scratch, bios configuration – would help.

FBC

Besides RC6, one other interesting feature present in the Intel graphical drivers is the support for framebuffer compression, of fbc. This feature allows the driver to store the contents of the picture on screen in a compressed format, effectively reducing the amount of energy (and, therefore, power) required to update the screen. On some hardware revisions, however, this feature sometimes causes the GPU not to redraw the display correctly, resulting in only partial screen updates, sometimes visible only after a few suspend-resume sequences. The solution for this problem was to disable this feature by default on such machines, while having it enabled automatically on the chips which do not reproduce the problem. However, even on those chips, you can always enable it manually, by using a i915.i915_enable_fbc=1 kernel parameter.

Semaphores

And finally, the 3rd major issue being worked on the kernel side is the usage of semaphores in the graphical driver, which allows for a big jump in performance, and also in stability in some cases. However, not everything is perfect in this world , so on some hardware models this feature results in performance choppiness or GPU hangs. It is within of the nature of the bug to appear only on some selected machines, most of which are out of our reach, so chances are, like with the RC6 and FBC features, it should just work out of the box. But if it does not – please, let us know!

Apart from those 3 big items, lots of work has been carried out on different components of the stack in the past months. I’ll try to summarize the most interesting points for each component below.

Kernel

The Linux kernel 3.1, which is quickly approaching its release date, brings lots of stability and performance improvements over 3.0 version. The performance results are the most notable ones, as according to the initial testing, you could expect about 25% performance improvements in 3D games and performance benchmarks (and even up to 40% in some of them). I won’t enter into the details here, as I am certain that Michal Larabel from Phoronix will do his usual round of benchmarks soon enough and provide the numbers .

Besides the performance fixes, the timing for detecting the different video outputs has also received lots of attention. Some of the fixes will appear in 3.1 kernel, and some of them are already being prepared to get into 3.2 as soon as its merge window will open.

And of course, there were lots of patches for stability and error recovery within GPU.

Out of the major distributions out there, as far as I know, only Mandriva Cooker has already updated its kernel to the latest 3.1 pre-released version, so its users already have most of those features with them. So if you are a brave soul and are willing to try this as soon as possible, you could either try Mandriva’s development version; or download and build the 3.1-git kernel yourself. Or just wait a few weeks and it will came to you as soon as your $FAVORITE_DISTRIBUTION would update it in the repository.

So, leaving kernel area, let’s move to another major component of the stack, which is well-known by its name..

MESA

(No, it is not the Black Mesa Research Facility, so you may put away your crowbar )

Lots of work has been done on Mesa library, and some thousands of emails on the mesa-dev mailing list complement this statement.

Some initial patches for HiZ support from Chad Versace landed on the list, and Phoronix has also performed initial testing on them, obtaining very impressive results.

Also, a huge cleanup of old drivers, together with the removal of old DRI1 code and overall refactoring of the code in preparation for the GL 3.0 was done by Ian Romanick. Kenneth Graunke provided lots of patches for both performance and stability improvements for a large number of cases, together with the IvyBridge-specific optimizations. New Vertex Shader backend, lots of TextureImage development by Eric Anholt, work on gl_ClipDistance and the layout of vertex attributes by Paul Berry, lots of GLSL 1.30 development and overall bugfixing complement the picture of what happened with Mesa for the past month or so.

As mesa-dev list, and the git source tree, are quite busy places, there were lots of other development and updates all around which I haven’t covered here. Mesa 7.11.1 and 7.12 are really going to be amazing releases when they will come out!

But leaving mesa, the next stop in the Intel Linux Graphics stack overview leads us to..

DDX, or xf86-video-intel X driver

The video driver for Intel graphics cards has received lots of attention for the past weeks. Most of the patches came from Chris Wilson, and were related to further improvements in the SNA backend, and a fix for a non-SNA-related X crash. Besides those, we also had some IvyBridge-specific fixes from Kenneth Graunke and cleanup of some warnings from Paulo Zanoni.

Cairo

On Cairo side, a huge work has been made on performance, stability and testing. In some workloads, the performance improved by several orders of magnitude, and in average, one could expect better performance for Cairo on most cases when comparing with the previous release.

Wayland

For Wayland compositor, lots of discussions took place in the wayland-devel mailing list, covering a large collection of topics, randing from the best way to process configuration events and requests, similarities and differences between the wayland protocol and X operations, window management and overall interaction between the clients and the compositor within the Wayland world. From the technical side, there were lots of patches from Tiago Vignatti and Kristian Høgsberg on both core wayland and the wayland-demos repository. One notable change was the change of the GPLv2 headers to MIT for the remaining files where such change wasn’t applied previously.

Intel-gpu-tools

The package for providing tools for debugging, analyzing, tracing and profiling the Intel graphical cards on Linux/Unix has received some code cleanups from Paulo Zanoni, some news tests from Daniel Vetter, and also a small series of patches from myself which allows it to work in a non-interactive way, generating a tab-separated list of performance values for each capturing points. Those events can be further analyzed with a statistical tool, or plotted with gnuplot, or dumped into openoffice calc/excel applications – you name it.

Libdrm

Libdrm, which is a glue between the kernel and the userspace applications that use the kernel graphical driver, has received some fixes from Daniel Vetter last week. Besides those, there was a fix to make ‘make check’ work correctly, and a support for using xf86drm.h from C++ applications.

Xserver

X.org X server has received lots of updates and merges since the 1.11.0 release in the past weeks. Among the most notable ones, there were some enhancements to the DRI2, XRANDR and DAMAGE extensions, documentation, comments and scripts fixes, besides the changes in the input framework.

VAAPI

And finally, as for VAAPI, not much activities happened in the git repo for the past weeks besides some refinements on the API and the vatrace tool.

So, as this post has already grown past the size I originally expected, I think that I’ll stop about here this time.

I’ll try to continue with the semi-regular blogging about the news in the graphics land of Intel world on a weekly basis.

See you! Eugeni

(Yeah, by the way, I am back to arch+xfce4 now.. )

Mandriva 2011 beta3 running on macbook air

To do a more fair comparison between Mac and Linux approaches on same hardware, I took a shot and installed Mandriva 2011 beta3 (x86-64 version) alongside Mac OS X on the same Macbook air. The process is nowhere simple nor straight, but it is certainly possible. So in case someone wants to repeat the feat, here is a quick step-by-step instruction how to do so (alternatively, for the impatient ones, you could skip till the end of this post for a simple one-step solution).

• Download Mandriva 2011b3 from your favorite mirror. The architecture should not matter, but to get the most from the hardware I’d recommend 64bits edition (but it is solely up to you to decide).
• Run hdiutil convert -format UDRW -o mdv2011.img Mandriva.2011-beta3.x86_64.iso to convert the image to mac-compatible format
• Now comes the tricky part. In order to make the system boot from this image, it is not enough to create a bootable usb disk or create a local disk partition for the installation. You actually have to create 2 local disk partitions – one where the Linux will be installed, and another roughly equal to the size of the installable image (1.6GB as of mdv2011 beta3), where you should put the copy of the installation image using dd. In other words, you must do the following:
• Open disk utility from Dock->Utilities.
• Create a new partition with roughly 2GB in size.
• Create another partition with the space you want for your Linux install (about 10GB should be enough).
• Format both partitions as MSDOS FAT.
• Plug your pendrive which will be used for installation.
• Open a terminal, become root and run diskutil list, it should show you the partitions you have created and the pendrive. E.g., it should show something like:

  sh-3.2# diskutil list
  /dev/disk0
     #:                       TYPE NAME                    SIZE       IDENTIFIER
     0:      GUID_partition_scheme                        *121.3 GB   disk0
     1:                        EFI                         209.7 MB   disk0s1
     2:                  Apple_HFS Macintosh HD            89.9 GB    disk0s2
     3:       Microsoft Basic Data                         29.2 GB    disk0s3
     4:       Microsoft Basic Data                         2.0 GB     disk0s4
  /dev/disk1
     #:                       TYPE NAME                    SIZE       IDENTIFIER
     0:     FDisk_partition_scheme                        *8.0 GB     disk1
     1:                       0x17                         1.7 GB     disk1s1

Here, disk0s3 is the partition where the Linux system will live after the installation, disk0s4 is the partition for the installer, and disk1 is the disk currently located inside the pendrive.

• Now we have to transfer the installation image both to the pendrive and local partition. For this, first run diskutil unmountDisk /dev/disk0s4 and diskutil unmountDisk /dev/disk1 to unmount the partitions, and then transfer the image to them with dd if=mdv2011.img of=/dev/disk1 and dd if=mdv2011.img of=/dev/disk0s4.
• !! AS ALWAYS, make sure you know what you are doing, because dd command does not likes newcomers and non-careful people !!. If you are not careful, this is the step you have the most possibility of losing all your data for good. You’ve been warned.
• After it is done, the installation procedure is mostly prepared, but you still need to prepare your mac for multi-booting. Luckily for you, this is easy – just install refit and it should work without any configuration.
• Now, with the pendrive still plugged, reboot your machine. On boot prompt, there will be a new nice refit menu, where you should choose partition tool and allow it to syncronize the GPT partition table with MBR. This is necessary because grub1 and low-level system utilities used in Mandriva 2011 do not support GPT partition tables.
• Now you can try booting from your pendrive. If you receive a Non-system disk or Unable to find isolinux.bin, make sure that you have followed the steps of having the same image on both pendrive and local partition. What (apparently) happens in this case is that Mac gets confused about the local disks namings (e.g., it confuses the USB partitions with local disk ones), and isolinux gets lost trying to figure what to do and usually gets stuck. There is probably a more clean way to make this work, but as I am lazy sometimes, I just settled with this solution.
• If you got to the grub splashscreen, congratulations, you have almost reached half of the procedure . Now press TAB to edit kernel parameters, and change the root=LIVE:LABEL=… to root=LIVE:/dev/sdb. This way, you are telling kernel that the partition you are booting from is in fact the pendrive, and it won’t get lost trying to solve the puzzle of GPT+MBR+multiple disks mappings (more on this later). Just make sure you select Live system instead of Installation to prevent needless reboots and problems.
• If everything goes OK, you should be able to boot to KDE with 800×600 resolution. If you reached this point, open the konsole terminal, become root, run draklive-install and proceed with the installation until the partitioning step. At this point, the Mandriva installer gets confused by the GPT+MBR partition table as well, and gets lost about what to do. What you should do is remove the partition you dedicated for Mandriva installation (the big one, not the 2GB one), create a new one with your favorite Linux file system (I suggest ext4) and format it. Just name it as / partition and create no swap – we could always create a swap file later.
• Now the installer will tell you that the machine must be rebooted to update partition layout and will quit. Instead of rebooting, however, just run partprobe command as root and it will re-sync in-memory partition table with the new disk content, and restart draklive-install. Now it should allow you to proceed with the installation, so just sit back and relax while Mandriva gets installed on your system. Or go make a tea or drink a beer, cause it will take a somewhat long time.
• When the install finishes, in the bootloader installation step, make sure to install it to the root of the partition – in my case, it was /dev/sda3, but your mileage may vary.
• The install should finish, but in case grub-install command output in the terminal gave you an error message, you must install grub manually because somehow, surprisingly, it gets confused with the GPT+MBR layout as well. So just run grub-install /dev/sda3 and it should work. If it does not, try running just grub so it would recreate the device mapping, and install the bootloader manually (this is a bit technical and tedious procedure so I’ll skip it on behalf of clarity – feel free to ask in comments if you have questions about this point).
• Finally, run fdisk /dev/sda, unmark the /dev/sda4 (old installation partition) as active, and mark /dev/sda3 as active. Basically, fdisk /dev/sda – press – a – press – 3 – press -a – press – 4 – w should do it (/me feels like describing Mortal Kombat fatalities with this explanation ).
• Reboot, and a new Linux entry should appear within refit menu. However, when you try to boot it, grub will fail, saying that it is unable to locate kernel and initrd files at correct location. This, once again, is due to mismatch between GPT and MBR partition table, and a quick fix is to change (hd0,3) to (hd0,2) for both kernel and initrd lines. Once again, I am not describing the right fix, but the quickest one.
• When the system boots, everything should work automatically, including wifi and everything else. As Mandriva 2011 comes pre-loaded with firmware for most closed cards and devices, it all should just work out of the box.
• Just remember to edit /boot/grub/menu.lst file and make the change from (hd0,3) to (hd0,2) there to have it permanently remembered.

So, that’s it, and if you have got through this quick tutorial to this point and managed to get Mandriva 2011 installed on your Mac machine, you can consider yourself a true geek. Of course, most of this tutorial applies to Macbook Air, because it does not has a CD/DVD port – if it had, most of those steps wouldn’t be necessary at all. But.. we do not seek easy routes, are we?

And of course, I mentioned in the beginning of this post that there is a way to install Mandriva on OSX in just 1 simple step. This step is very simple – just ask me to send you a .dd.img copy of my Mandriva partition to you, so you could simple copy it into one of your own partitions, and it will just work. Somehow it feels a more natural way of distributing and packaging anything on Mac platform (I mean, within a .dmg file) – so I am unsure if it is more a hack than the complete tutorial I described above .

P.S.: Just to update you with some timings on the same hardware. Mac OS X 10.6.8 takes approximately 10 seconds from refit boot menu towards desktop. Stock Mandriva 2011 beta3 takes approximately 12 seconds from grub menu to kdm, and approximately another 12* seconds from kdm to full-featured desktop. After some optimizations, I could decrease this time to 7 seconds from grub to kdm, and 6 seconds from kdm to full-featured desktop. With auto-login they are tied in this comparison, which is really amazing!

Surprisingly, it was really not that hard. X11 protocol, even being insanely over-engineered and complex, is very well-thought (I’d say ‘overthought’ actually). The biggest problem came with the X.org modularization, which make me miss a lot the good old xfree86-based way of packaging and running X on Linux. The modularization is certainly easier to maintain and develop individual pieces of X stack, yes; but if you consider that instead of one big XFree86 tarball you have to check on hundreds (or better, dozens ) individual packages, some of which require specific libraries, some of which do not compile anymore with the latest “stable” version and require grabbing patches from git or even complete checkouts – it is a bit close to nightmare from packaging point of view.

But luckily, Paulo Zanoni (previous X.org maintainer on Mandriva) did a truly amazing job keeping those packages well-commented, updated and maintainable. So it took me about 4 hours to update/fix/upgrade them all locally, and also update X.org server to the latest 1.10.2 version, Mesa stack to 7.10.2 and libdrm to 2.4.26. The final piece was the change in X server parameters (from -nr to -background none) which break the default kdm configuration, but it was fixed today as well thanks to Neoclust, our unreplaceable KDE maintainer .

So, as of today, I am proud to announce that Mandriva 2011 is powered by the latest, shiniest and greatest X.org server 1.10.2 and Mesa 7.10.2, with all the awesomeness which comes with that. I had to write some small patches to fix some Intel Sandy Bridge crashes here and there, but I think that Mandriva today has probably the most up-to-date X.org stack out there.

So, when I finished this, I wondered about another toy I haven’t touched since 2008, which is the hot topic out there these days. Or, namely, wayland . It was a bit harder to get ready because I needed to update or import lots of complex packages, but nothing impossible.

So, as a picture says more than 1000 words (at this point, wordpress was nice enough to remind me that this post is at 400 word count already), here is a picture to illustrate my today’s progress on it:

Wayland server running with Mandriva 2011 X.org with git-based mesa, drm, cairo and intel driver .

For the brave souls out there, here is the full list of packages needed to make it work:

lib64xkbcommon0-0.1-1.20110610-mdv2011.0.x86_64
lib64xkbcommon-devel-0.1-1.20110610-mdv2011.0.x86_64
libxkbcommon-debug-0.1-1.20110610-mdv2011.0.x86_64
lib64pixman1_0-20110610-1-mdv2011.0.x86_64
lib64pixman-devel-20110610-1-mdv2011.0.x86_64
pixman-debug-20110610-1-mdv2011.0.x86_64
lib64cairo2-20110610-4-mdv2011.0.x86_64
lib64cairo-devel-20110610-4-mdv2011.0.x86_64
cairo-debug-20110610-4-mdv2011.0.x86_64
lib64cairo-static-devel-20110610-4-mdv2011.0.x86_64
lib64wayland-server0-0.1-1.20110610-mdv2011.0.x86_64
lib64wayland-client0-0.1-1.20110610-mdv2011.0.x86_64
wayland-0.1-1.20110610-mdv2011.0.x86_64
lib64wayland-server-devel-0.1-1.20110610-mdv2011.0.x86_64
lib64wayland-client-devel-0.1-1.20110610-mdv2011.0.x86_64
wayland-debug-0.1-1.20110610-mdv2011.0.x86_64
lib64mesaglapi_0-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaopenvg1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64dri-drivers-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesawayland_1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
mesa-modesetting_drv-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglapi_0-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglesv2_2-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglesv1_1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaegl1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaopenvg1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesagl1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64dri-drivers-experimental-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesawayland_1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglesv2_2-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglesv1_1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaegl1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesagl1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglu1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglw1-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
mesa-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglut3-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglu1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglw1-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
mesa-debug-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
lib64mesaglut3-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
mesa-common-devel-7.10.2.99-0.git20110610.1-mdv2011.0.x86_64
wayland-demos-0.1-1.20110610-mdv2011.0.x86_64
wayland-demos-debug-0.1-1.20110610-mdv2011.0.x86_64

Of course, all this awesomeness lives only on my notebook for now, I am not crazy enough to commit it to cooker. But if anyone out there is interested in taking a look, drop me a note; I’ll be more than happy to share it with you.

To sum it up, it was really nice to relearn the x.org and mesa packaging/development which I have to confess I’ve been missing during those past years. This was certainly fun .

Lots of things are happening on all fronts.

On Mandriva side, Mandriva 2011 beta3 was just released, as promised, bringing lots of changes and bugfixes. One particularly amazing items I’d like to highlight is the TimeFrame feature, developed by ROSA Labs. It brings the power of nepomuk-powered annotations and tags to your desktop in an amazingly easy yet powerful fashion, allowing you to browse and access your files by date unlike any other software I know. Think about it as about zeitgeist and visualizing-your-stuff-according-to-the-timeline from Mandriva/ROSA. Totally awesome (IMHO) and extremely useful application of nepomuk technologies!

Timeframe example

On OpenClass side, the software has reached 0.2 version, and the development is by no means slowing down. Lots of new features and improvements are coming along daily. I guess I have never worked so easily on any piece of software, and it is amazing. And now, being present in Mandriva repos, having its own Ubuntu ppa repositories and Windows-compatible installer, it looks better than ever. Thanks for all your comments and feedback, I truly appreciate it a lot!

OpenClass on the-one-OS-whose-name-cannot-be-spoken

And finally, on personal side, I’ve got engaged last week .

So, in summary, life is going on fast. And that’s great!

For those of you who haven’t got a chance to look at it yet – OpenClass is an open-source class control solution which I develop in my free time, which helps teacher to control his activities in the classroom. Among such activities, the ones most notable ones are:

(From teacher to student)

• screen projection (send content of teacher screen to all the students)
• full-screen resolution-independent screen projection
• student attention request (blocking student activities and asking them to look at teacher)
• viewing contents of all students screens at once
• direct messaging to students
• file sharing and URL sharing to enrich class activities
• shutting down student computers from teacher
• allow and reject students from a specific class
• allow to block students from attempting to connect to a class
• support for multi-seat configurations and multiple clients per machine (for example, xdmcp-based environments)

(From student to teacher)

• automatic teacher discovery via broadcast
• receiving of teacher screen projection via multicasting protocol, suitable for both wired and wireless environments
• “raise hand” functionality to call teacher attention
• possibility to select teacher to connect to
• automatic handling of network saturation and disconnection events

And, of course, the best part. This application is open-source, and distributed under the GPLv2 license.

Of course, one could wonder – why should we need another class control solution, specially if we have ITALC?

Well, as most things in Linux and open-source world… just for fun!

But speaking seriously, I’ve been working on developing a closed-source multi-platform class control application called Bluelab at mstech from 2005 to 2008, until I left the company. However, most of this time since then, I felt that while there are many powerful, big, premium, advanced and full-featured classroom control solutions, some things were still missing in all of them..

So I decided to write one new solution, which would look like I think it should. Small. Efficient. Fast. Open-sourced. And real.

For this, I took some hours of my free time for some of the past weeks, and wrote it entirely from scratch, based on some lose ideas I had for the past years.

So, if you are interested – please, feel free to access the project page, look at the screenshots, grab the code from github, or grab the mandriva 2011-ready packages directly.

And – of course – if you have ideas, comments, suggestions, critics and contributions, please, say .

So, in April, Funda Wang managed an impressive number of 600+ commits. He was followed by jquelin and goetz, with almost 200 commits each, then neoclust and cfergeau (I’ll mark Mandriva current/former employees with bold marks for the sake of clarity) with a bit more than 100 commits, and then by many others.

Committers for April 2010

In May, neoclust got his revenge and ranked at number 1 with almost 300 commits. Funda came second with approximately 150 commits, and then we had thomas, tpg, fcrozat and guillomovitch.

Commits history for May/2010

In June, fcrozat beat the competition with his almost 100 commits. Thomas, goetz, ahmadsamir, neoclust, fwang, oden and me were the ones to do more than 20 package commits. Note that during this month cooker was frozen, so only the approved and highly-trusted fixes were accepted into it.

Commits for June/2010

July was the month of jquelin to be the king of the hill, he did an insane number of 800+ package rebuilds for perl. Funda came second with 500+ updates, then goetz, tpg and kharec.

Commits for July/2010

Funda regain the leadership in August, handling over 600 packages. Goetz got the second place with 400+, and jquelin – still on the perl rampage – did another 200+ packages. Neoclust was forth, with a bit more than 100 packages.

Commits history for August/2010

Goetz was the master-packager in September, delivering over 400 commits. Funda Wang got the silver medal with 300+ packages, and peroyvind delivered more than 100 packages as well. Jquelin, tpg, neoclust and oden were not far behind either.

September/2010 commits

And finally, now, in the first few days of October, Funda already managed to leave all the competition way behind, already being responsible for almost 200 commits. He is being followed by tv with about 60 packages, the thomas and goetz who almost got to 50 packages each, and peroyvind and oden, with about 40 and 30 packages each one.

October/2010 commits

So, considering the period from March 30rd to October 11th, the top-10 commiters in Mandriva Linux community are:

• fwang: 2492
• goetz: 1511
• jquelin: 1375
• neoclust: 739
• tpg: 416
• guillomovitch: 414
• thomas: 374
• peroyvind: 363
• ahmadsamir: 339
• oden: 320

In this list, Oden is working at Mandriva, and Neoclust was working on kde packages until the last month. But besides them, I guess it can be safely assumed that Mandriva community contribution to the distribution is far from inexistent .

…until yesterday! I became tired on metacity not offering this feature, so I just went ahead and implemented it overnight (learning a lot about gnome development during the process).

So, if anyone out there was missing this feature – feel free to grab this patch and apply it to the metacity source. Basically, it will add one new gconf entry (switch_to_previous_workspace), and will make metacity remember the last workspace. So you can press ctrl-f2 to switch to from workspace 1 workspace 2, and when you press ctrl-f2 again metacity will recognize that you want switch back, to whatever workspace you were before, and will do it.

Once again, this is the beauty of the open source. If there is something you need, but nobody implemented it, you always have the possibility of just doing it yourself. At least, sometimes .

diff -p -up metacity-2.30.1/src/core/prefs.c.switch metacity-2.30.1/src/core/prefs.c
--- metacity-2.30.1/src/core/prefs.c.switch 2010-03-30 11:35:40.000000000 -0300
+++ metacity-2.30.1/src/core/prefs.c    2010-05-06 17:47:14.000000000 -0300
@@ -97,6 +97,7 @@ static char *cursor_theme = NULL;
 static int   cursor_size = 24;
 static gboolean compositing_manager = FALSE;
 static gboolean resize_with_right_button = FALSE;
+static gboolean switch_to_previous_workspace = TRUE;
 static gboolean force_fullscreen = TRUE;

 static MetaVisualBellType visual_bell_type = META_VISUAL_BELL_FULLSCREEN_FLASH;
@@ -412,6 +413,11 @@ static MetaBoolPreference preferences_bo
       &resize_with_right_button,
       FALSE,
     },
+    { "/apps/metacity/general/switch_to_previous_workspace",
+      META_PREF_SWITCH_TO_PREVIOUS_WORKSPACE,
+      &switch_to_previous_workspace,
+      FALSE,
+    },
     { NULL, 0, NULL, FALSE },
   };

@@ -1757,6 +1763,9 @@ meta_preference_to_string (MetaPreferenc

     case META_PREF_FORCE_FULLSCREEN:
       return "FORCE_FULLSCREEN";
+
+    case META_PREF_SWITCH_TO_PREVIOUS_WORKSPACE:
+      return "SWITCH_TO_PREVIOUS_WORKSPACE";
     }

   return "(unknown)";
@@ -2719,6 +2728,12 @@ meta_prefs_get_mouse_button_menu (void)
   return resize_with_right_button ? 2: 3;
 }

+guint
+meta_prefs_switch_to_previous_workspace (void)
+{
+  return switch_to_previous_workspace;
+}
+
 gboolean
 meta_prefs_get_force_fullscreen (void)
 {
diff -p -up metacity-2.30.1/src/core/screen-private.h.switch metacity-2.30.1/src/core/screen-private.h
--- metacity-2.30.1/src/core/screen-private.h.switch    2010-01-14 22:31:32.000000000 -0200
+++ metacity-2.30.1/src/core/screen-private.h   2010-05-06 17:47:14.000000000 -0300
@@ -80,7 +80,7 @@ struct _MetaScreen
   MetaUI *ui;
   MetaTabPopup *tab_popup;

-  MetaWorkspace *active_workspace;
+  MetaWorkspace *active_workspace, *last_workspace;

   /* This window holds the focus when we don't want to focus
    * any actual clients
diff -p -up metacity-2.30.1/src/core/workspace.c.switch metacity-2.30.1/src/core/workspace.c
--- metacity-2.30.1/src/core/workspace.c.switch 2010-01-14 22:31:32.000000000 -0200
+++ metacity-2.30.1/src/core/workspace.c    2010-05-06 18:00:39.000000000 -0300
@@ -377,7 +377,31 @@ meta_workspace_activate_with_focus (Meta
                 meta_workspace_index (workspace));

   if (workspace->screen->active_workspace == workspace)
-    return;
+  {
+      meta_verbose("Switching to same workspace detected, going back to previous one!!\n");
+      if (meta_prefs_switch_to_previous_workspace()) {
+          if (workspace->screen->last_workspace) {
+              meta_verbose("Going to desktop %d\n", meta_workspace_index(workspace));
+              meta_workspace_activate_with_focus(workspace->screen->last_workspace,
+                      NULL, timestamp);
+              return;
+          } else {
+              meta_verbose("No old workspace..\n");
+              return;
+          }
+      } else {
+          meta_verbose("Last workspace switching disabled..\n");
+          return;
+      }
+  }
+  else
+  {
+      if (workspace->screen->active_workspace)
+          meta_verbose("Updating last workspace.. current: %d, new: %d\n",
+                  meta_workspace_index(workspace->screen->active_workspace),
+                  meta_workspace_index(workspace));
+      workspace->screen->last_workspace = workspace->screen->active_workspace;
+  }

   if (workspace->screen->active_workspace)
     workspace_switch_sound(workspace->screen->active_workspace, workspace);
diff -p -up metacity-2.30.1/src/include/prefs.h.switch metacity-2.30.1/src/include/prefs.h
--- metacity-2.30.1/src/include/prefs.h.switch  2010-01-14 22:31:32.000000000 -0200
+++ metacity-2.30.1/src/include/prefs.h 2010-05-06 17:47:14.000000000 -0300
@@ -60,7 +60,8 @@ typedef enum
   META_PREF_CURSOR_SIZE,
   META_PREF_COMPOSITING_MANAGER,
   META_PREF_RESIZE_WITH_RIGHT_BUTTON,
-  META_PREF_FORCE_FULLSCREEN
+  META_PREF_FORCE_FULLSCREEN,
+  META_PREF_SWITCH_TO_PREVIOUS_WORKSPACE
 } MetaPreference;

 typedef void (* MetaPrefsChangedFunc) (MetaPreference pref,
diff -p -up metacity-2.30.1/src/metacity.schemas.in.in.switch metacity-2.30.1/src/metacity.schemas.in.in
--- metacity-2.30.1/src/metacity.schemas.in.in.switch   2010-05-06 17:47:14.000000000 -0300
+++ metacity-2.30.1/src/metacity.schemas.in.in  2010-05-06 18:01:16.000000000 -0300
@@ -4,6 +4,24 @@
     <!-- General preferences -->        

     <schema>
+      <key>/schemas/apps/metacity/general/switch_to_previous_workspace</key>
+      <applyto>/apps/metacity/general/switch_to_previous_workspace</applyto>
+      <owner>metacity</owner>
+      <type>bool</type>
+      <default>false</default>
+      <locale name="C">
+         <short>Remember and recall previous workspace when switching via keyboard shortcuts</short>
+         <long>
+           Set this to true to allow to switch to previous workspace when
+           using the current workspace keybinding. For example, if you switched
+           from workspace 2 to workspace 1 by pressing keyboard shortcut for
+           workspace 1, pressing the same shortcut again while on workspace 1
+           will switch to workspace 2.
+         </long>
+      </locale>
+    </schema>
+
+    <schema>
       <key>/schemas/apps/metacity/general/mouse_button_modifier</key>
       <applyto>/apps/metacity/general/mouse_button_modifier</applyto>
       <owner>metacity</owner>
diff -p -up metacity-2.30.1/src/metacity.schemas.in.switch metacity-2.30.1/src/metacity.schemas.in
--- metacity-2.30.1/src/metacity.schemas.in.switch  2010-04-06 07:10:38.000000000 -0300
+++ metacity-2.30.1/src/metacity.schemas.in 2010-05-06 18:01:06.000000000 -0300
@@ -4,6 +4,24 @@
     <!-- General preferences -->        

     <schema>
+      <key>/schemas/apps/metacity/general/switch_to_previous_workspace</key>
+      <applyto>/apps/metacity/general/switch_to_previous_workspace</applyto>
+      <owner>metacity</owner>
+      <type>bool</type>
+      <default>false</default>
+      <locale name="C">
+         <short>Remember and recall previous workspace when switching via keyboard shortcuts</short>
+         <long>
+           Set this to true to allow to switch to previous workspace when
+           using the current workspace keybinding. For example, if you switched
+           from workspace 2 to workspace 1 by pressing keyboard shortcut for
+           workspace 1, pressing the same shortcut again while on workspace 1
+           will switch to workspace 2.
+         </long>
+      </locale>
+    </schema>
+
+    <schema>
       <key>/schemas/apps/metacity/general/mouse_button_modifier</key>
       <applyto>/apps/metacity/general/mouse_button_modifier</applyto>
       <owner>metacity</owner>
@@ -247,7 +265,7 @@
       <applyto>/apps/metacity/general/theme</applyto>
       <owner>metacity</owner>
       <type>string</type>
-      <default>Clearlooks</default>
+      <default>Ia Ora Steel</default>
       <locale name="C">
          <short>Current theme</short>
          <long>

Our old friend net_monitor, present in your favorite Mandriva distro!

The net_monitor currently used in all Mandriva versions is written in perl, is using internal drakx-net api (and is, therefore, only usable on Mandriva), and also have some issues such as memory leaks and non-usual interface. After a few thoughts and discussions we came to conclusion that it would be more adequate to project and rewrite it from scratch, turning it more modular, expansible and focused on common use cases.

Initially, I thought on using perl to write it, so it would still be part of drakx-net suite. However, after thinking on the code and the way it should work I felt that my brain was going to melt down (perl is a nice language, but it is certainly not that compatible with me). So I ended up with python, which is my language of choice (together with C). Also, I’ve received many comments saying that the net_monitor is no more relevant, as every desktop environment provides its own network monitoring tool, and it should be dropped from drakx-net. By combining those issues, we came to decision that it would be more proper to separate net_monitor into a different package – this way, it won’t depend on any drakx-net internal functionalities, and user could uninstall it if required and use his own network monitoring tool if he wants to. And, at the same time, users would still have a cute little network monitoring application on their machines.

So, as a picture says more than a thousand words, I guess I’ll just add some pictures here than additional KBs of text (EDIT: please note that the look and features of net_monitor have changed significantly in Mandriva since this post):

net_monitor monitoring a wireless connection

net_monitor monitoring a connection for which network accounting was not enabled

net_monitor displaying some statistics about your network usage (provided by vnstat)

looking at daily traffic statistics on my notebook for the past month

...and hourly statistics...

...and finding our when I killed my bandwidth..

Surely, this is just an early and preliminary version, with many missing features and such. If you want to give it a try, just install net_monitor package, and it will create /usr/bin/net_monitor executable for you. It won’t conflict with existent net_monitor from drakx-net which is installed in /usr/sbin, so both of them may coexist on your system. If you look at /usr/share/doc/net_monitor/TODO, you’ll see some of the ideas that I intend to add to it, but the idea is to keep it simple and not transform it into an emacs of network monitoring . And, of course, feel free to add your comments and suggestions (and bug reports) here!

P.S.: Just to prevent comments like ‘you should focus on fixing bugs instead of wasting time writing new things’. Net_monitor is present in Mandriva for years now, and if you look at bugzilla list it has a number of bugs and issues. So I am not creating a new app – I am bringing back from the land of the dead an old one .

P.P.S.: Answering in advance to another question – yes, it would work on any Linux distro which has python and pygtk. You’ll just have to add some tricks into your network startup scripts to enable vnstat integration, but it will work just fine even without that.

This time we have several improvements, such as:

• support for audit plugins
• more msec auditing checks
• improved auditing logging
• and, of course, bugfixes.

So let me introduce some details about each one of them.

Support for audit plugins

You may remember that msec shipped with Mandriva 2009.1 introduced support for plugins infrastructure (take a look at your /usr/share/msec/plugins/ directory to see some examples). This new msec, which will be shipped with Mandriva 2010, also introduces auditing plugins.

Well, you might be asking what the ..? what is the difference between those plugins?, so let me clarify it a bit.

Msec has two main functionalities:

• Security configuration
• Security auditing

The security configuration is what you configure using msecgui or using security levels – basically, you say what settings should be used on your machine for ssh, user logins, and all kind of system configuration. The security auditing are those background checks that run daily on your machine, to determine what has changed since the last run and let you know about that.

In old msec, this security auditing was performed by security.sh, security_check.sh and diff_check.sh, so we had just three large and complex files with a lot of duplicated code. With new msec version, everything was split to reduce code duplication, improve readability and simplify plugins creation.

Let me show you a sample plugin which checks for changes in system users:

    #!/bin/bash
    # msec: check for changes in local users

    # check if we are run from main script
    if [ -z "$MSEC_TMP" -o -z "$INFOS" -o -z "$SECURITY" -o -z "$DIFF" ]; then
            # variables are set in security.sh and propagated to the subscripts
            echo "Error: this check should be run by the main msec security check!"
            echo "       do not run it directly unless you know what you are doing."
            return 1
    fi

    # files to log the list of today's and yesterday's, and difference between them
    USERS_LIST_TODAY="/var/log/security/users_list.today"
    USERS_LIST_YESTERDAY="/var/log/security/users_list.yesterday"
    USERS_LIST_DIFF="/var/log/security/users_list.diff"

    # update yesterday's list
    if [[ -f ${USERS_LIST_TODAY} ]]; then
        mv ${USERS_LIST_TODAY} ${USERS_LIST_YESTERDAY};
    fi

    # check for changes in users
    if [[ ${CHECK_USERS} == yes ]]; then
        getent passwd | cut -f 1 -d : | sort > ${USERS_LIST_TODAY}
        Diffcheck ${USERS_LIST_TODAY} ${USERS_LIST_YESTERDAY} ${USERS_LIST_DIFF} "local users"
    fi

that’s it. You just drop this file into /usr/share/msec/scripts/01_check_for_users.sh and this check will be executed every time msec security checks are run. The security log will be updated, the diff check mail will be created and mailed (along with all other checks), and it will be working automatically from now on.

More msec auditing checks

A few additional msec auditing checks were added:

• CHECK_FIREWALL — checks for changes in iptables configuration
• CHECK_USERS — checks for changes in local users (most of its code was shown above actually)
• CHECK_GROUPS — checks for changes in local groups
• FIX_OWNER — if unowned files are found on the system, this check gives the opportunity to change their ownership to nobody/nogroup, instead of blindly doing it automatically
• CHECK_RPM_PACKAGES — checks for changes in installed RPM packages
• CHECK_RPM_INTEGRITY — checks all the installed packages for changed files. Both those checks were run before under the CHECK_RPM check, but, as they are quite expensive, these two new checks were introduced instead

If you are using cooker or 2010 alpha, these options will not be added automatically to your /etc/security/msec/security.conf configuration file. The best way to experiment with them is by using msecgui, or running msec -f standard or msec -f secure to install default configuration for standard and secure levels.

Besides those items, I was thinking on an option to check for changes in PAM authentication, check for failed login attempts and support for rkhunter. And, as always, if you have any idea on some other functionality that should be interesting to have in msec, feel free to comment!

Improved auditing logging

The logging format of /var/log/security.log was changed to be compatible with syslog-based logging. This should make it easier for system applications to parse it, and for administrator to examine its contents. Now it is way easier to find information by date, kind of message and check type.

Other ideas

Among other ideas for msec I thought on the following:

• msec supports an arbitrary number of custom security levels, but msecgui only supports two basic ones (standard and secure). It could be nice to have a combobox to select a custom profile..
• gui for TOMOYO security framework, since the AppArmor project looks quite stone-cold dead. This is already a work in progress, so probably I’ll post some update on this later.
• Support for administrator-supplied rules for security and diff checks. For example, to exclude everything matching ‘/var/tmp’ from any kind of checks and reports, or excluding network ports from 3000 to 5000 from open port checks.

Besides that, there is a number of bugfixes (which are going to be backported to 2009.1 shortly).

So msec is definitely is alive and getting better and better. Stay tuned for more news!

However, after running git gc on top of drakx-net directory, the .git directory size went from 70MB down to 4MB. A 17.5x improvement! Unbelievable!

So I did the same to msec repository, with quite similar results — from 21MB down to 3MB!

So a mental note to myself – run git gc always. It rocks.

Nada como uns 10 minutos de programação voltada a gambiarras .

#!/usr/bin/python
#
# quick and dirty french2english translator
#

import urllib
import urllib2
from subprocess import Popen, PIPE

URL='http://translate.google.com/translate_t#fr|en|'

print "Paste your message"
msg = []
while 1:
    try:
        line = raw_input('>> ')
        msg.append(line)
    except:
        break

s = ">>" + "\n>>".join(msg)

data = "http://translate.google.com/translate_a/t?client=t&%s&fr&tl=en" % urllib.urlencode({'text':s})
req = urllib2.Request('http://translate.google.com/translate_t', data, {'User-Agent':'Mozilla/5.0'})
resp = urllib2.urlopen(req).read()
p = Popen("lynx -dump -stdin | grep -- '>>'", shell=True, stdin=PIPE, stdout=PIPE)
p.stdin.write(resp)
p.stdin.close()
trans = p.stdout.read()
print trans

Agora é só dar ctrl-c no texto, depois rodar o programinha e dar ctrl-v seguido por ctrl-d .

huauhahahahaha

via Aegisub: If programming languages were religions….

Por exemplo, vamos imaginar a função que vai fazer todas as combinações entre os elementos de uma lista. Ela pode ser escrita de forma funcional:

# permutate-func
def permutate(l):
    '''Returns all possible combinations of list values'''
    return reduce(lambda x, y: y + x, [ [(x, y) for y in l if x != y] for x in l ])

ou de forma iterativa:

# permutate-iter
def permutate(l):
    '''Returns all possible combinations of list values'''
    res = []
    for x in l:
        for y in l:
            if x != y:
                res.append((x, y))
    return res

Para listas pequenas não temos muita diferença de desempenho. Agora para listas maiores (por exemplo, com 1000 strings):

dups=['string%d' % x for x in range(1000)]
permutate(dups)

temos os seguintes resultados para programação funcional:

# time permutate-func
real    0m24.494s
user    0m20.763s
sys 0m1.698s

e os seguintes para o algoritmo iterativo:

# time permutate-iter
real    0m1.191s
user    0m1.150s
sys 0m0.036s

O tempo de 24 segundos caiu para apenas 1 segundo!

Qual conclusão tiramos disso? Embora programação funcional é extremamente poderosa, em alguns casos é melhor usar outras soluções para o problema .

from gtk.gdk import *
screenshot = Pixbuf(COLORSPACE_RGB, False, 8, screen_width(), screen_height())
screenshot.get_from_drawable(get_default_root_window(), colormap_get_system(), \
    0, 0, 0, 0, screen_width(), screen_height())
screenshot.save("tela.jpg", "jpeg", {"quality": "75"})

(Tá certo, dividi em 5 linhas para melhorar a legibilidade, mas no fundo são só 4 linhas mesmo).

Uma das maiores vantagens do python para mim é a legibilidade do código, facilidade de programação, e eficiência. Com quantas linhas de código seria possível fazer esse exemplo em qualquer outra linguagem? (Não vale apelar para import -window root tela.jpg porque aí é ImageMagick que faz toda a mágica!)

Por exemplo, sem a programação funcional, eu usava o seguinte código antes para ler um arquivo com uma série de números, e determinar a média dos valores:

fd = open("data.log")
data = fd.readlines()
valores = []


le os dados

for line in data:
    line_val = float(line.strip())
    valores.append(line_val)

calcula a media

media = 0
for item in valores:
    media += item
media /= len(media)

Re-escrevendo isso com técnicas de programação funcional, temos o seguinte:

le os valores do arquivo, transformando-os para floats, e ignorando strings vazias

valores = [float(val) for val in open("data.log").readlines() if len(val) > 1]

calcula a media, somando todos os valores e dividindo pelo número de elementos no vetor

media = reduce(lambda x, y: x+y, valores) / len(valores)

(É óbvio que é só um exemplo rápido, não estou tratando as excessões aqui, mas para resolver problemas simples do dia-a-dia é mais de que suficiente!)

O essencial são as funções lambda, map, reduce e filter. Todos os detalhes interessantes sobre esse estilo de programação eu achei aqui, e recomendo essa apresentação para todos!

Functional Programming with Python (RuPy 2008)

Slashdot | World’s Shortest P2P App: 15 Lines

Impressionante.. como tudo em python!

Este script pega a lista de músicas do mpd, seleciona um playlist aleatório, e coloca no ipod shuffle.

!/usr/bin/python

import os,random

ipod mountpoint - must be mounted!

MOUNTPOINT="/mnt/ipod"

def get_files():
    '''Reads the list of mp3 files from mpd database'''
    data = open(".mpd.db").readlines()
    files = []
    for l in data:
        fields = l.strip().split(":",2)
        if len(fields) < 2:
            continue
        if fields[0] == "file":
            files.append(fields[1].strip())
    return files

def get_free_space():
    '''Gets available space from IPOD partition'''
    line = os.popen("df -k %s | awk '{print $4}'" % MOUNTPOINT).readlines()[-1]
    return int(line)

def fullcp(file, target):
    '''copies file and directory structure'''
    os.system('tar cf - "%s" | (cd %s && tar xf -)' % (file, target))

if name == "main":
    try:
        os.mkdir("%s/mp3" % MOUNTPOINT)
    except:
        print "Not creating %s/mp3!" % MOUNTPOINT
    files = get_files()
    freespace = get_free_space()
    while 1:
        # pega arquivo aleatorio
        pos = random.randint(0, len(files))
        curfile = files[pos]
        del files[pos]
        # determina o tamanho
        res = os.stat(curfile)
        size = res[6] / 1000
        if freespace - size < 1:
            break
        freespace -= size
        # copia
        print "Copying [%8dK left]: %s" % (freespace, curfile)
        fullcp(curfile, "%s/mp3/" % MOUNTPOINT)

É melhor usar ele junto com Shuffle-DB.

Muita gente já escreveu sobre isso, com opiniões variando entre “é a salvação do universo” e “e daí??”; agora eu queria falar a minha opinião, que não é nenhuma das duas.

Primeiro, vamos relembrar um pouco a situação como ela estava a alguns poucos anos atrás (vou comparar a evolução do OpenOffice com o Microsoft Office… porque todos os outros pacotes de Office, seja de IBM, de Corel, da SUN, ou de qualquer outra empresa perdem significativamente para o próprio OpenOffice. Temos o Google Docs, mas, obviamente, é um caso a parte!).

Na época que não tinha OpenOffice 1.0, e só tinha os milestones que – com muita sorte – até funcionavam e abriam alguns (poucos e seletos) arquivos do office. Você acha que o OpenOffice hoje em dia é lento?? Ha-ha. Instale algum dos milestones antigos – ou o 1.0 mesmo para ver a diferença. A maior vantagem dessas primeiras versões é que era possível abrir e editar uma grande parte dos arquivos de Microsoft Office. Obviamente, não todos, mas muitos. Nem isso não era possível antes (abiword? koffice? staroffice, siagoffice? prefiro não comentar).

A versão 1.0 foi um marco gigante – foi uma versão estável (na medida do possível), multi-plataforma, completamente livre e que abria a maior parte dos documentos existentes. Mais uma vez – não absolutamente todos, mas a grande maioria. Abrir lentamente, com interface diferente, com diversos problemas de layout, posicionamento e funcionamento, mas.. ela funcionava!

A versão 1.1 melhorou significamente o problema de desempenho, e essas melhorias continuaram com todas as versões posteriores. Versão 2 (e suas sub-versões) introduziu nova interface, suporte a ODF e desempenho muito melhor. E logo-logo vamos ter a versão 3.0.

O que é possível notar nessa evolução das versões?? Primeiramente, o número de reclamações caiu significativamente! Vejamos:

• Interface diferente: com o lançamento de Microsoft Office 2007 esta reclamação perdeu completamente o sentido. OpenOffice é muito mais parecido com as versões antigas do Office de que o próprio software de microsoft…
• Suporte incompleto a documentos de office: por mais reclamações que é possível encontrar sobre isso, tem que aceitar que o número de problemas de compatibilidade decresceu absurdamente nos últimos anos. Antes era sorte ter um documento .doc(.ppt, .xls) que abriria corretamente no OpenOffice. Hoje, em contra-partida, é difícil achar um documento com problemas. Chega a casos curiosos, onde OpenOffice consegue abrir documentos que travam o próprio Microsoft Office , e a própria Microsoft assume isso (obviamente, não publicamente ).
• Desempenho inadequado: esta afirmação também perdeu o sentido ao avaliarmos o Microsoft Office 2007.
• Falta de funcionalidades: o OpenOffice ainda não implementa todas as 100% das funcionalidades que o Microsoft Office oferece. Porém… você conhece alguém que usa TODOS os recursos do Word?? Pois é, as funcionalidades já presentes são mais de que adequadas…
• e assim por diante..

Qual é a conclusão que dá para tirar, avaliando as versões atuais de OpenOffice??

Elas já oferecem todas as funcionalidade que a absoluta maioria dos usuários precisam. Nem sempre do jeito idéntico ao Microsoft Office; nem sempre com a mesma interface; e nem sempre com todas as variações, mas oferecem!

E quanto a desempenho.. Seguindo os conselhos básicos localizaveis facilmente no google (desligar java, diminuir o cache, diminuir o uso de memória; otimizar o carregamento; desativar funcionalidades avançadas, etc) é possível melhorar o tempo de execução inicial em mais de 10x, e uso de memória em mais de 4x (eu comprovei isso com projetos que fizemos com Intel e Ardence em 2004-2005; inclusive tem até publicações da Intel sobre isso – as de Ardence continuam sendo sob n.d.a. até onde eu sei ). Mas, se alguém tiver curiosidade, fiquem a vontade para perguntar por aqui mesmo!

Bem.. passando por esta introdução pequena , o que vamos ver na nova versão de OpenOffice?

• Suporte a Mac OS X – bastante interessante, porque vai ser possível rodar o OpenOffice em cima de MAC sem precisar de servidor X.
• Suporte a ODF 1.2 e OOXML – preciso falar alguma coisa??
• Suporte a PDFs editáveis – conhece algum outro escritório que permite isso?
• Suporte a macros em VBA – uma das maiores limitações atuais foi a execução de macros voltados para Microsoft Office. Não mais.
• Suporte a extensions – extensions fizeram do firefox o browser tão popular o quanto ele é hoje em dia. Enquanto plugins para OpenOffice existem já faz alguns anos, nunca foi simples ou intuitivo instalar e usar eles. Acredito que agora isso vai ser resolvido definitivamente.
• Melhor suporte a multi-midia – suporte a reprodução de sons em background, suporte a múltiplos monitores, melhor suporte para CSV, HTML, melhor na renderização de fontes; melhorias na edição de imagens, e assim por diante. A lista é grande.
• Novas funcionalidades – novas possibilidades relacionadas a planilhas, formulas, gráficos, renderização de páginas WEB, etc
• e muitos outras melhorias menos significativas

O que dá para extrair de tudo disso? É simples – o desenvolvimento do OpenOffice é feito de forma evolucionária, e não revolucionária. O que acontece é que ele fica melhor e melhor gradativamente, e não visa fazer milagres de uma hora para outra. É bom isso? Sim, porque é possível ver o que podemos esperar das próximas versões. Isso tem lados negativos? Claro, porque sempre vamos ver comentários do tipo “office não está evoluindo”, “versão 2 é parecida com 1″, “microsoft é mais diferente”…

O resto vamos ver logo, na versão 3.0 do OpenOffice .

• SVN + SVK – parecido com SVN, tem os mesmos problemas que ele (cria um monte de diretórios, etc). Na minha opinião, não tem muito uso prático – é melhor usar soluções distribuídas mesmo (bzr, git ou mercurial), porque todas elas tem gateways para SVN propriamente dito.
• BZR – acho que é o meu favorito para a maioria das coisas. Facil de usar (o mais fácil de todos, na minha opinião), rápido – principalmente nas últimas versões, extensível. Os meus maiores problemas com ele foi o desempenho (que foi resolvido na versão 1.0), e o tratamento de arquivos binários grandes – ele fazia questão de colocar o commit inteiro na memória, em formato ASCII ainda. Ou seja, para fazer commit de 100MB ele usava 2GB de RAM. Mas aparentemente, isso foi arrumado recentemente.
• GIT – extremamente poderoso, rápido e eficiente.Em contra-partida, ele tem milhares de comandos, sub-comandos, parâmetros e opções. Se você aprender tudo com ele, ele é o melhor. Entretanto, eu vivo me perdendo na hora de fazer coisas mais complexas (tipo, fazer um cherry-pick de um repositório remoto em um branch diferente). Por outro lado, só ele que permite fazer cherry-pick de forma fácil (para quem está por fora – cherry-pick permite você pegar um commit independente e embutir ele em outro branch. Se isso não fez sentido para você, provavelmente você não precisa dele ). A melhor coisa do GIT para mim é o suporte dele para multiplos branches locais, no mesmo diretório. E a velocidade, é claro. Porém, a complexidade dele acaba complicando demais a vida as vezes.
• Mercurial – parecido com o BZR e GIT. Atualmente suporta branches e cherry-picks também (de forma diferente). Ele suporta queues de patches também nativamente – mas, como nunca precisei disso, não posso falar muito detalhes. Fora isso, nunca cheguei a mexer muito com ele (mas, para quem tiver interesse, tem um tutorial interessante aqui). A escolha entre ele, bzr e git muitas vezes é questão de religião mesmo .
• DARCS – bastante interessante, e diferente de todos os outros sistemas. Basicamente, todo o mecanismo de commits e diferenças entre versões dele é baseado em filas de patches, aplicados em determinada ordem. A filosofia dele também é parecida com GIT – ele visa manter controle do conteúdo, e não da estrutura de versões. Isso tem lados bons (o mesmo conteúdo pode migrar de um lugar para outro – arquivo, diretório, etc) e ruins (se alguém fez essa migração, você não vai ter controle exato sobre o que foi feito).
• GNU ARCH – acredito que hoje em dia ele tem mais interesse histórico de que prático. Muito mais complexo de usar (se bem que, comparando com GIT, acho que dá uma briga boa). As ideias dele são utilizadas em outros sistemas de controle de versões distribuídas, mas ele em si – pelo que eu sei – está parado. Eu cheguei a usar ele faz alguns anos, mas desisti logo devido à complexidade dele.
• MONOTONE – também em desuso nos últimos tempos, o MONOTONE serviu como inspiração para GIT. Fora isso, nunca vi ninguém usar ele, então não tenho opinião formada sobre ele.

Além disso, tem diversas outras soluções caseiras (com svn, cvs (eca..), etc) que fazem a mesma coisa que DRCS’es usando algumas gambiarras (hehehe). Mas eu fico entre BZR e GIT na maioria dos casos.