Kernel Cousin KDE #9: System Configuration Tools, etc.

After missing a week due to other commitments, Aaron J. Seigo is back in full swing with KC KDE # 9. Highlights include a new project to build KDE system configuration tools, improvement of the KDE printing framework to direct output to arbitrary devices (including faxes), and access control lists for KDE CVS. Read more here.



This is needed - like the Ximian setup tools for Gnome, KDE needs some standard configuration tools. I think it's a bit stupid that every distribution makes their own tools.

It would be much easier for the users if the same configurations tools were available no matter what distribution you use or if you change to another distribution.

By Joergen Ramskov at Wed, 2001/05/16 - 5:00am

But *please*, do not create a clone of Ximian setup. Instead, built on the GUI independent backends of Ximian setup so that Gnome and KDE share a common base.

By freedesktop at Wed, 2001/05/16 - 5:00am

Yes, I agree.
Mozilla can be compiled with gtk (default) or qt, why not simply work togheter with xiniam to add a --with-kde --with-qt options, so both enviroements will share the same (mostly) look of tools, user simply can choose if he wants use the setup tools using kde/qt or gnome/gtk.
This would be very smart and I think, really good for user.
But One thing I'm 100% sure: we need setup tools, the distros aren't really doing a good job. Yes, I know mandrake and suse are doing, but this is the problem! The tools chould be the same on all distros, all enviroements, etc.
Please KDE and Gnome/Xiniam people, go for a standard.

By Iuri Fiedoruk at Wed, 2001/05/16 - 5:00am

Yes, that's a good idea.
Just build some GUI around the backend.
It's much easier to do and improves Gnome/KDE cooperation.

By dc at Wed, 2001/05/16 - 5:00am

I think That KDE cane onlie be big if they have setup tools. My girl frent cane not config a OS whitout any good setup tools

By underground at Wed, 2001/05/16 - 5:00am

No need to reinvent the wheel.

Every distribution I know comes with setup tools.
Some distributions (like SuSE and Caldera) even come with fully QT-based installation- and setup-tools.


By Torsten Rahn at Wed, 2001/05/16 - 5:00am

Setup tools for each distro is not open source. In addition, there development is distro centric. It's best for KDE developers to work on a tool that is distro agnostic.


By Kent Nguyen at Wed, 2001/05/16 - 5:00am

> Setup tools for each distro is not open source.

This is wrong. Yast as well as Coas *are* OpenSource. Coas is even GPL!

By Me at Thu, 2001/05/17 - 5:00am

Nope, Yast ain't open source. It may come with the source but for example there is no way Red Hat could use it.

By nap at Thu, 2001/05/17 - 5:00am

You confuse open source with GPL. He is actually saying the exact same thing that you are.

By jj at Thu, 2001/05/17 - 5:00am

No I don't. I use the Open Source Definition presented here:

Yast license violates the very first requirement:

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

By nap at Thu, 2001/05/17 - 5:00am


And some of us are using FreeBSD for which such a tool would probably not be useful.

By Michael O'Henly at Wed, 2001/05/16 - 5:00am

It's important for everyone to know that this tool is not Linux specific. We even have a person who volunteered to write FreeBSD backends.

By Charles Samuels at Thu, 2001/05/17 - 5:00am

That's really great to hear! Thank you for the clarification.

By Michael O'Henly at Thu, 2001/05/17 - 5:00am

Good point... here is mine:

The KDE team could create a template, if you will, that all distro's could follow to create a standard config section in the control panel. For example, init scripts for runlevel 3 in redhat = /etc/rc.d/rc3.d. These same scripts in debian = /etc/rc3.d. It would be possible to create a template that would allow users to add/delete services from each runlevel and leave it to the distro's to do the backend part. The gui would be the same on Suse, Redhat, and Debian despite the fact that these 3 have startup scripts in different locations.

As far as FreeBSD, NetBSD, or OpenBSD is concerned, the template could be modified slightly for bsd init scripts. The major work is the backend stuff again. The Linux and BSD versions of the KDE control panel would only need to differ slightly and a user probably would probably be able to use either regardless of the underlying system. This could work for configurations for mouse settings, video settings, network settings, printer config, and much more.

