Archive for January, 2007

LXer Article

With KDE porting their applications to Mac and Windows the potential number of people using free software is unlimited. Imagine millions of people using Open Source Software for the first time..and getting hooked on it.

I had the opportunity to speak with several KDE developers recently. Benjamin Reed, Jaroslaw Staniek and Ralf Habacker are several of the many talented developers working on porting KDE to Mac and Windows respectively. They explain in detail what’s involved in making KDE and its myriad of applications boot under Mac and Windows.

Can you tell me about the technical design of the Mac and Windows ports?

Jaroslaw: I’ll refer to KDE/Windows as to “KDElibs/Windows and some KDE applications on Windows”. Porting applications to KDE/Windows typically just means making KDE libraries and the build system more “portable”. The source code of the applications are largely the same. As an example I can mention that Kexi’s source code, which I develop on Windows is often committed to SVN without prior checking it on other platforms. Then I just update another copy of the same source code from SVN on Linux and recompile. There are few, if any, easily fixable problems with this method, usually related to difference between compilers. You get the idea, this is how the portable development works.

There is one assumption many of the developers agree on. We re-use as much of the native interface as possible. However we do not perform any forks which would make ported applications non-standard in terms of file formats or protocols. I personally tend to give up with a given functionality (and look for replacement) rather than go with using a proprietary technology. A small example of this is my use of the mdbtools project to be able to access MS Access file format instead of using native Windows DAO/ADO API. This is not even a matter of license (because many APIs are considered as “system-level” technology) but more about a strategy. Other examples of re-using lower-level layers is multimedia framework. An example of an existing facility that should not be replaced in a a typical installation: explorer.exe desktop shell.

Benjamin: For the OSX port, right now there is no specific “technical design” beyond what KDE provides in general, and as far as the technical challenges involved, there is not a lot going forward that isn’t a general challenge to the KDE codebase. I know that’s not much of an answer, so I need to back up a little into the history of it.

Back in the day, Sam Magnuson (a Trolltech employee) did a bunch of work to rip out the X11-related code in the KDE3 codebase and got it to compile against Qt/Mac 3.x. I picked up where he left off and did a lot of work trying to clean up the patches, make it look a little nicer, etc. Around the same time, the Windows folks had started working on cleaning things up on their side. Time went by, and the Mac port stagnated, mostly because I’m not really much of a C++ coder, and I’d hit the limit of what I was able to do on my own. No one else really had the time to work on it with me (although there was certainly still a lot of interest). Most of my porting time went into maintaining other Fink packages, and keeping the Fink KDE/X11 port up-to-date and working smoothly. In that time, the Windows folks did a lot of *awesome* work on committing bits of my and Sam Magnuson’s work, along with a ton of their own, cleaning up the code, removing X11-isms, etc.

Fast forward to KDE4, I talked with various folks in #kde-devel off and on about wanting to pick up the Mac port again, and about the feasibility of really making a go at it. One of the things that really made the port possible was the move to Qt4, and a real dedication on the part of the KDE core folks to try to use official Qt API’s for things that had been hacked-around at the X11 level in KDE3 (and a commitment from Trolltech to add proper APIs for things that required hacks before). In addition, there were a lot of awful hacks that needed to be done to the existing autotools-based build system (automake, autoconf, libtool) to make things even build on OS-X against frameworks.

The move to the SCons build system made building on Mac feasible, and the subsequent switch to CMake made it easy. CMake has had a very large role in making it simple (and sane) to make KDE GUI and console applications cross-platform without a lot of work on the developer’s part. Mac OS-X has a lot of quirks at the compiler and linker level that make it hard to understand building (especially dynamic-loading) if you come only from a Linux point of view. CMake makes that completely transparent. A lot of the ease-of-porting now comes from Alexander Neundorf’s awesome work getting KDE to build with CMake.

So, to make a long story short, there used to be a lot of technical code hurdles to getting KDE to build on non-X11, but many of those were hashed out late in the 3.5 cycle, and early in the 4.0 cycle, thanks to the work of a lot of talented and dedicated people. At this point, there are only a few small platform-related issues for the Mac port, and the rest is really just a matter of keeping up with KDE4 development and fixing small problems before they snowball into big ones.

