SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
There are so many possible things that could come of KDE if QT was completely dropped by all potential corporate sponsors.
Perhaps a group of KDE devs would spawn off and maintain it?
Perhaps KDE would transition to another GUI tool kit? If that was GTK, I think there would finally be a de facto standard for most gui apps on linux. It would be more interesting to see them use the Enlightenment libs.
However, the least likely thing to do would be creating a new GUI tool kit that's not even QT based.
But I don't even use KDE anyway so I don't know why I'm bothering to speculate.
Either way, Slackware needs a feature rich Desktop Environment and it's unlikely KDE is going anywhere. I doubt Gnome would come back to Slackware... but who knows what the future holds.
Qt's development repository is still getting several commits/merges every hour, so Qt's development hasn't slowed down (yet).
If Nokia does drop Qt, then it will obviously be forked. In that case, the best case scenario would be a company that has existing software written in Qt stepping up to sponsor it. Amazon (whose Kindle desktop software is Qt) and Google (Earth is written Qt) are candidates.
i'm not sure whether the article in DistroWatch is correct, since it's user's choice to pick up the DE being used. There are two big DE in Slackware, which are KDE and XFCE, but there are others too and Slackware never use "default" for DE selection. Everything is based on user's preferences
Are you sure about this? It sounds completely wrong to me, and it's contradicted by KDE's Wikipedia article.
Try to find who is the members of The KDE Core Team, then try to find how many works full-time for KDE and which companies pay their bills, to do that ...
You'll be surprised.
BTW, you know which company develop Mesa/Gallium? Surprise! VMware Inc. Anyways, I found disturbing that Slackware don't ship the VMware Mesa/Gallium driver. It's funny, to exclude from The Game, right the main developer support!
Last edited by Darth Vader; 04-04-2011 at 12:19 PM.
I'm not going to bother. If you've already done it yourself, post your links.
Happen to know personally one of the developers / creators of Konqueror. And he explained to me how it works out the development of KDE. Also, why Red Hat has created GNOME, as an alternative to KDE. There is nothing wrong, of course. Some guys live writing OpenSource code, another guys live selling OpenSource.
In few words, the companies are heavily involved in OpenSource development because they have commercial interests. OpenSource is just another business model.
And, let's be realistic, but without those companies and their commercial interests, we can not develop/maintain highly complex application suites like we use today.