Re: DVI output, ATI or nVidia

[Andrea]

> >    I've seen something with nVidia GE 7XXX or GE 8XXX.
> >    Alternative is ATI 1650SE
> >    Or should I go for one Intel integrated? 
> Yes. 
> Intel integrated + ADD2 DVI card + "intel" xorg driver
> = open source solution. 
> The Intel driver is open source, not a binary blob. 

Thanks.
You mean that the open source driver for Intel card has a much better
support than the open source driver for ATI and nVidia.

I think I will investigate again and look for the one you mentioned.

Cheers

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/26/07, Mario Rossi <mariofutire(a)googlemail.com&gt; wrote:
>  >>    I've seen something with nVidia GE 7XXX or GE 8XXX.
>  >>    Alternative is ATI 1650SE
>  >>    Or should I go for one Intel integrated?
>
>  >Yes.
>
>  >Intel integrated + ADD2 DVI card + "intel" xorg driver
>  >= open source solution.
>
>  >The Intel driver is open source, not a binary blob.
>
>
>  Thanks.
>  You mean that the open source driver for Intel card has a much better
>  support than the open source driver for ATI and nVidia.
>
>  I think I will investigate again and look for the one you mentioned. 
Granted, I work at NVIDIA, so my opinions are going to be slanted
here, but I don't see how one defines support as better in one driver
versus the other unless you've got some written contract guarenteeing
a particular level of support.

DVI output, ATI or nVidia

[Alan]

On Tue, 26 Jun 2007, Lonni J Friedman wrote:

>  On 6/26/07, Mario Rossi <mariofutire(a)googlemail.com&gt; wrote:
> > >>    I've seen something with nVidia GE 7XXX or GE 8XXX.
> > >>    Alternative is ATI 1650SE
> > >>    Or should I go for one Intel integrated?
> > 
> > >Yes.
> > 
> > >Intel integrated + ADD2 DVI card + "intel" xorg driver
> > >= open source solution.
> > 
> > >The Intel driver is open source, not a binary blob.
> > 
> > 
> > Thanks.
> > You mean that the open source driver for Intel card has a much better
> > support than the open source driver for ATI and nVidia.
> > 
> > I think I will investigate again and look for the one you mentioned.
>
>  Granted, I work at NVIDIA, so my opinions are going to be slanted
>  here, but I don't see how one defines support as better in one driver
>  versus the other unless you've got some written contract guarenteeing
>  a particular level of support. 
"Support" in this case means "I have source and can fix it if I need
to". 
It is not obscured by a large binary blob that the user cannot touch. 
Support contracts have little or nothing to do with it.

My problem with the Intel hardware is that it is damned hard or impossible 
to get for some environments.  You can't just go down to the store and buy 
an Intel video card.  You either replace your motherboard and/or system 
and buy something that has an Intel card inside.  (And if you want/need an 
AMD64 you are just screwed.)

Of the closed source video card vendors, nVIDIA does a better job 
supporting Linux in my opinion.  (They at least attempt to support all of 
their currently shipping cards, unlike ATI.)  Although I am still abit 
pissed off about the sudden drop of support for the 440go in the supported 
drivers.  (Replacing a video card in a laptop is not a viable option 
without buying something like Alienware or buying a new laptop.)

-- 
"ANSI C says access to the padding fields of a struct is undefined.
ANSI C also says that struct assignment is a memcpy. Therefore struct
assignment in ANSI C is a violation of ANSI C..."
                                   - Alan Cox

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/26/07, alan <alan(a)clueserver.org&gt; wrote:
>  On Tue, 26 Jun 2007, Lonni J Friedman wrote:
>
>  > On 6/26/07, Mario Rossi <mariofutire(a)googlemail.com&gt; wrote:
>  >> >>    I've seen something with nVidia GE 7XXX or GE 8XXX.
>  >> >>    Alternative is ATI 1650SE
>  >> >>    Or should I go for one Intel integrated?
>  >>
>  >> >Yes.
>  >>
>  >> >Intel integrated + ADD2 DVI card + "intel" xorg driver
>  >> >= open source solution.
>  >>
>  >> >The Intel driver is open source, not a binary blob.
>  >>
>  >>
>  >> Thanks.
>  >> You mean that the open source driver for Intel card has a much better
>  >> support than the open source driver for ATI and nVidia.
>  >>
>  >> I think I will investigate again and look for the one you mentioned.
>  >
>  > Granted, I work at NVIDIA, so my opinions are going to be slanted
>  > here, but I don't see how one defines support as better in one driver
>  > versus the other unless you've got some written contract guarenteeing
>  > a particular level of support.
>
>  "Support" in this case means "I have source and can fix it if I need
> to". 
If you're fixing the code yourself, then you're not getting support.
For the vast majority of people, they are not going to fix the code
themselves when something is broken, they need someone, somewhere to
help.

