[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: kqemu is now GPLv2



On Wed, 7 Feb 2007 09:28:14 -0500
Jesse Keating <jkeating redhat com> wrote:

> On Wednesday 07 February 2007 03:15, Andreas Bierfert wrote:
> > Maybe we should just follow a different approach for kmods then? Why not do
> > something like a module manager (I heard some other distros have that ;) )?
> > With it people could easily build their modules themselves but have them
> > integrated via rpm so their filesystems don't go into nirvana after a
> > couple of system upgrades. If you make it easy (and graphical) enough I
> > suspect that people would be ok with it for external module stuff. That
> > would solve the problems of repo inconsistency but still give users what
> > they want...
> 
> And when they don't rebuild cleanly?  Then what?  The user is left holding
> the bag of a broken system should they ever reboot to that new kernel.

Yes, but maybe then the user should be given the choice to either reboot the
system with the new kernel (but missing module(s)) or stick with the old till
the module rebuilds. And to be honest: If a system goes into nirvana because
one of these modules is missing then I wonder how the system got installed in
the first place...

> I am entirely unconvinced that out of tree kernel modules adds any value over 
> the long run.  It may work for a kernel or two, but it will lag, it will 
> break, and somebody will get blamed for it, more often than not, it will be 
> us for moving the kernel too fast, or not caring enough about external 
> modules to hold back updates, or, or, or...  Out of tree modules _will_ lead 
> to poor user experiences and I do _not_ want the Fedora name attached to 
> _any_ of them.

Maybe out of tree kernel modules lead to these things and having an idealistic
view of moving everything into the upstream kernel is something I am fine with
but the problem is this: modules exist outside the kernel tree for various
reasons and they will exists no matter how hard we try to get everything we want
into the upstream kernel. To me the most important thing in fedora is user
experience and having modules for e.g. hardware available clearly is one of the
most basic and important things. If the modules are free in the fedora sense
why should we keep our users away from them? What I am suggesting is just that
we add an option to deliver a out of tree fedora kmod management tool so that
the user user experience does not suffer but we also solve the infrastructure
problems we face and could face. In a sense they then still will be second
class fedora 'packages' and I think that is a clear sign for upstream and users
to work on an integration to the kernel (add big red bold fancy 3D letters to
state this ;) ).

Maybe what I am trying to say is just this (regarding free modules):
Support and endorse out of tree modules to get integrated into the upstream
kernel and where possible support upstream to reach that goal. If that is not
possible or not desirable for some reason try to convince people to still do it
but also give users a chance to use the module via our magic management tool.

- Andreas

-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas bierfert lowlatency de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 173 5803043    | mail preferred

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]