What were some of the technical challenges facing the developers?

Jaroslaw: The integration with facilities existing on the target platform and the look and feel.

There is some probability that in special cases platform-dependent look will be configured. Think about toolbars on mac and windows as well as features related to window management (fullscreen, etc.). Thanks to our API, KDElibs tend to provide well defined helpers that behave appropriately for every given environment. Many of these facilities are also deliverred by Qt, namely the accessibility API, so KDE developers can focus on preparing higher-level facilities.

What were some of the technical requirements for building KDE on Windows?

Jaroslaw: On Windows many dependencies are not considered as “system” libraries, so these are delivered within the so-called KDE development environment. The environment is only needed for developers, not users. The general rule here is that we try to have the environment as self-contained as possible to make new developer’s life easier. There are two main compilers used on Windows gcc and MS Visual C++,a aka msvc. Since C++ does not define de-facto binary compatibility between compiles from various vendors, when distributing binaries. Both targets will be (probably) distributed together.

Jaroslaw: CMake is used as a high level build system for KDE4, on top of compilers and particular environments. This is a positive change since for KDE3/Windows Qt’s qmake was used, without any chances for using advanced and automated configuration checks. Now for instance, if you need a MySQL support in your application, it is possible to declare this fact once in your CMake’s build file and the build system will be trying to find all the needed facilities for this requirement.

KDE’s relationships with Trolltech are well known. In version 4, KDE is even more a place where community and companies meet for mutual benefit. CMake is an advanced buildsystem delived by Kitware, Inc. and others. In fact it’s not only delivered as-is but there are also CMake releases with may features needed especailly so as large project as KDE is.

Were there any special requirements for Mac?

Benjamin: For Mac, Nothing all that special other than XCode (Apple’s GCC compiler set). KDE has a lot of dependencies to get the most out of it, so if you don’t want to spend days compiling libpng, dbus, etc., then you probably want to install my Qt4 and “kdesupport” packages on the web site. I provide pre-made packages which include headers and dev libraries so that you can pretty much just jump in compiling KDE SVN if you’d like.

What is the distribution strategy?

Jaroslaw: On Windows there is installer that installs the development environment. In the end there will be a choice between runtime for users and runtime+development files for developers. You can get more info at KDE Lists

On Mac, Right now I’m putting together Apple Installer packages, with everything self-contained in /opt to avoid getting in the way of other software. Eventually my goal is to also provide KDE4 through Fink, but I’m not going to bother doing so until we get closer to a beta quality at the least, but even so I will probably continue creating the installer packages. I have it pretty much automated, and it provides a really easy way to just drop a running KDE4 setup on a system without any external dependencies.

What is the Timeline, support options and future developments going forward?

Jaroslaw: The timeline for KDE/Windows target is dependent on KDE4’s plans. In general porting efforts and updates provided try to follow the mainstream development, i.e the one for Unix target. There are already people (including me) interested in commercial development using the development facilities of KDE on Windows. There is the KDE ISV subproject in development. there is no doubt the user base is growing and we now have active community around this target, which helps KDE Project in general.

The design covers two steps:

1. KDE on Windows uses current code and similar packaging as on Unix and to have KDE applications as they are with a minimum of required porting effort. This is to show people how it works and to get Windows in contact with KDE applications. In this step the basic differences between Unix and Windows must be fixed (fork/exec and Unix domain sockets not available on Windows, no undefined symbols in shared libraries possible, different file path syntax)

2. When enough developers are available they could make partial redesigns of KDE internals To use specific Windows features like named pipes for faster ipc or be able to have standalone applications for example konqueror or contact/kmail not to be required to run as many additional background processes as now. I can image to have a redesigned klauncher, kded and kioslaves included into a standalone application, the latter may be using threads or similar. Jaruslav has gone already this way with Kexi.

Are there more features and ideas in the works?