>  It is not obscured by a large binary blob that the user cannot
> touch.
>  Support contracts have little or nothing to do with it. 
On the contrary, support contracts have a lot to do with it.  Unless
you're fixing the code yourself, there are no guarentees anywhere that
any issues that someone has with a driver, be it closed or open
source, will ever be addressed.

Open source projects are full of long standing bugs which haven't been
fixed.  Just because code is open does not mean that a bug is going to
get fixed faster unless you are the one who is capable of fixing it.

DVI output, ATI or nVidia

[Tom Horsley]

On Tue, 26 Jun 2007 14:03:16 -0700
"Lonni J Friedman" <netllama(a)gmail.com&gt; wrote:

>  Open source projects are full of long standing bugs which haven't
> been
>  fixed.  Just because code is open does not mean that a bug is going to
>  get fixed faster unless you are the one who is capable of fixing it. 
In my experience just because you are paying for support doesn't
mean it is gonna get fixed either (unless the one paying is Microsoft
or Sony and is providing the lion's share of revenue - bugs they pay
to get fixed probably do get fixed, or at least obscured :-).

For the sort of thing open source can provide even without actually
"fixing" a bug myself, see:

http://home.att.net/~Tom.Horsley/easy-linux.html

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/26/07, Tom Horsley <tom.horsley(a)att.net&gt; wrote:
>  On Tue, 26 Jun 2007 14:03:16 -0700
>  "Lonni J Friedman" <netllama(a)gmail.com&gt; wrote:
>
>  > Open source projects are full of long standing bugs which haven't been
>  > fixed.  Just because code is open does not mean that a bug is going to
>  > get fixed faster unless you are the one who is capable of fixing it.
>
>  In my experience just because you are paying for support doesn't
>  mean it is gonna get fixed either (unless the one paying is Microsoft
>  or Sony and is providing the lion's share of revenue - bugs they pay
>  to get fixed probably do get fixed, or at least obscured :-). 
Sure, I never implied that paying for support means that bugs get
fixed (or even fixed faster).  However the claim that if its open
source, its going to get fixed (or fixed faster) also doesn't hold up.
There are many great reasons to use open source software, however
getting bugs fixed faster is really not one of them unless you're the
one doing the fixing.

>  For the sort of thing open source can provide even without actually
>  "fixing" a bug myself, see:
>
>  http://home.att.net/~Tom.Horsley/easy-linux.html 
Of course, those are many great examples of the benefits of open
source. It certainly doesn't change the fact that open source bugs
don't necessarily get fixed any faster than closed source bugs.

The point here is that someone claimed that going with the open source
intel drivers means that someone would get better support.  That claim
is silly because 'support' is a rather vague concept, and my idea of
support likely differs from someone else's.

DVI output, ATI or nVidia

[Jim Cornette]

Lonni J Friedman wrote:
> > For the sort of thing open source can provide even without
> actually
> > "fixing" a bug myself, see:
> >
> > http://home.att.net/~Tom.Horsley/easy-linux.html
>  
>  Of course, those are many great examples of the benefits of open
>  source. It certainly doesn't change the fact that open source bugs
>  don't necessarily get fixed any faster than closed source bugs. 
It is a lot better to not have to go out and update drivers for every 
kernel release. Personally, I choose open code and specs.
You do have a point that neither bugs experienced in vendor only 
supported drivers and openly available code and known specifications 
ensures someone or group will fix the problem.
>  
>  The point here is that someone claimed that going with the open source
>  intel drivers means that someone would get better support.  That claim
>  is silly because 'support' is a rather vague concept, and my idea of
>  support likely differs from someone else's. 
I liked the times that I needed to try and work with developers through 
submitting bug reports and testing their proposed solutions. Neither 
upstream developers or RedHat developers seemed to outwardly make one 
feel inferior due to my lesser knowledge of the problems. It was a 
learning experience and the bugs were removed from the Intel driver 
source code once found. With closed source drivers it becomes an 
expedition to find a suitable driver to run hardware in a suitable 
manner. Since Linux distributions vary enough with compilers used and 
their frequency of updates, an open driver which the code can be updated 
and compiled for optimum performance would sell more hardware in my 
view. Of course the sales for closed drivers for hardware probably has 
less impact than I would expect.

I am using a laptop with a radeon card which has some 3D support for the 
particular chipset. The computer with the NVidia card has only 2D with 
the open nv driver. So I would suggest Intel, then radeon, then maybe 
NVidia. SIS, MGA  and S3 for 3D support I am not sure of how well they 
work, if at all. I only tried 2D on those machines to date.

Jim
>   

-- 
Your picture of the world often changes just before you get it into focus.

DVI output, ATI or nVidia

[Frank Cox]

On Tue, 26 Jun 2007 14:03:16 -0700
Lonni J Friedman <netllama(a)gmail.com&gt; wrote:

>  If you're fixing the code yourself, then you're not getting
> support.
>  For the vast majority of people, they are not going to fix the code
>  themselves when something is broken, they need someone, somewhere to
>  help. 
If you have the source code, then someone can fix it.   Unlike closed source
stuff, where there is a single source of "fixes", i.e. the original vendor,
with open source code anyone can fix it.  No worries about last year's model of
card X being dropped due to an arbitrary corporate decision or other reasons
like that.

