From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Tue, 04 Mar 2014 14:22:35 +0900 Message-ID: <877g8asfl0.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <83sirj9cyp.fsf@gnu.org> <20140217203145.71a849f7@forcix.jorgenschaefer.de> <837g8t8ouc.fsf@gnu.org> <20140219080524.25689b6b@forcix.jorgenschaefer.de> <83k3cr58o2.fsf@gnu.org> <530BAEE5.9040004@online.de> <87ppmatkpe.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgfsxsr.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqgf37n4.fsf@fencepost.gnu.org> <87ha7gshu9.fsf@uwakimon.sk.tsukuba.ac.jp> <871tyko9l5.fsf@fencepost.gnu.org> <87eh2ks897.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvn0mk25.fsf@fencepost.gnu.org> <87bnxorlol.fsf@uwakimon.sk.tsukuba.ac.jp> <877g8bmxal.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1393910707 13822 80.91.229.3 (4 Mar 2014 05:25:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Mar 2014 05:25:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 04 06:25:15 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WKhqt-0000ZU-4R for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 06:25:15 +0100 Original-Received: from localhost ([::1]:43189 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKhqs-0002YA-9K for ged-emacs-devel@m.gmane.org; Tue, 04 Mar 2014 00:25:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKhqi-0002H6-QX for emacs-devel@gnu.org; Tue, 04 Mar 2014 00:25:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WKhqc-0008Hq-UG for emacs-devel@gnu.org; Tue, 04 Mar 2014 00:25:04 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:40286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WKhqV-0007Y7-Sh; Tue, 04 Mar 2014 00:24:52 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9A8B39707DD; Tue, 4 Mar 2014 14:22:35 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8883C1A28E5; Tue, 4 Mar 2014 14:22:35 +0900 (JST) In-Reply-To: <877g8bmxal.fsf@fencepost.gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170122 Archived-At: David Kastrup writes: > "Stephen J. Turnbull" writes: >> David Kastrup writes: >>> "Stephen J. Turnbull" writes: >>>> David Kastrup writes: >>>>> It only weakens the GPL [big snip and back to David] > The GPL can _always_ be enforced by the copyright holder. > Collecting the assignments makes sure that the FSF has the full > ability to enforce You could have stopped there. *You* said "weaken the GPL" when what you really meant was "weaken the FSF." OK, conceded. But you continue: >> If the GPL can't be enforced, > > The GPL can be enforced. In theory, yes, each of a large collection of copyright-holders can enforce the GPL on their little bit. In practice, as you say: > That's underwhelming. That is, such a collective's threat of action to enforce is not credible, and the costs of defending in the unlikely event that such challenge arises becomes an ordinary business risk. Aside: I wonder if perhaps you could defend something like XEmacs or the Linux kernel or Python with a class action suit. I'll have to ask a lawyer. RMS might want to ask his, too, since the FSF owns enough of XEmacs, and probably other non-GNU software, to be a plausible class representative for them. Or maybe he already has. :-) And then your main point: > It doesn't weaken the GPL. It weakens GCC, and with it, the GNU > project. Part of the strength of the GNU project lies with GCC > setting language and performance standards, Except that last is now an exaggeration. Obviously GCC no longer sets performance standards, and since the reason I switched my default to Clang was to get better error messages, in at least one aspect it seems to be lagging on language standard-setting. (But see discussion below, especially fn. 1.) This is what happens when you have no real competition. > and it's bad if the most thorough modes we make available with > Emacs are not able to support the GCC dialects. Now that, as Richard would say, is a misrepresentation. Of course nothing prevents Emacs from supporting GCC dialects, certainly not a fiat from Mt. Olympus. Of course Emacs *should* support them. And if such support was lacking or weak, I think there's some chance that Richard would come around and encourage development of that mode. Don't you? AFAICS, the issue at hand is supporting unique features of free software whose licenses do not defend freedom according to Richard. There are a lot of such licenses, including those used by TeX, Perl, Python, Ruby, ncurses, X11, and Apache. Why doesn't the logic that applies to LLVM apply to them too? > So in this case GCC and the GNU project were in the situation of > creating a de facto standard. Once Emacs supports what Clang > provides rather than what GCC provides, not even Emacs will support > any new features of GCC. Hm. You've said that twice, now. This is a leap that I cannot follow. Would you explain? I understand the rest of your argument that *compiler users* could abandon GCC en masse. What I don't see is why that would prevent Emacs from supporting unique GCC features any more than it prevents Emacs from supporting a zillion true niche applications (eg, modes for .Xresource and RGB.txt manipulation). Furthermore, my personal estimate is that GCC's capacity for relevant innovation has been sapped by its dominant position and by the focus on internal issues that comes with high-stakes standard-setting. And furthermore, refactoring to make internal data structures available to cooperating applications has been forbidden for a decade or so. Just where are those "unsupportable" new features going to come from? And what is going to make them radical enough from the users' (and Emacs's) point of view that support is non-trivial? > GCC plays a central role in where people place their focus, their > loyalties, and their goals. Not in my experience. I tried Clang *once* because an XEmacs user posted about warnings it was issuing, discovered that its error messages and warnings were way more useful than GCC's, and switched immediately.[1] Perhaps kernel developers and a few others pushing the envelope of C performance or C++ conformance experience GCC as central, but for most of us it's just a tool, quite replaceable, I suspect. glibc and Emacs are far more iconic, and of course glibc is universal to the GNU System. > It's one of the actually active ties to the GNU project that the > Linux kernel has. That's because the kernel developers have not been supported by GNU. As usual with GNU, it was "my way or the highway." Linus took the highway, and almost all kernel developers went with him. There had to be a better way to handle that. There has to be a better way to handle LLVM. I'm not saying "mistakes were made"[2], but surely the result was undesirable. And I'm saying "we really don't want a central component of the system developed outside of the 'House of GNU' again."[3] > So we want to have GCC stay technically competitive No, at least based on current behavior, you don't want *GCC* to *do* anything. You want *LLVM* to *fail to innovate* in the same way that GCC is *prohibited* from innovating. The effect is the same, but your statement suggests that GCC is being defended, when in actual fact what is happening here is that Emacs is being commanded to attack LLVM (in the sense of "trade war", ie, withdraw cooperation from an external entity whose competence threatens a protected local industry). This is only to the detriment of Emacs and LLVM users. It does not hinder LLVM's attempt to achieve compiler dominance, and may even en(cou)rage some because they see it as mere spitefulness from GNU, and evidence that GCC really is lagging, even as viewed by GNU itself. > in order to retain a non-licensing based connection into those kind > of projects and, not least of all, the Linux kernel. On the other > hand, staying technically competitive is not self-serving but it > serves to have a wider audience for our non-technical goals. > Giving up the latter in order to have a stronger stand for the > former is sort of pointless. Sort of what one calls a "dying > throw" or "parting shot". That justifies redoubling efforts to innovate in GCC, while respecting the self-imposed limitation on acceptable areas for innovation. It doesn't justify "trade war". > When put to the choice, we'd rather give up on Android than GNU. > And us having to take that choice at some point of time is what > Clang/LLVM are working towards. I rather think you overstate the importance of GNU in the thinking of LLVM developers. > Once Clang/LLVM become the compiler for Android, it is a matter of > time and hipness before it becomes the default compiler for the > Linux kernel. > > Once the kernel is bootstrapped using Clang/LLVM, it is a matter of > time before the userland of big distributions is compiled using > Clang/LLVM as well, with GCC becoming optional. > > At some point of time, it will become harder to compile the Linux > kernel with GCC out of the box, and bootstrapping a full GNU system > will mean that we need to revert to the HURD, mostly relying on > using Linux drivers. A sad future history indeed. And you think that refusal to integrate Emacs modes that use Clang to improve the Emacs user experience is the finger in the dike that will save Holland, er, the GNU Project? The obvious fact is that GNU can't stop the process you've described -- it all happens outside of GNU! You can only hope it will fall apart due to its own internal inconsistencies. Unfortunately, the process you describe is pretty clearly the GNU Project falling apart due to its own internal inconsistency. Specifically, it wants to be universal but denies the clearly expressed aspirations and preferences of the rest of the free-software-producing world and their users. And now, it's denying the aspirations of some of its own members, merely to spite those with different beliefs about defending freedom. GNU's beliefs are essential to the free software movement. Nobody can deny that. But this decision is mere spite, without real effect, and > At least until someone sues us for combining GPLv2 drivers with a > GPLv3+ kernel. Surely GNU will not take that risk. If that ever happens, RMS and the GNU Project lose so much face that it's "game over". If the HURD is already doing so, isn't it time for a revolution? (Preferably led by RMS himself.) > And if you are saying "that's too pessimistic. All of this _could_ > happen, but that's by no means sure." No. I'm saying you're way too *optimistic*. The story you tell is way too plausible to be ignored, and the current response is way too weak. GNU outlived Zawinski's challenge, compromised with Drepper, and surmounted the EGCS challenge, but this time could easily be different (I'd put a small wager on no effective response and GCC gradually falling into disuse except for building HURD-based systems). What's different now? *Big* business has learned to cooperate effectively with free software projects, both idiosyncratically (eg, the Linux kernel) and systematically (via organizations like the Apache Foundation). Looking around more widely, the GNU Project is doing nothing effective to catch up to commerce-friendly free software leaders[4], and resorting to shooting spitballs at front runners (Linux and LLVM) and coddling con men ("GNU" Bazaar, whose members, with the presumed exception of the Invisible Maintainer, have far less allegiance to GNU ideals than I do). It's funny. I could happily live in the GNU System as described in the Manifesto, plus the Linux kernel. I could get all of my current work (with the exception of web publication and reading HTML mail and *Office docs -- even submission of *Office docs can usually be avoided by using plain text or PDF and w3.el is sufficient for the browsing I *need* to do -- including both $DAYJOB and FS support and development) done with today's versions of the base system, applications, and libraries listed there. But I look out at the world, and I see that others want a lot more. Some of it (eg, web browsing and publication, mailing lists, and issue tracking) is convenient for my activities -- but with the exception of GNU Mailman, *none* of that additional convenience can be achieved with GNU projects. Somebody needs to figure out whether that last sentence is too true in general to be ignored. (Eg, my desktop is XEmacs, so I don't include GNOME -- surely a convenience to many -- in my list of "conveniences".) And if so, why it happened and what to do about it. Hey, GNU! WTF?! > the whole point of being behind GCC is to do what is in our power > to push against this happening. Our power may be small compared to > those of the universe, but that has not kept us from making a > difference by applying it aimedly and timely enough. Being behind GCC? What have you contributed to GCC lately? Besides apologia for shooting spitballs at Clang, that is. If you wanted to *effectively* support, GCC you'd be ignoring me and posting ideas and encouragement and maybe even patches on GCC lists instead, no? The whole thing reminds me of my host country. "Alas, alack, a 'Lost Decade' for the Japanese economy. We must reform!" Oops, we can now make that two decades -- and counting, "Abe-nomics" not withstanding (Band-Aids #1 and #2 have been applied, but the painful surgery has not been done, and pretty clearly the administration intends to avoid it). And now they're shooting spitballs at TPP and justifying "attack as the best defense" military strategy. I don't know what to do about either Japan or GNU. I've presented my ideas, but (in both cases) they run counter to the natural instincts and/or principles of the leadership. Footnotes: [1] The effect may be temporary, of course: since the architecture is different, the errors and warnings issued are likely to be different. Long experience with GCC means those are *gone* (I mean, 100%) for older versions of GCC. Clang may just be reporting on issues that it catches that have been present for a decade. I'll have to go back and see which does a better job once we're "Clang clean". However, I bet that Clang's architecture gives it a lasting advantage here. [2] Perhaps the approach taken to trying to cooperate with Linus et cie. was the best possible, especially given the important differences on licensing. I grant those weren't reconcilable by concessions from the GNU side. [3] Well, to be honest I don't care specifically about the compiler. I do think that a strong GNU (= free software movement) is important, maybe essential, to a healthy FLOSS community. I don't think it has to be *dominant and universal*, though. Bottom line: if GNU thinks "owning" compiler space is important to its goals, I'm happy to assume that's important in my discussion. [4] The GNU Project has no entrants in kernels (HURD? give me a break), scripting languages (Guile? ditto), web servers, or web frameworks, the areas that scare Microsoft and power Google. It's most innovative on the desktop (GNOME), but still way behind the industry leaders (Microsoft in installations and Apple for overall design) and facing intense competition even for GNU System desktops (KDE). It doesn't have a distribution to speak of, not even a package manager. And now its long dominance in system software toolchains (GCC et cie.) is seriously challenged.