There's also fedora-desktop-list, perhaps discussions like this would work better there? There's actually a discussion going on there right now about the # of music players that are in our menus.

Dan

On Wed, 2004-04-21 at 15:57 -0400, Bill Nottingham wrote:

Razvan Corneliu C.R. d3vi1 VILT (razvan.vilt@linux360.ro) said:

...

Well... it seems like we have some small issues in the future path of the fedora core desktop (not only for fedora actually).

1. Menus. More is not the best solution, so it's out. We should try to

create a replacement, because in some situations the menus are overwhelming. 2) How many applications doing the same thing do we need? Having too many applications can be confusing. A new user (especially one that comes from another OS or from an old Linux distribution version), would be confused and might not make the optimal choice for his situation. Think of how many music players we have, how many editors, how many mail clients. Should all these be in the equivalent of the now deprecated X-Red-Hat-Base? Should we even show all the applications we have installed or just the popular ones? A Microsoft style hide unused entries would be practical? Are there any other solutions, such as 2/3 level menu tree?

This are related. The answer is generally to just move stuff out of Core, and into Extras. Eventually, if the user explicitly decides to install 20 mail clients, that's their own problem, but the default OS install shouldn't do this to them, yes.

Bill

-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-desktop-list

On Wed, 2004-04-21 at 16:23, Mariano Draghi wrote:

...

This are related. The answer is generally to just move stuff out of Core, and into Extras. Eventually, if the user explicitly decides to install 20 mail clients, that's their own problem, but the default OS install shouldn't do this to them, yes.

This is easy with some applications, and _very_ difficult with others. Take the (recent) example of Rythmbox vs XMMS f.i. And the same goes with Evolution vs KMail vs Mozilla Mail/Thunderbird. Right now, each of them has is strenghts, and there would be plenty of users that even for historical reasons will hate Fedora if we take out "their" e-mail client. Which one is the good default? Why?

I think that for some kind of applications, we should provide in Anaconda a list of choices, clearly specifying a recommended default: Which e-mail client would you like to install? [x] <b>Evolution (recommended)</b> [ ] Mozilla Mail [ ] KMail ... So the newbie can press [Next] and go on with the default, and the more advanced user (or just somebody a little more used to Linux) can clearly identify the default and change it for his own choice, or even choose (and install) all of them.

Besides, it would be nice to have some config tool to setup/change the default _after_ the installation, and this tool could take care of the MIME types, and menu auto-reconfiguration (i.e. move the new default e-mail client to the main menu, and the others (if any) to the extras).

-- Mariano

This would also be what I would like to see. For example, every time I upgrade or load a system I get the "out of the box" firewall rules without any other option. This is fine for average desktops and newbees, but causes my extra configuration work.

I would actually like more choices that can be selected as desired, in fact there was an issue with pine being removed.

On Thu, Apr 22, 2004 at 07:24:02PM -0400, Havoc Pennington wrote:

For the firewall example specifically, there's no real reason firewalls on most systems should even _require_ configuration - we know what services are up, we should open those ports and close the other ports. On a desktop, that probably means everything is closed. If someone starts a service, the initscript or whatever can open the port. If you don't want a port open, stop the service.

In that case, why even _have_ a firewall? If nothing's listening on a port, it's not like anyone can connect to it.

On Thu, 2004-04-22 at 21:23, Jens Knutson wrote:

On Thu, 2004-04-22 at 19:59, Matthew Miller wrote:

...

...

desktop, that probably means everything is closed. If someone starts a service, the initscript or whatever can open the port. If you don't want a port open, stop the service.

In that case, why even _have_ a firewall? If nothing's listening on a port, it's not like anyone can connect to it.

I suppose it's just for the case where you want to listen for connections from the local machine, but not from other machines? (Could use domain sockets for this too)

Also perhaps to block non-root users from starting servers on unreserved ports.

but then... if a service is to be made available, you can't have the firewall turned on for that port, so why have the service if the firewall will just prevent it from functioning?

Right, you just want to say "these services are available to the network, and nothing else is available" - and have the firewall and which daemons are started up reflect the desired availability.

I don't know. I'd be curious to hear about people who do anything complex with firewalling a single system. I know people do really complex things with a system that _is_ a firewall for a whole network. But for a standalone system firewalling itself it seems like you always want "enable the services this system provides, and disable everything else" - which seems like it can be automated if we have knowledge of those services.

Havoc

Having rear all the different opinions, i'd like to give one more.

