I just ftp'd the 5 disks, and put it on my system. Firstly, the installer sucks. Graphical only displays the top left corner of the screen, showing none of the useful information. I had to use text, which was completely garbled. Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages. I decided to use add/remove packages. This crashed pretty much immediately. I'm stuck with a pile of minimal non-working crud. FC4T2 was SOOOO much better. Hope to see you in final.
poly-p man
-- Registered linux user #386711 at http://counter.li.org -- There's no place like ~
Linux Counter (li.counter.org) #386711 wrote:
I just ftp'd the 5 disks, and put it on my system. Firstly, the installer sucks. Graphical only displays the top left corner of the screen, showing none of the useful information. I had to use text, which was completely garbled.
Nobody else has reported the problem so far. Which display card is this?. Can you provide more information of the system?
Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages.
Not this again. This is a feature not a bug :-)
Everything installations are generally a bad idea.
* Dependency issues - One of the reasons behind doing a everything installation is avoid dealing with dependency issues. However that is largely not a problem now since yum install and yum groupinstall along with along programs like pirut. Refer to the yum guide available at http://fedora.redhat.com/docs
* Discoverability - Fedora Core like you indicate a large number of useful programs but the installer divides these into several different types to target particular segment of use cases and avoid having to a everything installation. Custom group and package selection is available for those who would like to do a granular installation. Even if all the packages of Fedora Core is installed it doesnt grant users immediate access to all the packages since the ones in Fedora Extras repository is not available at installation time. Though the installer itself is getting support for additional repositories the aspect of making these packages more visible to users is better handled through the use of tools such as pirut rather than having users install everything which they cant now anyway since the installation is limited to Fedora Core packages.
* Redundancy - While Fedora Core itself is slowing moving towards providing more packages as part of the Fedora Extras and possibly doing several different targets the current selection uses multiple programs that provide the same functionality, browsers or desktop environments for example and its better for users to use a graphical tool like pirut and install packages as necessary.
* Security, manageability and performance - As more and more packages are installed on a system the amount of updates and interactions between the packages that the user has to handle drastically increases. For users who are using Fedora as a development system or using it just to learn Linux where the system serves no other purpose and a high amount of bandwidth is available this might make sense but for others users who use it deploy it at various levels the amount of updates and potential security issues that they have to deal with packages that they might not even use is a additional burden. Moreover the additional packages installed might need listen to network connections by default making the systems potentially more vulnerable by increasing the attack vector. Additional services enabled by default also affect performance.
I decided to use add/remove packages. This crashed pretty much immediately.
What packages did you try to add or remove?. Did you get a traceback?. See if its already reported or file a bug report in http://bugzilla.redhat.com against pirut.
I'm stuck with a pile of minimal non-working crud.
Yum and yum groupinstall can help you install rest of the packages required even if pirut is not working.
Rahul Sundaram wrote:
Linux Counter (li.counter.org) #386711 wrote:
snip
Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages.
Not this again. This is a feature not a bug :-)
Why do you think it keeps coming up? It's a lack of a feature =;0 seriously, different people have different goals when they install and run FC, who are you to say that there should not be at least a *choice/option*.
Everything installations are generally a bad idea.
Generally but not always! In my case, one of the things I'm doing is looking for things that don't have SELinux policy that need it.
- Dependency issues -
snip need to be found
- Discoverability -
snip Pirut needs an "everything" option as well. The list and search features will be good when they work.
- Redundancy - While Fedora Core itself is slowing moving towards
providing more packages as part of the Fedora Extras and possibly doing several different targets the current selection uses multiple programs that provide the same functionality, browsers or desktop environments for example and its better for users to use a graphical tool like pirut and install packages as necessary.
For those of us that run 'rawhide' redundancy is good and it saves time to have "more than one way to skin a cat" already installed. Don't you want "everything" tested?
- Security, manageability and performance - As more and more packages
are installed on a system the amount of updates and interactions between the packages that the user has to handle drastically increases. For users who are using Fedora as a development system or using it just to learn Linux where the system serves no other purpose and a high amount of bandwidth is available this might make sense
You just gave another reason to have a 'everything' option. Plus don't you want to make it easier for people to test everything? I'll bet there are things in FC that no one uses and never gets tested. BTW, what are you doing to get the number of CDs back down to 4?
but for others
users who use it deploy it at various levels the amount of updates and potential security issues that they have to deal with packages that they might not even use is a additional burden. Moreover the additional packages installed might need listen to network connections by default making the systems potentially more vulnerable by increasing the attack vector. Additional services enabled by default also affect performance.
That has nothing to do with whether or not there is a 'everything' option.
snip
Richard
Hi
Why do you think it keeps coming up?
You are the first for this release.
Everything installations are generally a bad idea.
Generally but not always! In my case, one of the things I'm doing is looking for things that don't have SELinux policy that need it.
What do you mean by that?
- Redundancy - While Fedora Core itself is slowing moving towards
providing more packages as part of the Fedora Extras and possibly doing several different targets the current selection uses multiple programs that provide the same functionality, browsers or desktop environments for example and its better for users to use a graphical tool like pirut and install packages as necessary.
For those of us that run 'rawhide' redundancy is good and it saves time to have "more than one way to skin a cat" already installed. Don't you want "everything" tested?
Use yum to install the rest.
- Security, manageability and performance - As more and more
packages are installed on a system the amount of updates and interactions between the packages that the user has to handle drastically increases. For users who are using Fedora as a development system or using it just to learn Linux where the system serves no other purpose and a high amount of bandwidth is available this might make sense
You just gave another reason to have a 'everything' option. Plus don't you want to make it easier for people to test everything? I'll bet there are things in FC that no one uses and never gets tested.
Use yum.
BTW, what are you doing to get the number of CDs back down to 4?
Not a agreed upon goal AFAIK.
but for others
users who use it deploy it at various levels the amount of updates and potential security issues that they have to deal with packages that they might not even use is a additional burden. Moreover the additional packages installed might need listen to network connections by default making the systems potentially more vulnerable by increasing the attack vector. Additional services enabled by default also affect performance.
That has nothing to do with whether or not there is a 'everything' option.
It does. Everything opens up more services.
Rahul Sundaram wrote:
Hi
Why do you think it keeps coming up?
You are the first for this release.
This is the first release that doesn't have it. ;)
Everything installations are generally a bad idea.
Generally but not always! In my case, one of the things I'm doing is looking for things that don't have SELinux policy that need it.
What do you mean by that?
I've been using the 'strict' policy since the 'Targeted/Strict' split and looking for things to run that will produce avc denied messages.
- Redundancy - While Fedora Core itself is slowing moving towards
providing more packages as part of the Fedora Extras and possibly doing several different targets the current selection uses multiple programs that provide the same functionality, browsers or desktop environments for example and its better for users to use a graphical tool like pirut and install packages as necessary.
For those of us that run 'rawhide' redundancy is good and it saves time to have "more than one way to skin a cat" already installed. Don't you want "everything" tested?
Use yum to install the rest.
'yum install available' doesn't work! try it =;)
- Security, manageability and performance - As more and more
packages are installed on a system the amount of updates and interactions between the packages that the user has to handle drastically increases. For users who are using Fedora as a development system or using it just to learn Linux where the system serves no other purpose and a high amount of bandwidth is available this might make sense
You just gave another reason to have a 'everything' option. Plus don't you want to make it easier for people to test everything? I'll bet there are things in FC that no one uses and never gets tested.
Use yum.
see above
BTW, what are you doing to get the number of CDs back down to 4?
Not a agreed upon goal AFAIK.
Just another indication of bloat or the need to move more things to Extras.
but for others
users who use it deploy it at various levels the amount of updates and potential security issues that they have to deal with packages that they might not even use is a additional burden. Moreover the additional packages installed might need listen to network connections by default making the systems potentially more vulnerable by increasing the attack vector. Additional services enabled by default also affect performance.
That has nothing to do with whether or not there is a 'everything' option.
It does. Everything opens up more services.
That for a long time produced bunches of avc denied messages.
thanks for all the good work-- It's looking good.
Richard
HI
What do you mean by that?
I've been using the 'strict' policy since the 'Targeted/Strict' split and looking for things to run that will produce avc denied messages.
Why does that require a everything installation?
Use yum to install the rest.
'yum install available' doesn't work! try it =;)
Works fine here. If it doesnt work for you, file a bug report
Use yum.
see above
Works for me.
BTW, what are you doing to get the number of CDs back down to 4?
Not a agreed upon goal AFAIK.
Just another indication of bloat or the need to move more things to Extras.
Define bloat. What is bloat for you is crucial for others.
On Fri, 20 Jan 2006, Rahul Sundaram wrote:
BTW, what are you doing to get the number of CDs back down to 4?
Not a agreed upon goal AFAIK.
Just another indication of bloat or the need to move more things to Extras.
Define bloat. What is bloat for you is crucial for others.
They can get their "crucial" stuff from Extras...
There's nothing magic about 4 CDs - it's just a reality check that says "hey, we are growing with no end in sight". It's not the size that's the problem - it's the endless growth.
Best, -- Elliot
Hi
Define bloat. What is bloat for you is crucial for others.
They can get their "crucial" stuff from Extras...
Not for regions where bandwidth cost a lot more.
There's nothing magic about 4 CDs - it's just a reality check that says "hey, we are growing with no end in sight". It's not the size that's the problem - it's the endless growth.
If we are fighting endless growth, we should be defining what core really means and then trim core to meet this goal which would result in a single CD or just build different targets like server or desktop. The current method of packages showing up and disappearing in core without an obvious reason behind them is not really sustainable.
On Fri, 2006-01-20 at 09:47 +0530, Rahul Sundaram wrote:
They can get their "crucial" stuff from Extras...
Not for regions where bandwidth cost a lot more.
When we get the ability to use Extras CDs during install, then we can ship these CDs with Core CDs. Then you dont have to install over costly lines, and it doesn't matter where your package comes from.
Jesse Keating wrote:
On Fri, 2006-01-20 at 09:47 +0530, Rahul Sundaram wrote:
They can get their "crucial" stuff from Extras...
Not for regions where bandwidth cost a lot more.
When we get the ability to use Extras CDs during install, then we can ship these CDs with Core CDs. Then you dont have to install over costly lines, and it doesn't matter where your package comes from.
Why not ship the Extras CD's now in FC5 and modify pirut to install packages from the CD/DVD's as necessary?
On Fri, 2006-01-20 at 09:59 +0530, Rahul Sundaram wrote:
Why not ship the Extras CD's now in FC5 and modify pirut to install packages from the CD/DVD's as necessary?
Why not indeed. Time to get pirut into that shape? Decent ideas of groupings of Extras packages?
When they can be used DURING the install, thats when I think it'll be key to ship them.
Jesse Keating wrote:
On Fri, 2006-01-20 at 09:59 +0530, Rahul Sundaram wrote:
Why not ship the Extras CD's now in FC5 and modify pirut to install packages from the CD/DVD's as necessary?
Why not indeed. Time to get pirut into that shape? Decent ideas of groupings of Extras packages?
Wasn't someone already working on this. http://fedoraproject.org/wiki/Extras/Schedule/ExtrasCompsXml
When they can be used DURING the install, thats when I think it'll be key to ship them.
Just able to handle them well post installation too is very much acceptable for fresh installations. If we get pirut into shape and figure out how to do a well defined extras repository release with yum groups we are done.
On Fri, 2006-01-20 at 09:47 +0530, Rahul Sundaram wrote:
There's nothing magic about 4 CDs - it's just a reality check that says "hey, we are growing with no end in sight". It's not the size that's the problem - it's the endless growth.
If we are fighting endless growth, we should be defining what core really means and then trim core to meet this goal which would result in a single CD
This is just picking a different arbitrary and extremely ephemeral size limitation. So now I'll have a go at it, just to demonstrate how banal this whole line of reasoning is:
To use our desktop without much pain, you realistically need a lot of ram, a pretty good video card, and a relatively fast CPU. Any computer with all of these can surely include a DVD drive.
Or, we could use the same logic, phrased in a more familiar historical way: 640 Kilobytes of computer memory ought to be enough for anybody.
In case my point isn't painfully clear yet, arbitrarily picking the number 1 doesn't address the growth problem any more than arbitrarily picking the number 4 does. Any hope of addressing this issue is not going to involve picking a size of some unit of storage that happens to be temporally convenient this week.
By picking silly numbers, we're focusing on how we'll know if we've done the right thing. We don't need to focus on that. If we get it right, there won't be a problem any more.
Peter Jones wrote:
On Fri, 2006-01-20 at 09:47 +0530, Rahul Sundaram wrote:
There's nothing magic about 4 CDs - it's just a reality check that says "hey, we are growing with no end in sight". It's not the size that's the problem - it's the endless growth.
If we are fighting endless growth, we should be defining what core really means and then trim core to meet this goal which would result in a single CD
This is just picking a different arbitrary and extremely ephemeral size limitation. So now I'll have a go at it, just to demonstrate how banal this whole line of reasoning is:
To use our desktop without much pain, you realistically need a lot of ram, a pretty good video card, and a relatively fast CPU. Any computer with all of these can surely include a DVD drive.
They could but it is additional cost to bear. DVD drives especially when introduced into a new market is much more costlier than a CD drive. You will have to take into consideration that Fedora is being redistributed all over the world including developing countries with extremely limited budgets. I have been involved with non-profit associations, educational institutions etc where a DVD drive cost can easily exceed a quarterly budget. If we are excluding these people we are limiting our audience drastically. One of the other things that needs to happen is a low resource economy edition of Fedora. That is something I am planning out already.
On Sat, 2006-01-21 at 09:13 +0530, Rahul Sundaram wrote:
Peter Jones wrote:
This is just picking a different arbitrary and extremely ephemeral size limitation. So now I'll have a go at it, just to demonstrate how banal this whole line of reasoning is:
To use our desktop without much pain, you realistically need a lot of ram, a pretty good video card, and a relatively fast CPU. Any computer with all of these can surely include a DVD drive.
They could but it is additional cost to bear. DVD drives especially when introduced into a new market is much more costlier than a CD drive.
[lots more stuff along the same lines skipped]
Gee, thanks, you've totally destroyed my strawman argument.
Go back and read the rest of the post, maybe?
Hi
They could but it is additional cost to bear. DVD drives especially when introduced into a new market is much more costlier than a CD drive.
[lots more stuff along the same lines skipped]
Gee, thanks, you've totally destroyed my strawman argument.
Maybe.
Go back and read the rest of the post, maybe?
I dont see what I missed that destroys the argument really.
On 1/20/06, Rahul Sundaram sundaram@redhat.com wrote:
If we are fighting endless growth, we should be defining what core really means and then trim core to meet this goal which would result in a single CD or just build different targets like server or desktop. The current method of packages showing up and disappearing in core without an obvious reason behind them is not really sustainable.
Regarding the number of CDs Fedora has, I think it would be good if:
- There was an official Fedora site you could go to where you would get a clone of the package selection screen and you could submit what packages you would want to install. It would then tell you which of the 5 CDs you need to download. In addition, could it also give you the option of downloading a kickstart file that has these preset? I haven't used kickstart so I don't know if that would be possible. A webpage like this would also be able to collect useful statistics on which packages are best to group on what CDs so as to keep the average number of CDs needed to a minimum.
- It would also be really cool if you could click a button on the package selection screen during installation, and say 'I only have Fedora CDs 1 and 2'. It would then grey-out any packages that would otherwise require you to have more CDs.
n0dalus.
On 1/20/06, n0dalus n0dalus+redhat@gmail.com wrote:
Regarding the number of CDs Fedora has, I think it would be good if:
- There was an official Fedora site you could go to where you would
get a clone of the package selection screen and you could submit what packages you would want to install. It would then tell you which of the 5 CDs you need to download. In addition, could it also give you the option of downloading a kickstart file that has these preset? I haven't used kickstart so I don't know if that would be possible. A webpage like this would also be able to collect useful statistics on which packages are best to group on what CDs so as to keep the average number of CDs needed to a minimum.
- It would also be really cool if you could click a button on the
package selection screen during installation, and say 'I only have Fedora CDs 1 and 2'. It would then grey-out any packages that would otherwise require you to have more CDs.
I forgot to mention; for the second point, you should be able to say any combination of CDs (as long as it includes the first).
n0dalus.
n0dalus wrote:
On 1/20/06, n0dalus n0dalus+redhat@gmail.com wrote:
Regarding the number of CDs Fedora has, I think it would be good if:
- There was an official Fedora site you could go to where you would
get a clone of the package selection screen and you could submit what packages you would want to install. It would then tell you which of the 5 CDs you need to download. In addition, could it also give you the option of downloading a kickstart file that has these preset? I haven't used kickstart so I don't know if that would be possible. A webpage like this would also be able to collect useful statistics on which packages are best to group on what CDs so as to keep the average number of CDs needed to a minimum.
- It would also be really cool if you could click a button on the
package selection screen during installation, and say 'I only have Fedora CDs 1 and 2'. It would then grey-out any packages that would otherwise require you to have more CDs.
I forgot to mention; for the second point, you should be able to say any combination of CDs (as long as it includes the first).
n0dalus.
Want to work on such a system?
On 1/21/06, Rahul Sundaram sundaram@redhat.com wrote:
Want to work on such a system?
Sure, I'd give it a shot. (The web interface)
Does anyone know how to generate a list of dependancies for each rpm? I would want to make a dependency tree and store it in an sqlite db or something. Other than that it should just be a matter of working out how the comps.xml files are formatted and stuff.
n0dalus.
n0dalus wrote:
On 1/21/06, Rahul Sundaram sundaram@redhat.com wrote:
Want to work on such a system?
Sure, I'd give it a shot. (The web interface)
Does anyone know how to generate a list of dependancies for each rpm?
repoquery
I would want to make a dependency tree and store it in an sqlite db or something.
Thats what yum does.
Other than that it should just be a matter of working out how the comps.xml files are formatted and stuff.
Work with yum and yum-utils developers.
On 1/21/06, Rahul Sundaram sundaram@redhat.com wrote:
n0dalus wrote:
I would want to make a dependency tree and store it in an sqlite db or something.
Thats what yum does.
Other than that it should just be a matter of working out how the comps.xml files are formatted and stuff.
Work with yum and yum-utils developers.
Maybe I should leave the website to someone that knows Python then?
n0dalus.
- It would also be really cool if you could click a button on the
package selection screen during installation, and say 'I only have Fedora CDs 1 and 2'. It would then grey-out any packages that would otherwise require you to have more CDs.
an alternative to this would be to have like only 1 or 2 "core" cds, and all others be "themed" cds. Like a "OpenOffice.org" themed CD. A "KDE" themed cd, or a "desktop" one if gnome and kde fit on the same cd. Maybe a "Advanced Development tools" cd. That way you have a logical result when you don't have a certain CD, and you know why you're not downloading that specific CD (or why you ARE downloading that one).
On Sat, 2006-01-21 at 10:52 +0100, Arjan van de Ven wrote:
- It would also be really cool if you could click a button on the
package selection screen during installation, and say 'I only have Fedora CDs 1 and 2'. It would then grey-out any packages that would otherwise require you to have more CDs.
an alternative to this would be to have like only 1 or 2 "core" cds, and all others be "themed" cds. Like a "OpenOffice.org" themed CD. A "KDE" themed cd, or a "desktop" one if gnome and kde fit on the same cd. Maybe a "Advanced Development tools" cd.
What about common dependencies between them, put them on every CD or make a separate "dependencies" CD (which people will certainly forget to download)?
Nils
Hi,
Rahul Sundaram wrote:
HI
What do you mean by that?
I've been using the 'strict' policy since the 'Targeted/Strict' split and looking for things to run that will produce avc denied messages.
Why does that require a everything installation?
Saves a lot of time!
Use yum to install the rest.
'yum install available' doesn't work! try it =;)
Works fine here. If it doesnt work for you, file a bug report
BS -- "No match for argument: available", ya ya file an RFE and get the same argument -- not.
Use yum.
see above
Works for me.
B*ll S***, "yum list available" works fine, "yum install available" doesn't!
BTW, what are you doing to get the number of CDs back down to 4?
Not a agreed upon goal AFAIK.
Just another indication of bloat or the need to move more things to Extras.
Define bloat. What is bloat for you is crucial for others.
Then why not put everything that is in extras in the core? oh, wait nothing in extras is crucial. ;)
HTH Richard
Hi
Works fine here. If it doesnt work for you, file a bug report
BS -- "No match for argument: available", ya ya file an RFE and get the same argument -- not.
Kindly avoid swearing. If you see the man page of yum you will find that such a feature does not exist. You can use yum install * instead.
Define bloat. What is bloat for you is crucial for others.
Then why not put everything that is in extras in the core? oh, wait nothing in extras is crucial. ;)
See my other mail on the topic.
Hi,
Rahul Sundaram wrote:
Hi
Works fine here. If it doesnt work for you, file a bug report
BS -- "No match for argument: available", ya ya file an RFE and get the same argument -- not.
Kindly avoid swearing.
OK If you see the man page of yum you will find that
such a feature does not exist.
that's why I was surprised that you said that it worked for you.
You can use yum install * instead. thanks for the tip.
Define bloat. What is bloat for you is crucial for others.
Then why not put everything that is in extras in the core? oh, wait nothing in extras is crucial. ;)
See my other mail on the topic.
I agree that a better definition for what goes in Core is needed.
Richard
On 1/19/06, Richard Hally rhally@mindspring.com wrote:
Hi,
Rahul Sundaram wrote:
Hi
Works fine here. If it doesnt work for you, file a bug report
BS -- "No match for argument: available", ya ya file an RFE and get the same argument -- not.
Kindly avoid swearing.
OK If you see the man page of yum you will find that
such a feature does not exist.
that's why I was surprised that you said that it worked for you.
You can use yum install * instead. thanks for the tip.
Define bloat. What is bloat for you is crucial for others.
Then why not put everything that is in extras in the core? oh, wait nothing in extras is crucial. ;)
See my other mail on the topic.
I agree that a better definition for what goes in Core is needed.
Richard
What I find funny in all of this, is people are complaining about "everything" option and in the same e-mail talking about "to much bloat" seems a tad odd.
On 1/20/06, Justin Conover justin.conover@gmail.com wrote:
What I find funny in all of this, is people are complaining about "everything" option and in the same e-mail talking about "to much bloat" seems a tad odd.
its perfectly consistent... if the long term goal is to strip all choice from the packaging selection and make anaconda only allow a "default" install which is also an "everything" install.
-jef
On Fri, 20 Jan 2006, Jeff Spaleta wrote:
On 1/20/06, Justin Conover justin.conover@gmail.com wrote:
What I find funny in all of this, is people are complaining about "everything" option and in the same e-mail talking about "to much bloat" seems a tad odd.
its perfectly consistent... if the long term goal is to strip all choice from the packaging selection and make anaconda only allow a "default" install which is also an "everything" install.
even if most people don't like the idea of an "everything" install, i'd like to think that sort of thing is part of pre-release Q/A to detect package incompatibilities before the release goes out the door, no?
rday
Hi
even if most people don't like the idea of an "everything" install, i'd like to think that sort of thing is part of pre-release Q/A to detect package incompatibilities before the release goes out the door, no?
rday
We have processes in place to do this. Kickstart can do this for the end users too. Just use that.
On 1/20/06, Rahul Sundaram sundaram@redhat.com wrote:
We have processes in place to do this. Kickstart can do this for the end users too. Just use that.
what would be super especially fantabulous is a reasonable useful webinterface by which people can "pre-order" kickstart files to use before they have an existing fedora install. Right now kickstart is really oriented to replicated install situations where its quite reasonable to expect people to have a testbed system locally which sees a normal fedora install and post-install customization from which a kickstart file is generated in preparation to rollup multiple copies of that configuration.
For people who want to one-off an install and short-circuit the normal installer blabbity-blah, they need to get a kickstart file from somewhere. We can either have community comtribute some starting point kickstart files to the wiki, or a clever person could go the extra mile and cook up an web interface that generates kickstart files via some Q/A for package selection and post-install configuration.
-jef"its a sad day... my 3com audrey won't reboot"spaleta
-jef
Jeff Spaleta wrote:
On 1/20/06, Rahul Sundaram sundaram@redhat.com wrote:
We have processes in place to do this. Kickstart can do this for the end users too. Just use that.
what would be super especially fantabulous is a reasonable useful webinterface by which people can "pre-order" kickstart files to use before they have an existing fedora install.
I have already been thinking of something along this lines. Its however in my every growing TODO list with other items bubbling up to the top. If anyone is interested in this let me know and I will see what can be done.
On Friday 20 January 2006 14:52, Justin Conover wrote:
On 1/19/06, Richard Hally rhally@mindspring.com wrote:
What I find funny in all of this, is people are complaining about "everything" option and in the same e-mail talking about "to much bloat" seems a tad odd.
For most users I agree that the everything install causes more problems than it's worth. But in my case and several others it's very useful.
We have to install Fedora onto several hundred machines twice a year for our student labs. Now what we normally do is "An Everything Install". Then we download a script from a server and run it on each machine. This script installs any extra rpms we need, like java, configures the machines to our requirements and disables any unwanted services etc. Fairly simple.
Now without "An Everything Install" we install the default packages. This will not install many packages from the base repository, for instance the openoffice language packs or the xorg fonts. We need these because some of our students will want to use their native language for some purposes. Also some lecturer will always require some package that's not in the default install but that he has on his machine. And in general they won't tell you about this untill after the semester has started ;-(
Now we could do a "yum install --exclude*debug* *" after the initial install to get the remaining packages, but that requires several Gb of space on the /var/cache partition which is a waste.
So please please give us back the "Everything Install" even if it's well hidden in the installer :-)
Tony
On Fri, 2006-01-20 at 15:54 +0000, Tony Molloy wrote:
We have to install Fedora onto several hundred machines twice a year for our student labs. Now what we normally do is "An Everything Install". Then we download a script from a server and run it on each machine. This script installs any extra rpms we need, like java, configures the machines to our requirements and disables any unwanted services etc. Fairly simple.
Now without "An Everything Install" we install the default packages. This will not install many packages from the base repository, for instance the openoffice language packs or the xorg fonts. We need these because some of our students will want to use their native language for some purposes. Also some lecturer will always require some package that's not in the default install but that he has on his machine. And in general they won't tell you about this untill after the semester has started ;-(
This problem is easily solved by writing a kickstart script with your required package set. Is it really that hard to identify what you need?
If you're complaining about /var/cache space, what do you think will happen over time with all the updates for all those unnecessary packages you've installed with everything?
Jesse Keating wrote:
On Fri, 2006-01-20 at 15:54 +0000, Tony Molloy wrote:
We have to install Fedora onto several hundred machines twice a year for our student labs. Now what we normally do is "An Everything Install". Then we download a script from a server and run it on each machine. This script installs any extra rpms we need, like java, configures the machines to our requirements and disables any unwanted services etc. Fairly simple.
Now without "An Everything Install" we install the default packages. This will not install many packages from the base repository, for instance the openoffice language packs or the xorg fonts. We need these because some of our students will want to use their native language for some purposes. Also some lecturer will always require some package that's not in the default install but that he has on his machine. And in general they won't tell you about this untill after the semester has started ;-(
This problem is easily solved by writing a kickstart script with your required package set. Is it really that hard to identify what you need?
"everything" as a constant name, whereas it takes quite some effort for user administrators to discover what the choices are, and those xml files aren't that easy to read.
If you're complaining about /var/cache space, what do you think will happen over time with all the updates for all those unnecessary packages you've installed with everything?
Aren't those easily cleaned after installation?
Jesse Keating wrote:
On Fri, 2006-01-20 at 15:54 +0000, Tony Molloy wrote:
We have to install Fedora onto several hundred machines twice a year for our student labs. Now what we normally do is "An Everything Install". Then we download a script from a server and run it on each machine. This script installs any extra rpms we need, like java, configures the machines to our requirements and disables any unwanted services etc. Fairly simple.
Now without "An Everything Install" we install the default packages. This will not install many packages from the base repository, for instance the openoffice language packs or the xorg fonts. We need these because some of our students will want to use their native language for some purposes. Also some lecturer will always require some package that's not in the default install but that he has on his machine. And in general they won't tell you about this untill after the semester has started ;-(
This problem is easily solved by writing a kickstart script with your required package set. Is it really that hard to identify what you need?
Kickstart is not installed on systems by default, no?
If you're complaining about /var/cache space, what do you think will happen over time with all the updates for all those unnecessary packages you've installed with everything?
I'll try kickstart later, I considered it one of those not needed packages in the past.
Jim
Tony Molloy tony.molloy@ul.ie wrote:
On Friday 20 January 2006 14:52, Justin Conover wrote:
On 1/19/06, Richard Hally rhally@mindspring.com wrote:
What I find funny in all of this, is people are complaining about "everything" option and in the same e-mail talking about "to much bloat" seems a tad odd.
For most users I agree that the everything install causes more problems than it's worth. But in my case and several others it's very useful.
We have to install Fedora onto several hundred machines twice a year for our student labs. Now what we normally do is "An Everything Install". Then we download a script from a server and run it on each machine. This script installs any extra rpms we need, like java, configures the machines to our requirements and disables any unwanted services etc. Fairly simple.
Use kickstart, that way you can even tweak configurations and pull in local packages during/after install.
And a student lab machine running everything under the sun isn't too wise anyway: more software ==> more places into which they can apply the prying iron...
On Fri, 2006-01-20 at 15:54 +0000, Tony Molloy wrote:
Now we could do a "yum install --exclude*debug* *" after the initial install to get the remaining packages, but that requires several Gb of space on the /var/cache partition which is a waste.
You can work around that by putting the packages on a local NFS server, use a file:///... baseurl for the base repo and the packages won't get copied to /var/cache. You'd be putting the yum line in a script anyway, so this is only an added 2 or 3 lines.
Nils
On 1/20/06, Keith Sharp kms@passback.co.uk wrote:
On Fri, 2006-01-20 at 10:05 +0530, Rahul Sundaram wrote:
If you see the man page of yum you will find that such a feature does not exist. You can use yum install * instead.
Does this automatically install the debuginfo RPMs as well?
Keith.
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Yes, but you could run
yum --exclude=*\debug* install *
to exclude the debug packages.
On Fri, 2006-01-20 at 08:55 +0000, Keith Sharp wrote:
On Fri, 2006-01-20 at 10:05 +0530, Rahul Sundaram wrote:
If you see the man page of yum you will find that such a feature does not exist. You can use yum install * instead.
Does this automatically install the debuginfo RPMs as well?
It includes all the packages that are in the repos that yum is currently configured to use. That may or may not include debuginfo packages, depending on the repos.
FWIW, you can also use this globbing in the %packages section of your kickstart config file, as of Friday or so, I think. (I'm not sure if Paul and Chris finished this on Friday, but I think they did.)
FWIW, you can also use this globbing in the %packages section of your kickstart config file, as of Friday or so, I think. (I'm not sure if Paul and Chris finished this on Friday, but I think they did.)
There's a yum patch that needs to make it upstream before this can be supported. There was basically no work required in anaconda. Just waiting on that patch to be discussed, etc.
- Chris
On Thu, 2006-01-19 at 23:02 -0500, Richard Hally wrote:
You are the first for this release.
This is the first release that doesn't have it. ;)
What happens next release when Extras is available in the installer. Or any other repo? Sure you want EVERYTHING installed?
Jesse Keating wrote:
On Thu, 2006-01-19 at 23:02 -0500, Richard Hally wrote:
You are the first for this release.
This is the first release that doesn't have it. ;)
What happens next release when Extras is available in the installer. Or any other repo? Sure you want EVERYTHING installed?
I would expect that I would be able to choose which repo or repos I wanted to use. I have never used extras.
Richard
On Thu, 2006-01-19 at 20:22 -0800, Jesse Keating wrote:
On Thu, 2006-01-19 at 23:02 -0500, Richard Hally wrote:
You are the first for this release.
This is the first release that doesn't have it. ;)
What happens next release when Extras is available in the installer. Or any other repo? Sure you want EVERYTHING installed?
With yum, I'm not quite sure an Everything install is really needed anymore, but I should surely be able to select faster what I want to be installed -- choosing each category, then going into details and selecting all the optional packages as well doesn't quite cut it.
Now that I think about it, one thing I actually liked about the MS Windows (98) installer was how I could just check a complete group of software which would give me the whole stuff with all optional things.
Nils
Rahul Sundaram wrote:
Hi
Why do you think it keeps coming up?
You are the first for this release.
Third today by my count, but I've not been watching closely.
John Summerfied writes:
Rahul Sundaram wrote:
You are the first for this release.
Third today by my count, but I've not been watching closely.
I think its more than that. I'll add my own "me too" to that. I've refrained until now, although I almost responded to Rahul's message when I fist saw it
I used to be selective about package installation, but on a recent machine I just selected everything. The main reason is because I run a collection of machines for a couple of dozen researchers at Stanford that do widely different tasks. I used to give them "sudo" access and tell them the basics of "yum" but they couldn't always guess the package names and were frustrated because they would need to install packages on all the machines (although I do provide a script for that.)
I talked to a friend who admins a SUSE cluster that just moved to CentOS about what he installs for his people and he does the everything equivalent for similar reasons.
I do have to be a little more on top of [SECURITY] announcements (although running on PowerPC its not a serious issue most of the time since I don't know of anyone making linux/ppc specific exploits :)) but I've also turned on nightly automatic yum updates to minimize being out of date on something critical if I happen to be away.
However, if its not a choice in the installer, its not a big deal for me anyway. I'll just add the equivalent yum liner to my new machine installation instructions. It might actualyl be better since I found that with the "everything" option I have a long post installation "yum update" since after a release is out a while most packages seem to be updated, especially the big ones like openoffice. If anything, that is an argument for me to have a minimal single CD installation that gets the rest of the files from online. Stanford runs a mirror that I can use so its not really a performance issue.
-bri
Brian D. Carlstrom wrote:
John Summerfied writes:
Rahul Sundaram wrote:
You are the first for this release.
Third today by my count, but I've not been watching closely.
I think its more than that. I'll add my own "me too" to that. I've refrained until now, although I almost responded to Rahul's message when I fist saw it
Again. Just use kickstart.
Rahul Sundaram writes:
I think its more than that. I'll add my own "me too" to that. I've refrained until now, although I almost responded to Rahul's message when I fist saw it
Again. Just use kickstart.
I have a friend that uses kickstart to make sure his groups CVS server can be rebuilt quickly in an emergency. I don't want to go through the learning curve that he did when I only get a couple new workstations a year. I'm not a sysadmin by trade, I'm trying to do research. If fact, I'm not the one installing the machines, I make people follow my instructions off the web site, I'll just have to be updating those for FC5 if we move to it.
In any case, I'm happy to use "yum" postinstall to get what I want, I just wanted to say that I did use the "everything".
I'm much more suprised that "minimal" might be going away, since that does seem to be a much more "targeted" install to want to have.
-bri
Hi
I have a friend that uses kickstart to make sure his groups CVS server can be rebuilt quickly in an emergency. I don't want to go through the learning curve that he did when I only get a couple new workstations a year. I'm not a sysadmin by trade, I'm trying to do research. If fact, I'm not the one installing the machines, I make people follow my instructions off the web site, I'll just have to be updating those for FC5 if we move to it.
Thats fine and you can ask the people involved to list potential areas of improvement in reducing the learning curve and we can look into it. One of the things thats being done is better documentation and by the way if you can provide details of the deployment do mail me off list.
In any case, I'm happy to use "yum" postinstall to get what I want, I just wanted to say that I did use the "everything".
I'm much more suprised that "minimal" might be going away, since that does seem to be a much more "targeted" install to want to have.
True. I dont think it should go away either.
Rahul Sundaram wrote:
Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages.
Not this again. This is a feature not a bug :-)
Everything installations are generally a bad idea.
- Dependency issues - One of the reasons behind doing a everything
installation is avoid dealing with dependency issues. However that is largely not a problem now since yum install and yum groupinstall along with along programs like pirut. Refer to the yum guide available at http://fedora.redhat.com/docs
If I were to do an "everything" install, it might be a. To evaluate all the software b. To create an evironment where I can rebuild everything.
I think both wishes worth supporting. I think the view expressed by "CodeHeads" that 'my way is the only way" is plain wrong.
<snip>
- Redundancy - While Fedora Core itself is slowing moving towards
providing more packages as part of the Fedora Extras and possibly doing several different targets the current selection uses multiple programs that provide the same functionality, browsers or desktop environments for example and its better for users to use a graphical tool like pirut and install packages as necessary.
I find having to dig out CDs later a pain. I'd rather have everything there from the start, especially if I didn't know what I wanted.
- Security, manageability and performance - As more and more packages
are installed on a system the amount of updates and interactions between the packages that the user has to handle drastically increases. For users who are using Fedora as a development system or using it just to learn Linux where the system serves no other purpose and a high amount of bandwidth is available this might make sense but for others users who use it deploy it at various levels the amount of updates and potential security issues that they have to deal with packages that they might not even use is a additional burden. Moreover the additional packages installed might need listen to network connections by default making the systems potentially more vulnerable by increasing the attack vector. Additional services enabled by default also affect performance.
I didn't think OP said anything about having services needlessly enabled.
There are times when having everything installed is a good and proper thing to do, and that should be the local administator's choice, not the vendor's.
On Sun, 2006-01-22 at 09:40 +0800, John Summerfied wrote:
I think both wishes worth supporting. I think the view expressed by "CodeHeads" that 'my way is the only way" is plain wrong.
I never said "my way is the only way" Where did you get that????
On 1/19/06, Rahul Sundaram sundaram@redhat.com wrote:
I would just like to add my voice to the "I miss the install everything" crowd. I use it. I value it. It works for me in my scenario. None of your "its bad because..." reasons (which are valid in many situations, btw) apply to me. I would like it back.
Everything installations are generally a bad idea.
Generally, but by no means always a bad idea.
Perhaps we should get the "yum install *" option removed from yum then, and removed from kickstart too? I'm joking, of course, but I hope that you can see that by providing workarounds you are validating our viewpoint.
gb spam wrote:
On 1/19/06, Rahul Sundaram sundaram@redhat.com wrote:
I would just like to add my voice to the "I miss the install everything" crowd. I use it. I value it. It works for me in my scenario. None of your "its bad because..." reasons (which are valid in many situations, btw) apply to me. I would like it back.
Everything installations are generally a bad idea.
Generally, but by no means always a bad idea.
Perhaps we should get the "yum install *" option removed from yum then, and removed from kickstart too? I'm joking, of course, but I hope that you can see that by providing workarounds you are validating our viewpoint.
I dont consider a yum install * a valid workaround since I dont see a problem at all . The tool provides the capability and I have never used it because I think its pretty much useless to install everything available in the repositories but its available and I wanted to point out that. Its humanly impossible to test all the software manually. Some of that work is being done using automated test cases in the build system. Users should install software that they use and can test manually for the test/devel releases which is limited. If you must use a everything installation on unusual occasions then kickstart is powerful enough to manage that and tons more. If you can work on making kickstart profile generation in a web interface and similar things easier apart from the system-config-kickstart GUI tool I would welcome that. Work is already being done to document kickstart capabilities better in the installation guide.
On 1/22/06, Rahul Sundaram sundaram@redhat.com wrote:
I think its pretty much useless to install everything
and this is where you (and presumably serveral others like you) disagree with me and several others like me. That does not make us wrong. We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
gb spam wrote:
On 1/22/06, Rahul Sundaram sundaram@redhat.com wrote:
I think its pretty much useless to install everything
and this is where you (and presumably serveral others like you) disagree with me and several others like me. That does not make us wrong.
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road. Granted we have a new package selector in anaconda now, but I guess adding back the Everything checkbox and code, perhaps hidden behind an "offereverything" boot loader option (so we don't scare away unsuspecting types) can't be that much of an effort. I'd say it would be worth the trouble, because then we could end this discussion.
Nils
On Thu January 26 2006 7:48 am, Nils Philippsen wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road. Granted we have a new package selector in anaconda now, but I guess adding back the Everything checkbox and code, perhaps hidden behind an "offereverything" boot loader option (so we don't scare away unsuspecting types) can't be that much of an effort. I'd say it would be worth the trouble, because then we could end this discussion.
I'll add my voice to this chorus - please put the "everything" option back. Put a warning in if you deem it necessary, but don't remove the option. Linux is about choices - let us, the end-users, decide.
On Thu, 26 Jan 2006, Claude Jones wrote:
I'll add my voice to this chorus - please put the "everything" option back. Put a warning in if you deem it necessary, but don't remove the option. Linux is about choices - let us, the end-users, decide.
while i really didn't want to add anything further to this thread, just a few more brief observations:
1) if, as some people have justifiably claimed, the label of "Everything" might be ambiguous (does that mean everything on accompanying CDs as well?), then just change the label to "All of the above." problem solved, OK?
2) there is no "cost" or "danger" associated with such a button. given that you would (theoretically) get *exactly* the same effect by just selecting all of the visible boxes that are already there, you simply can't make that argument, so please stop. you're just embarrassing yourself.
3) on the other hand, there is most *assuredly* a cost with removing that button, and that is that it annoys some users by forcing them to do more work than they would have to otherwise. and, yes, that's a cost. deal with it.
4) finally, if this is already a done deal and the button has been removed and it's non-negotiable, please make that clear so all of us can stop wasting our time and just move on. it would be just plain cruel to have let this thread go on this long if it was all utterly pointless from the beginning.
rday
I have just installed FC5-Test2. I have to connect Evolution to an Exchange server, and it does not seem to be working well - loses the back end connection to Exchange at random (but frequently).
There is a note at startup that says that Evolution 2.5.x is not stable, and if necessary it should be removed and the older 2.4.x version installed. I was able to remove the program with yum, but I can't locate the older version - how do I get it installed?
thanks,
nbc
On Thursday 26 January 2006 13:33, Robert P. J. Day wrote:>
while i really didn't want to add anything further to this thread, just a few more brief observations:
- if, as some people have justifiably claimed, the label of
"Everything" might be ambiguous (does that mean everything on accompanying CDs as well?), then just change the label to "All of the above." problem solved, OK?
I've stayed out of this discussion for the past few days since I think Rahul already has his mind made up and we're not going to get our "Everything" install button back.
But if there is a problem with with ambiguous interpretations of the button why not relabel it
"All packages on the CORE CD's" ^^^^ note core only no extras or third party repos.
- there is no "cost" or "danger" associated with such a button.
given that you would (theoretically) get *exactly* the same effect by just selecting all of the visible boxes that are already there, you simply can't make that argument, so please stop. you're just embarrassing yourself.
Not quite true, there are lots of packages on the CD's/iso's which are not in any of the package groups which are selectable. But I agree there is no "cost" associated with the button especially if it was clearly labeled and a warning issued on it's use.
- on the other hand, there is most *assuredly* a cost with removing
that button, and that is that it annoys some users by forcing them to do more work than they would have to otherwise. and, yes, that's a cost. deal with it.
Very true. I've just done an install and spent 10 minutes clicking mouse buttons to select everything in the package groups. Even after that there were 894 rpm's from the iso's not installed.
- finally, if this is already a done deal and the button has been
removed and it's non-negotiable, please make that clear so all of us can stop wasting our time and just move on. it would be just plain cruel to have let this thread go on this long if it was all utterly pointless from the beginning.
As I said I think Rahul has his mind already made up.
rday
Tony
On Thu, 26 Jan 2006, Tony Molloy wrote:
On Thursday 26 January 2006 13:33, Robert P. J. Day wrote:>
- there is no "cost" or "danger" associated with such a button.
given that you would (theoretically) get *exactly* the same effect by just selecting all of the visible boxes that are already there, you simply can't make that argument, so please stop. you're just embarrassing yourself.
Not quite true, there are lots of packages on the CD's/iso's which are not in any of the package groups which are selectable.
but i could have sworn that jef "no, there's only one 'f' there" spaleta was talking about a reorg of the packages so that *all* packages ended up in some category. if some packages would still not be categorized then, yes, my point would not be valid and i would withdraw it.
rday
2006/1/26, Robert P. J. Day rpjday@mindspring.com:
On Thu, 26 Jan 2006, Tony Molloy wrote:
On Thursday 26 January 2006 13:33, Robert P. J. Day wrote:>
- there is no "cost" or "danger" associated with such a button.
given that you would (theoretically) get *exactly* the same effect by just selecting all of the visible boxes that are already there, you simply can't make that argument, so please stop. you're just embarrassing yourself.
Not quite true, there are lots of packages on the CD's/iso's which are not in any of the package groups which are selectable.
but i could have sworn that jef "no, there's only one 'f' there" spaleta was talking about a reorg of the packages so that *all* packages ended up in some category. if some packages would still not be categorized then, yes, my point would not be valid and i would withdraw it.
rday
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
Every package should definitely be categorized in my eyes. just my opinion.
regards, Rudolf Kastl
Tony Molloy wrote:
On Thursday 26 January 2006 13:33, Robert P. J. Day wrote:>
while i really didn't want to add anything further to this thread, just a few more brief observations:
- if, as some people have justifiably claimed, the label of
"Everything" might be ambiguous (does that mean everything on accompanying CDs as well?), then just change the label to "All of the above." problem solved, OK?
I've stayed out of this discussion for the past few days since I think Rahul already has his mind made up and we're not going to get our "Everything" install button back.
Let me make this clear. I didnt decide to pull of this option nor can I decide not to bring this option back. I am only offering my viewpoints on it.
Nils Philippsen wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road.
You are thinking about this from the development perspective. The code base is a no brainer but from the support perspective the number of issues that a everything installation has caused is innumerous. Specifically in Fedora, try doing a everythings installation of FC4 and try running yum update. Watch GFS module packages fail.
On Thursday 26 January 2006 11:46 am, Rahul Sundaram wrote:
You are thinking about this from the development perspective. The code base is a no brainer but from the support perspective the number of issues that a everything installation has caused is innumerous. Specifically in Fedora, try doing a everythings installation of FC4 and try running yum update. Watch GFS module packages fail.
Been there, done that... I would still vote for keeping the option in. Make it a hidden option - put a BIG disclaimer next to it - advise against it - BUT, keep it in.
On Thu, 26 Jan 2006, Rahul Sundaram wrote:
Nils Philippsen wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road.
You are thinking about this from the development perspective. The code base is a no brainer but from the support perspective the number of issues that a everything installation has caused is innumerous. Specifically in Fedora, try doing a everythings installation of FC4 and try running yum update. Watch GFS module packages fail.
short response:
what on earth are GFS-related packages doing as part of a *standard* FC install? i mean, seriously -- why would regular users *ever* want to install clustering software?
longer response:
perhaps i misunderstood one of the eventual goals, but wasn't it part of the plan to *pare down* what would be a standard install of FC, and move a lot of what's there now onto supplementary disks? that approach would solve a lot of problems.
seriously, i've never understood why FC4 sucked up 4 entire CDs. why not just make the "Everything" install reflect a much more stripped install, and leave the rest of it for firstboot or something like that?
i can imagine at least a couple categories that would make sense to push off until firstboot:
1) office software (OOo, as if you couldn't guess)
2) multimedia (all audio/video stuff)
and so on.
wasn't this part of the eventual plan? or something vaguely like it?
rday
Hi
short response:
what on earth are GFS-related packages doing as part of a *standard* FC install? i mean, seriously -- why would regular users *ever* want to install clustering software?
Its not but a everything installation would pull it. Thats the whole point.
longer response:
perhaps i misunderstood one of the eventual goals, but wasn't it part of the plan to *pare down* what would be a standard install of FC, and move a lot of what's there now onto supplementary disks? that approach would solve a lot of problems.
seriously, i've never understood why FC4 sucked up 4 entire CDs. why not just make the "Everything" install reflect a much more stripped install, and leave the rest of it for firstboot or something like that?
I agree with that.
On Thu, 26 Jan 2006, Rahul Sundaram wrote:
Hi
short response:
what on earth are GFS-related packages doing as part of a *standard* FC install? i mean, seriously -- why would regular users *ever* want to install clustering software?
Its not but a everything installation would pull it. Thats the whole point.
longer response:
perhaps i misunderstood one of the eventual goals, but wasn't it part of the plan to *pare down* what would be a standard install of FC, and move a lot of what's there now onto supplementary disks? that approach would solve a lot of problems.
seriously, i've never understood why FC4 sucked up 4 entire CDs. why not just make the "Everything" install reflect a much more stripped install, and leave the rest of it for firstboot or something like that?
I agree with that.
you just contradicted your first point. if "Everything" is defined to be a pared down version, then "Everything" wouldn't necessarily pull in stuff like GFS.
again, don't think "everything". think "all of the above", where "above" isn't as voluminous as it is now.
rday
Hi
you just contradicted your first point. if "Everything" is defined to be a pared down version, then "Everything" wouldn't necessarily pull in stuff like GFS.
Currently everything is not parred down and it pulls GFS. I dont see the contradiction.
again, don't think "everything". think "all of the above", where "above" isn't as voluminous as it is now.
When it gets less voluminous everything installation is much more useful. I agree with that completely.
2006/1/26, Rahul Sundaram sundaram@redhat.com:
Hi
you just contradicted your first point. if "Everything" is defined to be a pared down version, then "Everything" wouldn't necessarily pull in stuff like GFS.
Currently everything is not parred down and it pulls GFS. I dont see the contradiction.
again, don't think "everything". think "all of the above", where "above" isn't as voluminous as it is now.
When it gets less voluminous everything installation is much more useful. I agree with that completely.
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
someone gotta fix GFS then.
regards, rudolf kastl
p.s. as a developer i dont need a clusterfs.. as a user i am happy about it.
2006/1/26, Rahul Sundaram sundaram@redhat.com:
Nils Philippsen wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road.
You are thinking about this from the development perspective. The code base is a no brainer but from the support perspective the number of issues that a everything installation has caused is innumerous. Specifically in Fedora, try doing a everythings installation of FC4 and try running yum update. Watch GFS module packages fail.
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
well but the issues it triggers are identified issues... the issues also exist without an everything install... just my point of view. found and reproduceable issues are already half fixed issues ;)) (i am a positive thinker)
regards, rudolf kastl
Nils Philippsen nphilipp@redhat.com wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road. Granted we have a new package selector in anaconda now, but I guess adding back the Everything checkbox and code, perhaps hidden behind an "offereverything" boot loader option (so we don't scare away unsuspecting types) can't be that much of an effort. I'd say it would be worth the trouble, because then we could end this discussion.
Yet again: The code to do this is probably quite simple. The problem is the fallout in form of non-working systems with weird sympthoms, security problems caused by forgotten servers installed, performance problems due to unnecesary stuff running (or at least on disk), longer update times (and higher load on mirrors). The (missing) feature you see, it's fallout you don't.
On Sat, 2006-01-28 at 02:21 -0300, Horst von Brand wrote:
Nils Philippsen nphilipp@redhat.com wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road. Granted we have a new package selector in anaconda now, but I guess adding back the Everything checkbox and code, perhaps hidden behind an "offereverything" boot loader option (so we don't scare away unsuspecting types) can't be that much of an effort. I'd say it would be worth the trouble, because then we could end this discussion.
Yet again: The code to do this is probably quite simple. The problem is the fallout in form of non-working systems with weird sympthoms, security problems caused by forgotten servers installed, performance problems due to unnecesary stuff running (or at least on disk), longer update times (and higher load on mirrors). The (missing) feature you see, it's fallout you don't. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
I just spent about and hour ticking check boxes because I wanted everything. I want to test it, play with it, break it, fix it. I have the bandwidth and the disk space. If in the process of my explorations I find I need an application or library, I want it to be there. I want to see Japanese characters when I access a Japanese web page. I want the Polish professor in my LUG to see Polish when he borrows my laptop. Please give me back that option, even if you hide it.
Stanton Finley http://stanton-finley.net/
On Saturday 28 January 2006 12:21 am, Horst von Brand wrote:
Yet again: The code to do this is probably quite simple. The problem is the fallout in form of non-working systems with weird sympthoms, security problems caused by forgotten servers installed, performance problems due to unnecesary stuff running (or at least on disk), longer update times (and higher load on mirrors). The (missing) feature you see, it's fallout you don't.
And once again I say (because no one has chosen to refute this suggestion), make the option available, but hide it. When those who want the option reveal it, accompany the option with a BOLD disclaimer, that it is NOT advised. Again I ask, why is this proposal unsatisfactory to the "Remove" faction? Especially if the code is simple, as contended above? As regards "fallout", I've been subscribed, and participate to the extent my knowledge permits, on the Fedora list for 20 months, now. I don't see the fallout, I don't see large numbers of posts by people who's problem is unwanted services running... There are some, but, perhaps fallout is a bit strong. In any event, hiding the option, and putting a big disclaimer next to it, would sure reduce fallout, it that's the big concern.
Horst von Brand wrote:
Nils Philippsen nphilipp@redhat.com wrote:
On Sun, 2006-01-22 at 20:03 +0530, Rahul Sundaram wrote:
No it doesnt. I made my argument with detailed rationale on why I believe it is not useful in general cases. If you disagree with me, feel free to do so but I would like to hear a detailed set of use cases that make it a convincing enough argument for Anaconda to support it for end users apart from Kickstart capability.
What most people complain about here is AFAICS that we completely removed (instead of just hid) an option they valued and that was a well tested (by them), supposedly no-brainer sort of code path, very much unlikely to give any problems down the road. Granted we have a new package selector in anaconda now, but I guess adding back the Everything checkbox and code, perhaps hidden behind an "offereverything" boot loader option (so we don't scare away unsuspecting types) can't be that much of an effort. I'd say it would be worth the trouble, because then we could end this discussion.
Yet again: The code to do this is probably quite simple. The problem is the fallout in form of non-working systems with weird sympthoms, security problems caused by forgotten servers installed, performance problems due to unnecesary stuff running (or at least on disk), longer update times (and higher load on mirrors). The (missing) feature you see, it's fallout you don't.
It is a poor design decision to remove a useful feature because that feature uncovers other problems that should be fixed rather than covered up. For example, the security concern about unused services should be handled by making sure that the initial state of the service when installed is that it is NOT running. Thus it is not a problem for those that don't use it and those that use it know that they need to turn it on. Each and every one of the 'objections' to the feature has a better solution than removing the "everything" feature (in some form). Carrying the "remove problematic (but useful) features when they are not the real problem" to any extent will lead to a "dumbdowned" feature set. Then we can call the distro "Fedora for Dummies".
On Sat, 2006-01-28 at 14:17 -0500, Richard Hally wrote:
It is a poor design decision to remove a useful feature because that feature uncovers other problems that should be fixed rather than covered up.
We're not talking about removing it. When the installer underpinnings changed to yum, the everything code would have to be written again. The old code doesn't work, the new code doesn't exist. We're talking about re-adding the feature back in, not dropping an existing feature.
Jesse Keating wrote:
On Sat, 2006-01-28 at 14:17 -0500, Richard Hally wrote:
It is a poor design decision to remove a useful feature because that feature uncovers other problems that should be fixed rather than covered up.
We're not talking about removing it. When the installer underpinnings changed to yum, the everything code would have to be written again. The old code doesn't work, the new code doesn't exist. We're talking about re-adding the feature back in, not dropping an existing feature.
Yes, I was referring to a 'feature sets' feature (capability) not whether the code was there or not.
Jesse Keating wrote:
On Sat, 2006-01-28 at 14:17 -0500, Richard Hally wrote:
It is a poor design decision to remove a useful feature because that feature uncovers other problems that should be fixed rather than covered up.
We're not talking about removing it. When the installer underpinnings changed to yum, the everything code would have to be written again. The old code doesn't work, the new code doesn't exist. We're talking about re-adding the feature back in, not dropping an existing feature.
With reading the fedora-list, reading and also experiencing myself some problems that relate to more packages, thus more to go wrong, I would agree that large package sets are not ideal for the bulk of users. I do however feel that ways to make this option available should be made to make an installation of all packages that are available without a lot of effort. Since the updating mechanism has changed and currently does not exist, thinking of the best method to reinstate an all available packages option can be discussed and the solution can be adopted for adding this feature to the installer.
Proposals: 1) make a command line option to perform a "yum -y install "*" option that a user could invoke. 2) Add an option that would allow all available packages to be selected with one click or at least selecting them all per category. 3) Develop a way to run an everything install after the system is setup to a smaller state at first boot. This would either be limited to those that use the DVD or from some devised scheme where the correct CD could be chosen with several CDs without having to toggle discs. 4) Cut down on the release size of packages that are not installable with the installer, but add them to the "lower 800" CD or some similar scheme.
Though this thread is long and viewpoints sometimes seem to be rather unmoving, it has expressed some fairly solid rationalizing from both extremes and those who hold middle ground.
Jim
On 1/22/06, gb spam gbofspam@gmail.com wrote:
We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
So let me get this straight.. nothing other than a single check box during install is going to satify you? There is no room to compromise? You've drawn the line in the sand and you are holding your breath? That's unfortunate.
Some of us, are working with the maintainers to identify which packages are not incorporated into the comps grouping structure correctly so that the functionality of the install all button will essentially be duplicate by selecting all displayed packages in all displayed groups during the install process. However since you aren't interested in anything but the single button solution, and aren't interested in helping with the comps membership organization( which also has value during post-install for finding and removing applications) I won't invite you to help with https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174244.
-jef
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
On 1/22/06, gb spam gbofspam@gmail.com wrote:
We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
So let me get this straight.. nothing other than a single check box during install is going to satify you? There is no room to compromise? You've drawn the line in the sand and you are holding your breath? That's unfortunate.
um ... no. what's unfortunate is your condescending attitude towards folks who are pointing out that they *like* the concept of an everything install. that would include folks like *me*, by the way. does that mean you're going to insult me as well?
Some of us, are working with the maintainers to identify which packages are not incorporated into the comps grouping structure correctly so that the functionality of the install all button will essentially be duplicate by selecting all displayed packages in all displayed groups during the install process.
ah. in other words, you're *going* to support an "everything" install, you're just going to make it way more inconvenient than it used to be.
bravo. progress marches on.
rday
Robert P. J. Day wrote:
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
On 1/22/06, gb spam gbofspam@gmail.com wrote:
We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
So let me get this straight.. nothing other than a single check box during install is going to satify you? There is no room to compromise? You've drawn the line in the sand and you are holding your breath? That's unfortunate.
um ... no. what's unfortunate is your condescending attitude towards folks who are pointing out that they *like* the concept of an everything install. that would include folks like *me*, by the way. does that mean you're going to insult me as well?
Can you explain to me a few different use cases which makes it a good argument to be available by default other than selecting package groups, kickstart and using yum . Please explain with rationale instead of just stating your preference.
On 1/22/06, Rahul Sundaram sundaram@redhat.com wrote:
Robert P. J. Day wrote:
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
On 1/22/06, gb spam gbofspam@gmail.com wrote:
We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
So let me get this straight.. nothing other than a single check box during install is going to satify you? There is no room to compromise? You've drawn the line in the sand and you are holding your breath? That's unfortunate.
um ... no. what's unfortunate is your condescending attitude towards folks who are pointing out that they *like* the concept of an everything install. that would include folks like *me*, by the way. does that mean you're going to insult me as well?
Can you explain to me a few different use cases which makes it a good argument to be available by default other than selecting package groups, kickstart and using yum . Please explain with rationale instead of just stating your preference.
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
--
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option. Me personally, I like the "minimum" check box but thats gone too :)
Hi
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?. Present the different scenarios where everything installation is useful enough for the end user to be prominently visible as a option?
Me personally, I like the "minimum" check box but thats gone too :)
This is a valid point I guess.
On 1/22/06, Rahul Sundaram sundaram@redhat.com wrote:
Hi
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?. Present the different scenarios where everything installation is useful enough for the end user to be prominently visible as a option?
Going through the list and selecting everything would be a pita, the users that want the "everything" have already stated why they want it back. I'm on the side of the fence of "I don't care, I've never installed everything in 7 years and I never will". However, I can see from this string of e-mails "why" it is important to some and I really wouldn't want to go through each category and sub category to select each item either, seems it would be very time consuming and all around a pita.
Me personally, I like the "minimum" check box but thats gone too :)
This is a valid point I guess.
-- Rahul
Minimum I think is more valid than everything, for reasons like were folks
are limited to dial up or something slow and pulling down 5 iso's over a week or however long that would take would just be horrible. 1.) download 6mb boot.iso 2.) http install with minimum 3.) yum install what you need as you go
I don't have a d/l problem my self, I just like to install minium and put what I want on there sometimes.
Hi
Going through the list and selecting everything would be a pita, the users that want the "everything" have already stated why they want it back. I'm on the side of the fence of "I don't care, I've never installed everything in 7 years and I never will". However, I can see from this string of e-mails "why" it is important to some and I really wouldn't want to go through each category and sub category to select each item either, seems it would be very time consuming and all around a pita.
Yes it can be a pain but why is it required at all?
Minimum I think is more valid than everything, for reasons like were folks are limited to dial up or something slow and pulling down 5 iso's over a week or however long that would take would just be horrible. 1.) download 6mb boot.iso 2.) http install with minimum 3.) yum install what you need as you go
I don't have a d/l problem my self, I just like to install minium and put what I want on there sometimes.
Valid point here because you presented the use case of a dialup user and that makes the difference.
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Hi
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?.
because some people *want* it that way. why is that so difficult to understand? if you object to that kind of inconvenience, then you should similarly object to the convenience offered by things like "workstation" install, which is simply a shortcut as well.
rdayx
Robert P. J. Day wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Hi
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?.
because some people *want* it that way. why is that so difficult to understand? if you object to that kind of inconvenience, then you should similarly object to the convenience offered by things like "workstation" install, which is simply a shortcut as well.
rdayx
Workstation installations are often enough and targeted. Everything installation is targeted at nothing at all. Every obscure feature has users lobbying for it. Developer's job is to only implement features that makes good sense.
On Sun, 2006-01-22 at 21:48 +0530, Rahul Sundaram wrote:
Workstation installations are often enough and targeted. Everything installation is targeted at nothing at all. Every obscure feature has users lobbying for it. Developer's job is to only implement features that makes good sense.
You could argue that Everything installs are targeted at testers and developers. Besides, they are a very quick way to get a system installed with the added bonus that you don't find something missing afterwards just because you happened to oversee something in the package selector. It's a convenience I buy with disk space and bandwidth which admittedly are cheap for me.
Nils
Nils Philippsen wrote:
On Sun, 2006-01-22 at 21:48 +0530, Rahul Sundaram wrote:
Workstation installations are often enough and targeted. Everything installation is targeted at nothing at all. Every obscure feature has users lobbying for it. Developer's job is to only implement features that makes good sense.
You could argue that Everything installs are targeted at testers and developers.
Then it can be enabled only during test/development releases.
Robert P. J. Day rpjday@mindspring.com wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?.
because some people *want* it that way.
Right. Some people *want* a KDE only installation by one click. Others "just the webserver stuff" by one click. Ad nauseam. That way you'll end up with hundereds of "single click" options, and that kind of defeats their purpose.
Besides, "everything" is dangerous. It makes no sense to install the webserver and the FTP server and the telnet server and two or three mail servers and... just because that is somehow more convenient than finding out what is needed and installing that.And if you are in charge of a dozen machines, you can't squirm your way out by saying you are not a sysadmin, and thus not required to learn a bit about kickstart. Best part about that is that with a little care you set it up and tweak it when something new comes around, almost maintenance-free (even for distribution upgrades).
why is that so difficult tounderstand? if you object to that kind of inconvenience, then you should similarly object to the convenience offered by things like "workstation" install, which is simply a shortcut as well.
It is. But one that has not just "some" people, but a large(ish) fraction of the target population as users.
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?. Present the different scenarios where everything installation is useful enough for the end user to be prominently visible as a option?
because not everyone has a mouse
because some pointing devices, clicking a zillion buttons is extremely time consuming and annoying
because for disabled users, clicking a jillion buttons is very tedious
-Dan
goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
The problem is, folks don't want to go through each category and select "everything" they like the simple one click and done option.
Again just dont keep telling me you dont like to do this. Tell me why it needs to be a single click?. Present the different scenarios where everything installation is useful enough for the end user to be prominently visible as a option?
because not everyone has a mouse
because some pointing devices, clicking a zillion buttons is extremely time consuming and annoying
You do know that Anaconda has a text interface too. right?
because for disabled users, clicking a jillion buttons is very tedious
Actually for disabled users the GTK accessibility features are usually much better than text interfaces.
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
because for disabled users, clicking a jillion buttons is very tedious
Actually for disabled users the GTK accessibility features are usually much better than text interfaces.
you totally missed the point. one button is better than many.
this is why in accessability guidelines they recommend a 'select all' for lists with more than a few entries.
-Dan
søn, 22 01 2006 kl. 15:50 -0800, skrev goemon@anime.net:
you totally missed the point. one button is better than many.
this is why in accessability guidelines they recommend a 'select all' for lists with more than a few entries.
Select all once the installer gets enabled to install from Extras, while considerably lenghten install time, put load on the mirrors not to mention fill up several gigs of diskspace.
I'm all for aiding disabled users, being one myself, but the install everything option is quite complex. If you do intend to do this, the point of having all these selections in the gui might be moot - if you want everything, how about there being a netinstall (like the Development test isos) that just default to hammering every single package on the system without asking first. That would save quite a few steps for those users who absolutely require this behavior and the rest of us can rejoice in the sanity that is the current default.
I don't imagine such a project could be hard to undertake, and this would a sensible middle ground I think.
- David
On Mon, 23 Jan 2006, David Nielsen wrote:
søn, 22 01 2006 kl. 15:50 -0800, skrev goemon@anime.net:
you totally missed the point. one button is better than many. this is why in accessability guidelines they recommend a 'select all' for lists with more than a few entries.
Select all once the installer gets enabled to install from Extras, while considerably lenghten install time, put load on the mirrors not to
and yet this is what some people seem to be arguing, eg making the installer see other repos and move the package selection to post install. i dont see this as being particularly nice to mirrors
of course now someone will pop up and suggest that all every single end user has to do is set up their own local mirror
-Dan
goemon@anime.net wrote:
On Mon, 23 Jan 2006, David Nielsen wrote:
søn, 22 01 2006 kl. 15:50 -0800, skrev goemon@anime.net:
you totally missed the point. one button is better than many. this is why in accessability guidelines they recommend a 'select all' for lists with more than a few entries.
Select all once the installer gets enabled to install from Extras, while considerably lenghten install time, put load on the mirrors not to
and yet this is what some people seem to be arguing, eg making the installer see other repos and move the package selection to post install. i dont see this as being particularly nice to mirrors
Yep. Thats why we are working in improving the mirror management to be more nicer. http://fedoraproject.org/wiki/Infrastructure/Schedule
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
and yet this is what some people seem to be arguing, eg making the installer see other repos and move the package selection to post install. i dont see this as being particularly nice to mirrors
Yep. Thats why we are working in improving the mirror management to be more nicer. http://fedoraproject.org/wiki/Infrastructure/Schedule
seems to me this should be priority 1 not 2, considering release is scheduled for march 15. or priority 0 if such a thing were possible.
-Dan
goemon@anime.net wrote:
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
and yet this is what some people seem to be arguing, eg making the installer see other repos and move the package selection to post install. i dont see this as being particularly nice to mirrors
Yep. Thats why we are working in improving the mirror management to be more nicer. http://fedoraproject.org/wiki/Infrastructure/Schedule
seems to me this should be priority 1 not 2, considering release is scheduled for march 15. or priority 0 if such a thing were possible.
Its not priority 1 since Fedora Installer doesnt support Fedora Extras yet.
goemon@anime.net wrote:
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
Its not priority 1 since Fedora Installer doesnt support Fedora Extras yet.
Is this an FC5 target or post FC5 target?
Extras support is a post FC5 target. So is mirror management improvements. You can help implement mirror management quicker by contacting the Fedora Infrastructure team. Patrick Barnes would be a good contact point if you want to help (cc'ed) to the discussion.
søn, 22 01 2006 kl. 17:19 -0800, skrev goemon@anime.net:
of course now someone will pop up and suggest that all every single end user has to do is set up their own local mirror
No (however the suggestion was highly humourous), but if my ISP would mirror Development I would be most grateful - they already host many free software projects including ftp.freebsd.org and I'm sure they have plenty of users like me running Fedora Development thus making it a worthwhile investment to mirror the packages just in terms of savings on bandwidth. I wonder who's behind to kiss to get this done..
- David
søn, 22 01 2006 kl. 09:48 -0600, skrev Justin Conover:
People... stop the madness.
You can still do the utterly pointless everything install if you absolutely need it - there are advantages of both having it and removing the option. Being clearly biased towards removing it I won't go into the flamewar further.
But this debat is going absolutely nowhere, could we please get on with life?
In other words, please for the sake of all which is compiled with GCC, END OF THREAD
- David
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Robert P. J. Day wrote:
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
On 1/22/06, gb spam gbofspam@gmail.com wrote:
We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
So let me get this straight.. nothing other than a single check box during install is going to satify you? There is no room to compromise? You've drawn the line in the sand and you are holding your breath? That's unfortunate.
um ... no. what's unfortunate is your condescending attitude towards folks who are pointing out that they *like* the concept of an everything install. that would include folks like *me*, by the way. does that mean you're going to insult me as well?
Can you explain to me a few different use cases which makes it a good argument to be available by default other than selecting package groups, kickstart and using yum . Please explain with rationale instead of just stating your preference.
hmmmmm ... that scraping you hear is the sound of goalposts being moved. apparently, it's not enough if i supply just *one* convincing reason for supporting an "everything" install. no, apparently, rahul wants to see "a few different use cases." ah, well, i should be grateful he didn't ask for several.
<anecdote>
i have a yahoo email account. when i log in to it, i might see a screenful of emails. with yahoo, i have the ability to select any subset of the visible emails and delete all checked emails. but yahoo also has this marvelous feature at the top -- with a single stroke, i can select *all* visible emails.
note that, strictly speaking, that meta checkbox isn't necessary. i could get *exactly* the same effect by manually and tediously checking each box one at a time. but the people at yahoo understand the concept of convenience -- hence, the meta checkbox. is that a nifty invention or what?
</anecdote>
back to reality. of course one could live without an "everything" install since, as folks here have pointed out, the idea is that you will be able to get the same effect without it, albeit with a little more effort.
using the same logic, you could do without a graphical installer since, technically speaking, everything can be done in text mode. sure, it would be more of a pain but, as we all understand, the functionality would still be there. do you buy *that* argument? no? why not? you just made the same one in a different context.
it's also odd that one can make the argument that there's no need to have an "everything" install if the packages are re-orged so that you can get the same effect by just checking every single box. in short (and as i mentioned before), this would be *exactly* equivalent to an everything install, it would just be far more of a PITA. this does not strike me as progress. ("sure, we'll give you the option of an 'everything' install. we just won't call it that, and it'll be far more annoying than it used to be.")
(by the way, if i read jef's posting correctly, the plan is to re-categorize so that *every* *single* *package* ends up in a category, is that correct? is it worth pointing out that, if one of these categories is called "Miscellaneous", it is a worthless re-categorization. but i digress. onward.)
perhaps the most irritating theme underlying this discussion is that people have to make a compelling argument to keep the concept of an everything install. i disagree. i think the developers have to make a compelling argument to *remove* it since many people have used it, and many people happen to like it.
rahul wanted some use cases to defend an everything install. i'll give him just one - i like it. period. and since it doesn't appear to do any obvious harm, and since it has historical precedence, and since it's been admitted that the same functionality will still be available but more inconveniently, i don't see why some people are so adamant about getting rid of it.
rday
Hi
Can you explain to me a few different use cases which makes it a good argument to be available by default other than selecting package groups, kickstart and using yum . Please explain with rationale instead of just stating your preference.
hmmmmm ... that scraping you hear is the sound of goalposts being moved. apparently, it's not enough if i supply just *one* convincing reason for supporting an "everything" install. no, apparently, rahul wants to see "a few different use cases." ah, well, i should be grateful he didn't ask for several.
Just one use case doesnt make a convincing argument you have to provide as many as possible for the relevant developers to understand whether the use cases provided by the users can be satisfied by other means or whether they exhibit patterns that show problems elsewhere or whether they truely need that option. A good developer's job is to say NO when it doesnt make sense and say YES only and if only the rationale provided by the users are solid enough for the feature to be added. Remember that every feature has a associated development and long term maintenance cost. Its is the responsibility of the developer to encourage good use cases and *discourage* the not so good ones. Of course some balances needs to be there to provide flexibility in order to present the user the benefit in cases where the developer has not thought of all the relevant use cases. Now in this particular scenario the flexibility is provided through checking the package groups or through installer or through using yum or pirut post installation. Now the question is whether you can present enough use cases for the developer to be convinced that the feature is worthy providing.
<anecdote>
i have a yahoo email account. when i log in to it, i might see a screenful of emails. with yahoo, i have the ability to select any subset of the visible emails and delete all checked emails. but yahoo also has this marvelous feature at the top -- with a single stroke, i can select *all* visible emails.
note that, strictly speaking, that meta checkbox isn't necessary. i could get *exactly* the same effect by manually and tediously checking each box one at a time. but the people at yahoo understand the concept of convenience -- hence, the meta checkbox. is that a nifty invention or what?
</anecdote>
No its not but its not a relevant analogy since I can already present use cases where it make sense. I provide detailed rationale why it *does not make sense*. I havent had much of a refute against the rationales presented by me. It could possible that I have missed out areas where it does indeed make sense despite my rationale. all I am asking for is users to present that so that it can discussed in detail.
back to reality. of course one could live without an "everything" install since, as folks here have pointed out, the idea is that you will be able to get the same effect without it, albeit with a little more effort.
using the same logic, you could do without a graphical installer since, technically speaking, everything can be done in text mode. sure, it would be more of a pain but, as we all understand, the functionality would still be there. do you buy *that* argument? no? why not? you just made the same one in a different context.
See above on developer responsibility.
perhaps the most irritating theme underlying this discussion is that
people have to make a compelling argument to keep the concept of an everything install. i disagree. i think the developers have to make a compelling argument to *remove* it since many people have used it, and many people happen to like it.
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
rahul wanted some use cases to defend an everything install. i'll give him just one - i like it. period. and since it doesn't appear to do any obvious harm, and since it has historical precedence, and since it's been admitted that the same functionality will still be available but more inconveniently, i don't see why some people are so adamant about getting rid of it.
It has very obvious harm. I remember so many times where users had a messed up box that I had to help them recover in #fedora channel. various administrative and security issues not to mention that a "everything" installation is not one really since Fedora Extras is not supported yet in the installer. Now your personal preference is that you somehow like it but it does require a better defense than that.
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
is the cost of an 'everything' button really so unreasonably high?
It has very obvious harm. I remember so many times where users had a messed up box that I had to help them recover in #fedora channel. various administrative and security issues not to mention that a "everything" installation is not one really since Fedora Extras is not supported yet in the installer. Now your personal preference is that you somehow like it but it does require a better defense than that.
Some of us dislike clicking jillions of buttons on every install. This seems a step backwards for FC.
-Dan
--- goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented
what I believe to be
compelling arguments against it. Remember again
that every feature has a
associated cost.
is the cost of an 'everything' button really so unreasonably high?
It has very obvious harm. I remember so many times
where users had a messed
up box that I had to help them recover in #fedora
channel. various
administrative and security issues not to mention
that a "everything"
installation is not one really since Fedora Extras
is not supported yet in
the installer. Now your personal preference is
that you somehow like it but
it does require a better defense than that.
Some of us dislike clicking jillions of buttons on every install. This seems a step backwards for FC.
I agree with you Dan. The idea of a custom install[Install Everything] should not be removed. It is time consuming to click on too many buttons. Keep the layout, it is excellent but please bring back the custom install option. I understand the need to make specialized options, i.e, for language customizations, selecting packages, etc. The changes in Anaconda are nice, but why get rid of a good thing "The everything install".
Best Regards,
Antonio
-Dan
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi
I agree with you Dan. The idea of a custom install[Install Everything] should not be removed. It is time consuming to click on too many buttons. Keep the layout, it is excellent but please bring back the custom install option. I understand the need to make specialized options, i.e, for language customizations, selecting packages, etc. The changes in Anaconda are nice, but why get rid of a good thing "The everything install".
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
--- Rahul Sundaram sundaram@redhat.com wrote:
Hi
I agree with you Dan. The idea of a custom install[Install Everything] should not be removed.
It
is time consuming to click on too many buttons.
Keep
the layout, it is excellent but please bring back
the
custom install option. I understand the need to
make
specialized options, i.e, for language
customizations,
selecting packages, etc. The changes in Anaconda
are
nice, but why get rid of a good thing "The
everything
install".
... because its not so good.
https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html.
Tell me on what occasions would a end user need it?
When a user is on dialup and wants to install some packages that are already on the iso's. Using yum to install software is nice but being on dialup is time consuming to get the programs that could have already been installed.
I understand the positives and negatives. In fact I like some of the new features in anaconda, but I missed the custom install. I know it is a double edged sword. It is very hard to please everybody.
Best Regards,
Antonio
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Antonio Olivares olivares14031@yahoo.com wrote:
[...]
When a user is on dialup and wants to install some packages that are already on the iso's. Using yum to install software is nice but being on dialup is time consuming to get the programs that could have already been installed.
OK, so you are arguing for getting the packages off the install CDs or DVDs when they are available there, not over the net? Sounds reasonable. AFAIU, SUSE does exactly that.
In any case, the /reasonable/ dial-up user will check locally first. Plus somebody who has got just dialup is quite unlikely to have enough machine to spare to install gobs of useless stuff...
In any case, the /reasonable/ dial-up user will check locally first. Plus somebody who has got just dialup is quite unlikely to have enough machine to spare to install gobs of useless stuff...
unlikely maybe, but does that mean we should have a policy to exclude them?
large user base * unlikely = significant numbers
gb spam gbofspam@gmail.com wrote:
In any case, the /reasonable/ dial-up user will check locally first. Plus somebody who has got just dialup is quite unlikely to have enough machine to spare to install gobs of useless stuff...
unlikely maybe, but does that mean we should have a policy to exclude them?
large user base * unlikely = significant numbers
Unlikely == unlikely. That there are 100 users that really (think) they need it doesn't make it fly. Need to consider how much it costs to cater for them, and if they are few and the cost is high, it just isn't worthwhile. The crux of the problem is that from the chair in front of the machine-to-be-installed the costs look a whole lot different than from the chair of the engineer who has to implement it and of the other one who has to deal with the fallout...
Note again, the talk is about an "Everything" install, but a quite strange one: No "languages I don't use", please (How is the installer to know I am confortable with English, Spanish and German? Others wouldn't install those and want Japanese...); no "useless packages" (who is to say a package like gnome-screensaver is/isn't useless?); "just Core" but "all I might need once in a blue moon" (i.e., Extras + the kitchen sink, please); "spare the user painful downloads via dialup" just so she suffers from painful updates all the time.
Rahul is right: Come up with /concrete/ cases of off-the-wall configurations that can't be handled nicely right now, and suggest ways to handle them sanely. Give guesstimates of numbers of users. Note that one-off power-user profiles won't cut it too much, as those (should) know their way around and so be able to tweak the install to their heart's content anyway.
Installing your favorite operating system is /not/ ordering a package deal at $RANDOM_FAST_FOOD_CHAIN, please.
On 1/25/06, Horst von Brand vonbrand@inf.utfsm.cl wrote:
That there are 100 users that really (think) they need it doesn't make it fly.
See below...
Need to consider how much it costs to cater for them, and if they are few and the cost is high
We keep being told the cost is high, but that is never being quantified. I am beginning to think that it is high on pride to have to change your mind and give the users what they obviously will miss.
If it is possible for me to click all the options myself manually, then its possible to automate it.
worthwhile. The crux of the problem is that from the chair in front of the machine-to-be-installed the costs look a whole lot different than from the chair of the engineer who has to implement it and of the other one who has to deal with the fallout...
Note again, the talk is about an "Everything" install, but a quite strange one: No "languages I don't use", please
Nope, install it all even if you or I current think I am not going to use it.
no "useless packages"
Nope, install it all even if you or I current think I am not going to use it.
"just Core" but "all I might need once in a blue moon"
Nope, install it all even if you or I current think I am not going to use it.
Rahul is right: Come up with /concrete/ cases of off-the-wall configurations that can't be handled nicely right now, and suggest ways to handle them sanely.
Good suggestions are being given, but in the replies they are either dismissed or snipped.
Give guesstimates of numbers of users.
I could give estimates, but you are likely to think they are biased towards my opinion, just like I think your estimates are biased towards your opinion (only 100 users only want this? seems low to me, particularly given the length of the discussion and the cry of "oh no, not this again" response to the first post to query it. its clearly a contentious decision, and its contentious because people use it and want it).
Note that one-off power-user profiles won't cut it too much
this is an example of a suggestion being dismissed. why should power users suffer?
as those (should) know their way around and so be able to tweak the install to their heart's content anyway.
Power users tend to like to take the shortest path to something. If you remove that shortest path and it is not replaced by something better, do not be surprised when they want it back.
Horst von Brand wrote:
OK, so you are arguing for getting the packages off the install CDs or DVDs when they are available there, not over the net? Sounds reasonable. AFAIU, SUSE does exactly that.
Not just the CD/DVD, but we need to be able to point to the iso image location on disk, or the Fedora/RPMS folder of the mounted iso image. I stopped making CD's to install fedora quite sometime ago. Ideally the storage location could be configured/stored, so that the add/remove doesn't require the user to keep entering the path details. For those trying to implement, try not to assume actual DVD/CD are available or have been created ! DaveT.
On 1/22/06, Rahul Sundaram sundaram@redhat.com wrote:
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
I wonder if there is a way to have an Everything option that isn't special checkbox in the installer but fits in with the groups. Everything would basically require all other groups, and specify that all optional packages in those groups were installed. It wouldn't even have to select every group. Leaving out the language specific groups would make sense since people will complain about getting languages they don't speak even if they selected everything.
I don't think comps.xml has a mechanism to specify which packages in a groupreq should be selected. I was thinking an attribute on the groupreq element which would have the values "mandatory", "default", "optional".
- Ian
Ian Burrell wrote:
On 1/22/06, Rahul Sundaram sundaram@redhat.com wrote:
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
I wonder if there is a way to have an Everything option that isn't special checkbox in the installer but fits in with the groups. Everything would basically require all other groups, and specify that all optional packages in those groups were installed. It wouldn't even have to select every group. Leaving out the language specific groups would make sense since people will complain about getting languages they don't speak even if they selected everything.
I don't think comps.xml has a mechanism to specify which packages in a groupreq should be selected. I was thinking an attribute on the groupreq element which would have the values "mandatory", "default", "optional".
- Ian
See the earlier bug reports on comps.xml related work. You can post your comments there or on followup discussion in anaconda lists. Thanks
Rahul Sundaram wrote:
Hi
I agree with you Dan. The idea of a custom install[Install Everything] should not be removed. It is time consuming to click on too many buttons. Keep the layout, it is excellent but please bring back the custom install option. I understand the need to make specialized options, i.e, for language customizations, selecting packages, etc. The changes in Anaconda are nice, but why get rid of a good thing "The everything install".
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
The major reason that I used the everything install in the recent past was the lack of packages that I liked being marked down the list and not selectable without using the everything installation choice.
Another reason for the rational resurrection of the everything install is because of groups of packages that are modularized and which bring up a lot of needless clicking on selections.
The major item that I disliked with doing an everything install was the inability to deselect portions of packages which I would not use. These packages are mainly related to different languages. I would prefer to have everything selectable and then allow a trimdown fo those that want an almost everything install.
For my computer usage, I use windows file servers, ftp, http, databases, a lot of multimedia applications, several desktops, development packages, legacy libraries and choose about everything anyway. Having this option is an option which should be available for those that find it useful.
On a clean install of FC5T2 that I went through today, I found the package groupings and package additions quite nice and easy to manage. I did however have to go through all of the groups and select the packages that were not selected by the default group selection fields.
Worthless package gnome-screensaver selected. Useful packages like gftp, mc and others I had to select. Packages that I use such as mozilla-mail were not even listed in the selection screens.
Also, why download 3+ gb of content and receive the suggestion that you use yum to get the rest of your desired packages from the mirrors?
I appreciate programs like pirut which aid in post-install package retrieval. I would however like to get the packages at installation time from the 3+ gig disc that I downloaded first. I then would upgrade the changes after the installation was loaded as I desire.
With a lot of useful programs being shifted over to Fedora Extras and maintained by developers from the community who take on the task of maintaining programs in the Extras repository, a disc or seperate installer to follow the reduced core package count seems to me to be of much value.
The option for an everything install is not unrealistic or not totally off the wall. For all of the extra packages installed during an everything install, what percentage of the everything packages really activate extra services?
Jim
On Tue, 2006-01-24 at 22:45 -0500, Jim Cornette wrote:
Worthless package gnome-screensaver selected. Useful packages like gftp, mc and others I had to select. Packages that I use such as mozilla-mail were not even listed in the selection screens.
Specific packages which are things that make sense to be user visible but aren't (mozilla mail probably counts here, although it is largely obsoleted by thunderbird at this point) should have a bug filed against comps so that they can be added at the appropriate location.
Jeremy
Jeremy Katz wrote:
On Tue, 2006-01-24 at 22:45 -0500, Jim Cornette wrote:
Worthless package gnome-screensaver selected. Useful packages like gftp, mc and others I had to select. Packages that I use such as mozilla-mail were not even listed in the selection screens.
Specific packages which are things that make sense to be user visible but aren't (mozilla mail probably counts here, although it is largely obsoleted by thunderbird at this point) should have a bug filed against comps so that they can be added at the appropriate location.
Jeremy
Thanks! I will file a bug against comps. There are programs which should be de-selectable like gnome-screensaver. Is this feature part of comps or another process?
Jim
Jim Cornette fct-cornette@insight.rr.com wrote:
[...]
The major reason that I used the everything install in the recent past was the lack of packages that I liked being marked down the list and not selectable without using the everything installation choice.
Did you report that obvious bug?
Another reason for the rational resurrection of the everything install is because of groups of packages that are modularized and which bring up a lot of needless clicking on selections.
Did you suggest a better layout?
Besides, after wanting "everything", you talk about "useless packages" being selected... now which one is it?
Horst von Brand wrote:
Jim Cornette fct-cornette@insight.rr.com wrote:
[...]
The major reason that I used the everything install in the recent past was the lack of packages that I liked being marked down the list and not selectable without using the everything installation choice.
Did you report that obvious bug?
I filed a bug for FC5T1 but not for problems where I just selected everything and un-installed the language packages later. I should have filed a bug related to the specific packages I wanted but were not selectable.
Another reason for the rational resurrection of the everything install is because of groups of packages that are modularized and which bring up a lot of needless clicking on selections.
Did you suggest a better layout?
The layout in the FC5T2 is a great layout and it is obvious that a lot of thought was put into the new installer. The problems that I see now are related to programs which do not show up on the installer selection screen. Also I see a problem where programs that are quite a deal less useful are not de-selectable and must be rpm -e useless-package after the installation is completed. The groups might be tailored where core libraries that are used by the major program do not show selectable, but individual front-ends to CLI programs or programs that can be removed without major dependency issues. This type of selection ability would appease a large spectrum of users.
Besides, after wanting "everything", you talk about "useless packages" being selected... now which one is it?
The major gripe was that gftp is not selected as a usual program to install and gnome-screensaver is not selectable. I use gftp frequently and choose it along with mozilla-mail and the rest of the suite. I also need to manually select mc and a few other programs. It is mainly a gripe where programs that I do not use are default and programs where I find very little redemption to are installed without having the initial ability to not select the program.
I do not think that I would select an everything install with the shape that pirut and the installer are in now. I do feel that users should be able to opt for a full install if they desire to install everything.
As someone stated, webmail companies added this feature so users can manage their systems better. Also, RHN used to have a select all feature and the feature came in handy to save steps. I see no problem with adding a way that one can set the installer to install everything and then be able to work their way down to smaller sets of selected packages.
Jim
On Mon, 2006-01-23 at 05:09 +0530, Rahul Sundaram wrote:
Hi
I agree with you Dan. The idea of a custom install[Install Everything] should not be removed. It is time consuming to click on too many buttons. Keep the layout, it is excellent but please bring back the custom install option. I understand the need to make specialized options, i.e, for language customizations, selecting packages, etc. The changes in Anaconda are nice, but why get rid of a good thing "The everything install".
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
Lemme see... last I looked, Fedora wasn't just for end users but also for testers and developers, on the contrary I would recommend that (unmanaged ;-) end users should use distributions with longer life cycles than Fedora.
(If this is Thursday, I don't dare imagining Friday) Nils
tor, 26 01 2006 kl. 14:58 +0100, skrev Nils Philippsen:
Lemme see... last I looked, Fedora wasn't just for end users but also for testers and developers, on the contrary I would recommend that (unmanaged ;-) end users should use distributions with longer life cycles than Fedora.
(If this is Thursday, I don't dare imagining Friday) Nils
If you want something useful for testers, and believe me an everything install is no good for 99% of all testers, give me test releases which by default installs -debuginfo packages for every package selected. Yes it will be big and dogslow but at least it carries with it some advantage for testers and consequently developers.
- David
On Sun, 2006-01-22 at 17:39, Rahul Sundaram wrote:
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
Pray tell, just who are these mythical 'end users' of which you go on and on about? This is Fedora under discussion, not RHEL. Fedora is quasi stable and short lived, I'd never suggest it for an 'end user.'
I really think an install with a single "are you sure you didn't accidentally boot this CD?" before doing everything fully automated would be considered the 'perfect zenlike state' by many. I'll be gone long before then though.
This seems to be yet another example of the long trend of 'defeaturization'. Attempts to call it a resource allocation issue fail when considered in the light of another post you made:
You could argue that Everything installs are targeted at testers and developers.
Then it can be enabled only during test/development releases.
So you consider it worth maintaining, but wish to supress the display of the option in final releases. That implies additional effort to switch it on and off, all in the persuit of some vague effort at avoiding confusion among these mythical 'end users'.
Perhaps some attention should be directed toward defining the future userbase being targeted. Then we can all know if we are or are not in that target population and can know whether to bother arguing.
And for the record, of late I always do an everything install at least once. Often finding new software that I would not otherwise have even known about. Wouldn't put an everything install into service, except as a buildhost, but it is handy.
John Morris wrote:
On Sun, 2006-01-22 at 17:39, Rahul Sundaram wrote:
... because its not so good. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html. Tell me on what occasions would a end user need it?
Pray tell, just who are these mythical 'end users' of which you go on and on about? This is Fedora under discussion, not RHEL. Fedora is quasi stable and short lived, I'd never suggest it for an 'end user.'
Fedora Core 1 which was the first release of Fedora released on 5 November 2003 is still maintained by the Fedora Legacy project. Not exactly a short update lifecycle and it could extended for as much time as contributers are willing to help with the project. Fedora releases are fast moving but are meant to be robust.
Hi
You could argue that Everything installs are targeted at testers and developers.
Then it can be enabled only during test/development releases.
So you consider it worth maintaining, but wish to supress the display of the option in final releases. That implies additional effort to switch it on and off, all in the persuit of some vague effort at avoiding confusion among these mythical 'end users'.
End users arent mythical beings in Fedora. There are a whole lot of them out there. The introduction of a option only meant for the test releases can be a very basic post installation yum install *. It doesnt necessarily involve adding much more code unlike the options in the GA releases.
On Thu, 2006-01-26 at 16:06, Rahul Sundaram wrote:
End users arent mythical beings in Fedora. There are a whole lot of them out there. The introduction of a option only meant for the test releases can be a very basic post installation yum install *. It doesnt necessarily involve adding much more code unlike the options in the GA releases.
Ok, let me restate this to make sure I understand.
To date, every Fedora Core or RHEL media set has included a very non-trivial number of uncatagorized packages not readily installable outside of an everything install. To even realize they are there requires a user to 1) know something as silly as this is happening and 2) know enough to do rpm -qip * on each of the CDs and wade through the output.
Then, if we find things we want we are expected to either setup a local repo with the packages on the CDs, redownload packages via yum or enter RPM Dependency Hell.
And this is being done to make things easier for 'end users' who are supposedly out there in great numbers, able to install Linux (hell, even create yum repos!) but lacking the literacy to read a warning notice.
Sorry guys, defeaturing the install isn't the magic bullet to make Linux ready for granny. Granny couldn't install Windows either, which is why it comes preloaded. I know, I have had to help enough people run the XP installer when their machine gets infested to the point a reinstall is the only safe option. I don't think Fedora can or should be quite as simple as XP's. For example Disk Druid kicks XP's partitioning program square in the nads but it isn't simpler.
John Morris wrote:
On Thu, 2006-01-26 at 16:06, Rahul Sundaram wrote:
End users arent mythical beings in Fedora. There are a whole lot of them out there. The introduction of a option only meant for the test releases can be a very basic post installation yum install *. It doesnt necessarily involve adding much more code unlike the options in the GA releases.
Ok, let me restate this to make sure I understand.
To date, every Fedora Core or RHEL media set has included a very non-trivial number of uncatagorized packages not readily installable outside of an everything install.
Yes. Thats the problem thats already being addressed in bugzilla. You can check out the related bugs and contribute to it. Thanks
On Thu, 2006-01-26 at 17:05 -0600, John Morris wrote:
To date, every Fedora Core or RHEL media set has included a very non-trivial number of uncatagorized packages not readily installable outside of an everything install. To even realize they are there requires a user to 1) know something as silly as this is happening and 2) know enough to do rpm -qip * on each of the CDs and wade through the output.
A lot of these packages are deps of other packages which ARE exposed. We don't expose each and every package for a clicky box. Thats an insane amount of boxes to display and a crapload of work to ensure that all apps are always in comps, etc, etc, etc... Thats 2198 checkboxes as of Test2. Translations for each package title, descript, etc...
So yes, there are packages that are not represented by a checkbox. There may be cases where these packages also don't get installed by an Everything, especially because of Language stuff. Everything selection doesn't mean EVERYTHING unless every language is selected. Even then there might be something which falls through the cracks. It is hard to keep up, and is part of the maint cost of having an 'everything' button.
as one of the more obnoxious posters who's been hounding rahul about this whole "everything"/"all of the above", i'll admit that, ***under the present circumstances***, i now see his point.
my arguments were based on the assumption that *all* available packages at compile time that would be considered part of a basic install would be *entirely* categorized and selectable via some checkbox selection. if that were the case, then it's *clear* that there would be no rational argument against an "All of the above" install.
*however*, the above is based on the assumption that every single package falls into some selectable category and, historically, that's clearly not been the case, as lots of people know. (historically, selecting every single checkbox still didn't give you what an "Everything" install did, and that was cause for much confusion on the part of folks who didn't realize that.)
clearly, a complete package categorization is a long-term goal and a good one (if it's achievable) and, as rahul admits, once that happens, then an "All of the above" install is not a problem. but until that categorization happens, then, yes, i can appreciate the problem as it exists currently.
i would still fall on the side of wanting an "Everything" install selection (however you define it), but it's obvious that a lot of this back-and-forth would go away once the categorization is finalized.
rday
p.s. even with the *current* layout, while an "Everything" install (in its historical sense) has the potential for confusion, an "All of the above" would most emphatically not. just my $0.02.
p.p.s. as i've written earlier, i'd like to see a partitioning of all the software into a much slimmer "basic" install, with a lot of that software selection moved into firstboot or something like it. is there a URL that discusses plans for something like this? thanks.
Hi
p.p.s. as i've written earlier, i'd like to see a partitioning of all the software into a much slimmer "basic" install, with a lot of that software selection moved into firstboot or something like it. is there a URL that discusses plans for something like this? thanks.
No such documented plan exists yet.
goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
is the cost of an 'everything' button really so unreasonably high?
Yes it is. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html
Some of us dislike clicking jillions of buttons on every install. This seems a step backwards for FC.
Use kickstart, post installation yum or click on maybe 6 groups or let me know the different use cases where end users would need it.
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
is the cost of an 'everything' button really so unreasonably high?
Yes it is. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html
not convincing at all...
this is a list of your rationales for removing it based on your assumptions of burden on end users, not a rationale that it is unreasonably high cost in code
Some of us dislike clicking jillions of buttons on every install. This seems a step backwards for FC.
Use kickstart
i cant believe someone would say an 'everything' button is unreasonably high cost, then with a straight face say 'use kickstart'... :P
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
-Dan
goemon@anime.net wrote:
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
is the cost of an 'everything' button really so unreasonably high?
Yes it is. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html
not convincing at all...
this is a list of your rationales for removing it based on your assumptions of burden on end users, not a rationale that it is unreasonably high cost in code
We care about burden of end users.
i cant believe someone would say an 'everything' button is unreasonably high cost, then with a straight face say 'use kickstart'... :P
Then help improve kickstart or atleast tell us whats wrong about it.
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
Not by far. Many people do support me. Just because a few people are more loud doesnt make them right. Instead of lobbying for a feature blindly, just tell me what different use cases does a end user require a "everything" installation which doesnt support other repositories like Fedora Extras yet and cannot be everything anyway.
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
Yeah everyone else in this discussion is insane.
I'm arguing for removal. In fact I'm arguing for removal of all package choice in the interactive Core installer so that an installation of core only gives you a default set of packages and everything else happens post install or via kickstart.
You do realize that anaconda is gaining the ability to see other repos beside Core in future fedora releases right? The "install everything" button in the UI surely will not map to what everyone would find useful when the installer can see both Core and Extras by default. Moving forward that little extra button is to incur more complexity to make any sense at all. Will everything mean just Core.. will it mean just Core+Extras.. will it mean Core+Extras+plus other repos you have enabled at install time? Are the developers going to have to build more UI around that one little button to give you a choice between those options. Complexity abounds without accomplishing much in the way of addressing a usage case that is not reasonably covered by post-install mechanisms.
If there were community provided kickstart images that did a Core everything install wouldn't that be sufficient solution.. instead of clicking you way through the graphical installer?
-jef"what is popular is not always right, and what is right is not always popular"spaleta
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
If there were community provided kickstart images that did a Core everything install wouldn't that be sufficient solution.. instead of clicking you way through the graphical installer?
seems like a rather convoluted band-aid to me. a custom built community provided kickstart image instead of a single gui button
-Dan
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
seems like a rather convoluted band-aid to me. a custom built community provided kickstart image instead of a single gui button
That's an interesting way to avoid the question i asked. If nothing other than the ui button will satify you and working towards any other implementation isn't something you are willing to explore, how about we just end this discussion and just replace it with a video of you beating your head against a brickwall which I can just watch for the next 3 hours and chuckle at.
-jef
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
seems like a rather convoluted band-aid to me. a custom built community provided kickstart image instead of a single gui button
That's an interesting way to avoid the question i asked. If nothing other than the ui button will satify you and working towards any other implementation isn't something you are willing to explore, how about we just end this discussion and just replace it with a video of you beating your head against a brickwall which I can just watch for the next 3 hours and chuckle at.
if you feel the need to make personal attacks on a mailing list then indeed we have nothing to discuss, so into procmail you go
-Dan
On Sun, 2006-01-22 at 17:40 -0800, goemon@anime.net wrote:
if you feel the need to make personal attacks on a mailing list then indeed we have nothing to discuss, so into procmail you go
Tactfully pointed out or not, you are STILL avoiding the question...
Hi all,
Jeff Spaleta wrote:
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
Yeah everyone else in this discussion is insane.
I'm arguing for removal. In fact I'm arguing for removal of all package choice in the interactive Core installer so that an installation of core only gives you a default set of packages and everything else happens post install or via kickstart.
Or "everything else" is extras or somewhere else. Consider the proposition that "If it's good enough to be included in Core it good enough to be installed on my system"
You do realize that anaconda is gaining the ability to see other repos beside Core in future fedora releases right? The "install everything" button in the UI surely will not map to what everyone would find useful when the installer can see both Core and Extras by default.
I sure hope that I have the choice in the installer to *not* use extras.
Moving forward that little extra button is to incur more complexity to make any sense at all. Will everything mean just Core.. will it mean just Core+Extras.. will it mean Core+Extras+plus other repos you have enabled at install time?
That should depend on which repos you have chosen to enable.
Are the developers going to have to build
more UI around that one little button to give you a choice between those options. Complexity abounds without accomplishing much in the way of addressing a usage case that is not reasonably covered by post-install mechanisms.
Are you forgetting the "non-internet access" use case? Or what about the person that only has a very slow connection(e.g. dial-up) and installs his system from the CDs he borrowed from his buddy and returns them after the install?
If there were community provided kickstart images that did a Core everything install wouldn't that be sufficient solution.. instead of clicking you way through the graphical installer?
Does kickstart install from CDs?
BTW, there is a bugzilla for kickstart not working with an everything selection.
-jef"what is popular is not always right, and what is right is not always popular"spaleta
And what makes Rahul think he knows the difference better than others? (wink,wink)
Richard
Richard Hally wrote:
Hi all,
Jeff Spaleta wrote:
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
Yeah everyone else in this discussion is insane.
I'm arguing for removal. In fact I'm arguing for removal of all package choice in the interactive Core installer so that an installation of core only gives you a default set of packages and everything else happens post install or via kickstart.
Or "everything else" is extras or somewhere else. Consider the proposition that "If it's good enough to be included in Core it good enough to be installed on my system"
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
Are you forgetting the "non-internet access" use case? Or what about the person that only has a very slow connection(e.g. dial-up) and installs his system from the CDs he borrowed from his buddy and returns them after the install?
You realize that work is being done to create ISO images of Fedora Extras packages too. right. Even you could that do that today.
Does kickstart install from CDs?
BTW, there is a bugzilla for kickstart not working with an everything selection.
Report number?
And what makes Rahul think he knows the difference better than others? (wink,wink)
Oh please guys. Listen before responding. I presented very detailed reasons why I think it is not a good thing. Now will any of you present a few different use cases that make it obsoletely require within the single click in the installer GUI itself instead of merely lobbying for a change without specifying the reasons why you use this option at all.
Rahul Sundaram wrote:
Richard Hally wrote:
Hi all,
Jeff Spaleta wrote:
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
Yeah everyone else in this discussion is insane.
I'm arguing for removal. In fact I'm arguing for removal of all package choice in the interactive Core installer so that an installation of core only gives you a default set of packages and everything else happens post install or via kickstart.
Or "everything else" is extras or somewhere else. Consider the proposition that "If it's good enough to be included in Core it good enough to be installed on my system"
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
You(Rahul) still don't get it! It's not about "using them all together" at all. Yes, it is about installing "everything" in Core at one time(install time!) *easily*. It's a usability / easy-of-use issue. It's about giving users the choice. If they want to - let then. Who are you to know better than users what they want to do. You can't seem to imagine any use cases. Your idea that developers know better than users what users want to do is flat wrong and smacks of paternalism.
Are you forgetting the "non-internet access" use case? Or what about the person that only has a very slow connection(e.g. dial-up) and installs his system from the CDs he borrowed from his buddy and returns them after the install?
You realize that work is being done to create ISO images of Fedora Extras packages too. right. Even you could that do that today.
Does kickstart install from CDs?
BTW, there is a bugzilla for kickstart not working with an everything selection.
Report number?
Search on "anaconda everything".
And what makes Rahul think he knows the difference better than others? (wink,wink)
Oh please guys. Listen before responding. I presented very detailed reasons why I think it is not a good thing.
And all those reasons are bogus and do not apply to the usability/ease of use of the package selection part of the installer.
Now will any of you present
a few different use cases that make it obsoletely require within the single click in the installer GUI itself instead of merely lobbying for a change without specifying the reasons why you use this option at all.
Several people have already given you "use cases" but this is not about your opinion that an "everything" install is not useful. It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
HTH Richard Hally
On 1/22/06, Richard Hally rhally@mindspring.com wrote:
Rahul Sundaram wrote:
Richard Hally wrote:
Hi all,
Jeff Spaleta wrote:
On 1/22/06, goemon@anime.net goemon@anime.net wrote:
so far it seems like almost everyone wants it back and you're the only one arguing for its removal. perhaps this should tell you something
Yeah everyone else in this discussion is insane.
I'm arguing for removal. In fact I'm arguing for removal of all package choice in the interactive Core installer so that an installation of core only gives you a default set of packages and everything else happens post install or via kickstart.
Or "everything else" is extras or somewhere else. Consider the proposition that "If it's good enough to be included in Core it good enough to be installed on my system"
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
You(Rahul) still don't get it! It's not about "using them all together" at all. Yes, it is about installing "everything" in Core at one time(install time!) *easily*. It's a usability / easy-of-use issue. It's about giving users the choice. If they want to - let then. Who are you to know better than users what they want to do. You can't seem to imagine any use cases. Your idea that developers know better than users what users want to do is flat wrong and smacks of paternalism.
Are you forgetting the "non-internet access" use case? Or what about the person that only has a very slow connection(e.g. dial-up) and installs his system from the CDs he borrowed from his buddy and returns them after the install?
You realize that work is being done to create ISO images of Fedora Extras packages too. right. Even you could that do that today.
Does kickstart install from CDs?
BTW, there is a bugzilla for kickstart not working with an everything selection.
Report number?
Search on "anaconda everything".
And what makes Rahul think he knows the difference better than others? (wink,wink)
Oh please guys. Listen before responding. I presented very detailed reasons why I think it is not a good thing.
And all those reasons are bogus and do not apply to the usability/ease of use of the package selection part of the installer.
Now will any of you present
a few different use cases that make it obsoletely require within the single click in the installer GUI itself instead of merely lobbying for a change without specifying the reasons why you use this option at all.
Several people have already given you "use cases" but this is not about your opinion that an "everything" install is not useful. It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
HTH Richard Hally
yum --exclude='jeff|Rahul' update users reading
I think many of you are missing the key point that is being made of "why" everything "click" is not good "NOW", not in the past, not in fc4/3/2/1 but now and beyond.
At some point, probably fc6 an "EVERYTHING" install could end up pulling in Extras and possibly some other 3rd party repos (which will be intresting for the users that don't know about mix'n'match of certian ones). Which means it will get freaking UGLY if you do EVERYTHING.
Instead of trying to maybe lessen the number of install cd/dvd's Fedora will end up looking like Debian Sarge, if you don't know what that means, Debian Sarge has 14 Cd's or 2 DVD's now,
FOURTEEN!!!!! Do you really want to sit on your pipe while 14 iso's are pulled down just so you can click EVERYTHING? Because in the future that is what your asking for now.
Me, I want one iso. Core + Gnome I'll use yum for the rest because guess what, thats what it does it d/l handles dep's with out the need to d/l iso after iso to grab a few rpm's here and there. with pup/piruit the user can be new and not even have to know yum exist and open up a cli if that grabs them.
If you just have to have that much software installed and affraid you might loose interent connection, start rsync'n the mirror to your local drive. Apparently space isn't a concern because one of these days the everything (click on every peice of software known to be on a fedora) install which I dunno, guessing is up to 6-7gb by now will start hitting 10gb in the future.
Anyway, the rants over but a lot of you are missing the key points that Jeff and Rahul are bring up (maybe some others, thread is up to 113 emails now, I'm not searching). Someday, everything is going to be so huge and ugly to do it would be nuts.
Don't just look at today, look down the road at what is going on and what is trying to be done.
Hi
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
You(Rahul) still don't get it! It's not about "using them all together" at all. Yes, it is about installing "everything" in Core at one time(install time!) *easily*. It's a usability / easy-of-use issue. It's about giving users the choice. If they want to - let then.
Choice has associated cost. Implementing everything any user ever asked for will lead to a unmaintainable mess.
Report number?
Search on "anaconda everything".
Thats not a number ;-)
And what makes Rahul think he knows the difference better than others? (wink,wink)
Oh please guys. Listen before responding. I presented very detailed reasons why I think it is not a good thing.
And all those reasons are bogus and do not apply to the usability/ease of use of the package selection part of the installer.
Sure. Call them all bogus with no explanation. That doesnt look a appealing argument.
Several people have already given you "use cases" but this is not about your opinion that an "everything" install is not useful.
Can you list them?
It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
Depends on what you want to do and how useful it is. I still havent heard good use cases yet.
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
Depends on what you want to do and how useful it is. I still havent heard good use cases yet.
"good" is subjective. and it seems a moving target in this case.
-Dan
goemon@anime.net wrote:
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
Depends on what you want to do and how useful it is. I still havent heard good use cases yet.
"good" is subjective. and it seems a moving target in this case.
Please explain what is good about the everything installation option. Dont throw around vague notions.
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
Depends on what you want to do and how useful it is. I still havent heard good use cases yet.
"good" is subjective. and it seems a moving target in this case.
Please explain what is good about the everything installation option. Dont throw around vague notions.
if this were posted to /. or digg you would get the answers you seek
-Dan
man, 23 01 2006 kl. 01:33 -0800, skrev goemon@anime.net:
if this were posted to /. or digg you would get the answers you seek
How is that any kind of reply, debating with you is like playing fundie wheel of fortune, which vague and inconclusive reply will you give to the sceptics challenge.
Asking your friends to help you cause a flamewar of slashdotish proportitions is no way to conduct reasonable debate, since when has sites like that where the barrier of entry to the debate requires zero amount of knowledge, zero amount of insight and to make matters worse the AC system ensures that uninformed nonsense and petty attacks are conducted without accountablity ever produced any kind of intelligent input. We are talking about a forum where random ignorant people under the moderation of other random ignorant people decide what is right and what is wrong. I can't tell you how often I've seen downright wrong posts modded +5, Insightful on slashdot. It's defies the scientific method, it's just.. well.. downright counter productive to rely on such metrics to get any kind of informed concensus.
There is a reason why civilized debate relies on informed opinion rather than popular opinion.
- David Nielsen
On Mon, 23 Jan 2006, David Nielsen wrote:
man, 23 01 2006 kl. 01:33 -0800, skrev goemon@anime.net:
if this were posted to /. or digg you would get the answers you seek
How is that any kind of reply, debating with you is like playing fundie wheel of fortune, which vague and inconclusive reply will you give to the sceptics challenge.
you asked for justifications. why not ask the end users.
[... slashdot rant snipped ...]
There is a reason why civilized debate relies on informed opinion rather than popular opinion.
asking your end users how they find 'everything' useful in actual practice is popular opinion?
i could pose the question to end users on other forums but i suspect it will be hard to find one you would accept the answers from
-Dan
goemon@anime.net wrote:
On Mon, 23 Jan 2006, David Nielsen wrote:
man, 23 01 2006 kl. 01:33 -0800, skrev goemon@anime.net:
if this were posted to /. or digg you would get the answers you seek
How is that any kind of reply, debating with you is like playing fundie wheel of fortune, which vague and inconclusive reply will you give to the sceptics challenge.
you asked for justifications. why not ask the end users.
Are you not an end user lobbying for this?. Why dont you explain to us how you use this option effectively?
asking your end users how they find 'everything' useful in actual practice is popular opinion?
It is
i could pose the question to end users on other forums but i suspect it will be hard to find one you would accept the answers from
Try.
i could pose the question to end users on other forums but i suspect it will be hard to find one you would accept the answers from
Try.
//putting on flac jacket
As an end user, who has installed every version of a rad hat product (aside from enterprise) and also someone who has extensive experience with Debian as well, ( FC is better IMHO) I can tell you what this end user has experienced.
I have done the everything install twice, My first time installing RH and Once in a class, it was convient in the class because we didn't have to yum or rpm packages we needed when we were covering a section, vsftpd and associated apps for example.
The first time I got burned, and I got a rootkit, because I as an end user had a package I didn't need.
I dont have an opinion on the everythig install 'cept to say that I haven't used it except for those two limited situations, and I was on a dial up for a long time and I can feel the pain of someone who has the gotcha of trying to install a big lib to get some other app running, on a dial-up.
anyway thats my $.02
-- --------------------- "Be careful Anais, abnormal pleasures kill the taste for normal ones." ~ Eduardo
Hi
I dont have an opinion on the everythig install 'cept to say that I haven't used it except for those two limited situations, and I was on a dial up for a long time and I can feel the pain of someone who has the gotcha of trying to install a big lib to get some other app running, on a dial-up.
package management tools should be fixed to enable users to install applications from CD/DVD's. Today you can do this by dumping all the packages into a directory. Running createrepo on them. They configure yum to point to the local repository instead of a online repository. man createrepo and man yum.conf for details.
man, 23 01 2006 kl. 04:01 -0800, skrev goemon@anime.net:
you asked for justifications. why not ask the end users.
What kind of end users are we talking about here, you average slashdot trolls or people who do real work.. what is our typical end user, you seem to think that you alone know who the target audience is and nobodies opinion matter except yours. When asked for supportive evidence for your stance you suggest slashdot as a serious reliable source of information.
asking your end users how they find 'everything' useful in actual practice is popular opinion?
Asking for a reasonable scenario that would justify "Everything" now and in the coming releases is quite sane - and everything that has been mentioned just far can be solved in a much more generic way tweaking profiles and using kickstart.
Should the Internet comes with a handy everything button as well, that would leech all information for convient offlne browsing?
i could pose the question to end users on other forums but i suspect it will be hard to find one you would accept the answers from
So now asking for evidence is stonewalling, great reasoning, I have yet to see any real world scenerios from you to suggest that Everything is absolutely needed now, much less that it should or even could be supported sanely for the coming cycles.
- David
On Monday 23 January 2006 10:52 am, David Nielsen wrote:
What kind of end users are we talking about here, you average slashdot trolls or people who do real work.. what is our typical end user, you seem to think that you alone know who the target audience is and nobodies opinion matter except yours. When asked for supportive evidence for your stance you suggest slashdot as a serious reliable source of information.
Hi I am an end user (and mostly lurker on this list)
<slip=into_the_lead_lined_shorts> <shrugging=flak_vest_on> I bought a Radio Shack TRS-80 in 1981. Ivan_I was a z80 running CP/M.
I use computers to write, organize photographs, do genealogy and related research.
I couldn't do much with RedHat 6.2, but it showed promise. I stayed with 7.3 as long as I could. I ran 8.0. 9.0 was a disaster; I used debian[sigh]. Fedora Core1 and I was back. Ivan_VIII is running FC4. I test on a spare machine, when one is available.
What I try to do is get some work done, and enjoy myself. What I try to avoid is to be a preprocessor for a computer. I don't want to learn the mechanics and calling conventions of packages without number. I run kde because gnome is configurable, but not usefully configured. Most of the time, I install Fedora Core twice on the same machine, in order to get the options right.
anaconda is just that good. It has been faster and more productive to re-install than to try fix a bad configuration. Before synaptic/apt and (k)yum(ex)/yum, I installed everything. I did not need most of the language packages; but it was easier and SAFER to load it all up. There is nothing worse than finding you need something, and that you are 7 levels of dependencies away from installing it.
IMHO, the trick is just to have it work. I have not apprenticed to emacs and I have no vim. This is never going to be a career for me. I am just looking to get a couple of jobs done. It is a joy to connect a digital camera, have it recognized, and just deal with editing and storing snapshots.
Following this list is a number of different educations - liberal arts as it were. I am impressed with the professionism and the elan. I don't know how average I am; but I aspire to be and end user.
And it is time to wrap this up and have beer. </shrug> </slip>
Cheers
Rahul Sundaram wrote:
goemon@anime.net wrote:
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
Depends on what you want to do and how useful it is. I still havent heard good use cases yet.
"good" is subjective. and it seems a moving target in this case.
Please explain what is good about the everything installation option. Dont throw around vague notions.
It saves me time when selecting packages to install. It saves me time to not have to install packages individually. I don't have to download packages (via yum or whatever) that have already been downloaded in the isos. I don't need a kickstart file. I don't need to waste space on disk with rpms when I already have the package installed from the initial installation.
HTH
Hi
Please explain what is good about the everything installation option. Dont throw around vague notions.
It saves me time when selecting packages to install.
Which ones?
It saves me time to not have to install packages individually.
What are you using your system for?. Is it a desktop/workstation/server/development system?. Doesnt it fit into one of these profiles?
I don't have to download packages (via yum or whatever) that have already been downloaded in the isos.
You cant work with them using the current tools provided anyway. Thats what we are trying to fix already. If you dont use yum to keep yourself updated installing everything is dangareous since it brings in potential security issues with packages you wouldnt even use.
I don't need a kickstart file.
I don't need to waste space on disk with rpms when I already have the package installed from the initial installation.
You waste disk space by installing packages you wouldnt use. You will to keep packages updated. Performance would do down with deamons and other session programs. You would be installing tons of world languages which you wouldnt be using and so on.
Rahul Sundaram wrote:
Hi
Please explain what is good about the everything installation option. Dont throw around vague notions.
It saves me time when selecting packages to install.
Which ones?
All of them, dummy. Duh! That is what we are talking about.
It saves me time to not have to install packages individually.
What are you using your system for?. Is it a desktop/workstation/server/development system?. Doesnt it fit into one of these profiles?
No it doesn't fit into one of those "profiles". I am (and have been since FC1) using it for Test and Evaluation of SELinux. *One* of the things I am looking at is how well this pervasive technology integrates with a reasonable sized distribution/OS. Also, I'm trying to see what the maintenance burden is when a large number of programs/packages are in play. For example, what will it take to keep policy current for all the package changes coming through rawhide?
I don't have to download packages (via yum or whatever) that have already been downloaded in the isos.
You cant work with them using the current tools provided anyway. Thats what we are trying to fix already. If you dont use yum to keep yourself updated installing everything is dangareous since it brings in potential security issues with packages you wouldnt even use.
This one is about *download*. see if you can follow this. All the rpms in Core get downloaded within the isos. If I install them *all* I don't need to use yum(i.e download it again) to install anything. Downloading *updates* is a different thing. I *update* my "everything" installation from rawhide every day.
I don't need a kickstart file.
I don't need to waste space on disk with rpms when I already have the package installed from the initial installation.
You waste disk space by installing packages you wouldnt use. You will to keep packages updated. Performance would do down with deamons and other session programs. You would be installing tons of world languages which you wouldnt be using and so on.
Wrong again! I use all the packages. Maybe not the way your mind thinks but I use them. Who are you to judge?
Hi
Which ones?
All of them, dummy. Duh! That is what we are talking about.
Can you stop name calling?. Lets keep this discussion technical. You install of the language packs and find them useful?. Thats not particular convincing as a general use case
What are you using your system for?. Is it a desktop/workstation/server/development system?. Doesnt it fit into one of these profiles?
No it doesn't fit into one of those "profiles". I am (and have been since FC1) using it for Test and Evaluation of SELinux. *One* of the things I am looking at is how well this pervasive technology integrates with a reasonable sized distribution/OS. Also, I'm trying to see what the maintenance burden is when a large number of programs/packages are in play. For example, what will it take to keep policy current for all the package changes coming through rawhide?
Yum.
This one is about *download*. see if you can follow this. All the rpms in Core get downloaded within the isos. If I install them *all* I don't need to use yum(i.e download it again) to install anything.
Yum can very well work with offline repositories. see the man page of creatrerepo. File a RFE against pirut to support this.
You waste disk space by installing packages you wouldnt use. You will to keep packages updated. Performance would do down with deamons and other session programs. You would be installing tons of world languages which you wouldnt be using and so on.
Wrong again! I use all the packages. Maybe not the way your mind thinks but I use them. Who are you to judge?
Merely trying to understand *general* use cases. Not personal preferences or trying to pass judgment. Lets keep this technical again.
Rahul Sundaram wrote:
Hi
<snip>
What are you using your system for?. Is it a desktop/workstation/server/development system?. Doesnt it fit into one of these profiles?
No it doesn't fit into one of those "profiles". I am (and have been since FC1) using it for Test and Evaluation of SELinux. *One* of the things I am looking at is how well this pervasive technology integrates with a reasonable sized distribution/OS. Also, I'm trying to see what the maintenance burden is when a large number of programs/packages are in play. For example, what will it take to keep policy current for all the package changes coming through rawhide?
Yum.
You misunderstood my concerns and what I am investigating. Let me try restating: Considering the rate of change in Core (as shown by the number of changes in rawhide) what part of those changes require changes to the policy sources to accommodate them. Dan Walsh and a few others seem to be able to keep up with the simplified "targeted" policy. But a large part of creating the modular approach seems to be to shift the creation and maintenance of policy to respective developers of each package/program. "Is that really a good approach", is one of my questions. Doogfooding rawhide is only a small part of what I'm doing and doing an everything install with "one click" saves me time.
That's part of my "use case". Call it a corner case if you like but remember that there are many others out there. The fact that the "everything" selection has been in RedHat at least since 7.0 and that it was put in in the first place should lend some credence to it's usefulness.
Let me know if I can be of any further assistance, Richard
Hi
You misunderstood my concerns and what I am investigating. Let me try restating: Considering the rate of change in Core (as shown by the number of changes in rawhide) what part of those changes require changes to the policy sources to accommodate them. Dan Walsh and a few others seem to be able to keep up with the simplified "targeted" policy. But a large part of creating the modular approach seems to be to shift the creation and maintenance of policy to respective developers of each package/program. "Is that really a good approach", is one of my questions. Doogfooding rawhide is only a small part of what I'm doing and doing an everything install with "one click" saves me time.
That's part of my "use case". Call it a corner case if you like but remember that there are many others out there.
Right thats a corner case. One that I use myself extensively but I am talking about end users. Not testers or developers. This discussion is my attempt to understand whether I can find useful scenarios where everything install makes sense for typical end users. I am involved with other efforts related to this that this discussion would help influence. Anyway, If anybody wants to discuss this further just mail me off list and keep the conversation sane. Thanks
On 1/23/06, Richard Hally rhally@mindspring.com wrote:
That's part of my "use case". Call it a corner case if you like but remember that there are many others out there. The fact that the "everything" selection has been in RedHat at least since 7.0 and that it was put in in the first place should lend some credence to it's usefulness.
And the fact that the developers who have been maintaining anaconda for use in rhl and fedora have felt that its a problem to maintain doesn't lend credence that that its the wrong technical solution? Or the fact that other users have filed bugreports asking for this feature to be removed because of their experience with associated security risks? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=16008 This is an OLD debate. For every person who has argued for its existence there have been people who have argued for it to be modified or removed... from the dawn of time.
Do you have an accurate accounting as to why it was put into place or are you just making assumptions? I personally like to think of the everything install option as a failed experiment. And I'm willing to graciously let the developers admit it was a mistake so they can move on free of shame and guilt over the entire history of its existance.
I think the developers/release team for all the releases between then and now are the only ones in a position to be able to really know why it was available to begin with. They are also the ones who have been dealing with bugreports about everything installs where different people have interpreted what "everything" is suppose to mean.. differently. And if you look over the changelog for the anaconda package, you'll see that over time the list of packages excluded in an everything install has changed. The history of the exclude list inside anaconda speaks for itself. There is a maintainence cost associated with keeping the everything install functional.
There is also an associated cost to overall userbase security by making it one-click simple for every user to install all software they do not use nor have any intention of using. I think you'll be very hardpressed to find an persuasive argument that would overcome the security arguments mattdm makes in that bugreport. I don't see the scales of justice swinging to defend desires for convenience for power users who have other means to accomplish what they want via less convenient methods over protection of naive users who innocently choose the install option without understanding the risks to security as presented by mattdm.
I've seen this movie, mattdm wins.
-jef On top of all this I think certain developers who are heavily involved with the installer have been making noises about removing the everything feature for a while now.... for over a year.
I will point out that certain maintainers have been telling people in bugreports
Richard Hally wrote:
Rahul Sundaram wrote:
Hi
Please explain what is good about the everything installation option. Dont throw around vague notions.
It saves me time when selecting packages to install.
Which ones?
All of them, dummy. Duh! That is what we are talking about.
It saves me time to not have to install packages individually.
What are you using your system for?. Is it a desktop/workstation/server/development system?. Doesnt it fit into one of these profiles?
No it doesn't fit into one of those "profiles". I am (and have been since FC1) using it for Test and Evaluation of SELinux. *One* of the things I am looking at is how well this pervasive technology integrates with a reasonable sized distribution/OS. Also, I'm trying to see what the maintenance burden is when a large number of programs/packages are in play. For example, what will it take to keep policy current for all the package changes coming through rawhide?
I don't have to download packages (via yum or whatever) that have already been downloaded in the isos.
You cant work with them using the current tools provided anyway. Thats what we are trying to fix already. If you dont use yum to keep yourself updated installing everything is dangareous since it brings in potential security issues with packages you wouldnt even use.
This one is about *download*. see if you can follow this. All the rpms in Core get downloaded within the isos. If I install them *all* I don't need to use yum(i.e download it again) to install anything. Downloading *updates* is a different thing. I *update* my "everything" installation from rawhide every day.
I don't need a kickstart file.
I don't need to waste space on disk with rpms when I already have the package installed from the initial installation.
You waste disk space by installing packages you wouldnt use. You will to keep packages updated. Performance would do down with deamons and other session programs. You would be installing tons of world languages which you wouldnt be using and so on.
Wrong again! I use all the packages. Maybe not the way your mind thinks but I use them. Who are you to judge?
I think the point has been made that some people want the "Everything" option and some don't, that's great, no how about we put this one to bed before it goes any futher. name calling is not needed, nor is it going to help your case any.
I say move on, and lets do some testing. isn't that what this is all about anyway?
Shalom! (Peace)
Jim
Rahul Sundaram wrote:
Hi
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
You(Rahul) still don't get it! It's not about "using them all together" at all. Yes, it is about installing "everything" in Core at one time(install time!) *easily*. It's a usability / easy-of-use issue. It's about giving users the choice. If they want to - let then.
Choice has associated cost. Implementing everything any user ever asked for will lead to a unmaintainable mess.
Let's see *your* cost/benefit analysis.
It saves me and many others time when selecting packages to install. It saves me and many others time to not have to install packages individually. I and many others don't have to download packages (via yum or whatever) that have already been downloaded in the isos. I and many others don't need a kickstart file. I and many others don't need to waste space on disk with rpms when I already have the packages installed from the initial installation.
Your "reductio ad absurdum" argument doesn't apply. We are talking about *one* "select all" feature.
Report number?
Search on "anaconda everything".
Thats not a number ;-)
The research is left as a learning experience for you. =:O
And what makes Rahul think he knows the difference better than others? (wink,wink)
Oh please guys. Listen before responding. I presented very detailed reasons why I think it is not a good thing.
And all those reasons are bogus and do not apply to the usability/ease of use of the package selection part of the installer.
Sure. Call them all bogus with no explanation. That doesnt look a appealing argument.
Your "reasons" are below in quotes: "* Dependency issues - One of the reasons behind doing a everything installation is avoid dealing with dependency issues. However that is largely not a problem now since yum install and yum groupinstall along with along programs like pirut. Refer to the yum guide available at http://fedora.redhat.com/docs "
Your "dependancies" reason does not apply to the question of whether a "select all" feature in the installer is useful. There are other reasons for doing an "everything" install. By not having a "select all" feature, it looks like you are trying to hide the symptoms of dependency problems.
"* Discoverability - Fedora Core like you indicate a large number of useful programs but the installer divides these into several different types to target particular segment of use cases and avoid having to a everything installation. Custom group and package selection is available for those who would like to do a granular installation. Even if all the packages of Fedora Core is installed it doesnt grant users immediate access to all the packages since the ones in Fedora Extras repository is not available at installation time. Though the installer itself is getting support for additional repositories the aspect of making these packages more visible to users is better handled through the use of tools such as pirut rather than having users install everything which they cant now anyway since the installation is limited to Fedora Core packages."
This reason is unrelated to the question of whether a "select all" option in the installer is useful. The problem of finding packages is much easier if they are "all" in one place(i.e. installed). see also 'rpm -qa | grep <whatever>', google, etc.
"* Redundancy - While Fedora Core itself is slowing moving towards providing more packages as part of the Fedora Extras and possibly doing several different targets the current selection uses multiple programs that provide the same functionality, browsers or desktop environments for example and its better for users to use a graphical tool like pirut and install packages as necessary."
There are users that want to compare the "redundant" programs. Who are you to say what is better for users? It is arrogant it assume you know more than the users.
"* Security, manageability and performance - As more and more packages are installed on a system the amount of updates and interactions between the packages that the user has to handle drastically increases. For users who are using Fedora as a development system or using it just to learn Linux where the system serves no other purpose and a high amount of bandwidth is available this might make sense but for others users who use it deploy it at various levels the amount of updates and potential security issues that they have to deal with packages that they might not even use is a additional burden. Moreover the additional packages installed might need listen to network connections by default making the systems potentially more vulnerable by increasing the attack vector. Additional services enabled by default also affect performance."
It is a "user choice" issue as to what trade offs users want to make regarding "Security, manageability and performance" ! If people want to install "everything" that is their choice and just trying to make it more difficult because you don't think it is a good idea is wrong.
Several people have already given you "use cases" but this is not about your opinion that an "everything" install is not useful.
Can you list them?
do your own homework.
It's about those users that want to do it (in spite of your opinion) being able to do it easily. Trying to make it difficult is just arrogance!
Depends on what you want to do and how useful it is. I still havent heard good use cases yet.
The sooner you realize that it is not your judgment of what I or other users want to do that counts, the smarter you will be.
Good luck to you and the Red Sox, Richard
Richard Hally wrote:
Rahul Sundaram wrote:
Hi
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
You(Rahul) still don't get it! It's not about "using them all together" at all. Yes, it is about installing "everything" in Core at one time(install time!) *easily*. It's a usability / easy-of-use issue. It's about giving users the choice. If they want to - let then.
Choice has associated cost. Implementing everything any user ever asked for will lead to a unmaintainable mess.
Let's see *your* cost/benefit analysis.
Not to anyone who rather would name call rather indulge in good discussions. This is not constructive.
On 1/23/06, Rahul Sundaram sundaram@redhat.com wrote:
Richard Hally wrote:
Rahul Sundaram wrote:
Hi
Thats too generic. Is all of the software thats available in core needed to be installed simultaneously and is using all of them together a common scenario?
You(Rahul) still don't get it! It's not about "using them all together" at all. Yes, it is about installing "everything" in Core at one time(install time!) *easily*. It's a usability / easy-of-use issue. It's about giving users the choice. If they want to - let then.
Choice has associated cost. Implementing everything any user ever asked for will lead to a unmaintainable mess.
Let's see *your* cost/benefit analysis.
Not to anyone who rather would name call rather indulge in good discussions. This is not constructive.
I haven't resorted to that, could I see your cost/benefit analysis please?
Hi
Let's see *your* cost/benefit analysis.
Not to anyone who rather would name call rather indulge in good discussions. This is not constructive.
I haven't resorted to that, could I see your cost/benefit analysis please?
When users ask for features the rationale is supplied by them. However I have already presented by ideas
* Everything installation installs every package including all the language package that is definitely not going to be useful for anyone in the same time. There is obsoletely no requirement to install all the language packages except the l10N QA team which is a corner case * Everything installation is not really everything since it doesnt support additional repos like Fedora Extras yet during installation * It adds increase burden of manageability (just look at GFS kernel module issues in FC4 as a prominent example of how many users ran into a unnecessary issue even though they werent using GFS or werent aware of it just because they did a everything installation) * The local and remote vulnerability potential increases due to the amount of updates that that user has to install * For dialup users keep their system updated can be even more harder due to unnecessary packages * Performance of the system can go down to unnecessary services and session programs
Better package management has resulted in much more flexibility post installation to install software on demand. Not enough good use cases in support for a everything installation has been presented. So if you want to lobby for a particular feature kindly present additional reasons why it is being required for end users who wouldnt be able to use kickstart, select particular groups during installation, pirut or put post installation. When Fedora Core reduces in size, everything installation might be more of a feasible option. Just that some users want it is not a good reason to implement any feature without understanding the cost involved in long term maintenance and support.
On 1/23/06, Rahul Sundaram sundaram@redhat.com wrote:
Hi
Let's see *your* cost/benefit analysis.
Not to anyone who rather would name call rather indulge in good discussions. This is not constructive.
I haven't resorted to that, could I see your cost/benefit analysis please?
When users ask for features the rationale is supplied by them. However I have already presented by ideas
- Everything installation installs every package including all the
language package that is definitely not going to be useful for anyone in the same time. There is obsoletely no requirement to install all the language packages except the l10N QA team which is a corner case
- Everything installation is not really everything since it doesnt
support additional repos like Fedora Extras yet during installation
- It adds increase burden of manageability (just look at GFS kernel
module issues in FC4 as a prominent example of how many users ran into a unnecessary issue even though they werent using GFS or werent aware of it just because they did a everything installation)
- The local and remote vulnerability potential increases due to the
amount of updates that that user has to install
- For dialup users keep their system updated can be even more harder due
to unnecessary packages
- Performance of the system can go down to unnecessary services and
session programs
Better package management has resulted in much more flexibility post installation to install software on demand. Not enough good use cases in support for a everything installation has been presented. So if you want to lobby for a particular feature kindly present additional reasons why it is being required for end users who wouldnt be able to use kickstart, select particular groups during installation, pirut or put post installation. When Fedora Core reduces in size, everything installation might be more of a feasible option. Just that some users want it is not a good reason to implement any feature without understanding the cost involved in long term maintenance and support.
I'm sorry, my question was "Can I see your cost/benefit analysis please?"
Hi
I'm sorry, my question was "Can I see your cost/benefit analysis please?"
I guess you didnt read my response.
On 1/23/06, Rahul Sundaram sundaram@redhat.com wrote:
Hi
I'm sorry, my question was "Can I see your cost/benefit analysis please?"
I guess you didnt read my response.
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
I read it, I just didn't see the cost of have a "install everything from core" option. You talk about how much effort it would be, I'm interested in knowing where the cost is.
Thanks
Hi
I read it, I just didn't see the cost of have a "install everything from core" option. You talk about how much effort it would be, I'm interested in knowing where the cost is.
The cost is long term maintenance. I specifically cited the GFS module issue as an example. Its NOT just cost of coding the feature.
On 1/23/06, Rahul Sundaram sundaram@redhat.com wrote:
The cost is long term maintenance. I specifically cited the GFS module issue as an example. Its NOT just cost of coding the feature.
Sure its not, it never is, but how much is that cost? For example, you been defending your decision for 4 days or so now, and it shows no sign of ending. My suspicion is that this is nothing compared to the discussions that will arise when FC5 goes live.
BTW, was it solely your decision to remove the option? I can see you have support, but who is the final arbiter?
Thanks for your input. It is obvious that you are taking a lot of flak for this, but I do value the work that you have put into Fedora. I think the pirut interface is much better than what was available before, for which the developers deserve much credit. Its just that for me, and many others, the benefit of the better interface does not outweigh the functionality provided by previous releases.
gb spam wrote:
On 1/23/06, Rahul Sundaram sundaram@redhat.com wrote:
The cost is long term maintenance. I specifically cited the GFS module issue as an example. Its NOT just cost of coding the feature.
Sure its not, it never is, but how much is that cost?
Like I said, as someone on the receiving end this cost is very high.
For example, you been defending your decision for 4 days or so now, and it shows no sign of ending. My suspicion is that this is nothing compared to the discussions that will arise when FC5 goes live.
Thats fine. I have been answering a lot many mails in fedora-list than here
BTW, was it solely your decision to remove the option? I can see you have support, but who is the final arbiter?
Developers of the packagers usually decide on the feature set to implement or prioritize on.
Thanks for your input. It is obvious that you are taking a lot of flak for this, but I do value the work that you have put into Fedora. I think the pirut interface is much better than what was available before, for which the developers deserve much credit. Its just that for me, and many others, the benefit of the better interface does not outweigh the functionality provided by previous releases.
File RFE's in http://bugzilla.redhat.com, fedora-devel: pirut
On 1/24/06, shrek-m@gmx.de shrek-m@gmx.de wrote:
Rahul Sundaram wrote:
I guess you didnt read my response.
please stop this never ending thread or move it to bugzilla, wiki, ...
Don't place it in bugzilla -- it will linger there forever... -- WC -Sx- Jones | http://ccsh.us/ | Open Source Consulting
Chasecreek Systemhouse wrote:
On 1/24/06, shrek-m@gmx.de shrek-m@gmx.de wrote:
Rahul Sundaram wrote:
I guess you didnt read my response.
please stop this never ending thread or move it to bugzilla, wiki, ...
Don't place it in bugzilla -- it will linger there forever...
If it lingers there forever help in triaging or post to fedora-devel list for major blockers or regressions. Bugzilla as a tracking system is much more efficient than mailing lists.
--- Rahul Sundaram sundaram@redhat.com wrote:
Hi
Let's see *your* cost/benefit analysis.
Not to anyone who rather would name call rather
indulge in good
discussions. This is not constructive.
I haven't resorted to that, could I see your
cost/benefit analysis please?
When users ask for features the rationale is supplied by them. However I have already presented by ideas
- Everything installation installs every package
including all the language package that is definitely not going to be useful for anyone in the same time. There is obsoletely no requirement to install all the language packages except the l10N QA team which is a corner case
- Everything installation is not really everything
since it doesnt support additional repos like Fedora Extras yet during installation
- It adds increase burden of manageability (just
look at GFS kernel module issues in FC4 as a prominent example of how many users ran into a unnecessary issue even though they werent using GFS or werent aware of it just because they did a everything installation)
- The local and remote vulnerability potential
increases due to the amount of updates that that user has to install
- For dialup users keep their system updated can be
even more harder due to unnecessary packages
- Performance of the system can go down to
unnecessary services and session programs
Better package management has resulted in much more flexibility post installation to install software on demand. Not enough good use cases in support for a everything installation has been presented. So if you want to lobby for a particular feature kindly present additional reasons why it is being required for end users who wouldnt be able to use kickstart, select particular groups during installation, pirut or put post installation. When Fedora Core reduces in size, everything installation might be more of a feasible option. Just that some users want it is not a good reason to implement any feature without understanding the cost involved in long term maintenance and support.
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
I am following this thread closely and I can see the pro's and con's. Many times, the everything install is the best way to go. You do not want to have to install any missing dependencies via yum/rpm when you want to compile a certain tarball for which there is no rpm available, or there is one, but in your system it *does not work*. The security risks are something that we could live without. In fact many people do not update the kernel to the latest one, despite several vulnerabilities that they keep their existing kernel because it boots everytime and many things just work.
For example in FC4, the default package KDVI (KDE Graphics) was broken, when you opened a DVI file, KDVI told you that the file was corrupt. Being on dialup, yum update kde-graphics took about 2 to 3 hours at the time. I updated it on one of my home machines. I read about the vulnerability and I knew I had to install it. On the other machine, I changed the kile configuration to use xdvi package and forget about kdvi error.
This are some of the things that we can live with. I am well aware of vulnerabilites, and understand why install everything all those languages that I am not going to use and I agree with that part. But the everything install is much easier and faster to do and saves time and effort when solving dependencies on installing other software. It is a double edged sword but I strongly agree that the everything option should be kept there because we are used to it, it was a part of the old red hat 8.0, red hat 9.0, Fedora Core 1, 2, 3 and 4. I know things change, but why change something that has been there and people feel comfortable with it. *Also keep the new changes they are awesome too* but that "Custom Install" Everything Install is missing.
Just that some users want it is not a good reason to implement any feature without understanding the cost involved in long term maintenance and support.
What does that magic button(s) cost to implement when it has been living there for sometime already? The changes are welcomed, but what has been the cost and long term maintence and support have been throughout the Fedora Release cycles?
Why is Fedora trying to reduce the Core? Why is wanting to become like Ubuntu? Fedora is great as it is! Why change it to less CD's, and us having to search for packages that are and have been there for ages.
Sorry to get involved, but I felt the need.
Best Regards,
Antonio
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi
I am following this thread closely and I can see the pro's and con's. Many times, the everything install is the best way to go. You do not want to have to install any missing dependencies via yum/rpm when you want to compile a certain tarball for which there is no rpm available, or there is one, but in your system it *does not work*.
Just you use yum and pirut post installation. They should work with CD/DVD's too.
The security risks are something that we could live without. In fact many people do not update the kernel to the latest one, despite several vulnerabilities that they keep their existing kernel because it boots everytime and many things just work.
We need to discourage anything that creates security issues.
Just that some users want it is not a good reason to implement any feature without understanding the cost involved in long term maintenance and support.
What does that magic button(s) cost to implement when it has been living there for sometime already? The changes are welcomed, but what has been the cost and long term maintence and support have been throughout the Fedora Release cycles?
It costs quite a lot which is why it is being removed. I already gave examples of this.
Why is Fedora trying to reduce the Core? Why is wanting to become like Ubuntu? Fedora is great as it is! Why change it to less CD's, and us having to search for packages that are and have been there for ages.
Why do you think reducing core is equal to reduce CD images. They are not related at all.
--- Rahul Sundaram sundaram@redhat.com wrote:
Hi
I am following this thread closely and I can see
the
pro's and con's. Many times, the everything
install
is the best way to go. You do not want to have to install any missing dependencies via yum/rpm when
you
want to compile a certain tarball for which there
is
no rpm available, or there is one, but in your
system
it *does not work*.
Just you use yum and pirut post installation. They should work with CD/DVD's too.
The security risks are something that we could live without. In fact many people do not update the kernel to the latest one, despite several vulnerabilities that they keep their
existing
kernel because it boots everytime and many things
just
work.
We need to discourage anything that creates security issues.
Just that some users want it is not a good reason to implement any feature without understanding the cost involved in long term maintenance and support.
What does that magic button(s) cost to implement
when
it has been living there for sometime already?
The
changes are welcomed, but what has been the cost
and
long term maintence and support have been
throughout
the Fedora Release cycles?
It costs quite a lot which is why it is being removed. I already gave examples of this.
Why is Fedora trying to reduce the Core? Why is wanting to become like Ubuntu? Fedora is great as
it
is! Why change it to less CD's, and us having to search for packages that are and have been there
for
ages.
Why do you think reducing core is equal to reduce CD images. They are not related at all.
I see this occur in other distros too. They reduce the number of packages and/or exclude packages that were helpful but now removed them because of other people who wanted something else.
I'll put some examples.
* Take Knoppix for instance. Knoppix had tetex, tetex-latex, kdvi, xdvi packages up to version 3.3 after which it dropped becuase of the space issue. Klaus Knopper said that because of space constraints he reduced it. I liked knoppix because it had this feature. I could tex/latex a document virtually everywhere I could boot off live cd.
* I had to find a replacement. and there was Kanotix. very similar to Knoppix an make by Kano "Jorg S". Now as of today the version Kanotix-2005-04 removed tetex completely from the live cd distribution.
* I have found Team-TL, a slax live cd, slackware based live cd/dvd which has what I want and they are specialized. It is nice and it works. I can take tex/latex anywhere.
Take also Mandriva ( formerly Mandrake), they give out 3 cd's only, they want you to pay into their Club to get the other stuff. They include that it is a download edition.
Fedora Core comes with 4 cd's + 1 rescue cd and we can also get it as a dvd.iso. Fedora is a completely free operating system free of proprietary stuff and patents and you stand by it completely.
As you stand by it, we and others stand by our we want "everything install back". We do not care about security issues. we care to install everything in a faster way that way we do things faster and run great risks as you and others have suggested.
It costs quite a lot which is why it is being removed.
Why did it not cost a lot before?
What triggered the rapid changes?
As I have said before I welcome some of the changes implemented in this Fedora Core 5 Test 2 Releease. I like them, but still like the everything install.
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi
Fedora Core comes with 4 cd's + 1 rescue cd and we can also get it as a dvd.iso. Fedora is a completely free operating system free of proprietary stuff and patents and you stand by it completely.
As you stand by it, we and others stand by our we want "everything install back". We do not care about security issues.
Fedora which has invested so much effort into security has to continue discouraging potential security issues. Just because some users think security doesnt matter doesnt change this policy.
Why did it not cost a lot before?
What triggered the rapid changes?
See anaconda list archives. The changes are not rapid at all. It has been discussed for months before
--- Rahul Sundaram sundaram@redhat.com wrote:
Hi
Fedora Core comes with 4 cd's + 1 rescue cd and we
can
also get it as a dvd.iso. Fedora is a completely
free
operating system free of proprietary stuff and
patents
and you stand by it completely.
As you stand by it, we and others stand by our we
want
"everything install back". We do not care about security issues.
Fedora which has invested so much effort into security has to continue discouraging potential security issues. Just because some users think security doesnt matter doesnt change this policy.
I like this. This is great. Security does matter. but considering the threats out there, what is the probability that your machine(home machine) will get compromised?
I do care about security issues and I am rethinking what you are telling me, but say you are not going to connect that machine with the everything install to the internet. You just want it for your nephews/nieces to play games/word process, listen to music, watch movies, etc. How is the "everything installed" gonna hurt here with security?
Now the thing changes a little if you have a server running and that machine gets connected to the internet with a fast connection, then it does matter so I get your point. You need to have it constantly updating, otherwise your system could become compromised.
Best Regards,
Antonio
Why did it not cost a lot before?
What triggered the rapid changes?
See anaconda list archives. The changes are not rapid at all. It has been discussed for months before
-- Rahul
Fedora Bug Triaging - http://fedoraproject.org/wiki/BugZappers
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi
I like this. This is great. Security does matter. but considering the threats out there, what is the probability that your machine(home machine) will get compromised?
My home system is really irrelevant to the conversation but if you mean in general user home systems then there is a good amount of potential there.
I do care about security issues and I am rethinking what you are telling me, but say you are not going to connect that machine with the everything install to the internet. You just want it for your nephews/nieces to play games/word process, listen to music, watch movies, etc. How is the "everything installed" gonna hurt here with security?
Any belief that security is only important in the networked systems and home users dont need it is invalid. That kind of sloppy thinking would cause way too many problems. You will continue to see increased security focus on providing home user desktops through efforts like SELinux.
Now the thing changes a little if you have a server running and that machine gets connected to the internet with a fast connection, then it does matter so I get your point. You need to have it constantly updating, otherwise your system could become compromised.
Security is not exclusive for servers. It in increasingly important for the desktops too. Its relatively hard problem since servers are highly targeted compared to desktops but doesnt mean we should just give up and not care about that particular segment of the Fedora user base.
On Mon, 23 Jan 2006, Rahul Sundaram wrote:
goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
is the cost of an 'everything' button really so unreasonably high?
Yes it is. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html
no, it's not. i took the time to check out that post and it most emphatically *doesn't* demonstrate that an "everything" button has an associated "cost." let me just use the first bullet point on that page as an example:
"* Dependency issues - One of the reasons behind doing a everything installation is avoid dealing with dependency issues. However that is largely not a problem now since yum install and yum groupinstall along with along programs like pirut. Refer to the yum guide available at http://fedora.redhat.com/docs"
note well that what that point shows is that an everything install may not have as compelling reason for *existence* as it once did, and i'm certainly willing to grant that. but it most certainly does *not* show that it has a "cost." there's a difference.
more to the point, it cannot *possibly* have an associated "cost" since you can emulate it simply by selecting all of the check boxes on the screen.
i have no problem with people arguing against an "everything" install. but, please -- don't make up bogus arguments to bolster your case.
rday
p.s. i can appreciate the argument that calling it "everything" may confuse users who aren't sure if that means everything they can currently see, or absolutely everything imaginable. fine. so call it "all of the above" -- that solves the problem.
in any event, there may be reasons why an "everything" install isn't as important a feature as it once was. but it doesn't appear to have an actual "cost" associated with it, and it clearly doesn't do any actual harm. so let's not make those arguments, ok?
Hi
note well that what that point shows is that an everything install may not have as compelling reason for *existence* as it once did, and i'm certainly willing to grant that. but it most certainly does *not* show that it has a "cost." there's a difference.
Of course it does. How many users have you supported that end dealing with the GFS kernel module issue in FC4 just because they did a everything installation and had no clue what GFS mean and wouldnt have installed had it not the installation supported a everything installation?. I remember dealing with in #fedora, fedora list. fedora forum and in person atleast three dozen times. In every single instance that I was able to discuss this in detail with them they agreed they were doing it out of ignorance about the issues involved.
more to the point, it cannot *possibly* have an associated "cost" since you can emulate it simply by selecting all of the check boxes on the screen.
You are working around something that shouldnt be really required for end users at all who wouldnt use kickstart, yum or pirut.
i have no problem with people arguing against an "everything" install. but, please -- don't make up bogus arguments to bolster your case.
Please make your case *in support of it* more just that you want it without providing any good reasons. I have asked for it so many times already
in any event, there may be reasons why an "everything" install isn't as important a feature as it once was. but it doesn't appear to have an actual "cost" associated with it, and it clearly doesn't do any actual harm. so let's not make those arguments, ok?
It has so many manageability, performance and potential security issues with packages they wouldnt be using. Did you actually read my entire rationale against it?
On Mon, 2006-01-23 at 05:39 +0530, Rahul Sundaram wrote:
Hi
note well that what that point shows is that an everything install may not have as compelling reason for *existence* as it once did, and i'm certainly willing to grant that. but it most certainly does *not* show that it has a "cost." there's a difference.
Of course it does. How many users have you supported that end dealing with the GFS kernel module issue in FC4 just because they did a everything installation and had no clue what GFS mean and wouldnt have installed had it not the installation supported a everything installation?. I remember dealing with in #fedora, fedora list. fedora forum and in person atleast three dozen times. In every single instance that I was able to discuss this in detail with them they agreed they were doing it out of ignorance about the issues involved.
Lack of an "Everything" button won't solve that particular problem, the hunter-gatherers among those who can't help themselves (who just have to have everything because it's there, the same clientele likely to fall prey to "1001 hidden secrets of Windows" if they were on a different OS, ...) will just click all them checkboxes, have the GFS kernel module problem and still complain that they wore out their mouses because the installer sucks ;-). Honestly: the (GFS) kernel module problem shouldn't be solved in the installer. Some people will always install stuff they don't need just because it's there.
more to the point, it cannot *possibly* have an associated "cost" since you can emulate it simply by selecting all of the check boxes on the screen.
You are working around something that shouldnt be really required for end users at all who wouldnt use kickstart, yum or pirut.
I don't think he was talking about end users at all. From fedora.redhat.com/about/objectives.html:
""" Objectives of Fedora Core:
1. Create a complete general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community — those who not only consume, but also produce for the good of other community members. """
I would argue that this means that "power users", developers and testers are very much a target audience of Fedora. Again, I'd like to emphasize that the problem to me isn't the lack of "Everything" per se but the deficiencies of the current package selector when it comes to selecting stuff beyond what someone deemed worthy to be default ;-). If the groups and subgroups UI had an easy way to "give me all that cruft within and forget about disk space and bandwidth" I wouldn't complain and others probably neither.
i have no problem with people arguing against an "everything" install. but, please -- don't make up bogus arguments to bolster your case.
Please make your case *in support of it* more just that you want it without providing any good reasons. I have asked for it so many times already
Instead of the "Everything" install, I'll try to make the case for bulk selections as outlined above, note that in some cases this relates to perceived rather than actual need:
1) Testers who want to test every corner of the system. 2) Some of 1) might even be journalists and fair share of them labels things missing if they can't find them or missed to install them. Or so it seems to me. 3) The survivalist type: Mobile users/developers/... who'd rather waste some disk space than find themselves having something not installed when they're away from net access. 4) Hunter-gatherers who want everything under the sun just because it exists and no you won't make them behave with rational arguments. 5) Number 4) light, if they install on a spare machine to "browse" the new version in order to decide what they actually need. Rarely seen ;-).
in any event, there may be reasons why an "everything" install isn't as important a feature as it once was. but it doesn't appear to have an actual "cost" associated with it, and it clearly doesn't do any actual harm. so let's not make those arguments, ok?
It has so many manageability, performance and potential security issues with packages they wouldnt be using. Did you actually read my entire rationale against it?
First, software just installed usually should only cause updates to take longer. If we distribute software, it'd better be secure. Nevertheless we shouldn't enable to many daemons by default, rather have the users activate them if they need them. The issues you bring up can be handled differently than by not installing specific software IMO.
Nils
Hi
Instead of the "Everything" install, I'll try to make the case for bulk selections as outlined above, note that in some cases this relates to perceived rather than actual need:
- Testers who want to test every corner of the system.
Enable the option only during test/devel releases and disable them in the GA release.
- Some of 1) might even be journalists and fair share of them labels
things missing if they can't find them or missed to install them. Or so it seems to me. 3) The survivalist type: Mobile users/developers/... who'd rather waste some disk space than find themselves having something not installed when they're away from net access.
Improve the post installation package management to be flexible so that it can offer to install packages from CD/DVD.
- Hunter-gatherers who want everything under the sun just because it
exists and no you won't make them behave with rational arguments.
We shouldnt be designing Fedora for corner cases just because users dont listen to rational arguments.
- Number 4) light, if they install on a spare machine to "browse" the
new version in order to decide what they actually need. Rarely seen ;-).
So admittedly a corner case.
First, software just installed usually should only cause updates to take longer. If we distribute software, it'd better be secure. Nevertheless we shouldn't enable to many daemons by default, rather have the users activate them if they need them. The issues you bring up can be handled differently than by not installing specific software IMO.
True but I dont see much traction in cutting down the number of services and everything installation definitedly brings in a number of unnecessarily services. If you want to help, refer to http://fedoraproject.org/wiki/DefaultServices
On 1/26/06, Rahul Sundaram sundaram@redhat.com wrote:
- Testers who want to test every corner of the system.
Enable the option only during test/devel releases and disable them in the GA release.
No, that can't be done. Rahul has stated that the cost associated with the option is too high.
gb spam wrote:
On 1/26/06, Rahul Sundaram sundaram@redhat.com wrote:
- Testers who want to test every corner of the system.
Enable the option only during test/devel releases and disable them in the GA release.
No, that can't be done. Rahul has stated that the cost associated with the option is too high.
Are you deliberately doing this or is this just a misunderstanding?. I said the cost of supporting this option for end users is high. I am sure you would agree that testers and developers are not the typical end users.
Hi, Please stop. NOW.
I could have missed someone, but so far I have counted only 6 messages from people who actually develop Anaconda in this endless thread. None of the messages was talking about the "everything" option.
Do you really think this thread can accomplish something? Mirek
On Mon, 2006-01-23 at 05:11 +0530, Rahul Sundaram wrote:
goemon@anime.net wrote:
On Sun, 22 Jan 2006, Rahul Sundaram wrote:
Though I am not a developer I already presented what I believe to be compelling arguments against it. Remember again that every feature has a associated cost.
is the cost of an 'everything' button really so unreasonably high?
Yes it is. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01138.html
In that post, you're outlining why you think an Everything install isn't needed, but I somehow fail to see anything pertaining to cost there.
I would say that because the code was there already (for quite a while), didn't cause any problems to me and possibly several others (otherwise), the cost of having it would have to be almost zero, the most of it would be to hide that option from the uninitiated.
If we see the package selection as a tree of groups, subgroups and detailed packages, "Everything" is "just" the root node of that tree. The real problem to me is that at the moment it needs numerous clicks to select anything beyond a subgroup with its default packages
Some of us dislike clicking jillions of buttons on every install. This seems a step backwards for FC.
Use kickstart, post installation yum or click on maybe 6 groups or let me know the different use cases where end users would need it.
Currently, kickstart is not an option installations of a single or few machines, the learning curve is too steep and effort to create a working kickstart file to high. Besides, if you want to convince other people of free software, you'd better show them a shiny, glitzy installer right away, not some cryptic installation script. And trust me, you do want these people to have everything on their machine, among other reasons because it's you who will be asked questions if they don't find something (and you don't want to teach them installing packages over the phone).
Post installation yum is the best alternative suggested so far -- even I only want Everything minus all if only it could cope with the installation media already downloaded.
Nils
Can you explain to me a few different use cases which makes it a good argument to be available by default other than selecting package groups, kickstart and using yum . Please explain with rationale instead of just stating your preference.
I install to my laptop and travel often without internet access.
It's not uncommon for me to want some particular tool which isn't automatically installed, and it's very frustrating if I'm on the road and don't have the tool(s) that I want.
I'm afraid of missing a tool during install that I might have a need for on the road, so an 'everything' install is nice. (Not to mention that it gets old in a hurry having to discover which tools are missing and installing them as I discover them.)
-Ed
On 1/22/06, Edwin Olson eolson@mit.edu wrote:
I'm afraid of missing a tool during install that I might have a need for on the road, so an 'everything' install is nice. (Not to mention that it gets old in a hurry having to discover which tools are missing and installing them as I discover them.)
In the future, when/if cds for fedora Extras are available. Are you going to be installing everything for Core+Extras at install time?
In the future, when anaconda gains support for arbitrary repository definitions are you going to be attempting "everything" installs for Core+Extras+3rd party repos on the network at installtime?
-jef
In the future, when/if cds for fedora Extras are available. Are you going to be installing everything for Core+Extras at install time?
Clearly my intent by selecting "everything" is that I want the installer to google for ".tgz", download, build, and install all the results. Oh, and I want every version of gcc that has ever existed. :)
Kidding aside, I appreciate the problem you're indicating. To clarify: My intent, when I say "everything", isn't "everything". It's "everything" as known on FC4, at least approximately. Perhaps a different term would be better ("thorough", "comprehensive", "swiss-army knife"?)
I find that the workstation/server "profiles" don't really fit me that well. My recollection is that you get to "pick one" and then modify it. Maybe a good compromise would be to allow the user to "check off" multiple profiles which fit the user's needs. I could select all workstation *and* server tools, for example, and my install would then be the union of the two profiles.
Addressing the second half of my problem, perhaps one of these profiles could be "Useful but less-often used utilities", kind of a catch-all for stuff like 'nc', 'lsusb'... Perhaps there's criteria limiting those packages which qualify for this profile, such as size. I suspect that a handful of these types of "profiles" could be fairly easily conjured up, and would satisfy most of the users who want an "everything-ish" option.
-Ed
Hi
I find that the workstation/server "profiles" don't really fit me that well. My recollection is that you get to "pick one" and then modify it. Maybe a good compromise would be to allow the user to "check off" multiple profiles which fit the user's needs. I could select all workstation *and* server tools, for example, and my install would then be the union of the two profiles.
Are there are packages in these profiles which shouldnt be there? Are there packages in the Fedora Core which fits into these profiles but are not there?. If these cases are common then they need to be added there. If they are unusual you can use kickstart.
Addressing the second half of my problem, perhaps one of these profiles could be "Useful but less-often used utilities", kind of a catch-all for stuff like 'nc', 'lsusb'... Perhaps there's criteria limiting those packages which qualify for this profile, such as size. I suspect that a handful of these types of "profiles" could be fairly easily conjured up, and would satisfy most of the users who want an "everything-ish" option.
Yes it requires more work addressing these profiles and tuning. Perhaps you can help in that using the comps work related bugzilla reports pointed out earlier. Anaconda lists might be a good place if its require a large amount of discussions.
On 1/22/06, Edwin Olson eolson@mit.edu wrote:
I find that the workstation/server "profiles" don't really fit me that well. My recollection is that you get to "pick one" and then modify it. Maybe a good compromise would be to allow the user to "check off" multiple profiles which fit the user's needs. I could select all workstation *and* server tools, for example, and my install would then be the union of the two profiles.
This sounds very much like what the comps groupings try to address. Figuring out which comps groups should be defined and where in the comps groups specific packages should go, is non-trivial and requires thought and review.
Here's the fascinating bit, in the future when/if anaconda gains support for using arbitrary repos, repos could provide only comps grouping information which provides specialized comps groupings which differ from the comps in Core without providing a single additional package. You could very well see specialized profiles being offered by community which redefine the available groups to offer you some different options.
My point is, the catchall "everything" button which has lived as special UI outside of the grouping definitions, is going to be ill-defined in future releases when support for repositories other than Core is exposed in the installer. Instead of trying to layer functionality into the specialized everything install button which tries to figure out if you mean everything in Core or everything in Core+Extras or everything in Core+Extras+other repos... the functionality can be wrapped into how comps is handled with effort.
-jef
On Sun, 22 Jan 2006, Jeff Spaleta wrote:
My point is, the catchall "everything" button which has lived as special UI outside of the grouping definitions, is going to be ill-defined in future releases when support for repositories other than Core is exposed in the installer. Instead of trying to layer functionality into the specialized everything install button which tries to figure out if you mean everything in Core or everything in Core+Extras or everything in Core+Extras+other repos...
ok, i can see that logic there. i think that one of the appealing features of the "everything" selection is that it was great for people who really weren't sure what some of the package categories meant and figured they'd just play it safe and grab everything. then they could take their time and figure it out later.
if "everything" disappears, i think you *really* want to make sure there's install-time help available to make sure people can figure out what a category means. (yes, i realize they can always install extra stuff later, but novice users are *always* going to be nervous that they're going to screw up an install if they forget something.)
rday
Hi
if "everything" disappears, i think you *really* want to make sure there's install-time help available to make sure people can figure out what a category means. (yes, i realize they can always install extra stuff later, but novice users are *always* going to be nervous that they're going to screw up an install if they forget something.)
Yes. Give a howler if you see pot entail docs missing in the installation guide and release notes.
On 1/22/06, Edwin Olson eolson@mit.edu wrote:
I install to my laptop and travel often without internet access.
It's not uncommon for me to want some particular tool which isn't automatically installed, and it's very frustrating if I'm on the road and don't have the tool(s) that I want.
I'm afraid of missing a tool during install that I might have a need for on the road, so an 'everything' install is nice. (Not to mention that it gets old in a hurry having to discover which tools are missing and installing them as I discover them.)
For travelling, I would suggest making a local copy of the CDs. That way you can use yum to install packages you are missing but aren't wasting the disk space for all the installed packages.
- Ian
On Sun, 2006-01-22 at 10:35 -0800, Ian Burrell wrote:
For travelling, I would suggest making a local copy of the CDs. That way you can use yum to install packages you are missing but aren't wasting the disk space for all the installed packages.
Well, but I'd waste disk space for all the package files I haven't installed and those I have installed because I surely won't go through sorting the latter out when I copy the CDs.
Nils
On 1/22/06, Robert P. J. Day rpjday@mindspring.com wrote:
what's unfortunate is your condescending attitude towards folks who are pointing out that they *like* the concept of an everything install. that would include folks like *me*, by the way. does that mean you're going to insult me as well?
Most likely, since you seem to be easily insulted, I'll probably be unable to avoid it. My mere existence might be an insult to you. It's difficult for me to gauge how thin-skinned you are without implementing a destructive test. And destructive tests are messy.
ah. in other words, you're *going* to support an "everything" install, you're just going to make it way more inconvenient than it used to be.
Shrug... I'm not going to do anything with regard to the one button solution.. other than work on problems that have a larger benefit. Working on getting Core packages into comps groupings coherently has benefit beyond the issue of the one true install button of power. It impacts not only the flexibility of the install, but also the flexibility of post-install package management. if I stopped to pick a fight over each and every feature change which was less "less convenient" for me in the near term, in each and every piece of open source software that I use.. I'd be doing nothing but complaining and very very little active contribution. Having a one-sided argument with a software maintainer seldom leads to them changing their mind.
Oh and I happen to think an everything install is an absolutely great idea long term for Core. You drop in the Core installer media and you get no packaging selection choices at all. You get everything. Of course in my future Core is a much less flexible set of packages and there are several other specially purposed Fedora mediasets which compliment Core.
-jef"I refuse to use Fedora until the tea timer gnome applet is back in Core!!!!!!!!!!!!!"spaleta
On Sun, 2006-01-22 at 10:28 -0500, Jeff Spaleta wrote:
On 1/22/06, gb spam gbofspam@gmail.com wrote:
We value everything installs, it works for us and jumping through hoops (write web apps; managing kickstart files; using kickstart during installs - does it still not tell you if it can't load the ks file until you get to a point in the install where your options haven't been selected?) is "less convenient" than clicking a check box during install.
So let me get this straight.. nothing other than a single check box during install is going to satify you? There is no room to compromise? You've drawn the line in the sand and you are holding your breath? That's unfortunate.
Some of us, are working with the maintainers to identify which packages are not incorporated into the comps grouping structure correctly so that the functionality of the install all button will essentially be duplicate by selecting all displayed packages in all displayed groups during the install process.
Hmm: Are you really implying (I don't think so) that browsing all the groups, going into the details for each of them, selecting all the optional packages is somehow equivalent to clicking one checkbox? Well, maybe in the outcome but definitely not in terms of time consumed and wear and tear on fingers, mouse buttons, etc. ;-). I guess if we had a means of selecting none/recommended/all packages for specific groups/subgroups with a single click, they amount of complaints would be drastically reduced.
Nils
On Sun, 2006-01-22 at 19:38 +0530, Rahul Sundaram wrote:
manually for the test/devel releases which is limited. If you must use a everything installation on unusual occasions then kickstart is powerful enough to manage that and tons more. If you can work on making kickstart profile generation in a web interface and similar things easier apart from the system-config-kickstart GUI tool I would welcome that. Work is already being done to document kickstart capabilities better in the installation guide.
Requiring kickstart abilities to achieve that is a bit over the top, don't you think? I don't think we want to put the hurdles much higher than the "yum --exclude=*-debuginfo* install *" if we want people to test Fedora Rawhide (and we would effectively do it if we e.g. documented the kickstart but not the yum way).
Nils
2006/1/26, Nils Philippsen nphilipp@redhat.com:
On Sun, 2006-01-22 at 19:38 +0530, Rahul Sundaram wrote:
manually for the test/devel releases which is limited. If you must use a everything installation on unusual occasions then kickstart is powerful enough to manage that and tons more. If you can work on making kickstart profile generation in a web interface and similar things easier apart from the system-config-kickstart GUI tool I would welcome that. Work is already being done to document kickstart capabilities better in the installation guide.
Requiring kickstart abilities to achieve that is a bit over the top, don't you think? I don't think we want to put the hurdles much higher than the "yum --exclude=*-debuginfo* install *" if we want people to test Fedora Rawhide (and we would effectively do it if we e.g. documented the kickstart but not the yum way).
Nils
Nils Philippsen / Red Hat / nphilipp@redhat.com"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
in my opinion everything install should definitely available since it helps with testing aswell doesent it?
and generally... we "everything installers" test alot more aspects of the system. i wouldnt want to see that option removed personally.
just my personal opinion.
regards, Rudolf Kastl
Linux Counter (li.counter.org) #386711 wrote:
I just ftp'd the 5 disks, and put it on my system. Firstly, the installer sucks. Graphical only displays the top left corner of the screen, showing none of the useful information. I had to use text, which was completely garbled. Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages. I decided to use add/remove packages. This crashed pretty much immediately. I'm stuck with a pile of minimal non-working crud. FC4T2 was SOOOO much better. Hope to see you in final.
poly-p man
We very well for me, text and graphical.
As for installing everything, I do not like to do that. It takes the fun out of learning and experimenting with things.
~WILL~
CodeHeads wrote:
Linux Counter (li.counter.org) #386711 wrote:
I just ftp'd the 5 disks, and put it on my system. Firstly, the installer sucks. Graphical only displays the top left corner of the screen, showing none of the useful information. I had to use text, which was completely garbled. Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages. I decided to use add/remove packages. This crashed pretty much immediately. I'm stuck with a pile of minimal non-working crud. FC4T2 was SOOOO much better. Hope to see you in final.
poly-p man
We very well for me, text and graphical.
As for installing everything, I do not like to do that. It takes the fun out of learning and experimenting with things.
~WILL~
Yeah I agree, the "everything" Option will not be missed, I never did find it useful. I installed fc5t2 today, and had no major problems, a minor one with nVidia, but it too will be worked out. I think those who are working on FC5 are doing a great job, I love the new look, it installs (for the most part) faster and it is cleaner. I personally would like to see more packages head on over to extras, and bring the 5 cd down to a more managable number, but that is personal preference. plus, I use the DVD anyway :-)
Thanks folks! Smashing Job!!!
BaVinic
Jim Martin wrote:
CodeHeads wrote:
Linux Counter (li.counter.org) #386711 wrote:
I just ftp'd the 5 disks, and put it on my system. Firstly, the installer sucks. Graphical only displays the top left corner of the screen, showing none of the useful information. I had to use text, which was completely garbled. Then, I got to the package selection screen. I know that they're still working on it, but come on! With no 'everything' option,I got very minimal packages. I decided to use add/remove packages. This crashed pretty much immediately. I'm stuck with a pile of minimal non-working crud. FC4T2 was SOOOO much better. Hope to see you in final.
poly-p man
We very well for me, text and graphical.
As for installing everything, I do not like to do that. It takes the fun out of learning and experimenting with things.
~WILL~
Yeah I agree, the "everything" Option will not be missed, I never did find it useful. I installed fc5t2 today, and had no major problems, a minor one with nVidia, but it too will be worked out. I think those who are working on FC5 are doing a great job, I love the new look, it installs (for the most part) faster and it is cleaner. I personally would like to see more packages head on over to extras, and bring the 5 cd down to a more managable number, but that is personal preference. plus, I use the DVD anyway :-)
Thanks folks! Smashing Job!!!
BaVinic
Very well said BaVinic!!! :) I just installed it today too :) This is actually the first test release I installed. I thought I would help out the best I can. I did find a few things, but someone beat me to it. I guess because they are more experienced in test releases then me. :) I am learning though. Usually when I find something wrong i try to track it down to make sure it was not me who screwed it up LOL. Believe me I have had to nuke and pave quite a few installs, but hey that is part of learning how things tick :) I am almost 100% M$ free. Out of 5 computer only 1 is windows!! :)
Thanks for a job well done!! :) I will try t