(of course, if you have attended and want to see it again, you can do this too ).

Have fun!

Intel Linux Graphics

I tried to summarize all the patches and changes which went to this kernel release which somehow affected the drivers/gpu/drm/i915 directory (and, therefore, the kernel part of our driver).

To give proper credit to all the authors whose code was accepted into the official kernel between the 3.0.0 and 3.1 release, here is the full list:

• Adam Jackson: drm/i915/dp: Better hexdump of DPCD
• Adam Jackson: drm/i915/dp: Don’t turn CPT DP ports on too early
• Adam Jackson: drm/i915/dp: Explicitly disable symbol scrambling while training
• Adam Jackson: drm/i915/dp: Explicitly request 8/10 channel coding
• Adam Jackson: drm/i915/dp: Move DPCD dump to common code instead of PCH-only
• Adam Jackson: drm/i915/dp: Read more DPCD registers on connection probe
• Adam Jackson: drm/i915/dp: Retry DPCD fetch on G4X too
• Adam Jackson: drm/i915/dp: Zero the DPCD data before connection probe
• Adam Jackson: drm/i915/pch: Fix integer math bugs in panel fitting
• Adam Jackson: drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend
• Ben Widawsky: drm/i915: add module parameter compiler hints
• Ben Widawsky: drm/i915: hangcheck disable parameter
• Ben Widawsky: drm/i915: provide module parameter description
• Chris Wilson: drm/i915: Add an interface to dynamically change the cache level
• Chris Wilson: drm/i915/bios: Avoid temporary allocation whilst searching for downclock
• Chris Wilson: drm/i915: Cache GT fifo count for SandyBridge
• Chris Wilson: drm/i915: Combine pinning with setting to the display plane
• Chris Wilson: drm/i915: Disable FBC across page-flipping
• Chris Wilson: drm/i915/gtt: Split out i915_gem_gtt_rebind_object()
• Chris Wilson: drm/i915: Introduce i915_gem_object_finish_gpu()
• Chris Wilson: drm/i915: Introduce i915_gem_object_finish_gtt()
• Chris Wilson: drm/i915: Mark the cursor and the overlay as being part of the display planes
• Chris Wilson: drm/i915: Only export the generic intel_disable_fbc() interface
• Chris Wilson: drm/i915: Perform intel_enable_fbc() from a delayed task
• Chris Wilson: drm/i915: Remove vestigial pitch from post-gen2 FBC control routines
• Chris Wilson: drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()
• Chris Wilson: drm/i915: Set persistent-mode for ILK/SNB framebuffer compression
• Chris Wilson: drm/i915: Share the common work of disabling active FBC before updating
• Chris Wilson: drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writes
• Dave Airlie: Revert “drm/i915: Try enabling RC6 by default (again)”
• Eric Anholt: drm/i915: Use the LLC mode on gen6 for everything but display.
• Eric Anholt: drm/i915: Use the uncached domain for the display planes
• Hugh Dickins: drm/i915: more struct_mutex locking
• Jesse Barnes: drm/i915: add GPU max frequency control file
• Jesse Barnes: drm/i915: allow cache sharing policy control
• Jesse Barnes: drm/i915: apply phase pointer override on SNB+ too
• Jesse Barnes: drm/i915: apply timing generator bug workaround on CPT and PPT
• Jesse Barnes: drm/i915: check for supported depth at fb init time
• Jesse Barnes: drm/i915: don’t set SDVO color range on ILK+
• Jesse Barnes: drm/i915: don’t set transcoder bpc on CougarPoint
• Jesse Barnes: drm/i915: don’t use uninitialized EDID bpc values when picking pipe bpp
• Jesse Barnes: drm/i915/dp: wait for previous AUX channel activity to clear
• Jesse Barnes: drm/i915: enable ring freq scaling, RC6 and graphics turbo on Ivy Bridge v3
• Jesse Barnes: drm/i915: fix CB tuning check for ILK+
• Jesse Barnes: drm/i915: flush plane control changes on ILK+ as well
• Jesse Barnes: drm/i915/hdmi: HDMI source product description infoframe support
• Jesse Barnes: drm/i915/hdmi: send AVI info frames on ILK+ as well
• Jesse Barnes: drm/i915/hdmi: split infoframe setting from infoframe type code
• Jesse Barnes: drm/i915: load a ring frequency scaling table v3
• Jesse Barnes: drm/i915: load the LUT before pipe enable on ILK+
• Jesse Barnes: drm/i915: provide more error output when mode sets fail
• Jesse Barnes: drm/i915: provide more error output when mode sets fail
• Jesse Barnes: drm/i915: set bpc for DP transcoder
• Jesse Barnes: drm/i915: set GFX_MODE to pre-Ivybridge default value even on Ivybridge
• Jesse Barnes: drm/i915: show interrupt info on IVB
• Jesse Barnes: drm/i915: split out Ironlake pipe bpp picking code
• Jesse Barnes: drm/i915: split out PCH refclk update code
• Jesse Barnes: drm/i915: split out plane update code
• Jesse Barnes: drm/i915: use pipe bpp in DP link bandwidth calculation
• Jesse Barnes: drm/i915: use pipe bpp in DP link bandwidth calculations
• Jesse Barnes: drm/i915: use pipe bpp when setting HDMI bpc
• Kamal Mostafa: i915: do not setup intel_backlight twice
• Keith Packard: drm/i915: Call intel_enable_plane from i9xx_crtc_mode_set (again)
• Keith Packard: drm/i915: Cannot set clock gating under UMS
• Keith Packard: drm/i915: Can’t do accurate vblank timestamps with UMS
• Keith Packard: drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
• Keith Packard: drm/i915: Enable dither whenever display bpc < frame buffer bpc
• Keith Packard: drm/i915: Enable i915 frame buffer compression by default
• Keith Packard: drm/i915: FBC off for ironlake and older, otherwise on by default
• Keith Packard: drm/i915: Fix PCH port pipe select in CPT disable paths
• Keith Packard: drm/i915: Fixup for ‘Hold mode_config->mutex during hotplug’
• Keith Packard: drm/i915: Flush other plane register writes
• Keith Packard: drm/i915: Hold mode_config->mutex during hotplug processing
• Keith Packard: drm/i915: i915_gem_object_finish_gtt must always release gtt mmap
• Keith Packard: drm/i915: Ignore GPU wedged errors while pinning scanout buffers
• Keith Packard: drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd
• Keith Packard: drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri
• Keith Packard: drm/i915: Leave LVDS registers unlocked
• Keith Packard: drm/i915: Remove unused ‘reg’ argument to dp_pipe_enabled
• Keith Packard: drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd
• Keith Packard: drm/i915: Select correct pipe during TV detect
• Keith Packard: drm/i915: Set crtc DPMS mode to ON in intel_crtc_mode_set
• Keith Packard: drm/i915: Skip GPU wait for scanout pin while wedged
• Keith Packard: drm/i915: Try enabling RC6 by default (again)
• Keith Packard: drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
• Keith Packard: drm/i915: Use dp_detect_common in hotplug helper function
• Keith Packard: drm/i915: Wait for LVDS panel power sequence
• Keith Packard: Revert and fix “drm/i915/dp: remove DPMS mode tracking from DP”
• Keith Packard: Revert “drm/i915/dp: Zero the DPCD data before connection probe”
• Matthew Garrett: i915: Fix opregion notifications
• Matthew Garrett: Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support.
• Michel Alexandre Salim: drm/i915: Add quirk to disable SSC on Sony Vaio Y2
• Pieterjan Camerlynck: i915: add Dell OptiPlex FX170 to intel_no_lvds
• Simon Farnsworth: drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
• Thomas Jarosch: drm/i915: Fix wrong initializer for “locked” variable in assert_panel_unlocked

