Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Wed, Apr 28, 2010 at 3:36 AM, James P. Wallen wrote: > > On 01/-10/-28163 02:59 PM, Boyd Stephen Smith Jr. wrote: >> [snip] >> Once you've got the hardware, you might as well use it, even if it >> requires >> non-free drivers. The manufacturer has already got their cut of what you >> paid; you are hurting none but yourself by not using it. You should try >> and >> avoid becoming dependent on that hardware, since that makes you dependent >> on >> non-free software. > > And, if I were stuck in a situation where I really, really needed to use > (for instance) proprietary drivers so that I could use the 3D acceleration > capabilities of the nvidia cards, or if I needed to use the wireless cards > that require proprietary firmware, I'd do so -- though it would irk me a > little bit, perhaps enough to goad me on into getting new hardware. > This is the issue with me, I would love to use open source or non proprietary stuff (firmware / blobs etc). But reality kick in some times - to get what I want done I have to compromise some times Alex [snip] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/t2q836a6dcf1004271502v664ff0dkd437cf38e2097...@mail.gmail.com
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On 01/-10/-28163 02:59 PM, Boyd Stephen Smith Jr. wrote: And I claim he would be better off using a card that doesn't use firmware[1] or uses free firmware, since non-free firmware is an issue for distributors and it's relatively easy to "accidentally" participate in distributing software in violation of its license. That's an interesting sticking point. In reality, the probability of my accidental participation in distribution of the software is probably pretty low, but I can certainly see the principle involved. I wouldn't want to be stuck without non-free available, but I recommend making hardware purchases that allow you to avoid non-free as much as possible. I'm gradually moving that way myself. (Desktop and laptop each need one driver from non-free.) That is most certainly my aim. Once you've got the hardware, you might as well use it, even if it requires non-free drivers. The manufacturer has already got their cut of what you paid; you are hurting none but yourself by not using it. You should try and avoid becoming dependent on that hardware, since that makes you dependent on non-free software. And, if I were stuck in a situation where I really, really needed to use (for instance) proprietary drivers so that I could use the 3D acceleration capabilities of the nvidia cards, or if I needed to use the wireless cards that require proprietary firmware, I'd do so -- though it would irk me a little bit, perhaps enough to goad me on into getting new hardware. It's not a religion, but the ideas are important to me. And, as I said, I'm also just genuinely interested in seeing how well I can do without the proprietary bits. The resolve is made all the stronger by my experiences in industry where I see what I think are some pretty unwise decisions being made by companies who are often unwittingly tying their fortunes irrevocably to the whims (business models, I think they call them) of other companies -- companies whose interests might (and do) run in a counter direction. The industries I've worked in might not have had very many choices (at least without incurring huge development costs) when making their hardware / software decisions. But, as an individual, I can do what I danged well please -- even if others may think that it looks like I'm just cutting off my nose to spite my face. ;) [1] "Firmware" here is specifically limited to executable data transmitted to the device from a host operating system, and does not include executable data loaded from an EEPROM (or similar) that is provided with the device. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd7208b.1000...@comcast.net
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Monday 26 April 2010 20:27:14 Celejar wrote: > On Mon, 26 Apr 2010 17:03:07 -0500 > "Boyd Stephen Smith Jr." wrote: > > On Monday 26 April 2010 16:34:36 Celejar wrote: > > > On Mon, 26 Apr 2010 16:16:32 -0500 > > > "Boyd Stephen Smith Jr." wrote: > > > > On Monday 26 April 2010 15:09:57 Celejar wrote: > > > > > What makes the non-free firmware question particularly interesting > > > > > is that the alternative is often to hardcode the functionality into > > > > > the hardware. Now, if you had a board with completely closed HW, > > > > > but that presented an open, well documented interface for the > > > > > driver, most people would be very happy (although there are, of > > > > > course, the open hardware crusaders - more power to them!). So, > > > > > now that they've simply implemented some of that functionality in > > > > > SW, in the form of firmware which the driver installs on the card, > > > > > but which has nothing to do with your host machine, are you really > > > > > any worse off? > > > > > > > > As a distributor you may very well be. If you can't provide the > > > > source code, you can't satisfy the terms of the GPL (usually). > > > > > > ? We're talking about firmware for things like wireless cards, > > > produced by the HW manufacturers, e.g., Broadcom. Where does the GPL > > > enter into this? > > > > Some are included in the tarball provided by the Linux kernel team, which > > is distributed under the GPLv2. In particular, I am thinking of the > > iwl3945 firmware that is required to run my wireless card. > > > > It doesn't matter what upstream wants to call source code. The GPL(v2) > > defines it as the preferred form for making modifications. (GPLv2, > > section 3.) It is unlikely that the firmware was written in a hex editor > > (or equivalent). Most likely it is C source for a freestanding > > (non-hosted) environment with some manufacturer-specific libraries, but > > it could also be in some manufacturer-specific assembly code. Either > > form would be better for making modifications than a binary blob. > > This is all very well, but the context of this subthread is James's > statement that he avoids installing the non-free firmware that his HW > requires out of a commitment to FLOSS ideals, to which I responded that > I'm not sure if one is really worse off installing such firmware, or > using a card that just has that logic built in to its non-free HW. And I claim he would be better off using a card that doesn't use firmware[1] or uses free firmware, since non-free firmware is an issue for distributors and it's relatively easy to "accidentally" participate in distributing software in violation of its license. I wouldn't want to be stuck without non-free available, but I recommend making hardware purchases that allow you to avoid non-free as much as possible. I'm gradually moving that way myself. (Desktop and laptop each need one driver from non-free.) Once you've got the hardware, you might as well use it, even if it requires non-free drivers. The manufacturer has already got their cut of what you paid; you are hurting none but yourself by not using it. You should try and avoid becoming dependent on that hardware, since that makes you dependent on non-free software. [1] "Firmware" here is specifically limited to executable data transmitted to the device from a host operating system, and does not include executable data loaded from an EEPROM (or similar) that is provided with the device. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Mon, 26 Apr 2010 17:03:07 -0500 "Boyd Stephen Smith Jr." wrote: > On Monday 26 April 2010 16:34:36 Celejar wrote: > > On Mon, 26 Apr 2010 16:16:32 -0500 > > "Boyd Stephen Smith Jr." wrote: > > > On Monday 26 April 2010 15:09:57 Celejar wrote: > > > > What makes the non-free firmware question particularly interesting is > > > > that the alternative is often to hardcode the functionality into the > > > > hardware. Now, if you had a board with completely closed HW, but that > > > > presented an open, well documented interface for the driver, most > > > > people would be very happy (although there are, of course, the open > > > > hardware crusaders - more power to them!). So, now that they've simply > > > > implemented some of that functionality in SW, in the form of firmware > > > > which the driver installs on the card, but which has nothing to do with > > > > your host machine, are you really any worse off? > > > > > > As a distributor you may very well be. If you can't provide the source > > > code, you can't satisfy the terms of the GPL (usually). > > > > ? We're talking about firmware for things like wireless cards, produced > > by the HW manufacturers, e.g., Broadcom. Where does the GPL enter into > > this? > > Some are included in the tarball provided by the Linux kernel team, which is > distributed under the GPLv2. In particular, I am thinking of the iwl3945 > firmware that is required to run my wireless card. > > It doesn't matter what upstream wants to call source code. The GPL(v2) > defines it as the preferred form for making modifications. (GPLv2, section > 3.) It is unlikely that the firmware was written in a hex editor (or > equivalent). Most likely it is C source for a freestanding (non-hosted) > environment with some manufacturer-specific libraries, but it could also be > in > some manufacturer-specific assembly code. Either form would be better for > making modifications than a binary blob. This is all very well, but the context of this subthread is James's statement that he avoids installing the non-free firmware that his HW requires out of a commitment to FLOSS ideals, to which I responded that I'm not sure if one is really worse off installing such firmware, or using a card that just has that logic built in to its non-free HW. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426212714.877e21f0.cele...@gmail.com
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Monday 26 April 2010 16:34:36 Celejar wrote: > On Mon, 26 Apr 2010 16:16:32 -0500 > "Boyd Stephen Smith Jr." wrote: > > On Monday 26 April 2010 15:09:57 Celejar wrote: > > > What makes the non-free firmware question particularly interesting is > > > that the alternative is often to hardcode the functionality into the > > > hardware. Now, if you had a board with completely closed HW, but that > > > presented an open, well documented interface for the driver, most > > > people would be very happy (although there are, of course, the open > > > hardware crusaders - more power to them!). So, now that they've simply > > > implemented some of that functionality in SW, in the form of firmware > > > which the driver installs on the card, but which has nothing to do with > > > your host machine, are you really any worse off? > > > > As a distributor you may very well be. If you can't provide the source > > code, you can't satisfy the terms of the GPL (usually). > > ? We're talking about firmware for things like wireless cards, produced > by the HW manufacturers, e.g., Broadcom. Where does the GPL enter into > this? Some are included in the tarball provided by the Linux kernel team, which is distributed under the GPLv2. In particular, I am thinking of the iwl3945 firmware that is required to run my wireless card. It doesn't matter what upstream wants to call source code. The GPL(v2) defines it as the preferred form for making modifications. (GPLv2, section 3.) It is unlikely that the firmware was written in a hex editor (or equivalent). Most likely it is C source for a freestanding (non-hosted) environment with some manufacturer-specific libraries, but it could also be in some manufacturer-specific assembly code. Either form would be better for making modifications than a binary blob. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Mon, 26 Apr 2010 16:16:32 -0500 "Boyd Stephen Smith Jr." wrote: > On Monday 26 April 2010 15:09:57 Celejar wrote: ... > > What makes the non-free firmware question particularly interesting is > > that the alternative is often to hardcode the functionality into the > > hardware. Now, if you had a board with completely closed HW, but that > > presented an open, well documented interface for the driver, most > > people would be very happy (although there are, of course, the open > > hardware crusaders - more power to them!). So, now that they've simply > > implemented some of that functionality in SW, in the form of firmware > > which the driver installs on the card, but which has nothing to do with > > your host machine, are you really any worse off? > > As a distributor you may very well be. If you can't provide the source code, > you can't satisfy the terms of the GPL (usually). ? We're talking about firmware for things like wireless cards, produced by the HW manufacturers, e.g., Broadcom. Where does the GPL enter into this? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426173436.20bb15d2.cele...@gmail.com
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Monday 26 April 2010 15:09:57 Celejar wrote: > On Mon, 26 Apr 2010 08:03:24 -0400 > "James P. Wallen" wrote: > > On 01/-10/-28163 02:59 PM, Celejar wrote: > > > On Sat, 24 Apr 2010 09:53:27 -0400 > > > "James P. Wallen" wrote: > > >> Heck, I haven't even installed the non-free firmware to make wireless > > >> work in a couple of these notebooks. > > > > > > Firmware runs on the external hardware, not the system, so system > > > stability shouldn't be an issue. I assume that here it's just the > > > principle of the thing. > > > > What makes the non-free firmware question particularly interesting is > that the alternative is often to hardcode the functionality into the > hardware. Now, if you had a board with completely closed HW, but that > presented an open, well documented interface for the driver, most > people would be very happy (although there are, of course, the open > hardware crusaders - more power to them!). So, now that they've simply > implemented some of that functionality in SW, in the form of firmware > which the driver installs on the card, but which has nothing to do with > your host machine, are you really any worse off? As a distributor you may very well be. If you can't provide the source code, you can't satisfy the terms of the GPL (usually). Firmware is often simply provided as raw bytes. It is rarely actually developed that way. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Mon, 26 Apr 2010 08:03:24 -0400 "James P. Wallen" wrote: > > > On 01/-10/-28163 02:59 PM, Celejar wrote: > > On Sat, 24 Apr 2010 09:53:27 -0400 > > "James P. Wallen" wrote: > > > > ... > > > >> Heck, I haven't even installed the non-free firmware to make wireless > >> work in a couple of these notebooks. > > > > Firmware runs on the external hardware, not the system, so system > > stability shouldn't be an issue. I assume that here it's just the > > principle of the thing. > > > > Celejar > > I'd characterize it as a combination of principle and curiosity. I > really want to see how well I can accomplish what I want to do and what > I need to do using only FOSS. I'm relatively new to GNU/Linux, but I've > had very few problems that were at all difficult to resolve. Come to > think of it, the only problems that were absolutely indomitable were > caused by the use of non-free software / drivers in my earlier forays > into the various distributions. I guess those experiences have > strengthened my resolve to stick with FOSS. What makes the non-free firmware question particularly interesting is that the alternative is often to hardcode the functionality into the hardware. Now, if you had a board with completely closed HW, but that presented an open, well documented interface for the driver, most people would be very happy (although there are, of course, the open hardware crusaders - more power to them!). So, now that they've simply implemented some of that functionality in SW, in the form of firmware which the driver installs on the card, but which has nothing to do with your host machine, are you really any worse off? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100426160957.ac880f31.cele...@gmail.com
Re: Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On 01/-10/-28163 02:59 PM, Celejar wrote: On Sat, 24 Apr 2010 09:53:27 -0400 "James P. Wallen" wrote: ... Heck, I haven't even installed the non-free firmware to make wireless work in a couple of these notebooks. Firmware runs on the external hardware, not the system, so system stability shouldn't be an issue. I assume that here it's just the principle of the thing. Celejar I'd characterize it as a combination of principle and curiosity. I really want to see how well I can accomplish what I want to do and what I need to do using only FOSS. I'm relatively new to GNU/Linux, but I've had very few problems that were at all difficult to resolve. Come to think of it, the only problems that were absolutely indomitable were caused by the use of non-free software / drivers in my earlier forays into the various distributions. I guess those experiences have strengthened my resolve to stick with FOSS. I have to admit that GoogleEarth would be a nice thing to have. Jim -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd5810c.7000...@comcast.net
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Sat, 24 Apr 2010 09:53:27 -0400 "James P. Wallen" wrote: ... > Heck, I haven't even installed the non-free firmware to make wireless > work in a couple of these notebooks. Firmware runs on the external hardware, not the system, so system stability shouldn't be an issue. I assume that here it's just the principle of the thing. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100425152941.47f9c918.cele...@gmail.com
Re: Re: The future of "nv" driver
On Sun, Apr 25, 2010 at 08:55:52AM -0400, James P. Wallen wrote: > Hmmm. Maybe Debian could set up "activation servers" that could > determine whether or not we are using "genuine Debian". Hmm... sounds like an interesting feature request for vrms. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100425134506.ga16...@pear.tzafrir.org.il
Re: The future of "nv" driver
On 04/25/2010 07:55 AM, James P. Wallen wrote: [snip] Hmmm. Maybe Debian could set up "activation servers" that could determine whether or not we are using "genuine Debian". But seriously... each kernel module has a "license" field, so if a non-GPL module gets installed, the kernel knows. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd442f5.6050...@cox.net
Re: Re: The future of "nv" driver
On Sun, Apr 25, 2010 at 13:55, James P. Wallen wrote: > Hmmm. Maybe Debian could set up "activation servers" that could determine > whether or not we are using "genuine Debian". Eeww creepy... -- () ascii-rubanda kampajno - kontraŭ html-a retpoŝto /\ ascii ribbon campaign - against html e-mail -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/r2u6b1504c41004250616o93977a5x2cddeeb0e7f85...@mail.gmail.com
Re: Re: The future of "nv" driver
On 01/-10/-28163 02:59 PM, Mark Allums wrote: On 4/24/2010 7:31 AM, John Hasler wrote: Mark Allums writes: Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, apparently.) No. A matter of support. Okay. But perhaps a less loaded word than "taint" could be chosen. MAA I always had the feeling that "tainted" was not so much meant to be derogatory as to indicate that the use of proprietary blobs introduce unknown elements into the kernel. If I brought a glass of purple water down to the local water purification plant and complained that their water tasted like grapes, they'd tell me it wasn't their problem that I'd added grape kool-aid to it. Same thing. Well, except for that fact that it's a crappy analogy. ;) Hmmm. Maybe Debian could set up "activation servers" that could determine whether or not we are using "genuine Debian". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd43bd8.3050...@comcast.net
Re: The future of "nv" driver
On 4/24/2010 7:31 AM, John Hasler wrote: Mark Allums writes: Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, apparently.) No. A matter of support. Okay. But perhaps a less loaded word than "taint" could be chosen. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3db06.40...@allums.com
Re: The future of "nv" driver
I occasionally turn on Xfce's compositing for specific tasks in which it actually makes my work easier. But most if the time, it's off. How do you enable it? Did you also have to add something to xorg.conf? Desktop compositing in Xfce? I just turn it on in the Compositing tab of the Window Manager Tweaks applet. No fiddling with xorg.conf necessary. What about GoogleEarth? I don't use it. I guess I ought to look into it. My brother showed me a really fantastic use he made of it for tracing the path of a priest through Colorado and Kansas in the 1600s for an anthropology paper he was doing. Just what I need, another way to spend time at a computer. But I have to admit that it's a fascinating application, despite my curmudgeonly tendency to scoff at fancy browser stuff. I don't suppose the bits are open source? If not, I'll probably be passing. Eh, maybe I could talk myself into running it in a virtual machine. ;) and I'm happier with them. Nvidia is simply not on my radar for any future systems because I consider their approach to Linux to be inimical to FOSS. That's a reasonable position to take... Well, I'm seldom accused of being reasonable. But I figure I can be unreasonable with my own systems. Thank you for the reminder of GoogleEarth. I've been so busy since I saw my brother that I had let it slip from my mind. Or it could just be old age. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3ae7c.9030...@comcast.net
Re: Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On 01/-10/-28163 02:59 PM, Ron Johnson wrote: > That's one difference between us: I don't use Compiz. That's not a difference. I don't use it, either. My use of Compiz was just a part of exploration of the Gnome DE. I don't even use Gnome now. > ... because I don't need glitzy special effects. Neither do I. That's why I use Xfce. > Are there any non-glitzy benefits to compositors? I occasionally turn on Xfce's compositing for specific tasks in which it actually makes my work easier. But most if the time, it's off. > Which driver version do you use? nv - Debian Squeeze Gave up finally in December last year trying to get the blobs to work reliably. They're simply not worth the effort for someone with my particular needs. I'm reasonably happy with the systems with the nvidia workstation cards. But the cheaper systems with Intel and ATI graphics are faster and handle any special effects I might want (like occasional use of desktop compositing) better, and I'm happier with them. Nvidia is simply not on my radar for any future systems because I consider their approach to Linux to be inimical to FOSS. PS: My apologies. Recent update to my mail client coupled with lack of sleep. I accidentally sent Ron a direct e-mail reply. Mea culpa. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd37aa0.2040...@comcast.net
Re: The future of "nv" driver
On 04/24/2010 04:09 PM, John Hasler wrote: Mark Allums writes: Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, apparently.) I wrote: No. A matter of support. Device driver bugs can cause crashes in apparently unrelated parts of the kernel. Ron Johnson writes: I must not stress my system enough, because even using the nvidia driver, my machine is rock stable. I didn't mean to imply that the Nvidia drivers were particularly buggy. It's just that when kernels with Nvidia drivers do crash (whether due to bugs in the Nvidia stuff or elsewhere) the kernel maintainers can't properly debug it because the don't have all the source. Since Nvidia does have all the source they refer you to Nvidia. They came up with the "taint" device as a automated way to warn them of the presence of closed-source drivers since the users often don't know. Exactly. Which is why I wrote "Which is perfectly reasonable..." in my reply to you. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd372f8.3040...@cox.net
Re: The future of "nv" driver
Mark Allums writes: > Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, > apparently.) I wrote: > No. A matter of support. Device driver bugs can cause crashes in > apparently unrelated parts of the kernel. Ron Johnson writes: > I must not stress my system enough, because even using the nvidia > driver, my machine is rock stable. I didn't mean to imply that the Nvidia drivers were particularly buggy. It's just that when kernels with Nvidia drivers do crash (whether due to bugs in the Nvidia stuff or elsewhere) the kernel maintainers can't properly debug it because the don't have all the source. Since Nvidia does have all the source they refer you to Nvidia. They came up with the "taint" device as a automated way to warn them of the presence of closed-source drivers since the users often don't know. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eii48sn0@thumper.dhh.gt.org
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On 04/24/2010 08:53 AM, James P. Wallen wrote: On 01/-10/-28163 02:59 PM, Ron Johnson wrote: On 04/22/2010 08:49 AM, Stephen Powell wrote: [snip] I shall now avoid, when possible, computers with Nvidia graphics cards. Except that Nvidia's drivers are still *much* better than ATI's drivers. Insofar as my experience goes I'd have to qualify that with a /sometimes/ they are better... I've got a couple of fairly high-end Quadro graphics workstation cards that have given me fits in every distro I've tried. If I used restricted / blob / proprietary / whatever drivers -- whether I got them directly from nvidia or from distro-associated repositories -- the result was always that bits and pieces of the desktop environment would break from time-to-time. Trying to use Compiz under Gnome could be a nightmare. That's one difference between us: I don't use Compiz. Using the nv drivers has at least always left me with a reliable system, albeit without much in the way of glitzy special effects. ... because I don't need glitzy special effects. Are there any non-glitzy benefits to compositors? Right now I run a bunch of systems with ATI, integrated Intel, and the Quadro cards in them. I've settled happily into Debian Squeeze with Xfce. The desktop compositing in Xfce 4.6.1 even works with the nv drivers -- but very, very slowly. The far cheaper ATI and Intel graphics subsystems are snappy and responsive with the same environment. If I use the binary blob nvidia driver, I get fast, snappy -- and unreliable. Which driver version do you use? I don't like that. And I don't like nvidia's attitude. I came over to GNU/Linux because I was tired of feeling that I was being screwed over in the name of business models and IP. I won't be buying any more nvidia stuff, either. Heck, I haven't even installed the non-free firmware to make wireless work in a couple of these notebooks. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd34603.1050...@cox.net
Re: The future of "nv" driver
On 04/24/2010 01:14 PM, Stephen Powell wrote: [snip] I agree. I do not willingly use non-free software. I only use it if it's the only thing that will work. I might change my mind if the Nouveau driver gets picked up by X.Org and there's a standard Debian package for it, and it works reliably. But for now, no more Nvidia. And next question is, "Now what?" ATI? -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3438d.20...@cox.net
Re: The future of "nv" driver
On 04/24/2010 07:31 AM, John Hasler wrote: Mark Allums writes: Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, apparently.) No. A matter of support. Device driver bugs can cause crashes in apparently unrelated parts of the kernel. I must not stress my system enough, because even using the nvidia driver, my machine is rock stable. Thus in order to properly debug kernel problems it is necessary to have complete source. When you install a closed-source driver part of the kernel source is hidden from the kernel maintainers, thus "tainting" the kernel. The maintainers suggest that you ask whoever supplied the closed-source code for support as only they have complete source for the kernel that you are having trouble with. Which is perfectly reasonable... -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3434a.4070...@cox.net
Re: The future of "nv" driver
On Sat, 24 Apr 2010 05:24:14 -0500 Mark Allums wrote: Hello Mark, > I've never understood the use of the word "taint" in this context. For some people, maintaining a system with FLOSS software is of the utmost importance. To them, adding stuff like the Nvidia drivers, acroread, or any other software that has a non-free EULA would "taint" their goal. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" Just stop and take a second U & Ur Hand - P!nk signature.asc Description: PGP signature
Re: Re: The future of "nv" driver
On 01/-10/-28163 02:59 PM, Mark Allums wrote: On 4/24/2010 6:26 AM, Sven Joachim wrote: On 2010-04-24 12:24 +0200, Mark Allums wrote: I've never understood the use of the word "taint" in this context. It means the same as "contaminate". The practical consequence is that nobody will accept bug reports against the kernel if the nvidia module is loaded. http://www.kernel.org/pub/linux/docs/lkml/#s1-18 http://kerneltrap.org/node/5616 Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, apparently.) Sorry, I must respectfully disagree, although I do acknowledge the practical problem of getting your machine running properly when no one will read your reports. MAA One of the primary reasons I started using GNU/Linux was that I was really tired of being stonewalled when looking for explanations for system functions and malfunctions. Trying to figure out a problem by looking through data that is limited to what the associated proprietary interests think you ought to know is no fun. I'd say that it's not a matter of taste so much as a matter of practicality. I wanted control of the systems that hold my data. This is where I found that control. And, yeah, I'm tired of vendors who think that they own me. I deal with enough of that crap at work. <>
Re: Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On 01/-10/-28163 02:59 PM, Ron Johnson wrote: On 04/22/2010 08:49 AM, Stephen Powell wrote: [snip] I shall now avoid, when possible, computers with Nvidia graphics cards. Except that Nvidia's drivers are still *much* better than ATI's drivers. Insofar as my experience goes I'd have to qualify that with a /sometimes/ they are better... I've got a couple of fairly high-end Quadro graphics workstation cards that have given me fits in every distro I've tried. If I used restricted / blob / proprietary / whatever drivers -- whether I got them directly from nvidia or from distro-associated repositories -- the result was always that bits and pieces of the desktop environment would break from time-to-time. Trying to use Compiz under Gnome could be a nightmare. Using the nv drivers has at least always left me with a reliable system, albeit without much in the way of glitzy special effects. Right now I run a bunch of systems with ATI, integrated Intel, and the Quadro cards in them. I've settled happily into Debian Squeeze with Xfce. The desktop compositing in Xfce 4.6.1 even works with the nv drivers -- but very, very slowly. The far cheaper ATI and Intel graphics subsystems are snappy and responsive with the same environment. If I use the binary blob nvidia driver, I get fast, snappy -- and unreliable. I don't like that. And I don't like nvidia's attitude. I came over to GNU/Linux because I was tired of feeling that I was being screwed over in the name of business models and IP. I won't be buying any more nvidia stuff, either. Heck, I haven't even installed the non-free firmware to make wireless work in a couple of these notebooks. <>
Re: The future of "nv" driver
Mark Allums writes: > Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, > apparently.) No. A matter of support. Device driver bugs can cause crashes in apparently unrelated parts of the kernel. Thus in order to properly debug kernel problems it is necessary to have complete source. When you install a closed-source driver part of the kernel source is hidden from the kernel maintainers, thus "tainting" the kernel. The maintainers suggest that you ask whoever supplied the closed-source code for support as only they have complete source for the kernel that you are having trouble with. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3xp9gmr@thumper.dhh.gt.org
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
> The VESA driver is not adequate > for many users. If I recall correctly, the VESA driver only makes > use of video graphics modes supported by the video BIOS. These video > modes often cannot exploit the maximum video resolution available on > many modern LCD displays. This was the main reason for nVidia to support their "nv" driver : offering correct user experience (i.e. avoid the Vesa driver) just after the installation of the OS, and until they install their proprietary driver for full functionnality. However, with the state of the (open-source) "Nouveau" driver, there is no real reason anymore for nVidia to support "nv"... You might want to read this : http://www.phoronix.com/scan.php?page=article&item=nvidia_kills_nv&num=1 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1272112145.1787.10.ca...@jf-desktop
Re: The future of "nv" driver
On 4/24/2010 6:26 AM, Sven Joachim wrote: On 2010-04-24 12:24 +0200, Mark Allums wrote: I've never understood the use of the word "taint" in this context. It means the same as "contaminate". The practical consequence is that nobody will accept bug reports against the kernel if the nvidia module is loaded. http://www.kernel.org/pub/linux/docs/lkml/#s1-18 http://kerneltrap.org/node/5616 Ah, a matter of taste, then. (Debian tastes bad with Nvidia loaded, apparently.) Sorry, I must respectfully disagree, although I do acknowledge the practical problem of getting your machine running properly when no one will read your reports. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd2dc66.7080...@allums.com
Re: The future of "nv" driver
On 2010-04-24 12:24 +0200, Mark Allums wrote: > On 4/24/2010 5:11 AM, Sven Joachim wrote: >>> Except that Nvidia's drivers are still *much* better than ATI's drivers. >> >> Only the proprietary ones, and not everybody wants to taint their system >> with these non-free blobs. > > I've never understood the use of the word "taint" in this context. It means the same as "contaminate". The practical consequence is that nobody will accept bug reports against the kernel if the nvidia module is loaded. http://www.kernel.org/pub/linux/docs/lkml/#s1-18 http://kerneltrap.org/node/5616 Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aasthz0e@turtle.gmx.de
Re: The future of "nv" driver
On 4/24/2010 5:11 AM, Sven Joachim wrote: Except that Nvidia's drivers are still *much* better than ATI's drivers. Only the proprietary ones, and not everybody wants to taint their system with these non-free blobs. I've never understood the use of the word "taint" in this context. [Possibly private] Explanation? MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd2c6ce.7090...@allums.com
Re: The future of "nv" driver
On 2010-04-24 01:18 +0200, Ron Johnson wrote: > On 04/22/2010 08:49 AM, Stephen Powell wrote: > [snip] >> >> I shall now avoid, when possible, computers with Nvidia graphics cards. >> > > Except that Nvidia's drivers are still *much* better than ATI's drivers. Only the proprietary ones, and not everybody wants to taint their system with these non-free blobs. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq7hi2ix@turtle.gmx.de
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On 04/22/2010 08:49 AM, Stephen Powell wrote: [snip] I shall now avoid, when possible, computers with Nvidia graphics cards. Except that Nvidia's drivers are still *much* better than ATI's drivers. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd22ad4.3060...@cox.net
Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Wed, 21 Apr 2010 17:36:27 -0400 (EDT), Camaleón wrote: > > Let me "copy/paste" from the official announcemnet¹: > > *** > "(...) For this reason, NVIDIA is dropping support, on new GPUs, for the > xf86-video-nv driver. > > Details: > > - NVIDIA will continue to support the existing functionality and > existing level of acceleration in the nv driver for existing GPUs, > on existing, and (within reason) future, X server versions. > > - NVIDIA will not support the xf86-video-nv driver on Fermi or > later GPUs. > > - NVIDIA will not support DisplayPort, on any GPU, in the > xf86-video-nv driver." > *** > > ¹ http://lists.freedesktop.org/archives/xorg/2010-March/049749.html I am disappointed to hear of Nvidia's increasing hostility to open source video drivers. It's one thing to withhold source code for 3D graphics accelerated drivers. It's another thing to not support an open source driver at all. The VESA driver is not adequate for many users. If I recall correctly, the VESA driver only makes use of video graphics modes supported by the video BIOS. These video modes often cannot exploit the maximum video resolution available on many modern LCD displays. I shall now avoid, when possible, computers with Nvidia graphics cards. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/470756615.230941.1271944177380.javamail.r...@md01.wow.synacor.com
