spin kickstart/minimization cleanups

[drago01]

On Wed, Apr 21, 2010 at 7:58 PM, David Zeuthen <davidz at redhat.com> wrote:
> Hi,
>
> (Dropping devel, cross-posting is evil etc. etc.)
>
> On Wed, 2010-04-21 at 09:40 -0400, Colin Walters wrote:
>> On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>
>> >
>> > I've spent a little time looking at the hardware side of things and
>> > done a basic patch for some of the hardware stuff based on the current
>> > rawhide comps file. I've broken it down into network/server/misc for
>> > the time being and pushed the print stuff over to its group. More can
>> > be done as it was a quick look through. The old hardware-support
>> > currently includes all the other groups so there's no real change for
>> > current builds overall.
>>
>> This looks like a good start.  I think the way this kind of thing
>> should work in general is that the system detects if you have the
>> hardware, and dynamically installs support for it.  We'd need some
>> database mapping things like USB ids to packages.  Networking is an
>> exception; we should include as many drivers/tools for
>> networking-related functionality as possible so that the system can be
>> bootstrapped.
>>
>> Basically: if you have a GPS chip, gypsy gets installed and runs.  If
>> you don't, it doesn't.
>
> Don't take this mail the wrong way, but I strongly object to something
> like that. It is a departure from how things currently work e.g. we
> install all drivers/software/etc for any gizmo you may or may not plug
> in. While the current approach certainly represent a cost (bandwidth,
> diskspace, etc.) I find it highly preferable to some unreliable
> auto-detection system that is very very hard to get right and comes with
> its own set of problems (See non-OEM installs of Windows for details).
>
> My view is that there's are a couple of corner cases where doing
> something like the proposed might work (printer drivers comes to mind)
> but for core hardware support it is just bound to fail. And it doesn't
> really buy you anything. Granted, it's an interesting problem to solve
> and I guess that's why people keep advocating such a system. But for a
> free OS developed in a centralized way (for better or worse) it's pretty
> much just fail city.
>
> (FWIW, here's an idea: I think we should work towards everyone getting
> everyone the same goddamn OS image (which is thoroughly tested, QA'ed
> etc etc) instead of making the current time-space combinatorics thing
> we're doing right now even harder and more complex.)

+1

Hardware should JUST WORK ... anything else is just failure on our side.

And when we have to choose between better user experience (hardware
just work) or save some disk space (which is cheap anyway) the choice
is obvious imho.