As part of an exciting new initiative by a group of KDE and Debian developers, a strategy has been formulated to conquer the enterprise desktop. The proposal covers integration and development of standard KDE features as well as developing Debian-specific integration such as an installer and system tools. We have a lot of Debian expertise on board, so focussing on a single Debian target instead of a wide variety of platforms makes a lot of sense here. We hope that similar groups with relevant expertise will form around other efforts such as Fedora and Cooker, where others like SUSE and Ark Linux are already doing an excellent job themselves. Want something controversial to discuss? Check out our proposal for integrating GTK+ into KDE.
This announcement is not as UserLinux specific as much as it is Debian-focussed. We welcome collaboration with, endorsement and sponsorship by other entitites. Just drop a mail to express your interest.
And last but not least, a big thank you to all the developers who are already and have been contributing code, effort and wisdom to this.
Comments
How does this relate to the Debian Desktop Project (http://wiki.debian.net/index.cgi?DebianDesktop)? Is there a cooporation?
Thanks for pointing that out. We're still having contacts flooding in, but yes this is definitely one project we will want to collaborate with.
Would that just not be the coolest thing ever? A Debian-based distro with KDE-based configuration tools, and good commercial backing?
This certainly makes me feel a whole lot better about the whole Novell/Sun/GNOME thing. At least, it seems that KDE is willing to put up a fight in that market space.
I wish all the luck to this project and UserLinux as a whole. These are really best-of-breed technologies, and it would be great if they became a significant force in the enterprise market.
I'm glad to see some *positive* response on the KDE side to the UserLinux initiative. UserLinux has chosen to focus their limited resources on a set of "core" applications, and KDE/Qt can be a nice add-on for those who want the ultimate best. This is similar to the situation with Python and TK. TK is no match for Qt, but it meets the needs of the Python project, lightweight and no restrictions on licensing. Anyone with a big GUI project in Python will move quickly to Qt.
Unix is at another crossroads, similar to what happened in the 80s. I watched in astonishment as the different minor variations of Unix focused on their petty little war, while Microsoft took the entire market. Let's not repeat that mistake as we go this last mile to the end user. We need the best possible cooperation between KDE and UserLinux. Stop the personal attacks. Give users a set of tools we can *easily* install in Debian / UserLinux / Redhat / Whatever. Go that extra mile to make sure all package dependencies are resolved. Try it on some real users.
-- Dave
A first step (hack? ;) has been made: the GtkQt and the QtPixmap engine for Gtk by Craig Drummond. I use it, and it works very well. You can change matching Gtk themes, fonts and colors from the KDE Control Center.
http://kde-look.org/content/show.php?content=6954
Unless I'm completely mistaken... work is being conducted that would allow GTK to draw its style directly from the KDE/Qt style... thus obviating the need for two separate themes (Keramik and Geramik) that look alike. With this engine all you would need is Keramik. Stay tuned.
Well, _this_ is interesting! I would love that! I only hope that GTK apps do not get too slow!
matching themes is a trivial and hardly useful step. this is probably why it's been done so much: it's easy and inconsequential.
what is much harder, but much more useful, is allowing apps written to other toolkits to be able to use KDE's file dialog, network-transparent IO Slaves, etc... that's the sort of stuff that is being worked on. and when i use the word "worked on" i mean "code being written".
Sodipodi can be compiled with KDE support, and if so it uses the KDE file and printing dialogs.
Which is incredible easy and is looking nice on your desktop
But what we need is to be able to install a theme as one package and have it theme everything.
At the moment, I need install maybe three packages, then go into kcontrol and choose the them, run gnome-control-centre and choose it again there, and do the same for the likes of xmms.
What is the admin tool? any info on it? I am curious as to the approach taken on it.
thanx.
admin tool_s_, and we'll all just have to wait until the authors are ready. KDE has never really been about announcing vapourware, and the wait won't be that long.
Hi all,
I just want to pop my head up and mention that I've been working on some administration tools too. (also because I'm sick of the current state of affiars wrt distros).
http://www.simonzone.com/software/guidance/
The user&group admin is pretty complete, also the Service level prog. I've been bevering away on a fstab admin prog lately.
Aaron and the other people involved, it would be nice if you people could let me know what your plans are in this area. I'm not interesting in duplicating any effort in this area, and I'd like to work something out. :-)
--
Simon
Simon,
that looks like a really great beginning!
I agree about the essential need for stuff like that. We should stop to be
at the prey of distro's (semi-)proprietary or half-baked and inconsistent
tools which are slow to use.
Too long we did let them go away with their say about "keeping
the admin tools in our re-alm since it is too complicated for KDE to
think of all the distro-specific stuff".
Heck, I can't even set the IP address with a KDE tool!
Cheers,
Kurt
Wow! Looks fantastic! I've always wanted some KDE specific, and non-distro branded, config tools. Everyone says SuSE is "seemlessly" integrated with KControl - but this is rubbish. SuSE's tools are in their own section - why? And have the stupid "YaST", and gecko logo - hardly integrated, as they look nothing like the other modules. For a complete desktop OS (KDE + Unix/Linux) everything should be consistent, both UI wise and functionality wise.
Is their any chance these, and Guarddog, could be converted to KControl modules?
If there was sufficient interest to take the stuff that I've written and integrate it all into a complete desktop, then yeah there is a very big chance that it could be converted into KControl modules. :-) I'm certainly not against it although I do prefer ArkLinux's way of organising a control center over the current KDE Control Center, but that's a different story. :)
I just want complete and polished desktop too. That's my top concern.
--
Simon
Well I'd love to have them integrated. I agree Ark's Mission Control looks nice - my only concern with that is if the HTML pages are static, the problem would then be if you install a new control it won't show up!
Making your tools into KControl's would allow them to be used in both scenarios.
And I share you concern about a "complete" desktop - *none* of the current distros offer this. There's allways KDE's control settings, and then the distro tools. Which doesn't give the impresion of an integrated OS.
Aaron, while I appreciate not wanting vapourware, it is useful to still talk about things (or at least see things).
Back in KDE 2.2, I developed a 3 tier approach to handleing admin on *nix (as opposed to pure unix, pure linux, pure bsd, etc). I suspect that I have done a bit of work that you may find useful. I was generating GNOME and KDE controls, and had the ability to easily move to a networked tool (think ksysguard). This was also working on many of /etc's files.
Is there a page that has your work on it?
the majority of this isn't my work, i just happen to know about a lot of it... the stuff i'm personally working on relates more to thin client management and i'll probably be helping out with some LDAP related things. but it isn't like we'll have to wait long to see the fruits of everyone's labours; it seems January will be the month that a lot of this stuff surfaces in alpha/beta form and/or as design documents.
feel free to discuss further with me via email this 3-tier system you designed, though. i'm more than interested and would be happy to point people in the right directions to increase collaboration and involvement.
With respect to a 3 tier approach it might be good to talk to the authors of gnome-system-tools to see if they would be interested in that as well. It is intended to ship with Gnome 2.6 in a few months.
There are at least three kde/qt (partly) implementations of frontends using the gnome system tools. I had started one, but never got more than the system chooser running, because of lack of time.The gnome system tool developers' were quite cooperative back than and would have appreciated a full KDE frontend implementation for their backends
Will this be a kind of KDE-Distro ??
IMO: no and yes. when complete it will be a distribution of software that leverages KDE to its full potential (including raising the level of that potential), but it won't be "the operating system of the KDE project". KDE supports many, many different OSes, and this doesn't change that in the least. personally, i hope that this process will result in four things:
1. show what KDE can be like, to its full potential
2. provide a platform for third parties looking to build upon Linux/KDE for their clients whose needs aren't served by SUSE, Mandrake, Red Hat, etc... it turns out that there are more people in that category than i first thought.
3. provide a case study for how the KDE project can work with the SUSEs and Mandrakes of the world more directly. right now that relationship is often quite passive, and that may not be the best thing for KDE or the vendor. the question is HOW to do it in such a way that it works; this may be a first forray into that realm.
4. through a combination of 1-3, grow KDE's user base.
Check this out: http://kde-look.org/content/show.php?content=8966 It is a kioslave for apt that performs queries on the apt-cache from withing konqui...
This is great news to hear. But it's really important to stress that only collaboration between KDE and GNOME will lead to success. It's that simple:
1) No user will understand why he can't set the gimp's font from the kde control center.
2) Users will be confused if half of their applications has OK/Cancel and the other half has Cancel/OK as button order.
3) My KDE app has to dock into GNOME Panel's systray.
4) ... much more
And everything vice versa.
If both desktops collaborate, better solutions can be achieved in shorter time. (There is enough market share to steal from MS :-))
That is the whole point.
Isn't docking to the systray standardised between kde and gnome already? I seem to remember gaim docking into my kde systray, before I started using kopete.
I'm sure they won't mind me quoting part of their email. :)
We, at LinuxMagic Inc, have adopted the KDE and Debian based strategies for
all our LinuxMagic OS and product developments. Our LinuxMagic Workplace
products especially show the alignment of our organization, and our beliefs
in the statements expressed in your article entilted "Conquering the
Enterprise Desktop"
Using Thin Client technology, KDE Desktop, Debian based systems, OpenOffice,
our product is specifically designed to statisfy the requirements of the
typical office, whether small or enterprise scale..
Woo! Things are moving fast. Juanjo has joined and already whipped up some new PyQt code. Eyal whipped up some Qt designer interface examples.... keep them coming folks!
produktivIT:
Their plans for contributions include:
IMAP Mail server configuration (Cyrus first)
SMTP Mail server configuration (Postfix first)
HTTP server configuration (Apache first)
SMB server configuration (the kdesamba-plugin project being currently dead)
Proxy server configuration (Squid first)
System Authentication configuration (PAM first)
User Management extended to LDAP, Samba & SASL
KDE has a ControlCenter and a InfoCenter. I think it´s time for a ServerCenter :)
Please no! Splitting up the Control Center into two apps is a BAD IDEA. Reason: Joe user wants to change a setting in their mail server. Do they open kservcenter? No, they open kcontrol since it's familiar to them as the single opint of configuration ala MS Windows. It may make sense to you as a UNIX admin, but makes no sense to the MSCE who's been told that his boss wants the server room MS free, now.
Joe user does not need kservcenter, if it needs a root password. He only needs the control center. The joe admin may need it, but keeping it separately makes sense. Hopefully he has enough sense to know what to use where if he wants to be an admin. The kservcenter could be called "advanced settings" or something.
BTW why would a joe USER be allowed to change the settings of the mail server? That's the admin's job. Maybe if there are any allowable changes, these changes should be accessible through kcontrol.
To me at least it does make GOOD sense. This is not MS Windows.
You are falling into the old UNIX mindset that all systems that have servers are only run by admins. If we follow this logic, we don't install KDE on the server, nor do we even install X11.
This is not just useful for servers, it is useful for workstations also, the type that windows today is used in most offices today. Please don't fool yourself into believing that only windows-like workstations exist in this world. Windows workstations give a hell of a nightmare for security in administration, especially windows 9x.
Users frequently do something to their systems and it stops working (BSOD, viruses, corrupt registry or deleting other peoples files) and these actions are often not deliberate. I don't know how many times a win admin has to reinstall win98 on their workstations due to ignorant users. This is because they have access to system utilities that should normally be restricted (any one can download Xsetup and play with it). KDE should cater to those workstations which attempt to make the admin (and users) life better, where most of these problems don't crop up so often (unless the user is determined to cause trouble).
Such systems are more often setup than home pcs (which I assume is your idea of the general system). Besides, the topic is on the Enterprise Desktop.
Users shouldn't be shown dangerous options. Leaving it around is not dangerous, since it requires root piviledges anyway, but it makes the common control center redundant. Shunt it. keep it out of the way (not inaccessible though) maybe in another similar app. Like I said once before (http://dot.kde.org/1071469854/1071499344/), presenting a user with a Login manager settings box which is entirely disabled (except for an admin mode button) makes this option totally redundant here for most users.
They should keep it in a separate kservcenter or whatever which has most options with root priviledges. Since there is a clear reason to differentiate these options, and we can be pretty sure they are going to increase, we must catagorise and make place for them.
Then let the admin hide those settings via kiosk mode or maybe, I dunno, kmenuedit? The problem is that you are thinking with the mindset that KDE will or should only be used in a workstation business type of environment. The idea of splitting this stuff out for home desktop systems is not very helpful for those of us trying to break *NIX into the home PC market. I understand the issues your speaking of 'cause for my day job, I'm an employee of the IT support department at Grand Valley State University. I see the kind of stuff that happens because Windows is too insecure. Does this detour GVSU from using Windows based systems? No.
When competing for a market, sometimes breaking paradigms is good, however in the case of usability, people don't care how logical the system is as long as it's something they're comfortable. This is why I cannot get GVSU to use a *NIX based KDE solution for the labs, because the ease of use isn't there yet according to the department after doing an analysis of the environment.
Since you mentioned kiosk mode, this is exactly what is useful in a workstation environment.
Where I am studying, the systems have all windows 98 (newer ones have XP). The only reasons they use Windows is that a large number of plugins and client softwares for bioinformatics (my subject) are available on it (not that there are no linux versions -- they have bought windows versions and windows too). There are some tools which have no clients on UNIX systems (esp. some homegrown ones).
Splitting the Kcontrol center is simply a better way of organising the ever-growing kcontrol center. It is already unweildy now with a large number of options. At least some property should be chosen which can be used to categorise options, and I can think of no better. If it doesn't agree with you, I'm not going to try convincing you. Hopefully someone else is reading these comments too.
Try imagining the Kcontrol center with all options -- with everything for tweaking the OS -- from hardware to themes to server options. Mail settings would hold Client settings and Server settings. As a non-priviledged user you start kcontrol. How would you feel if half the controls are disabled, and are all strewn across the applet? Maybe you are brilliant, but any other person would get pissed off seeing all these options, including the disabled ones lying around mixed with the ones that 'work'. Imagine him trying to figure out what is where, and which one is 'working'.
Hell, even a single-user system doesn't run root all the time. There is a clear distinction between the two types of settings. If you really don't want to see them separate, keep them as two icons in a Control Panel folder, like windows (Local settings and Global settings -- perhaps).
Windows has the Control Panel and the Microsoft Management Console. What do you mean?
It may have both, however, MMC is accesable from the Control Panel, sure the MSCE may load mmc.exe, however the most of the time, they'll just browse to the Control Panel for the Administrative Tools. Moving obvious comfiguration tools from the Control Center to a seperate app is poor usability and adds an inconsistancy to KDE. Mac OSX Server also has it's server tools accessable in it's control center, so please let's follow good paradigms in usability.
HERE is his oh-so-well written rebuttal: http://www.userlinux.com/GUI.html
Someone mentioned to me who his secret "1-million-$-a-year" backers might be:
Sun, and maybe HP...
Sun is feeling increasingly uneasy to have underneath their mis-named
JavaDesktop a SuSE-engine which now belongs to Novell! Not something they'd
have expected to happen when they signed the deal with SuSE.
And Sun is quite experienced to utilize "the community" for their efforts (see
their Blackdown/Java behaviour). Now, Bruce P., who are your backers? We want
to know _before_ we start coding for you!
Strange reply he made there.
Obviosly, it is better to have the possibility to develop with QT, since it has some very interesting features. So if GTK apps will be able to work well in KDE, then what's the problem?
I don't think that's any rebuttal to this. Indeed, I would say this may be a rebuttal to _his_ writing. His comments do not reflect even have the minimum hint of what's mentioned in this article.
He really condemns one of the desktops. KDE has a better option that may please even the Novell/SuSE team: lets make them work together. If they really want to do it, they have no better choice than this really.
I think it has become clear to anyone who has been on the userlinux mailinglist recently that Bruce lies and tries to enforce his agenda by dictatorial means
** Bruce Perens doesn't reveal the names of his sponsors which seem to be clouded in secrecy. Who would ever work on a project where you don't know who the instructing party is?
** Bruce Perens doesn't reveal the requirements specification which obviously does exist and which ties the 1 Mio Dollar payment to using Gnome instead of KDE for example. If you browse the archives you can clearly see that the decisions which were made on the list are mostly not related to the discussion which happened on the list.
** Bruce Perens claims that the 1 Mio budget is is tied to using Gtk - while on the other hand he claims that he has no financial interest in Gtk (his claim of having a financial interest concerning the Qt book just sounds like hypocrisy to me!)
** On one hand Bruce insists that the reason for excluding the Qt toolkit (and therefore KDE) is justified by the decision that only *ONE* toolkit should be used in UserLinux, while on the other hand he has already approved *THREE* other toolkits for UserLinux!
** In spite of the fact that the majority of the vocal list has already clearly stated that KDE is much better in technical terms, much better suited as a development platform and much better in terms of cost (as the time to develop a Qt based product is lower and support/quality is much higher) he spreads a deliberate misrepresentation.
Obviously someone has a financial interest to drive his agenda and tries to muzzle others under the "banner of freedom".
Yes; that seems ridiculous to me. $1Mil USD for Gtk+ development--but Qt is bad because of the financial cost for proprietary development (which would likely, no doubt, be for profit)?
Bruce is alright and all, but sometimes he leaves me scratching my head. ;-D
Bruce needs to either be honest about his reasoning or admit to his intellectual difficulties. His "developmental" argument flies in the face of reason and is an open insult to free software and the common man. Who are these "imaginary developers" that will be hamstrung by license costs? This scenario only plays out when you are planning on taking a lot of free development efforts and turn around and sell the product after adding some value. That means that the finished product isn't free software and the development was contributed largely by free developers. This is the only model where the license issue comes up and it is the Microsoft whine we all know as "we can't steal your software.. Wah!"
Let's look at reality. There are several factors to consider developing an application. Will it be distributed or is it vertical market software? What are the skill sets of the developers and how much developer resources do you have? What is your financial standing to accomplish this? The idea that a little guy writes a fully polished desktop application by himself in his spare time and the fee will break him is irrational. It takes man years to write an application from scratch unless you buy a lot of pre-assembled code and widgets as many developers make a business around. If your program is going to make enough money to turn a profit and $1500 makes a difference you have a funny concept of profit. The most expensive part of development is by far the man hours and you're going to need a lot of them... We're talking hundreds of thousands of dollars in billable hours! Check the last Quanta BE release in sloccount.
===
Total Physical Source Lines of Code (SLOC) = 149,389
Development Effort Estimate, Person-Years (Person-Months) = 38.38 (460.52)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 2.14 (25.70)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 17.92
Total Estimated Cost to Develop = $ 5,184,133
(average salary = $56,286/year, overhead = 2.40).
SLOCCount is Open Source Software/Free Software, licensed under the FSF GPL.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
===
Figuring licenses for each of the theoretical 18 developers above at no discount for volume that's 0.5% of the development cost. You also need to sell over 100,000 copies at $50 net just to break even, which should the popularity of free software. You could make more money packaging and training. Bruce is advocating the wooly mammoth we're slaying.
1) However similar KDE and GNOME are in use and appearance there are architectural differences. Most application designers are more oriented to C++ which would make KDE an obvious choice for them. Bruce has decided to remove this.
2) Reviewing the tools, lines of code to accomplish various tasks and docs, the question of efficiency comes up. As illustrated above the logical question of cost comes down to evaluating whether your people would realize an increase in efficiency. You would have to assert *zero* efficiency gains on Qt/KDE to make this argument hold water!
3) If you're selling software for a profit then bringing it to market sooner also significantly affects yor cash flow so you can't afford not to examine this question in the real world unless you have more money than you know what to do with.
4) If you're developing an application that is not going to be distributed but used internally the license issue is a moot point.
5) Whatever desktop is being used to put forward it's pretty face the smartest thing to do to support users is to give them what they want. This means that from a user perspective people will want to run Quanta and telling corporate shops to "go to hell we don't do Qt" is just not good business. Only a company with a Microsoft mentality would treat their customer like that.
Clearly what Bruce offers is a red herring unless he is involved with a group who wants coders to work for free so they can resell their work. This could be done with a dual license agreement, but I would rather consider what made F/OSS work in the first place. If a company has a lot of money, they are going to develop an application and go with the old guard model of selling it for a profit instead of selling service or value added packaging then I don't see why they should not pay for the software that goes into it. Why the hell is Bruce beating us over the head about 1% software profits instead of promoting free software development? Is market penetration and branding more important than principles?
Let me be clear... if you intend to charge me for your software you had better get my permission and compensate me before taking my software to do it with. You ought to pay for your software profits. What happened to the principles that made F/OSS grow?
Bruce is either suffering a lapse of ethics or reason and he ought to know better. I don't know what's in this for him but I would not sell my principles for any amount of money. Somebody said he had an investor? Could be Sun, but for all we know it's M$. Come clean Bruce. Enough double talk. Who's your sugar daddy? Why are you really making a bad business move to spite a desktop?
I thought in the open source community you had a position based on your code and your adherence to principle. Can someone explain to me why Bruce's 15 minutes of fame aren't up yet? I honestly don't want people to think he is somehow representing me instead of some corporate cabal that won't even step into the light of day. I'm going to enjoy producing the software people ask him about that he is trying not to support.
> What happened to the principles that made F/OSS grow?
People seem to think that, as soon as big corporations can take free software and use it to sell their own products without giving back to the open source community, then free software will succeed.
I definitely don't believe this. Privately owned companies will eventually do _anything_ to trash the competetiors (eg free software), that's a force to take into account. And that's why the LGPL is dangerous. The "we support open source" thing only makes sence at some point in time, not anymore when your competitor is an open source project.
I had a good long chuckle when the 'chosen' software was announced by Perens and group. It's not that they don't have the right to chose. But the customers and users definitely do. Hasn't every distribution, including Debian, tried to chose a desktop environment? Haven't they all tried to say this or that is the best MTA, or DB? and what happens? someone who has a different preference, for very good reasons, packages another. And another. And another.
The distros accept this because they have no choice. Users want choice, for the very good reason that each package provides strong and weak points.
The *nix desktops are still immature. KDE has it's strengths and weaknesses, Gnome/Evolution/Mozilla/Openoffice do too. To try to select now, before they are complete is, being generous, amusing. To think a committee can select and put together 'the right way' is plain stupid.
Derek (who wonders if the vaunted and courted enterprise developer can use the OO editor or spreadsheet as a part in their application?)
If you don't like the idea, why care?
As you said yourself people like to have choices. This project sounds like the best choice for me if it delivers.
So what do you want to achieve - take away this choice from people like me?
You say people like to be able to choose desktop. Then how come Windows and MacOS are so successful?
And how come the OS with most desktop choices has the smallest market space among the big desktop players?
Probibly because its been arround the shortest :)
Indeed, MacOS has had twenty+ years to maturate and Windows has had
nearly that long. You don't build up large user bases overnight people! Linux has done fine considering it's desktop offerings are only six years old at the most (KDE)