glib dependancy in KDE3.x

[Maks Orlovich]

> This page fault is handled in the kernel, where the VM decides how this
> page can be provided. Usually, the page can be found already in the
> "cache", which is just another way of saying that it has been loaded
> previously, but nobody used enough other memory so that the linux kernel
> saw the necessity to throw it out.

<snip>

You're grossly simplifying things here, by ignoring the effects of disk 
latency, readahead, cache pressure, linking time [1], etc. There is a 
considerable performance penalty imposed by the paging in libraries on 
demand, so I wouldn't be surprised if that changed. You're also forgetting 
that the layout of libraries is never optimal, so the RSS footprint is 
considerably larger than the actual working set. Unless something is in an 
entirely different object file section (like say the EH or debug info tables) 
I don't think you can say it has no effect. 

> We know that a lot of applications written in C use glib already. In fact,
> its unlikely to find a linux system where there is no gtk+ application
> installed that the user wishes to use. 

Well, if user chooses a Gtk+ application and not a KDE one, we're not working 
hard enough. Thankfully, I don't need to use any; and I don't see any reasons 
why people other than artists (who may need gimp) would need to as well; 
perhaps my needs are atypical, I don't know, but if they are, this sounds 
like a good opportunity for you to point out areas that need work.

> That is possible in the following ways:
>  - depend aRts on Qt
>  - depend Qt on glib
>
> I think if we were to evaluate these two alternatives carefully, we would
> find that the second is more beneficial, because again its unlikely that a

Sorry? The second alternative is IMHO just unmaintainable code bloat, since 
glib is completely and utterly useless when you already have Qt; especially 
since in large part it tries to work around, and is hobbled by the 
inadequacies of C. OK, it's the choice of people who want to deal with it, 
find; but that's definitely *not* a good reason to pollute Qt code with stuff 
like that.

> user would suffer from serious problems, because he has committed himself

Serious problems? Sorry?

> In fact, I am convinced that some things should be implemented in C. And I

I am not convinced that it's the case for any things that are in any way 
relevant to this list. I /am/ convinced that's the #1 reason for using C is 
ignorance; since it's extremely rare to see someone asked about their choice 
respond by something that's not complete nonsense, at least in my experience. 
Again, I may have a bad sample.

> We only should support those users optimally that want to use whatever free
> software is best for the job, without religious attachments to what
> language, race, country, free software project, ... is best for the world.

Hmm last I checked our stated goal was to provide a consistent and uniform 
desktop based on the KDE/Qt libraries; and a good modern development 
platform, not to advance the free software ideology. Did I miss something?


[1] Since glib does use tables of pointers, it faces some of the same problems 
we do with vtables, only on a smaller scale