Category Archives: GNOME

Moving on: 64bit Linux, PulseAudio, Fedora 10 and so on

Tux
With the release of Fedora 10 I took the opportunity to finally switch over to 64bit Linux – including the proprietary stuff like Flash, Skype, and so on. Also, Fedora 10 itself had several rather pleasing surprises for me.

I already used Fedora 10 since it’s Beta release. However, recently I decided to re-install it, this time in 64bit, and check how that would go. Also, since I had some rather strange problems and performance issues I wondered if a re-install would fix them.

64bit in General

Switching from 32bit to 64bit on an operating system is a huge and complicated task involving effectively all larger applications. This can e a real pain – unless you have an operating system where all software usually supports 64bit anyway. This is the case with most open source operating systems and therefore also with Linux. So grabbing the 64bit image and installing it was just like grabbing the 32bit image. In case of Fedora the download link offered by default was 32bit, but 64bit was just a click away. I wonder when that will change.

There are numerous advantages and disadvantages regarding 32bit and 64bit, for a first introduction start with the Wikipedia article.

Flash

The problems regarding 64bit arise when you deal with non-Open Source software: this might only be provided as 32bit. In case it depends on any other library, the system must provide these libraries in 32bit and 64bit. While on RPM systems this is not a problem at all, this can be rather problematic when browser plugins are 32bit only, because then the browser needs to be 32bit only as well, the same is true then for all other plugins, and so on. There are wrappers to deal with that, but these are sub-optimal.

Luckily, Adobe has now released a 64bit Alpha version of their Flash player. While it is still missing several features and is not even provided as a rpm or deb file, in my first tests it worked without problems. As a side note, the 64bit versions for Windows and Mac OS are still not out there – Linux is a clear technology and development pusher here!

For the sake of completion (and since someone would point it out in a comment anyway), there are also free (as in FLOSS) alternatives to the Flash player – which are available in 64bit for quite some time now, of course.

Skype

Another issue is Skype – this is not provided as a 64bit version at all (bug report). For Ubuntu users there is at least a 32bit version modified for easy installation on 64bit systems. Btw., hardly anyone seems to know that, even the German Ubuntu wiki doesn’t mention that at all.

Anyway, that doesn’t help the Fedora community anyway – but since Fedora runs on RPM installing all the compatibility libraries is just a question of hard disk space:

yum --nogpgcheck localinstall skype*rpm
yum install alsa-plugins-pulseaudio-1.0.18-1.rc3.fc10.i386

That’s it. In my tests Skpe indeed worked, even a video test image was shown although I haven’t actually made a real video call. Also, I had problems with the microphone, but that might be due to problems with PulseAudio. I appreciate any tips on that issue.

PulseAudio

Well, PulseAudio is a difficult thing. It has a rather strong community and people are making sure it comes up everywhere and works everywhere like it should. However, while I read all the rather long papers and documents why I should need PA, nothing of these papers really stuck, and I always wonder why it is really needed – apart from the more esoteric reasons that Alsa is not suitable for the future. Besides, I do wonder if the Alsa guys would say the same.
Additionally, in my first tests PA worked just fine – under Gnome, but not in KDE. So my first step after installing Fedora since my first contact with PA was always to remove PA.

But I always tend to give things another try, and this time I didn’t remove it. And indeed, almost everything works, and I haven’t even met a delay yet. It all just works, even on KDE with its Phonon!

So it looks like PA finally fits in well. Now what I only need some ideas what to do with it :D Seriously, what I would appreciate to see is a simple one sheet drawing with all the usual suspects of the Linux audio blob (from Phonon over xine down to Alsa) to see where PA fits in and what it does there.

KDE, Nvidia and performance

Fedora 10 now includes KDE 4.1.3 (included in the updates), and together with RPM Fusion Nvidia drivers are just a

yum install kmod-nvidia

away. While I had trouble with this way with the beta version, and general serious performance problems with the drivers installed manually, it turned out that with Fedora 10 final everything works like a charm – fast and snappy!

I am slightly surprised and wonder what was wrong with my Fedora 10 Beta setup. But on the other hand, my work machine is running Kubuntu 8.10 and there the performance is similar fast. So to me it looks like the days of slow KDE 4.x on Nvidia hardware are finally over, given that the drivers are the newest stable ones and KDE is of version 4.1.3.

Fedora’s encryption

This time I decided to not go with a full hard disk encryption, but rather with a home disk encryption. And while I still dislike Fedora’s disk druid for not letting me chose the disk setup in detail I appreciate that clicking a checkbox was all I had to do to activate the home partition encryption. It is even nicely integrated with the boot process.

Overall impression

The overall impression of Fedora 10 is very good. Most bugs I encountered running the Beta version are fixed – except for a strange coding problem, but I will survive that one.

