KDE 4.0 Beta 1

KDE 4.0 Beta 1 will be released soon. This means that the feature freeze hits KDE 4.0, and the development team will focus on bug fixing.

Among other news the last Commit Digest noticed that KDE 4.0 Beta 1 was tagged. I expect the official release of KDE 4.0 Beta 1 very soon.
And this means feature freeze – no more features and of course no more applications will be added. However, since this is KDE 4.0 the rules are not as strict as someone might expect from a Beta release:

it is still
fine to change the API to

make porting from KDE3 applications easier

fix major (!) API glitches that cannot be fixed in a binary compatible way later

remove parts from the public API that is intended to be added at a later point in the KDE 4.1 release cycle as public API again, when it was matured and fixed.

Basically the rules give the freedom to still change things which are really necessary but ask you to not change if it requires major efforts by others or if it is unnecessary.
A good example in this regard is Ark, KDE’s tool for compressed files and archives: it was reworked lately, but the rework started to late, and the old version in SVN was broken. Therefore, the maintainer of the new version deleted the old version and mentioned that he will continue development and will incorporate Ark again in KDE 4.1:

This version was basically very bug ridden and not maintainable.
I have a rewrite almost ready in a branch, which will go back here when ready. Unfortunately, this will only happen for KDE 4.1, as the feature freeze is today and my code is not ready for it just yet.

however, this would have meant that KDE 4.0 would ship without a handler for compressed archives which would be odd. Therefore the release team mentioned that they could be flexible:

We’re not intransigent. I think we can let you bring it back, as long as you do it soon.

But in general KDE 4.0 Beta 1 will mean that most really new things have to happen outside of the next KDE release. An example for that are animations in the new Oxygen style: the mentioned rewrite is going on and will be ready in time, but without animations. These were to resource intensive and were delayed till KDE 4.1 because there is simply not enough time yet.
Also some new plasmoids which are written in C++ might not make it into the main KDE tree, but these could also be released as an KDE Extragear package.

Speaking about Plasmoids: I’m really wondering where the kicker replacement is. At the moment KDE 4 SVN still has kicker activated, and I really hope it will die pretty soon! If kicker stays for any time longer it has to be supported over the entire KDE 4 life cycle which would be pretty bad, I think. And I certainly don’t want to continue to use kicker, not after Aaron Seigo said so much bad things bout it
But to replace it there are quite some components missing: a systray, the taskbar (a first try is available in this case) and an application launcher. Also the menu must be ready.
However, the Plasma people haven’t disappointed so far, quite the opposite is the case, so I’m confident we will see something nice quite soon.

As a last note, speaking about a new bar and design in general: this blog post features some very impressive mockups worth a look. However, I’m not sure which state or aim these mockups reflect. Also, some of the mockups have been removed because they created too high expectations, so see them as an example of what KDE artists can dream of and can imagine, not of something you will see in KDE 4.0!

Short Tip: Determine current shell

To figure out the current shell you’re using, like bash, zsh or sh, just call echo $SHELL:

ps -p $$ | tail -1 | awk '{print $NF}'

Pretty helpful if you’re playing with different shells at the same time.

New Category: Short Tip

I just added a new category to this blog, “Short Tip”. In future it will be used for the really small but sometimes helpful things.

Usually I only cover stuff in this blog which is worth writing an entire article. But sometimes I come across small but very helpful tips or workarounds I would like to write down here to not forget them, but which are not long enough for an entire article. In the future these will be covered by the category Short Tip.

As you might have noticed all my articles follow a specific layout: there is the short summarize written in italic on top and flanked by a topic related image, and the rest of the article is sometimes parted by sub-headlines. And of course there is a lot of text.
And since i (quietly) introduced this new layout I’m quite pleased with it, however it makes it almost impossible to write really short things like the key bindings information. But this blog is, among other things, a place for me to remember important or useful or helpful information. Therefore I was wondering how to bring these together: layout on the one hand, short information on the other hand.

And I will take the direct way: tips won’t be written in the layout, they will just appear without anything else. Maybe I’ll keep the picture, but I’m not sure yet about that.

And if you just wonder why I do care so much about that topic and the style of writing: it is just too late for me

Podcast with Chris Mason on Btrfs

Oracle’s TechCast crew interviewed Chris Mason on Btrfs.

