Impressions around KDE 4 development

The last days were quite interesting regarding KDE 4 development: Aaron released a screenshot showing the new Alt+F2 application launcher with translucency abilities and linked a public relations (or sometimes called propaganda) document introducing Oxygen to “normal” people.
Btw. these screenshots were not the last one – Aaron said he plans to release new screenshots every Wednesday. We now have different days dedicated to different topics: a screenshot Wednesday, kdelibs Monday, Wiki Friday, SVN commit digest Sunday, and so on. I like that because now I have something special every day concerning KDE
Ha, I wonder if there will be a svn commit digest on sunday!

The only negative thing happened these days was – yet again – a stupid post released by osnews.com. This time it was editor/author Thom Holwerda and it was again some “Linux is dead” rant. I have to admit that I’m getting tired of this crap constantly released by osnews. If it were solid analysis it would be at least interesting to read, but in the last cases I’ve read (like this one) it looked like the author did not even bother to read into the material. For example Thom should better check how much Plasma code was actually released and in which state Phonon really is before claiming that there is nothing but death.
Anyway, osnews have lost quality in huge steps in the last weeks and months and I wonder if they will ever find back to a former shape.

Hm, I really need a decent computer to get back into KDE 4 compiling – my laptop is needed for work and it will probably melt through the table when I start compiling such an amount of code. On the other hand I do not really have a machine capable of compiling and testing a KDE 4 version on – for example a decent Intel or ATI card would be nice for the graphic effects. Also a dual core system would be cool to have faster compiles.
Hm, that reminds me that I have to be help desk (student job) at a place were they got entirely new Dual Core systems… and all are running Windows XP, and they mostly use these machines for E-Mail and Office stuff. So much wasted power makes me sigh. That, again, reminds me of a computer pool I heard of where they used Colinux installations to use the extra CPU power of the windows machines. Sounds like a pretty good idea.

New Fedora Core 7 plan

Bill Nottingham from Red Hat released a new plan for Fedora 7 that summarizes the most important topics. And again, I know exactly why I use Fedora: because Fedora is an evolving distribution dedicated to new technology and to good technology.

For example, the plan lists two topics dedicated to the init system: “10. Boot and shutdown speedup” is all about making the current init system a better place and providing a faster and better experience, while “11. Init system work” is about researching a replacement for init. Also the second topic will not bring any new code into Fedora 7 it will (hopefully) create the basis for a init replacement in Fedora 8. That could be Ubuntu’s upstart, btw.
Also the team plans to port Randr 1.2 back to X.Org 7.2 – that would mean that we get full monitor plug&play in X!
Other targets are a better integration of encrypted file systems, the integration of a real time kernel and “8. Rock Solid Wireless” which means in this case out-of-the-box support for all cards and all methods (WEP and WPA).

For me that is what Fedora is about: providing new technology, introducing this new technology to the Open Source community and showing what is possible. As you can see other distributions normally follow (NetworkManager, AIGLX, SELinux, ..) which is by the way one of the big, big advantages of the distribution model.

But of course there are also Fedora specific topics mentioned in this new plan: we will see different releases of Fedora 7 (Server, Gnome, KDE), the merge of the extras and the core build system to one rule-them-all build system, an improvement of the speed of yum/rpm and various other things.

Looks exciting – and I already look out for Fedora 8 and a possible init replacement – Ubuntu, come on, we need a good example here to convince our developers. Integrate upstart fully into Ubuntu and show that it is worth integrating it into Fedora!

Additional thoughts about software installation

After Ian now unveiled the FSG plans to make software installation easier several people commented on these plans – and as usual there were thousands of other ideas. This is a community, after tall. Nevertheless I hope that there is now the foundation for a solution to the current problems, and I hope at least the most important people will help to deliver this as a real solution.

