TUX Magazine: Interview with Daniel Molkentin, Klik Explained

In its current issue, TUX Magazine interviews KDE core developer Daniel Molkentin. Daniel talks about the features in the just-released KDE 3.5 and explains the current plans and ongoing efforts for the next major KDE release, KDE 4.0. In the same issue, KDE's Jess Hall explains how Klik makes trying and using new applications easy.


it is pretty unusual to offer a magazine in the 'net for free, and still ask for an a priori registration.

this smells fishy.

are them publishers then spamming my mailbox with advertisements praising arbitrary payware in return? are them address collectors harvesting my email address in exchange for a few cent?

above, the title page of that thingie looks much too polished to be true. i've yet to see a software running on linux that would be able to create such a layout. i could imagine that they use adobe indesign or quark express on windows or mac to produce it.

so what was the point of "tux" magazine, again?

By noobie at Fri, 2005/12/02 - 6:00am

They could be using Scribus, or many other programs. I don't believe I've gotten any spam from them (I generally make up an address at my website for each place I register, like [email protected]).

They apparently offer advertising in their magazine which is probably how they make their money. I really doubt they get enough subscribers to be able to sell them to spammers.

By Corbin at Fri, 2005/12/02 - 6:00am

it's done by the same people who do linux mag (or at least i hope i got the right publication.. i'm always mixing up those publications as they all have such similar names).

they are giving it away for free and keeping the publication costs low specifically to help promote and grow the open source desktop market while having a sustainable publication (ergo why it isn't on paper)

registration is a pretty low cost and i haven't gotten a single piece of spam due to it myself.

as for open source software that can do layouts that good, one would obviously point to scribus which fits the bill. however, i'd bet that they use more "traditional" tools since they are part of a larger and older publishing house.

for me the point of tux mag is to get nice user-level articles that average computer using people utilizing linux at home or in the SOHO would actually be interested in. that means being gui-centric and not much about writing software or the latest amazing enterprise server stuff.

less SAN, more iPod

By Aaron J. Seigo at Fri, 2005/12/02 - 6:00am

Its done by the same people that do Linux Journal & Linux Gazette (it says on the bottom of the site).

By Corbin at Fri, 2005/12/02 - 6:00am

Corbin, Aaron J.:

thanks for your replies. they clarified a few bits. even makes me confident to register my email there now. see, how I trust your testimonials? ;-)

By noobie at Fri, 2005/12/02 - 6:00am

It looks like it was made in a Dreamweaver template. you can run dreamweaver through crossover office, or one wine if you tweak the wine.conf and know which dll's to use. So it could have still be developed in linux on a windows application.


By JOe at Sun, 2005/12/04 - 6:00am

There are logins available at bugmenot (use the wonderful firefox plugin)

By Vicks at Sun, 2005/12/04 - 6:00am

you could use just about anything to create that layouy - it's just a case of how easy it would be

By mabinogi at Wed, 2005/12/07 - 6:00am

... _that_ is the question _I_ ask myself.

After all, there is .rpm, .deb, .tar.gz, Autopackage, ZeroInstall, Gobo Linux and some more in the One Big Linux World. How do they differ from klik?

I'm pretty new to Linux (coming from a Windows programming background), and I've been looking at Linux packaging formats since early summer because my boss told me to prepare to lead a new software project next spring that is supposed to also offer value to Linux customers.

I read the klik FAQ linked above, but didn't grok it all. The FAQ avoids the comparison with the other formats.

Adding Linux to your supported platforms if you are an ISV is a pretty non-profitable business, if you ask me!

By heh at Fri, 2005/12/02 - 6:00am

From the FAQ:
Is klik a new alternative package management system?
No. klik does neither replace, nor interfere with your system's package manager.

What good is klik then for?
klik is good for letting you test bleeding edge software releases and development versions, or use packages that are not available for your distro (or only in outdated versions). Once you start to use and like klik, you will probably find many more use cases on your own.

By Morty at Fri, 2005/12/02 - 6:00am

Alrighty then.

But why can't I test bleeding edge releases and development version with one of the other package formats?

Why can't there be just _ONE_ package format??

By heh at Fri, 2005/12/02 - 6:00am

Let me add a thing or two.

Don't get me wrong: I do not want to impose one package format, one window manager, one distribution onto this movement. I am aware that you love the freedom of choice this gives to you, and the freedom to experiment and research. I must admit that I am even attracted to this, your Freedom, as a person. I find it more and more fascinating.