The "someone" doesn't have to be you and it doesn't have to be me.  But
I would
rather depend on a whole community of coders for my fixes than one corporation
who may decide that there isn't enough money in it.

With Intel graphics, I can install my Linux operating system and have it work
right out of the box.  I recommend that everyone stay far far away from ATI and
Nvidia, personally.

-- 
MELVILLE THEATRE ~ Melville Sask ~ http://www.melvilletheatre.com

DVI output, ATI or nVidia

[Dr. Michael J. Chudobiak]

>  Granted, I work at NVIDIA, so my opinions are going to be slanted
>  here, but I don't see how one defines support as better in one driver
>  versus the other unless you've got some written contract guarenteeing
>  a particular level of support. 
Open code and open discussion make for better support... that should be 
obvious on a Fedora list :-) Since just about everyone on this list will 
have no support contract with intel and no support contract with nvidia, 
  intel "wins" because it's an open driver...

I've talked with the intel driver developers on the xorg list (Keith 
Packard, for instance), who have been extremely helpful in resolving issues.

I have nothing against nvidia, but the intel driver eliminates so many 
issues related to binary drivers, making it very compelling if you have 
to support multiple computers. (For example: you don't need to sync 
driver/kernel releases, you don't need livna rpms, compiz works, you can 
get straight answers from the driver developers, the developers are real 
intel employees rather than volunteers working without access to nvidia 
technical specs...)

The only "bad" thing is that all current intel devices are integrated on 
the motherboard, and you generally need an ADD2 card to get the DVI port 
(and a LCD monitor with "DDC/DI" capability - obscure but important!) 
But if you have that... it just works!

Also - if the integrated intel chip doesn't work for you, for whatever 
reason, you can always install an ATI or nvidia expansion card.

The rendering performance won't impress hard-core gamers, but for 
everyone else it's more than adequate.

The open driver means all of my current and future computer purchases 
will require intel integrated graphics...

Intel has chosen to aggressively support linux by opening the driver 
code. nvidia hasn't. Intel wins!


- Mike

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; wrote:
>  > Granted, I work at NVIDIA, so my opinions are going to be
> slanted
>  > here, but I don't see how one defines support as better in one driver
>  > versus the other unless you've got some written contract guarenteeing
>  > a particular level of support.
>
>  Open code and open discussion make for better support... that should be
>  obvious on a Fedora list :-) Since just about everyone on this list will
>  have no support contract with intel and no support contract with nvidia,
>    intel "wins" because it's an open driver... 
Based on what criteria?  I'm still amused how people keep making that
claim yet never provide any criteria, as if its just glaringly obvious
to all but the most casual observer.

>  I've talked with the intel driver developers on the xorg list
> (Keith
>  Packard, for instance), who have been extremely helpful in resolving issues.
>
>  I have nothing against nvidia, but the intel driver eliminates so many
>  issues related to binary drivers, making it very compelling if you have
>  to support multiple computers. (For example: you don't need to sync
>  driver/kernel releases, you don't need livna rpms, compiz works, you can
>  get straight answers from the driver developers, the developers are real
>  intel employees rather than volunteers working without access to nvidia
>  technical specs...) 
NVIDIA employees (myself included) interact directly via both of the
support methods documented in the NVIDIA driver README.  So, I regret
that you are misinformed.

>  The only "bad" thing is that all current intel devices are
> integrated on
>  the motherboard, and you generally need an ADD2 card to get the DVI port
>  (and a LCD monitor with "DDC/DI" capability - obscure but important!)
>  But if you have that... it just works! 
So if you have specific hardware, it works.  That seems like a rather
huge hurdle (and a rather poorly documented one, at that).

>  Also - if the integrated intel chip doesn't work for you, for whatever
>  reason, you can always install an ATI or nvidia expansion card. 
How do you mean "if the integrated intel chip doesn't work for you"?
I thought you said that support for Intel is superior to non-open
source options.  Either it is superior or its not.

>  The rendering performance won't impress hard-core gamers, but for
>  everyone else it's more than adequate. 
As long as "everyone else" doesn't include anyone running workstation
graphics applications or anyone in the film industry or anyone doing
GPGPU work, or even casual gamers who want to play Quake every now &
then.  I could go on and on, but I think my point is clear.  You're
concept of "everyone else" is an extremely small percentage of the
graphics market from a revenue perspective.

>  The open driver means all of my current and future computer purchases
>  will require intel integrated graphics...
>
>  Intel has chosen to aggressively support linux by opening the driver
>  code. nvidia hasn't. Intel wins! 
Fan boy much?  Opening the driver does not equate with aggressively
supporting linux.  The list of companies that have released the specs
or an open source driver, and provided very poor support (the source
only works with a specific kernel version, its buggy, its incomplete,
etc) is rather long.  Open sourcing a driver does not equate with
aggressive linux support.  You're deluding yourself if you truly
believe that it does.