But there were some interesting comments I would like to mention here. First of all there was a link posted to Bitrock. The Bitrock guys provide a GUI tool to create installer packages for Linux and other platforms which can also be integrated with the rpm database. It is, however, a proprietary solution, but that doesn’t matter so much for an ISV. I’m not entirely sure how it works and where the disadvantages are, but it sounds pretty interesting and, that’s probably most interesting, very easy to use for developers.
The attempt reminds a bit of Autopackage (although autopackage cannot talk to the rpm database).

Also klik was mentioned several times, mostly due to the strong sense of mission of its developers. It is a technically very interesting solution, but you get maybe a bit irritated by the religion like way of how the developers advertise it The main disadvantages are the fact that klik is also not able to talk to the package system and that it is designed to not really intereact with the base system – this does not make sense for software like server apps, daemons, services, or everything which needs specific configuration or simple file type association. Also I do not think that it is a realistic way to have – again – a central repository for pacakges, this time *.cmg. It also does not address the problem of software on a CD or distributed only to people who pay thousands of euros. Still, the attempt of one file per application is tempting and could be a nice way for providing easy and small apps. Also, klik is still in heavy development, and there is enough room for improvements yet.

But there was another thought mentioned in the comments which got me: we all compare Linux to Windows or Macs, and see: Windows and Mac have an easy way to deliver software, Linux does not. At least Windows is spread pretty much, and Mac does not suffer from that problem, too.
But well, there is another point of view: there are several other platforms which have a pretty clear way of installing software. They do not suffer this problem – but they are not as spread as Windows. This thought got me because it shows that not everything depends on this problem, and that even the best imaginable solution (installing software by just thinking of it) would not make Linux magically the better platform – there are many other fields were Linux is having problems, but other were Linux is pretty good.

I just have to remind my self of that point of view because at the moment I tend to think that the software installation part is the one and only problem left and that without this problem Linux would start off. I wonder if there are other things were other platforms have solved specific problems Linux still have…

Ian Murdock about Software Installation on Linux – Part two

Ian Murdock posted part two of the analysis of Linux Software installation issue done at the FSG package summit. It doesn’t make sense to repeat anything he has written, but I do want to discuss some core points.

First of all: the analysis came to the conclusion that we need an evolutionary process to solve the problem. While it is tempting to throw in something entirely new the main problem is that is not clear at all when the main distributions would pick this up:

No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right.

This can be reached by implementing an API to the underlying package system – something which was already mentioned by Michael Leibowiz. The API itself should be as simple as possible because normally the ISVs don’t need to have all the flexibility of RPM or deb/dpkg. But they do need a way to tell the system which kinds of files they have included, and they need a way to query which LSB version is supported by the underlying system. Interesting here is that the analysis says that we do not have to worry about dependencies:

Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with.

I wouldn’t have thought that, but since the people who made this analysis know quite well what they are talking about I guess they are right here. Also, the API could be dependency agnostic in the first version – and if it would be adopted pretty quickly we could think about extending the API.
Most important is that we get something working which is accepted and works and is used in reality.

To address these problems further and continue to develop a solution in this field a new group was founded: the LSB packaging group. Also an e-mail list was revived.

I cross my fingers that this is the beginning of something new to solve this problem. I really do.

Digikam 0.9

After more than a year digikam 0.9 has finally been released. It was developed for more than a year and comes with an impressive list of new features and closed bugs. The most important new features are:

• 16 bit Colormanagement workflow
• Raw file support
• GPS/EXIF/IPTC metadata support

Especially interesting here is that the 16bit workflow means that all used tools can handle 16bit images – something not every other image program for Linux can do.

You can find more about the features here. There are also training videos available.

One thing however about the user interface: digikam is made for people who are really willing to read about the subject. It is aimed at more professional users. Keep this in mind – if you just want a album program to occasionally view your images, you should check for another program.
But I do agree that the GUI of digikam could need some work – I think the usability guys could help here, improving the layout maybe. But I will use it anyway because I am a pro user who does not really care for the GUI as long as it is functional enough.