Hi folks,

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!

…or how to purge pulseaudio and systemd presence from your beloved system and start a world crusade in 3 easy steps :) .

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 :) .

This is just a quick post which perhaps will help someone else besides me.

If you tried to install VirtualBox from its official binaries available at the official site on Mageia, you perhaps have realized that it won’t install itself due to a missing libcrypto.so.0.9.8.

Where this library comes from? Let’s go for a bit of history of openssl in latest Mandriva releases..

Back in pre-Mandriva-2010.1 era, I was the one responsible for upgrading openssl library to the official 1.0.0 release, which was released after almost a decade of development. And according to Mandriva library policy, which allows multiple libraries with different major versions to coexist, this resulted in having available both libopenssl1.0.0-version-release.rpm and libopenssl0.9.8-version-release.rpm, which was carried out from the old build. It was still kept for backward-compatibility issues, and also for third-party packages compatibilities (as almost nobody has migrated to openssl 1.0.0 back then). And at some point, (almost) all of the Mandriva packages were rebuilt to use OpenSSL 1.0.0 libraries correctly.

However, this also resulted in the package libopenssl0.9.8 becoming orphan – it had no corresponsing .src.rpm in the repository, as the source rpm was providing only libopenssl1.0.0 library now. But as for binary package, it was left there, as there were additional applications requiring it.

When Mageia folks has forked the Mandriva repository, they did a correct think – they fully rebuilt all the packages from their source files, resulting in a complete, fully rebuildable and non-ambiguous repository. However, the libopenssl0.9.8 went missing in action – as it had no corresponding source package anymore, it became unavailable.

So finally, after almost a year since the openssl 1.0.0 migration, I’ve discovered one 3rd-party package which was still relying on openssl 0.9.8 to be available – Oracle’s VirtualBox packages. This is why such question arose.

There are many ways to solve this problem, ranging from creating a new package specifically for openssl0.9.8 (most ugly one), to creating dumb symlinks from libcrypto.so.1.0.0 to libcrypto.so.0.9.8 (most workaroundish and dangerous one), to persuading Oracle devs to build their VirtualBox packages on post-2010.1 Mandriva versions (most correct one), and so on.

However, I just took a simple route, and simple did

urpmi http://ftp.free.fr/pub/Distributions_Linux/MandrivaLinux/devel/cooker/x86_64/media/main/release/lib64openssl0.9.8-0.9.8n-1mdv2010.1.x86_64.rpm.

(or, for 32bits installations):

urpmi http://ftp.free.fr/pub/Distributions_Linux/MandrivaLinux/official/2010.1/i586/media/main/release/libopenssl0.9.8-0.9.8n-1mdv2010.1.i586.rpm

This is certainly not the right thing to do, but it works :) .

My last series of posts about what I think about Desktop OSes and the place of Linux distributions among them resulted in lots of very interesting and informative discussions, so I decided to write this follow-up to summarize everything, and describe the role of Mandriva in this environment as I see it.

(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 :) .

So, after 2 years with previous blog design (powered by MiniMoo 1.3.4 theme), I thought that time has come to give some new and fresh look to it.

So now it is powered by the amazing Suffusion theme for wordpress. And, at least in my opinion, it looks much more clean and cool. Please let me know if you find any problems, or if anything that was working suddenly has stopped.

Having said that, the ones of you running wordpress blogs on custom mandriva-based sites, please note that there is a new version of it in Mandriva available in cooker (contrib/release) and 2010.1 and 2011 branches (in contrib/testing), thanks to Adam Williamson, its maintainer.

Yes, yes – I believe that you have noted that there is a new 2011 branch of Mandriva now, which is going on in parallel with Mandriva cooker! As I promised last year, our idea for Mandriva was to provide this a bit before the release – a rolling cooker version of the distribution; and a stable branch which will be supported for 3 years. It is called just 2011, and will have the same way of living and being supported as we did with Mandriva 2010.2 – the first release will become 2011.0; after 6 months or so there will be just an incremental updated isos and images (2011.1), and then 2011.2 which should be out of the door somewhat together with the Mandriva 2012 version.

As for Mandriva 2013, I won’t promise anything now – with all that Maya prophecies it is hard to forecast something. (Just kiddin’ of course :) )

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

Hi folks,

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 :) .

Edit – please look at the P.P.S. below for clarifications before commenting same thing over and over again*

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.

© 2012 Eugeni's blog Suffusion theme by Sayontan Sinha