Adam T. Gautier wrote:
I think it's a bad idea.
Great, this is the discussion I want...
It sounds like what you're doing is giving folks theWell technically that is how Anaconda works, using a tiny linux image to load Anaconda but other than that it just collects information for configuration and installs packages. Anyway, a user would choose packages that are available to installation. The installation would happen the same way it does now. Eventually, a customized Anaconda installer would probably be available that would allow customization of the install process.
ability to select "Choose packages" in the Fedora installer before actually
installing the operating system.
Also, I am not thinking that the any joe schmo would use this service. It would really be for IT managers, developers, and technical hobbiest. They would choose the packages they wanted available to be installed. Instead of using the one size fits all Fedora install, which also has the contraint of only using packages allowed by RedHat, no third party packages.
HUH?
Where do you get the 'one size fits all' theory. Fedora has many different configurations (minimal, server, workstation) and NONE are limited to exactly one size since all can be further configured by selecting what to install/exclude.
Any OS distro only allows the packages on the distro disk to be installed *when first installed*. But the linux distros do not limit or restrict in any way what software can be installed after the system is up and running. There are certainly many 3rd party packages included in the distribution as well as available after the fact. Mysql, postgres, OOo and many others are examples of those included. You cannot say that about the other OS.
With any linux distribution available there is a limited amount that can be included out ot the box, and then the add-ons are limitless.
Your idea is likely feasible, but will require a LOT of attention to detail and refining. RedHat, among others, had an internet install process with previous releases by using just a boot disk to start the install. It is still possible to do that, and it appears your suggestion is to use a similar method for the OS install with the added ability to do the same for additional non-distribution software.I agree, Red Hat, Mandrake, and Suse already have thriving businesses based on the support model. I expect users to get their support packs and package upgrades etc from them. I just think there is a group of people that want to define their own distribution parameters: look and feel, packages, configuration, etc... If these systems are based on say Fedora why can't they get support from these mailing lists. Would it not be the same as installing fedora and editing a file in /etc?
This process is not conduive to, nor indeed feasable, via a "public one size
fits all" webpage service.
Why not?
If you have something else in mind, like aCreating custom RPMs is one way to go... But people use technology to implement solutions not to install software. I am just trying to provide another distribution of complete solution sets not just installable software. Sure I could create a custom RPM of postfix to implement a specific part of a solution, I could also create a pre-configured distribution that I know will have the correct packages for the solution. Just seems like another way to go...
"pre-customize Fedora Core with your own logos" or something, that's another
thing entirely. You could just release your own version of fedora-logos.
The problem will pop up when it becomes (and it is) *mandatory* that the binary being installed this way be 1) Compatible with the installed OS (kernel, distribution, libraries, etc) and 2) Able to work OTB for the user installing it from your site/service. If not they will expect you to provide support to _make it work_ since it is your distribution.
Your idea will only work on Linux with _custom_ .rpm or .deb packages that support the users hardware/OS configuration. A source package with the compile/install occuring on the users mahcine is not likely to work with this type of install. Otherwise the current method of letting the user decide what he wants/needs and take steps to make it work is best.
If we limit the users choice then we go back to the rigid path of following what a *vendor* wants us to be able to do.
