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
On 6/26/07, Mario Rossi mariofutire@googlemail.com 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.
On Tue, 26 Jun 2007, Lonni J Friedman wrote:
On 6/26/07, Mario Rossi mariofutire@googlemail.com 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.)
On 6/26/07, alan alan@clueserver.org wrote:
On Tue, 26 Jun 2007, Lonni J Friedman wrote:
On 6/26/07, Mario Rossi mariofutire@googlemail.com 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.
On Tue, 26 Jun 2007 14:03:16 -0700 "Lonni J Friedman" netllama@gmail.com 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:
On 6/26/07, Tom Horsley tom.horsley@att.net wrote:
On Tue, 26 Jun 2007 14:03:16 -0700 "Lonni J Friedman" netllama@gmail.com 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:
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.
Lonni J Friedman wrote:
For the sort of thing open source can provide even without actually "fixing" a bug myself, see:
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
On Tue, 26 Jun 2007 14:03:16 -0700 Lonni J Friedman netllama@gmail.com 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.
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
On 6/27/07, Dr. Michael J. Chudobiak mjc@avtechpulse.com 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.
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
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
On 6/27/07, Dr. Michael J. Chudobiak mjc@avtechpulse.com 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.
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
On 6/27/07, Dr. Michael J. Chudobiak mjc@avtechpulse.com 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.
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
On 6/27/07, Dr. Michael J. Chudobiak mjc@avtechpulse.com 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.
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."
On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
On 6/27/07, Dr. Michael J. Chudobiak mjc@avtechpulse.com 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
* 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@avtechpulse.com 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?
On 6/27/07, Walter Garcia-Fontes walter.garcia@upf.edu 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@avtechpulse.com 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.
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 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.
On 6/27/07, Jonathan Dieter jdieter@gmail.com wrote:
On Wed, 2007-06-27 at 07:34 -0700, Lonni J Friedman wrote:
On 6/27/07, Dr. Michael J. Chudobiak mjc@avtechpulse.com 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.
On Wed, 2007-06-27 at 08:37 -0700, Lonni J Friedman wrote:
On 6/27/07, Jonathan Dieter jdieter@gmail.com 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