Also, my first move into the lands of 64bit are also far less complicated than expected. Your mileage may vary, depending on the used proprietary software, but then again kvm might be a solution to work around that problem.

Plans for Gtk+/GNOME 3.0 surfaced

Tux
At the GNOME conference GUADEC plans were presented how the transition to the new Gtk and GNOME is supposed to happen. The basic idea is to make the transition as smooth as possible by first cleaning up everything and introducing new concepts later on.

The news flash came right from GUADEC today: there will be a GNOME 3.0, and it will break the libs. Most news sites picked that up, but unfortunately there are hardly any further information out there.
A notable exception is the Austrian derStandard.at which covered the topic with a bit more details.

Basically the main aim for Gtk+ 3.0 is to clean up everything. Old/Not anymore needed functions will be dropped. The current state of this cleaning is tracked at the GNOME wiki. New features are planned for versions coming afterwards. This will of course include ABI/API brakes, but an aim is to make such a transition smooth. Well, it would be surprising if it wouldn’t ;) One notable idea though is to flag all dropped functions as “deprecated” in an upcoming GTK+ 2.x release.

The GNOME release team also plans to drop unnecessary/old code and to clean up the code base, and again the plan is to make this transition as smooth as possible. Additionally, it is planned to come up with a two-sided release schedule: there will be a release every six months, but there will also be long time rhythm for larger aims and features.

These aims sound and ideas sound reasonable – and do remind of course of the KDE 4 process. I do hope for the GNOME team that they had a close look at the KDE 4 process and learned from it: many things worked out surprisingly well, some things didn’t, and they can copy the first and learn from the second, why not.
I must admit though that I wonder how the “first-clean” idea can be realized – at least for KDE that would not have worked. Or said different: where such an approach was used it was also strongly criticized. The best example here is probably the KDE-PIM suite: as part of KDE, it was cleaned and will be introduced first again with KDE 4.1. Many people missed it heavily, although of course it was made sure that KDE-PIM-3 worked perfectly well with KDE 3, so a smooth transition is indeed possible. With the plasma panel a simple version of a panel was introduced to build upon, and again there have been many critics.
Also, sometimes straight cuts are necessary – think of arts->Phonon here.

Anyway, in the end GNOME is a quite different project compared to KDE, so it is difficult to compare both. But they will face some similar problems, and so it would not be the worst idea to see and learn from the KDE experiences. It’s always easier if something is done a second time because you have the experience from the first run, but good luck nevertheless! :)

Short Tip: Using Brother MFC-5840nc printer in Linux/Fedora

Tux
Brother printers are usually not supported out of the box on Linux. However, the company provides drivers for Linux which are working. In this case the printer is a Brother MFC-5840nc connected via LAN.
Brother provides two packages (rpm and deb) which have to be installed in that case: the lpr drivers and the a cups wrapper. Both packages for the appropriate printer must be downloaded. Afterwards, a new printer is already registered with the system but must be configured right: by default it is registered as a USB connected printer which in case of a LAN connection is of course wrong.
The easiest way to configure the printer is to access http://localhost:631/printers/ which is an interface to the printing system. In case of Fedora the root password is needed to store the configuration changes. When everything is set up a test page can be sent to the printer.

The printer also appears in other applications like in KDE/GNOME apps.

Forth and back again – having a look at Fedora 9 and KDE 4.1beta

kde-logo-official
Recently my distribution of choice, Fedora, published a new version, Fedora 9. This one featured KDE 4.0, and there were also KDE 4.0.80 packages available, and I decided to take a look at them. Unfortunately, I had to return to Fedora 8 and KDE 3.5.9 – but not for long, that’s for sure.

The background

Recently I wanted to try two new “tools” – Fedora 9 and KDE 4.1dev. The reason behind was that both came along with a whole bunch of new features. Fedora 9 promised full disk encryption, a new X-server, PackageKit, a new NetworkManger, Upstart and so on, while KDE 4.1dev promised me first and foremost KDE 4.x. I was still in KDE 3.5.9 because I had to write a thesis during the upcoming of KDE 4.0 and wasn’t able to switch. Therefore I decided to install Fedora 9 and afterwards update the system to KDE 4.80 with packages from kdeforge. KDE 4.0.x wasn’t an option because I wanted to have the KDE 4 PIM suite.

The bad experiences

