From owner-freebsd-amd64@FreeBSD.ORG Wed Dec 14 14:08:39 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56A11065672 for ; Wed, 14 Dec 2011 14:08:39 +0000 (UTC) (envelope-from matt@chronos.org.uk) Received: from chronos.org.uk (chronos-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:12b::2]) by mx1.freebsd.org (Postfix) with ESMTP id 137638FC0A for ; Wed, 14 Dec 2011 14:08:38 +0000 (UTC) Received: from workstation1.localnet (workstation1.local.chronos.org.uk [IPv6:2001:470:1f09:12b::20]) (authenticated bits=0) by chronos.org.uk (8.14.5/8.14.5) with ESMTP id pBEE8X1I038513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2011 14:08:33 GMT (envelope-from matt@chronos.org.uk) X-DKIM: OpenDKIM Filter v2.4.1 chronos.org.uk pBEE8X1I038513 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=chronos.org.uk; s=mail; t=1323871713; bh=4l8POx/FYGcvx/nEdZPnNj7zxnn3p/xZ1bN43te28LA=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=fD9BEhdOSRfGSFhd8UeNbg5L/QWvc/PP89uFqbGnztWXBBcJcyXWloJGVjKFFS0nU ONRC8AkrTKewfbEEfPlEEmKZMUCLVFnuXFvAyUqSvQrykrg4mp4nrow+4W2BPWdUsn XrUNBuDBbM1Hu9GO0il9uh+1skPLpA7k7GgwxmB8= From: Matt Dawson To: freebsd-amd64@freebsd.org Date: Wed, 14 Dec 2011 14:08:31 +0000 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.7.3; amd64; ; ) References: <20111213222156.218250@gmx.com> In-Reply-To: <20111213222156.218250@gmx.com> X-Face: -a*{KS?gYyH>pt=1?H+(>B2Z'>b6WxX:^O@+VaMV>l\tOh@[x`#&AHSdl`m<-EEhk=1%t9iRthI|; ~8)mN@qxJ}x5l:zhDO( =?utf-8?q?=2Eas=0A?= NeO!\oL7huHfsoF'I5,0G+Yo[G-G"FG,l`QJ$IgwH/[\a]vRH^'=`; cY+*_{Or` MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201112141408.33231.matt@chronos.org.uk> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (chronos.org.uk [IPv6:2001:470:1f09:12b::1]); Wed, 14 Dec 2011 14:08:33 +0000 (GMT) X-Virus-Scanned: clamav-milter 0.97.3 at central.local.chronos.org.uk X-Virus-Status: Clean X-Spam-Status: No, score=-100.4 required=3.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RP_MATCHES_RCVD, SPF_PASS,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on central.local.chronos.org.uk Subject: Re: Video Card for FreeBSD 9.0 (RC2) AMD64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 14:08:39 -0000 On Tuesday 13 Dec 2011 22:21:55 Dieter BSD wrote: > Matt writes: > > [The n]Vidia binary blob and the support from nVidia on the forums > > is generally accepted as a best-effort endeavour. > > Binary blobs are completely unacceptable, and there are multiple > good reasons for this. There are advantages and disadvantages. I've already given one example of a binary blob that is integrated into the kernel for pragmatic reasons. There was ath_hal for a while. I'm sure if I look a bit harder, I'll find some more. iwi(4) springs immediately to mind. It's all down to weighing up the pros and cons. It's easy to become polarised on this issue but it really doesn't help when you are sitting in front of a box that you require certain functionality from that is sitting there flipping you the digital bird and stubbornly refusing to fulfil its general purpose computing remit. Given the choice between the not-quite-fully-derrierred OSS support of the Radeon [1] and Intel integrated devices coupled with lagging behind in the DRI2/KMS/GEM/TTM/Gallium alphabet-soup-eating contest due to other OS bias within X.org or the excellent quality of the nVidia 64 bit driver it's a no-brainer, especially when the portion of the driver that has the most potential for freedom and privacy breaches is supplied as source. I, for one, am not prepared to abandon FreeBSD over these issues, so a compromise was necessary. Christian Zander was very open and approachable while the amd64 driver was being developed and worked closely with the community to see that goal come to fruition. He also did an interview for the BSDtalk podcast to discuss the importance of FreeBSD support at nVidia. > Do we really need to rehash this over and over again? No, no we don't. We pragmatists will continue to run what fits the purpose best for as long as the option is available and the idealists will continue to complain when they'd be better served by a release from that other OS such as gnewsense (a *very* apt name indeed) or similar that emphasises politics over function. There's no need for a discussion at all unless it's to point out to people such as the OP that there are options. Here in the FreeBSD world, such decisions are made by the user or sysadmin. It is never going to be the default but it will be made available as painlessly as possible for those who wish to use it. That's the key factor: Choice. We have it, it's not going away and nobody is holding a gun to anyone's head. It fits very nicely into the BSD ethos: Here's some software. Use or use not, there is no pressure. [1] I have three Radeon X850XT cards here which were, until the r600 import, the fastest 3D cards supported by FreeBSD's DRI subsystem[2]. While they worked, FSVO "work," the humble GF 210 wipes the floor with them in terms of stability, ease of maintenance and functionality. [2] I'm not just blindly ranting, nor am I a fanboy; I have been through the gamut of graphics support on FreeBSD. if you want to know just how thoroughly I went into this, I wrote a full Handbook chapter on DRI a couple of years ago but didn't submit it due to it rapidly becoming outdated. You can view that here and make your own mind up: http://www.chronos.org.uk/handbook/dri.html -- Matt Dawson MTD15-RIPE matt@chronos.org.uk