rojtberg.net

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.

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.

as you probably noticed, the domain changed from madman2k.net to rojtberg.net. Please update your bookmarks as the old domain will expire soon.

on the legacy version of the web-page I had a quite popular article called Gnome prospects, where one could find some of the recent developments of the Gnome community.

Now that everyone talks about stagnation inside the Gnome project and how GTK3 should look like I think reviving that article is a good way to participate in that talk. 🙂

read on…

there were several problems with the last release of YouAmp, since I have not tested the upgrade path at all. The app simply crashed if you had an older version installed beforehand, but thankfully I managed to fix them by now, so you can safely upgrade.

The next release wont get that many architectural changes but is going to be localized, and here is where you can help; if you want YouAmp translated in your language, grab this messages.pot file and put the translations of the lines beginning with msgid on the lines beneath beginning with msgstr.

But please check the repository beforehand to be sure that the translation is not there yet. You can send me the translations via email (check the About section).

Basically I already wrote on the topic even before the thread on Planet Gnome started, but I would like to add a few things in that context.

Basically I also think that the way for Gnome from now on is to evolving rather than rewriting stuff for Gnome 3.0.

But in order to be able to evolve reasonable, one has to mutate first. And mutating is hard being Gnome – to catch up my former post – since Gnome is written in C.

In order to explore new concepts of usability, one need prototyping, but writing a prototype from scratch is hard and also unnecessary, since we already have applications for that task. So the straightforward thing would be to create a fork for experimenting and change the structure as necessary.

And here is where where Gnome fails; changing a python program is very easy since the language suits RAD very well, while hacking away in C is hardly possible.

That is also the reason why all the promising things are written in dynamic languages; GnomeDo is C#, Gimmie is Python, only AWN is C, but most of its Plugins are Python.

Now imagine Nautilus would have been written in Python – how easy would it be to hack away a version solely relying on Tracker for file organisation. I definatly think we would see much more innovative stuff here.