DVI output, ATI or nVidia

[Ralf Corsepius]

On Wed, 2007-06-27 at 06:03 -0700, Lonni J Friedman wrote:

>  > The open driver means all of my current and future computer
> purchases
>  > will require intel integrated graphics...
>  >
>  > Intel has chosen to aggressively support linux by opening the driver
>  > code. nvidia hasn't. Intel wins!
>  
>   Opening the driver does not equate with aggressively
>  supporting linux. 
>
>   The list of companies that have released the specs
>  or an open source driver, and provided very poor support (the source
>  only works with a specific kernel version, its buggy, its incomplete,
>  etc) is rather long.  
Yes, the key to success would be to open up the sources and
then to let
employees and community developers work together and let them share
their knowledge.

Ralf

DVI output, ATI or nVidia

[Dr. Michael J. Chudobiak]

Lonni J Friedman wrote:
>  Based on what criteria?  I'm still amused how people keep making
> that
>  claim yet never provide any criteria, as if its just glaringly obvious
>  to all but the most casual observer. 
OK, random example: where is the nvidia bug tracker? Pretty standard 
support tool for anything linux-related - the kernel, xorg, gnome, kde, 
openoffice...


> > The only "bad" thing is that all current intel devices
> are integrated on
> > the motherboard, and you generally need an ADD2 card to get the DVI port
> > (and a LCD monitor with "DDC/DI" capability - obscure but important!)
> > But if you have that... it just works!
>  
>  So if you have specific hardware, it works.  That seems like a rather
>  huge hurdle (and a rather poorly documented one, at that). 
Not a huge hurdle, but it is limiting, I agree. Nonetheless, it is a 
lower hurdle than making closed binary drivers work reliably, I find 
personally.


>  How do you mean "if the integrated intel chip doesn't work
> for you"?
>  I thought you said that support for Intel is superior to non-open
>  source options.  Either it is superior or its not. 
Glad to clarify: It is superior.

The point was, if you get the cheap integrated chip and you find it 
doesn't meet your needs (for whatever reason: there's a bug that affects 
you, you decide that you really need to edit full-length motion pictures 
in real time on your computer, you become a competitive gamer, etc) you 
can slap in an ATI/nvidia card. You can go both ways: decent open driver 
on the intel hardware, or closed higher-performance binary driver on the 
add-in card. Doesn't apply to laptops of course, but hopefully you 
aren't editing movies on a laptop.


>  As long as "everyone else" doesn't include anyone
> running workstation
>  graphics applications or anyone in the film industry or anyone doing
>  GPGPU work, or even casual gamers who want to play Quake every now &
>  then.  I could go on and on, but I think my point is clear.  You're
>  concept of "everyone else" is an extremely small percentage of the
>  graphics market from a revenue perspective. 
Fair enough - from a revenue perspective. MS Windows also dominates 
server OS sales - from a revenue perspective. Not true from a count of 
installations, of course.


>  Fan boy much?  Opening the driver does not equate with aggressively
>  supporting linux.  The list of companies that have released the specs
>  or an open source driver, and provided very poor support (the source
>  only works with a specific kernel version, its buggy, its incomplete,
>  etc) is rather long.  Open sourcing a driver does not equate with
>  aggressive linux support.  You're deluding yourself if you truly
>  believe that it does. 
Are you trying to say that intel doesn't really support linux? Or that 
nvidia's linux support is actually better? Or what?

Are you comfortable with the fact that the source code and development 
process for the kernel, the application software (word processors, image 
browsers, the gimp, cinepaint), the other drivers (mouse driver, network 
driver, ...) are open, but the video driver is binary and secret?

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?


- Mike

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; wrote:
>  Lonni J Friedman wrote:
>  > Based on what criteria?  I'm still amused how people keep making that
>  > claim yet never provide any criteria, as if its just glaringly obvious
>  > to all but the most casual observer.
>
>  OK, random example: where is the nvidia bug tracker? Pretty standard
>  support tool for anything linux-related - the kernel, xorg, gnome, kde,
>  openoffice... 
Its available to all of NVIDIA's customers.  If you have to ask where
it is, then you're not an nvidia customer.

>  >> The only "bad" thing is that all current intel
> devices are integrated on
>  >> the motherboard, and you generally need an ADD2 card to get the DVI port
>  >> (and a LCD monitor with "DDC/DI" capability - obscure but important!)
>  >> But if you have that... it just works!
>  >
>  > So if you have specific hardware, it works.  That seems like a rather
>  > huge hurdle (and a rather poorly documented one, at that).
>
>  Not a huge hurdle, but it is limiting, I agree. Nonetheless, it is a
>  lower hurdle than making closed binary drivers work reliably, I find
>  personally. 
How is being forced to purchase a specific display device in order to
use the GPU a lower hurdle than using any display device with the GPU?