I propose a general template for all configuration. Make the template modular in such a way that all Linux distro's or even the BSD's could write backend plugins for their specific configurations. I think this will lead to much more solidarity among KDE desktops without the user having to worry about whether the system is Suse, Redhat, FreeBSD, etc...

Until the LSB finalizes, a common system config section in KDE will make Linux appear more uniform to most end users. Standardization of the configuration interface will most definately help the adoption of *nix on the desktop.

My 2 cents,


By posthumous at Thu, 2001/05/17 - 5:00am

*This tool is NOT KDE specific!* It even says that on the web site. "Note: This is not a KDE project."

By Charles Samuels at Wed, 2001/05/16 - 5:00am


in that case you might want to consider moving your cvs code to Sourceforge or elsewhere.

I've followed the threads (also on the dedicated list) and I know the intention is to make generic middleware which can work with all sorts of distributions (backends) and GUIs (frontends), much like SANE, but when the shit is within KDE cvs, initiated by KDE people etcetera, it *will* be seen as a KDE project.

By Rob Kaper at Wed, 2001/05/16 - 5:00am

...or at least create an own homepage on sourceforge, where you can download the stuff separatly.
Having it in the KDE cvs is a good thing I think, many users, developers, bugfixing


By aleXXX at Wed, 2001/05/16 - 5:00am

> *This tool is NOT KDE specific!*

Well you really drove home that point by calling the mailing list kde-sysconfig :-P

Btw: I love the idea of a non-distribution non-os non-desktop-environment spesific config program :)

By anon at Thu, 2001/05/17 - 5:00am


On kde-specificness: I have followed this discussion a bit on KDE-core-devel, here and on your new lists' archives. I have not read everything, but I have read a bit. I have a question.

I have seen you mention several times that this effort is not KDE-specific. I have seen people who agree with you saying that there should be some Gnome integration. Yet, even though the question has been asked (ie on this forum), you have never said a word about Ximian setup tools.

Forgive me if I am wrong, but your description of what you want to do fits the description of what Ximian wants to do with its tools precisely. They want to be distribution (and *nix) agnostic. They want to be desktop agnostic... So what is the problem?

Have you even looked at their code? Is it good enough that you might contribute instead? If not, is it so dreadfully bad that it is really better for you to forget about collaboration and start your own thing instead?

Talking about writing desktop-agnostic code is fashionable at the moment. Why don't you take it a step futher? Actively collaborate with the Gnome people to build a solid, shared infrastructure...

Not whining, just asking. You code, you decide.

By Jérôme Loisel at Thu, 2001/05/17 - 5:00am

according to their web site, it requires gnome:

"Each backend/frontend combination is standalone and has no other dependencies than a working GNOME setup and the interpreter for the backend script."

I also don't trust Ximian and know their implementation isn't C++. Ximian also doesn't support non-linux (hell, it barely doesn't support non-redhat).

By Charles Samuels at Thu, 2001/05/17 - 5:00am

The backend of the Ximian Setup Tools is written in Perl, with only the GUI written with C/GTK+. To me, it makes perfect sense for the backend perl codebase to be shared, with a C++/QT interface implemented for use in KDE.

Such collaboration would not only decrease the amount of work required (the XST project is maturing well), but also allow for a common feature set, to which users can become accustomed (whether using either KDE or Gnome).

As for the support of various systems - to date, many different Linux distributions are supported, as well as planned support for Solarus and HP-UX. See for the details of the latest XST release and overview. It looks like quite a capable system that would also benifit and improve with the help of others.

By Tim Riley at Thu, 2001/05/17 - 5:00am

Why don't you trust Ximian?
Are there evil aliens working behind Ximian?
Aren't the developers just humans too?
Think about it: Ximian Setup Tools is GPL.
The developers would be happy if they hear that KDE wants to cooporate.

So Ximian don't support non-Linux operating systems yet.
Who said they wouldn't in the future?
And how do you know this is also the case with Setup Tools?
Even if they don't support other operating systems, if you guys work together that can be easily added and saves both parties lots of time.

