People Behind KDE: Alexander Neundorf

Tuesday, 14 March 2006  |  Jriddell

People Behind KDE is our fortnightly exposé of the celebrities of KDE. Tonight we bring you the man who made the first Samba io-slave, an NFS io-slave and from those pre-zeroconf days the Lisa lan-browsing io-slave. This same man is single handedly porting KDE to a whole new build system, but get back in your seats ladies, he's not up for adoption. Find out all the gossip in our interview with Alexander Neundorf.

Comments:

Networking - Anon - 2006-03-14

Is Lisa still up-to-date? Superseded by zeroconf? What's that for anyway? Back when I tried to access Windows PCs on the LAN (not so long ago.. KDE 3.3?) I always thought I'd need that (because nothing initially worked). Besides, smb:// sometimes didn't work for non-obvious reasons. So lan:/ told me to start LISa first to get "LAN" working, and after finally managing that lan:/ redirected me to an empty view of lan://localhost/. Never really understood that completely.. Also, configuring Samba for smb:// wasn't that easy to do for a half-clueless noob, so there is was stuck. Some Linux attempt later LAN / smb:// worked (most of the time). So I never touched it again. I don't know if a fresh installation of Distro/KDE already delivers that for the most part. I wish I've had at least graphical tools to manage protocols, services etc. back then.. and without command line. I think that's a hard requirement for "normal people", who don't breathe Linux and know their processes by name. For the future I wish it would just work without configuring most stuff, also covering wireless and dynamic changing networks. I really hope that's what Solid and KDE 4 can deliver.

Re: Networking - a.c. - 2006-03-14

I agree. I have been using LISA since it first came out and absolutely love it. So I am a bit confused. LISA is about spying on the network and tracking what is going on. zeroconf is more about listening to broadcasts. Big difference. If LISA is dead, why? It will be years before all the systems are into zeroconf.

Re: Networking - Ben - 2006-03-20

I have to agree. It really, really frustrating to have all of this potential in a kioslave like smb:// and then find out that juk/amarok/konqueror can't play audio over them for mystrious reasons. Anyone have a clue how to fix this? Thanks, Ben

What's the status of FUSE-KIO? - ac - 2006-03-14

