Gnome and NFS

when it comes to folder sharing in a local network and Linux, you have basically the choice between samba and NFS. While samba is the better choice when you have also windows machines on the network, NFS should be the choice when the network is homogeneously Linux, since it is much easier to configure and directly maps user-ids and permissions on the remote machine.

One might think, that that native Linux filesystem should have good GUI tool coverage, but amazingly there are absolutely no tools for setting up NFS in Gnome, while accessing a Samba share is just a few clicks away. In order to set up NFS one still has to manually edit the fstab and manually mount the directory in the console. Neither Nautilus nor gnome-volume-manager give you a hand here.

Even though the tools you need are already there; you can already advertise NFS through Avahi/ Zeroconf and make it automatically show up on OSX – all it takes is to make Nautilus recognise this and automount the share in the /media/ folder.

So lets vote here and hope that the situation improves.

fglrx 8.9: improved 2D performance

AMD just realeased a new version of their proprietary graphics driver fglrx. While usually they only introduce new bugs every months while the really interesting stuff is happening within the open source radeon driver, this month there are also some interesting things in fglrx.

Not that it would excite any of the existing radeon users, since they have got that stuff for months, but now fglrx also supports Xrandr 1.2 and accelerated 2D rendering through Xrender.

in order to enable this, add the following to the Video Device Section of your xorg.conf:

    Option      "Textured2D"
    Option      "EnableRandR12"
    Option      "TexturedXrender"

Textured2D is AMDs acceleration architecture for primitive drawing, similar to EXA in the open source world and is required for the Xrender Acceleration.

Although 2D is just as good as with the OSS drivers now, the texture_from_pixmap extension is still slow and so is scrolling in compiz,  therefore I would still recommend the OSS drivers for compiz.

So Mozilla is getting cocky again

As you propably already know, mozilla is now demanding that vendors display their EULA if they want to ship the Firefox branding. I could understand the issue they had with debian last time, since the debian package was not it that good shape – but now I think it is going over the top.

Firefox is an open source application an as far as my intuition of this goes this means that it must be as easy distributable as possible. Putting an EULA in front of the application complicates the whole thing unnecessarily. But Mozilla thinks Firefox is such an important brand that everyone just has to swallow it.

But I do not think they are that important, since they are only a small component in the operating system called Ubuntu. And for most people the “operating system” is synonymous for “the computer” and hence they call it so.

So I propose to split up the current firefox package in two packages one called “xul-browser” and another called “firefox-branding”. As default “xul-browser” is being installed which is basically firefox but without the icon and without google in the search engine list and of course without the EULA. The “firefox-branding” package will include the icon, the EULA and add back google as the search engine, but wont be installed as default. Lets see how mozilla reacts when google asks why their ad, they have paid for is not visible in a major Linux distribution. The risk for Ubuntu should be minimal, hence most people I install Ubuntu for ask me for “the Internet” and dont care whether it is displayed to them by Firefox or by IE.

YouAmp 0.4.1 is out

Yeah, I have missed the YouAmp 0.4.0 release announcement, but since this update is just a few days ahead, I will just merge that two.

So the changes since 0.3.8 are

  • support submission to
  • submissions are happening in background and do not block UI
  • cursor is moved on shuffeling/ unshuffeling, so you can just unshuffle if you want to get more of the same artist
  • the playlist is now automatically updated if you change the music folder
  • mp4 and wmv files are now also supported

Finally Liberated

Bcoming with the approaching Intrepid Ibex release it seems like you finally will not have to use any closed source drivers on a Lenovo T60.

Right now with hardy I use fglrx and madwifi to get all the hardware working properly.

  • fglrx is needed because of the used r500 graphics chip, which got supported only recently with the mesa 7.1 release
  • madwifi is actually not really closed source, it just uses the closed source hal library in order to talk to the wireless chip

But with intrepid there are now better alternatives available:

  • mesa the open source driver now also supports the r500 chip in 3D and on top of that also offers superior 2D performance by using EXA
  • ath9k atheros has started supporting open source properly and got a working IEEE 802.11n wireless driver in the kernel in just several months. And it feels like ath9k connects a bit faster than madwifi. But it displays the wrong connection speed – the transfer rates are the same though.


Now that DRI2 was removed from the Xorg7.4 release, there is a lot of whining around why it was not released as is so that we have at least something working.

The first thing one has to understand, is that the current Xserver rendering architecture is horribly outdated; there was no work done to keep it up to date during the Xfree days and even when Xorg started, the primary goal was to uncouple the different parts to allow asynchronous releases.

So currently there is not one field where construction done but several. These are 2D Acceleration, Memory Management, 3D Acceleration and 2D Modesetting. And they are all being worked on at the same time to speed things up.

But the problem is that more or less all of these depend on proper Memory Management, which is also the hardest thing to get right.

Now lets look at how Xorg works today; every Xorg driver implements its own way of memory management and provides the DRI1 functionality when it comes to 3D. Furthermore it is responsible for modesetting, which is quite suboptimal, since some perliminary modesetting is already done in kernel, so it can output messages during bootup. The Xorg driver resets the hardware again when it is loaded.

Kernel Based Modesetting

In order to solve this duplication the modesetting code is about to be moved into the kernel, so the hardware can be setup once and for all. But since modesetting involves memory management which is not done properly yet too.

Memory Manager

The idea here is to share as much code between the drivers as possible and to provide a common API for the userspace. (the new memory manager will live inside the kernel) So a memory manager consits of an API, a shared part and a hardware specific part. The first proposal came in form of TTM from Tungsten Graphics. TTM had a quite complicated API which many developer also thought of as not being able to suit new graphics cards. The shared code part was already written and some drivers like noveau started to use it. But then Intel introduced GEM, which had a simpler API and suited modern graphics cards better. Although GEM currently contains only Intel specific code, developers started to pick it up. There is a branch of the ATI driver which provides a similar API to GEM. The bottom line here is that there is no stable API yet, but it will likely be more similiar to GEM then to TTM.

3D Acceleration

DRI2 is a restructuring of the direct rendering infrastructure which was needed in order to redirect direct rendering. Currently when an application wants to draw an OpenGL window, it does this directly to the framebuffer. With DRI2 it will be redirected to some offscreen memory so the Compositing Manager can do fancy things with the output. This obviously depends on a stable memory management API and thus had to be changed when GEM was introduced, because DRI2 was designed only after TTM in the first place.

2D Acceleration

in the 2D acceleration area EXA was set as the way to go. But then Intel again introduced UXA – this time it is nothing different. It provides the same API as EXA, but takes advantage of the new GEM Memory manager. It was just given a new name because much of the old code was ripped out. This work will be most likely be used by the other drivers too.

Hope this helps too clear things up a bit. As you can see, changing the Memory Manager means changing all the other stuff too. Therfore it is important to get it right in the first place.