glib dependancy in KDE3.x
mo002j at mail.rochester.edu
Fri Mar 7 16:51:13 GMT 2003
> 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.
You're grossly simplifying things here, by ignoring the effects of disk
latency, readahead, cache pressure, linking time , 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
> 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?
 Since glib does use tables of pointers, it faces some of the same problems
we do with vtables, only on a smaller scale
More information about the kde-core-devel