From Uncyclopedia, the content-free encyclopedia
“Experience Freedom! Tie up resources!”
KDE, or the K Desktop Environment, is a desktop environment package - essentially the stuff on the computer people actually use - originally designed for UNIX-like systems and developed around the idea that proper software will always use all available resources. This is more difficult than it might seem; not only do other running programs not wish to share a system's resources, but as time passes and technology improves, the available resources keep expanding, well beyond the capabilities of a single group of applications to effectively hog. Even the primary competitors in the realm of system-hogging, OS-X and Windows, have fallen short of similar goals, despite their more financially-driven reasons for doing so.
Like most desktop environments, KDE consists of both a desktop server, or window manager, and a collection of software packages. Unlike most desktop environments, and key to KDE's goals, these individual packages contain a great deal of overlap - for instance that the image viewer doubles as a file manager and the file manager doubles as an image viewer, among many other capabilities. Most users only use them for their labelled purposes simply because the labels are what they see, and because most users are not actually that bright.
The packages themselves are easily recognisable; just as GNOME, another desktop environment developed for similar systems, names all of its packages such that they start with the letter 'g', KDE's packages all contain the letter 'k', although since K is a rather uncommon letter, many are actually misspellings of words normally containing 'c's. This combined with the uniquely graphically-intensive and excessively blue style of the interfaces makes for a very distinctive look.
“If there are free system resources, add more features.”
Like a teenage girl in a house with just one bathroom, KDE had two goals: the original notion of using all available resources, as well as a relatively new goal of looking pretty, something that either developed out of that, or more likely started because the original developers liked pretty. In the early days of computers, looking pretty in of itself more than sufficed to hog an entire system. As faster and more powerful computers evolved, however, it became increasingly tough to use all resources through a single technique, forcing the developers to get more clever at tying up the processor, adding new features with each successive release, a few of which also happened to be useful.
Active System Hogging
Arguably the easiest way to tie up resources is to add useless or even counter-productive modules, a common tactic among Microsoft Windows applications and viruses alike. Unfortunately, the early KDE developers tended not to use Windows and as a result also tended not have any experience with viruses, either. Subsequently they did not even think of following similar patterns. When they finally did, the notion was officially discarded as 'being too easy'.
Instead, the developers produced applications that might contain many useful things, but those things would rarely actually be put to such use. Even then, they would not be used for all of their functions at once despite that being their default - running all at same time. This is most exemplified in the combination web browser, file manager and document viewer, Konqueror. Unlike traditional applications that simply do one of those things, Konqueror starts up, grabs all the resources it can under the guise of 'it might need to do anything', and then sits there looking pretty while the user uses it to look at some files stored on the computer.
KDE's desktop environment is typical: it contains all the usual pieces, as well as many unusual pieces, most of which are completely unnecessary.
From the start, KDE's interface rendered effects well ahead of its time. Drop shadows, for instance, initially caused almost as many system failures as there were systems, simply because computers were nowhere near ready for it. But since it was pretty, and because the developers hid the option to turn it off, users lived with it.
As with all desktop environments, KDE contains an assortment of specific packages - or what the end user sees and uses and forgets are running when they minimise to tray but still start automatically with the rest of it after being started once, either for a single instance of usefulness or by complete accident. Not only are most of these applications somewhat redundant with each other due to their secondary, unlabelled functions, but many are also completely redundant with each other, serving the same primary tasks, because most of the developers never learned how to properly communicate with each other. Thus there are at least three of everything - three main web browsers, Eureka, Konqueror, and rekonq, three main file managers, Dolphin, Konqueror, and Krusader, and so on. It also includes about ten main media players and even comes with multiple calculator programs, such as KCalculator, kcalc and Abakus, as well as the calculator functions built into other, larger KDE applications.
KDE does have some more stand-alone applications, however, ones whose functions are either so specific that there were too few people involved to add other features, as well as some that manage to be so completely overcomplicated that they simply overshadow the existence of other applications serving the same purpose.
An exemplary case of an application targeting a very specific userbase, Kdenlive is a full-featured, industry-standard video conversion, publishing and editing program, that, like all KDE applications, is capable of doing far more that it reasonably needs to for day-to-day use. It supports both free and unfree codecs; prepackaged with a wide assortment of free ones, it also, unlike GNU software, supports the purchase and installation of proprietary codecs. Capable of rendering, converting and modifying anything from home video to complex modelling, it is all-around an incredible piece of video-editing software on all of the 5% of computers on which installation succeeds.
Because installation has a strange tendency to fail for unknown reasons on the other 95%, and because unlike most commercial video-editing software, it is not cross-platform, however, Kdenlive has yet to reach wide use despite its potential capabilities.
Despite remaining essentially unchanged since 2006 when most of the original developers mysteriously disappeared, K3B remains one of the most extensive CD and DVD authoring suites available on any platform. By slapping a pretty interface over already existing and normally separate command-line functions to operate, K3b was a breakthrough for KDE techniques when it was first released in 1998, requiring surprisingly little effort to put together and yet still consuming an unprecedented amount of resources through the interface alone. This method of using existing functions has also enabled it to remain reasonably up-to-date even without any active developers, which is fortunate since none of those who have considered modifying it in the meantime have been able to figure out how it works.
KDE has a long and for the most part completely unremarkable history. Applications were made, they started to come together, and suddenly they were an environment. Over the years, it developed into what it is today, just like any other. In order to make things seem more interesting, however, some of the developers began to form the notion of a war, a grand conflict between KDE and GNOME in which the two great software communities battled it out for the right of being The Top Unix Environment. This idea even served to explain the few months in 2007 when some developers got sidetracked and forgot to tell their programs hog all of their respective available resources, since saying that it was in the hopes of attracting users from the GNOME userbase by attempting to seem a more friendly environment made for a much more grandiose excuse than that 'xkcd started to get interesting'.
After that, it was a simple enough matter to make up battles in a similar vein to the AOL-Microsoft Server-Buffer War of the 1990s, the 64-day AMD War between Intel and AMD which ultimately resulted in AMD stealing Intel's designs and making them better, and then Intel stealing them back and making them even better yet, the guerilla campaigns levied against various proprietary software firms accused of 'monopolistic practices,' and even the recent duel between Richard Stallman and Linus Torvalds. Saying that 'both sides' made a practice of downloading each other's source code, conveniently available as they were and are both open source, explained GNOME and KDE's long standing practice of freely integrating each other's methods into their own, though explaining how stealing each others' code wouldn't yield only their own modified code proved more of a stretch.
When a collection of gerbils, also known as Xfce, wandered into the imaginary battlefield, mostly cloning GNOME whilst stealing KDE's graphics, the daydream was sufficiently disrupted that the KDE developers were finally forced to come to their senses and go back to overtly stealing other's code off public servers without any of the supposed drama of which they had grown so fond.
KDE for Windows
After much consternation and an utter loss for ideas subsequent to computers overcoming even KDE's graphics, a final plan was hatched, an ultimate solution to the problem of ever expanding resources. Suddenly it occurred to the developers that they were going about things all wrong. All of that daydreaming, as well as some actual work, had distracted them from approaching a much more obvious platform for KDE's purposes.
KDE had ever been a Unix-type environment, but next to the monstrosity that was Windows, and Vista especially, Unix-like systems simply fall short on slowness. It was the perfect solution, save for the fact that it would have to be ported to this completely different operating system. But a small section of the community that happened to have even more spare time than the rest were up to the challenge and immediately delved into the mysteries of OS-porting, and by 2009 a working framework had been developed. Suddenly, the boundary was broken. Windows was theirs, and immediately the base applications were recompiled.
Unfortunately, those involved completely misunderestimated just how entirely most Windows applications will hog a system and thus many of the KDE applications wound up relatively less huge and demanding than those they set out to replace. Recognising the project as a monumental failure, most of those involved left, but because what they considered a failure proved attractive to a startling new base of Windows users, enough new names signed on that the project not only survived, but now flourishes.
As it stands, things are looking pretty bleak for the KDE community's hopes of maintaining it as an entirely bloated system.
- ↑ Although concerns have been raised that perhaps it was actually out of stubbornness and a need to make themselves feel better about having completely failed to realise the obvious for so long.
- ↑ This technique of hiding options to turn such things off was later adopted by Microsoft when they began implementing similar features, but by this time most of their userbase was already used to annoying tactics and nobody cared.
- ↑ You think we're making this up? Look it up. We're not. Seriously.
- ↑ AMD64 operating systems are the result of this.
|The Article Whisperer-Winning Article|
This article was chosen as the Best Most Wanted Article in the 2010 The Article Whisperer writing competition.