Slashdot Log In
KDE Developer on the GNOME Foundation
from the war-rages-on dept.
The following was written by Slashdot Reader and KDE Core Team Member, Kurt Granroth
One developers Opinion of Sun + GNOME
Recently, Sun and HP (but mostly Sun) announced that they will be using Gnome as their default desktop. As a member of the KDE Core Team and as a US press-rep, announcement, I have been asked more then a few times what KDE thinks of this. I have also been asked if KDE user should be worried about the future of KDE now. I've given a rough idea of what "KDE thinks" to those journalists.. but the answer must be pretty generic since KDE is too distributed and diverse to permit me to speak for everybody.
But the wishy-washy answer that I am forced to give doesn't mean that I don't have strong *personal* opinions on the matter -- I do. So I'd like to take this time to offer a few of them for your enjoyment.
I look at the Sun announcement and I try to imagine how it can effect the KDE project. Let's look at the absolute *worst* case situation (from our point of view). Say Sun and HP contribute a significant amount of top-notch programmers towards the Gnome project and as a result, they overtake us. Perhaps for the first time, Gnome is better designed, easier to program for, easier to use, and more stable then KDE. Meanwhile, with the momentum gained by it being the "commercial Unix standard", more and more vendors use Gnome in porting their apps without giving KDE a second thought. Maybe as a result, even "Joe Hacker" in his dorm room might not want to work with KDE.
That's the "worst" case. But say, even if that *did* become true (doubtful, see below), it still wouldn't take away from the fact that KDE is very well designed, incredibly easy to program for, intuitively easy to use and rock solid stable. We have managed to attract hundreds of developers and millions of users to KDE and we will continue to attract the numbers after words. Remember, even if Gnome does become a great desktop, that doesn't mean that KDE will stop being a great desktop. Put another way, KDE will always be around and it will always be a worthwhile desktop to use and platform to develop on.
But let's back-pedal just a bit. I personally find the above scenario *incredibly* unlikely. It has never been shown that throwing more developers on the project will guarantee that the project will succeed, and you can show that it often makes no difference at all. Sun may have a lot of developers, but it remains to be seen if it will matter.
I have reason to be skeptical. Let's not forget just how the backers of the Open Group/Motif and CDE were. That's right -- Sun and HP. Two large companies with all their resources thrown at this that couldn't compete with *either* Gnome or KDE. The Sun website talks glowingly of all the really cool things they will do with Gnome... but those with a memory (and a web browser pointed towards the Open Group's website) will remember that Sun said pretty much the same thing for Motif/CDE.. and look where that went.
No, Sun's developer resources don't worry me in the slightest. We have already shown that we can take them on and win convincingly. I don't see that they will magically change anytime soon.
I do worry a *little* bit more about the PR aspects of this, though. There will be a temptation among the less-dedicated journalists to say that now that Sun and HP and RedHat all favor Gnome, then it must be a standard for Unices. After all, everybody knows that Linux *is* RedHat, right? I am already seeing mentions of this and as people jump on the bandwagon, we'll likely see it even more.
This may have nothing to do with any kind of reality, though. Already, for every new Solaris or HP workstation, there are likely several computers running Linux. Looking at the demographics of all the Linux distributions worldwide, we see that KDE focused distributions are still the norm. All in all, there are likely a LOT more workstations running KDE then there are running something else.
This somehow brings me to the another question that has been frequently asked: Will KDE ever have a corporate-backed "foundation" deciding it's future? While I'm not arrogant enough to think I can guarantee what the future will hold, I am still reasonably secure in saying that pigs will probably fly first. A board like that flies square in the face of everything that the KDE project stands for.
KDE is, has been, and always be governed and managed by those *developers* that actually do the work on it. Working code is what matter, not your market capitalization. Commercial entities may sponsor development on various aspects of KDE, but they will never be allowed to decide what KDE will become. KDE is a desktop "by the people and for the people" and if we were to prostitute ourselves to big-money for the chance of being a media-recognized standard, we would be stomping on all the people that have supported, developed, and used KDE throughout the years. We can honestly say to all developers that if you contribute good code to KDE, we will welcome it and assure you that it will never be subject to the whims and fancies of a company under the gun from shareholders. Your code will be judged purely on it's merits. More to the point, your contribution will make a difference -- it will *matter*.
I do find it ironic, though, that it is *Gnome* taking this step. Could anybody have possibly imagined this when Gnome started? Weren't they the "hacker desktop"? Didn't they have all the "desktop for the people" principles? Hmm... times change, I guess.
But back to KDE and the possibility of a great Gnome. I get the feeling that most of the people that are comparing Gnome and KDE are doing so with current Gnome and KDE 1.1.2 (or less). Even though a version of KDE that *old* still compares favorably, it's a pale shadow to the upcoming KDE 2.0. A comparison between current Gnome and current KDE (in my opinion, of course), shows KDE really shining. I *strongly* urge everybody to check out 2.0 before jumping to any kind of conclusion -- it is a truly kick-ass desktop with by far the best development architecture out there.
So I'll end this longish, partially incoherent ramble with this disclaimer: These are all my personal (largely un-filtered) opinions on these matters. They *may* reflect the views of other KDE developers, but there is no possible way I'm going to be presumptuous enough to claim that they *do*. I may be a little bit pro-KDE in thinking it is superior to Gnome, but I still have the utmost respect for the Gnome developers themselves. I've met a number of hackers -- both "free-agent" ones and HelixCode/Eazel/RedHat paid ones -- and all have demonstrated immense talent and a genuine hacker mentality. Please don't take any of what I said as a attack on *any* person or persons.
You're forgetting something (Score:3)
Re:I Apologize in advance (Score:3)
Seriously, do you look at slashdot more then once in 6 months? have you seen all the KDE 2.0 beta's? so WHAT ARE YOU TALKING ABOUT??
Next Week, KDE 2.0 RC1 (Release Candidate 1) will be out - I suggest for you to grab the binary files or the source code (you can also CVS checkout now also) - and compare both..
So please, check facts before you post!
Should be interesting to watch (Score:3)
Re:I do not undertand all this. (Score:3)
Some (note: *some*) KDE developers feel that GNOME has not really contributed so much yet and that there are more words than there is code.
GNOME seems to pull existing projects into its base, such as Gecko, AbiWord, now StarOffice, etc. While "joining" these efforts and binding them (see GNOME as the glue) is a nice accomplishment and a great effort, some KDE developers feel that the actual coding progress is within KDE, having it's own Office suite, it's own HTML renderer, etc etc. Despite all the external contributions GNOME still hasn't caught up and some developers like to express that.
Personally I wanted not to have any KDE reaction on the GNOME foundation, as (in practice) it doesn't affect KDE development at all. Most KDE developers are coding right now, not engaging in this discussion.
Re:You're forgetting something (Score:3)
Seriously, if you have a half decent computer, it should be plenty of RAM for running multiple widgets and libaries at the same time.
Especially, when an fast machine can have dual 1 ghz proccessors and 1024 meg or so RAM.
Heck, I am stuck with 32 megs of RAM + 64 megs of Swap, on a PowerMac 4400/200 (with a 603ev processor), and don't have any problem running (right now) KDE + Netscape + X-Chat + xmms + gnapster. It gets a bit slow from time to time, but it's really not bad most of the time.
Also, consider using a recent version of Linux 2.2, it has very good swap mangment.
Re:You're forgetting something (Score:3)
Since for the most part applications overlap between the two nicely, it's not that big a deal to keep the segregated.
Finkployd
Re:Let the licensing flamewars begin... (Score:3)
I think that your analysis of the licensing problems is quite right. The two responses that are usually given are also usually countered with the following arguments:
But there is hope, especially about the second point... As reported on Wednesday, Mozilla is going to be dual licensed [slashdot.org]. In order to change the license, they will get in touch will all contributors in order to be sure that they agree with the re-licensing. More precisely, as explained in their relicensing FAQ [mozilla.org], they will make a reasonable attempt to contact and obtain consent from each of the contributors (it may not be possible to contact all of them, so the law only requires them to be able to prove that they made a reasonable effort).
If the Mozilla team can do it, then the KDE team should not be scared to do it. Maybe there is still hope for KDE2 to be released with the "Qt exception" in all source files. This would put an end to this licensing controversy, and this would benefit KDE (a lot!).
This would probably not end the GNOME vs. KDE flamewars, but at least they would have to consider some more technical arguments instead of flaming KDE for its licensing problems.
Re:-1 FlameBait (Score:3)
If you spent any time in the OSDN booth at LWCE, you found a lot of Andover employees and volunteers talking about the "death of KDE" with smiles on their faces. This was especially ironic since those folks in the FSF, GNOME and KDE booths seemed to get along quite well.
Re:He's right, except that GNOME ain't superior (Score:3)
Okay... that's purely subjective... I actually personally like the look and feel of KDE 2.0 much better than Helix Gnome. I liked the "Feel" of KDE 1.x better than earlier Gnome, and since at the end of the day, I need to get work done, I went with KDE from 1.x.
But it's all subjective here - I don't think anybody wins on superiority,
When you start an Helix Gnome session, and type "free", you simply have 9 or 10 more free megs than when you start a KDE session (1.1.2 or pre 2.0), for similar functionnalities.
Yes, but I've noticed that KDE eats less memory per app. I *really* looked into this because of a memory leak in a beta of 2.0... I played with KDE + only Gnome apps, BlackBox + KDE apps, and some other combos. Lots of experimentation, but no hard numbers - the apps that *you* run may lead to different results. I'd wait until 2.0 is final release anyway... having followed the alphas for some time, they get leaner each release - the developers seem to take a "make it *work* now, and *then* optimize it".
Free software was supposed to bring "obsolete machines" back to life, or at least to slower the rythm of obsolescence. So, yes, this matters. The situation is similar when it comes to speed.
Not to me. I run dual Celeron 350, Pentium II 450, and a dual Pentium 700 as my desktop machines (work, home experiment, home office in order). Every one runs KDE of all flavors with no problem in 64 megs of RAM. (When I got the new dual 700, I had to spread out memory... it was a month before I got some new memory).
In average, a Gnome/Gtk tool is ~30-40% smaller than its KDE/Qt counterpart.
Okay, are you taking memory footprint or size of the file on disk? And *how the hell do you compare*??? Sure, on disk, the kword binary (a nicely featured word processor) is 3428 bytes, and abiword (a nicely featured word processor) is 1053 bytes. Somehow, I don't think that's the end of the story. Even when they're loaded, is it with an empty document? A paragraph? An embedded spreadsheet, several multimegabyte images, and an mpeg?
I've always hated the "show me the numbers" game (because it so often can be balanced either way), so I'm just going to say - all apps run fine on everything I'm going to use 'em on. They all do what I need. I like the potential of KOffice, and I think stability and interoperability is much more of a priority (not *better*, not *worse*, just a higher priority) than many gnome apps.
KParts seems to work pretty well, yet it's just a smart ad hoc and proprietary hack.
*Bzzzt.* Name calling is no way to promote *or* disgrace. Linux is a "smart ad hoc and proprietary hack". So is the GPL, Bonobo and how I set up my pavilion at SCA events. "Hack" is an elegant solution to a problem in *my* dictionary. Everything is propritary to the people who use it.
Roughly, it replicates OLE/COM.
Not a bad thing, if done right... and Konqueror is *damn* fast. As fast as IE on a speedy winbox, and that is fast.
I won't tak about Gtk+ and Qt, yet there's also a lot to say about this.
And it's going to be shortly clear who is hiding spite behind a veneer of religious indignation: http://lists.kde.org/?l=kde&m=9664 2933010813&w=2 [kde.org].
--
Evan "Who uses KDE2 on BlackBox for a lean, powerful desktop" E.
Re:Please keep in mind.. (Score:3)
This editorial is a different case indeed. I've never heard a developer call corporate backing "prostitution" before. Say what you will, but I think being paid to write free software is a hell of a lot better than being paid to write proprietary software at work, then coming home to write free software. Tell me: which one was selling out again?
Bloat+Bloat ==Solaris+GNOME. (Score:3)
PS> With the coming of GNOME, KDE, and Mozilla, have you noticed how many Linux zealots have removed "bloated" from NT's list of transgressions?
Re:Standardisation (Score:3)
gnomecc
kcontrol
The only reason kcontrol has anything more is because it includes settings for kwm, whereas gnome relies on a separate WM.
So I ask you again, who gives flying f* what "desktop environment" you are using? They do NOTHING. It is the programs that do everything. I run KDE, but I program in GTK only. Incompatible programs are a pain in the ass (although I hardly experience any problems currently). Imagine trying to tell a Linux newbie that he can't copy and paste between two different applications because of what they were programmed in.
To conclude this rant, let me say this:
I should be able to use any program made for GNOME or KDE, almost to its full potential, with a program made for the other "desktop environment". In TWM. Period.
Re:A plague on both your houses (Score:3)
Not a big appreciator of art, are we? I've seen a lot of pictures that convey love in a lot of ways better than any number of words. I particularly like Klimt's "Fulfilment".
Your message reads like flamebait, but you hit a nerve with me, so I'll take it.
Language is a very powerful medium for communication. I'll give you that. However, language was designed to work with certain hardware limitations: humans can't display imagery as complex as a computer in real time. They can talk, write, or wave their hands; all relatively light data streams. Furthermore, computers, while they do posess very wide information bandwidth, cannot understand human language in any meaningful way. They can be set up to recognize certain character streams in a certain way, but in no way does their use of text streams approximate the power and flexibility of language.
If you don't like GUIs, that's fine, don't use them, but please don't make it sound like GUIs are somehow starving users of information. People can take in more data in image form than in straight-line text. The coded metaphor of visual interface is highly effective for communicating functionality of objects without explicit enumeration. For example, when I'm using a programming language, say C++, I spend a lot of time checking the STL docs: "What operations exactly does a map support?" Sometimes, simple, language-based, but ultimately visual metaphors help: the difference between a stack and a queue is fairly intuitive from their names. However, in a more complex functionality space, or in a situation where time resources do not lend themselves to such intense study of documentation, a simple picture may help a lot. Take, for example, the VCR-like controls on most GUI media playback applications. Have I ever had to look up how to play, stop, rewind, or fast-forward a media stream in any sort of resource with a GUI tool? No. I just know, because the image of the buttons serves as a pointer to media-playback knowledge I already have. It hashes into the part of my brain where information about how to work stuff is stored. On the other hand, lets look at something like say, mpg123. Playing a file with mpg123 is obvious only from my experience with similar crappy command line tools: "mpg123 ". But how do I interact with it when playing? How do I play multiple files? How do I skip over the files when playing through a bunch of files? How do I rewind to something? None of this is obvious, if it is even possible. If I ever want to know how to do this, my workflow is broken, I must look up mpg123 in the manual. There is nothing inherently wrong with learning how to use all of your tools extraordinarily well, it's just that often, time resources are not sufficient to allow such intense study of documentation for all the tools that must be used. The first time I used xmms, I was playing files and manipulating playlists instantly, with no documentation study at all, the time saved gets me back to code.
Let's take another example: GUI configuration. I run fvwm2. Whenever I want to change something simple, like a color of something in fvwm2, I need to go through a long textual configuration file and hope I can judge from context what line sets the color. Often, the color is not explicitly set, it's a default, so I need to start paging through some documentation to find out how to do it. Now, fvwm2 is incredibly flexible, in part because of these files, but for certain simple tasks, it is a huge pain. In windows, on the other hand, when I want to change a color, I go to the "Colors" dialog box. There is a miniature image of the window interface. I click on the part I want to change, then I click on a color to change it. How intuitive is that? There is no need for documentation because the picture of the windows exactly communicates what I am changing. There is no wondering what "inactive child area" is. Is it the area in the focused program that isn't being used? Is it the area unfocused windows? Not obvious. With a GUI, I click on what looks like what I want to change. Faster, easier, no studying needed, I'm back to work.
Funny you should bring up autocad. Most of the people in the place I work spend their whole day in autocad, much like I spend my whole day in xemacs and some shells. In this situation, extreme customizability and speed of textual interaction easily triumphs over intuitiveness of use. Autocad is hard, like vi/xemacs is hard. It's for experts. There are no casual autocad users. That's fine. However, in the majority of computer usage domains, the visual knowledgebase that a GUI leverages greatly increases usability. Most users don't have time to read all the manpages for mpg123 or fvwm2, using them is not their full-time job.
Furthermore, the fact that autocad uses a programming language internally is another special case. Autocad users are generally engineers. They have probably had some programming in school (my college required it), and probably think in a mathematical way, anyhow. Making them learn to use a programmming language in this situation is a lot different than making my mom learn the fvwm2 config file structure so she can change the colors of things.
Furthermore, why should everyone have to be a programmer if it is possible to allow them to get their work done without forcing them to invest the time in learning to program? I have been programming for years and I still feel like a novice. Forcing users to become programmers is not a manifestation of respect for users, it is a sign of laziness. The programmers should figure out how to allow the users to do what they want to do without learning the programmers' skill set. That's like saying that when you buy a house, you should be handy with carpentry, cause the walls may come apart and you should be able to fix them. Or if you buy a car, you should be able to fix it when it breaks on the road. That's absurd! We expect carpenters and car engineers to provide total solutions that present the user with a manageable interface. It may be true that I could wring more performance from my car if I could adjust ignition timing, fuel/air mixture, cooling rate, etc., as I drove, but it would be a huge pain in the ass. I don't want to do that. I want to get from my house to work so I can program.
The GUI is, in effect, as much of a "language" as shell commands. It has nouns (windows, files, etc.) and verbs (click, drag, select). The user can state things to the computer by clicking on things, etc., and the computer can communicate back via these same visual elements and some text. The difference is that instead of requiring the user to go all the way and learn a whole new computer-oriented language, the GUI attempts to first of all build on the visual language the user already has (photo-editing suites contain dodge/burn and crop tools, cad suites contain rulers) and to leverage a common set of linguistic ideas between programs so the user only has to learn them once (the maximize and minimize buttons always do the same thing. Unfortunately, this idea is largely ignored in unix GUIs).
jeb.
It is too. (Re:, except that KDE ain't superior) (Score:4)
This is why I am still a little pissed that they didn't link to the interview I submitted in which Kurt dealt with the whole "Corba Issue". Here is the full quote. This is more valuable than his whole rant above.
Kurt: Yes, we did. The initial development on the KDE 2.0 branch was all done with Corba, using the Mico ORBb.
Liz: What changed that?
Kurt: There were several reasons. We worked on the KDE 2.0 development starting when we were still stabilizing KDE 1.0. We spent months on it but were unhappy with the results. The performance was very bad. That, we knew, was potentially fixable through the use of a different ORB, possible Orbit. In addition, though, the complexity of the code, the complexity of the Corba standard, was such that the code became more and more difficult to work with. Eventually, we only had a small group of seven or eight developers who really understood it and could work with it. That was a huge bottleneck for development. Then one of our developers sat down and developed KParts, an alternative to CORBA, within only a short amount of time. He showed it to us. Not only was it blindingly fast, but the code itself resembled the code we'd already written for KDE 1.0. That made it possible for all of our developers to work with it immediately.
Then we had our KDE developer meeting in Europe. We sat down and looked at the potential cost of dumping CORBA. We would be losing the ability to use remote components, but we didn't know anyone currently using that ability and felt it could be added later if people really wanted it. Interoperability with other CORBA implementations wasn't a major impact; everyone builds their own layer on top of CORBA (like Bonobo) and you really have to be compatible with that, not just CORBA, in order to interoperate. So all we really felt we lost was the buzzword. That isn't important to us as developers, so we moved to KParts.
Re:Intelligent (Score:4)
FYI: I went Afterstep -> KDE -> GNOME -> KDE.
Here where my complaints about GNOME (probably partly my fault):
* gmc still sucks. It's gotten better, and more stable, however it has locked up my box hard a few times, it's icons are unprofessional and not eye pleasing. The second problem is a matter of taste. Forently, the GNOME team is addressing both of these problems with Natilus.
* panel's app menu is sluggish, no matter how I change the settings. The kpanel app menu is always fast for me. I think 24-bit color PNG mini images used in the menu are mainly to blame for this. I guess a faster machine might help, although I those mini icons, should probably be 8-bit xpm, which is much faster to load.
* panel is still unstable. I think this is due to the design of the way applets load, and the bonobo panel to applet communication bugs.
* I like to see more intergration between the wm and GNOME, and the same with the file manager.
* Also, I would like to see some scriptablity (like KDE has with kwmcom or dcop command line app).
* grdb doesn't work nearly as well as krdb. Mainly because grdb is based on an really old version of it.
* gdm needs a gui config app
* GNOME feels to unix-ey, and not very Mac-ey or
Window-ey. Part of this is in the design purposely, most of the GNOME creators are UNIX people, who are used to writing UNIX software in motif.
However these problems are relatively minor, they can easily be fixed. There are many excellent GNOME apps that I use everyday in KDE, such as X-Chat, GnomeToaster, gaim, xmms, etc.
While I like GNOME alot, it has many fundimental problems that KDE has addressed. Being able to run GNOME apps almost seemlessly in KDE 2.0, makes KDE very attractive to me