JUL
19
2002

Linux Today: A Look at Kernel Cousins and KDE Myths

Linux Today takes a closer look at Kernel Cousin KDE and the new KDE Myths site, particularly how they originated (1, 2) as a community effort by Aaron J. Seigo. "Our spotlight here is on Aaron's KDE Kernel Cousin. Aaron started as "a happy KDE user." But he wanted more. He wanted to get involved in the KDE project himself, so to him that meant getting to know as much about the people, culture, and goings on as possible. Soon he found himself on not only kernel issues for KDE, but also on more than a dozen other lists related to various aspects of KDE development. Several thousand pieces of mail a week flooded into his mailbox." A great read and a nice tribute to Aaron.

Comments

... just the other days I thought about how his name keeps popping up everywhere. He sure keeps busy.

Thanks for your work, Aaron! :)


By jd at Sat, 2002/07/20 - 5:00am

First, props to Aaron for his great
work on the cousin and I think the myths
page is an excellent idea.

I do think the myth about speed has some
room for improvement, though.

It would be nice to see specific mention
of tools by name and version number in
which fixes/tools are included -
combreloc, binutils, g++. Right now
it is very vague about when and how
the typical linux user can get these
fixes.

BTW, there doesn't appear to be a consolidated
source of info on how/when this problem
is being addressed. For example,
I have compiled my system with combreloc
and kde3 is using kdeinit, so it seems my
linking is happening as fast as possible,
no? Are there other fixes in the works?
It's hard for me to tell if they are not
mentioned by name.

The docs for object prelink 2 seems to
imply that with combreloc applied *today*,
the linker is no longer the bottleneck
for starup times:

http://objprelink.sourceforge.net/

I think the existing description of this
"myth" gives developers the easy way out just
a bit - as Waldo pointed out, it will
be nice when the linker "excuse" goes away.

Perhaps we can make the excuse go away
earlier through careful documentation?

For example, the myth page could be recast
to include install instructions (or
pointers to them) for combreloc, and
a running list of distributions that
are compiling with it.

The second issue - startup times from
NON-kde desktops (w/out kdeinit) could
be discussed separately, and addressed
by saying the fix will be included with
gcc "sometime after version 3.1." Then
update the topic when the fix actually
comes out, and list distributions
that are shipping with binaries compiled
by the new gcc.


By steve at Sat, 2002/07/20 - 5:00am

the speed issues regarding linking are largely felt on non-KDE desktops, indeed. and this is also where the improvements of the linker will be felt. as for specifics, i lack the resources locally to test and experiment with things enough to get the details. if you (or anyone else) can send some specific information on it, i will indeed add to / modify that entry.

and yes, over time, the entries on kdemyths will change to reflect the current reality. maintenance of the information will be key to making it a useful resource.

i've recieved dozens of emails from various people with updates, suggestions, corrections, additions, proof-readings , etc... and that has only made the site better. i hope that trend continues as i'm just one guy and i'm quite fallible. having community interest and support is the only way the information will ever be worthwhile. fortunately, that interest is currently there! =)


By Aaron J. Seigo at Sat, 2002/07/20 - 5:00am

Thanks for reading...specific details about
versions of libraries that will address linking
speed are hard to come by, even on the mailing lists.

Perhaps readers here can help?

- are there any other linker fixes in the
works that will help launch speed from kde,
beyond those described here?
http://objprelink.sourceforge.net/objprelink.html

