Slashdot Mirror
Why KDE Rules
diegocgteleline.es writes "Being a long time Gnome user and while talking with some non-KDE users, I realized that non-KDE users know few things about what are the "Good Things" of KDE. So I wrote an article about "Why KDE Rules" focused in KDE, with lots of screenshots and some texts - so all those non-KDE (or non-Linux) users can take a look at what KDE can offer to them, why KDE users use it and what they can expect about the future of the KDE platform if they choose to use it. Of course, this doesn't means that this was written to critize other desktops neither it means you should start Yet Another Gnome vs KDE flamewar..."
Can we please include a few opinion pieces about GNOME and OS X and have a real slug fest?
What's better, rain or sunshine?
Everyone has preferences, and Linux is all about choices. I'd rather see an occasional Gnome/KDE flamewar and have the choice to use whichever I prefer. Truth be known, I have both installed. I love Gnome's beautiful interface, and KDE's powerful apps for development. Depending on my task du jour is what I choose from my GDM login screen.
Of course, if you can't make up your mind, there's always blackbox, xfce, windowmaker, enlightenment, and 7.2 hojillion other choices for your X environment. Of course, no one ever complains that Windowmaker is better than XFCE. >83=
Evil Walrus >83=
oh yes, and just for the record: using Ubuntu at home and KDE (Knoppix) at work I have to state my preference for the less cluttered Gnome.
Let the trolling begin.
The same action in KDE will open 4 boxes:
- a dialog asking me which program I want to open the cd with
- a konqueror window displaying the contents of the cd
- an instance of kaffeine, playing the cd
Now, I know I could change all of this, but try as I might, it just doesn't work.In short, KDE may offer more, but GNOME just works (and audio-cd management is far from the only example that I have experienced).
I never much liked KDE, but this article does highlight some cool features. Time to give it another try, maybe.
Well you can do that too with GNOME after installing gDesklets... Actually you can get a mix of whatever you like like this or even this... dunno but I like what I can do with GNOME when it comes to desktop configuration...
Having a choice of various different interfaces to computers systems is a blessing, not a curse. Need to build a netsurfer box for Grandma, wife, or kids then use Gnome or KDE. Put together a server, no GUI needed. On my workstation, WindowMaker on the main box, shell access only on the other but X displays on the main box. Others do different tricks with different tools.
It's your box, your systems: Decide how the machines will be used and who will be using them, then pick the appropriate tools. Be glad -- and be thankful -- for the variety as it is a very good thing.
And for those who insist that "Linux" have only one standard interface, just remember "Linux" isn't a monolithic structure but a collection of tools from which you build what you want or need. If you are with a company worrying about providing support, build a distro and tell your customers that's what you support directly, everything else Linux-wise is base info support only and the customer is expected to know what to do for their distribution. Or tell them you only support such-and-such distributions directly, everything else is basic info only. There are many different ways to skin this particular dog.
Arguments over "which one rulz" are stupidly pointless unless it's a feature-by-feature comparison. The reference article would have done better to have done just that; a comparison of KDE vs. Gnome as concerns their features and tools. Are KDE and Gnome meant to address the same user groups? I'm not so sure and a good comparison of the two might have proven useful in deciding betwix the two. I am sure that having a choice between the two gives people flexibility via options.
About preferences. Some people prefer blondes, some like brunettes and I've heard rumors of some folks even liking red-haired types. Then there is the whole eye color thing, and then body shapes and breast sizes, etc. Oy, it quickly becomes complicated, but it's such a fine form of torture. Indeed, beautiful women are like fine art: If you have to own every piece that strikes your fancy, you are either very rich or very frustrated. But _having_a_choice_ amongst so many different makes and models ensures continued shopping bliss by keeping it interesting.
Start with GUIs, end with fine women; time to call Dr. Strangethoughts.
Happy New Year!
Everything in the Universe sucks: It's the law!
....Its so fucking over simplestic.. For example, when I go to save a file, i cant enter a text path...Noooo that would be too hard for the nubs...So, I have to click around FOREVER tell i find where I want it to go. This theme of over simpleness is displayed everywere in Gnome.
For example, when I click an icon, it starts bouncing.
If that's one of your complaints, I can tell you've never really used KDE much. The option to disable to this is clearly visible in kcontrol.
This might sound like a flame posting, but altough I have to admit that KDE and Gnome are pretty and probably good desktop environments, I'm sad that they are killing many established Un*x philosophies that have been around for a while and proven themselves. I already noticed this 10 years ago, when KDE started to "reinvent the wheel" [tm] instead of providing proper frontends for established (console) applications, with things linke kppp or kinternet. KDE also has the ability to configure many aspects of your Xserver like keyboard ayout, resolution, fonts... - but only for KDE, if you sitch to another Window manager, those changes will not be reflected, they only affect your KDE session. KDE and Gnome both have the ability to browse different "filesystems" in Nautilus or Konqueror, like sshfs/fish, bluetooth devices etc., but again, this only works for KDE/Gnome application. This might be a nice abstraction, but we already got such thing, it's called the VFS layer inside the kernel. Why not provide a nice interface for mount and perhaps FUSE, which can do the same thing, but in a nice and consisting way that fits into the Unix way of life (Yes, I know that FUSE is not perfect yet). Why design every application with a GUI, despite the fact that people might want to use them in a script (without an X session), just like kitchenync or multisync? I'd like to get my device synced automatically upon hotplug/udev detection, but that would require a command line version, just like pilot-sync used to have.
Those DEs are also reinventing drive letters - not letters as such, but a directory structure that has the drives next to each other on the root. I know an OS who does this, and I think it has been proven a bad idea.
The fact that each job had its own tool, and that those tools could be combined in an easy way (pipes, script) is what made Unix/Linux so great - But KDE/Gnome are ignoring the facts, repeating the same mistakes Windows made. Poor Kernel, getting run over by these reinvented wheels (called KWheels and GWheels) over and over again :-(
Life is just nature's way of keeping meat fresh.
the ssh ioslave (fish://).. any KDE app I'm using can read and write to arbitrary SSH shells I have access to. Works anywhere.
No, it's not working everywhere, it is only working in KDE applications. It's another aspect of KDE reinventing the kernel function of abstracting the filesystems you access.The right way to do this would be on kernel level, allowing all applications to access the file system (like FUSE does). Of course it's just a question of perspective, you could argue that this is more like an FTP client. But I feel bad about adding more and more functions to KDE and leaving the rest of the system behind.
Life is just nature's way of keeping meat fresh.
Of course, this doesn't means that this was written to critize other desktops neither it means you should start Yet Another Gnome vs KDE flamewar...
too late.
What ? Me, worry ?
This part also goes into technicalities like database backends (WTF)
Dude, this article it's ABOUT "technicalities".
Following this, the obligatory chastising of readers that use the wrong browser
No, it's not the "obligatory chastising". My thumbnails use PNG transpareny. And IE DOES NOT support png transparency. So, duh, I'm a troll because I recomend readers to use a browser than can render the page properly?
I'm sad that they are killing many established Un*x philosophies that have been around for a while and proven themselves.
I don't think they are. Actually, I think KDE, with DCOP, Kioslaves and KParts, is doing a good job of extending the Unix philosophies into the GUI space.
I already noticed this 10 years ago, when KDE started to "reinvent the wheel" [tm] instead of providing proper frontends for established (console) applications, with things linke kppp or kinternet.
I don't know about kinternet, but kppp *is* a front end to pppd, a console application.
KDE also has the ability to configure many aspects of your Xserver like keyboard ayout, resolution, fonts... - but only for KDE, if you sitch to another Window manager, those changes will not be reflected, they only affect your KDE session.
I think some would argue that's a feature, not a bug. I can see both sides.
KDE and Gnome both have the ability to browse different "filesystems" in Nautilus or Konqueror, like sshfs/fish, bluetooth devices etc., but again, this only works for KDE/Gnome application. This might be a nice abstraction, but we already got such thing, it's called the VFS layer inside the kernel. Why not provide a nice interface for mount and perhaps FUSE, which can do the same thing, but in a nice and consisting way that fits into the Unix way of life (Yes, I know that FUSE is not perfect yet).
And kioslaves have been around for several years, while FUSE is new. Until file systems are implemntable in userspace, doing something like them at the VFS level means kernel hacking, which is much harder and more error-prone. Given that the kernel did not support the required functionality, the KDE developers' only option was to build their infrastructure in at a higher level. But they followed the Unix philosophy and made it very modular and pluggable, so that all kioslaves are usable from every KDE application that uses files.
Why design every application with a GUI, despite the fact that people might want to use them in a script (without an X session), just like kitchenync or multisync? I'd like to get my device synced automatically upon hotplug/udev detection, but that would require a command line version, just like pilot-sync used to have.
In the first place, assuming you have a GUI, there's nothing preventing hotplug/udev from starting a GUI app to do the synching.
In the second place, you're complaining (and I think it's a legitimate gripe) about one particular application, and applying it to the whole desktop. I agree that the core functionality should be provided through a command-line interface.
Those DEs are also reinventing drive letters - not letters as such, but a directory structure that has the drives next to each other on the root.
This I haven't seen. Can you elaborate?
The fact that each job had its own tool, and that those tools could be combined in an easy way (pipes, script) is what made Unix/Linux so great
You really need to learn about DCOP.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I say, give me something that will eat 10% of the resources and provide 5% of the functionality. Then give me 20 other somethings that do the same, but provide different functionality, and we'll have all of amaroK's functionality with only 10% of the resource commitment.
That's more or less my principle complaint against both KDE and Gnome: in order to get the hand full of features that could be useful, one has to add a bunch of stuff that at best isn't used and at worst gets in the way.
But, the good news is those 20 programs *do* exist, and I can use them. So long as no one is forcing me to use amaroK, I'm glad to see that it exists and that someone enjoys it.
In fact, it brings me great joy to know that both Gnome and KDE exist and that there are fans out there talking each other into using them.
First, people find them useful, and anything that improves people's lives (even in a very small way) is a good thing.
Second, they both help attract new users to free unix-like software, and give talented developers something fun to work on. Anything that makes linux and the BSD's more popular is good for those of us who love them.
Third, I'm happy that *both* gnome and kde exist, because so long as both maintain a large following developers will have no choice but to make projects able to run without requiring either. That's good news for those of us who prefer alternative environments. The day one wins is the day third party apps stop simply requiring libraries and start requiring that the winner be actually running.
The author of this comment is missing something: KDE is not a Linux only desktop. Try forgetting about Linux completely and think Solaris or FreBSD - or even Windows, and read it again.
I was using KDE on Solaris a while back, and it was every bit as powerful as it is on my Linux boxes. And that is because KDE does not use all sorts of Linux only technologies.
This isn't the full picture, though. In many cases, KDE will use the enhanced options of your OS, and provide backups for other systems. A simple example: Monitoring directories and files for changes. Linux (and possibly others) have a system that does notifications from the filesystem when something changes. For systems that can't do this, there is a polling implementation.
And in other situations, KDE will use extra features of your system. X extensions like render comes to mind.
And you mention FUSE - this is actually the KDE IO system that is exported like filesystems. That's a very nice idea, but it sort of goes against the argument that KDE reinvents this wheel.
KPPP was for a very long time a frontend to a command line ppp tool. But this turned out to not be powerful enough to be useful. If you start doing these frontends (and I actually have), you very soon run into situations where the reporting from them is too simple. One example is that GUI apps have progressbars for long running "things" - almost no text app provides a hook for GUI frontends to provide this. And you *always* have to parse whatever text is output to the user and present this in a GUI - and you can bet on this text to be different between every single release, and that your application is running on 117 different distros that have 117 different versions of your backend app. This means you have to figure out what version of the backend app this currently is, and parse the right one.
Now, add the multiple OS problem from above. Either you have to make frontends to the very different commands on FreeBSD, Solaris, h-pukes, AIX, and others, or you start adding GNU software to the requirements list of your application. Personally I hate having to install all sorts of stuff, just to run a single application.
Making frontends to text apps is often mentioned as a good idea. But that is only by people who have not actually tried implementing and supporting one of these beasts. If it should really be done, we should start compiling all text apps as a static library, and make the text app a frontend too. Then it could potentially work - providing both the GUI and text app authors have influence on the backend library.
Sometimes reimplementing the wheel is actually a better choice.