Why not integrate yum, apt or up2date, doesn't matter wich one. Whith the actual package manager of Fedora? I myself think it currently misses a ton of features, so why not try to develop it, and it the way integrate a package updater and downloader in it? It's better for the newbie user, that get's all the control of the software in one place. And for the ones that prefer the console tools, they have it in the same way.

This is my opinion.

Thank you, and keep up the good work!

Nando

On Fri, 2004-04-23 at 00:47, Matt Hansen wrote:

Are you talking generically with that last sentence or is this in the works? i.e. http://fedora.redhat.com/projects/config-tools/ states a number of tools "that would be useful but do not exist yet". For example it lists: "Firewall - configuration tool for IP Tables (something more finegrained than redhat-config-securitylevel)" What's the status on this tool and other tools listed there? One tool that isn't listed that would be useful is a Mail server tool - could take some of the complexity out of setting up Sendmail/Postfix (esp. Sendmail). I suppose it's lack of RH developer interest/time?

I've been arguing that for the desktop end user, we need to eliminate the need to use any tool that ends up modifying files in /etc.

There's also a pretty strong argument that our primary target admin is going to be managing multiple systems and using kickstart, scripts, thin client, RHN, or other architectures to avoid configuring them one-by-one.

Basically manually configuring one system at a time kind of sucks, and SMBs and home users only do it because it's too much work to set up a nice architecture to avoid it. Configuring systems one at a time this way means you have to back up the full OS image of each system, systems get out of sync, etc.

So the question becomes what is the target audience of a GUI that only modifies a single system's config files in /etc. A possible answer is that you use this GUI to configure the template system or image subtree that gets replicated to multiple other systems.

Another question is whether effort should be focused on architecture for configuring multiple systems at once and avoiding per-system state.

An ideal is that your machine crashes, you get a new one, you assign a profile/template/whatever to the machine, and you're immediately back up and running with no reconfig or data loss.

To answer your question, I think we are still spending a fair bit of time on the config tools though.

Havoc

On Fri, 2004-04-23 at 10:01, seth vidal wrote:

...

There's also a pretty strong argument that our primary target admin is going to be managing multiple systems and using kickstart, scripts, thin client, RHN, or other architectures to avoid configuring them one-by-one.

is it?

The strongest argument for that (IMHO) is that a single machine is just the simplest case of multiple networked machines. Having an architecture that is network/multi-host aware allows it to apply equally well to both the individual home user and the LAN sysadmin.

let me give you a few common examples:

1. prof in the dept with a laptop
2. my dad

both run linux. I am the 'admin' for both machines. However I do not have immediate access to ssh into the machine. So I have to be able to talk them through things. Have you ever talked someone through vim or emacs for editing a file in /etc? it's a nightmare.

Well, aside from the issues of both vim and emacs being really, really unfriendly to first time users, talking someone through editing a text config file is much easier than trying to have them navigate a UI. Especially since UIs have a habit of changing much more quickly than the on-disk file format. If I'm running FC 3 and I'm trying to guide someone using FC 2 through a UI, the odds are pretty good it's going to take a lot longer than just having them edit the config files by hand. That's not counting the time it's going to take to have them find the right application. Even if the UI hasn't changed significantly, the odds are almost 100% (at this point) that the menu structure will have.

So I think there is definitely an argument for the home user to be editing their config files - even if those files are network configuration and adding a user.

-sv

I don't disagree, but this use case *should* be taken care of using the same tools that manage multiple hosts. Assuming the UI isn't poorly designed, most users would have no idea that the tools they were using could be used to manage multiple computers at the same time.

Hmm, though maybe the desktop sharing gadget in FC2 is helpful (although, if ssh doesn't work - is that a firewall thing? - I guess VNC won't either)

Has anyone external tried out the desktop sharing in a helpdesk-type situation?

It doesn't work, at all, through firewalls or nat. and it won't help, at all, when the problem is their network connection is hosed up.

-sv

On Fri, 2004-04-23 at 15:04, Havoc Pennington wrote:

On Fri, 2004-04-23 at 13:01, seth vidal wrote:

...

1. prof in the dept with a laptop

We should be able to get laptops managed. That other thread on fedora-devel mentioned this a bit maybe? Anyway, basically replicate the OS image to them whenever they are connected.

do you have any idea how intrusive that is? Especially on laptops where hardware gets ODD from release to release.

I disagree - there need to be ways for a user to setup and modify config files w/o having to understand each one. If I can't tell the chair how to reconfigure his network adapter for a static ip when he's in some remote location then there is going to be problems.