- is it true that combreloc is included in
versions of binutils >= 2.12 ? (I am running
2.12.90.0.7, and I do have combreloc - see
this link to test your system:
http://objprelink.sourceforge.net/howto.html)

- are any distributions shipping with combreloc
enabled right now?

- what version of gcc/glibc does/will contain
the fix to make apps started without kdeinit
link as fast as apps started with it?


By steve at Sat, 2002/07/20 - 5:00am

Following the test on http://objprelink.sourceforge.net/howto.html KDE packages for SuSE 8.0 (KDE 3.0.1) seem to have been linked with combreloc.


By Anonymous at Sat, 2002/07/20 - 5:00am

All news in the dot end up having comments about speed.
Might KDE team leaders launch a campaing to recruite developers interested in stuff such as optimization, etc.?
I might be interested in doing so. I worked during last year optimizing soft.
There are a bunch of things that can be done when you want to optimize a soft.
But, previous to taking a look to the code, I would like to read a report of one/some of the KDE team leaders, where he/she/they explain which are the places where the bottleneck is, what can be removed, which apps need it. etc. And then a small overview of KDE system and how to learn about it to understand what is going on. I don't have the time to organize a team, but I could work on a "optimization team" if a "leader" shows the way of what to do to each one of the developers.
Really, this stuff needs to be solved and a serious study has to be done.

Thanks.


By Anonymous at Sat, 2002/07/20 - 5:00am

To get more information about it you should first read through the KDE KCs (which this article was all about....) and then search the mailing list archives. _Everything_ has been discussed there already.


By Stephan Oehlert at Sat, 2002/07/20 - 5:00am

i like that you step forward , could anyone who already read all the stuff take the lead in the "optimisation project" ???


By cv at Sat, 2002/07/20 - 5:00am

[ed: this is a systematic troll/abuser]


By KDE Myths at Sun, 2002/07/21 - 5:00am

You bring up a lot of valid points about KDE and Gnome but please don't assume the KDE people are trying to imply that KDE is superior to Gnome.

Also, KDE does have some advantages over Gnome that matter to the users. I use KDE because it looks pretty and *feels* integrated. I keep my Gnome (and E and WM and Black Box and etc.) installation up to date and occasionally try it out but I keep coming back to KDE because Gnome is less pretty and lacking a complete (and functional) configuration application to tie all the pieces together (sure, there are many fine configuration apps for all the pieces for Gnome but I want them all in one place like KDE's Control Center).

I hope this sheds some light on why so many people have the "Wow! KDE roolz." mentality.


By Andy at Sun, 2002/07/21 - 5:00am

Wow! I debated even responding to this. It is this kind of emotional outgassing that make me want to barf. Does anyone really want to even TRY Gnome after something like this. If you are going to come to a KDE message board and post about GNOME, try to be constructive. If GNOME is better, than bring ideas about how we can work together. Free software is about having FUN, you have your party and we will have ours. If we can, lets work together.


By james at Sun, 2002/07/21 - 5:00am

1) Integration means that distinct parts of KDE know about each other and are able to react to eachother. Sort of what GNOME tries to do with Bonobo but the technologies in KDE are much easier to use so that, unlike most GNOME applications, KDE applications actually take advantage of this.

2) KDE is easier to use. That's why more people use KDE as you admit in point #3. KDE resemblance on MS Windows in certain ways contributes to KDE's ease of use by tapping into the habbits that many computers users have developed over the years. KDE makes decisions based on what its users want, not based on what the marketing departments of Sun or HP wants. If Sun would be listening to its users it would have ditched CDE a long time ago in favour of KDE.

3) KDE is used by more people. I'm sure you will be able to find small groups of Mexican immigrants who prefer GNOME, good for you, good for them.

4) Konqueror may not be the best web-browser, yet many people prefer it over Opera and Mozilla because it integrates (see 1) very well with the rest of their desktop and handles real-life webpages well.

5) The author fails to mention that many of the applications listed don't use GNOME libraries at all because their authors don't want to depend on the dependency hell that GNOME is. In fact they don't consider their apps part of GNOME at all. GNOME easy to develop for? Many of its alleged own developers don't even want to use it!

6) The author here tries to impress you with a mixture of C++ terms he looked up in a book and insults. You might also notice that he doesn't really deny that KDE is faster. At the end he confuses "KDE architecture" with "poor design choices in the GNU linker". Luckily the linker developers have recognized this problem and are currently fixing it. Soon the Linux linker wil be almost as good as the linker on e.g. AIX (which never suffered from this problem).

7) The author here stresses the fact that you need RedCarpet to constantly upgrade the dependency hell that GNOME is. Then he explains that users (he refers to them as "lamers and newbies") do not appreciate this but prefer KDEs understandable platform versioning. He seems to confuse disorganized with fast.
If GNOME development was so fast and advanced, why are the majority of GNOME applications still not ported to GNOME 2.0 as originally planned?


By GNOME_lies at Sun, 2002/07/21 - 5:00am

If the root topic off the thread is beeped out shouldn’t the whole tread be killed? Just leaving the pro KDE replies seems like to much bias.


By Fredrik C at Mon, 2002/07/22 - 5:00am

This troll posts the same message over and over and over again, could be posted by a robot for all anyone knows. Deleting the considered responses is, well, not nice to those who took the time to write them.

As to bias: this is the KDE news site. Of course it's biased - the very name indicates that. Oh, and when you find an *unbiased* news site - please do let me know, been searching my whole life for that.


By Mebbe so at Mon, 2002/07/22 - 5:00am

It was *not* originally planned.

They were planned to get in by G 2.2

Just setting the record straight.
Thx


By Anon Man at Mon, 2002/07/29 - 5:00am

Most of your problems seem to stem from the fact that gnome is a body of projects as opposed to a single project like kde. Personally i am coming to love KDE because of said integration,as well as the fact that while groups (ximian for instance) are building more and more gnome related proprietary projects, kde related groups seem to be going more and more libre. Oddly the proprietary nightmare that caused the creation of gnome in the first place is gradually becoming a free software paradise. However I would like to see a bit more variety of choice in my desktop environment, but it seems karamba is doing this gradually.


By Troy Unrau at Mon, 2003/12/01 - 6:00am

KDE is not really a single project either but also a body of differents subprojects each having their own goal. But due to the high amount of shared code resulting in high integration this is not exactly apparent from outside (many of the subprojects' websites sadly being seldomly updated doesn't help either here).


By Datschge at Tue, 2003/12/02 - 6:00am

Could we not provide the following solution (or does it exist already?)...