If we count the final number of changes between the 3.0 and 3.1 versions, we come to the following results:

drivers/gpu/drm/i915/i915_debugfs.c     |  232 +++++++-
drivers/gpu/drm/i915/i915_dma.c         |   10 +-
drivers/gpu/drm/i915/i915_drv.c         |   69 ++-
drivers/gpu/drm/i915/i915_drv.h         |   51 +-
drivers/gpu/drm/i915/i915_gem.c         |  193 +++++-
drivers/gpu/drm/i915/i915_gem_gtt.c     |   39 +-
drivers/gpu/drm/i915/i915_irq.c         |   22 +-
drivers/gpu/drm/i915/i915_reg.h         |   59 ++-
drivers/gpu/drm/i915/i915_suspend.c     |   13 +-
drivers/gpu/drm/i915/intel_bios.c       |  140 +++--
drivers/gpu/drm/i915/intel_display.c    | 1028 +++++++++++++++++++++++--------
drivers/gpu/drm/i915/intel_dp.c         |  135 +++--
drivers/gpu/drm/i915/intel_drv.h        |   38 +-
drivers/gpu/drm/i915/intel_hdmi.c       |  166 +++++-
drivers/gpu/drm/i915/intel_lvds.c       |   90 ++--
drivers/gpu/drm/i915/intel_opregion.c   |   16 +-
drivers/gpu/drm/i915/intel_overlay.c    |    6 +-
drivers/gpu/drm/i915/intel_panel.c      |   76 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c |   13 +-
drivers/gpu/drm/i915/intel_sdvo.c       |   88 +--
drivers/gpu/drm/i915/intel_tv.c         |   46 +-
21 files changed, 1879 insertions(+), 651 deletions(-)

So, in sum, there are changes all around the driver. Among the most interesting ones (in my humble opinion), are:

• Frame Buffer Compression is now enabled for Gen6 onwards (in other words, starting with Sandy Bridge). Of course, you can always enable it manually on your machine as well by using the i915.i915_enable_fbc=1 kernel parameter.
• FBC should work better in general, thanks to patches from Chris Wilson which disable it across page-flipping and before updating, persist framebuffer compression mode for Ironlake and Sandy Bridge, and also making a proper use of fences after CPU writes.
• RC6 was attempted to be enabled, but it was reverted early in the development cycle. As we had unusual time frame for this kernel release, by the time we have hit RC8, all the remaining RC6-related issues were tracked down. But as it was already too late for kernel 3.1, its enablement by default should happen in kernel 3.2. The usage of RC6 brings amazing power usage benefits, so you can enable it by yourself via the i915.i915_enable_rc6=1 kernel parameter – and letting us know about any non-covered issues it may bring.
• DCPD, or Display Port Configuration Data handling has received lots of attention, and in general one should have a much better support for Display Port outputs.
• configuration parameters for changing the cache level, maximum GPU frequency, cache sharing policy and GPU ring frequency scaling.
• additional debugging output when mode setting fails, information about interrupts on Ivy bridge, hangcheck disabling support and better DPCD hexdump.
• improvements for HDMI support, SDVO and LVDS handling, better pipe handling of EDID bpc values and proper panel fitting calculationsl
• usage of LLC mode (usage of CPU cache for GPU instructions) for Gen6. This one-lined (excluding comments ) change alone was responsible for about 20% performance improvements for openarena in full-screen mode, and about 12% improvements in nexuiz.

The i915 driver in kernel 3.1 received a total of 95 new patches when compared to 3.0 (excluding merges), coming from 14 different authors – both working at Intel and not. Now the road is open for 3.2. So fasten your seat belts and prepare for the next ride .

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

As most of you who are following either my twitter or facebook has already noticed, I am working at Intel now, within the Intel Linux Graphics group. However, this does not means that I have abandoned the Mandriva/Mageia communities! The move to other city, job, relocation, and other boring and time-consuming things took most of my time for the past weeks, but slowly everything is getting back into shape now.

Quoting Andrzej Sapkowski, one of my favorite authors, “something ends, something begins”. I am at the beginning of this new journey, and really looking forward for this new experience!

See you around .

so, today is my last week at Mandriva/Conectiva! I think I said everything I had to say about this experience I had here in my previous posts, and I’d like to thank you a lot for all your kind words and feedback. So, as a parting gift for you, I prepared one small open-source tribute to the communities, users and developers out there.

As you all know, Mandriva (and now, Mageia as well) has its own set of tools and applications, some of which were developed solely – or mostly – by me for the past few years. Whenever possible, I was trying since the beginning to develop such tools and applications in a distribution-agnostic way, and I think I managed to do it fairly well (well, I tried ). Nothing in any of them depends specifically on Mandriva or Mageia, and not even on rpm infrastructure itself – and when it does, it is split into a separate plugin or customizable option.

However, as their customization and development outside of Mandriva/Mageia distributions is a bit hard due to the subversion repository access and availability, it certainly made them a bit non-inviting to new contributions (IMHO). So I decided to update those applications a bit in the past few days, and also made them available at my github site. I think that now, as we have both Mandriva and Mageia (at least) using some of the tools which share common code, it would be only fair to convert those projects into upstream ones, instead of making them incompatible forks of each other.

They are fully synchronized with Mandriva’s svn repository, but not with Mageia patches yet (however, this is easy to be done considering git flexibility, I just lacked time and bandwidth to do so). So yes, I’ll be still maintaining and developing them for the foreseeable future, but – as always – everyone is free to contribute, adapt and use them in the way you think the best.

So, without further words, those are my preciousssss toys:

• msec – Multi-Security Tool (a.k.a. Mandriva Security Tool and Mageia Security Tool), probably the one of the most hated (yet useful ) tools in Mandriva history. It is responsible for defining security on your machine, controlling file permissions, running periodic security checks, and so on. There are plenty of posts in this blog about its evolution for the past years as well. It was fully redesigned for Mandriva 2009.1 originally, and after that it gained a new UI, support for plugins, checks with customizable periodicity and arbitrary user-defined security levels. It does not depends on Mandriva/Mageia infrastructure for about 95% of its features, and the remaining 5% are controlled via plugins and configuration parameters.

• netprofile – Network profile tool. It allows you to define multiple network profiles, each with its own network, proxy, urpmi, firewall and other settings, and easily switch among them. Its UI is provided by drakx-net package (available only in Mandriva/Mageia), but the core functionality is distribution-independent. And at least I use it only in console, so it does not matters much for me .

• net_monitor – Network monitor. A simple network monitor which, besides network traffic accounting, also allows you to monitor the wireless signal level, used ports statistics, and integrates itself into network scripts via ifup/ifdown-based plugins. It also works with vnstat for nice usage statistics and reports generations. I also started to write a plasma backend for it, but never managed to finish it. Yet.

• Tomoyo GUI – Graphical Tomoyo configuration tool. Probably the first (and as far as I know, still the only one out there) graphical configuration utility for Tomoyo Security framework. It should work with both ccs-tools and tomoyo-tools, and supports automatic security profile generation, application behavior learning, profiles exporting/importing, and so on.

• s2u – Services 2 User, a small Mandriva tool used to share system messages with user desktop sessions via dbus. It is used by drakx-net infrastructure to notify user sessions when host name changes (thus assuring that the desktop continues working with new hostname), by msec to provide desktop notifications for security events, and by netprofile to provide desktop notifications on profile changes. It is a small tool, but as some of the aforementioned apps rely on it, it deserved its place on github as well.