If we can't figure out how to manage laptops (require manual config/admin of them) then it's a big problem, since half of corporate desktops are laptops.

show me any other operating system that doesn't have manual administration of configuration settings (system-wide) be able to be done from a gui console?

Can you think of ANY?

I can think of lots that can't do mass-system-maintenance. But NONE that can't do a single-system maintenance.

you're going too far in the opposite direction and it just isn't realistic at all.

-sv

On 2004-04-23T15:18-0400, seth vidal wrote: ) On Fri, 2004-04-23 at 15:04, Havoc Pennington wrote: ) > If we can't figure out how to manage laptops (require manual ) > config/admin of them) then it's a big problem, since half of corporate ) > desktops are laptops. ) show me any other operating system that doesn't have manual ) administration of configuration settings (system-wide) be able to be ) done from a gui console?

http://www.slackware.org/ (everything is done from a traditional console)

However, I think you two may be talking past each other. Our goal is not to limit the power of our users, but rather to eliminate the need for their involvement in this task. (In "require manual config," emphasis is on "require.")

At worst, we would be enabling individual users' disempowerment by forces in network support. ("Do not reconfigure your machine or face the wrath of hostmaster!")

If done well, however, the machines' configuration (automatically determined and/or mass managed) would be robust enough to keep most users from ever worrying about using a "manual override." If the network support staff do not see frequent, repeated problems from the use of manual override, they should not need to issue any mandates about its use.

On Fri, 2004-04-23 at 15:37, Mariano Draghi wrote:

Havoc Pennington escribió:

...

This is a home user though as you say, not really a current focus at Red Hat. Though we're happy to see people improving Fedora in this respect and aren't going to reject enhancements for home users.

Havoc

Sorry, but http://fedora.redhat.com/ states: """ The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system exclusively from free software. """

I really don't see where the "home users" are excluded in that definition. I've been thinking that the "corporate" user was a target of RHEL, _not_ Fedora.

That's why I said "not really a current focus at Red Hat." Other contributors to Fedora could choose to focus on home users (and I'd encourage it).

Besides, many of the latests discussions in this list (rythmbox vs xmms being a very good example) are clearly focused in usability of things that have nothing to do with the corporate desktop client assisted by a IT department.

Lots of corporate environments do allow people to listen to music, and have webcasts and conf call recordings and things of that nature.

Really, I don't get the point.

My point is primarily that we need to be clear what the context is for every proposed enhancement. Ultimately there are multiple target users and multiple possible deployment scenarios, and you have to design different features and modes of the software to accomodate each of them.

In my opinion we can go ahead and assume that home installs won't work the same as corporate installs in many respects.

Though personally I would love an easy out-of-the-box way to set up my home network such that I got automatic backups, etc. ... I'm also pretty tech savvy.

Besides, if RedHat is going to focus only in the things they care (i.e., enterprise), and want others (the community) to do the rest of the work, then Red Hat should set up ASAP the infrastructure so the community can get more involved.

I certainly agree with that, and Christian and his team are working on it.

Right now (FC1), Fedora is a very "usable" and general purpose OS. Has this goal changed? When? Why? By whom?

The goal has not changed. What we're discussing here is adding new capabilities and focused improvements for particular audiences and scenarios.

UI design can't be done "generically," you have to know what your focus is. This is the reason I'm emphasizing our focus, because that is where our design proposals come from.

Red Hat does expect home users to be a focus down the line, and we don't want to see the OS go in directions that will preclude that.

Both Fedora and RHEL are intended to be general-purpose operating systems; home vs. corporate is not the difference between them (and server vs. desktop *certainly* is not the difference).

Anyway, to think about desktop UI and design crisply, we *must* distinguish different kinds of user and deployment scenario. In a whole lot of cases, we'll need multiple UIs. A router and a home desktop for example can't sanely use the same network config dialog.

Havoc

On Thu, 2004-04-22 at 19:24, Havoc Pennington wrote:

On Thu, 2004-04-22 at 16:50, jludwig wrote:

...

This would also be what I would like to see. For example, every time I upgrade or load a system I get the "out of the box" firewall rules without any other option. This is fine for average desktops and newbees, but causes my extra configuration work.

I don't think more installer options will happen - everyone is very in favor of kicking that stuff to firstboot or to config tools post-boot.

I'd like to see the firewall screen removed from anaconda. The installer would then disallow all incoming traffic by default with the possible exception of ssh. Then move the firewall screen to firstboot so that if the system is ever compromised, it's because the user specifically chose to open something up. We should try to be secure by default.

Having said that, I think we could improve the firewall screen a bit. Users moving over from Windows have no idea what "SSH" or "SMTP" connections are or why they would want to enable them. Other services in the list like "Telnet" should probably be removed since no one in their right mind should use telnet anymore.

Of course, kickstart will still be there for people who have highly customized configurations and need to roll them out to multiple machines.

Cheers, Brent

If you want to avoid manually configuring systems, what you want is kickstart.

For the firewall example specifically, there's no real reason firewalls on most systems should even _require_ configuration - we know what services are up, we should open those ports and close the other ports. On a desktop, that probably means everything is closed. If someone starts a service, the initscript or whatever can open the port. If you don't want a port open, stop the service.

Yes, some services can serve both local and remote users. Let those two aspects be started and stopped separately. "[ ] Receive print jobs from this machine" "[ ] Receive print jobs from other machines" - if both are unchecked, no print daemon starts.

But of course leave the config file, so if you really want some other firewall config, or are setting up a machine whose purpose is to be a firewall, rather than to be firewalled, you can create that config. And there might be a GUI for creating a custom firewall, covering common use-cases for that.

Havoc

On Thu, 2004-04-22 at 09:43, Gene C. wrote:

Should kdenetwork be split so kmail is not included but instead moved to Extras? This has to be a management nightmare.

For end-user apps (i.e. those in the menus), it will almost always be desirable to maintain a 1 .desktop file to 1 RPM mapping. And in fact we should be syncing the name of the package displayed in the package tool (including translations) with the .desktop file name. Or even making package management happen in terms of .desktop files. From a single-user standpoint, "menu editing" (at least in terms of add/remove items) and "package management" really have no reason to be different.

The ideal user experience might be to effectively refcount each RPM by the number of users that have it in their menus, and when nobody has the item in their menus the package gets removed. And similarly you'd install a package by choosing what items to add to your menus. Unclear if there's a sane way to implement this, but this is a nice way for a desktop user to see things.

Obviously it only works for desktop-app type of packages. You need another approach to deal with servers, though you could perhaps imagine a similar approach (when you enable the service, it automatically gets the required packages and punches the firewall to make the service go).

Also, even if package add/remove were combined with menu editing, you still need an "update" or "get patches" kind of UI... though judging by the number of Windows viruses out there, perhaps the default should be to run this thing automatically every night unless the user opts out ;-)

Anyway, we really should think about the issue much more broadly and not assume that the task at hand is "write a single tool that does package management." How can we get it smoothly integrated into the desktop? Maybe there are multiple tools for different tasks or kinds of user.

There are related problems too, such as making it really easy for third parties to provide a set of RPMs with comps file on a CD or in an http directory, and handle that really nicely with an install wizard.

Just some brainstorm ideas. Let's start with what the user should see though, and then figure out how to implement our closest approximation.

Havoc

Havoc Pennington wrote:

[ ... snip ... ] For end-user apps (i.e. those in the menus), it will almost always be desirable to maintain a 1 .desktop file to 1 RPM mapping. And in fact we should be syncing the name of the package displayed in the package tool (including translations) with the .desktop file name. Or even making package management happen in terms of .desktop files. From a single-user standpoint, "menu editing" (at least in terms of add/remove items) and "package management" really have no reason to be different.

I can't agree more with you on that, specially w/ the last sentence. It would be a much more clear 'metaphor' for the newbie. I've never tried a Mac on my life, but I believe that there is in Mac OS a kind of vFolder where all the applications reside, moving an installer there installs the application, removing the application from there uninstalls it (please correct me if I'm wrong). Anyway, I think a strong relationship between Menu Items and Applications is a big step in usability... It would be very intuitive for a new user to drag an RPM to the menu, and have the application installed.

But I can't figure out how we can deal with a multiple-user desktop... should the new added RPM appear auto magically in all the other users' menus? Should the system alert the other users in the next login about a recently added application, and ask them if they want to use it? (i.e. put it in the menu)

What it's clear is that for desktop-apps it has no sense to have the app installed without the matching menu entry somewhere.

Just some brainstorm ideas.

Same here ;)

On Thu, 2004-04-22 at 13:33 -0400, Havoc Pennington wrote:

On Thu, 2004-04-22 at 09:43, Gene C. wrote:

...

Should kdenetwork be split so kmail is not included but instead moved to Extras? This has to be a management nightmare.

