Starting with kernel, many notable changes happened in the past weeks. To make our -next merge window process go faster, a new process was adopted for the kernel patch and branch handling process. Let me elaborate a bit more about how this is going to work.

For the past months, we had the drm-intel-next branch (containing patches intended to go into the next merge window – e.g., when the 3.3 kernel is being developed, this is the branch which contains patches intended to be included in the 3.4 kernel version), and also drm-intel-fixes branch (containing patches for the currently developed kernel – e.g., patches which fix issues which were added during the past merge window. So for instance, those are the patches which go into 3.3-rcN kernel versions after the merge window). Both of those patches were maintained by Keith Packard.

However, the amount of patches combined with other tasks resulted in a somewhat slower patch queuing process. So Daniel Vetter has volunteered himself to maintain the drm-intel-next branch from now on, reviewing, queuing and managing the patches intended to get into the next kernel merge window (for now, those are targeting the 3.4 kernel version).

At the same time, Keith Packard will continue to maintain the drm-intel-fixes branch, managing and carrying stability patches for the current kernel.

And finally, to improve the testing and availability of newer features for older kernel versions, I’ve started my own drm-intel-backports set of branches, for 3.0, 3.1 and 3.2 kernel versions – containing all the latest and greatest patches from the latest kernel releases. Of course, those patches do not follow the usual kernel stable development model, so they introduce new features, capabilities and possible issues. But for the brave souls out there willing to see and test the absolutely latest development in our drivers on top of their kernels, it should be a great chance to do so.

(I assume that I was not that fast with the drm-intel-backports patch merging process in the past 2 weeks, so for now it only contains patches from the 3.2 kernel branch. I intend to backport the 3.3 and 3.4-next patches for all those versions in the coming days. Also, apparently those backported patches do not work correctly with pre-Ironlake chipsets on 3.0 kernel, and there are some display-related issues on top of 3.1 one – I’ll look into it as well. Sorry for the delay – but the real life interfered with my patching capability for the past weeks…)

Besides those changes, we had a large number of notable kernel advances in the past weeks:

• One of the most interesting features is the support for interlaced modes in the Intel Linux Graphics cards. A great work by Peter Ross, Daniel Vetter and Paulo Zanoni resulted in a series of patches which provided support for interlaced modes. These patches will be queued for inclusion in the 3.4 kernel – but when I’ll get back to my -backports series of patches, I’ll certainly include them into the 3.[012] series as well.
• More Ivy bridge 3-display pipes issues were fixed, such as the hibernation problem with 3rd pipe being active.
• Stabilizing the almost-ready-to-launch Ivy bridge platform, the hopefully final forcewake-related fixes were included in both drm-intel-next and drm-intel-fixes branches, and were also cherry-picked by Greg to be included in the stable 3.2 kernel as well. This should solve the remaining missing interrupts problems we were experiencing.
• Initial patches to support the hardware context switching were sent by Ben Widawsky, and are accessible in his own freedesktop.org repository for testing. Hardware-supported context switching allows to save the hardware registers and state for each process, so it could essentially help the GL_EXT_transform_feedback extension and advanced geometry shading state passing between different stages. And, of course, it can also improve the stability – hardware would ensure that different processes would not interfere with each other in a harmful way.
• And almost a hundred pending patches were picked by Daniel Vetter for his new drm-intel-next branch. The next merge window certainly looks interesting for the Intel Linux Graphics support in this sense…

On Mesa side, the 8.0 release is getting really close. After the 8.0-rc1 release a couple of weeks ago, lots of patches were picked into the 8.0 branch, improving the stability, performance, and fixing many rendering issues – especially on the Ivy Bridge platform. More excitingly, the communication between Mesa and Unigine developers resulted in better support for open-source drivers in the just released Oil Rush game. It is really great to see such cooperation – and Unigine-based game certainly is one of the most advanced graphical releases of past years on Linux.

Speaking about the Mesa development, this final stabilization phase prior to the 8.0 release is a great chance for you to report issues, bugs and problems before the release which is expected in a few days from now. So if you observe any last-minute problems and regressions with Mesa 8.0 branch – please, let us know! This next release looks really impressive from the technical side, but your help in additional testing is more than welcome.

On Wayland side, lots of different patches and features were received in the past weeks. Wayland and Weston development goes on with great pace – and the ones of you to attend FOSDEM next week will have some really interesting stuff to gaze upon. But I won’t spoil the surprise .