Keep your main system as a console based linux box. Then have a separate RAM drive that contains X and KDE. Once you run startx, X and KDE are then run entirely out of the RAM Drive. A startup script could then load a list of your favourite applications (such as Konqueror) into RAM, so that when you actually click on the Konqueror icon for the first time, it is already linked and ready for use. Every application would then load directly out of RAM and not from the hard drive. So in theory, each of those preloaded applications would load instantaneously.

To me, KDE startup time is irrelevant. It could take 5 minutes to load and I would still be happy IF the applications responded the way I am used to under Windows. For example, IE and Word, on second load, are instantaneously available on my PII 400 with 160MB RAM. This is what I am used to, as is true with millions of other Windows users.

Another advantage would be the following: Even if KDE, or X dies on you (for whatever reason), you can simply kill the RAM Drive and fire it up again without it affecting your actual Linux box underneath. Maybe X would have to be replaced with a GGI server so that it can be run as a non-super user process?

I would gladly buy another 128MB DIMM (or 256MB DIMM) just for this purpose.

My personal solution is to load every application that I use on a regular basis on a separate desktop on first login and then to flip between desktops as and when I need to use a particular application. I never close the applications, I just simply change desktops. This solution is okay and it certainly works, but I am bending myself to work around KDE , and not the other way around.

On a positive note, the way that you can modify application shortcuts, tollbars, dialog boxes etc. to meet your personal needs is wonderful, please keep that as it is in future versions of KDE.

Flames and comments welcome :)


By D. Imm at Tue, 2002/07/23 - 5:00am

:: Then have a separate RAM drive that contains X and KDE. Once you run startx, X and KDE are then run entirely out of the RAM Drive.

I tried that (well, moved KDE onto a RAM Drive). It didn't make much of a difference. I didn't really expect it to, either. I was just curious.

:: ... so that when you actually click on the Konqueror icon for the first time, it is already linked and ready for use.

There's been some work toward that. One of the handheld systems has a linker that does basically the same thing to the executable binaries. It prelinks them statically against a lookup table, and shuffles everything around so every binary resolves correctly. It results in a space saving a speedup in application startup time. Borland and Mix's linkers did some neat stuff too.

Realistically, the problem lies in the compiler/linker you use. As has been pointed out, if you use the compiler provided with a different Unix, you don't have these same problems (you may run into others, YMMV). The Gnu compiler, linker and system library are incredible in terms of functionality, and abysmal in terms of speed and efficiency. Intel's and Borland's compilers for Linux blow gcc out of the water both in resulting excutable speed and in compilation speed - not a difficult task to accomplish. I am curious as to if anyone has tried using these C++ compilers on KDE.

The gcc folk are working hard at improving the compiler and linker, but there is so much code out there that is dependant on extremely specific behaviour of both those tools (notably the Linux kernel) it hampers their ability to make advancements that are compatable with language definitions, but incompatable with the precise behaviour of the previous versions. Objprelink and the like are really ugly binary hacks that depend on the way the current linker works. Unfortuantly, there are lots of applications out there that depend on stuff like that. KDE does not - portability breeds robust code, and KDE is very portable. But it does mean that your performance will vary depending on the performance of your compiler, linker and system libraries.

--
Evan


By Evan "JabberWok... at Tue, 2002/07/23 - 5:00am

Thank you for this reply Evan :)

From the Intel website ...

"This free Non-Commercial Unsupported download contains Intel® C++ Compiler 6.0 For Linux"

http://www.intel.com/software/products/compilers/c60l/noncom.htm

For all the people out there that can download this software and compile KDE using this compiler, please try to do so. After all, KDE is open source, so let us try and use this compiler to see if we get a speed boost.

Thank you.


By D. Imm at Wed, 2002/07/24 - 5:00am

What you want to do was actually done in the early stages of
portable computing. Namely the first generation of HP Omni-
Books had 40 megs of ROM (or it could have been EEPROM)
allowing the entire DOS/Win3.x OS/GUI to be stored forever
unachangable in system ROM as well as the typical business
apps of the day. This in turn meant the machine booted near
instantly. The downside to this approach was obvious - it
prevented owners from making upgrades to the software in ROM.

Another solution to what you want to do has also been achieved
and at greater capacities by taking ordinary RAM sticks, a 5
1/4 inch drive, and a battery and/or hard drive of equal capacity
(for backing up data in case of power failure). This is a RAM
drive/RAM disk. They cost a terrible sum of money but give you
access to gigs of data at .1 ns versus the access time of today's
hard drives, there are no moving parts, and they are not
affected by magnetic fields. There are also cache cards for an
expansion slot giving you the function of a hard drive in some
cases or that of insanely high cache RAM :)

The last I read on these cache / RAM drive expansion cards is
they offer 4 and 8 gigabytes each. As a RAM drive it actually
is seen by the PC as a hard drive even though it uses 1 GB RAM
sticks (4 sticks = 4 gigs). Personally though I see no reason
why someone cannot create a much higher capacity RAM drive for
a drive bay with 40 or more gigs capacity using FLASH memory.
No need for power to keep the data, no moving parts to wear down,
no loss or corruption of data from a magnetic field, ideal for
industrial uses as shock isn't an operational factor to
consider :-)


By Bob S. Laquer at Mon, 2002/08/26 - 5:00am