If you're afraid that Ximian will turn it onto a closed source project, then think again.
If KDE contributes then that means the rights are shared, so they can't relicense the code anymore.

By dc at Thu, 2001/05/17 - 5:00am

You did'nt know? Yes they are evil alien stuffed monkey peddlers. Not to be trusted.

By Craig at Thu, 2001/05/17 - 5:00am

That's like saying that KDE is a group of ev1l green dragons.

By dc at Sat, 2001/05/19 - 5:00am

Yea of course where have you been?

By Craig at Sat, 2001/05/19 - 5:00am

"Each backend/frontend combination is standalone and has no other dependencies than a working GNOME setup and the interpreter for the backend script."

The backend/frontend *combination* requires GNOME, NOT the backend alone. The backend is entirely independent of GNOME as I understand it. Of course Ximian's frontend requires GNOME, after all, it's what they do. It would be a shame to just ignore the work that Ximian has done here because of a misunderstanding. Writing a KDE frontend to Ximian's setup tools (and perhaps working on and improving the backends too) would seem to be the best course of action here. After all, the setup tools themselves are GPL and Ximian can never take them away. Ximian has no control over the existing code. Why re-do all the work Ximian has done so far and make it impossible for them to help in the future when you could use what they already have and get a head start?

"I also don't trust Ximian and know their implementation isn't C++."

Well, their frontend, being GNOME-based, is in C. But its only one possible frontend. The backends (the only part of the software that this project would use) are in Perl, I think. You wouldn't want to program the backends in C++ anyway, would you? Seems like perl or python would be a better choice.

By not me at Fri, 2001/05/18 - 5:00am

What more is there to say? So much for co-operation. Good luck on your project.

By Jerome Loisel at Mon, 2001/05/21 - 5:00am

Yes I want this.

I want to have _total control over my box, regardless which platform (Linux, *bsd,...) and all with a consistent GUI.

I don't have any usage of the different GUIs of the distributions.

Please give me total control!


By Philipp at Wed, 2001/05/16 - 5:00am

I think system config tools is a great idea. With proper tools integrated tightly into the UI will make it easier for Windows users to move to Linux. Difficult config is what stops most people!

By Dave Oxley at Wed, 2001/05/16 - 5:00am


Hum, I was confused about KDE system configuration tools, because it is out of the desktop environment... However, I now see that there are some good arguments in this direction...

As a basic user, I felt some disappointment in the Mandrake 8.0 when I saw that interesting tools where not KDE-like, but Gnome-like... Out of my comfort... With some duplications with Kde (rpmdrake-kpackage...)

I also saw that the start menu was managed by Mandrake, not by KDE... However it is, here, more comprehensive for having the same menu in KDE and in Gnome... But I only use the KDE desktop...

So, in facts, Gnome has already system configuration tools and it is growing and growing. So, in the end, they may be more grouped for offering a larger set of programs and it will, of course, minimise the KDE Desktop.

So it is a good policy to go in the same way and try to do better...

And, as told in previous messages, there are others arguments to go in this direction...

It seems to be a step, a necessary step. So KDE is going to be more than a desktop environment... I hope that it will not weaken the desktop development...

So, both in Gnome and KDE, there seems to be some logic of larger and larger growing, of eternal separation...

And I wonder about this spiral... Is then going the time where there will be Gnome distributions and KDE distributions ?? And then a Linux-Gnome and a Linux-KDE ???

I hope good job...

By Alain at Thu, 2001/05/17 - 5:00am

I think that people will see something very different happen over the next year. It's becoming clear to everyone that the huge gap between KDE and Gnome can't continue to exist. Forcing developers to choose one toolkit over the other and cut out 1/2 of the possible audience is not something that most people find all that attractive, and unfortunately it's holding back both KDE and Gnome.

Having both KDE and Gnome existing seems to be very positive for both projects, however interoperability between them will be key for the long term survival of both projects. Many positive things could happen if developers are free to choose whatever desktop environment they prefer, users are free to choosee, and the choices don't need to coincide for the app to perform optimally.

By Chad Kitching at Thu, 2001/05/17 - 5:00am