Ralf Habacker: The current implementation of KDE is designed in a unix specific way, which is partially different from the Windows way. Examples for this are:

* Process creating – Using the Unix way of fork and exec.
* It isn’t available on Windows, this difference requires a redesign of the related parts.
* Its missing Windows api counterparts.
* KDE uses Unix domain socket for high speed data transfer betwen kioslave slaves and its parent process and for the communication to/from the dbus deamon. On Windows there are no Unix domain sockets. They could be emulated by tcp sockets with the costs of slower bandwidth and additional patches to deal with Unix domain socket files exchanged between processes.

There are different application interfaces. Windows for example has a tcp socket stack similar to the Unix one, but it differs in some areas which makes porting harder. Windows named pipes have a completely different api, which required a partial redesign of KDE code.

After Qt4/GPL was released, our next step was clear, build a native kdelibs4 on windows. The main problem is that we’re too few people with too much work (starting with a native dbus implementation and ends with a working kde app on windows to show others that we really moving forward). Because of this I’m happy for any publicity to get new developers which could help because we’re all doing this in our spare time.


Some of the developers working on the Windows port are Peter Kümmel, Holger Schröder and Christian Ehrlicher and on the Mac side there are Derek Ditch, Alexander Neuendorf, Marijn Kruisselbrink and Tanner Lovelace, just to name a few. There are many more who have contributed in the past that were integral in making these projects a success. All the hard work they have done will have the cumulative effect of exponentially increasing the number of people who get exposed to and use Open Source Software.

I believe that KDE porting their Desktop Environment to Mac and Windows to be a watershed moment for Open Source Software. By and large, people are resistant to change and in all my interactions with strangers, friends and family I have learned creative ways to describe what using Linux is like or how to run it from a liveCD or how to install it on a PC. I have learned to stay away from the word “change” and use the word ‘add’ instead.

It is much easier to convince someone to try Open Source Software if you describe it as “adding” something to their computer rather than “changing” it. Many who read this do not look at ‘changing’ their computer with apprehension or fear but we are not in the majority. If “adding” KDE to a Mac or Windows machine gets millions of people who otherwise would not, to try OSS then so be it. I am convinced that once a person tries OSS they will get hooked on it. It is easier than starting smoking. 😉

From the day I first downloaded Firefox my addiction and/or love affair with OSS has flourished unabated. It started with Firefox and progressed into using only FOSS within two years. Why? Because I chose too. After using it every day and comparing it to proprietary software it was a “no brainer” to switch to Open Source Software entirely. There was no loss in quality of applications, security and functionality on my machine. There was a significant increase in the quality and choice of applications I could use and by switching to Linux my computer became a bank vault compared to whatever it was running Windows. How did all this happen? I started using one program, got hooked and never looked back.

Soon everyone who owns a computer will be able to try and use OSS and all they will have to do is “add” software to their computer. That shouldn’t be too hard, people add software to their computers every day, right? So, lets say that 25 to 50 million people who had never tried OSS before, try it because all they have to do is “add” some software to their computers. Those of you who have surfed before will know what I mean when I say this, Your laying on your board and you look out into the ocean and see a bulge in the water and you think to yourself “Is that the next big wave coming in?” The answer is yes, this is the next big wave coming in.





Kexi Project

KDE Wiki Page

Fink Project

The Road to KDE 4: Full Mac OS X Support

The Road to KDE 4: Job Progress Reimagined

Read Full Post »

Originally Posted Jan. 14th 2007

LXer Article

PuppyLinux is one of the most popular “flavors” of Linux, I have used it on several old P-II and P-III machines that I donated and it got them to work when the original OS (95 and 98) would not even so much as boot up. It was just after PuppyLinux’s offer to be the OS for the One Laptop Per Child and the new “Unofficial PuppyLinux Guide” came out that I first contacted Kenneth of PuppyLinux. I wanted to know more about Puppy, the OLPC and what goes into making a guide for a Linux distro, Kenneth was kind enough to share his experinces with me.

How long have you been active with OSS?

I believe that I have been involved for about 3 years now.

How long have you been involved with PuppyLinux?

