Monthly Archives: October 2007

PackageKit: new backends and discussed at Ubuntu conference

Tux
PackageKit gains more and more attention these days: with Pisi and Smart two new backends have been added and PackageKit was discussed at an Ubuntu conference as a possible default package manager.

Richard Hugehes’ PackageKit – a tool for unified package and software management on Linux regardless of the distribution’s backend – was first introduced around July/August this year. Since that it gained an unbelievable development speed and was improved on an almost daily rhythm.

New Backends

Two weeks ago PackageKit released 0.1 version and marked the API as stable. More and more distributions now realize that PackageKit can indeed become what everyone hoped for and start implementing support for the various backends. The last two added backends add support for Smart and Pardus’ PiSi.
The backend matrix currently looks like this:

PackageKit features and backends matrix
conary yum apt box alpm Smart PiSi
resolve X X X X
refresh-cache X X X X X X
get-updates X X X X X
update-system X X X X X
search-name X X X X X X X
search-details X X X
search-file X X
search-group
install-package X X X X X X
install-file X X X
remove-package X X X X X X
update-package X X X X X X
get-depends X X X
get-requires X X X
get-description X X X X X X
get-update-detail
get-repo-list X X X X X
repo-enable X X X
repo-set-data X
cancel-transaction X

Keep in mind that PackageKit was first development for yum and apt. Nowadays other backends are even better supported than yum. In a far future this might even lead to a situation where the backend is developed with the needs and possiblities of PackageKit in the mind. I doubt that any backend developer would like to have the least supported backend if PackageKit gets really wide spread.

PackageKit at Ubuntu conference

PackageKit was also discussed at a recent Ubuntu conference:

The result of this general enthusiasm is that Canonical will likely move forward with the adoption of PackageKit in the near future, although they will need some time to make some adjustments to their own packages first. For example, PackageKit does not permit interactive questions (like agreeing to licenses) during the installation process; dpkg does. As a result, the few remaining .deb’s that still require interactive feedback during install will have to be adjusted to be non-interactive.

The same report also mentions that PackageKit is now widely accepted by rPath distributions. Congrats, PackageKit.

But this discussion also shows the problem between powerful backends and the real world: while it is an interesting feature to have a package/software manager with an interactive mode it is just a feature which is usable by real power users. Normal users cannot answer interactive questions of any kind (maybe licence questions, but that’s it) and therefore distributions which have regular users in their mind should not offer that possibility.
For the same reason PackageKit should not include support for it – it would spoil the entire idea of making the package management easy.

At the moment it looks like PackageKit is the new shining star in the Linux world when it comes to package management. At the moments there are only three things missing to have world domination for it: a zypper backend for OpenSuse, an urpmi backend for Mandriva and a KDE GUI.

Apple’s Leopard understands ODF

documents.png
Apple released the newest incarnation of it’s operating system, Leopard. While many news sites cover the shiny improvements most of them fail to mention that Apple made a small but important step towards open standards: Leopard will be able to read OASIS’ ODF.

For unknown reasons Apple is battling at two fronts at the same time: while it tries to get some market share from Windows it at the same time does everything to hold down open standards of any form. This includes network protocols, audio and video formats, document file formats and so on. Apple’s programs all have their own formats and only support some other really wide spread de-facto-standards – if at all. In this behaviour – which sometimes even take a ridiculous form – Apple is worse than Microsoft.

However, Apple made now a first, tiny step towards Open Standards in the document format area: with Leopard Apple will be able to at least view ODF files:

UNIX® Certification
Mac OS X is now a fully certified UNIX operating system, conforming to both the Single UNIX Specification (SUSv3) and POSIX 1003.1. Deploy Leopard in environments that demand full UNIX conformance and enjoy expanded support for open standards popular in the UNIX community such as the OASIS Open Document Format (ODF) or ECMA’s Office XML.

The fact however that Apple mentions ECMA’s Office XML as a UNIX standard is a bit confusing. I wonder if that is on purpose or if someone at Apple’s just wasn’t sure what he/she was talking about. Anyway, it is an improvement and it shows that even Apple cannot stand the pressure.

Of course, Apple could for once try to actually work together with the open parts of the world and drop their strange behaviour, but that is as unlikely as Microsoft dropping their XML format.
But still, this small step shows that even Apple actually *can* grow up in parts. Maybe one of the next versions of Apple’s office suite will come along with a plugin for ODF export or import. The pressure on Microsoft is tough, and if Apple wants to hold it’s share in the education sector it has to change it’s rather childish strategy.

KDE 4 Beta Videos

kde-logo-official
Jos Poortvliet has produced a set of videos showing some features fo the upcoming KDE 4. Until now the featured applications are some games, KTouch, Kalzium and Gwenview.

The Videos

Jos Poortvliet produced these videos running KDE 4 apps inside of a KDE 3 session. The KDE 4 session is a recent SVN checkout and therefore has some additional features compared to the rencetly released KDE 4 Beta 3.

The videos themselves are of average quality due to the flash-based hosting but still give a good impression of the feature richness and quality of the new KDE 4. And videos are just better than static images.

At the moment there are 7 new videos at Jos’ youtube page but chances are that he will upload more of them in the near future. Four of the videos show the KDE 4 games KMines, KMajongg, KAtomic and KSudoku:

Two other videos present the development in the educational areay, KTouch and Kalzium:

The last video presents the new features of Gwenview, KDE 4’s default image viewer. Compared to the KDE 3.x version Gwenview is now able to also crop images and has a subtle but clear way to inform the user that there are still unsaved changes.

Thanks to Jos for uploading these short videos and the permission to publish them here, it is a great way to show how KDE 4 shapes up.

Why so many Games and Educational Apps?

Some people might wonder why the focus is on educational apps and games while KDE 4 will have so much more to offer. There are several reasons:
First, other stuff like Plasma was already covered several times by others. There is no need to cover it yet again as long as there are no new features because everyone already knows it.
Second, many of the new features of KDE 4 are behind the scenes – Solid, Phonon, Qt4 are difficult to show because these improvements are about design and capabilites, not actual features.

And third, and that is connected to second, to show what KDE 4 can be capable of the best is to show the applications which use these new capabilities and implement new features using them. And as in real world this is best done with games because these are the applications which take frameworks and APIs (and often hardware, btw.) to their edges and beyond.
In a file manager it would be too distrcting if it would use all the blink which is possible now – in a game that is exactly what the users want to see.

Browser Wars – Reloaded

kde-logo-official
The dispute over WebKit and KHTML reached a new peak today. With Harri Porten yesterday a KHTML supporter already pubslished his position on the subject and today Zack Rusin, a WebKit supporter, answered.

The Background

WebKit was originally forked from KHTML by Apple (more details at WebKit’s Wikipedia entry). Today it the developmnet is still backed by Apple but supported by other groups as well: Nokia, Adobe, Trolltech, some Gnome guys – and several KDE developers.
Soon after WebKit went public it was questioned if the resources of WebKit and KHTML could not be bundled to benefit both. This didn’t work out totally. Some KDE developers decided to help WebKit, some stayed with KHTML.
In the meantime WebKit became more and more famous and spread: Adobe adopted it, Nokia adopted it, Trolltech will adopt it, it is the standard browser on recent Mac OS releases and was as such even ported to Windows. Therefore WebKit became even recognized by web designers and developers.

So nowadays there is the quite open WebKit development project which is not controlled by KDE at all (but up to a certain degree by Apple) but has a nice set of features. On the other hand there is the KHTML project which is fully controlled by KDE, works nice, but still lacks several features. Especially stuff like missing support for WYSIWIG rich text editors in web applications (WordPress editor, CMS systems, etc.) is a pressing issue for several users.

As a result many users still ask what the situation around WebKit and KHTML is.

