Linux Today: A Look at Kernel Cousins and KDE Myths
Saturday, 20 July 2002 | Numanee
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:
funny... - jd - 2002-07-20
... just the other days I thought about how his name keeps popping up everywhere. He sure keeps busy. Thanks for your work, Aaron! :)
Myth - "KDE Applications and Speed" - steve - 2002-07-20
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.
Re: Myth - "KDE Applications and Speed" - Aaron J. Seigo - 2002-07-20
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! =)
Re: Myth - "KDE Applications and Speed" - steve - 2002-07-20
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?
Re: Myth - "KDE Applications and Speed" - Anonymous - 2002-07-20
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.
Re: Myth - "KDE Applications and Speed" - Anonymous - 2002-07-20
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.
Re: Myth - "KDE Applications and Speed" - Stephan Oehlert - 2002-07-20
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.
Re: Myth - "KDE Applications and Speed" - cv - 2002-07-20
i like that you step forward , could anyone who already read all the stuff take the lead in the "optimisation project" ???
Kde Myths - KDE Myths - 2002-07-21
[ed: this is a systematic troll/abuser] <!-- The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts. Myth #1 - KDE is more integrated than GNOME The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means. Myth #2 - KDE is easier to use Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org] [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian [ximian.com] [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations. Myth #3 - KDE is more popular In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all. One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues. Myth #4 - Konqueror is the best Linux browser Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development). Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit See also: Qt/TrollTech. This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2. GNOME applications get much more testing in their 0.x stages and despite shorter development phases they mature and reach stable featureful release states much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead. It's not only in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further. It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property. Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself. Myth #6 - KDE is faster and takes less memory than GNOME KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems. Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth. Myth #7 - GNOME development is slower. KDE releases faster. Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz. -->
Re: Kde Myths - Andy - 2002-07-21
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.
Re: Kde Myths - James - 2002-07-21
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.
Re: Kde Myths - GNOME_lies - 2002-07-21
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?
Re: Kde Myths - Fredrik C - 2002-07-22
If the root topic off the thread is beeped out shouldnt the whole tread be killed? Just leaving the pro KDE replies seems like to much bias.
Re: Kde Myths - Mebbe so - 2002-07-22
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.
Re: Kde Myths - Anon Man - 2002-07-29
It was *not* originally planned. They were planned to get in by G 2.2 Just setting the record straight. Thx
Re: Kde Myths - Troy - 2003-12-01
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.
Re: Kde Myths - Datschge - 2003-12-02
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).
RAM Drive solution to the speed issue - D. Imm - 2002-07-23
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 :)
Re: RAM Drive solution to the speed issue - Evan "JabberWokky" E. - 2002-07-23
:: 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
Re: RAM Drive solution to the speed issue - D. Imm - 2002-07-24
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.
Re: RAM Drive solution to the speed issue - Bob S. Laquer - 2002-08-26
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 :-)