KIO-FUSE (http://wiki.kde.org/tiki-index.php?page=KIO+Fuse+Gateway) is a very promising project because it allows non-KDE apps (including legacy and shell utilities) to access remote files set up under KDE as if they were local files. It combines Linux's Filesystem in Userspace (FUSE): http://fuse.sourceforge.net/ and KDE's KIO slaves. Alexander had started the project awhile back, but I'm not sure how it's been progressing...

Re: What's the status of FUSE-KIO? - yaac - 2006-03-14

For this to be of any use IO Slaves would need seeking support though, at least at the framework level. There's plenty of IO Slaves that can potentially be made seekable, but the framework support is simply not there. Any chance of it happening in 4.0?

Re: What's the status of FUSE-KIO? - aleXXX - 2006-03-14

kio_fuse is in kdenonbeta and basically working, also the seek() command is implemented (not very efficently since ioslaves don't have seek, but it works), e.g. gimp, joe, OOo work with it. The problem is, I don't do a lot of networking stuff since some time now already, so I don't actually use it. So, IOW it needs a new maintainer. Being able to seek in ioslaves would be nice, but it would require some work. KDE 4 libs are not finished yet, so if you want to help, you're welcome :-) Alex

Re: What's the status of FUSE-KIO? - yaac - 2006-03-15

Thanks for your effort, Alex. Can't help unfortunately, too much other stuff to do. BTW, the KIO seeking bug/wish is http://bugs.kde.org/show_bug.cgi?id=116091, currently with 0 votes. ;)

cmake, scons - Ian Monroe - 2006-03-14

Is cmake likely to be the build system for KDE4 then? I have to admit just glancing at the cmake docs that its syntax doesn't appear to be much of an improvement over Makefile.am/configure.in.in. Which isn't a requirement for KDE4's build system, it would just be nice. :)

Re: cmake, scons - Marten Klencke - 2006-03-14

A recent post on kde-devel reveals that apparently it has been chosen as the build system for KDE 4.

Re: cmake, scons - Carlo - 2006-03-14

That would suck. I thought scons/bksys was the chosen one!?

Re: cmake, scons - ste - 2006-03-14

yes, it was i really hope it still is [scons is the best tool for the job IMHO]

Re: cmake, scons - Michael - 2006-03-14

SCons is terribly slow and has some portability issues, at least on win32 (maybe that changed lately though, I haven't tried it for some time) CMake is in itself not a build system but a Makefile generator, so CMake alone still won't compile KDE4. However, because it abstracts over the makefile-generators, it is (in theory) possible to use almost any make tool for building KDE 4. For example make, unsermake, qmake, nmake,... Additionally, the Makefile syntax of CMake is much more readable than that of scons (the SConscript files are actually Python scripts)

Re: cmake, scons - Carlo - 2006-03-14

> SCons is terribly slow and has some portability issues, at least on win32 (maybe that changed lately though, I haven't tried it for some time) It is? I found it quite acceptable - even on slower boxes. Regarding portability issues: I don't know (or particularly care about Windows), but that should be fixable. > Additionally, the Makefile syntax of CMake is much more readable than that of scons (the SConscript files are actually Python scripts) Can't do anything else but disagree.

Re: cmake, scons - blacksheep - 2006-03-17

«I found it quite acceptable - even on slower boxes.» But KDE code is huge! An insignificant hit of performance for some program of yours, even if big, might be huge when you want to compile something of the size of the all KDE. Anyway, if you really want scons to be used, just jump forward and help making it suitable. Less talk, more code. ;)

Re: cmake, scons - Ben - 2006-03-20

I have a bit of experience with scons and it's obvious that gcc takes 95-99% of the time in large compiles. The benefits of scons are that its much easier to work with, parallel builds are possible in separate dirs (imagine having N cpus running scons -j 2*N, and it scales without major bottlenecks!), and it has caching of intermediate files for faster rebuilds.

Re: cmake, scons - aleXXX - 2006-03-14

Do you actually know cmake ? scons was chosen at akademy, and people started to work on it. But after months of work we ended up basically with a fork of scons. So apparently scons wasn't the best tool for the job. About "it was chosen": yes, scons was chosen, but KDE still follows the "who codes decides" or "The power of the doer" rule: I just did after I got the "Go" from David on the buildsystem mailing list. So it just happened that right now it seems cmake will be the buildtool for KDE 4. CMake needed some enhancements mainly for the windows stuff (we are probably the first project which uses mingw heavily). The cmake developers have been very supportive for KDE, they are on the buildsystem mailinglist and fixed the issues we found within days. They want cmake to become the buildsystem for KDE 4. Alex

Re: cmake, scons - Carlo - 2006-03-14

> About "it was chosen": yes, scons was chosen, but KDE still follows the "who codes decides" or "The power of the doer" rule: I just did after I got the "Go" from David on the buildsystem mailing list. That's true of course. As I looked at cmake (a while ago) it had lots of paths hardcoded in its modules files instead relying on some prefix. If you have more than a single (virtual) installation on some box and you want it to use /.../<foo>, but /.../<bar> is found, things get wrong. I also hope that the KDE 4 build system will be better regarding optional dependencies. Autodetection sucks, deterministic en/disabling is needed.

Re: cmake, scons - Ian Monroe - 2006-03-15

> The cmake developers have been very supportive for KDE, they are on the > buildsystem mailinglist and fixed the issues we found within days. They want > cmake to become the buildsystem for KDE 4. Well, this alone is enough reason to choose cmake. Its really nice to have an active "upstream".

Re: cmake, scons - renox - 2006-03-15

> But after months of work we ended up basically with a fork of scons. I'm curious: why a fork? I can understand that some modifications were needed, but did scons's maintainer refused to integrate them?

Re: cmake, scons - ita - 2006-03-15

Not a fork but an experimental branch.

Re: cmake, scons - Thiago Macieira - 2006-03-16

We had basically no relationship with the scons maintainers. None of our changes were applied upstream. One of the reasons, at least, was to maintain compatibility with an old Python version. By dropping that compatibility, we made some progress, but created a fork.