The Podcast (MP3) about the new file system is roughly 10 minutes long and speaks about the aims of Btrfs, the planned features and the adoption in the community.

Unfortunately there is no transcript of the record (am I really the only one who dislikes podcasts and would prefer written interviews?), but here are the most notable comments and quotes I was able to write down (in no particular order):

Btrfs is explicitly designed to replace ext3 – current file systems for Linux are identified as not sufficient for today’s needs. Because, while it is easy to make a file system that addresses a large disk it is difficult to make a file system that really manages such large amounts of data: disk or data errors have to be handled, consistency checks must be possible, and it should be possible to add and remove drives.
All these things take too long time or are simply impossible with ext3 or other typical Linux file systems. And Chris isn’t alone with this statement – other kernel developers like Andrew Morton agree here and see the need for a better file system.

As a result of this situation the design of Btrfs is unlike the old UFS type file systems which most file systems for Linux follow, but takes a new approach. In this regard it has similarities with ZFS which was designed in the same time frame. For the same reason both have a comparable set of features, btw.
However, Chris keeps the typical Linux file systems in mind while developing Btrfs: he aims to compete “with ext3 in terms of excellent usage for mid range server workloads” and with XFS for its capabilities “to scale and address large amounts of storage”.

The features of the new file system were also outlined: snapshots, online file system checker, online defragmentation and resizing, object level striping and mirroring (so you have duplicates on the disk of critical files), validating and compression of the entire file system.
This list isn’t new but it is good to hear that it hasn’t changed that much since the first announcement.

Anyway, the snapshot part was explained in more details:
It is not that taking snapshots is a feature which was added later on, but it is the basic principle of the file system: “everything is basically a snapshot, every transaction is a snapshot that is just quickly removed when the transaction is over”. Snapshots can also be snapshotted again later on. So you can take a snapshot and turn in into a real part of your file system later on.
Chris summed up these points in a single phrase which hits the mark:

snapshot is [...] a first class citizen in the file system

I’m really looking forward to Btrfs since I could use some snapshot support in Linux. Especially in case of backups this can come in handy, and I also would like to have something similar to Window’s shadow copies.
However, one thought struck me this evening: everyone talks these days about ZFS like file systems – what happened to the ideas of creating database like file systems? Did this idea die out?

Decibel: first real world usage with kcall, but what is about kopete?

basysKom announced that their SIP program kcall has been ported to Decibel, making it the first real world application actually using Decibel. But there are still no information available about the state of kopete.

Decibel was developed to provide a central interface for real time communication in KDE 4. The idea is that on the one hand users will be able to manage everything in one place while on the other hand developers can use the APIs provided by Decibel to integrate their program fully with this central place.
Technically Decibel uses the Tapioca which in turn implements the Telepathy specifications. This by the way should make it quite easy to share resources with other Telepathy implementations like they are planned for Gnome.

So Decibel is the Phonon for VoIP and IM. And like Phonon it would be worthless without a real application using it. To do that kcall, a kontact integrated SIP solution, was is ported to Decibel. This is good to see because it gives the Decibel developers feedback about API quality and application needs. Also, after the port kcall will be more than a SIP application – it will be even able to remote control snom telephones making it a real telephony application.

However, the most often used IM application on KDE is kopete. And the idea behind Decibel was that applications just like kopete switch over to use Decibel to be able to concentrate on the app only instead of implementing yet another protocol.
But there seem to be problems. First of all, Decibel won’t be ready for KDE 4.0, but for KDE 4.1:

I rather doubt that we will meet the KDE4.0 deadlines (is it even possible to still add apps to that release at this point?), but I am positive that we can get into KDE 4.1.

Second, kopete itself won’t be ready for KDE 4.0 as it looks like.

On the other there is the techbase entry about kopete which has been written by Mlarouche, the lead developer of kopete. The page sets the aim of a 4.0 release and lists several features. Decibel is supposed to be integrated as a plugin for 4.0 and fully supported as the main backend for 4.1.

So at the moment the situation around kopete is still unclear. I would like to see a version ready for KDE 4.0, but not necessarily as a part of kdenetwork but maybe as part of extragear. Amarok and others have a healthy live there, and I think kopete could benefit in similar ways. But that’s up to the developers.