On Sat, 2005-05-21 at 01:28, Rahul Sundaram wrote: > GCC4 is a improvement. So these > would flow from Fedora to others. Other changes could come from other > platforms to Fedora. If we cannot share core, we can share ideas. Sharing should go both ways. Their good ideas include a 'run from CD' version so you can easily test a release against your hardware without a destructive installation, and a single-CD base install. These are great features currently missing in Fedora. > > And in the context > >of fedora, the servers most likely aren't re-installed from scratch > >every 6 months. > Support for Fedora Core 2 was moved to Fedora Legacy when Fedora Core 4 > test 2 was released. Fedora Legacy has a FAQ on its support policy. > http://fedoralegacy.org/about/faq.php > So its not necessary to do any reinstallations every 6 months. Fedora > due to its upgrading method of staying close to upstream rather not > backporting may not be suitable for servers anyway. I will write and > post more about this later That's not exactly what I meant. Even if you did re-install the latest release on your servers, in most cases you wouldn't see any difference. Server features were pretty much complete in RH 7.3. There have been some bugfixes since - perhaps a few new things in sendmail and the database servers but nothing that is really going to pay for the downtime while you reinstall and reconfigure to take advantage of anything different. On the other hand, there is almost nothing in common between what RH 7.3 offered on the desktop and what you want there today. The improvements there are so obvious that it is worth the effort to change and so intertwined that it is best to blow everything away and start over (and the files you need to keep should be on a server anyway...). >I don't think it is something that should be answered in theory. > > > > > If you are interested in helping out, working out the packages > practically would be helpful. Like you said this can be answered in > theorotical statements that top 20 packages should be picked I think it should be much more dynamic than a committee decision. How about a framework where anyone who thought a system they had configured was worth duplicating could run a program that extracted a list of the installed RPMs minus the version numbers into a file that could be uploaded somewhere? Then add a program to Fedora's boot.iso that could grab this file from a central or local location and install the matching set of current RPMs. Unless I'm mistaken, that would be about half a page of perl or python, given the existing tools - maybe even a single line. Then it becomes an issue of marketing as to why that set of choices is a good one for some intended purpose and the end user only has to select one to get an expertly chosen set of applications. A subsequent step could be to automate the generation of a iso image containing the selected packages, but the real value would come from being able to share someone's expertise in package selection. > >I'm not sure I understand the concept of a 'core' that is right for > >both a desktop and a server install. > > > > > So you think core should be focussed towards desktop. Thufir just mailed > me yesterday about his opinion that none of the DE's should be included > within Fedora core to accomodate users preferences better. This is > certainly a subjective thing What I mean is that Core vs. Extras is an administrative concept related to who controls what packages. From a user's perspective the important grouping is the set of packages that need to be installed on any particular machine, which will be related only to the purpose of the installation - and for most purposes I'd expect a mix of Core and Extra packages to be wanted. What matters from the user's side is the effort/bandwidth needed to choose and install them, not where the master copies are stored. -- Les Mikesell lesmikesell@xxxxxxxxx
