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: Release plans Date: Tue, 19 Aug 2008 02:58:16 +0900 Message-ID: <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> References: <873al79akr.fsf@skyscraper.fehenstaub.lan> <48A5BAD7.8030302@emf.net> <48A740CB.4050404@emf.net> <20080816213508.GA8530@muc.de> <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp> <20080817073124.GA1294@muc.de> <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818101802.GA2615@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219082304 11223 80.91.229.12 (18 Aug 2008 17:58:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Aug 2008 17:58:24 +0000 (UTC) Cc: hannes@saeurebad.de, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 18 19:59:16 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KV90d-0006qE-4m for ged-emacs-devel@m.gmane.org; Mon, 18 Aug 2008 19:59:15 +0200 Original-Received: from localhost ([127.0.0.1]:41685 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV8zg-0000ke-72 for ged-emacs-devel@m.gmane.org; Mon, 18 Aug 2008 13:58:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KV8za-0000k8-V0 for emacs-devel@gnu.org; Mon, 18 Aug 2008 13:58:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KV8zZ-0000jq-3k for emacs-devel@gnu.org; Mon, 18 Aug 2008 13:58:10 -0400 Original-Received: from [199.232.76.173] (port=37314 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KV8zY-0000jf-SA for emacs-devel@gnu.org; Mon, 18 Aug 2008 13:58:08 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:43236) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KV8zS-00061M-Bi; Mon, 18 Aug 2008 13:58:02 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6F6C98003; Tue, 19 Aug 2008 02:58:00 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8D3C81A25C3; Tue, 19 Aug 2008 02:58:16 +0900 (JST) In-Reply-To: <20080818101802.GA2615@muc.de> X-Mailer: VM ?bug? under XEmacs 21.5.21 (x86_64-unknown-linux) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102602 Archived-At: Alan Mackenzie writes: > Morning, Stephen! > > On Mon, Aug 18, 2008 at 09:01:54AM +0900, Stephen J. Turnbull wrote: > > Alan Mackenzie writes: > > > > I wasn't talking about a scientific process for which evidence can > > > be weighed up. > > > Shouldn't you be? Surely you know it is possible to quantify risk, > > and analyze it scientifically? > > OK, but it is like the blowing up of a nuclear reactor, not a plane > crash. Faulty analogy, until you provide a neutrino's weight of evidence that any user's freedom to stop using the module is impaired. The difference between the nuke and the plane is that we know a nuke accident endangers millions of people. A plane crash can be avoided by not getting on. Similarly, any damage to my freedom that is threatened by a proprietary module can be avoided by not using it. Sneaking it in a distribution of Emacs is clearly a GPL violation. > > Why do you ask that we on your nightmares, or Richard's, to guide > > policy? > > I don't ask anyone to we on my nightmares. ;-) I think you missed a > word out. "Why do you ask that we *depend* on your nightmares, or Richard's, to guide policy?" > > Are you beginning to see how untenable your position is? > > No. It may well be that, after more rigorous analysis, loadable binaries > in Emacs might not be a problem. But being wrong is a long way from > being untenable. Sigh. All the analysis so far has been provided by me and Tom, principally, with similar comments from others on the pro-DSO side. You just repeat your assertions, and Stallman compliments your for your clear statement of the issues. Humbug! > > In fact the only thing it has going for it is > > > > Richard is a master of nasty deviousness, so the fact that he sees a > > > problem is reason in itself to take it seriously. ;-) > > > but that's genuinely ad hominem. > > Yes, but it's not an a.h. attack. It's an a.h. compliment. Attacks are often valid logically. Ad hominem is a logical *fallacy*, inadmissible in reasoned discouse. > > > The essential point is that if an un-free Emacs became established > > > through the mechanism of loading binary libraries, we could not > > > easily reverse it. > > > Huh? All you have to do is write the patch and announce a release. > > Richard has done that before (the security patch a couple years ago). > > "Huh?"? Such a patch would do nothing to disestablish an established > un-free version. Of course it does. The old version was an unfree *GNU* Emacs. The new state of affairs is a free GNU Emacs, and an unfree *fork*. If you don't think that causes disestablishment, consider that no major GNU/Linux distributor would be likely to continue to distribute the fork as GNU Emacs; they'd make a separate package. Users would get their butts kicked as this addictive non-free app stops working with a bizarre error message about `function load-module not found' as soon as they upgraded Emacs. And Richard would do what he did to the Lucid people (what *they* did then is not relevant; I'll bet you none of them would be willing to go through that again, is the point). If that doesn't disestablish the fork pretty quick, Emacs is at least as far behind the fork as Emacs 18.59 was behind Lucid 19.1. Pretty unlikely. The above is what *analysis* looks like. Are you beginning to see how untenable your position is yet? > Those two sentences seem to contradict eachother. I can't find any > documentation for it in either of the manuals (XEmacs 21.4.17) or NEWS. > I even know it exists, and I've even got a solid search term ("loader"), > but I still can't find it. That's hardly encouragement. OK, so we don't *encourage* it, and we have some documentation bugs. "Would you like to work on the bugs?" It's still a standard feature, supported and easily configured for those interested in it. Alan, why don't you apply these picky-picky standards to your *own* non-arguments? You complain about how we try to avoid the issues, although I don't see that we do. I've explained, Tom has explained, why we don't believe a "non-free Emacs" can become established. But you have a monster in the closet that simply disappears every time we open the door. Not one dirty footprint, no fur settling to the floor, nothing. You haven't even described what a "non-free Emacs" would look like. I mean for starters, the GPL guarantees that Emacs remains free. So people can just say no and keep their personal freedom. And what is the difference between an Emacs that calls non-free code via a binary module, and an Emacs that accesses files via TRAMP and non-free SSH? Should we remove process support from Emacs? > I've just had a look at the SXEmacs home page, having not previously been > aware of it. I can't really see any reason for SXEmacs's existence. Freedom. Steve on the one side and me and Ben on the other had different ideas about how to run a project, and what quality of code and design should be allowed in. ("Quality" here includes style etc, it's not necessarily better or worse.)