>  > How do you mean "if the integrated intel chip doesn't
> work for you"?
>  > I thought you said that support for Intel is superior to non-open
>  > source options.  Either it is superior or its not.
>
>  Glad to clarify: It is superior.
>
>  The point was, if you get the cheap integrated chip and you find it
>  doesn't meet your needs (for whatever reason: there's a bug that affects
>  you, you decide that you really need to edit full-length motion pictures
>  in real time on your computer, you become a competitive gamer, etc) you
>  can slap in an ATI/nvidia card. You can go both ways: decent open driver
>  on the intel hardware, or closed higher-performance binary driver on the
>  add-in card. Doesn't apply to laptops of course, but hopefully you
>  aren't editing movies on a laptop. 
Many people are editing movies on laptops.  Just not with Intel GPUs.

>  > As long as "everyone else" doesn't include anyone
> running workstation
>  > graphics applications or anyone in the film industry or anyone doing
>  > GPGPU work, or even casual gamers who want to play Quake every now &
>  > then.  I could go on and on, but I think my point is clear.  You're
>  > concept of "everyone else" is an extremely small percentage of the
>  > graphics market from a revenue perspective.
>
>  Fair enough - from a revenue perspective. MS Windows also dominates
>  server OS sales - from a revenue perspective. Not true from a count of
>  installations, of course. 
We're talking about hardware, not software.  Please don't change the
focus just to bolster your argument.

>  > Fan boy much?  Opening the driver does not equate with
> aggressively
>  > supporting linux.  The list of companies that have released the specs
>  > or an open source driver, and provided very poor support (the source
>  > only works with a specific kernel version, its buggy, its incomplete,
>  > etc) is rather long.  Open sourcing a driver does not equate with
>  > aggressive linux support.  You're deluding yourself if you truly
>  > believe that it does.
>
>  Are you trying to say that intel doesn't really support linux? Or that
>  nvidia's linux support is actually better? Or what? 
I'm saying that open sourcing a driver does not equate with support.
I'm sure that Intel does the best job that they can to support
whomever they deem as important to their business.  However,
pretending that just because they have open source drivers their
support is somehow better is delusional.

>  Are you comfortable with the fact that the source code and
> development
>  process for the kernel, the application software (word processors, image
>  browsers, the gimp, cinepaint), the other drivers (mouse driver, network
>  driver, ...) are open, but the video driver is binary and secret? 
Yes, I am.  I've yet to see any evidence that open source software
provides a higher level of support than closed source software.

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

DVI output, ATI or nVidia

[Dr. Michael J. Chudobiak]

Lonni J Friedman wrote:
> > OK, random example: where is the nvidia bug tracker? Pretty
> standard
> > support tool for anything linux-related - the kernel, xorg, gnome, kde,
> > openoffice...
>  
>  Its available to all of NVIDIA's customers.  If you have to ask where
>  it is, then you're not an nvidia customer. 
Hmm, I didn't order my Intel GPU direct from Intel either, but I can 
still access the driver bugzilla. I guess you finally have some evidence 
of how open source support can be better.


>  How is being forced to purchase a specific display device in order
> to
>  use the GPU a lower hurdle than using any display device with the GPU? 
You can plan for hardware requirements. The closed-source bugs and 
kernel incompatibilities of the binary drivers are harder to manage.


>  Many people are editing movies on laptops.  Just not with Intel GPUs.
OK, agreed, they should use closed drivers and ati/nvidia hardware.


> > > As long as "everyone else" doesn't include
> anyone running workstation
> > > graphics applications or anyone in the film industry or anyone doing
> > > GPGPU work, or even casual gamers who want to play Quake every now &
> > > then.  I could go on and on, but I think my point is clear.  You're
> > > concept of "everyone else" is an extremely small percentage of the
> > > graphics market from a revenue perspective.
> >
> > Fair enough - from a revenue perspective. MS Windows also dominates
> > server OS sales - from a revenue perspective. Not true from a count of
> > installations, of course.
>  
>  We're talking about hardware, not software.  Please don't change the
>  focus just to bolster your argument. 
It's an analogy - see the parallels? The "power users" are of course the 
big spenders, so they will dominate the revenue picture. But most users 
simply do not need the power of the latest nvidia/ati hardware.


>  I'm saying that open sourcing a driver does not equate with
> support.
>  I'm sure that Intel does the best job that they can to support
>  whomever they deem as important to their business.  However,
>  pretending that just because they have open source drivers their
>  support is somehow better is delusional. 
So intel has open source drivers AND good support, and nvidia just has 
good support (well, for its direct OEM customers, at least).


> > 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.   
Exactly equal, perhaps :-)


>  No one here has yet to provide any concrete evidence to prove
>  otherwise. 
OK, how about the fact that kernel developers can't debug kernel<>driver 
relationship issues because the driver is closed? Hence the kernel 
bugzilla prohibition against reports from nvidia users? Does that not 
count as evidence?


