I've received 2 emails asking for more blogging and info about current klik2, especially since FOSDEM 2008.

Unfortunately, I don't have much time these weeks for 'FOSS-work', due to pressing 'work-work' duties. Since about October, I'm entangled deeply (too deep, if you ask me) in a major project that leads me to spend 5-6 days a week in Frankfurt (250 km away from home), with 12-14 hours a day on a customer site. Now compute: how much time does that leave me on evenings (in the Hotel) and weekends (at home), given that one-way travel time Stuttgart <=> Frankfurt is about 3 hours, and daily travel time inside Frankfurt is about 30 minutes?

This project takes much longer than initially thought. (Also, it involves only a very little bit of Linux, Solaris and Open Source, and much more MS Windows and proprietary software.) However, now there's the first light at the end of the tunnel. A few more weeks, and sometime mid-May my routines will be back to more normal.... *sigh*.

Anyways, while there are some more current klik2 development news, here's just one item for now: GSoC!

The klik team has submitted to become a mentoring organization for the Google Summer of Code 2008. If you are interested in some of the possible student projects, visit our GSoC idea's page.

We give a short description of each idea, as well as listing required skills and expected difficulty level to implement it, the programming language to use and some reference links to study:

• klik2 Updater
• klik2 Security Framework
• Enhancement/Replacement for fakechroot
• Packaging the klik2 client
• Porting klik2 to *BSD and Opensolaris
• Automate klik Recipe Testing
• Replacing Server-side APT with Server-side Smart

Due to too little testing, the Milestone 3 release announcement is postponed until Wednesday. It may actually happen even later, should I have no time to really do it on Wednesday evening, due to my work-work obligations.

Anyway, here is what we have planned for M3.

The FOSDEM 2008 organizers now have published their 'speakers interview' with probono and myself.

If you are interested in some background about the current klik2 development, it may be serving as a good general introduction into the concepts.

This weekend it's time to announce it. Finally: klik2 development has reached our internal "Milestone 2".

Remember klik? That project that aims to make Linux end-user software installation and usage more easy than on any other platform? "Grandma-proof", if you like? By making to 'install' an application as easy as copying a single file to a USB thumbdrive or to a different computer? By implementing application-level virtualization, encapsulating each end-user program into a single file, following the 1 application == 1 file principle?

For Milestone 2 we originally had set very modest goals:

1. Number of tested applications: 5 (xvier and 4 Gnome apps only: xchat, gobby, glade and hardinfo)
2. Number of tested distros: 3 (Ubuntu Gutsy, Fedora Core 8, Mandriva 2008)
3. Number of tested klik CLI sub-commands: 2 (klik get, klik run)
4. Number of tested desktop environments: 2 (Gnome, KDE)
5. Number of Screencasts: 3 (gobby, glade, xchat)

Well, if we took it literally, we failed. Because we could not find someone to thoroughly test on Fedora (it also turns out we have most problems currently to get klik2 to work on Fedora), and we could not find anybody for Mandriva. We also don't have the screencasts yet...

But we don't take it literally. Since we found people to test it on openSUSE and on Debian/Sidux, we're happy enough nevertheless and declare Milestone 2 reached. And as for the screencasts... why don't you step forward and create some for us??

This Milestone 2 achievement means that we have most of the "pillars of klik2" in place now to make big progress in a very short time. With some more finetuning, we hope to have a few hundred tested applications working and also showcase them pretty soon... However, for Milestone 3 we still do 'only' aim for 15 -- but!, we'll add Qt- as well as KDE-based applications, plus, we want 2 more distros tested...

What is even more exciting: our old friend Niall "bfree" Walsh is currently putting lots of efforts into two totally unexpected additions which we would very much like to see ready for addition to the current Milestone 3 goals:

• transforming the klik2 client source code into a properly done .deb package
• getting klik2 run on the tiny EEE PC

If you want a glimpse at bfree's work look at the screenshot on the right (click thumbnail to see full size).

Next stop: Milestone 3! If you want to help, here is what you can do:

• Install and test the klik2 client from our SVN repository (and ask questions in #klik IRC channel on Freenode)
• If you happen to run Mandriva, test the Milestone 3 application set for that distro (and fill in the gaps)
• Test the Milestone 3 application set for your distro (feel free to already start testing some more too)



• Use the openSUSE Build Service to create proper RPM packages (also for Fedora, CentOS, Redhat, Mandriva,...) for the klik client (and tell us about it)
• Help us create some nice screencasts about klik2

Make sure you send us back the automatically generated feedback (see screenshot on the right -- fill in some additional comments too), when that dialog pops up after running "klik get someapplication"...

Now that OpenOffice.org does make some splashes in the IT press for the sole achievement of having created a "portable" version that can run from an USB stick (on Windows only, that is) -- isn't it time for klik to get ready for gaining its own share of public fame sometime soon? That's because klik does not only turn OpenOffice.org, but many thousand Linux applications into "PortableApps". And does not need painstakingly recompiling portable binaries from modified source code, one by one. But will re-utilize the marvellous work and special knowledge of all the dedicated Debian, RPM and Slackware packaging heroes out there and repackage 95% of its supported klik bundles fully automatically, including dependency resolution...

Have I ever mentioned that klik will be featured as one of 3 (invited) talks in the FOSDEM 2008 main track about "Packaging"? (The other two talks will be given by the Conary and the PackageKit developers.)

probono and myself will be presenting and showing off the (then) state of klik2 development, which will (hopefully) have reached a major milestone by February.

Last evening I re-tested how well (or not) klik2 does deal with applications that have no GUI at all. Though general CLI support is not even part of our preliminary February milestone plan, that one does start to work already pretty well.

Even though I finally did find an ipcalc package on the openSUSE build service repository, my personal coolness factor for running a Debian-born, klik-ified ipcalc on my (oldish) openSUSE-10.2 notebook feels considerably higher.

I hit [ctrl]+[alt]+[f2] to go to a non-GUI console and started:

   klik get ipcalc

The process to download and run the XML-based (and largely Zero-Install compatible!) klik2 recipe, which in turn fetched the ipcalc_0.41-1_all.deb from the official Debian repository, and converted this single ingredient into our .cmg format that suits klik's "1 application == 1 file" principle took less than 12 seconds.

As usual, the resulting .cmg image file was placed into the $HOME/Desktop folder. I tried to run it to see if it worked:

   klik run $HOME/Desktop/ipcalc_0.41-1.cmg

which brought up the usage output. Next, I ran a calculation for an existing customer's site that I had done earlier the day, but manually/mentally, since the notebook didn't have an ipcalc RPM installed (also, I hadn't found the one in the build service repository yet). This time in a KDE Konsole, to be able to provide a screenshot proof to you:

   klik run $HOME/Desktop/ipcalc_0.41-1.cmg 10.49.46.146/255.255.255.192

Now that this worked so nicely, I moved the .cmg to my standard folder of working klik bundles (BTW, which standard naming convention for the klik .cmg files would you prefer: bundle? container? image? archive? AppFilesystem? capsule? packet? package? BoxedApp? PortableApp? What else can you come up with?).

Then I created an alias in my ~/.bashrc file:

   alias ipcalc='klik run ~/Desktop/klik2-work/ipcalc_0.41-1.cmg'

Works like a charm. To recognize the difference from a "normally" installed ipcalc running, you'd need to know exactly what to look for.

Kudos to Jason "killerkiwi" Taylor and Lionel Tricon for doing most of the recent work to make the current klik2 state of development a reality!

This afternoon it looks like I'll get to go tomorrow to the Systems fair in Munich. I've got various exhibitor booths to visit and see what new things they have on offer, and also one or two meetings arranged already.

However, there is one thing I'm especially keen to see: x2go.

x2go is a fast remote desktop connection suite based on NoMachine's NX libraries; you can scale it up to enterprise level or slim it down to personal use only for an "everywhere@$HOME" personal use-case for geeks and nerds.

To say it first: x2go is *not* compatible with FreeNX or NoMachine's NX servers. Nor is it with NoMachine's NX client or with QtNX. However, x2go does base its remote desktop access part of their functionality on NoMachine's NX libs -- but it implements 'the rest' differently: mainly sound/printer/fileshare tunnelling and user authentication for now (example: uses sshfs for file sharing; LDAP for user admin+auth; printing and sound do not work yet). Their x2go client is Qt4-based (Win32 version available).

x2go developers don't care much about accessing Windows remotely -- their main concern is Linux/Unix, and that's where they focus their development work on.

Their coolest (working!) feature for now: store your authentication data on a USB stick or a SmartCard. Remove stick/card from client -- your remote session is suspended; stick it in again (even on a different client) -- your session is immediately resumed.

What KDE users probably will appreciate very much: they have their configuration module completely integrated into KDE's Control Center.

What a coincidence today happened. In the morning I used KDEPrint's 'poster' frontend to create a "poor man's poster" in A1 size from 4 A3 printouts.

In the afternoon, a lady mailed me, asking why her KDE print dialog on Solaris didn't show the poster dialog, while her husband's openSUSE KDE did show it.

I took the time, mailed her back what I knew about the question, and included a few screenshots.

Two hours later I thought for myself: "WTF -- you took more than half an hour to write back to this lady and explain everything to her... Why not put another 30 minutes effort into it and convert the mail into a little tutorial to be published in my blog?".

I slightly changed my earlier mail in a few sentences, re-arranged it a bit, and posted a screenshot with a long comment to kdedevelopers.org.

Hardly I was ready with this when I saw a posting by Hin-Tak on the 'printing summit' mailing list over at linux-foundation.com, asking about ... poster again (without remembering the name of the utilitiy). Happily I mailed the link to said image with comments back to him.

And now it's "Heck! I may as well make a real blog post from it, add a few more screenshots and declare it a tutorial...."

So here we go.

You may already have come across the "Poster" tab in KDE's printing dialog. The one the screenshot to the left shows. It should be there for each printer you select from the drop-down list, even the virtual ones, that "Print to File" or "Send to Fax" or "Mail PDF File".
However, the poster tab of kprinter will *NOT* show up if you don't have the "poster" utility installed and in your $PATH. So if you want it, simply install the 'poster' package.

(UPDATE: Seems after Michael Goffioul's patches from 2002 there were more new features added to poster (which I wasn't aware of). There's a bug report 132916 which was pointed out to me in a comment below by jlp. Given that the bug reporter says "version 20060221 doesn't work, while version 20050907 does", it is probably saver to download and use the latter. BTW, openSUSE ships the version 20020826 which works as well. This bug may explain why Gentoo and Debian have reverted to a 1999 version of poster, which does not work with KDEPrint.)

Obtain "poster" from here: ftp.kde.org/pub/kde/printing/.

Important: you need to use the version from the link above, should your distro's version not function properly! It contains some patches to make it work with KDEPrint (poster's commandline abilities don't suffer from these patches!). The patches (written by our deerly missed Michael Goffioul, who currently does have too little time for active KDEPrint development) have also been accepted by the upstream poster developer, years ago.

Unfortunately, some recent distro releases (Debian?, *buntu?) for some reason seem to ship an older version which makes the kprinter poster tab display an error message.

As soon as you install the patched version (compiling it is easy), kprinter will start work with it.

If you figure your distro is using a b0rken version (or no poster package at all), you should contact its respective packager and/or submit a bug report or feature request. Ask them to use the patched version of poster to make it work with KDEPrint.

Some of you may remember my blog post "How to simulate a slow network (after all, QT_FLUSH_PAINT=1 doesn't work with Qt3)" from nearly two years ago.

After all, I'm still getting a private mail or two every half year inquiring about it. That blog post did describe in some detail how you can use a command like

  {/usr}/sbin/tc qdisc add dev lo root handle 1:0 netem delay 20msec

to emulate a network connection across the loopback interface that is handicapped by a 20msec latency delay. (Of course you can use a different interface, like eth0 to slow down the connection there, and a bunch of many different parameter to fine-tune to your needs).

If you missed that previous post, you may want to read it again...

The "tc" command is part of the iproute(2) package available on most distros.

This morning I discovered a new tool that may help with the same scenario (which is: "I need to test some application to run across network links which are crappy, but I can't test it because my own network connection is excellent...." ). It is called "wanem" (for 'Wide Area Network Emulator') and available on Sourceforge.

wanem is a complete Live CD, Knoppix-based. It allows you to configure all parameters you want via a comfortable web interface: available max bandwidth, latency delay, package loss, -- if you want, with different setting for uplink and downlink.

Underneath wanem is the same "tc" commandline used that my previous blog posting dealt with. However, the web interface does allow you to set up the thing more easily, with hardly any prior in-depth networking knowledge. The drawback is that you need to run it on a machine of its own (but that does not need to be any very new and shiny hardware, as long as it boots the Live CD).

Best, if that machine has two separate NIC interfaces that you use to put the machine in between your test client and your test server application (but if you read the docu, it tells you how you can use it with a single interface as well).

I've not yet tested using the Live CD ISO image to boot a VMWare or a VirtualBox machine, and use that for testing, but it should work nearly the same. (You can at least be sure that you'll not get *better* network performance than the settings you're using, and you want to test the bad conditions anyway...).

wanem auto-creates a few shell scripts that run "tc" for you with the desired settings. You can save and re-use those scripts at any later time, without re-configuring the web interface anew. Very convenient.

wanem is the perfect tool for you, if you are *not* a guru when it comes to TCP/IP, networking, routing, proxying, firewalling, gatewaying and iptables commandlines, but if you nevertheless want to test your application's performance when using network connections of all kinds and qualities. (Yes, that could be some simple web application. Yes, that also includes KDE3 and KDE4 applications supposed to run over a network connections via NoMachine NX, FreeNX, NX Free Edition, VNC, LTSP, remote X11, fish, smbclient, 2X or X2Go [Heh, I already can see how now a few people out there will start to consult Google about a few of the strange abbreviations I used in the last sentence... ] ).

BTW, wanem comes with some excellent documentation. I wonder why the download figure for the iso image (available since July 2007) is over 1000 while the main PDF document was downloaded less than 200 times. Is it still the same as it was many years ago already, that everybody starts installing and using an application first, without ever bothering to read the docu, and when the first problem occurs, just complain at a mailing list about it (without bothering to read the... oh, I said that already)?

Or is it that wanem is just so easy to use that nobody ever comes across a problem?

Today I experienced two moments of bewilderment, the second one mixed with dismay. At first, when I googled for something unrelated, on one of the returns I saw a forum post where someone said "Icaza himself says that OOXML is superb". Well, first I was amazed, then I shrugged, and wrote it off as a troll, and continued with my other tasks. Two hours later I remembered again.

So I googled once more. This time simply for OOXML +superb. And sure enough, I found this (may also be found here).

The Google group where this quote (which is only 5 days old) is from, is setup by Miguel himself, specifically to provide a feedback forum for his blog. Here is the quote. The emphasize was added by me:

 

OOXML is a superb standard and yet, it has been FUDed so badly by its competitors that serious people believe that there is something fundamentally wrong with it. This is at a time when OOXML as a spec is in much better shape than any other spec on that space.

Besides, it is always better to have two implementations and then standardize than trying to standardize a single implementation.

I've never seen Xinerama combined with Compiz/Beryl/XGL (or AIGLX) in action. This morning, when checking out a printing-related blog, I stumbled upon a little YouTube video showing exactly that. It does look amazing indeed.

Looked like all the effects did work in the demo-ed setup. Duh!, the video is even a year old. I wonder when I'll be able to get meself a new (!) notebook that can do at least non-Xinerama 3D desktop stuff. (It's not that I'm convinced it will make me more productive... but it at least makes for nice "demoware" to impress relatives, friends, customers or complete strangers in the airport lounge).

(Note: the image is only a screenshot. Don't send a bug report if clicking it won't play the video.)