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 Wed, 2007-06-27 at 08:37 -0700, Lonni J Friedman wrote:
> On 6/27/07, Jonathan Dieter <jdieter@xxxxxxxxx> wrote:
> > 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.
Sorry, my mistake.  I meant to say "support process".  I do understand
your point, as the rest of my e-mail hopefully showed.

> > 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.
While you may be right that I'm a rarity, my point is that there are a
lot more people like me working outside of NVIDIA then there are working
inside of NVIDIA.  If NVIDIA's code was open, those who are like me
(though they might be relatively rare) would be able to help find the
problems that affect us.

> 
> > 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.
Okay, fair enough.  I assumed because the problem was easily fixed with
the nvidia module parameters, it had to do with the NVIDIA card.  That
is my mistake.  Though I think the only point I've made is that a closed
BIOS is just as bad as a closed graphics driver.  :)

<snip>
> 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.
I do completely understand your point.  I just believe the small
minority can accomplish much more than can be accomplished with just one
company.  Open-sourcing NVIDIA's code wouldn't mean that NVIDIA could
toss it out to the world and then ignore it, but it does mean that
NVIDIA would have the advantage of other people looking at it and
helping to fix bugs that they find.

Like you said, I may be part of a small minority, but that minority is
what makes open-source software work.

> > 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.
Thank you

Jonathan

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux