Re: Closed vs. open development methods (Was DVI output, ATI or nVidia)

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

 



On 6/27/07, Jonathan Dieter <jdieter@xxxxxxxxx> wrote:
On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
> On 6/27/07, Dr. Michael J. Chudobiak <mjc@xxxxxxxxxxxxxxx> wrote:
<snip>
> > Is it good that the kernel bugzilla says "NO BINARY MODULES or other
> > tainted kernels. Do not file bugs here if you have any binary kernel
> > modules loaded, reproduce without that module first. NVIDIA users - THIS
> > MEANS YOU!"?
> >
> > In what way is the closed nvidia code and process better than being
> > open? How does that benefit users?
>
> I never claimed that it was better.  I just said that its certainly no
> worse.  No one here has yet to provide any concrete evidence to prove
> otherwise.
>
This is *unreal*!!  Are you actually claiming that the using a
closed-source development process is as good as an open-source
development process?  That there is no evidence to the contrary?

No, I'm not claiming that.  I'm referring to support, which I thought
was clear from the start.  Please don't confuse software development
processes with support processes. That are completely different
animals.

Let's look at two very different problems that I had when I got my new
laptop nine months ago.

The first problem:  The hard drive was very slow...so slow that Fedora
Core 5 would crash when I tried to install it.  I was also getting an
"Invalid MAP value" in dmesg.

The first solution:  I looked into the kernel source to find why I was
getting the Invalid MAP value.  It turned out that Intel's specs for my
hard drive controller say that the controller doesn't support 2 PATA + 2
SATA slots.  The ata_piix driver followed the specs.  I changed the
ata_piix driver (one or two lines of code) to allow said combination.
Everything started working perfectly.  Sent fix upstream (my first and
only kernel bugfix).  It was included in the next kernel update, and
made it (barely) into Fedora Core 6.  Woohoo!  Problem fixed after a
couple hours of work, plus an hour or so spent on sending e-mails
upstream.  And now nobody else will have this problem.

In the grand scheme of things, you're a rarity.  Most people wouldn't
even know where to look in the source for this, much less what to look
for.  You supported yourself in this case.  You got no support from
any other party.  You've just made my point that for the majority of
people, support for open source software is no better than closed
source.

The second problem:  I couldn't get compiz to work with the NVIDIA card
that came with the laptop.  Once I enabled compiz, my system would work
fine for between one and ten minutes, and then the display would start
flickering and sooner or later the kernel would crash.

The second solution:  I report a bug using the nvnews forum, and get the
useful suggestion (from YOU) to "update my BIOS".  Except there isn't a
BIOS update available for my system.  And it's not a BIOS problem
anyway.  There's no way for me to track down the offending
code...because there's no source available.  All I can give you is some
"Xid" errors which obviously aren't useful to either of us.  Finally,
after days of searching, a friend from the forum points out a solution
that, according to you[1], "isn't possible in Linux for mobile GPU's
right now."  Except it does work...if I pass certain undocumented
parameters to the nvidia kernel module.

Guess what, you've made my point again.  The 'solution' that you
employed was due to a BIOS bug.  Now for someone who claims that
there's no way to track the source of the problem, you have some
amazing confidence that its not a BIOS problem, even though you've not
seen the BIOS source either.


So, to sum up, with an open driver, I'm able to find the problem and fix
it (sending the fix upstream as well).  With a closed driver, I'm left
helplessly flailing about asking for help from what seems to be one or
two overworked NVIDIA employees and/or other people who are helplessly
flailing about.

Lonni, I don't want to be bashing you at all, because, from what I see,
you and one or two others are the only ones helping us Linux users on
nvnews.  But it really sucks that NVIDIA doesn't have a proper
bug-reporting tool for *all* their users, and that there's no way for us
to even *try* to fix our own problems.  And it's even worse that the
code isn't open so that those who do know what they're doing (myself
most definitely excluded) can improve it.

Its unfortunate the very small minority who are capable of
understanding device driver code cannot fix problems in closed source
drivers, however that small minority is just that, the small minority.
For the vast majority of people, getting the source wouldn't help
them or anyone else to fix their problems.  As I've stated before in
this thread, the open source software world is littered with thousands
of bugs that no one has fixed for various reasons.  Just because the
source is freely available does not mean that everyone's problems are
going to suddenly disapear.


Our school is going to be buying 40 new computers this summer, and I've
specified Intel graphics because I'm tired of dealing with opaque driver
problems.

I wish you the best of luck.

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux