On 11/27/12, Doug <dmcgarr...@optonline.net> wrote: > On 11/26/2012 11:51 PM, Stefan Monnier wrote: >> The problem with proprietary drivers is of course that they're >> proprietary, but on top of that, they aren't as hassle-free to install >> and update.
> 1. Proprietary drivers are generally written by the folks who know the > product the best, and so have the best chance of working without bugs. Like Intel's graphics drivers? > 2. Unless you intend to modify the driver yourself by modifying the > underlying code, why should you care if it's proprietary? Are you serious? (Have you ever read the GPL license, or other documents with such grounds/ reasons/ positions?) Your statement implies bias on your part. Not necessarily, yet implied. Off the top of my head: 1) Obsolescence/backwaters issue: ability for others to modify means greater likelihood of fixes for drivers for older hardware. 2) Educational purposes: proprietary cannot be used to learn from, eg school, uni, personal, etc. 3) Tainting of Linux kernel: ie "frowned on" bug reports with Linux devs. 4) Blind trust requirement/ phoning home: must trust developer to not include code which is against my interests; code cannot be inspected, so no trust certainty pathway; drivers are in kernel, so are given trust at an OS level. 5) Custom kernels inflexibility: often times (at least in the past, I have no experience as of recent years) proprietary drivers == a limitation on compiling your own kernel, or lack of support for kernels provided with lesser known/ smaller distros. Want to run and learn about vservers, the latest rt-kernel for minimum-latency audio, ... ... then problem can be (I should say, has been, may be still is, if not today, may yet be). 6) Security by obscurity: delays in fixing of security bugs (without ability to verify the fix works, or doesn't introduce a new security bug) even if discovered. 6b) Inability to fix, or pay someone to fix, security bugs in proprietary closed code if you want to do that. 7) Built in to default install disks. Don't have to do separate download/ install step. 8) Libre/ freedom (I should have put this first): I actually care about freedom for freedoms' sake! We stand on the shoulders of giants in so many ways, not just technically; that old adage applies very well to freedom too, those freedoms we are free to be so careless about! The early K Desktop Environment, now KDE, developers decided it was worth a little short term effort and undoubtedly frustrations etc, to create a "more free" GUI desktop than had existed before. This spurred the GNOME project and today we have much truly libre GUI desktop software (if not ideally integrated yet) to choose from. 9) My point is, we ought to be celebrating those who are willing to suffer their time and effort, who sacrifice their short-term convenience, for our longer term strengthening of our freedoms. It is because those who've gone before have done so that we have so much freedom today (technically and otherwise). And google would undoubtedly find more. > 3. Probably come in both deb and rpm form, so should install easily on > most systems. Unlike libre drivers? I guess that at least for mainstream distros, there is a pathway to install your proprietary driver... that be convenient for those who want them, no? > 4. May even have instructions, which is more than can be said for most > Linux software! "most"? Does your definition of instructions be a file called "README.txt" with a file called "README" not counting? I guess proprietary drivers have the advantage of forums ... > 5. If it works when you install it, there should be no reason *ever* to > update it. "If it ain't broke, don't fix it!" --Ann Landers If you choose to use proprietary drivers, that's fine by me. They are their own reward, so to speak :) I can well believe, that in certain circumstances, and for certain purposes, proprietary drivers even have specific advantages which could be enumerated. I'm not overly interested in those myself, but that doesn't stop them satisfying yours or others' needs/ use cases etc. Anyway... back to life, Regards Zenaan -- 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/CAOsGNSQ01xeioserkywLu31n0dcuN=A2geWL56Fj=9mn15g...@mail.gmail.com