But I also try to figure how to make a successful business based on Linux software development. The more I let myself be entangled by the fascinating sites of Linux, the less I think about business. I spend a day or two diving into some technical problem or learning a new lesson about this OS, forgetting the world around me... then some days later I awake with the sobering question in my mind "And how do we earn our livings with it?" Happened not only once to me in the last 5-6 months.

By heh at Fri, 2005/12/02 - 6:00am

>how to make a successful business based on Linux software development.

That's a big question isn't it! The best way to answer it is to use some of your skills learned as a software developer, start with dividing the problem into manageable parts. If you remove the "Linux" from your question, you still have the hardest part of the question left. Linux does not change that bit, and it's no problem delivering proprietary solutions on Linux the same way you do on other platforms. Several companies do so successfully.

But on Linux you also have the opportunities and competition that is FLOSS. Making it perhaps little harder to get a good business model, but not much. Direct competition with FLOSS will require outstanding products, and it's perhaps not a good idea:-) For some products you may do dual licenses like MySQL or Qt. But the important thing to remember is that most software development is not abut writing one application and selling it, it's about delivering solutions. In that market a FLOSS license are really not an issue, afterall your customer will not be interrested in distributing the software. Most likely the only one interrested in such custom solutions are their competition, actually making it rather unlikely they will distribute. On the other hand FLOSS will give you possibilities to reduce development costs with lots of premade code.

By Morty at Fri, 2005/12/02 - 6:00am

Fell for the FUD? No offense, really, but the package format issue is mood IMHO. I hear it all the time, but I don't believe it, because I know it's BS. In case you don't know, there are quite a few commercial applications for Linux (my company is currently developing one as well, using Qt). Anyone not completely stupid won't create distro packages at all. There are distro-independent installers, like Loki installer (used by most Linux games, Crossover Office, and Nvidia drivers AFAIK). Then, there's InstallAnywhere, commercial, Java-based, used mostly for Java applications (eg Omnicore X-Develop). A few companies use hand-written custom installers (Softimage|XSI and ptc Pro/E, Pixel32). Or just use plain tgz archives (Apple, D2 Software, ifx).

Plus, there's only _one_ Shake and _one_ Softimage|XSI package for Linux (this is true for all the apps I mentioned), both should work on pretty much every distro starting at RedHat 7.3 - I've yet to see an incompatible distro.

And well, yes, the remaining 'issue' is the desktop environment. But why is that an issue? Ever noticed that even on Windows or OSX, most apps won't integrate at all? That almost every current application uses it's own HIG, design, style, color scheme and custom widget set anyway? Yes, Softimage|XSI uses Mainwin. It never looks or feels 'native', regardless of the desktop environment. But it works, copy and paste works, moving/ maximizing/ minimizing the application works, so hip hip who cares if it uses a different style and color scheme? If Softimage (or Mainwin) wanted to do it, they could at least parse a few config files and set the fonts and colors accordingly, but that wouln't make such a huge difference anyway...

By Willie Sippel at Sat, 2005/12/03 - 6:00am

There are lots of different package formats because in the Free software world the packaging is the distribution's job. Not the vendor. The distribution authors know how their system works and how they want their system to work.

They are the ones that keep linux systems consistant. If everyone went around downloading .exe equivalents from developers' websites, everyone's systems would be a mess and be going wrong all the time.

Now, that can be a problem if you want to distribute proprietary software. Ransomware relies on you keeping it not freely available. So the distributions won't be able to package it for you and hold it on their repositories. Some people make the binaries frely avaliable but use a registration code system. I don't know , I'm not really interested in non-Free software. I suppose the answer is to keep the file layout of the software quite simple, so that installation/making packages is rather trivial.

"...then some days later I awake with the sobering question in my mind 'And how do we earn our livings with it?'"

You get paid to create the software by the person or organisation that needs it.

By Robert at Sun, 2005/12/04 - 6:00am

I hope that KDE and Gnome will adopt something like Elektra in the future. When we have one flat registry, x-distribution thing will get a lot of easier.


By gerd at Mon, 2005/12/05 - 6:00am

KConfig-XT is more better suited and already commonly used by many KDE applications!

By Hans Chen at Tue, 2005/12/06 - 6:00am

Of course you can, but there are a few situations it is not possible or reasons you don't want to do it that way.

