Installing Counter Strike on Fedora 18 in 4 steps. And some comments.

(1) Follow the instructions listed on this blog to install Steam. Don't worry, it works well on Fedora 18, too.

(1a) If you wonder who is 'Spot', the Fedora 18 unofficial steam package provider,  checkout out his short bio on fedoraproject wiki.

(2) Install Counter Strike 1.6 using Steam Client. A piece of cake.

(3) Now the important part: go to your local steam directory

~/.steam

directory and create a symlink to provide all libs that are required by the game.

cd ~/.steam
ln -s bin32 sdk32

(4) Play!

I'm not hiding that I'm really excited about having Counter Strike running on my Fedora. It was exactly this game that made my switch to Linux really difficult.

I'd like also to point to one more thing. This wouldn't be possible without a major OS provider, whose attitude caused Valve to look for alternatives. It will be a bitter lesson for some people.

We, as an open source community, should never forget what happens if you ignore your users.

Happy fragging!

That's just unbelievable

I never thought it will happen. Thank you all, who made this. And thank you all, who caused this (including OS providers).

Counter Strike 1.6 running on Fedora 18

Instructions how to do that will follow soon.

Happy fragging!

Unmaintained libraries are a security hole - Call for Help

I was thinking about naming this post "A security hole in Eclipse" but that could be a bit too strong. But the truth is that unmaintained libraries are a big risk to the entire software stack, because there is nobody to look after them and release new versions.

I'm writing about this, because recently my eyes looked at Eclipse and bug 337449 - [transport] Consume httpclient 4 provider from ECF. It looks innocent, but is it indeed?

The HttpClient project website says:

The Commons HttpClient project is now end of life, and is no longer being developed. It has been replaced by the Apache HttpComponents project in its HttpClient and HttpCore modules, which offer better performance and more flexibility.

Now, if you drill down into the aforementioned bug, you will discover that there is a support for HttpClient 4 in ECF, although it looks unfinished. It is unfinished in that sense that it is not fully tested. So Eclipse Platform can't use it. So it remains untested... We really can't afford for waiting any longer.

So I have prepared an Eclipse Platform Build with httpclient4 for all major platforms. Please get it from my fedoraproject page and test it by installing anything from an update site. Especially if you are behind a proxy. And update the bug with results. It's needed to move that bug forward!

Here are direct links to Eclipse Platform with httpclient4:

• http://kdaniel.fedorapeople.org/httpclient4/org.eclipse.platform.sdk-win32.win32.x86_64.zip
• http://kdaniel.fedorapeople.org/httpclient4/org.eclipse.platform.sdk-win32.win32.x86.zip
• http://kdaniel.fedorapeople.org/httpclient4/org.eclipse.platform.sdk-linux.gtk.x86_64.tar.gz
• http://kdaniel.fedorapeople.org/httpclient4/org.eclipse.platform.sdk-linux.gtk.x86.tar.gz
• http://kdaniel.fedorapeople.org/httpclient4/org.eclipse.platform.sdk-macosx.cocoa.x86_64.tar.gz

Happy testing!

BTW. This would not be possible without platform CBI build system making the build process really easy.

far Orbit

I am not a biggest fan of Orbit project. I do, however, understand now, that it is needed due to the legal reasons, as it was stated in the comment to my blogpost nearly a year ago:

• The 3rd party libs have been vetted for IP, 
• they have been turned into OSGi bundles so they can be used
• they are available from a p2 repo so they can be consumed by PDE builds

 The biggest fear I have is that Orbit version of projects is isolated. They get OSGi Manifests, sometimes version number that is different from what is in the original, and sometimes even different name.
All those things does not make adoption and updates easy. There is practically no way to build Eclipse with newer version of a particular library and use it for testing.
So here is my proposition - let's contribute OSGi manifests or even entire packaging back to their providers. They don't always know/care about OSGi, but they rarely object such changes.
This will make the process of new version adoption easier, because testing/3rd party products could use newer version of libraries which is not yet present in the Orbit without taking the effort to build it them themselves.
Of course, I'm not demanding everyone to do it right now, but please, give it a thought before submitting a new [version of] Orbit bundle.

We should be removing the border between Eclipse and the rest of world.

Happy bundling!

Eclipse Git update

New Year gift to Fedora users: yet another performance update, this time to EGit and JGit, has been just submitted.

It contains a new upstream release 2.2.0 with an impressive number of new features and enhancement, among which the most important (for me) is incremental reindexing of repository.

Actually this update and last Eclipse update reduced the heap usage almost by half, and Eclipse is much more responsive now. Check it out!

sudo yum --enablerepo="updates-testing" update eclipse eclipse-egit eclipse-jgit

The entire list of EGit/JGit is here and here.

Happy New Year Hacking!