From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Mon, 18 Aug 2008 21:09:27 +0000 Message-ID: <20080818210927.GD2615@muc.de> References: <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> <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219093667 18995 80.91.229.12 (18 Aug 2008 21:07:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Aug 2008 21:07:47 +0000 (UTC) Cc: hannes@saeurebad.de, rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 18 23:08:39 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 1KVBxr-0004gv-9D for ged-emacs-devel@m.gmane.org; Mon, 18 Aug 2008 23:08:35 +0200 Original-Received: from localhost ([127.0.0.1]:45936 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVBwu-0001s2-4j for ged-emacs-devel@m.gmane.org; Mon, 18 Aug 2008 17:07:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVBwE-0001YM-0l for emacs-devel@gnu.org; Mon, 18 Aug 2008 17:06:54 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVBwC-0001XV-Cv for emacs-devel@gnu.org; Mon, 18 Aug 2008 17:06:53 -0400 Original-Received: from [199.232.76.173] (port=43161 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVBwC-0001XP-5Y for emacs-devel@gnu.org; Mon, 18 Aug 2008 17:06:52 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:3761 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KVBwB-0004cd-AI for emacs-devel@gnu.org; Mon, 18 Aug 2008 17:06:51 -0400 Original-Received: (qmail 72893 invoked by uid 3782); 18 Aug 2008 21:06:48 -0000 Original-Received: from acm.muc.de (pD9E50A0C.dip.t-dialin.net [217.229.10.12]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Mon, 18 Aug 2008 23:06:45 +0200 Original-Received: (qmail 19379 invoked by uid 1000); 18 Aug 2008 21:09:27 -0000 Content-Disposition: inline In-Reply-To: <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.6-4.9 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:102611 Archived-At: Evening, Stephen! On Tue, Aug 19, 2008 at 02:58:16AM +0900, Stephen J. Turnbull wrote: > Faulty analogy, until you provide a neutrino's weight of evidence that > any user's freedom to stop using the module is impaired. I do not accept, as a criterion for freedom, that it is permissible to consider a person's actions divorced from the effect on his neighbours. We are not just individuals, we are each part of a community, in fact of several communities. If Joe gets saddled with a non-free Emacs, that affects James who has a free one, and quite markedly. That's just my philosophy and my politics. If you're going to challenge my arguments, you're going to have to accept, even if only for the sake of argument, these principles. I think I made that clear last night, with my image of lots of hypothetical Microsoft users who'd get saddled with an entirely non-free Emacs. > 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. This is where we differ. A plane crash hurts not just the people on board, but the people the wreckage falls on. Think of Lockerbie in 1988. > Similarly, any damage to my freedom that is threatened by a proprietary > module can be avoided by not using it. The fallout will hit you. That proprietary module will gunge up Emacs development, damage Emacs's reputation, cause sysadmins to hate it (they must field the rage from hackers) just as that aeroplane devastated a street in Lockerbie. Again, I'm thinking about the Community's freedom, not just yours as an isolated individual. > > > 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?" I think I've made it clear that my "nightmares", as you call them, are not positions I'm defending. I put them forward only as a counter (mainly) to Tom and to you, to show that bad things are possible, even if not probable. > > 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! Well, I don't think I'm calling people nasty names, and I'm not using derogatory hyperbole/ambiguous terms like "nightmare", "defeatist", and "untenable" to imply or half imply other people are idiots or incapable, or to detract from calm factual discussion. The analysis from you and Tom falls short of mathematical perfection. Unless I'm mistaken, it focusses purely on the effects it would have on knowledgeable automous hackers. To me, it is thus incomplete, and thus invalid. In any case, I think the burden of proof lies on you, as a proponent of change, not on me. I think we differ because our axioms differ. You and T regard only the freedom of the informed automous hacker as important. I (and possibly RMS) see freedom for the entire community as important. I think my hypothetical bad case ("microsoft8.dll") from last night made that clear. That such could be imposed on others is a bad thing for me. Apparently it bothers you not at all. > > > > 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. . What I meant, and I think this was perfectly obvious, is that Richard's copious experience of nasty deviousness in the real world, his contacts with legal experts, his experience of and intuition in such things, and so on, should incline the rest of us to respect his judgement and caution. Is that OK for you now? > > > > 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, ..... Sorry, this is just a pedantic squabble about the exact meaning of words. "Establish" has more than one syllable, and that should have been a warning sign for me not to use it. Here's a clarification: Should a non-free Emacs become widely installed ("established"), say GNU Emacs hobbled by the "microsoft8.dll" I pictured last night, a newer version of Emacs is unlikely to cause the number of installations of that un-free version to fall rapidly to near zero (i.e., become "disestablished"). > The above is what *analysis* looks like. Are you beginning to see how > untenable your position is yet? I've nothing more to add in this particular bit of the conversation. > > 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. Assuming that, somehow, they get to find out the feature exists. If I didn't know you better, I'd wonder if you weren't being economical with the truth here. It's your project, Stephen, so please give me a pointer to something in XEmacs 21.4.17 which tells me how to link in an external binary. I'm interested in what this feature looks like. And please tell me how I should have become aware of it. Or did the feature first appear in 21.4.x, where x > 17? > 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. For the third time, our basic axioms seem to differ. I don't think you see the point I'm making, and your analysis is oblivious to that point, so I disregard it. Maybe. > You haven't even described what a "non-free Emacs" would look like. That's unwarranted and manifestly false. In my post last night, I drew a picture of Emacs running on a future MS OS, where in order to get access to its file system, you had to install the proprietary library "microsoft8.dll". This would have the side-effect, on the pretext of "security", of disabling `defun' and only allowing signed (by MS) Lisp libraries to be loaded. This scenario would be essentially impossible without Emacs linking into external binaries. Tom, in his reply, simply failed to address this central issue of my post. An apology, please. > I mean for starters, the GPL guarantees that Emacs remains free. So > people can just say no and keep their personal freedom. Oh, so GPL's "guarantees" mean that everything's fine, and so we don't need to worry about anything. They are guarantees, after all. Hmmm. For the fourth time, I reject your axiom that the measure of freedom is solely that of individual informed autonomous hackers. > 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? The ability of a binary module to disable `defun' and prevent all but digitally signed code from being loaded. > Should we remove process support from Emacs? No. My question to you: what can an intimately linked binary module achieve that calling something as a separate process couldn't? Linking to external binaries has been in XEmacs for some while. What have people done with it? Could they have done the same by calling an external program via an OS call? Up to now, you and Tom have been asserting that calling external binaries is critically important and very useful. I don't recall seeing much justification. If I've missed it, a pointer would be appreciated. -- Alan Mackenzie (Nuremberg, Germany).