Remember the last call? After less than 5 months we can see apparent success, and a lot more than a proof of concept.

Click to enjoy the show

Shocked by the title? So I am.

Would you like to see Qt supported on this platform? Just two days ago the answer was like "But it's close to impossible".
Now with NDK 1.6 the "little robot" OS opens more to C/C++ native code. I am eager to read some analysis on the topic.

One big risk with git is forgetting which branch you're working in. Several people solve that by putting the git branch in their shell prompt. But often they do that by calling `git branch` and parsing its output, which is quite slow, especially in big repositories (we strace'd it, and it really opens and reads a lot of files).

At GCDS, together with Aurélien Gateau et Sébastien Renard, we came up with
this light-weight implementation (http://www.davidfaure.fr/scripts/git_branch_in_zsh_prompt).

Hearing that kubuntu jaunty was out, I upgraded two machines today.
My wife's machine, so she can finally use KDE 4.2, and my own desktop machine. On her machine, NVidia card, no problem at all.
On my machine, ATI Radeon X1300, after the upgrade, X would always just show some red dots on the top of the screen, and then the machine would hang (no keyboard, no ssh, nothing except reboot).
I tried every possible driver in xorg.conf, no difference. So this isn't a driver problem, but an Xorg problem.
Other people on #kubuntu (e.g. "chx") reported the same issue.

Yes, sounds strange. Why should i did it ?
Well, first is known among the distros that qt-creator in first release is not the most friendly to packaging.
Not only beacuse qmake, but because some distros rely on things like splitted packages or 32/64 bits coexistent libs and plugins.
Second, was quite a challenge for me do this, because i need to learn some new tricks ( thanks dfaure for automoc4 help ).
Third, dressing my packager hat, i would love to see qt-creator been in the main Mandriva distro, compliant with our policies, and been adopted as well i expect for kdevelop4 when be released. Qt Creator is one of the amazing IDE's around and i thought that worth the effort to give some love in buildsystem to have it in a full Mandriva way, including our flags and standard cmake build.
During the process, i could manage to fix all bugs open in our bugzilla about packaging, and at same time enable the "most wanted" feature here, the designer plugin, which for some reason was not enabled in our qmake previous compilation.

To summarize what i did:
- Write whole cmake buildsystem
- Backported icons and mime and desktop files from upstream binary Qt Software package ( as same as Kubuntu did )
- Make the plugin standard dir be the Qt plugins standard dir, which make possible have 64 and 32 bits plugins instalable
- Make qt-creator easily compliant to /usr linux install
- Splitted libraries in subpackages as usual, and installed in our standard libdir instead of a subdir
- Reenabled designer plugin.

So, now i'm totally happy with all the changes, barely minimal in code ( most moc include additions and add standard Qt plugin path ).

For who is interested, our svn repository is Qt Creator Package Repos
For who wants to try our marvelous distro, today we will be releasing RC1 from Mandriva 2009 Spring, so you will be able to see how hard we are working to make a better distro for you...

Well I have been mumbling for a few weeks now about this "Flo" project and so far I have gotten a ton of encouraging feedback. For those of you who don't know what Flo is, here is a gentle introduction.

So some guy from Nokia named Ari Jaaksi was speaking at some conference and said something along the lines of open source developers needing to be "educated" about consumer restriction technologies like DRM.

While I agree with Ted Tso that these words weren't chosen wisely, I believe that the actual message got "lost in translation".

As reported at some point Ari Jaaksi said "...but we are not yet ready to play by the rules..." (emphasis mine), cleary indicating a wish to move beyond the the messed up situation they are currently in, caught by traps like DRM.

To get out they need help from someone who is not trapped and, as Ari Jaaksi indicates, this basically means the Free and Open Source developers on a technical side and the Free Culture communities overall, since anyone in the industry is caught as well.

To help somebody out of a trap one needs to understand the trap and how those in it got caught (or why they willingly submitted into), so I am going to discuss one of the: DRM, Digital Restriciton Management, e.g. technology and techniques to deny consumers the execution of part of their rights.

DRM is a very nasty trap, not only for those effected by it from outside, but also for those caught in it, because it is a cover-up of a lie.
As everybody knows, if one lies, one needs to make sure the truth is not uncovered, because whatever one used the lie for, getting exposed as a liar has usually worse consequences as one's original wrong-doing.

It started when those who get the work of the gifted to distribute it to the consumers, also known as publishers, failed to do their job properly and their profits declined.
Instead of taking the responsibility for losing sight of the customers' demands and letting product quality decrease, they blamed it on the "pirates".

To make sure their lie would not be noticied, they were willing to spend money on whoever was willing to help hold up the fake truth and when money is to be made, there is always somebody willing to take it.

So DRM was born and everybody directly involved knows that it does not work as advertised to those who pay it.
The developers in the companies creating DRM technology know it, their management knows it, the management of their customers (the publishers) knows it, their developers integrating it into the final product know it, however, those who pay, the consumers and publisher sharewholders do not.

There will be different strategies how we, the untrapped, can help them out, assist them in getting out, disarming the traps, etc. and each strategy will have different implications for both sides.
Therefore it is important to learn about the messed up situation these technology providers are in, to understand which strategies might look good from our point of view, but will force them into countermeasures.
They are looking for a way out that lets them leave broken concepts like DRM behind without "losing their face".

I think we should continue to do what we do best: delivering cool, innovative, useful and, most important none-restricting, techology experiences, so customers learn to understand that they do not have to cast away their rights in order to participate in modern life style.

Ever called a perl script and got this?

Can't locate Regexp/Common.pm in @INC (@INC contains: SCRIPT /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0 /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.10.0 /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at SCRIPT line 18.

Well, use zypper:

coolo@desdemona#STABLE>sudo zypper in -C 'perl(Regexp::Common)'
Reading installed packages...

The following NEW package is going to be installed:
perl-Regexp-Common

Easy, no?

Well, was a huge journey for usr this time. 2008.1 was not only an updated 2008.0, but since early design, was clearly that we would try do a big step on our development. Just to mention what arrived since 2008.0, we're integrated Manbo labs work, which means now we're have a real common core system between us and Turbo Linux, we're integrated PulseAudio on whole distro, which was a bold move and even not been so perfect yet, for me proves at all that was the right decision, and of course, we did most of possible fixes and insanities on KDE 3 !!
I can tell, we sacrificed polish a kde 4 environment, today in contrib, due our heavy tasks to make KDE 3 as best as possible. I can't measure the stress of hunt and do changes like we want, and some couldn't be solved to last moments, but i can say was one of the best KDE deployments the Mandriva KDE team did ever. From the screensaver to the kicker changes to menu changes, all small patches and fixes almost impossible to be noted, but which took hours from us to find, or even touch in monster codes like kicker one, and integrate new features.
As i promised myself, the day we gone gold, would be last day i would see KDE 3 in my personal work machine, so now i'm using in production KDE 4.0.68 over 2008.1 base and i guess you know why ...
So congrats to everyone that did a wonderful job on Mandriva Spring and we finally break the curse

We implemented some very interesting features for openSUSE 11.0 to make the
installation easier and faster:

• giving it a green face
• making the configuration automatic
• switching from bzip to lzma for rpm payload
• put images of default patterns on the DVDs
• move online update to the desktop applets
• improved package management speed

Yesterday I installed 11.0 Alpha3+ (which is a snapshot of Factory burned
on DVD) and it definitely felt fast and easy. So today I decided to give
10.3 another try to measure where exactly we improved or if it's just placebo.

I let the #yast channel know my ongoing times (here only a short excerpt):
10:22 * coolo starts with a 10.3-i386
10:23 < coolo> ok, let's start.
10:29 < coolo> 6 minutes for first stage configuration
10:52 < coolo> finishing basic installation
11:06 < coolo> I'm in the 10.3 KDE online and registered
11:06 < coolo> 43 minutes all in all
11:09 < coolo> ok, on to 11.0
11:16 < coolo> starting from DVD
11:21 < coolo> first stage config done
11:25 < coolo> images deployed
11:33 < coolo> finishing basic installation
11:40 < coolo> I'm online in KDE - 24 minutes

I did not do online updates in either - that would have been incomparable, the
registration is missing from 11.0 though, this will only be done in time for
beta1. But even if you add another 2 minutes, an improvement from 43 to 26
minutes would be a very good deal to install a full blown system with 2.6 GB.

Sorry that I did not create graphical representations of the individual stages,
that will come later - and yes, the title of this blog was fixed before I did
the actual testing.