all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* clang and FSF's strategy
@ 2014-01-21 20:19 Eric S. Raymond
  2014-01-22  0:07 ` David Kastrup
                   ` (4 more replies)
  0 siblings, 5 replies; 14+ messages in thread
From: Eric S. Raymond @ 2014-01-21 20:19 UTC (permalink / raw)
  To: rms, gcc, emacs-devel

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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: clang and FSF's strategy
@ 2014-01-22  4:49 grischka
  0 siblings, 0 replies; 14+ messages in thread
From: grischka @ 2014-01-22  4:49 UTC (permalink / raw)
  To: dak; +Cc: emacs-devel

David Kastrup wrote:
> The whole point of the FSF was _not_ to "move with the times". 

Really?  Is that a theory of everything or still quantum gravity?

--- grischka




^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-01-25 15:26 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-21 20:19 clang and FSF's strategy Eric S. Raymond
2014-01-22  0:07 ` David Kastrup
2014-01-25 15:26   ` David Kastrup
2014-01-22  0:50 ` Alexandre Oliva
2014-01-23 18:21   ` Joseph S. Myers
2014-01-22  1:31 ` Stefan Monnier
2014-01-22  1:31 ` Ian Lance Taylor
2014-01-22  4:02   ` Eric S. Raymond
2014-01-22 11:27     ` David Kastrup
2014-01-22 14:33 ` Jordi Gutiérrez Hermoso
2014-01-23 10:03   ` Michael Witten
2014-01-23 10:52     ` David Kastrup
2014-01-23 17:17     ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2014-01-22  4:49 grischka

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.