There are many other Mandriva/Mageia-specific utilities, such as ldetect, mandi, drakx and its friends, drakguard, among many many many others. But they are very Mandriva/Mageia specific tools, and I don’t believe that their usage could be used outside of the scope of those distributions. But as for the aforementioned ones, I think that they could be very useful for other distributions as well.

Of course, besides me, all of those tools has received numerous contributions from old Mandriva/Mandrake/Conectiva developers, community members, translators and users. And I could not thank them more than by making their efforts available for the next generations of open-source users and communities!

So have fun and may the source be with you!

This topic arises frequently in all the corners of the world – how to remove even the smallest presence of pulseaudio and systemd from the system. Most Linux-aware people already know that, at least in most modern Linux distribution, there is no need to remove them at all – at least on Mandriva/Mageia-based distributions, both pulseaudio and systemd can be disabled entirely with a click of a mouse (inside draksound, or via ln -sf /etc/sound/profiles/alsa /etc/sound/profiles/current), or with a package removal/replacement (urpmi sysvinit) – but still, I frequently have the chance to met people who are offended by mere presence of said packages and files bearing the smallest similarity to the terms ‘pulse’, ‘audio’, and ‘systemd’ in their list of installed packages in files.

I have to say that I never had any problems with either pulseaudio or systemd for the past years, and I personally consider them as probably one of the most useful items in current generation of Linux distributions – they use most of computer features to provide many different multimedia aspects which otherwise are almost impossible to achieve without hard and tedious scripting and hacking (in case of pulseaudio); and they finally provide a powerful, modern and extremely efficient boot mechanism for Linux distributions (systemd). But.. each one has its own opinion, so who am I to speak for everyone?

So this motivated me to write this post – I’d like to specially thank the people from probably the best Russian open-source-oriented site – opennet.ru – for asking me for doing it. I decided to write it in English however, for 2 reasons:

1. Those questions arise in each and every language out there, and English is the lingua franca of todays world; and

2. I write much faster (and probably better ) in English than I do in Russian, specially when it comes to technical items and descriptions .

So let’s begin. I’ll split this tutorial in 3 big sections – how to find all the traces of pulseaudio and systemd in your system; how to exorcise all the traces of pulseaudio and systemd from all the found packages; and how to make a holy crusade to deliver those packages for the world (we all leave in open-source community after all) .

So..

PART I – how to find all the packages which rely on pulseaudio and systemd?

In Mandriva/Mageia and other rpm/urpmi-based systems, a very handy command is urpmf, which allows to search in the repositories for provides, conflicts, files, and so on. In our case, let’s start with pulseaudio, which is considered by The Root Of All Evil on Linux, Unix, and in All The World Under The Sun by some people out there.

To locate all the packages which require pulseaudio stack, let’s search for the packages requiring ‘libpulse’ – this will match packages which require the libpulse.so itself, libpulse-simple.so, libpulse-mainloop-*, and so on. This magical command would be:

# urpmf --requires libpulse

which will output something similar to:

padevchooser:libpulse-browse.so.0()(64bit)
padevchooser:libpulse-mainloop-glib.so.0()(64bit)
padevchooser:libpulse.so.0()(64bit)
lib64alsa-plugins-pulseaudio:libpulse.so.0()(64bit)
lib64mediastreamer1:libpulse.so.0()(64bit)
mplayer:libpulse.so.0()(64bit)
libpulsezeroconf0:libFLAC.so.8
libpulsezeroconf0:libICE.so.6
libpulsezeroconf0:libSM.so.6
libpulsezeroconf0:libX11-xcb.so.1
libpulsezeroconf0:libX11.so.6
...

The output format is: package:requires – e.g., it says for example that mplayer package is requiring libpulse.so.0()(64bit). However, as you can see, it would also list pulseaudio own packages as well (namely, libpulsezeroconf0). So let’s do a different command with some filtering:

# urpmf --requires libpulse | awk -F: '/:libpulse/{print $1}' | sort -u

This will list all the packages available in the repositories which require libpulse pattern.

However, as it is usually the case, not everyone wanting to get rid of pulseaudio wants to remove it completely from the distribution. Most of the time, he just wants to have his small, cozy system to be Truely Free from Lennart’s evil applications (c). So in this case, the following command will compare the results of the previous urpmf command with the list of the installed packages, and print the names of the source rpm files of installed packages which need to be exorcised:

# rpm -q $(urpmf --requires libpulse | awk -F: '/:libpulse/{print $1}' |\
  sort -u) --qf '%{sourcerpm}\n' | grep -v 'not installed' | sort -u

This will pass the urpmf output to ‘rpm -q’ command, asking it to print the names of the source rpm files for each found package, skips the packages which are not installed, and sorts the output removing duplicates. In my case, the list became fairly small, containing only:

alsa-plugins-1.0.24-1.src.rpm
gstreamer0.10-plugins-good-0.10.30-2.src.rpm
kdebase4-runtime-4.6.5-6.src.rpm
kdemultimedia4-4.6.5-2.src.rpm
libcanberra-0.27-3.src.rpm
mplayer-1.0-1.rc4.0.r32713.6.src.rpm
paprefs-0.9.9-8.src.rpm
pavucontrol-0.9.10-8.src.rpm
phonon-4.5.0-4.src.rpm
pulseaudio-0.9.23-1.src.rpm
qemu-0.14.0-1.src.rpm

So, now we have the list of all packages which must be exorcised from the Pulseaudio evil influence! Let’s head for the Systemd-corrupted packages now.

In similar way to what we did to locate packages which need libpulse, let’s do a search for packages which have /lib/systemd files somewhere inside, with a simple:

# urpmf /lib/systemd

Once again, the list is quite bit – and it is a good thing, which means that most of the developers and packagers are adopting the systemd native units already! However, our goal is to remove the evil roots of systemd from such packages, so let’s find out which packages installed on our dear, sweet and comfortable system were possessed by the systemd spirit:

# rpm -q $(urpmf /lib/systemd | awk -F: '/:\/lib\/systemd\//{print $1}' \|
  | sort -u) --qf '%{sourcerpm}\n' | grep -v 'not installed' | sort -u

Once again, the list is quite small (for my machine):

abrt-1.1.14-11.src.rpm
acpid-2.0.10-1.src.rpm
alsa-utils-1.0.24.2-1.src.rpm
avahi-0.6.29-1.src.rpm
consolekit-0.4.5-1.src.rpm
cups-1.4.6-5.src.rpm
dbus-1.4.6-2.src.rpm
initscripts-9.25-5.src.rpm
libcanberra-0.27-3.src.rpm
lm_sensors-3.3.0-5.src.rpm
rsyslog-5.8.2-1.src.rpm
rtkit-0.10-1.src.rpm
smartmontools-5.41-1.src.rpm
systemd-29-3.src.rpm
udev-168-1.src.rpm

But nonetheless, it is quite complete.

So, now we found packages which were tainted by the evil hands of Lennart Poettering (all credits for this phrase belong to opennet.ru), so let’s strip them of this unspeakable evil in the next part!

PART II – exorcising evil beings from innocent packages

Now that we have the list of packages tainted by evil spirits of pulseaudio and systemd, the next step is to remove their dependencies on such entities to make the users who are unable to tame with such unbelievable requirements became happy and in piece with their inner voices!

