From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: esr@thyrsus.com (Eric S. Raymond) Newsgroups: gmane.comp.gcc.devel,gmane.emacs.devel Subject: clang and FSF's strategy Date: Tue, 21 Jan 2014 15:19:49 -0500 (EST) Message-ID: <20140121201949.21DE1380522@snark.thyrsus.com> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390335589 18223 80.91.229.3 (21 Jan 2014 20:19:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jan 2014 20:19:49 +0000 (UTC) To: rms@gnu.org, gcc@gcc.gnu.org, emacs-devel@gnu.org Original-X-From: gcc-return-181654-gcc=m.gmane.org@gcc.gnu.org Tue Jan 21 21:19:58 2014 Return-path: Envelope-to: gcc@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W5hnh-0002gT-Ny for gcc@plane.gmane.org; Tue, 21 Jan 2014 21:19:58 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:message-id:date; q=dns; s=default; b=c7/DrfpXF4bntZE jI/rQJDblhtQIQ7HsmTDdcgWbbeL2ghFAIOoTglQcIHwHKA0vnADn9fyJmTw2YbP EKeP3OemAtuO570o3dAT/mXtS3/EtTCQ3rRoI2vMfhWQUbXlr+PFw+UzXVJDtlXO ykDN3JrMsA4UX7QUMhxk4qw9QYPI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:message-id:date; s=default; bh=Qio3WLTdEm60wOGyYymCV FP3Wt4=; b=SFJk033TbDOMHY+1oBTEeweUkUn0tddZqx0sdRvfM2avKbJiWzBxU cqtRiHj8+IgJ7128VrIVS3zUxCg/0JLWAZwZbkfT2D5nFV2PRoZufH2EyxyzArqo 7LKGuy0VqpFksMfHWdExmamk+1Rr+qhtvQNFZkUwn/UZAzsbqBgBJo= Original-Received: (qmail 19532 invoked by alias); 21 Jan 2014 20:19:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Original-Sender: gcc-owner@gcc.gnu.org Original-Received: (qmail 19521 invoked by uid 89); 21 Jan 2014 20:19:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: snark.thyrsus.com Original-Received: from static-71-162-243-5.phlapa.fios.verizon.net (HELO snark.thyrsus.com) (71.162.243.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2014 20:19:50 +0000 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 21DE1380522; Tue, 21 Jan 2014 15:19:49 -0500 (EST) Xref: news.gmane.org gmane.comp.gcc.devel:134098 gmane.emacs.devel:168855 Archived-At: David Kastrup's recent question on emacs-devel motivates me to bring up a larger related question I've been meaning to open for a while: Are the FSF's goals best served by continuing to technically restrict GCC? This is a question in which I have some positive stake. Yes, I continue to be opposed to the FSF's style of propaganda exactly because I think it hinders an end goal - a software ecosystem that is open-source and user-controlled - that I agree with and have worked hard to achieve. On the other hand, I have always said that the FSF's artifacts are its best artillery, and GCC is certainly one of the biggest guns in that arsenal. I want GCC to do what the FSF wants it to do - promote freedom and openness, erode proprietary control, prevent vendor lock-in of development toolchains. I think it is time to question whether the anti-plugins policy is still the best way to accomplish this. What gives this question point is the very existence of clang. The clang developers aren't shy about saying in public that they regard the FSF's anti-plugin policy as obstructive and that this is a major motivation for their work. And they're making excellent progress; clang is a production-quality tool today, not yet as mature as GCC but with better features in some areas - its error messages, in particular are *far* superior. The clang developers very carefully do *not* say that they aim to make GCC obsolete and relegate it to the dustbin of discarded tech. But I believe that is unmistakably among their goals, and I judge that they are a credible threat to GCCs's dominance in the 3- to 5-year timeframe. It might be that my goals would actually be advanced if clang were to kick GCC off the top of the heap. That is, there is at least a possible world in which a serious hit to FSF's prestige would decrease its ability to hinder progress through PR I have made no secret of considering ham-handed and counterproductive. For the present I choose to ignore this possibility. It seems better to me to promote as vigorous as possible a competitive race between GCC and clang, so that both will improve and the the aggregate position of open-source toolchains will strengthen. Therefore, I point out that FSF can no longer prevent proprietary vendors from plugging into a free compiler to improve their tools. That horse has left the barn; the strategic goal of the anti-plugin policy has been definitively busted. I also think it bears noticing that nobody outside of Microsoft seems to particularly want to write proprietary compilers any more. GCC won its war; the cost and time-to-market advantages of hooking into open-source toolchains are now so widely understood that new processor designs support them as a matter of course. Wouldn't it make sense, then, to entirely drop the factoring restrictions from GCC so it can compete for developer attention more effectively with clang? Before clang existed, back when GCC had a near monopoly in its competitive space, there might have been a functional case for those restrictions. Reasonable people may differ on that; there's no point in arguing it retrospectively. Now, I submit, they have become a pointless gesture that serves only to hinder GCC development abd increase clang's competitive advantage. GCC has a lot of strengths to play from, most notably the maturity of its multiplatform and cross-development support. I urge the FSF to fully free the code - drop the policy restrictions, encourage a flourishing ecosystem of surrounding plugins. Let GCC, clang, and other alternatives compete for attention on pure technical merit. I think the last fifteen years have demonstrated that in this sort of competition, the proprietary vendors will eat dust if they try to outcompete open-source tools on their own ground. Furthermore, they've learned this the hard way, and are quite unlikely to try. There are less risky uses for their NRE. In some sense I don't really care who wins. Either GCC or clang will serve my needs. I do prefer that both tools be as excellent as possible. And it would be nice if the FSF were to demonstrate that it can recognize changed conditions and move with the times. -- Eric S. Raymond There's a tendency today to absolve individuals of moral responsibility and treat them as victims of social circumstance. You buy that, you pay with your soul. -Tom Robbins, Still Life with Woodpecker