From: Arjan van de Ven <arjan@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: 3D video card recommendations
Date: Mon, 07 Nov 2005 08:42:23 +0100 [thread overview]
Message-ID: <1131349343.2858.11.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <1131112605.14381.34.camel@localhost.localdomain>
On Fri, 2005-11-04 at 08:56 -0500, Steven Rostedt wrote:
> I'm currently putting together (ordering parts for) another machine. It
> will be a AMD64 X2. Now I'm looking into a video card for this. Up till
> now, I've always used NVidia. But I also want to test 3D acceleration
> under Ingo's -rt patch. So now I need something that does not have a
> priority module.
>
> I'm not much of a gamer, although I do play every so often. So I don't
> need the highest quality card, but I also want something that is still
> pretty good. For example, I currently have a NVidia GeForce 6800 GT
> card. So I'm hoping to get something equivalent.
people who buy a 3D card for linux that depends on a closed source
module take a few risks, and they should be aware of them (I suspect
they are) so let me make some of them explicit:
By buying a piece of hardware that requires a closed module you take the
risk that one of the following can happen at any time
1) The vendor in the future stops considering linux important and you're
stuck with old kernels; for example as a side-effect of getting a good
deal to supply graphics chips to a certain game console maker
2) The vendor in the future stops considering the hardware you bought
important enough to spend time on; after all they got their cash and the
product cycles for consumer hardware are often in the 3 to 6 month
timeframe. Result: you're stuck with old kernels.
3) The vendor gets sued and convicted for GPL violations and stops doing
linux as a result. (not saying it will happen, but it sure is a risk you
are taking)
4) The linux kernel developers change the kernel in a way that the
module in question no longer is possible and the vendor stops updating
the driver
5) The vendor goes out of business and thus stops updating the driver
6) The vendor doesn't release an x86-64 binary (or other architecture)
and your next PC can't use the module anymore
7) The vendor starts charging money for the driver or updates thereof.
Open source is not just something for developers, but also for users. It
means that you or anyone else can keep the open driver going even when
the manufacturer stops doing so. By using a closed driver you get all
the disadvantages of the open source model (yes there are some just that
normally the benefits outweigh them by far) without getting the gains.
Be very sure you want to do this before spending your hard earned money
on hardware that doesn't work without closed drivers.
next prev parent reply other threads:[~2005-11-07 7:42 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-04 13:56 Steven Rostedt
2005-11-04 15:10 ` Mark Knecht
2005-11-04 15:14 ` Paweł Sikora
2005-11-04 15:22 ` Steven Rostedt
[not found] ` <ec92bc30511040730g2ad412ddsb3ac63f701de6c97@mail.gmail.com>
2005-11-04 15:39 ` Anshuman Gholap
2005-11-06 23:46 ` Nix
2005-11-07 7:42 ` Arjan van de Ven [this message]
2005-11-07 12:42 ` Steven Rostedt
2005-11-07 12:55 ` Hugo Mills
2005-11-07 14:22 ` Paweł Sikora
2005-11-07 15:07 ` Paweł Sikora
2005-11-07 14:51 ` Ville Syrjälä
2005-11-07 15:50 ` Jerome Glisse
2005-11-07 16:24 ` Gerhard Mack
2005-11-07 16:35 ` Ian Romanick
2005-11-07 16:41 ` Ville Syrjälä
2005-11-07 14:24 ` Alan Cox
2005-11-07 13:59 ` Xavier Bestel
2005-11-07 16:17 ` Gerhard Mack
2005-11-07 15:20 ` Toon van der Pas
2005-11-07 15:31 ` Arjan van de Ven
2005-11-07 17:35 ` Steven Rostedt
2005-11-08 22:08 ` Matthias Andree
2005-11-08 22:18 ` John Stoffel
2005-11-08 22:37 ` Tue, 8 Nov 2005 23:37:43 +0100
2005-11-09 1:34 ` Alan Cox
2005-11-07 17:00 ` Diego Calleja
2005-11-07 17:30 ` Steven Rostedt
2005-11-07 17:44 ` Gerhard Mack
2005-11-07 17:53 ` Steven Rostedt
2005-11-07 17:56 ` Gerhard Mack
2005-11-07 18:01 ` Mark Knecht
2005-11-07 18:15 ` Steven Rostedt
2005-11-07 18:31 ` Mark Knecht
2005-11-07 19:08 ` Gerhard Mack
2005-11-07 19:09 ` Mark Knecht
2005-11-07 19:05 ` Lee Revell
2005-11-07 19:23 ` Mark Knecht
2005-11-07 19:47 ` Steven Rostedt
2005-11-12 9:11 ` Lee Revell
2005-11-07 18:19 ` Joel Jaeggli
2005-11-08 18:59 ` Stefan Seyfried
2005-11-08 19:06 ` Lennart Sorensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1131349343.2858.11.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®