This section requires a bit of patience and rpm editing skills, so if you lack them probably it will be a bit confusing. In this case, I suggest you to read some references on how to package rpm files (this and this are a nice place to start in case of Mandriva and Mageia distributions).

For the old-school hackers out there, who install src.rpm packages by hand, the initial packaging unpacking is trivial – download the said packages and run rpm -ivh *.src.rpm, and you are done. For the ones who got used to Mandriva/Mageia facilities provided by repsys or mgarepo, the following commands probably would come in handy:

1. First, we need to find out the name of the package repo – in case of abrt-1.1.14-11.src.rpm it is ‘abrt’, in case of udev-168-1.src.rpm it is ‘udev’, and I’ll let you figure out the remaining ones as an exercise .

2. Second, for each package, we should run repsys co PACKAGE (or mgarepo co PACKAGE).

3. After that, package with all its sources and specs will become available in PACKAGE directory. So just go there, install the package build requirements, and you are all set.

Now, let’s go to the package exorcism itself. First at all, you have to figure out IF the pulseaudio evil could be stripped from the package during the build process. If it is not possible, well, you have no other solution besides:

1. Writing your own clone of the package
2. Writing a patch to the package to not require pulseaudio anymore
3. Ask upstream developers to remove those functionality from their packages specially for you, out of good will and companionship spirit.

(Somehow I suspect that the 3rd alternative won’t be quite easy in some cases, but one never knows…).

Let’s take for example mplayer package, and use it as example of pulseaudio exorcism. Looking at mplayer.spec file, we cannot find anything which looks like disable this option to disable pulseaudio forever, which is, without any doubts, sad. However, if we take a closer look, there is a %define build_pulse 1 option which definitely looks a bit suspicious. If we change it to %define build_pulse 0, search deeper within the package for the build_pulse flag usage, and add a --disable-pulse option to the build, and rebuild the package with bm -l – then voila! It will build mplayer package without any reference to pulseaudio. Yes, we just had our first package liberated from pulseaudio evil!

In other words, simple patch the package with as follows:

Index: SPECS/mplayer.spec
===================================================================
--- SPECS/mplayer.spec  (revision 691091)
+++ SPECS/mplayer.spec  (working copy)
@@ -56,7 +56,7 @@
 %define build_alsa 1
 %define build_jack 1
 %define build_openal   0
-%define build_pulse    1
+%define build_pulse    0
 %define build_schroedinger 1
 %define build_twolame 0
 %define build_lame 0
@@ -206,6 +206,7 @@


 Name:      %{name}
+Epoch:     9999 # to prevent future upgrades
 Version:   %{version}
 Release:   %{release}%{?extrarelsuffix}
 Summary:   %{Summary}
@@ -630,6 +631,8 @@
 %endif
 %if %build_pulse
        --enable-pulse \
+%else
+   --disable-pulse \
 %endif
 %if !%build_openal
        --disable-openal \

