Guidance in KDE Admin

[Sebastian Kuegler]

On Thursday 27 March 2008 00:01:38 Sebastian Sauer wrote:
> Nicolas Ternisien wrote:
> > What is your main problem about this Leo ?
>
> I agree with Leo and don't particularly like that idea too. I guess mainly
> cause of two reasons. 1) why Python and not language XYZ and if also
> language XYZ then 2) I hope we don't end to depend on n different
> interpreters to get a basic KDE setup running. Also it may help to keep in
> mind that over the years traditional desktops will be extended/replaced
> with smaller portable devices and there Moore's law isn't that active since
> the progress may not go into faster hardware but longer lifetime, smaller
> devices and more functionality (I still hope to see one day the plasma
> analog clock running on my watch).
> I guess my fear is, that we open a door there and wan't be able to provide
> any hint why that door is only open for some (e.g. why exactly Java but not
> Mono which is GPLv2 too btw? not needed to answer, just a sample that
> matches to what Nicolas wrote and should show that there is already
> potential for conflicts).
> But maybe a general "each language is welcome" and a clear limit to
> optional modules (so, nothing what is needed to have a basic KDE-desktop
> running) would help there already?!

Let me explain a bit how I see it.

From measurements we made some time ago, the overhead of running an 
application in PyKDE is about 8MB once for the bindings. CPU-wise, it hardly 
makes any difference since most of the expensive code is still C++. I cannot 
talk about Ruby, but I would guess it's in the same ball park.

Also, I wrote that we don't want to replace core applications, or long running 
ones. So to run a KDE desktop you won't need any Python or Ruby bindings, you 
can live just fine without those apps.

For things like Kcontrol modules, for example, that's not really a problem. 
The advantage of it being easier to write a module for a specific purpose 
outweighs that disadvantages. I don't think this would form a barrier for 
getting some parts of KDE running on your watch -- as long as your watch does 
not need a mountconfig utility ;-)

Which language? Well, I'm a Python guy, but I wouldn't have any problems with 
a Ruby application ending up in one of the KDE modules that get typically 
shipped. Anything free is basically fine with me, although I wouldn't like C# 
to be ending up being that language. Not that its chances are particularly 
high anyway. That doesn't mean that it wouldn't be good to have at least one 
language that is easier to write and deploy supported by KDE. The win in 
terms of development time is tremendous and we can tap into a large pool of 
developers that previously haven't really been able to write KDE software. By 
exercising the bindings in that way, we would make sure that the bindings are 
of high quality as well.
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080327/3dc69fd6/attachment.sig>