"Many positive things could happen if developers are free to choose whatever desktop environment they prefer, users are free to choosee, and the choices don't need to coincide for the app to perform optimally."

Where do people get the idea that this is not already the case? Look, you can run KDE programs on a GNOME desktop and GNOME programs on a KDE desktop (you can even run some windows programs on either with WINE). You can use whatever setup tools you want (KDE's, Ximian's, WebMin, etc). Developers can choose to write programs for whatever desktop environment they want and know that anyone with a reasonably recent Linux distro will be able to run them regardless of whether they use KDE, GNOME, Enlightenment, WindowMaker, TWM, or whatever! Where is the problem? I see no problem here.

By not me at Thu, 2001/05/17 - 5:00am

I think there is no need for setup tools that works both in console and GUI. Either some one configure tools dirrectly in the configuration files, wither he use the GUI tool.

Also, you can think more, to not only to just a setup tool, but to an entire management system. I mean, for example, that instead of writing a setup tol for Apache, you can develop an "Apache Control Center", that could be used for both configurations and management (watching logs, stop/restart daemon, monitor performance, statistics (even in the way of KDE System Guard, updating), training (manuals, embeding websites like or even embeding kmail for specific discussion lists).

By Socrate at Thu, 2001/05/17 - 5:00am

I think there is no need for setup tools that works both in console and GUI. Either some one configure tools dirrectly in the configuration files, wither he use the GUI tool.

I couldn't disagree more. If X is unavailable for some reason, and a user doesn't know how to edit config files, it will be *crucial* to have a ncurses or some type of interface for them. Besides, there are plenty of servers out there that don't use X at all.


By Erik Severinghaus at Thu, 2001/05/17 - 5:00am

Well, in that case there is already Linuxconf. Why spend time reinven it?

The motivation that such setup tools can be used if no X is available is not valid, because KDE is suposed to be used where X is available, for peoples that need it (and of cors for the people that love it).

Besides, this time could be used to design what I proposed as "Someserver Control Center" (where someserver could be any one of current widly used servers: Apache, BIND, Sendmail/Qmail/Postfix, DHCP, Samba, wuftpd/proftpd, SSH, etc) in the way I provided an example for Apache in my first message.

I think that such integrated "management control centers" for services where Linux rulez could be more helpful for both KDE and Linux, because they could provide a smoother learning and transition both for newbie and peoples from another OS world, than jumping dirrectly in setup files, logfiles, BSD or SysV startup scripts, shel, etc. This way, Linux could attract more peoples that are used with other GUIs and that don't know from where to start.

Shortly, the ideea is that Linux and KDE needs more that just some setup tools. Simply, let's go further and do things that are really needed.

By Socrate at Thu, 2001/05/17 - 5:00am

"KDE is suposed to be used where X is available"

These proposed config tools are NOT KDE- or even Linux-specific. The hope is that they will be a flexible backend that can be adapted for any system and take a wide range of frontends, from a KDE/QT or GNOME/GTK frontend to a ncurses console-based frontend. In fact, they sound exactly like the Ximian setup tools that are being developed in this respect.

"Well, in that case there is already Linuxconf. Why spend time reinven it?"

Linuxconf only works on some Linux systems, as opposed to these proposed tools which would work on all Linux, BSD, and other Unix-like systems. Besides, many people are not satisfied with Linuxconf.

Most of the services you mention will probably have control panels in the proposed setup tools, if they actually become a reality. To truly be a total system control panel, these would have to be configurable.

By not me at Fri, 2001/05/18 - 5:00am

I think all you guys against this idea do not use linux for anything serious.

I have a bunch of NT kids trying to get to grips with linux. And every time the have to configure something, the first question they ask is: Which tool do I use? kcontrol? Mandrake control? linuxconf? netconf? netcfg?

Each one of these does something better than the other.

When you move accross distros, its total chaos. Yast, Lisa, Yast2, coas etc.

with kde-sysconfig, all a user will have to learn is KDE. They wont even need to learn linux or BSD or whatever.


By nalogquin at Thu, 2001/05/17 - 5:00am

Why not just improving Ximian Setup Tools?
It has a GUI-independent backend.
And it can always be ported to other OSses.

Saying "Because I don't trust Ximian" is not a valid answer.
They exists more than 2 years and haven't taken over GNOME, nor messed up it's codebase, dispite what people have predicted for months.

By dc at Thu, 2001/05/17 - 5:00am

What do you mean they hav'nt taken over gnome? Thats just silly.

By Craig at Thu, 2001/05/17 - 5:00am

Well then, show me your proof.
I don't have to ask Ximian before I download/modify/sell GNOME.
I don't have to ask Ximian before I send bug reports.
I don't have to ask Ximian before I can send patches to the mailing list.
Do you?

By dc at Sat, 2001/05/19 - 5:00am

The proof can be found on the tag thats on the Xiamian monkeys. If you hav'nt bought one then you don't know. Never trust a carney stuffed monkey peddler.


By Craig at Sat, 2001/05/19 - 5:00am


Why do you have so much venom for Ximian and GNOME? Working together with GNOME would *help* both environments, and as far as I can tell, most of the developers of the respective environments are starting to do that.

The plush monkey-peddler comments really come off as trollish. Look at what Ximian is doing. Look at how they are purposefully separating the backend and frontend code, so that other toolkits and environments can use it. See how even things like Bonobo (which is used *only* by GNOME right now) could be used with other toolkits as well.

Let go of the venom and the hatred. Those things only lead to the dark side ;-).