We could check it with rpm -qp --requires RPMS/*/*rpm | grep pulse.

And one important thing comes into mind – how to prevent future upgrades from the distribution to remove all your hard work and changes? One extremely evil, painful and non-rollbackable solution would be to add something like:

Epoch: 9999

into each .spec file. This way, until the distribution reaches this number of package versioning resets, your own packages will take priority above anything distribution says (yes, I told that it would be an evil and extremely hackish solution) .

Now it is only necessary to repeat the same process with all other pulse-depending packages. Of course, for some of them (for example, qemu) it is not easy, because pulseaudio support is builtin. In this case, the following options apply – you could either write a patch to remove its support, or ask upstream to build a specific qemu package specially for you without pulseaudio support .

As for systemd, the similar strategy applies – with the difference that it would be easier to strip support for systemd in the packages. Just remove all the ‘/lib/systemd’ entries in .spec files, or prepend them with ‘%exclude’ tag, and the support for systemd in said packages will be gone.

In short, resuming this section, if you want to remove pulseaudio and systemd support from your packages, you have to exercise some coding and packaging skills. Unfortunately (for you), most of Linux distributions and environments believe that pulseaudio and systemd are cool and great technologies, so they provide them by default, and it is not very likely that you’ll have any distribution with such changes applied by default… So what could you do now?

The next part explains..

PART III – carrying on a anti-pulse-and-systemd crusade in 2 simple steps

If you want to have any distribution come out without systemd and pulseaudio, you basically have 2 choices.

1. Make a fork of a distribution, maintain it yourself, and add the packages without pulseaudio/systemd support there. This is the most suitable thing to do if you want to have your own distribution and become rich and famous . Alternatively, you have the solution 2. Yet more alternatively, there is always a way to start a brand new distribution yourself.

2. Create your own repository for packages liberated from pulseaudio and systemd evil influence. This is easier because you don’t need to do the entire distribution on your own, and usually a simple directory on a web-server or ftp would suffice. To follow this path, the following steps should be done:

   2.1. Copy all the resulting packages into a directory

   2.2. Run genhdlist2 directory

   2.3. Put the resulting directory on your http/ftp/rsync server for others to grab it.

This will prepare a Mandriva/Mageia-compatible repository, and when you put it onto a web or ftp server, just share its address with the world, and everyone will be able to add it by running:

# urpmi.addmedia diepulseandsystemd http://your.server.address/repository/$ARCH

This way, on the next urpmi --auto-update run, urpmi will discover that packages from such repo has absolutely higher priority over all possible packages provided by the distribution, and will install them automatically, replacing the currently installed and the available ones. With this, having all the packages freed from the evil pulseaudio and systemd reference, pulseaudio-related packages and libraries will be marked as orphans, and will be removed automatically when you run urpme --auto-orphans.

Therefore, this completes my quick tutorial on how to cleanup the evil presence of pulseaudio and systemd from the packages on a Mandriva/Mageia-based system. Of course, it is possible to improve the packaging, define custom disttags and –with flags for the build, but this text is already becoming too big so I left it out of the scope for now.

So to conclude, I hope you have enjoy reading it as much as I enjoyed this writing .

(Of course, everything said here is my personal opinion, and in no way I am trying to say something on behalf of Mandriva Board of directors)

First of all, what comes into mind when you think about the term ‘Linux Distribution’? I bet that names like Fedora, Ubuntu, Mandriva, Debian, Slackware, Arch, Gentoo – and many others come into mind.

However, what names come into mind when you think about Desktops? I believe that in this case, the names which feel most like it are Mac, Windows, Android, Meego, BeOS, ChromeOS, JoliCloud, and so on. Some of them are running proprietary OSes, some of them are partly open, and some of them are actually based on a Linux distribution or a Linux kernel and libraries stack.

And finally, what comes into mind when you think about the term ‘Linux Desktop’? Without holy wars and discussion which distribution is better (notice the word distribution here), I believe that it is hard to escape from the names as Ubuntu, Mandrake, Linspire, SLED, and similar solutions.

Some of you perhaps have already got my point. What makes a “Desktop” is not a mere combination of packages, applications, community and artwork; but it is the integration and common feeling among all of its components, and somewhat inherited desire of having a ‘standard’ way of doing everything. And Linux Distributions, on their turn, inherently have the essence of freedom of choice, flexibility and multitude of combinations of applications and goals within, which make them much more flexible on one hand, but much less focused on another.

Why Linux distributions will never (in my humble opinion) beat Windows or MacOS on desktop? By a one simple reason – they are too flexible. They provide too many options and possibilities by default, without a ‘standard’ way of doing things, and while everything works and is usually tightly integrated, this is still a combination of packages and applications, and not a Desktop. This is not a bad thing – by the contrary, I believe that this is awesome! But this opposite to what is expected from a Desktop experience.

On other turn, the Desktops which managed to succeed in the history of computers are the ones which started with a vision, and according to this vision, has evolved into a combination of applications, features, standardization and look-and-feel which made them unique.

If you think about productive and efficient desktop, Mac OS comes into mind. Even if it (with some bit of imagination) could be considered a distribution (it has lots of non-apple applications, gnu stack, unix infrastructure under it, and so on) – it is rarely seen as one. It is a desktop, it has its own unique feeling and usage.

It is the same feeling which we have for Android, Chrome, JoliCloud – even if they are, in fact, Linux distributions, they are not seen as such. They are products – with their own features, functionality, feeling, goals, and so on. They have a focus, they have a unique and controlled roadmap and goal, and this is what makes them more focused on that goal.

And this is the road where Ubuntu, and now Mandriva, are headed – running away from being ‘Linux distributions’ in the most common sense of the word, towards becoming Desktops. Ubuntu GNU/Linux Distribution has already become just ‘Ubuntu’. It is still a Linux distribution, it is based on shoulders of the giants, but it is not just another distribution out there – it became a Desktop, with its own look-and-feel, functionality, goals, features and behavior.

This is how Android and ChromeOS evolved as well – even if they are, in fact, Linux distributions, they are not seen as such, but as separated and unique products. This is what JoliCloud did as well, and this is what Linspire did in the past.

In other words, when separating Linux Distributions with Desktop solutions, it is possible to imagine a simple scale, ranging from freedom of choice, flexibility and non-prioritization of specific DEs and UIs – to single and unique look-and-feel, restricted flexibility and focus on specific features and details. The further away from the ‘flexibility’ and ‘freedom of choice’ a solution is moving, the closer it gets to become a product with ‘Desktop’ name in it.

Most Linux distributions value freedom of choice and diverse and mulch-opinionated community among everything else. They treat KDE as good as GNOME, and do not consider XFCE and LXDE as 2nd-class citizens. Every one is able to select what he wants to use, mix applications – and there are no restrictions nor enforcements on how his desktop should work.

In other corner, there are Desktop products – which enforce a single and common look-and-feel and mode of operation, define behaviors, and are focused on one single and unique way of doing anything.

And this is basically what I think on the matter .

Hi folks,

as some of you already know, this is my last month at Mandriva/Conectiva.

So I am writing this blog post to summarize a bit of what the Mandriva experience was for me.

When I came to work officially at Mandriva back in 2008 (I was already in close contact with many Conectiva and Mandriva developers for some years then), I was expecting a lot from this challenge. The possibility to work in an open-source-based company, developing open-source solutions and products for everyone – it was practically my geek dream coming true. And I have to say now, after 2.5 years since that moment, that it was certainly an amazing experience.

While at Mandriva, I managed to work on many challenging yet amazingly interesting projects; I had the privilege to work with extremely talented people from all the corners of the world – Canada, Brazil, France, Sweden, Russia – just to name a few! And it certainly was an unforgettable experience for me.

During all those years, I managed to work a bit on probably each and every Mandriva product – as a developer/maintainer for Mandriva Distribution (2009.0, 2009.1, 2010.0, 2010.1, 2010.2, 2011); as member of Mandriva Security team first with Vincent Danen, and then with Oden Eriksson, providing several thousands packages via official updates for the whole range of Mandriva products (MNF2, CS3, CS4, Mandriva 2007.0 to 2010.2); working on dozens of research and development projects (msec, tomoyo-gui, mandriva cloud, mandriva edu, and many others, some of which did not came out of the door yet, so I won’t comment on them ), developing several custom solutions for Brazilian customers, and of course countless packages..

For the past year, I also had the honor to be the technical leader and manager of Conectiva team in Brazil. And of course, as you all know, for past 9 months I was the responsible for Mandriva Desktop distributions development, leading the Mandriva 2010.2 and Mandriva 2011 products (which should be out in less than 2 months from now!).

During those years, I had the privilege to get to know and work alongside such legendary figures in the open-source world as ennael, cavassin, blino, tv, fcrozat, pterjan, rtp, teuf, neoclust, ahmad samir, götz, misc, pixel, pcpa, claudio, miura, herton, santiago, jbj, boiko, tmb, rda, colin, guillomovitch, lcapitulino, vdanen, heliocastro, bogdano, oden, aginies, anssi, adamw, … just to name a few, and of course many many others! It was a real honor, and I learned a lot with you all!

And of course, I had the chance to meet (and be the one responsible for bringing some of them ) the newly-rising stars in both Mandriva and open-source world, such as gmoro, wiliam, paulob, alexandrefm, edgard, franck, jvdm, leonardoc, denis koryavov, alex burmashev, eugene sokolov, ural mullabaev, kirill monakhov – and many other talented developers from Mandriva, Conectiva and ROSA! If you are using Mandriva, or will be using its 2011 version – you’ll certainly encounter the fruits of their work!

So, definitely, it was an amazing and priceless experience!

However, times change, people change, and I realized that time has come for me to sail to new horizons and look for new challenges. Many things changed in Mandriva during those 2.5 years, and it is a completely different company from what it once was. Many people had left, and many new faces has arrived as well during this time. But nonetheless, albeit all the challenges, problems, disappointments and achievements, we managed to stay alive and kicking even in cases where nobody was believing that Mandriva would survive. But it did.

So I’d like to thank you all for the time we spent together trying to make a Linux distribution which would change the world – I believe that we did a not that bad job over those past years!

Mandriva 2011 is almost at the release bay with all of its enhancements and unique features; Mageia 1 is there and Mageia 2 is starting its sail towards its exciting new release. Future looks bright for everyone – and I am really happy about it.

So, I’ll be around in Mandriva (the company) until the end of this month, and I’ll certainly be around in Mandriva and Mageia communities afterwards! And, of course, in the open-source world as a whole .

Cheers,

Eugeni

The pictures from my previous post, of AltLinux booth at FISL – the ones saying that the Russian President and Prime-Minister are users of AltLinux distribution – has caused lots of repercussion on several sites and forums.

Unfortunately, from what I was told, such pictures were done for marketing purpose-only (or in some sort of a joke), are purposely misleading, and were limited to Brazil only. Central AltLinux office did not knew anything about them, and it is not clear whether they were done as some sort of joke, PR or attempt to spread some of the Russian culture in South America via some “unconventional” means (according to what I learned on ru-foss livejournal community).

So I’d like to apologize here for publishing them if it caused any sort of distress or confusion. In my personal opinion, I believe that if you put some misleading public posters on your company’s official booth, on an international and widely-known conference, just for some PR effect, it is not a correct thing to do. And if you do it, be aware that a Linux-related conference certainly will have lots of people taking and sharing what you are demonstrating.

So, just to clarify and answer to all the questions I am receiving:

NO, VLADIMIR PUTIN AND DMITRY MEDVEDEV ARE NOT USING AltLinux – or any other Linux distribution at all.

However, I still hope that perhaps they will use Linux some day .

Even after living in Brazil for 15 years now, I am closely following up the stories about Linux and Open-Source success in Russia. This is why I could not resist sharing those pictures which were available at AltLinux stand at FISL (International Free Software Forum):

The caption says 'Russian Prime-Minister Vladimir Putin is using ALT Linux, and you, what are you using?'

For those of you who don’t know, Dmitry Medvedev – the President of Russian Federation – is also well-known for his interest in technology, computers and Internet technologies – and it is great to know that now he is using a Linux distribution as well!

'Russian president Dmitry Medvedev is also using ALT Linux'

As I always said, I believe that Linux and Open-Source being spread as far as possible only benefits the Free Software communities as the whole – so I can only say ‘Congratulations’ to our colleagues from ALT Linux – which was also based on Mandrake Linux in its origins. It is a completely independent distribution with its own community now of course.

Here in Brazil, Linux usage is gaining more and more adoption for the past decade, and it is quite common to find Linux-based computers in supermarkets, computer shops, and so on. Of course, they are not that widely available as their Windows counterparts, but still, it is hard to find any computer store which wouldn’t have at least some computers running a Linux-based OS, and it is usually enough to do a web search on any Internet shop to find several compatible models which come with Linux pre-installed. Be it Mandriva, Ubuntu, or any other distribution – they all have the common open-source foundation and all the benefits of free software. And yes, they are ready for desktop and casual users to use!

It is great to know that the Open-Source movement is gaining more and more spread world-wide. I truly believe that it has the power to change the world, and I am really happy to know that it does it.

P.S.: I wasn’t at FISL this year, so all the credit for those pictures go to Bogdano and Bedi from Conectiva who attended the event.

P.P.S.: Per official AltLinux response, those posters do not represent the truth and were done for Marketing purpose only. No, in fact, neither Dmitry Medvedev nor Vladimir Putin use AltLinux. Please talk to AltLinux representative for other comments, I am in no way related to them, nor I know anyone from AltLinux personally.

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!

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!

I am starting to suspect that I am the only person on the face of the Earth who actually uses this functionality. The metacity patch was rejected, the mutter patch seems to have gone to limbo (not a single developer bothered to reply to the feature request with patch over the last few months), and now it won’t enter kwin too. However, from the experience, the kde developer’s feedback was the best one, and it actually gave me some ideas on how to do this functionality without changing a single line of code within kwin.

The idea came from the fact that the kde sends and receives dbus messages for anything. So I took some time today, learned how to develop for udev in python, and also learned how to grab a message which knotify sends when a desktop switch occurs, save the last used workspace; then how to discover that a desktop switch is attempted via a keyboard shortcut, and finally trick kwin into thinking that a different workspace switch should be done.

Yes, it is a hack, which actually relies on parsing strings and regexps contained within DBUS parameters, and it has a huge and enormous overhead over plain metacity/mutter/kwin patches, but it works and does not required me to manually patch metacity or mutter or kwin for each and every release .

So this is the code. Just run this “daemon” in background and become a happy user of such functionality:

#!/usr/bin/python

import dbus
from dbus.mainloop.glib import DBusGMainLoop
import pygtk
pygtk.require('2.0')
import gtk
import traceback
import re

# This is a very dirty hack which will probably affect the karma and maybe
# even cause a global meltdown...
regex = re.compile('The global shortcut for Switch to Desktop (.*) was issued.')

lastdesktop=None
prevdesktop=None

def match(bus, msg):
    global lastdesktop, prevdesktop, newdesktop, curdesktop, kwin
    if msg.get_path() == '/Notify':
        args = msg.get_args_list()
        if args[0] == "globalshortcutpressed":
            val = regex.findall(args[4])
            if lastdesktop == None or prevdesktop == None:
                return
            if val:
                curdesktop = "%s" % (val[0])
                if lastdesktop == curdesktop:
                    global kwin
                    kwin.setCurrentDesktop(int(prevdesktop))
        elif len(args[0]) > 6:
            param = args[0][:7]
            if param == 'desktop':
                val = args[0][7:]
                newdesktop = "%s" % val
                if newdesktop == lastdesktop:
                    return
                else:
                    prevdesktop = "%s" % lastdesktop
                    lastdesktop = "%s" % val

if __name__ == "__main__":
    DBusGMainLoop(set_as_default=True)

    bus = dbus.SessionBus()
    bus2 = dbus.SessionBus()

    # ask dbus-daemon to receive all matching messages
    bus.add_match_string("member='event',interface='org.kde.KNotify'")

    # add a callback when receiving a message
    bus.add_message_filter(match)

    kwin = bus2.get_object('org.kde.kwin', '/KWin')

    try:
        gtk.main()
    except:
        traceback.print_exc()

A careful reader already noticed that I am using 2 message bus instances, parse strings by hand, use a regexp to extract the new workspace number for the switch, and use a gtk mainloop within a kde environment. And I am also doing a “cast” from dbus variables into a local representation.

Is it a hack? Yes. Is it a dirty hack? Yes. Is it an awesomely dirty and hackish and oh-my-god-I-dont-believe-it-works-kind of a hack? I certainly think so.

But it works .

And the answer I have for myself is that we are limited by the fact that we know what should one expect from his average desktop.

So, what do we know about it?

Well, the de-facto standard for the desktops includes a integrated environment, standardized appearance across all the applications, ability to quickly launch applications and switch between them, possibility of working with many documents easily… Possibility to easily work on different types of documents, graphical applications, use the resources located in some distant place over the world-wide network. And all the other small things that became so tightly integrated into our lives that we cannot imagine a computer without that.

And now, most desktop environments and desktop projects have it. We have it in Windows. We have it in Mac. We have it in Ubuntu, Fedora, SuSE, Mandriva (or better – in Gnome, KDE, XFCE and other desktop environments).

But if we consider the other part of the medal, I think that things are not that simple.

The evolution of the Internet and the web – as we know it – has flown very quickly in the past decade. Just 10 years ago, we had that crappy modem connections (in the best case), the Wide World Web was still making its first steps towards the web 2.0 revolution, and a Pentium 3 with 128MB of RAM was a dream machine.

And at the same time, we had the desktop evolution, which was going slow and steadily. On Microsoft front, we went from Windows 2000 to XP to Vista to 7. On Mac, we went through Mac OS X versions. On the open-source front, we went from KDE 1 to 4.5; from GNOME 1 to GNOME 3; XFCE went all the way up to its latest 4.6 version…

And what if we consider how the mobile and portable computing has evolved in the same time as well? Thinking 10 years ago, could we imagine Android? IPhone? Meego? And at the same time, if look at our desktop environments, they are essentially still the same as a decade ago.

If we think how the world has changed on the web, Internet and technology side; and compare it with the evolution of the desktop, I believe that it is undeniable that a slower pace was taken on the desktop side. Beside the revolution caused by the Mac OS X launch, the biggest and major revolution – in my honest opinion – was brought to us by the KDE 4 release. Yes, we have gnome – which is my main desktop environment as of now; we have all the evolution brought by the development teams at Microsoft; but I can see those changes as evolution, and not revolution in the way we use our computers.

Of course, desktops of today they are much better-looking. They have much more features, integration with the world-wide network, gadgets, eye-candy utilities, and many other features. But essentially, they still work in the same way as in the last decade.

And with the evolution of the information we have around us, with the number of information we are working with daily, with the global network around us, mobile devices, distant friends which we talk to over cellphones, social network, instant messengers, email, and the overall quantity of the information we are dealing with daily, I believe that the way the desktop is used now is slowing us down.

And what it all has to do with Planet Mandriva and my blog, where I am posting all this rant?

Well, it is a simple answer..

Since I first knew about Mandrake and Conectiva (who gave birth to Mandriva), they had the Desktop innovation in mind. Mandriva came through a difficult road this year, this is true. But now we can start thinking on how to continue this innovation even further. And as it came to me to be the one in front of the Mandriva Desktop, I can only share with you what I have in mind about it all.

In a few words, my goal is to make Mandriva the best desktop distribution out there. Not yet another distribution, perhaps not the biggest one, but the one which will attempt to transform the way we think about and use our desktops.

Will it be simple? Definitely, now. But what fun is in doing simple things?

Will it be challenging? Heck, yes!!

And I will do my best to make it work.

After the last of the LOTR movies, I was a bit lost. There was no more need to wait for the next movies. I felt almost like ‘the cinema has got to its top, and I don’t think any other movie will entertain me, and allow me to go to the other worlds as the LOTR did’. For several years, I was waiting for the next LOTR movies like a child who is waiting for the Santa’s gifts at the end of the year. And suddenly I felt like all the wishes were fulfilled.

However, some new movies appeared and made me feel almost as when I was waiting for the Fellowship of the Ring, The Two Towers and The Return of the King – movies like the Spiderman series, The Jason Bourne series, the last episode in the Starwars movies (well, the 3rd episode to be correct), Pirates of the Caribbean, 300, the new Batman and The Dark Knight movies, and many others. However, most of those movies appeared before 2009, so I started the year thinking ‘oh my.. this year will be a really boring one, with nothing interesting to watch’.

Well, to sum it in a few words.. I was completely wrong. The year of 2009 brought me a lot more excellent movies that I could possible hope. Just to name a few: Watchmen (until the very end of the year, I thought it would be simple the best movie in a long long time), 500 Days of Summer, Zombieland, Terminator Salvation, Inglorious Bastards, Taken, Star Trek, Pandorum (almost-the-best SciFi movie in a long long time), District 9, and many many others. I have to say that all those movies were great, and left a mark in my memories.

And then Avatar came and put them all into the background.

I already expected a lot from this movie, and also was quite afraid that it would not live up to the expectations. However, I had a lot of trust in James Cameron – the cinema magician who created Terminator, Aliens, True Lies, Abyss and Titanic.. and he made yet another cinema miracle. In my opinion, Avatar is the biggest happening in the cinema world of this decade. And it is specially true for the ones out there who happen live some part of their life in different worlds – worlds created by writers, cinema guys, or RPG games.

The writers manage to create great worlds, and make you believe that they are real in your mind. Role-playing games put you in those worlds, and make you part of it. But with Avatar, James Cameron was the first guy to in fact create a different world, and let us to live in it for a while. That world feels so real, that you forget about all the computer-generated graphics, effects, and a (few) plot holes, so you just lose a few hours of your real life to spend them on Pandora.

So, to sum it all up – if you haven’t done it yet, go watch Avatar – and, if possible, watch it in 3D. You’ll probably feel the same feeling as the people in the beginning of the past century had, by watching the first movies ever.

I think that resumes pretty much everything I have to say about it .

Para quem quiser mergulhar numa aventura emocionante, conhecer as teorias, mitos e lendas do Grande Caos, comparar a sua inteligência com a artificial, e participar de uma busca dinâmica afim de e averiguar a verdadeira autonomia de computação, sintam-se convidados a se escalar nessa jornada!

http://www.teses.usp.br/teses/disponiveis/55/55134/tde-05082009-205709/

Nesse em particular aconteceram muitas coisas comigo. E, seguindo a tradição dos últimos anos, só posso falar duas coisas: – A cada ano parece que o tempo passa mais e mais rápido – Todos os planos feitos no começo do ano acabam se transformando de forma inacreditável .

Bem, alguns dos destaques de 2008, que logo-logo vai ficar no passado:

• Encontrei a Vanessa (sem dúvida alguma uma das coisas mais legais de 2008 )!
• Fui para Salvador no carnaval. Foi uma experiência única e inesquecível .
• Saí da mstech, depois de 5 anos lá. Aprendi muito lá, fiz diversos projetos interessantes, achei amigos para toda a vida e cresci muito. Mas chegou a hora de procurar novos desafios..
• Adiantei de forma inacreditável as coisas do doutorado. Se no fim do ano passado eu não sabia nem para onde ele estava indo, e hoje posso falar que o projeto está praticamente terminado, e é um projeto BOM.
• Entrei para Mandriva. Para mim isso é particularmente interessante – estou mexendo com Linux já faz mais de 10 anos, mas nunca trabalhei em nenhum lugar que trabalhasse diretamente com software livre.
• Realizei diversos projetos para Intel (com ajuda do Paulo, é claro).
• Li mais de 300 livros no meu N800. Encontrei diversos livros que realmente marcaram a minha vida e fizeram pensar nela.
• Conheci diversas cervejas diferentes (novo hobby), e comecei a “degustar” vinhos bons. Casillero Del Diablo, de 2007.. hummm…
• Consolidei o meu hobby de fotografia. Algumas fotos receberam milhares de visitas, algumas centenas.. Mas, observando as fotos antigas e comparando com as de hoje, consigo notar o meu crescimento pessoal nitidamente.

E muitas outras coisas.

De forma geral, 2008 foi bom. Corrido, mas bom. Vamos para 2009 agora!

O interessante é a evolução dele (no caso, com o meu perfil).

Em 2004, só tinha gente conhecida nele (em torno de umas 250 pessoas).

Em 2005, uns 80% das pessoas no meu profile foram as que me encontraram e adicionaram (e delas, só uns 30% mandou alguma mensagem sequer um dia) (chegou a 800 pessoas o meu perfil).

Em 2006, fiz uma limpeza, removendo as pessoas que nunca responderam nenhuma mensagem nem mandaram (chegou a 500).

Em 2007, chegou a temporada de SPAM, com bilhões de perfis falsos e propaganda.  E muita gente (desconhecida e conhecida) acabou desencanando dele e saiu (em torno de 450 pessoas).

Em 2008 (i.e., agora), só tem pessoas conhecidas nele (350 pessoas).

O que eu tiro como conclusão disso? Em 4 anos, o orkut me ajudou a achar 100 novos amigos (digo, pessoas com quais eu converso, e que são especiais para mim). Tá certo que boa parte delas eu conheci na vida real, mas… o orkut ajuda a manter amizade apesar de distância e tudo.

MULHERES SÃO IGUAIS AO Linux

E é muito fácil provar isso! Vejam só:

• Ambos mostram mensagens crípticas, difíceis de entender, porém essenciais.
• Se você não prestar atenção nestas mensagens, freqüentemente pode levar um “Oops”!
• Se você não prestar atenção mesmo assim, isso vai acabar dando um panic. Kernel panic, para ser mais exato. Ou seja, f***u.
• Embora o kernel é o mesmo, as distribuições variam bastante (cor de cabelo, gostos, cor de sapato + cor de cinto, etc).
• Essa variação torna-se ainda mais visível se a gente considerar os skins que elas gostam de aplicar! (“Cabelo vermelho + sapato preto hoje; cabelo loiro + sapato verde amanhã..”)
• Elas podem ser de mais diversas configurações e opções (tem as que gostam de cálculo (hehe, não resisti), tem as que gostam de dançar, tem as que fazem até computação…)
• As mensagens que elas demonstram são quase sempre indecifráveis, e você precisa de um man para entendê-las. Err… bem, pensando melhor, no caso do Linux é mais fácil..
• Geralmente elas suportam todos os dispositivos presentes no mercado, porém cada variação do seu próprio jeito.
• Elas tem interfaces-padrão de entrada-e-saída.. (acho que vou apanhar depois dessa)
• Se você der um reboot nelas sem dar um sync antes, com certeza vai ter problemas!!
• A facilidade para instalar novos pacotes (bolsas, sapatos, vestidos) é impressionante!! (Por outro lado, alguns pacotes dão conflitos que demoram um tempo significativo para resolver).
• Elas criam processos-filhos… (essa foi péssima.. hehe)
• A interface gráfica é facilmente customizada, as vezes até demais…
• Você precisa conhecer um bilhão de comandos para fazer funcionar do jeito eficiente, e conseguir o que você quer.
• Elas tem tratamento padronizado para o protocolo ICMP PING (“psiu!!”)
• Elas suportam diversos aliases para os comandos mais variados. Alguns inclusive podem resultar em efeitos opostos do que você pensava.
• Elas geralmente estão por trás de qualquer grande projeto .
• Existem diversos bugs que precisariam ser tratados nas versões mais atualizadas…
• Elas conseguem conversar entre si em protocolos de mais baixo nível (as vezes eu acho que é mais fácil entender a saída binária do tcpdump de que a conversa de duas mulheres sobre a moda…)
• Elas tem diversas aplicações que fazem mais-ou-menos a mesma coisa (alguém pensou mozilla, firefox, epiphany, galeon, opera e konqueror para navegar na net? nada a ver, eu pensei simplesmente nos 0×208308 sapatos que tem no armário..)
• e finalmente, para concluir:
• VOCÊ NUNCA CONSEGUE ENTENDER O SISTEMA INTEIRO!
• (se você entende, é porque você é o vi.. hehe)

Eu estou usando ele desde o fim do ano, nas versões conhecidas como “nightly” (com codenome “minefield“) – são as versões compiladas diariamente. Isso tem lados positivos e negativos – entre os positivos, o desempenho dessas versões geralmente é significativamente superior ao das mais oficiais. Entre os negativos – vire e mexe algo para de funcionar (por exemplo, gmail, acentos, teclado, etc, etc). Mas em geral eu gostei da experiência que eu tive com os nightlies.

Porém, recentemente – já faz aproximadamente 1 mês -  ele tem 2 problemas extremamente irritantes:

1. O acesso ao chrome (i.e., páginas “internas” do browser) foi desabilitado. Com isso, extensions como yardvark (para remover partes das páginas – tipo banners, fontes ilegiveis, etc) e webdeveloper (caixinha mágica dos web-developers ) pararam de funcionar. Enquanto o webdeveloper – de acordo com o site do seu criador – ainda tem esperança, o outro aparentemente não vai ser atualizado no futuro previsível…
2. Os atalhos (alt-número) para trocar de tabs pararam de funcionar de vez no Linux. Isso é mais de que irritante. Inclusive eu achei o commit que quebrou isso, mas, apesar da minha experiência com o código do mozilla, não estou nem um pouco animado a mexer com isso.. hehehe

Mas, fora isso, o desempenho dos nightlies é mais de que suficiente, e qualidade de renderização também.

E, por falar em desempenho.. Acredito que muitos já perceberam que o Firefox para windows ganhou um speedup de até 4x na renderização de páginas, javascript, e funcionamento em geral. Tudo isso foi possível graças ao PGO (profile-guided optimizations) – técnica nova que apareceu nas últimas versões do GCC (junto com uma multidão de problemas, o gcc também trouxe coisas boas nas versões mais recentes ). Entretanto, só versões para windows são compiladas com esse suporte; as de Linux não.

Eu tentei dar uma chance a essa técnica – já que o Arch Linux, que estou usando no último ano-e-pouco, tem facilidade muito grande para criação de pacotes otimizados. E, realmente, a diferença de desempenho é MUITO grande. Não vou colocar nenhum benchmark nem nada aqui, só a minha opinião subjetiva. E ela é:

LIGUE JÁ O PGO!

hehehe.

(se você quer ver um benchmark, dê uma olhada aqui por exemplo -Firefox 3 ainda mais veloz | Open Mania).

E é isso. De forma geral, o firefox 3 parece ser muito melhor que o 2, vamos esperar o release final!

• porque um bit se perdeu na floresta? porque não levou o bitmap
• porque Deus criou o mundo em 7 dias? para caber num byte
• porque os processadores antigos não eram coloridos? porque não eram multi-core
• qual é a bebida favorita dos administradores de rede? ping
• como o programador dá descarga? ele chama flush()
• porque o programador foi na imobiliária? alguém quebrou o pipe dele
• porque o programador foi na imobiliária? para alocar uma casa
• onde o programador fica bronzeado? no Solaris
• quem inventou a WWW? o Homem-Aranha
• onde foi criado o Java? na Bahia
• qual é o cúmulo da calma? jogar paciência em Java
• qual é o software favorito na bahia? screensaver
• depois dos 7 primeiros dias o Deus disse: “hello, world”
• qual é o nome do cachorrinho do programador? FIFO
• e qual é a raça? fila
• como programador fecha a casa? </home>
• como o programador entra em casa? cd
• que que tem no guarda-roupa de um processador? 38 meia

(redes neurais e algoritmos genéticos):

• que que um neurônio faz no tempo livre? dorme na rede neural
• porque uma rede neural cresceu? porque os neurônios ficaram excitados
• e porque a rede não respondeu nada? porque os neurônios ficaram inibídos
• quais atividades físicas cromossomos exercem? fitness
• quem criou a TDNN? Walter Mercado
• e qual foi a primeira saída dela? Ligue Yá
• porque a MLP aprende devagar? porque ela fica pensando “\eta…. \eta….”

LaTeX:

• que que um cachorrinho faz quando encontra o dono-programador? \lambda

Novas:

• que que o programador faz nas férias? vai surfar nas wavelets
• como o programador abre um livro? ele faz um unfolding
• como o programador se reproduz? ele faz um fork()
• que que um doutorando falou depois de defender? agora PhDeu!

Comentários? Sugestões?

(Eu sei que pós-graduação deixa sérios traumas psicológicos ).

É impressionante.. Tem mais de um ano ja o bixinho (o n800, digo), mas parece novo!

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.

• A gente decidiu continuar como empresa grande (“por mais que a gente tentou, todos os nossos projetos de crescer falharam”)
• Estamos conversando com diversos patrocinadores (“nenhum dos que a gente conversou quer dar $$$ para nós)
• E quando a gente se tornar o novo Google (“Os meus sonhos eróticos foram trocados por essa frase”)
• O ano que vem será decisivo (“Estamos falando isso faz 5 anos, uma hora tem que dar certo!”)
• Estamos pensando vender a empresa por 100 milhões (“Os outros conseguiram, eu li na Internet! Porque que a gente é pior? Pena é que estamos no pequeno prejuízo constante, mas..”)
• Nós podemos vender a empresa por 10 milhões facilmente, mas queremos crescer um pouco mais antes (“Eu li em alguma revista que alguém vendeu uma empresa parecida por 10 milhões, e tenho fé que conseguimos também! Só trabalhar um pouco mais no prejuízo sobre a grandeza do qual eu também menti na pergunta anterior..”)
• O mercado não estava pronto antes, mas agora temos uma oportunidade única (“Estávamos fazendo algo completamente inútil por 5 anos, e de repente apareceu algum tonto querendo comprar!”)

Em poucas palavras, dá para fazer um dicionário de como conversar com um CEO:

• Divide todas as palavras, promessas por 10, e depois por 10 de novo, para chegar perto da realidade.
• Avalie o sucesso da empresa pelo lucro e prejuízo (idealmente, avaliando o relatório financeiro completo e plano de trabalho), e não pelo que o CEO diz.
• Se o CEO diz “com certeza”, leia isso como “talvez”. Se ele diz “provável”, leia isso como “só por um milagre”. Se ele fala “talvez” então, nem com milagre .

Original aqui: http://victorronin.com/2008/04/19/molochnye-reki-i-kiselnye-berega/