However, the journey did not went as well as hoped. First of all Fedora itself did not boot up any faster. Of course I know that switching the init system itself doesn’t make the scripts go faster, but somehow I expected it to go at least a bit faster than maybe a minute. But the problems with the new KDE were more pressing: KDE froze X several times (Gnome didn’t), most often when the kerneloops popup tried to tell me something. This happened regularly after only a few minutes, and made the system unusable. I deactivated kerneloops, selinux and other usual suspects, but X still froze after some minutes most of the times.
Additionally, Plasma is not able to enlarge to a new size when for example an external monitor with a higher resolution is plugged in. That is however my daily setup, and must work before I can switch to KDE 4.x.
Last but not least I had two issues with Dolphin: first of all, the Ctrl key doesn’t work as expected. Seems to be a bug in Qt 4.4, but nevertheless, I rely heavily on that feature. Second, Dolphin is quite slow when scrolling through large folders. I deactivated the information panel and it was quicker, but still not as fast as I am used to from KDE 3.5.

I did suspect that these problems could be related with Fedora or were fixed with newer devel versions of KDE, and therefore I switched my system to OpenSuse 11RC with the unstable KDE 4.1dev packages. But all mentioned problems were still present except for the X freezes (not entirely sure about that one).

So, in the end I had to switch back to KDE 3.5.9. There are only few things, mostly corner cases, which keep me there, but these are, unfortunately, existential to me.

The positive outlook

However: the impression I got from just playing around and testing the system was the same I already got from testing it only for minutes in virtual machines or demoing the system at LinuxTag: KDE 4 is awesome.
One of the best examples work-flow wise is probably the new menu. I newer was a fan of menus (Alt+F2 does the job quicker) and wasn’t really interesting in the change introduced with KDE 4. However, just using it for minutes already changed the way I worked. The ability to search through the menu is a nice and helpful add-on and just makes sense today. But the main advantage is the easy and intuitive way of setting favorites. It is a blast once you get the idea behind it and actually try to use it. I got accustomed to it after minutes, that was almost scary.
Also, I’m someone who never uses icons or links to clutter the wallpaper – but the folder view might be a good solution when I have to work with a bunch of files (think of TeX here, or of merging different images or text files). It still has some rough edges and could use a way to have no background at all, but it is definitely on a very promising way.

Besides these work-flow improvements there are of course the improvements within the apps, and the new apps in general: just some days ago I was chatting with a friend about city distances, and right in the discussion she said “so just check it with Marble”. Well, I would like to!
Another application I’m really looking forward to is Gwenview – the KDE 4 version is very, very neat. Also, KDE3’s KHTML engine is a bit notchy at the edges, holey in the middle and has a crack at one side. But KDE 4’s KHTML engine is much improved and is therefore a reason on its own to switch. And I haven’t even tested yet (that means: used in daily live) apps like Okular or the improved Kopete.

So I am very eager to see the above mentioned bugs fixed and will afterwards give it yet another try. I’m already sure that my work flow will be more efficient, and that’s in the end what really counts!

Closing words

Besides KDE 4.1 there is also Qt 4.4: some new apps I would like to test are based on Qt 4.4: Screenie and Arora/Foxkit are just the most prominent examples.
There are also bew 3rd party KDE 4.x applications: while the “usual” programs like Ktorrent, Krusader, digikam, Amarok or Konversation already have KDE 4.x versions or are working at it, there are also some new interesting programs around, like Audex or KGrubeditor.

Having said that all that, I’m still very happy with KDE 3.5 right now. It is still a supported platform which just works as I expect it, as I am used to. It even gets bugfix updates if necessary, for example KDE 3.5.9 was released after KDE 4.0, and I’m very thankful for it.
So I’m totally free to choose what I want – and that’s the most important point!

Future of FLOSS password storages: combined solution soon?

kde-logo-official
In a recent discussion about the future of KDE’s password manager KWalletManager it was mentioned that it is currently discussed to share a common password manager across all important FLOSS projects. While there is no result yet this is indeed a promising – and necessary – development.

It started with a question by Michael on the list kde-core-devel regarding the possibility to switch KWalletManager’s backend to the Qt Cryptographic Architecture (QCA) entirely. Robert answered that there was indeed discussion going on during FOSSCamp to merge all existing solutions (KDE, GNOME, OpenOffice, Firefox) to make it easier for the user to use these applications, but also to have the ability to sing-sign-on (meaning one login as user, and than automatically login everywhere else), which is a need for modern desktops. Afaik Fedora also has this topic on its radar, and it would surprise me if no one at OpenSuse, which constantly tries to bring these two desktops closer, has already put some thought into that.

While there are no visible results currently the need for such a solution is definitely present: At the moment it can happen that there are multiple programs used to store different keys in one single user session: Firefox on KDE introduces for example a second key storage right besides KWalletManager. Since the Open Source world does not want to force any solution on anyone, it should be possible to switch between Konqueror and Firefox without the need to take care of your passwords.
Technically there is no reason against a shared password storage, but it might tricky to convince the application/desktop developers. On the other hand, if KDE would get a pluggable KWalletManager backend it could even become possible to use the native key storages on other platforms if such APIs exist.