Loading custom DSDT

Dave Jones davej at redhat.com
Tue Oct 25 19:48:26 UTC 2005


On Tue, Oct 25, 2005 at 08:09:53PM +0100, Manuel Moreno wrote:
 > Dave Jones wrote:
 > >Mandriva, SuSE and Ubuntu also carry lots of other patches we don't
 > 
 > I do not know right now about Mandriva and SuSe but I'm well sure that 
 > Ubuntu kernel carry far less patches than RH.
 > 
 > >have in Fedora, so the analogy is pointless.
 > So your comparison is unsound, untrue and misleading. :-)

What comparison ?

 > >End-users shouldn't need to know what a DSDT, or an initrd is.
 > Why?

Why should they ? A user just wants their computer to work, they
don't necessarily care what an "acpi" or a "dsdt" is.
 
 > >End-users shouldn't need to know what a DSDT, or an initrd is.
 > Because you say so?

speaking as one of the people that have to make sense of
bug reports coming in, yes.  Part of my job is to make decisions
based upon on how supportable something is. It's exactly the
same process that kept inotify from being merged until it
got upstream. It's the same reason we don't have reiser4.
It's the same reason we don't have countless other things people
ask for, that no doubt, *someone* would really like to see in the
Fedora kernel. But until these things get upstream, my job
is to say no, or go insane trying to deal with the resulting fallout.

 > Considering the increasing number of laptops/notebooks out there your 
 > stand is unsustainable and looks like technofundamentalism. Do you 
 > really want Fedora to wane into the shadows of marginal/niche 
 > distributions... :-)

This stuff should "just work".  I agree users shouldn't have to
build their own kernels. But that also includes "users shouldn't
have to mess around with the initrd".  Take a look through bugzilla
if you want to see the million ways users *have already* screwed
up their initrd's because they thought they knew what they were doing.

By saying "you *have* to do this to make it work", we're taking a
giant step backwards.

		Dave




More information about the fedora-devel-list mailing list