I hope my two cents here is what the Fedora Usability Project is looking for.
For office desktop users, there are several usability issues with the old "ethernet cable is unplugged" problem. These problems affect a "normal" Fedora Core 5 office computer that uses ethernet, DHCP, NIS (for authentication), and NFS (especially for users' home directories). Some of the problems also affect (a) home users and (b) situations where the cable is plugged in but the network services are unavailable.
1. If the computer starts with the cable unplugged, then there's a start-up message like "Determining IP information for eth0:. Failed or link not present. Check cable?" First, some people may not read it because the startup messages are a bunch of technical mumbo-jumbo. Second, some people may be getting a cup of coffee instead of watching the screen during (long) startup process.
2. If the ethernet doesn't work at startup, it dies forever. If I plug in my ethernet cable some time later after startup, nothing happens. Even if the user can figure out the problem, it seems the user has to have root privileges to do "service network restart" to get the network back up.
3. If ypbind can't connect at startup, it just dies forever. Even if the user can figure out the problem, it seems the user has to have root privileges to do "service ypbind restart".
4. If NFS mounting fails at startup, it stays unmounted until manually mounted. Even if the user can figure out the problem, it seems the user has to have root privileges to do mount the directories. Though there is a setting in /etc/fstab to allow users to mount directories without root privileges, it also allows them to unmount the directories.
5. If a user tries to log in when the system is suffering from the above problems, GDM just tells him his username or password is incorrect. This error message is misleading: the more fundamental problem is related to networking.
Based on these problems, here's what would reduce confusion, eliminate help desk calls, and make people happy:
1. If the network cable is unplugged and the system requires networking for authentication (NIS), then display a warning in GDM.
2. Better yet, cache authentication from ypbind. Supposedly, there are ways to do it, but the only way it's ever worked for me is to configure the system as a slave NIS server.
3. If the user is already logged in when the ethernet network goes down, display from the system tray using the new pop-up notification system in Gnome 2.14. Also, a system tray icon may be helpful if the user is away from his desk when the problem happens.
4. If the DHCP server/NIS server/NFS server is unavailable when the system starts but is available later, the system should do something roughly equivalent to "service network restart; service ypbind restart" and then mount NFS drives. Basically, DHCP, ypbind, and NFS mounts should be more resilient.
As a quick competitive analysis, a Windows 2000 system does not suffer any of these problems while not requiring any extra configuration.
Andrew
Andrew Ziem (andrewz@springsrescuemission.org) said:
- If the computer starts with the cable unplugged, then there's a
start-up message like "Determining IP information for eth0:. Failed or link not present. Check cable?" First, some people may not read it because the startup messages are a bunch of technical mumbo-jumbo. Second, some people may be getting a cup of coffee instead of watching the screen during (long) startup process.
Use NetworkManager.
- If the ethernet doesn't work at startup, it dies forever. If I plug
in my ethernet cable some time later after startup, nothing happens. Even if the user can figure out the problem, it seems the user has to have root privileges to do "service network restart" to get the network back up.
Use NetworkManager. :)
- If ypbind can't connect at startup, it just dies forever. Even if
the user can figure out the problem, it seems the user has to have root privileges to do "service ypbind restart".
This is best solved with proper dependency resolution in the initscripts.
- If NFS mounting fails at startup, it stays unmounted until manually
mounted. Even if the user can figure out the problem, it seems the user has to have root privileges to do mount the directories. Though there is a setting in /etc/fstab to allow users to mount directories without root privileges, it also allows them to unmount the directories.
Same here
Based on these problems, here's what would reduce confusion, eliminate help desk calls, and make people happy:
- If the network cable is unplugged and the system requires networking
for authentication (NIS), then display a warning in GDM.
- Better yet, cache authentication from ypbind. Supposedly, there are
ways to do it, but the only way it's ever worked for me is to configure the system as a slave NIS server.
See pam_ccreds.
- If the user is already logged in when the ethernet network goes down,
display from the system tray using the new pop-up notification system in Gnome 2.14. Also, a system tray icon may be helpful if the user is away from his desk when the problem happens.
Use NetworkManager. (Yes, I'm a broken record here.)
Bill
man, 14 08 2006 kl. 20:23 -0400, skrev Bill Nottingham:
Use NetworkManager. (Yes, I'm a broken record here.)
Bill
Pretty much Bill, so pray tell us when exactly will NM be ready for default deployment in Fedora like say OpenSuSE/SLED does. Untill that glorious day these concerns are perfectly valid and a perfect indicator as to just how much we need a fully functional NM implementation suitable for the core Fedora use cases.
- David Nielsen
David Nielsen (david@lovesunix.net) said:
Use NetworkManager. (Yes, I'm a broken record here.)
Pretty much Bill, so pray tell us when exactly will NM be ready for default deployment in Fedora like say OpenSuSE/SLED does. Untill that glorious day these concerns are perfectly valid and a perfect indicator as to just how much we need a fully functional NM implementation suitable for the core Fedora use cases.
If you want to deploy a desktop in such a configuration how does:
chkconfig --level 345 network off chckonfig --level 345 NetworkManager on
not work for you?
Bill
tir, 15 08 2006 kl. 01:22 -0400, skrev Bill Nottingham:
David Nielsen (david@lovesunix.net) said:
Use NetworkManager. (Yes, I'm a broken record here.)
Pretty much Bill, so pray tell us when exactly will NM be ready for default deployment in Fedora like say OpenSuSE/SLED does. Untill that glorious day these concerns are perfectly valid and a perfect indicator as to just how much we need a fully functional NM implementation suitable for the core Fedora use cases.
If you want to deploy a desktop in such a configuration how does:
chkconfig --level 345 network off chckonfig --level 345 NetworkManager on
not work for you?
My point was that we don't yet do this by default which means the concerns still apply to any default case for Fedora.
And I was wondering when we might see NetworkMAnager be deployed as the standard solution for networking, I'm hoping for FC7.
- David
On Tue, 2006-08-15 at 07:04 +0200, David Nielsen wrote:
man, 14 08 2006 kl. 20:23 -0400, skrev Bill Nottingham:
Use NetworkManager. (Yes, I'm a broken record here.)
Bill
Pretty much Bill, so pray tell us when exactly will NM be ready for default deployment in Fedora like say OpenSuSE/SLED does. Untill that
SUSE doesn't have that many custom patches for NetworkManager, they pretty much ship a stock version. So the base functionality isn't the same. What they have chosen to do is just flip the switch, turn it on by default, and people then live with it or turn it off.
They just flipped the switch, and seem to be doing fine so far. [1]
Dan
[1] That doesn't mean it would be fine for us, of course. But it's a data point.
glorious day these concerns are perfectly valid and a perfect indicator as to just how much we need a fully functional NM implementation suitable for the core Fedora use cases.
- David Nielsen
Dan Williams wrote:
SUSE doesn't have that many custom patches for NetworkManager, they pretty much ship a stock version. So the base functionality isn't the same. What they have chosen to do is just flip the switch, turn it on by default, and people then live with it or turn it off.
They just flipped the switch, and seem to be doing fine so far. [1]
Dan
[1] That doesn't mean it would be fine for us, of course. But it's a data point.
Without any deep understanding of the issues I would say we can do the same for FC6 and update the missing features later.
Rahul
On Tue, 2006-08-15 at 07:31 -0400, Dan Williams wrote:
On Tue, 2006-08-15 at 07:04 +0200, David Nielsen wrote:
man, 14 08 2006 kl. 20:23 -0400, skrev Bill Nottingham:
Use NetworkManager. (Yes, I'm a broken record here.)
Bill
Pretty much Bill, so pray tell us when exactly will NM be ready for default deployment in Fedora like say OpenSuSE/SLED does. Untill that
SUSE doesn't have that many custom patches for NetworkManager, they pretty much ship a stock version. So the base functionality isn't the
This should read "So the base functionality _is_ the same".
same. What they have chosen to do is just flip the switch, turn it on by default, and people then live with it or turn it off.
They just flipped the switch, and seem to be doing fine so far. [1]
Dan
[1] That doesn't mean it would be fine for us, of course. But it's a data point.
glorious day these concerns are perfectly valid and a perfect indicator as to just how much we need a fully functional NM implementation suitable for the core Fedora use cases.
- David Nielsen
On Tue, 2006-08-15 at 07:50 +0200, David Nielsen wrote:
My point was that we don't yet do this by default which means the concerns still apply to any default case for Fedora.
Perhaps what the world needs is a derived Fedora Core distribution tailored for the desktop. Same packages [1], few patches [2], just different behaviour out of the box more suited for the desktop.
Certainly a lot easier trying to explain the powers that be ... things like it's easier for servers admins to
chkconfig --level 345 network on chckonfig --level 345 NetworkManager off
instead of asking people installing a desktop to do
chkconfig --level 345 network off chckonfig --level 345 NetworkManager on
as the latter category of people is not really UNIX savy.
Doing a derived distro for the desktop would allow us to care more about the desktop without wasting time educating other stake holders in Fedora that we need this or that change for the desktop to work well.
Maybe the desktop needs a break from the rest of the distro. Just a thought.
David
[1] : well, all the daily crob jobs like updatedb etc. plus much more would have to go :-)
[2] : maybe that glibc patch to reread /etc/resolv.conf so we don't have to run bind for NetworkManager in the default install :-)
On Tue, 2006-08-15 at 22:10 +0530, Rahul wrote:
David Zeuthen wrote:
[1] : well, all the daily crob jobs like updatedb etc. plus much more would have to go :-)
Not very relevant to larger idea of a derived distro which might very well be a good thing to try but we dont run updatedb cron by default for a while now.
Well, I'm aware of that, but the script is still installed with tons of other stuff that we don't need on a modern desktop [1]. There's so many things we have right now that we don't need in a desktop distro.
For example, the very idea of using anaconda to install the OS is just wrong in 2006. The way you want to do this (and Ubuntu is doing this already) is clearly to have a bootable CD with a "Install OS to hard disk" icon that does what you want. Nothing more, nothing less.
This, and tons of other things e.g. krh's plymouth stuff, is not something I personally want to try in the context of Fedora - I'd much rather spend my time working on the bits to actually enable this (and I am) rather than argue with the powers that be what the implications of doing this is for arcane platforms like ia64 or s390 :-)
David
[1] : sure, servers or the UNIX people might need it. They can just install Fedora or, who knows, maybe a derived distro tailored for them :-)
On Tue, 2006-08-15 at 12:56 -0400, David Zeuthen wrote:
For example, the very idea of using anaconda to install the OS is just wrong in 2006. The way you want to do this (and Ubuntu is doing this already) is clearly to have a bootable CD with a "Install OS to hard disk" icon that does what you want. Nothing more, nothing less.
Of course, I meant a livecd here. So you could actually try out the bits in the OS e.g. Firefox, NetworkManager, 3d apps etc. etc.. So, you know, you can make sure the OS works on your hardware before installing it.
David
David Zeuthen wrote:
On Tue, 2006-08-15 at 22:10 +0530, Rahul wrote:
David Zeuthen wrote:
[1] : well, all the daily crob jobs like updatedb etc. plus much more would have to go :-)
Not very relevant to larger idea of a derived distro which might very well be a good thing to try but we dont run updatedb cron by default for a while now.
Well, I'm aware of that, but the script is still installed with tons of other stuff that we don't need on a modern desktop [1]. There's so many things we have right now that we don't need in a desktop distro.
For example, the very idea of using anaconda to install the OS is just wrong in 2006. The way you want to do this (and Ubuntu is doing this already) is clearly to have a bootable CD with a "Install OS to hard disk" icon that does what you want. Nothing more, nothing less.
They do have a traditional style installer too. I was discussing the Live CD with installer option in fedora-livecd list and Jeremy Katz didnt appear too keen on it. However I completely agree with you on having this atleast as a option. If we have enough people willing to do a Fedora Desktop derivative, then lets just do that. We are going down that path of enabling such things to happen anyway.
Rahul
David Zeuthen (david@fubar.dk) said:
On Tue, 2006-08-15 at 12:56 -0400, David Zeuthen wrote:
For example, the very idea of using anaconda to install the OS is just wrong in 2006. The way you want to do this (and Ubuntu is doing this already) is clearly to have a bootable CD with a "Install OS to hard disk" icon that does what you want. Nothing more, nothing less.
Of course, I meant a livecd here. So you could actually try out the bits in the OS e.g. Firefox, NetworkManager, 3d apps etc. etc.. So, you know, you can make sure the OS works on your hardware before installing it.
No, you make sure the OS has the applications for your needs before installing it. It obviously should work on all your hardware as a matter of course. :)
Bill
tir, 15 08 2006 kl. 22:38 +0530, skrev Rahul:
David Zeuthen wrote:
On Tue, 2006-08-15 at 22:10 +0530, Rahul wrote:
David Zeuthen wrote:
[1] : well, all the daily crob jobs like updatedb etc. plus much more would have to go :-)
Not very relevant to larger idea of a derived distro which might very well be a good thing to try but we dont run updatedb cron by default for a while now.
Well, I'm aware of that, but the script is still installed with tons of other stuff that we don't need on a modern desktop [1]. There's so many things we have right now that we don't need in a desktop distro.
For example, the very idea of using anaconda to install the OS is just wrong in 2006. The way you want to do this (and Ubuntu is doing this already) is clearly to have a bootable CD with a "Install OS to hard disk" icon that does what you want. Nothing more, nothing less.
They do have a traditional style installer too. I was discussing the Live CD with installer option in fedora-livecd list and Jeremy Katz didnt appear too keen on it. However I completely agree with you on having this atleast as a option. If we have enough people willing to do a Fedora Desktop derivative, then lets just do that. We are going down that path of enabling such things to happen anyway.
I would definitely lend any help I can to such a project, I use Fedora exclusively as my desktop OS so I have a great interest in seeing it be all it can be even if that means taking it out of the context of the regular Fedora distribution. I don't especially see why we couldn't do it within Fedora but if it's preferred to do it in a seperate sub project then that would be fine by me.
I'm however not a big fan of livecd installers, I think livecds are great for testing but if I want to install something then I'm in favor of the "old school" Fedora method. It just seems cleaner to me. Also the installers of that kind I've tried so far aren't really all that good. I recently played with the Ubuntu installer and it doesn't support half the nice things Anaconda does, e.g. I was completely unable to perform the some what simple task of setting up my two 400gig drives in a RAID, let alone up LVM on top of that. Sure that could be added but we have that in a perfectly fine form within Anaconda already.
But Fedora would make a great foundation for a top of the line secure desktop with all the lastest in cool technology for that market. NetworkManager just being one of them, I could see us having fun with stuff like Galago and Telepathy, there are plenty of areas where the desktop experience can be improved.
- David Nielsen
On Tue, 2006-08-15 at 19:43 +0200, David Nielsen wrote:
I was completely unable to perform the some what simple task of setting up my two 400gig drives in a RAID, let alone up LVM on top of that. Sure that could be added but we have that in a perfectly fine form within Anaconda already.
The really funny thing is that I agree that Anaconda excels at this point. However, it's really way beyond me why this great functionality is restricted to install time only. Why can't I do RAID and LVM easily from the desktop to setup external drives?
(Sure, you can say system-config-lvm is one answer for LVM at least but that leaves RAID out of the question.)
That's why I started writing a Disk Utility for GNOME - the plan is for it to work much like Mac OS X's Disk Uility and also do RAID / LVM, here's a very early screenshot
http://people.freedesktop.org/~david/gdu-2.png
It uses HAL and PolicyKit so we'll also get out of that "run X11 apps as root" trap plus once we teach HAL about RAID / LVM we can add options to g-v-m such as
[ ] Assemble RAID arrays when hotplugged [ ] Set up Logical Volumes when hotplugged
etc. etc.
David
tir, 15 08 2006 kl. 14:22 -0400, skrev David Zeuthen:
On Tue, 2006-08-15 at 19:43 +0200, David Nielsen wrote:
I was completely unable to perform the some what simple task of setting up my two 400gig drives in a RAID, let alone up LVM on top of that. Sure that could be added but we have that in a perfectly fine form within Anaconda already.
The really funny thing is that I agree that Anaconda excels at this point. However, it's really way beyond me why this great functionality is restricted to install time only. Why can't I do RAID and LVM easily from the desktop to setup external drives?
(Sure, you can say system-config-lvm is one answer for LVM at least but that leaves RAID out of the question.)
That's why I started writing a Disk Utility for GNOME - the plan is for it to work much like Mac OS X's Disk Uility and also do RAID / LVM, here's a very early screenshot
http://people.freedesktop.org/~david/gdu-2.png
It uses HAL and PolicyKit so we'll also get out of that "run X11 apps as root" trap plus once we teach HAL about RAID / LVM we can add options to g-v-m such as
[ ] Assemble RAID arrays when hotplugged [ ] Set up Logical Volumes when hotplugged
etc. etc.
That looks awesome, it is also a testament to your lack of blogging about cool stuff recently.
- A lesser cool David
David Zeuthen (david@fubar.dk) said:
http://people.freedesktop.org/~david/gdu-2.png
It uses HAL and PolicyKit so we'll also get out of that "run X11 apps as root" trap plus once we teach HAL about RAID / LVM we can add options to g-v-m such as
[ ] Assemble RAID arrays when hotplugged [ ] Set up Logical Volumes when hotplugged
How are you handling partial volumes?
Bill
On Tue, 2006-08-15 at 14:48 -0400, Bill Nottingham wrote:
David Zeuthen (david@fubar.dk) said:
http://people.freedesktop.org/~david/gdu-2.png
It uses HAL and PolicyKit so we'll also get out of that "run X11 apps as root" trap plus once we teach HAL about RAID / LVM we can add options to g-v-m such as
[ ] Assemble RAID arrays when hotplugged [ ] Set up Logical Volumes when hotplugged
How are you handling partial volumes?
This code is not written yet (patches welcome!) but I suspect you will be able to start partly-assembled stuff from g-d-u after clicking a warning dialog or two.
David
David Zeuthen (david@fubar.dk) said:
It uses HAL and PolicyKit so we'll also get out of that "run X11 apps as root" trap plus once we teach HAL about RAID / LVM we can add options to g-v-m such as
[ ] Assemble RAID arrays when hotplugged [ ] Set up Logical Volumes when hotplugged
How are you handling partial volumes?
This code is not written yet (patches welcome!) but I suspect you will be able to start partly-assembled stuff from g-d-u after clicking a warning dialog or two.
No, I mean you'll get disparate events:
- hey, I added hda1! - Looks like it might be part of VG <foo>... - hey, I added hdb1! - Looks like it might be part of VG <foo>... <kernel takes a nap, five seconds later> - hey, I added hdc1! - Looks like it might be part of VG <foo>...
When do you decide to assemble?
Bill
On Tue, 2006-08-15 at 15:21 -0400, Bill Nottingham wrote:
No, I mean you'll get disparate events:
- hey, I added hda1!
- Looks like it might be part of VG <foo>...
- hey, I added hdb1!
- Looks like it might be part of VG <foo>...
<kernel takes a nap, five seconds later>
- hey, I added hdc1!
- Looks like it might be part of VG <foo>...
When do you decide to assemble?
Each PV got enough metadata to tell what the entire LV looks like - e.g. actually each PV has metadata saying 1) I'm part of LV "foo"; and 2) LV foo consists of PV's "bar", "baz" and "bat".
So we just teach HAL to pick up this metadata (like we already do for 20 + file systems) and then export it as volume.linux.lvm.* properties and then g-v-m can do the right thing when it sees all the PV's. It's actually pretty simple.
Same thing for is true for RAID. However, for RAID, we might allow the user to start a RAID mirror set (probably from g-d-u) even if some backing volumes are missing but we probably shouldn't do this automatically. Except for maybe on boot but that's initramfs / initscripts business. That's what I thought you were asking :-)
David
On 15 August 2006, at 11:33, David Zeuthen wrote:
On Tue, 2006-08-15 at 07:50 +0200, David Nielsen wrote:
My point was that we don't yet do this by default which means the concerns still apply to any default case for Fedora.
Perhaps what the world needs is a derived Fedora Core distribution tailored for the desktop. Same packages [1], few patches [2], just different behaviour out of the box more suited for the desktop.
We already have a "Desktop" option in the installer. I propose that that option configure things differently, instead of just juggling packages differently.
Certainly a lot easier trying to explain the powers that be ... things like it's easier for servers admins to
chkconfig --level 345 network on chckonfig --level 345 NetworkManager off
instead of asking people installing a desktop to do
chkconfig --level 345 network off chckonfig --level 345 NetworkManager on
as the latter category of people is not really UNIX savy.
Doing a derived distro for the desktop would allow us to care more about the desktop without wasting time educating other stake holders in Fedora that we need this or that change for the desktop to work well.
Maybe the desktop needs a break from the rest of the distro. Just a thought.
David[1] : well, all the daily crob jobs like updatedb etc. plus much more would have to go :-)
[2] : maybe that glibc patch to reread /etc/resolv.conf so we don't have to run bind for NetworkManager in the default install :-)
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
hackmiester (Hunter Fuller) wrote:
On 15 August 2006, at 11:33, David Zeuthen wrote:
On Tue, 2006-08-15 at 07:50 +0200, David Nielsen wrote:
My point was that we don't yet do this by default which means the concerns still apply to any default case for Fedora.
Perhaps what the world needs is a derived Fedora Core distribution tailored for the desktop. Same packages [1], few patches [2], just different behaviour out of the box more suited for the desktop.
We already have a "Desktop" option in the installer. I propose that that option configure things differently, instead of just juggling packages differently.
No. We dont from FC5 onwards.
Rahul
On 15 August 2006, at 12:15, Bill Nottingham wrote:
No, you make sure the OS has the applications for your needs before installing it. It obviously should work on all your hardware as a matter of course. :)
All hardware is impossible to provide drivers for, as it evolves constantly. For example, it doesn't work on my MacBook stock. It doesn't like the video card. Or my ThinkPad R51's wireless.
Bill
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
hackmiester (Hunter Fuller) wrote:
On 15 August 2006, at 12:15, Bill Nottingham wrote:
No, you make sure the OS has the applications for your needs before installing it. It obviously should work on all your hardware as a matter of course. :)
All hardware is impossible to provide drivers for, as it evolves constantly. For example, it doesn't work on my MacBook stock. It doesn't like the video card. Or my ThinkPad R51's wireless.
I think that is well understood. The smiley indicated a tongue in cheek comment.
Rahul
On 15 August 2006, at 18:08, Rahul wrote:
hackmiester (Hunter Fuller) wrote:
We already have a "Desktop" option in the installer. I propose that that option configure things differently, instead of just juggling packages differently.
No. We dont from FC5 onwards.
ergh... sorry... but why not? It'd be perfect for this!...
Rahul
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
On 15 August 2006, at 18:14, Rahul wrote:
hackmiester (Hunter Fuller) wrote:
All hardware is impossible to provide drivers for, as it evolves constantly. For example, it doesn't work on my MacBook stock. It doesn't like the video card. Or my ThinkPad R51's wireless.
I think that is well understood. The smiley indicated a tongue in cheek comment.
Aah, thanks for clarifying :)
Rahul
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
hackmiester (Hunter Fuller) wrote:
On 15 August 2006, at 18:08, Rahul wrote:
hackmiester (Hunter Fuller) wrote:
We already have a "Desktop" option in the installer. I propose that that option configure things differently, instead of just juggling packages differently.
No. We dont from FC5 onwards.
ergh... sorry... but why not? It'd be perfect for this!...
We are moving into supporting Fedora Extras and any custom repository during installation and "desktop" as defined by the installer isnt what everyone has in mind. Now it is designed to be more task based
http://fedoraproject.org/wiki/Anaconda/PackageSelection
Rahul
On 18 August 2006, at 17:13, Rahul wrote:
hackmiester (Hunter Fuller) wrote:
On 15 August 2006, at 18:08, Rahul wrote:
hackmiester (Hunter Fuller) wrote:
We already have a "Desktop" option in the installer. I propose that that option configure things differently, instead of just juggling packages differently.
No. We dont from FC5 onwards.
ergh... sorry... but why not? It'd be perfect for this!...
We are moving into supporting Fedora Extras and any custom repository during installation and "desktop" as defined by the installer isnt what everyone has in mind. Now it is designed to be more task based
Well still, the installer should have some option for automatically setting things up a certain way. One page for package selection, another for configuration.
http://fedoraproject.org/wiki/Anaconda/PackageSelection
Rahul
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
hackmiester (Hunter Fuller) wrote:
Well still, the installer should have some option for automatically setting things up a certain way. One page for package selection, another for configuration.
Agreed. The installer already allows package selection. Configuration setup that depends on particular installation groups are a good thing but isnt necessary dependent on the user interface.
Rahul
desktop@lists.stg.fedoraproject.org
-
Andrew Ziem -
Bill Nottingham -
Dan Williams -
David Nielsen -
David Zeuthen -
hackmiester -
Rahul Sundaram