On Xserver development, the 1.12 RC2 and 1.11.4 releases were unleashed last week, together with a new glproto, util-macros and xkeyboard-config versions. The development continues non-stop, with hundreds of patches and discussions happening in the mailing lists.

And finally, the phoronix feedback I got from you over the past weeks was amazing. Thank you all for all your questions and suggestions – it was really nice to hear what you have in mind, what you like (and dislike) in our drivers and what direction we should be heading. I’ll try to answer the last remaining questions in the next few day, and will summarize everything on a dedicated blog post.

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.

It took me longer than I originally expected to write this next post in the series due to some personal problems which kept me out of the virtual world for quite some time, but better late then never.

So, starting with Kernel, as usual, we had lots of updates.

• Jesse Barnes sent out his patches for adding DRM planes and support for a new FB creation ioctl. Planes are similar to half-CRTCs, in the sense that they have a location and fb, but don’t drive outputs directly. His patchset provided two new interfaces: addfb2, a new FB creation ioctl that lets specify a surface format, as defined by a fourcc code from the video4linux headers; and ** planes – ioctls for fetching plane info and attaching an fb to a plane.
• Jesse has also proposed some patches for enabling video sprites via overlays.
• Keith Packard has prepared some patches for flicker-free boot, which attempts to avoid the initial modesetting in drm.
• A very interesting set of patches from Ben which attempt at adding fairness to GPU scheduling, preventing greedy apps from over-dominating the GPU and leaving nothing for other apps. This, of course, is still experimental, but think about this like on what CFS scheduler did to Linux Process Scheduling, and CFQ did to I/O scheduling. Of course, this also raises some concerns, like for example what should happen to benchmarks – which expect to grab all the possible power to get some measurable numbers, but nothing unsolvable here. It would be really interesting to see how it will go.
• Ben has also sent out some patches which attempt to fix recursive unmapping of pages, a side effect of the Ironlake workaround which was done recently.

For Mesa, lots of activities on all fronts too. I won’t be able to cover all of them, but the main highlights of the past days were:

• Work on EXT_transform_feedback by Dan McCabe and Paul Berry from Intel and Marek Olsak. The piglit tests are already in place for some months (I actually started to work on some of them, but then Marek has published his own set of tests, and I left mine in a half-finished state for now at my freedesktop.org personal repo. But I think I’ll finish them at some point). The mesa support for this GL 3.0 extension is approaching its completeness fairly quickly.
• A 33-patch series from Eric Anholt with lots of fixes for batch buffer handling within mesa.
• Lots of different fixes and consistency improvements for Gen6 and Gen7 generations of cards from Ken were also unleashed into the wild.
• A HUGE cleanup of the remaining DRI1 pieces, such as the radeon drivers, dri1-specific extensions and core mesa bits, was carried out by Kristian Høgsberg, Eric and many others who participated in the discussion.
• GLSL and extensions-related work continues, with clean-ups, fixes and improvements from Ian, Ken, Paul Berry and Chad.
• GL_ARB_texture_storage support was brought in by Brian Paul from VMware. It is supported by gallium drivers and swrast for now.
• Chad Versace sent more patches for the Stencil buffer and HiZ support.
• Ian sent out a 20-patch series which completely refactors the handling of uniforms within Mesa.
• Eric has sent 24-patch series for improved renderbuffer mapping (MapRenderbuffer).
• Paul Berry has added support for GLSL 1.30 interpolation qualifiers for Gen6+. This allows to keep track of which fragment shader inputs are overridden with the GLSL “flat”, “smooth”, “perspective” and “noperspective” interpolation qualifiers.
• And Chia-I Wu has sent some new patches for an updated version of glext.h and for improved android-x86 support within core Mesa.

On Wayland land, we also had quite some interesting changes:

• Tiago Vignatti sent several patches for improving input and evdev handling.
• Juan Zhao has put out some documentation about Wayland building.
• Ander, me, Benjamin Franzke, Casey Dahlin, Pekka Paalanen and Juan Zhao has also sent some build, correctness and GL-related patches. In overall, Wayland development is moving on nicely.

Moving to VAAPI, as I already wrote here, Gwenole has released a new version of both libva and vaapi-driver-intel. Also, speaking on new releases, Eric Anholt has also released libdrm 2.4.27, we had the release of xorg-server 1.11.2 RC2, a new pixman 0.23.8 release, which happens to be a release candidate for the stable 0.24 release, and Chris Wilson has put out xf86-video-intel 2.17 RC1, with several fixes and amazing list of 200+ SNA-related patches.