- Mike

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; wrote:
>  Lonni J Friedman wrote:
>  >> OK, random example: where is the nvidia bug tracker? Pretty standard
>  >> support tool for anything linux-related - the kernel, xorg, gnome, kde,
>  >> openoffice...
>  >
>  > Its available to all of NVIDIA's customers.  If you have to ask where
>  > it is, then you're not an nvidia customer.
>
>  Hmm, I didn't order my Intel GPU direct from Intel either, but I can
>  still access the driver bugzilla. I guess you finally have some evidence
>  of how open source support can be better. 
Different perhaps.  I don't see how that makes it better other than
listing hundreds, if not thousands of bugs that haven't been fixed,
and may never be fixed.

>  > How is being forced to purchase a specific display device in
> order to
>  > use the GPU a lower hurdle than using any display device with the GPU?
>
>  You can plan for hardware requirements. The closed-source bugs and
>  kernel incompatibilities of the binary drivers are harder to manage. 
I'm sorry but I'm not following you here.  Are you stating that having
the source for the driver allows you to plan your hardware
requirements?  I find it hard to believe that any significant
percentage of people are reading the driver source in order to decide
whether they should purchase that hardware.

>  > Many people are editing movies on laptops.  Just not with Intel
> GPUs.
>
>  OK, agreed, they should use closed drivers and ati/nvidia hardware. 
I'm not even making that argument.  I'm just saying that people are
seemingly unaware that the market segment which finds Intel's graphics
offerings sufficient is a rather small segment from a revenue
perspective.  Most people are unaware of the fact that desktop usage
is not where most companies get the bulk of their revenue, other than
by sheer volume.  Its done either by quantity or quality.  And no, i'm
not implying that Intel's drivers or hardware are low quality, just
that they are going on quantity to make money.

>  > I'm saying that open sourcing a driver does not equate with
> support.
>  > I'm sure that Intel does the best job that they can to support
>  > whomever they deem as important to their business.  However,
>  > pretending that just because they have open source drivers their
>  > support is somehow better is delusional.
>
>  So intel has open source drivers AND good support, and nvidia just has
>  good support (well, for its direct OEM customers, at least). 
Again someone is throwing around the phrase "good support" yet not
defining it.  What defines good support?

>  >> 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.
>
>  Exactly equal, perhaps :-)
>
>
>  > No one here has yet to provide any concrete evidence to prove
>  > otherwise.
>
>  OK, how about the fact that kernel developers can't debug kernel<>driver
>  relationship issues because the driver is closed? Hence the kernel
>  bugzilla prohibition against reports from nvidia users? Does that not
>  count as evidence? 
Can't or won't?  I've seen many kernel backtraces from systems that
happened to have closed source drivers on them, where the backtrace
never even made a passing reference to the closed source driver and
the developers refused to look at it.  Sure, there's a chance that the
closed source driver contributed to, or even caused the problem, but
there's an even better chance that it was completely uninvolved.  This
stance seems more to do with religious zealotry than technical
limitations.  And its certainly their right to stand up for their
principles.  However, hiding behind them is something entirely
different.

DVI output, ATI or nVidia

[Dr. Michael J. Chudobiak]

> > Hmm, I didn't order my Intel GPU direct from Intel either,
> but I can
> > still access the driver bugzilla. I guess you finally have some evidence
> > of how open source support can be better.
>  
>  Different perhaps.  I don't see how that makes it better other than
>  listing hundreds, if not thousands of bugs that haven't been fixed,
>  and may never be fixed. 
Well, a list of unfixed bugs would tell you what bugs were real, how 
common they were, who you could contact to see if workarounds were 
found, what level of development is occurring, and whether your 
particular issue is likely to be addressed any time soon.


>  I'm sorry but I'm not following you here.  Are you stating
> that having
>  the source for the driver allows you to plan your hardware
>  requirements? 
No. I'm saying that in my experience, dealing with the hardware quirks 
and limitations imposed by the intel driver are easier to manage than 
the software quirks of the closed drivers.

Once you know you need DDC/DI, you buy NEC Multisyncs (or whatever). 
Problem solved. (And the driver developers have indicated that the 
DDC/DI requirement will be removed in the future, incidentally.)

Binary drivers and open kernels, however, make a square peg <> round 
hole system. It's just hard to maintain over the long-term.


>  I'm not even making that argument.  I'm just saying that
> people are
>  seemingly unaware that the market segment which finds Intel's graphics
>  offerings sufficient is a rather small segment from a revenue
>  perspective.  Most people are unaware of the fact that desktop usage
>  is not where most companies get the bulk of their revenue, other than
>  by sheer volume.  Its done either by quantity or quality.  And no, i'm
>  not implying that Intel's drivers or hardware are low quality, just
>  that they are going on quantity to make money. 
OK, nvidia doesn't want to spend the effort on a decent open source 
driver because the market isn't worth it. That's fine, and that's 
nvidia's call. But for the linux user, it sucks, and Intel's approach is 
better - for the average, non-movie-editing user. The nvidia approach 
only benefits power video users. Let's not pretend that nvidia is a good 
solution for the typical user.