I have been involved with PuppyLinux for almost three years.

What projects have you been or are involved with?

The project that I mostly involve myself with is of course PuppyLinux. Though I do involve myself with other projects like metalink or metalinker & stickwiki. Though I am not a developer. I do help by testing and getting the word out about the projects above. I also send suggestions & bug reports too many of the applications that I use.

Do have any programming experience?

No. But the good thing about PuppyLinux is how it is scripted. The reason PuppyLinux is so easy is because of the scripts that automate certain jobs & processes. A fellow pup that goes by GuestToo writes many great scripts for PuppyLinux. And it was actually through his scripts that I became interested in the commandline & bash scripting. And also thanks to Nathan F. creator of GrafPup I learned html.

What is the PuppyLinux Foundation?

The PuppyLinux Foundation came about as an ideal to support the (PuppyLinux 1.xx Series) which is based on the 2.4 kernel. So a group of persons decided to try and do just that. It is still in the development phase but the webpage and many support links are already up.

Why did you decide to create “The Unofficial PuppyLinux Guide”?

In the beginning there was the forum, and I do not believe anybody anticipated how big PuppyLinux would grow in such a short time. Many suggested that a wiki would do a good job for this documentation. This was a positive, but sadly no one showed any leadership. After messing around with StickWiki I got to messing around, I was going to surprise Barry K. by transforming his help files into one single paged wiki. This did not go right for me, because I could not understand much of the docs available. This is not to bash Barry, he has enough responsibility as is. So I took a look at the ubuntu guide and seen what they did, my advantage is using StickWiki because of how much quickly it loads than that of the ubuntu folk. So I scoured the Puppy Linux websites looking for what a typical end-user would look for. I condensed it as much as possible but still made sure it was understandable.

Can you give us a rundown of how you put all the divergent information in the guide?

Very quickly.. At the time the forum was going through some changes and I was terrified that all information would be lost. I also pay attention to what most people are asking about when they first come to puppy, little by little a lot had been done. I focus on one area at a time and plan to to keep doing it as such.

Do you have any tips or tricks that you can share that helped you when you were working on the Guide?

Using IceWeasel browser’s tab feature helped me flip back and forth from the ubuntuguide. 🙂 Though the PuppyGuide is not as defined as the ubuntuguide it’s roots stem that teams work. Not that I copied and pasted, but that I looked at how I felt they went right & went wrong.

How long did it take you to finish it?

The PuppyGuide will never be complete. Puppy like other distro’s is constantly evolving.

What were some of the mistakes you made and how did you overcome them?

The regular mistakes one makes when typing or writing. And I think I might have rushed on some areas. Of course I will critique myself and go back and try to make what others and myself think need to be better.

What happened with One Laptop per Child? What went wrong?

What happened & went wrong? Corporate interest of course. Every corporation trying to sink their teeth/name into the project. Everyone including Apple, Microsoft and Intel. To state that people have shelter and food, and what they need is an education seems ridiculous to me. It is the educated world who seems to bring the weapons and strife that cause poor under-developed nations to become worse than what they already were. Now they want to educate these people ? Get real, most of these countries are up to their necks in debt thanks to the World Bank or IMF whatever they call themselves, and it comes as no surprise that they would want to finance these countries more money for computers. And these countries I speak of mostly consist of African nations, because the developed world has already realized it’s all a scam.

Where do you see PuppyLinux going?

To the best of my understanding Barry K. has already turned down some offer’s. I do not speak for Barry but it would be my best guess that if the right company with the best intentions came along Barry would endorse such a company as he has in the past.

What are some of your personal interests?

My personal interest.. I enjoy fishing and camping very much and I used to play a lot of frisbee golf. But since moving out of the city fishing and linux seem to be the only things available.

Thanks again to Ken for the interview and the great work on the PuppyLinux Guide. If you are interested in getting more info on how puppy works, visit their website and Forums. They have a very active and freindly community to help you.


The Unofficial PuppyLinux Guide

PuppyLinux Website

Puppy Linux Discussion Forum

Read Full Post »