DistroWatch: Jonathan Riddell Interviewed about Kubuntu

This week DistroWatch interviews our own Jonathan Riddell about Kubuntu, the KDE-centric Ubuntu flavor. He reveals to us how he started with Kubuntu, what problems they've encountered and what his plans are for the upcoming new version.

Dot Categories: 

Comments

by Petteri (not verified)

That simple browser interface looks really good. Mayby the idea could be worked a bit more and ingrated to Konqueror so that when browsing web the interface would autodetect the mode and konqueror would morph it self to a nice webbrowser :)

by zmc (not verified)

It's been in konqueror for ages. Just load it up (via the Settings>Load View Profile menu) and overwrite the Web Browser profile with it. I created a customized version of it probably a year ago, because i don't need 40 buttons ;)

by drizek (not verified)

I wanted to try out one of the daily releases, but they only work on 64bit cpus. whats up with that?

by ltmon (not verified)

Whilst Kubuntu has a ways to go to catch up with some of the more mature distros (most notibly with the bad package manager gui and a lack of system configuration tools) I really like what they've done so far.

Fast and light, up-to-date packages released often and nice, clean default settings set it apart from other distros. Hardware and media detection is better than most other distros I've tried also.

Can't wait for Breezy. Keep up the good work.

Cheers,

L.

by rqosa (not verified)

> lack of system configuration tools

It has debconf. See "man 7 debconf" and "man dpkg-reconfigure" for further information. The man page even says that there's a KDE-based frontend for it, although it seems to missing from the Ubuntu Hoary package. It is present in the Debian Sarge package, though: http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelis...

BTW, why do people keep complaining about {Ku,U}buntu and Debian lacking system configuration tools? Maybe debconf needs more promotion.

by Roberto Alsina (not verified)

Quick, how do I reconfigure the screen resolution using debconf? And how did you know that?

by rqosa (not verified)

dpkg-reconfigure xserver-xorg

I know that because, when one runs, for example, "apt-get install foo" where foo is a package which uses debconf, the debconf front-end being used will say "Configuring foo"; so, to change the cofiguration later, run "dpkg-reconfigure foo".

I haven't ever used any of the graphical front-ends to apt, so I don't know if they provide an easy way to launch dpkg-reconfigure. Maybe some extra work is needed there to make debconf more accessible to people who don't like the shell.

by Roberto Alsina (not verified)

I rest my case. It's quite non-discoverable.

A regular user is never going to find it.

At *least* there should be a menu, or a list somewhere saying what configures what.

by rqosa (not verified)

> A regular user is never going to find it.

Why not? It seems simple enough to me; if one wants to change the settings for the X server, one reconfigures the package which provides the X server. Furthermore, the configuration questions automatically appear during installation of the package, so they will definitely be seen at least once.

I tried using Conectiva 10 once, and one thing about it that frustrated me was that packages might not be configured correctly after installing them (with the RPM version of apt-get), and the appropriate configuration management utility is in a separate package, and it can be difficult to find which one it is. Compared to this, the debconf way seems much more "discoverable" to me.

> At *least* there should be a menu, or a list somewhere saying what configures what.

This is a job for Kynaptic or somthing similar. Maybe there's a program that already does this?

by Roberto Alsina (not verified)

Well, if I have to explain this...

a) The user doesn't want to change the settings for his X server. He wants to change the resolution of his display. The need to know that there is such a thing as an X server is useless complication already.

b) How is the user who has heard the term "X server" going to guess that the package providing it is called xorg-xserver? By looking at the descriptions of the 1300 installed packages?

c) In any useful setup, the questions will be asked during the installation of the system, not during an independent "installing the X server" step, so the user will probably *not* remember the exact name of the package. Not to mention the likely chance of the user not having installed the system himself.

d) I never got to Conectiva 10 (I left the company around Conectiva 7 ;-) but I can tell you that on SuSE, the setup tool is always yast, and that in Fedora/RHEL/CentOS/Scientific Linux/TAOS it is always system-config-something and that they are all in the menu anyway.

On the other hand, on Debian, they are nowhere. Not on any menu. Not an icon in some place. You have to know the magic words. And there is no list that I know of the magic words you have to use for common config tasks. That's *not* discoverable.

And no, it's not a job for kynaptic, because that would have the following problems:

a) It mixes the install-software and the configure-software functionality, which are not related at all in the users mind

b) It doesn't make the useful configuration any easier than the useless.
Since *every* package can be dpkg-reconfigure'd, the ones that actually are useful are a tree, lost in the forest. It's inconfigurability by obscurity.