By andrew at Mon, 2001/05/21 - 5:00am

Get over it. It was a joke. I can't believe you replyed to it.


By Craig at Mon, 2001/05/21 - 5:00am

he not trusting ximian is one of the reasons.

the main one is:

¨Each backend/frontend combination is standalone and has no other dependencies than a working GNOME setup and the interpreter for the backend script.¨ from

what they´re aiming to create would work on a freebsd box with only gnome, no kde, for example.

By Evandro at Thu, 2001/05/17 - 5:00am

Have you asked the developers wether they would change that or not?
They just might be willing to do that!

By dc at Sat, 2001/05/19 - 5:00am

"Each backend/frontend combination is standalone and has no other dependencies than a working GNOME setup and the interpreter for the backend script."

The backend/frontend *combination* requires GNOME, NOT the backend alone.

By dc at Sat, 2001/05/19 - 5:00am

¨They exists more than 2 years and haven't taken over GNOME¨

that´s a questionable affirmation.

they control: bonobo, gnome-print, gdk-pixbuf, glade, gnome-basic, gal; ximian gnumeric, ximian evolution; not to mention ¨the gnome foundation¨, which ximian is a part of, where bussiness people make decisions for gnome, not developers.

look here:

do you know who sander vesik is? well, he works for sun. quoting miguel de icaza:

¨ * Aim low: we do minimal cleanup work on the core libraries; we do little or no integration of modules like gnome-vfs and bonobo and we just port things over to the Gtk 2.0 platform.¨

¨ The blue sky scenario might lead to a number of problems:

* Force vendors like Sun to either delay their adoption for GNOME, or make them stick to the GNOME 1.4 platform.¨

¨ We do have existing evidence from free software projects that the above might very well happen. Linux 2.4, KDE 2.0, Gtk+ 2.0, Nautilus 1.0, Evolution 1.0 have all slipped on their schedules as they were projects with more ambition than time on their schedules.

the full document at

By Evandro at Thu, 2001/05/17 - 5:00am

How does Ximian control the GNOME Foundation?

Nothing in the minutes of the Foundation can be used to back up your claim. The GNOME-2.0 documenta that you quote was my `proposal' for the way we should do GNOME 2.0 and be careful about how things moved forward.

This was *not* the proposal that was approved by people at GUADEC, a different version was approved which based on mine, it was the `multi-split libraries' proposal.

That proposal is also in public, and actually the GNOME 2.0 is being coordinated by volunteers at SuSE and Sun.


By Miguel de Icaza at Fri, 2001/05/18 - 5:00am

Aha. So I have to ask Ximian before I can modify/sell Gnumeric, gnome-vfs, glade and stuff?
Do I have to ask them before I can fork them?
I don't. Do you?

By dc at Sat, 2001/05/19 - 5:00am