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.
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!
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.
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.
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.