Also on SNA, I’ve put out two patches which would allow to activate SNA by means of a config file option, without recompiling. Those patches patches are floating around the intel-gfx mailing list, and make the task of SNA testing amazingly more easy (at least, for me ).

So – I guess I’ll stop here for now.

See you in the next iteration of The Tales from the Crypt Intel Linux Graphics land .

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

Hi, I'm Mac.

So, after using a Linux-based OS exclusively for my Desktop for the past 10 years or so (except the time at Microsoft where I was using a pre-released version of Vista during the work hours), I finally was able to get a hold of a MacBook Air. One thing I can say that most of the mac advertizements are true – the hardware really looks amazing and “cool”. As for the software, well, let’s go step-by-step in this evaluation.

The fest thesis I want to emphasize is that the fundamental change between the Mac and Linux Desktop approaches is that Mac does everything to force you to understand and bend to the system default settings and the way it works, and Linux is completely aimed at making the system easy to customize and adapt to you. In other words, Mac forces you to adapt to the system, and Linux focuses on making system easily adaptable to what you want. This ranges from each and every level of the system configuration, starting with the UI, standardization of the used applications, the standardized menu, dock, and so on. On Mac, it is done this way, and you should not even think on changing it – it just works and the only solution for you is to get used to it.

On Linux, the things are quite opposite on all stages. Each and every part of the system can be customized, adapted, modified; there is no single point of complete integration between applications, settings and features. It is quite common to have a Linux system with systemd+kde+pidgin+openoffice, where each application has its programming framework, UI, look-and-feel, and functionality. And by no means it makes this system a second-class citizen when comparing to a upstart+gnome+emphaty+libreoffice one. This is the biggest advantage (and, for some, disadvantage) of Linux-based approaches – the large choice without One True Way of doing things.

This also brings me back to the eternal flame was which says that “the Mac is the Best Desktop Experience out there”, which I personally cannot agree with. Yes, Mac has its own experience, but the largest drawback is that is the only experience you could get out of it. By the contrary, on Linux there are thousands ways of how one could create, customize and run his Desktop. Somebody feels comfortable with pure KDE experience, someone would feel much more natural with a GNOME desktop. Many productivity-oriented Linux desktops are running dwm, icewm, ratpoison, wm3, evilwm and many many other desktop environments with multitude of apparently incompatible applications and do not miss any of their larger cousins (like kde, gnome or xfce) features.

So to summarize it all, one big advantage of a Mac-based experience is that the entire desktop feels like an appliance. To illustrate, consider any cellphone OS, or any TV or a videogame – the things “just work”, and you have no choice nor need to modify the way they work and just go on with using them. This is certainly a huge plus for casual users who just need to use their devices to get things done – it is very hard to get confused about what to do with the system, and in most applications all keyboard shortcuts, UI, menus, appearance and so on is standardized. In other words, you don’t learn how to use a Mac or Android or Symbian, you just use it, and there is only one correct way to get something done.

The advantage of a Linux-based desktops is their absolute – and even exaggerated sometimes – flexibility. They are completely focused on making the desktop experience bendable towards what you need, at a cost of much higher entry level and necessary learning about all the puzzles which compose it. It is certainly not focused on casual users (and, in my personal opinion, it should not be), and it is more of an elitist system – only the ones willing to learn, customize and adapt the system will be able to get the most out of it. But the ones who manage to get through this exhaustive task will be truly rewarded with a system where you know exactly what each and every piece, process or file are responsible for.

In other words, Mac is an appliance, and Linux is a constructor. Mac just works (not necessarily the way you expect), and Linux gives you the possibility to make it work the way you want (at a cost of a high learning and customization curve).

So in my personal opinion, it is pointless comparing a Mac experience to a Linux Desktop one. If Mac should be compared to anything, it is to other appliance-like environments, like cellphones and similar devices for example; or to end-to-end solutions based on any OS which has the similar goals in mind (like meego, android, winphone, windows, symbian, ubuntu – and now mandriva, which has invested a lot of time of ROSA Labs designers and developers to introduced a new UI experience for the 2011 release). In such cases, the user does not cares – nor should he – about what the system is based upon – a darwin os, a win kernel, a linux or any other low-level operating system. What use gets is the overall default UI which just works, and he should adapt to.

Hi, I am PC^WMandriva 2011 (this shot was shamelessly borrowed from softpedia because it really looks awesome!)