c) If there is such a tool, Debian sure doesn't mention it prominently enough, I think (I must be wrong ;-)

In short, you are thinking like a linux geek. I recognize it. I am one, too :-)

by cm (not verified)

> a) It mixes the install-software and the configure-software functionality, which are not related at all in the users mind

Doesn't YaST do exactly the same?

by Roberto Alsina (not verified)

Well, never claimed yast to be perfect! ;-)

by rqosa (not verified)

> a) The user doesn't want to change the settings for his X server. He wants to change the resolution of his display. The need to know that there is such a thing as an X server is useless complication already.

Well, with the XRandR extension, the screen resolution can be changed while the server is running, so there's no need to change a configuration file and no need for debconf. KDE has (if I understand correctly) a front-end to XRandR in the form of Control Center -> Peripherals -> Display, and this is included in Kubuntu and Debian, so one can't complain about lack of configuration utilities there.

> b) How is the user who has heard the term "X server" going to guess that the package providing it is called xorg-xserver? By looking at the descriptions of the 1300 installed packages?

Like I said before, debconf will display the name of the package it's configuring, so when the X server was first installed, every screen of configuration questions related to video settings would have had "Configuring xserver-xorg" at the top.

Also, it's not too difficult to search for it:

$ apt-cache search 'X\.Org' | grep erver
xorg-driver-synaptics - Synaptics TouchPad driver for X.Org server
xserver-xorg - the X.Org X server <--- HERE IT IS
xserver-xorg-dbg - the X.Org X server (static version with debugging symbols)
libroxen-zopegw - Zope relay module for the Roxen Challenger web server
xcin - Chinese input server in X11
xcin2.3 - Chinese input server (Big5) for XA+CV in X11.
xcingb - [Obsolete] Chinese input server (GB) for Crxvt in X11.
xprt - X print server
$

(In my case, I remembered it because when I "apt-get dist-upgrade"d from Warty to Hoary, apt-get listed "xserver-xfree86" as one of the packages which would be upgraded, and I had to tell it explicitly to get the X.Org server instead.)

> c) In any useful setup, the questions will be asked during the installation of the system, not during an independent "installing the X server" step, so the user will probably *not* remember the exact name of the package. Not to mention the likely chance of the user not having installed the system himself.

Well, that's what "apt-cache search" and "dpkg -S" are for.

In the case of someone else having installed the system, then would it be true that that same person is responsible for changing the settings? Ok, in the case of things like screen resolution changes, maybe the user can do that (especially because this doesn't require changing the X server config file anymore, see above), but look at these:

http://www.gnome.org/projects/gst/screenshots/networking.jpg
http://www.gnome.org/projects/gst/screenshots/boot.jpg
http://www.gnome.org/projects/gst/screenshots/runlevel.jpg

In the business-desktop use case, the person(s) responsible for installing the operating system probably wouldn't even allow most users to change settings like these. Even where the user is allowed to change things, it's not very likely that someone who hasn't installed the system would want to be changing settings like these.

> d) I never got to Conectiva 10 (I left the company around Conectiva 7 ;-) but I can tell you that on SuSE, the setup tool is always yast, and that in Fedora/RHEL/CentOS/Scientific Linux/TAOS it is always system-config-something and that they are all in the menu anyway.

Not neccesarily. They're in the menu if they're installed, but what if they haven't been installed? When I installed Ark Linux, I didn't use the ISO (I have neither broadband nor a CD writer); instead, I installed Debian from floppies, installed rpm2cpio, downloaded RPMs, used rpm2cpio to extract their contents into a directory, chrooted to that directory to check that there were enough things there to run bash and rpm, ran "rpm --initdb", re-installed all of the RPMs using "rpm -U" so that they would be in rpm's database, then moved the contents of the chroot directory into the real root directory and vice-versa. (Also, when I installed Conectiva 10, I did so by "apt-get dist-upgrade" from this Ark Linux.) A problem with doing this with an RPM-based distribution is that packages don't know how to configure themselves, so the resulting system always acted weird in some ways, which I assume was caused by bad configuration files.

(Side note: when I installed FreeBSD years ago, it's installer had the ability to install by downloading everything over a PPP connection. I'd like to be able to install Linux distributions this way, but I've never seen one that can.)

> On the other hand, on Debian, they are nowhere. Not on any menu. Not an icon in some place. You have to know the magic words. And there is no list that I know of the magic words you have to use for common config tasks. That's *not* discoverable.

Just now I looked at Synaptic's package description, and it says that it can reconfigure packages. I would think that it would be on the menu if it were installed.

Furthermore, by the same reasoning that "it's not on the menu", one could say that apt-get isn't discoverable, and yet I don't remember seeing complaints that "Debian/Ubuntu lacks package installation tools".

> And no, it's not a job for kynaptic, because that would have the following problems:
>
> a) It mixes the install-software and the configure-software functionality, which are not related at all in the users mind

