Hans de Goede wrote:
Rahul wrote:
Hans de Goede wrote:
Hi all,
I've been following the AIGLX repository discussion from the sideline.
And I'm a bit shocked by what I'm reading there. There seems to be
strong support for releasing Xorg 7.1 as an update for FC-5 even though
that will break both NVidea and Ati binary drivers. For the records all
my computers have a radeon 9200 running OSS drivers.
Kernel updates have been breaking non-free drivers all the time. There
are a number of other changes that broke other third party packages. I
dont quite understand why there is no much shock on potential of Xorg
updates breaking such proprietary drivers.
Yes,
They do which is bad enough from an end user POv. But which aslo is
fixable, usually by booting the old kernel, wait for a day or two that
other repo todo the work and tada magicly fixed.
Doesnt work that way if a fix is unavailable, there is noone working on
it, for several different packages where noone is interested or which do
not allow repackaging in repositories. We arent catering well to those
user bases which use these non-free drivers and we are not going to do
it ever. Others can workaround it and probably will continue doing that
but there are going to be limitations. There is nothing new here.
Not quite perfect, but
close. NVidea doesn't have drivers which will work with 7.1 planned for
a month and Ati probably will be even slower. Also one cannot just
reboot into that older kernel, so there is a HUGE difference here.
One can however ignore the update or if they driver is packaged
properly, it will simply revert to the open drivers.
Anyways I explicitly asked not to discuss this in this thread this
belongs in a seperate thread.
Your whole discussion is tied to the argument that since we are
potentially breaking non-free drivers, noone would use Fedora. I can't
see how we can have the discussion now without considering the premise.
Anyway, I hope the objectives page
(http://fedoraproject.org/wiki/Objectives) answers you on your question
regarding target audience. Its fluid but I dont think we need to
restrict our definitions too much.
Rahul
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