Of course, it doesn't explain why nvidia doesn't actively support the 
nouveau driver.


>  Can't or won't?  I've seen many kernel backtraces from
> systems that
>  happened to have closed source drivers on them, where the backtrace
>  never even made a passing reference to the closed source driver and
>  the developers refused to look at it.  Sure, there's a chance that the
>  closed source driver contributed to, or even caused the problem, but
>  there's an even better chance that it was completely uninvolved.  This
>  stance seems more to do with religious zealotry than technical
>  limitations.  And its certainly their right to stand up for their
>  principles.  However, hiding behind them is something entirely
>  different. 
Hmm, kernel developers are religious zealots and I'm a fan boy. Did you 
run this past the PR department? :-)

The kernel developers are busy, why should they cooperate with you if 
you won't cooperate with them?


- Mike

DVI output, ATI or nVidia

[Lonni J Friedman]

On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; wrote:
>  >> Hmm, I didn't order my Intel GPU direct from Intel
> either, but I can
>  >> still access the driver bugzilla. I guess you finally have some evidence
>  >> of how open source support can be better.
>  >
>  > Different perhaps.  I don't see how that makes it better other than
>  > listing hundreds, if not thousands of bugs that haven't been fixed,
>  > and may never be fixed.
>
>  Well, a list of unfixed bugs would tell you what bugs were real, how
>  common they were, who you could contact to see if workarounds were
>  found, what level of development is occurring, and whether your
>  particular issue is likely to be addressed any time soon. 
All of that information is already readily available via the methods
documented in the NVIDIA driver README (and on its website).

>  > I'm sorry but I'm not following you here.  Are you
> stating that having
>  > the source for the driver allows you to plan your hardware
>  > requirements?
>
>  No. I'm saying that in my experience, dealing with the hardware quirks
>  and limitations imposed by the intel driver are easier to manage than
>  the software quirks of the closed drivers.
>
>  Once you know you need DDC/DI, you buy NEC Multisyncs (or whatever).
>  Problem solved. (And the driver developers have indicated that the
>  DDC/DI requirement will be removed in the future, incidentally.) 
I'm still amazed that you gloss over this nasty hurdle as if its
trivial.  If i've just spent a non-trivial amount of money on a
display, it should damn well work with my GPU.  Why would anyone even
think that this limitation would exist?

>  Binary drivers and open kernels, however, make a square peg <> round
>  hole system. It's just hard to maintain over the long-term. 
Considering how flawed your example above is, this seems like the pot
calling the kettle black.

>  > I'm not even making that argument.  I'm just saying that
> people are
>  > seemingly unaware that the market segment which finds Intel's graphics
>  > offerings sufficient is a rather small segment from a revenue
>  > perspective.  Most people are unaware of the fact that desktop usage
>  > is not where most companies get the bulk of their revenue, other than
>  > by sheer volume.  Its done either by quantity or quality.  And no, i'm
>  > not implying that Intel's drivers or hardware are low quality, just
>  > that they are going on quantity to make money.
>
>  OK, nvidia doesn't want to spend the effort on a decent open source
>  driver because the market isn't worth it. That's fine, and that's
>  nvidia's call. But for the linux user, it sucks, and Intel's approach is
>  better - for the average, non-movie-editing user. The nvidia approach
>  only benefits power video users. Let's not pretend that nvidia is a good
>  solution for the typical user. 
You can pretend whatever you'd like.  I'm basing my statements on reality.

>  > Can't or won't?  I've seen many kernel backtraces
> from systems that
>  > happened to have closed source drivers on them, where the backtrace
>  > never even made a passing reference to the closed source driver and
>  > the developers refused to look at it.  Sure, there's a chance that the
>  > closed source driver contributed to, or even caused the problem, but
>  > there's an even better chance that it was completely uninvolved.  This
>  > stance seems more to do with religious zealotry than technical
>  > limitations.  And its certainly their right to stand up for their
>  > principles.  However, hiding behind them is something entirely
>  > different.
>
>  Hmm, kernel developers are religious zealots and I'm a fan boy. Did you
>  run this past the PR department? :-) 
I'm not speaking for my employer anywhere in this thread.  I'm
speaking for myself.

>  The kernel developers are busy, why should they cooperate with you if
>  you won't cooperate with them? 
No where was I asking any kernel developers to "cooperate" with me.
If random Joe User is having a problem, random Joe User shouldn't be
punished by kernel developers.  Or at the very least those kernel
developers should be honest about why they don't want to debug the
problem, rather than hiding behind a "binary driver, we can't debug
this, go away" statement.

DVI output, ATI or nVidia

[Todd Zullinger]

Lonni J Friedman wrote:
>  If random Joe User is having a problem, random Joe User shouldn't
> be
>  punished by kernel developers.  Or at the very least those kernel
>  developers should be honest about why they don't want to debug the
>  problem, rather than hiding behind a "binary driver, we can't debug
>  this, go away" statement. 
In my limited reading (and probably equally limited understanding), it
seems that more than a few kernel developers have been far down the
trail on a bug too many times only to find that the problem was caused
by some binary driver.  That's a huge waste of time for them and it
doesn't seem at all unreasonable to say "make sure the problem is
reproducable without the binary driver before expecting us to debug
it."

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gun control to end crime is like abolishing sex to prevent rape.

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

