Monthly Archives: November 2006

Linux Kernel 2.6.19 released

Some hours ago Linus Torvalds released the Kernel in version 2.6.19. A commented changelog can be read as usual at kernelnewbies – its the best source for information about the Linux kernel around.

Most interesting in this release are certainly the new file systems: Red Hat’s GFS2 found its way into the Kernel as well as EXT4, although EXT4 is only experimental. Also eCryptfs found its way into the Kernel, and I have to admit that I wasn’t aware of that file system – but it sounds very interesting: it is a GnuPG like encryption system for files inside of file systems. The files carry all information needed to decrypt them in a header so you can also transfer the data from one file system to another. Sounds like we will finally have file-based encryption in default Linux (ReiserFS4 can also perform file encryption), before there was only the option to encrypt complete partitions.

Besides the file system stuff this release made pretty clear that the Open Sound System is going to die in the mid term: several OSS drivers have been removed, and all people still using OSS drivers are supposed to switch to ALSA.
And with the continued effort of improving the new ATA driver system the old IDE drivers are also going to die. But that’s a slow process where only these drivers are deleted which has been replaced by better ones.

Last but not least Atmel’s AVR32 is now officially part of the Linux-Kernel. This is, btw. a typical example for what I call community: community does not necessarily mean that the people working for it are not employed: Atmel will support the new architecture because it is in their interest, and they will pay developers for that. And with contributing to Linux, they are part of the Linux community, independent from the fact if they do this for money in a corporate environment or not. The key is that both sides, corporate developers/companies and free developers/projects, work together and on the same level.

Hope that this kernel will find its way into Fedora pretty soon, would like to see how it performs and would also like to collect some experience playing around with ecryptfs. I would *love* to see transparent encryption in my KDE sessions. Well, or not see, you know what I mean ;)

The problem with 3rd party repositories

I am a big supporter of the idea of a common repository format for all software management tools around Linux. Because if there would additionally be an easy way to include and exclude standard 3rd party repositories they would eventually find their way into more corporate environments, and would maybe become the default way to update software in Linux environments – at the moment we already have repositories for skype and macromedia, but there are plenty of companies which do not provide repositories at all.

But: whenever you install software from someone else, you should be aware that this person can gain total control of your entire system. The same is with repositories where a person can easily insert software packages which update your system packages (as long as you don’t specify the packages). And that’s a big security risk!
So big that no one should ever enable any third party repository he or she doesn’t fully trust in!

A very good example of what can happen when you activate the wrong repository is the so called Treviño Story. A repository maintainer of a small Ubuntu development repository got in the situation that suddenly his repository was used by much to many people – and he decided to change the wallpaper to a warning.
In my opinion he did exactly the right thing: showing people that they have to start thinking, without harming their systems. He could have done worse things, like automatically deleting his entry in the sources.list or just transform all of these machines into zombies. And yes, the more favourite Linux becomes, the more problems we will see in the near future with captured and/or evil repositories.

One way to deal with such problems by the way would be to have two security mechanisms:
First one mechanism which makes it impossible for non-original repositories to replace a system package. And another mechanism which makes sure that non-original repositories are only allowed to install their stuff into /opt/ or anything like that.
These two options would make the machine more secure – not perfect, but at least better.

But before we can start thinking about that we need two things first: a common and widely accepted and used package format and a common and widely accepted repository format. Shouldn’t be so hard even from a realistic point of view, but unfortunately nothing happens in that area.

Binary firmware in Fedora

fedora-logo-bubbleI stumbled over this thread on the Fedora Extras list today which discussed the inclusion of Binary Firmware in Fedora Extras. I remembered only vaguely that there was something mentioned in the package guidelines, but it is there:


  • The files are non-executable (note: this means that the files cannot run on their own, not that they are just chmod -x)
  • The files are not libraries.
  • The files are standalone, not embedded in executable or library code.
  • Explicit permission is given by the owner to freely distribute without restrictions (this permission must be included, in “writing”, with the files in the packaging)
  • The files must be necessary for the functionality of open source code being included in Fedora.

Sure, these requirements are hard, therefore not too many firmware will find its way into Fedora – on the other hand it makes it at least possible in theory, and therefore puts a bit of pressure to release the firmware under licence terms which meet these requirements.

If it makes sense to include binary firmware blobs in such a way? Sure, they do not meet the criteria of truly Free Software, because there is code you cannot look into and which cannot be reproduced.
On the other hand the code is not allowed to be stuff like a program or libraries – the rules are clear there, and you have at least to respect that when you talk about Free Software which is indeed about program or library code.

In any case it was surprising when I read it now again.


cube-with-matrixSome minutes ago I read the announcement about the newest Compiz release.
Seems to have some very nice improvements, like a as-good-as-possible fix for multi-head setups, and there is also support for multiple desktops now, but I’m a bit unsure what that is. There are also some new and also updated plugins – the changelog is quite short, have a look for yourself.

But while I read this announcement on the list I started thinking again about the “Beryl vs Compiz” discussion which started when Beryl finally forked away from Compiz. There was an interview with David Revemann, the man behind Compiz. Ted Haeger asked him several questions and tried to show David’s point of view while the media mostly covered the statement of the Beryl people.
The interview was quite interesting and covered quite some information I wasn’t aware of, like the fact that Compiz isn’t hardcoded against GNOME with its configuration done through gconf but has a plugin structure where you can exchange the GNOME stuff against some KDE stuff (or Xfce, or whatever you prefer).

But one of the things that wasn’t covered by the interview but I saw around very often as a reason for Beryl was the involvement of the community. One of the main reasons why Beryl was able to fork very successful and take over most of the Compiz users in one step was the fact that Beryl provided all that stuff a normal user needs: a forum, HowTos, fancy plugins in masses and a cool looking configuration tool. Sure, from a technical point of view this isn’t important, the second one might even be a bit dangerous stability-wise. But still, if you want users, feed the community!
And that’s what David and the Compiz team never did – that is a terrible mistake I think.

And today, when I read the announcement, I realized that nothing has changed. The Compiz team still didn’t learn a bit: if you announce a new version of your application, especially when it comes with some new features, you should send it to a place where normal users look at: a forum, a wiki or a blog. But not on only to an e-mail list for developers.
Its a bid sad somehow that the Compiz folk didn’t learn anything from the fork. If the distributions are going to switch over to Beryl than Compiz will be left with nothing – in case of Beryl there is a huge community which provides help how to set up Beryl for each distribution, providing help and all that stuff.
Compiz does not has anything comparable.

If I was at David’s place I would just launch a form, a wiki and a page to upload and rate new plugins – I think the community would form alone around that stuff. And as long as David would blog/post about his development and answer the most pressing questions once in a while everything would be fine. That’s not too hard…

Btw., talking about Beryl: after Fedora Extras included Beryl and the link from the Beryl wiki to my howto became obsolete and therefore was deleted the number of visitors of my blog dropped by more than 65 % … well, that’s life ;)

Beryl part of Fedora Extras now

fedora-logo-bubbleThanks to Jarod Wilson Beryl is now part of Fedora Extras and can therefore be installed without any additional configuration – just fire up yum or Pirut, and install beryl-gnome or beryl-kde, depending on what desktop environment you prefer.

Also, the packages which has been included come along with two nice extras:

  • The package aquamarine can be used as a window manager inside of beryl. It will use the window themes you chosen in the normal KDE control center.
  • heliodor supports Metacity themes and is therefore a drop in replacement for the GNOME users.

There might be more in the future.

However, due to the fact that it is now very easy to install Beryl on Fedora there is no need for my HowTo anymore – I rewrote that part in the Beryl Wiki. No ore link there pointin at my blog, I can already see it in my stats ;)

And, just as a side note: KWin, the KDE window manager, got more features these days. Most interesting part is however that it works even with drivers which do not support “texture from pixmap” – like the fglrx-ATI drivers. I wasn’t aware that you can create a composition manager without TFP – I never stop learning.