At the end, summarizing and concluding this long text, I can say now that it is more clear for me now where the ROSA Labs designers and developers are getting their inspiration from. Personally, for me, the Rosa Panel (included by default in Mandriva 2011) feels more natural and easy to use than its Mac equivalent and more flexible and tunable than its Windows counterpart. The same way, the ROSA Launcher application feels more powerful than Mac’s finder+dockbar combination, and much more flexible and friendly than Windows 7 start menu. This, at least for me, only complements my opinion that Linux is a constructor – you can build anything from the tools and pieces it has, take the best ideas out there and use them as inspiration, and result in something new. This is specially true to the geeks (like me) who do not like some of the design choices taken by ROSA – so we can just go ahead and make the system the way we want, taking the best from the both worlds.

Hi, I'm a bit customized Mandriva 2011 - and the limit to my customization is only your imagination

And, of course, having the power of Linux constructor, you can certainly adapt the system towards your needs, remove or change things you don’t want, and add what you find missing.

That’s it .

P.S.: Please, consider everything said here as my own personal opinion. By no means it represents the official Mandriva or ROSA view on the matter. This is what I think.

P.P.S.: Some extremely interesting discussion and feedbacks in the comments, be sure to check them out. Thanks for all this feedback!

In other words, I was missing some small, simple – but efficient and, of course, open-sourced class control application.

So in the past week, I took some hours of my free time to gather some of the my scratches and ideas, and put them all together into a simple class control application.

Why the heck the would would need yet another class control solution? In my case, and probably in most geek’s, the answer is simple: just for fun.

So – this is how OpenClass was born.

Have fun .

10 Awesome Ads (For Traumatizing Children) | Cracked.com.

World Builder from Bruce Branit on Vimeo.

Autenticação por pam_blue rules! Para que usar tokens? Celular é o que há . http://tinyurl.com/dc8nvb #

Powered by Twitter Tools.

Autenticação por pam_blue rules! Para que usar tokens? Celular é o que há . http://tinyurl.com/dc8nvb #

Powered by Twitter Tools.

Isso sim é promoção! Petra Bock, no extra São Carlos, foi de R$ 12 para R$ 1.99! Para ficar melhor é só poder comprar com visa vale! #

Powered by Twitter Tools.

Isso sim é promoção! Petra Bock, no extra São Carlos, foi de R$ 12 para R$ 1.99! Para ficar melhor é só poder comprar com visa vale! #

Powered by Twitter Tools.

Powered by Twitter Tools.

por algum motivo a integração twitter/blog quebrou de vez esses dias… #

Powered by Twitter Tools.

Automatically shipped by LoudTwitter

Powered by Twitter Tools.

09:46 @olavojunior, querer eu quero faz tempo, o problema é $$$. Depois de andar num Land Rover, a minha vida nunca mais foi a mesma hehehe. #

18:59 Estava em Salvador a exatamente 1 ano atrás… e exatamente 2 anos atrás estava nos EUA. E hoje estou trabalhando. hehehe. É a vida . #

Automatically shipped by LoudTwitter

11:00 @Capitulino, @coxande, i686. I just installed default packages for both Mandriva and Arch. I’m looking on what’s wrong with it right now . #

17:44 @Capitulino, daqui a 1 mes tem Iron em SP! Esse é mais light . #

21:32 @olavojunior eu tentei fazer trilha (sem querer ) com o meu megane nesse fim da semana. Meu deus… como eu queria um jipe . hehehe. #

Automatically shipped by LoudTwitter

08:41 @fabiocpn xulrunner nada, compila o openoffice para você ver #

22:45 @Capitulino, eu estou remoto de qualquer jeito.. No pior caso, código com àlcool no sangue sai até mais bonito! Principalmente em perl #

Automatically shipped by LoudTwitter

23:48 Updated flickr with nice Ituverava photos. Powered by N95. And a bit of gimp+hugin . tinyurl.com/c32tvv #

Automatically shipped by LoudTwitter

09:04 World of Goo nativo para Linux!! Mais um software comprado . #

Automatically shipped by LoudTwitter

00:25 @mvkampen tá tudo feito (maldito enter que cortou mensagem no meio!) #

11:03 @olavojunior Death Magnetic é o melhor CD deles da última década-e-pouco! #

Automatically shipped by LoudTwitter

22:41 Just watched Transporter 3. Another great french movie. Well.. mostly . #

23:58 2.6.28.5… maaaaais um update.. que saudades do 2.4… #

00:25 @mvkampen tá tudo feito (maldito enter que cortou mensagem no meio!) #

Automatically shipped by LoudTwitter