For end-user apps (i.e. those in the menus), it will almost always be desirable to maintain a 1 .desktop file to 1 RPM mapping. And in fact we should be syncing the name of the package displayed in the package tool (including translations) with the .desktop file name. Or even making package management happen in terms of .desktop files. From a single-user standpoint, "menu editing" (at least in terms of add/remove items) and "package management" really have no reason to be different.

The ideal user experience might be to effectively refcount each RPM by the number of users that have it in their menus, and when nobody has the item in their menus the package gets removed. And similarly you'd install a package by choosing what items to add to your menus. Unclear if there's a sane way to implement this, but this is a nice way for a desktop user to see things.

Obviously it only works for desktop-app type of packages. You need another approach to deal with servers, though you could perhaps imagine a similar approach (when you enable the service, it automatically gets the required packages and punches the firewall to make the service go).

Also, even if package add/remove were combined with menu editing, you still need an "update" or "get patches" kind of UI... though judging by the number of Windows viruses out there, perhaps the default should be to run this thing automatically every night unless the user opts out ;-)

Anyway, we really should think about the issue much more broadly and not assume that the task at hand is "write a single tool that does package management." How can we get it smoothly integrated into the desktop? Maybe there are multiple tools for different tasks or kinds of user.

There are related problems too, such as making it really easy for third parties to provide a set of RPMs with comps file on a CD or in an http directory, and handle that really nicely with an install wizard.

Just some brainstorm ideas. Let's start with what the user should see though, and then figure out how to implement our closest approximation.

Havoc

That sounds soo nice for the end user. But what about me? I've been using linux since 1996. I was 12 by then and I'm not sure I'm ready for such radical changes. I just love being in control of things. First I WANT to be able to select the rpm packages one-by-one, whether it's in anaconda or system-config-packages, we should not forget those users which want to be in control. It's nice to have an easier way, but lets not give up the power of rpm.

Havoc Pennington said:

One suggestion from Seth is to have a "UNIX" comps group, containing all the GUI stuff that traditional UNIX users expect that would not be interesting to our desktop users.

or even call it 'power users', this would also take care of the 'xmms or rhythmbox' argument. just have xmms as a part of that, so casual users won't have to know it's there or get frustrated by it.