[Jonathan Dieter]

On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
>  On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt;
> 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?

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.

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.

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.

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.

Jonathan

[1]http://www.nvnews.net/vbulletin/showthread.php?t=80888#13

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

[Walter Garcia-Fontes]

* Jonathan Dieter [27/06/07 17:23]:
>  On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
>  > On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; 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.
>  >  
It also escapes to me completely why a hardware producer would like to
have close-source drivers, since it does not sell software but
hardware. What does it gain? If the driver was open code, would it
loose any revenues? Is it giving any information to competing hardware
producers? 

-- 
Walter Garcia-Fontes               
Barcelona

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

[Lonni J Friedman]

On 6/27/07, Walter Garcia-Fontes <walter.garcia(a)upf.edu&gt; wrote:
>  * Jonathan Dieter [27/06/07 17:23]:
>  > On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
>  > > On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; 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.
>  > >
>
>  It also escapes to me completely why a hardware producer would like to
>  have close-source drivers, since it does not sell software but
>  hardware. What does it gain? If the driver was open code, would it
>  loose any revenues? Is it giving any information to competing hardware
>  producers? 
I think you've answered your own questions.

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

[Tim]

On Wed, 2007-06-27 at 17:35 +0200, Walter Garcia-Fontes wrote:
>  It also escapes to me completely why a hardware producer would like
> to
>  have close-source drivers, since it does not sell software but
>  hardware. What does it gain? If the driver was open code, would it
>  loose any revenues? Is it giving any information to competing hardware
>  producers?  
Closed source doesn't stop copycats.  They can hook up logic analysers
and see how the hardware works.  They can pull apart boards and work out
the wiring and parts.  They can decompile software and firmware, to
discover its operating principles.  They may not make a perfect clone,
but they may have discovered all the tricks that the original
manufacturer made, to make their own similar product that works just as
well, or even better.

Just about all electronic devices are open source, so to speak.  There's
nothing really secret about how a television set works, even a
particular model.  Likewise for a personal stereo system, or a telephone
exchange.  Yet none of those devices have their sales killed.  They even
benefit from being able to check on each other, and avoid dumb ideas.

All closed source does it make it more difficult for someone to work on
without all the toys that I talked about in the first paragraph.  I
think the wealth of what can be done with open source on Linux, and
other OSs, does demonstrate why it's good.

-- 
[tim@bigblack ~]$ rm -rfd /*^H^H^H^H^H^H^H^H^H^Huname -ipr
2.6.21-1.3228.fc7 i686 i386

Using FC 4, 5, 6 & 7, plus CentOS 5.  Today, it's FC7.

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

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

[Robin Laing]

Tim wrote:
>  On Wed, 2007-06-27 at 17:35 +0200, Walter Garcia-Fontes wrote:
> > It also escapes to me completely why a hardware producer would like to
> > have close-source drivers, since it does not sell software but
> > hardware. What does it gain? If the driver was open code, would it
> > loose any revenues? Is it giving any information to competing hardware
> > producers? 
>  
>  Closed source doesn't stop copycats.  They can hook up logic analysers
>  and see how the hardware works.  They can pull apart boards and work out
>  the wiring and parts.  They can decompile software and firmware, to
>  discover its operating principles.  They may not make a perfect clone,
>  but they may have discovered all the tricks that the original
>  manufacturer made, to make their own similar product that works just as
>  well, or even better.
>  
>  Just about all electronic devices are open source, so to speak.  There's
>  nothing really secret about how a television set works, even a
>  particular model.  Likewise for a personal stereo system, or a telephone
>  exchange.  Yet none of those devices have their sales killed.  They even
>  benefit from being able to check on each other, and avoid dumb ideas.
>  
>  All closed source does it make it more difficult for someone to work on
>  without all the toys that I talked about in the first paragraph.  I
>  think the wealth of what can be done with open source on Linux, and
>  other OSs, does demonstrate why it's good.
>   
But doing this takes time and allows a company some time to market their 
product and make some money from it.

Of course if you reverse engineer a product, you could open yourself to 
legal headaches in the USA due to the DMCA.

-- 
Due to the move to M$ Exchange Server,
    anything that is a priority, please phone.
Robin Laing

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

[Lonni J Friedman]

On 6/27/07, Jonathan Dieter <jdieter(a)gmail.com&gt; wrote:
>  On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
>  > On 6/27/07, Dr. Michael J. Chudobiak <mjc(a)avtechpulse.com&gt; 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.

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

[Jonathan Dieter]

On Wed, 2007-06-27 at 08:37 -0700, Lonni J Friedman wrote:
>  On 6/27/07, Jonathan Dieter <jdieter(a)gmail.com&gt; 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