-The package are not available for your distribution/packageformat.
-You or other users want to keep using the stable version of the same program, using the packagemanger will most likely overwrite or replace the old version.
-Your user account don't have rights to install packages on the system with the packagemanager.

Klick is an addition to the package formats, think of it as a kind of sandbox rather than a plain install method.

_ONE_ package format would not really make a big difference, since in most cases you would have to deal with different libraries and compiler versions. Forcing you to make different packages for the different distributions anyway.

By Morty at Fri, 2005/12/02 - 6:00am

Klik is a self contained image, so you don't 'install' it or any of it's dependencies. Klik isn't suitable as a means of distributing things such as libraries (or anything else thats not directly run by the end user).

Using the system's normal package manager would mean you would have to update 1 or more packages on your system and if they are unstable, you would have to uninstall them and reinstall the old ones (which if it pulled in many new dependencies may not be very fun).

By Corbin at Fri, 2005/12/02 - 6:00am

> Why can't there be just _ONE_ package format??

Desktop LSB + elektra --> one plattform in 4-5 yrs.

By gerd at Tue, 2005/12/06 - 6:00am

"Why can't there be just _ONE_ package format?"

There's this inconvenient thing called "freedom". Because of it Fedora is not obligated to use Debian's package manager, or vice versa. There is no dictator telling distros and developers what package manager they must use.

By Brandybuck at Wed, 2005/12/07 - 6:00am

Klik's main advantages over a "real" packaging system are:
- Installable by non-priveledged user. Don't need to ask your admin to install "really crashy, untested application x" just so you can try it out.
- Doesn't mess with any other versions. You can keep your stable digikam installed via the normal package manager, but test out bleeding edge digikam without removing anything else. That's really hard to do using traditional deb/rpm etc.
- Easily portable. Copy a klik package to a usb key and take it to another computer, and it will (usually) run just fine.

Of course, not all of these goals are _quite_ realised yet, but that's the direction that they are heading in.


By ltmon at Sun, 2005/12/04 - 6:00am

These are all problems that should be addressed in the package manager itself.

For example, users should be able to install a .deb package in their own dir (/home/user/.local for example, instead of /). As long as the files don't conflict with other packages, two packages of the same name should be installable in this case.

By Reply at Sun, 2005/12/04 - 6:00am

So, are you going to write that fabulous package manager ??

In the meantime, I'll be a happy klik user.

As soon as you have something to test, tell so. Announce here: I'll get in touch with you to be your first beta tester.

By reply-reply at Sun, 2005/12/04 - 6:00am

It's called autopackage.

-> Fritz

By Fritz at Mon, 2005/12/05 - 6:00am

yeah, works perfect with all those KDE/Qt applications, right?

By cl at Mon, 2005/12/05 - 6:00am

Actually, it works just as well with KDE/Qt applications as Klik does. The only potential issue is the C++ ABI which has changed a little bit between different GCC versions. In practice I never found it to give any trouble though, and their current development version even allows for packages to contain different binaries for the different ABI's.

@rinse: Autopackage is _not_ a replacement for existing package managers, it just complements them.

By Arend jr. at Wed, 2005/12/07 - 6:00am

++++ (autopackage) "works just as well with KDE/Qt applications as Klik does"

No it doesn't.

The reason is: autopackage and klik do different things (with similar goals).

autopackage compiles source code. And tries to make the result as portable as ever possible. Its main religion is *first* to create a cleaner build environment+system, obtain cleaner source code from upstream, work for a cleaner dependency determination... and only *then* they'd put everything for 1 application underneath one directory. autopackage creates new tools to change the world of software.

klik re-packages already compiled binaries (.deb, .rpm, .tgz, and even .package packages). And tries to make the result as portable as currently possible. It works with means and tools that are currently available. Its main religion is "1 file == 1 application" (have everything contained in one .cmg file system image). klik uses existing tools to change the world of software.

autopackage works now for only very few applications. It requires the programmers to learn new tricks. autopackage requires sometimes many, sometimes fundamental changes in the source code of a program to make it auto-package-able. And it always requires re-compilation before an autopackage for a given application is created for the first time. Sometimes many man-days of "non-sexy" work.... Therefore, its success and popularity amongst coders is not spectacular, though I wish it were. (I really appreciate, applaud and admire the efforts of the autopackage guys -- but I am also a big fan of klik, if you could not tell yet.)

klik works already now for many, many applications. It requires no changes in the source code, and no re-compilation. Its results are ready in minutes very often. The klik developers have me had surprised and stunned on various occasions already, when a user came into their IRC #channel and asked for a new klik://package and they were able to create a fully working one within 2 minutes (happened with klik://flock, klik://wesnoth-latest, klik://wengophone and klik://xara).

Call klik an assortment of ugly hacks -- but it is wildly successful in what it does! And the removal of the ugliness is not in the realm of klik itself. This lays with the upstream packagers, with the Linux Standard Base efforts, and with the GCC developers (hell, they should not break ABI with every other minor release!). It also lays with the future success of autopackage!

If I understand the klik developers in #klik right, they even *wish* autopackage to succeed more than it currently does. Because this would give them much cleaner ingredient files for their klik recipes, which would then be much better portable across different Linux distributions.

By I disagree at Wed, 2005/12/07 - 6:00am

No, that is another replacement :)

By rinse at Mon, 2005/12/05 - 6:00am

"For example, users should be able to install a .deb package in their own dir"

They already can. I don't know the syntax for Debian, but every package manager has the ability to install to a different directory hierarchy (/, /usr/local, /opt, /sandbox, ~/MyStuff, ...).

By Brandybuck at Wed, 2005/12/07 - 6:00am

++++ "every package manager has the ability to install to a different
++++ directory hieraevery package manager has the ability to install
++++ to a different directory hierarchy (/, /usr/local, /opt, /sandbox,
++++ ~/MyStuff, ...).rchy (/, /usr/local, /opt, /sandbox, ~/MyStuff, ...)."


Stop telling fairy-tales. Please!

By I disagree at Wed, 2005/12/07 - 6:00am

While, yes, dpkg and rpm both _can_ install files into a new root, making it work right is not for the faint hearted. First, if the package is not relocatible, then you have the problem of needing to create a new package manager db in that fake "root", then the fun begins since if this is NOT a relocatible package, you will now have to deal with providing all those wonderful dependancies that that app needs to run.

Now what developers and packagers both need to strive for is making software completely relocatible. If you're furthur in doubt of this, take a look at the Maximum RPM book info about relocatible packages at

By Gary Greene at Mon, 2005/12/12 - 6:00am

I recognized that the rdf feed is not working anymore. What's the reason for this?


By Roland Wolters at Mon, 2005/12/05 - 6:00am

The RDF is hosted on which is down currently. Should return to normal once www is back.

By Navindra Umanee at Mon, 2005/12/05 - 6:00am is up, you must have obsolete dns information.

By Anonymous at Mon, 2005/12/05 - 6:00am

> host has address mail is handled (pri=1) by
> host is a nickname for domain name pointer

I'm all for it!

By interesting at Mon, 2005/12/05 - 6:00am

Didn't Troll Tech use to host it? What happened?

By KDE User at Tue, 2005/12/06 - 6:00am

Trolltech is atm busy moving.

By Anonymous at Tue, 2005/12/06 - 6:00am

As far as I know, Trolltech has/had not

Have a nice day!

By Nicolas Goutte at Tue, 2005/12/06 - 6:00am

FWIW: The PDF from the latest issue says it was made with Acrobat Distiller 6.0.1 for Macintosh (haven't checked the earlier ones).

Seems to be a pretty good magazine, though.

> by JOe on Saturday 03/Dec/2005, @18:29
> It looks like it was made in a Dreamweaver template. you can run dreamweaver
> through crossover office, or one wine if you tweak the wine.conf and know which > dll's to use. So it could have still be developed in linux on a windows
> application.
> joe

By Cazo at Tue, 2005/12/06 - 6:00am

Hey, I am running a klik version of Firefox 1.5 in Mandriva 2006. It runs just dandy (except for a failure to register some "chrome" component, and java does not work). The flash plugin I had to reinstall, but it took 15 seconds, and I did it all as a regular user, and within Firefox. Excellent !

By MandrakeUser at Wed, 2005/12/07 - 6:00am

I just found pipitas' blogged about his new klik package:

* klik://thunderbird15-tabbed ....(a patched 1.5 release candidate version)
* klik://thunderbird16-tabbed ....(a patched 1.6 Alpha version)

Way cool!

Also thanks to Jess Hall for writing such a useful article, giving really useful insight.

By kliker-noobie at Fri, 2005/12/09 - 6:00am