-+(duncan brown -+(duncanbrown@linuxadvocate.net -+(http://www.linuxadvocate.net

() ascii ribbon campaign - against html e-mail /\ - against microsoft attachments

Blessed is the man who, having nothing to say, abstains from giving wordy evidence of the fact. -- George Eliot

Matthew Miller wrote:

On Thu, Apr 22, 2004 at 07:11:00PM -0400, Havoc Pennington wrote:

...

One suggestion from Seth is to have a "UNIX" comps group, containing all the GUI stuff that traditional UNIX users expect that would not be interesting to our desktop users.

"Old School".

That would rock. A large group of academic users at my school would thank you. One of our school's most ardent Linux advocates is a Fvwm2 user. It's important not to leave people behind when it's of minimal pain to offer plenty of small programs like that and make sure they work correctly.

On Wednesday 21 April 2004 15:57, Bill Nottingham wrote:

Razvan Corneliu C.R. d3vi1 VILT (razvan.vilt@linux360.ro) said:

...

Well... it seems like we have some small issues in the future path of the fedora core desktop (not only for fedora actually).

1. Menus. More is not the best solution, so it's out. We should try to

create a replacement, because in some situations the menus are overwhelming. 2) How many applications doing the same thing do we need? Having too many applications can be confusing. A new user (especially one that comes from another OS or from an old Linux distribution version), would be confused and might not make the optimal choice for his situation. Think of how many music players we have, how many editors, how many mail clients. Should all these be in the equivalent of the now deprecated X-Red-Hat-Base? Should we even show all the applications we have installed or just the popular ones? A Microsoft style hide unused entries would be practical? Are there any other solutions, such as 2/3 level menu tree?

This are related. The answer is generally to just move stuff out of Core, and into Extras. Eventually, if the user explicitly decides to install 20 mail clients, that's their own problem, but the default OS install shouldn't do this to them, yes.

Some additional thought (besides what I posted in my other message):

How about the multiple desktops supported (gnome/metacity, gnome/sawfish, kde, xfce)?

How about upgrade support? What happens during an upgrade when something (lets take sawfish) is moved from Fedora Core to Fedora Extras? Will this break upgrade.

Some time ago there was a message posted to the fedora-config-list about a new package management tool: http://fedora.redhat.com/projects/config-tools/specs/redhat-config-packages

I believe such a tool may be necessary in order to do any shuffling of packages between Core and Extras (especially from Core to Extras).

On Thursday 22 April 2004 11:55, Razvan Corneliu C.R. \ wrote:

...

Some time ago there was a message posted to the fedora-config-list about a new package management tool: http://fedora.redhat.com/projects/config-tools/specs/redhat-config-packag es

I believe such a tool may be necessary in order to do any shuffling of packages between Core and Extras (especially from Core to Extras).

That tool exists for some time. It's called system-config-packages lately. The downside is that it simply doesn't do all that yet.

It has been doing what it currently does for a long time not ... even when it is named redhat-config-packages.

The network stuff would be nice but it is the individual package installation/removal that is needed (at least by me).

There was a point (in the FC1 development cycle IIRC) where x-config-packages could install (and remove?) individual package but this got dropped because of some problems. At the time there was come comments to the effect of "we really need to do this right and redesign the whole thing with system-config-packages and up2date merging" (IIRC).

Up2date has "some" of the needed functionality (install but not remove) with the --show-package-dialog command line option. But this is currently broken in that it only works if you have pending updates too (otherwise it says your system is up-to-date).

On Thursday 22 April 2004 12:50, seth vidal wrote:

...

The network stuff would be nice but it is the individual package installation/removal that is needed (at least by me).

There was a point (in the FC1 development cycle IIRC) where x-config-packages could install (and remove?) individual package but this got dropped because of some problems. At the time there was come comments to the effect of "we really need to do this right and redesign the whole thing with system-config-packages and up2date merging" (IIRC).

I think a lot of system-config-packages is going to be the subject of a discussion sometime soon b/t me and katz and others. Specifically, figuring out if we can make s-c-p frontend for yum in an intelligent way.

Yes! This is the obvious (to me) solution for accessing packages via the network is yum ... why reinvent things when you have a good capability.

Now, the rest of the story ... handing installation of individual new packages as well as removal of individual installed packages (including removing selected installed kernels).

While the current package groupings can work for many, they do not work for everyone. The manual effort of removing packages from an everything install or installing additional packages from a selected install if very time consuming. The package management tool (at least as described in http://fedora.redhat.com/projects/config-tools/specs/redhat-config-packages ) looks like it would be very close to addressing my needs.

On Thursday 22 April 2004 13:12, seth vidal wrote:

...

Yes! This is the obvious (to me) solution for accessing packages via the network is yum ... why reinvent things when you have a good capability.

Now, the rest of the story ... handing installation of individual new packages as well as removal of individual installed packages (including removing selected installed kernels).

There needs to be some work done on the lists of packages displayed in s-c-p - then that can be handled. The new yum-HEAD work is intending to make specific package selection more possible.

If you have individual and group installation and removal (plus handling multiple repository which I believe yum already does ... I am not currently a yum user), this could give the needed functionality as well as replace up2date.

On Thu, 2004-04-22 at 13:29, seth vidal wrote:

...

If you have individual and group installation and removal (plus handling multiple repository which I believe yum already does ... I am not currently a yum user), this could give the needed functionality as well as replace up2date.

up2date isn't going away - it's interfaces to rhn and the protocols involved are it's best feature - in addition, adrian has generated a rather impressive infrastructure in up2date.

But I would like to see a nice gui on yum and some neat utils derived from there.

To me a separate GUI based on the backends used is pretty darn weird. I don't see how it's sane to install both a yum gui and an up2date gui by default for example.

Havoc

not only that, but you'd be re-inventing the wheel. apt should be a part of fedora core, along with synaptic. i know that there are problems with multi-arch procs and apt, but why not devote the time and effort into getting apt up to snuff (along with synaptic) and have that as your update manager?

all the config tools I can think of in fedora core are in python - why go out and work on one which is all in C or C++?

Synaptic is all in C and C++.

-sv

To me a separate GUI based on the backends used is pretty darn weird. I don't see how it's sane to install both a yum gui and an up2date gui by default for example.

then why are s-c-p and up2date separate now?

Why does s-c-p exist at all?

-sv

The original plan was to eventually deprecate one, but then nobody has had a ton of time to work on it. s-c-p was a newer UI proposal.

then this is something worth discussing. do rhel commitments make it impossible to modify up2date interface? I think starting from the base of s-c-p leaves a lot of room to grow.

this is an area I am deeply interested in working on. -sv