KHTML’s FAQ

The KHTML supporters team never bothered with marketing. In fact there are not even many blog posts or anything else at all about KHTML from their point of view. This became a problem recently when the KHTML supporters realized that they had no voice for the users outside of the community and that they had no way to answer many of the existing questions.
As a reaction Harri Porten published a “KHTML FAQ” yesterday on behalf of the KHTML supporters. The FAQ picks up the most important points of the discussion and highlights the stand of the KHTML fraction.
In short it can be said that they would like to work together with the WebKit project – if they get certain rights. This is understandable since the KDE project has its own needs and wishes and the KHTML team wishes to work according to these just as it did in the past.

However, the FAQ fails to explain what the WebKit project actually responded to these wishes and needs. Since the WebKit project often highlighted that they welcome other developers the question is what the outcome of current discussions and talks which issues are blocking what.

Zack Rusin’s response

One of the most famous WebKit supporters is Zack Rusin who worked for Trolltech for years. He got reviewer rights in the WebKit project quite some time ago. And he posted a response to the FAQ.
In short it can be said that Zack was pissed of by certain assumptions in the KHTML FAQ: Zack points out that many former KHTML developers simply switched over to WebKit and that they still can be seen as “KHTML developers”. He also highlights that even the founder of KHTML is a strong WebKit supporter, and that in general more KDE people contribute to WebKit than to KHTML.

However, he also does not address the real reason or problem why both projects simply do not work together. The question remains what the most blocking reasons are.

Future Development

The discussion boiled up now and will certainly stay on the radar for some time. After all, this is a discussion and an argument between software developers which are emotionally involved with their software.

There are now two solutions: one would be to let a third party step in to settle the conflict. The KDE e.V. comes to the mind: one of the tasks of the KDE e.V. is to settle major problems between developers and technology. The KDE e.V. is also “official” enough to start talks with Apple (if they want to listen). This would be the political solution.

The other solution is the more Open Source one: the one who codes decides. If there will be a WebKit kpart, then the distributions will include it. Then users will decide on their own which engine they use. In the end, the users will decide.
Or it could happen that a developer starts with a WebKit KDE browser on his/her own. If that one works well and is well integrated with KDE it might even happen that most people switch over to that one. As an example, the developer momesana has already developed an own WebKit browser:

Momesana Browser - Google main page

Momesana Browser - Overview

Momesana also published a video (Ogg, 8.8 MB) showing the “Momesana Browser” at work and performing quite nice.

Third Linux Desktop Survey Announced

Tux
The Linux Foundation has announced it’s third annual Linux Desktop Survey. The Linux Foundation asks Companies, Institutions and individuals to take part in this survey to pinpoint user needs to focus the development in the Linux ecosystem.

The Linux Desktop Survey has already taken part 2005 (PDF, 340 kb) and 2006 (PDF, 870 kb) and is this year again offered by the Linux Desktop Workgroup of the Linux Foundation.

The idea of the surveys is to pinpoint the user needs in the Linux ecosystem and top focus the development more according to the needs of the userbase. Jim Zemlin, executive director at The Linux Foundation, said:

Past Linux Desktop Surveys allow us to capture the pulse of user need, which we can then use to guide our efforts.
[...]
These surveys also provide useful feedback to developers and vendors who are working on improving the Linux desktop. We expect this survey to continue this progress and look forward to hearing from Linux desktop users everywhere.

The survey itself does only take a couple of minutes and is available in several languages. But although the announcement says the survey also targets at individuals the entire survey is designed to be answered by people working as IT people in a company. There are hardly any questions targetted at private persons or even at people who work in a company without a deeper knowledge of the background IT. It would have been more productive to split the survey into one for private people with answers about the private live and the workplace and into another for IT system administrators who have detailed knowledge about the needs of the company/department they are working for.
Nevertheless the survey is the right step to gather more information about the otherwise quite unknown Linux userbase.