Well, it could be split off into a separate program. However, I don't agree that install-software and configure-software functionality are unrelated, for the reason I said in my previous message: many packages must be configured in order to be useful, so when I install one, I want to configure it right away, and I don't want to have to go looking for some separate program which might or might not be installed already.

> b) It doesn't make the useful configuration any easier than the useless.
> Since *every* package can be dpkg-reconfigure'd, the ones that actually are useful are a tree, lost in the forest. It's inconfigurability by obscurity.

There's an obvious solution to that: have the user interface list only the packages which actually have configuration questions. It could also have a "bookmarks"-like functionality for quick access to the most-often-reconfigured packages.

> c) If there is such a tool, Debian sure doesn't mention it prominently enough, I think (I must be wrong ;-)

If its package description is correct, Synaptic is such a tool:

Besides these basic functions the following features are provided:
* Search and filter the list of available packages
...
* Configure packages through the debconf system
...

As for Debian not mentioning it prominently enough, it seems to me that Synaptic is well-known as a program for installing packages, but is less well-known as a configuration manager. So, yes, Debian (or Ubuntu) should publicize it better. (They should publicize debconf itself better, too.)

by rqosa (not verified)

Ubuntu Hoary includes GNOME System Tools (in "main").

by Roberto Alsina (not verified)

Ok, this is starting to be long enough to be a usenet thread, so I will try to keep it short.

a) xrandr is not good enough because it changes it for the session only. You can use something like krandrtray and make it redo it every login but it still doesn't fix, for example, a bad default resolution in kdm.

b) I thought we were talking about regular users.

> Also, it's not too difficult to search for it:

> $ apt-cache search 'X\.Org' | grep erver

Is not exactly trivial, you know. Not to mention that you are searching for X.Org that, again, the user may never have heard of.

c) You know, in most places you can buy a CD for about the cost of a hamburger that will have your linux distro of choice already burned in it. That would avoid using such a weird install mechanism.

The problem you had was that most RPMs you installed never ran their post-install scripts.

d) The default install of all the systems I mentioned install all basic configuration tools. If you specifically ask *not* to install them, it's your problem to get them later. Debian is pretty much the opposite.

e)You say:

> There's an obvious solution to that: have the user interface list only
> the packages which actually have configuration questions.

Well, sure. It's not there, though.

I'm outta here.

by rqosa (not verified)

> c) You know, in most places you can buy a CD for about the cost of a hamburger that will have your linux distro of choice already burned in it. That would avoid using such a weird install mechanism.

Why should I have to have a CD whose contents will quickly become outdated? That seems wasteful to me. (Ok, there are CD-RWs, but where can I take my CD-RW disk to get an ISO installer image written to it?)

> The problem you had was that most RPMs you installed never ran their post-install scripts.

Oh really? Using rpm2cpio won't run the post-install scripts, true, but I re-installed *EVERYTHING* using "rpm -i" (or maybe "rpm -U", I'm not sure). I don't understand why "rpm -i" wouldn't run the post-install scripts.

I think it's more likely that the problems I had were because RPM-based distros rely on the installer to do some "special magic" at install time. I think this is on of the main reasons why RPM distros don't have an equivalent to "apt-get dist-upgrade" (or in the case of the RPM version of apt, I doubt that "dist-upgrade" works as well as in the .deb version).

by Roberto Alsina (not verified)

Well, the cost of a CD is USD 0,15. If you buy one with your distro of choice, it may be about USD 2. I am willing to bet the time it took you to work around not having the CD is worth more than that.

And no, the installer doesn't do any magic at all. I know, I have seen the code. For example, Anaconda, the most used one, simply installs everything, then it calls a few of the system-config-* tools to let you configure the basic stuff.

You can do the exact same thing, of course.

RPM distros *do* have the exact equivalent of apt-get dist-upgrade.

In fact, it *is* apt-get dist-upgrade, if you want, and it works just fine. I updated, for example, a RH8 to CentOS4 that way.

Sure, you can't update Ark to Fedora and expect it to work flawlessly, but there simply aren't two Debian-based distros that are so different.

by rqosa (not verified)

> For example, Anaconda, the most used one, simply installs everything, then it calls a few of the system-config-* tools to let you configure the basic stuff.

