[kde-solaris] KDE 3.2.*, Solaris 9, and other news [ was: swap space requirements ]

[Stefan Teleman]

I'm back at home, thus i can post some more. :-)

On Monday 26 January 2004 10:47, Philippe Bourdeu d'Aguerre wrote:
> >         a) shrink KDE
>
> Is it impossible ? I notice that when I launch an application from
> a shell there are lot of debug output. Is it possible to suppress
> them ? With Linux-Mandrake there is no such output.

I believe it is possible to shrink KDE somewhat. This little 
explanation below is going to be a little long, tedious and boring, 
so, if you don't feel like being subjected to it, please feel free to 
stop reading. :-)

IMVHO opinion, there is one main reason for the RSS and PS sizes 
described by Lars: KDE makes very extensive use of dlopen() with 
RTLD_NOW (which means, resolve and bind all symbols at load time). 
Not only that, almost all processes started from within KDE are 
started by kdeinit which then fork()'s (which explains the presence 
of so many kdeinit's being swapped out). The dlopen()/RTLD_NOW trick 
has some advantages, by giving a performance boost (no need to 
resolve and load symbols run-time). It was also implemented because 
of gcc and the problems with the GNU run-time loader which could not 
(still can't ? -- i hear the situation is improving) do symbol 
relocation.

Disclaimer: i am not criticizing KDE by any means. I am only 
describing some aspects of its internal architecture.

So, in theory, all this dlopen() stuff could be safely removed from 
Solaris KDE, because the SunOS run-time loader has no problems 
relocating symbols. But this would require one of the following 
things:
	- create a separate source code branch for KDE Solaris (which would 
probably work, but it's not a Good Thing To Do by any means) -- it 
makes source code upgrades and patches between releases a complete 
nightmare.
	- keep only one branch, but fill the code with #ifdef's -- guaranteed 
to make the code incomprehensible and unmaintainable within 6 months, 
and also guaranteed to be veto'ed by kde-core-devel
	- remove all dlopen()'s completely, which runs the risk of breaking 
KDE on GCC, and also requires some significant rewrites in kdelibs 
and kdebase.

The other aspect is: being written in C++, KDE binaries will incur a 
size overhead because of the exception mechanism, if nothing else. I 
can disable exceptions at compile-time, but that is not a good idea. 
The only way of guaranteeing that something does not throw, is to 
declare it with a throw() exception signature. Neither KDE nor QT 
declare exception specifications in their method signatures, so, 
anything can throw. In the unfortunate case that something throws, 
but the exception mechanism was disabled at compile-time, the 
behavior is undefined, and it is also close to impossible to debug, 
or even track down.

And now, you can flame me. :-)

OK, now for the news:

I have gotten my hands on a second Ultra60 box (2x450 UltraSPARC II, 
2GB RAM Elite 3Dm6 :-), and i installed Solaris 9 on it. Which, for 
the purpose of working on KDE, is Da Bomb. I was trying to get an 
UltraSPARC III box, but, to paraphrase someone else's post on a 
different newsgroup, these things cost an arm, a leg and the original 
Mona Lisa, even refurbished. I am now working on 64-bit KDE, and i 
have started by working on those required 90+ little libraries last 
weekend. I cleared a major bump this weekend when i got 64-bit NAS to 
work. I am building for v9a. I am hesitant, at this point, to give a 
precise timeframe as to when the whole 64-bit port will be finished, 
but i just wanted to let everyone know that i am indeed working on 
it, as of January 17. When it's done, it will be only for Solaris 9. 

As far as KDE 3.2.* goes: i'd like to wait until the first 'official' 
release is out before i start working on it (32-bit and 64-bit in 
parallel).

--Stefan

-- 
Stefan Teleman          'Nobody Expects the Spanish Inquisition'
steleman at nyc.rr.com                          -Monty Python