Well, I'd consider the use of system-config-* to be special treatment, because that doesn't happen when installing an RPM.

> In fact, it *is* apt-get dist-upgrade, if you want, and it works just fine. I updated, for example, a RH8 to CentOS4 that way.

Every time I've dist-upgraded with the .deb version of apt-get, there were debconf questions asked for many packages, in order to keep the settings the same even though the new configuration file will have different contents. In my experience, rpm would sometimes rename the file in question to "filename.rpmsave" and other times would keep the old file in place and put the new file at "filename.rpmnew". I would think that the .deb way of handling this situation is more reliable.

> Sure, you can't update Ark to Fedora and expect it to work flawlessly, but there simply aren't two Debian-based distros that are so different.

Once I tried to "yum update" from RH9 to WBEL3, and the resulting WBEL3 installation had some problems.

by Leo (not verified)

"Pure KGX"

What does that mean?

by cm (not verified)

_K_DE / _G_NU / Linu_x_

by c (not verified)

KDE
GNU
X

by cm (not verified)

Not according to this: http://en.wikipedia.org/wiki/KGX

by troll... (not verified)

> Not according to this: http://en.wikipedia.org/wiki/KGX

so i changed it... ;-P

cies breijs

by Bart Verwilst (not verified)

Hello!

One thing that's been "annoying" me about kubuntu is that it's kinda hard to follow the development progress of Kubuntu.. Would be cool to have some feeds/pages of new deb's getting into kubuntu, bugs getting fixed, and other stuffs that would make the whole kubuntu thingy more transparant.. The wiki is unsufficient for this IMHO. Otherwise, this distro rocks! It's been my main desktop distro for months!

Keep up the good work!

Cheers, B.

by Bart Verwilst (not verified)

damn i use the word "kubuntu" a lot :p

by Jonathan Riddell (not verified)

The breezy-changes mailing list has all the new package uploads. The kubuntu-bugs mailing list has all the beastie reports. Most of the development happens on IRC because of the reduced lag compared to mailing lists.

by Bart Verwilst (not verified)

Oh cool :d I knew it had to be somewhere ;) BTW, do you have any idea how's the status with the bootsplash thingy? Will that make it in breezy in time? I know it's not kubuntu specific, but still :d The debian init script system isn't the prettiest thing to look at while booting ;)

Thanks!

by Jonathan Riddell (not verified)

usplash has recently been written by mjg59, you can find details on how to test it on the ubuntu-devel mailing list (not sure the date, it was written during debconf). If it's reliable it should get into breezy.

by Miq (not verified)

I second that. It has also been my major complain. Those initial problems with kde-datalibs update, KUser crashes, Admin mode not working in KControl, Kopete MSN not working... have been pretty bad (even if it wasn't always Kubuntu's fault). It would have helpfull or at least reassuring if a web page listing all those quirks had been put up.
That it nonetheless has remained my distro of choice says a lot (good :)

Just a list with current important bugs or problems and a "next release goals list" (just a general idea) would be welcome. The information at udu.wiki.ubuntu.com is too much and too unclear.

Kubuntu as the KDE's developers personal distribution would be great

Keep up the good work!

by Miq (not verified)

Thanks, that's a fine page.
But don't you think it should be more visible from http://www.kubuntu.org.uk/ ? It's a bit difficult to find there (click at "Kubuntu 5.04 Announcement" then scroll down to "Feedback and Helping"). If kubuntu.org is to be some sort of portal for the distro it should have this important information very visible. Plus some kind of Feature plan for next release.

Is there information about ept? (the substitute for Kynaptic and Kapture). That would be most interesting. I think the only reason I have the GTK libraries installed is Synaptic. I might be able to help in the project.

by guillaumeh (not verified)

The "admin not working in kcontrol" problem is solved with kde 3.4.2

by Futal (not verified)

Unfortunately not! At least, it is still in Kubuntu Breezy (KDE 3.4.3). Not everybody experiences this bug but it is a real blocker for any newbie, especially since the new systemsettings kdesu window doesn't show anymore the name of the kcmshell command.

http://bugzilla.ubuntu.com/show_bug.cgi?id=8681

by Leo (not verified)

Does anyone know if KDE 3.4.2 will be available for amd64? Currently the packages.gz for amd64 doesn't exist on any of the mirrors. Seems to be i386 only.

by Jonathan Riddell (not verified)

I don't have any plans to make them, mainly because I don't have access to an amd64.

by Tim Sutton (not verified)

That system settings looks sweet! (Obviously mac inspired!) Where can I get more ingo on it? Is it apt-gettable yet?

Thanks

Tim