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 18:46:22 +0900 Message-ID: <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <20080818210927.GD2615@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219139195 6570 80.91.229.12 (19 Aug 2008 09:46:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Aug 2008 09:46:35 +0000 (UTC) Cc: emacs-devel@gnu.org, hannes@saeurebad.de, rms@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 19 11:47:27 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 1KVNoE-00018r-Oj for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 11:47:27 +0200 Original-Received: from localhost ([127.0.0.1]:50289 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVNnH-0002Ah-JX for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 05:46:27 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVNn9-00028c-KM for emacs-devel@gnu.org; Tue, 19 Aug 2008 05:46:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVNn8-00027K-1u for emacs-devel@gnu.org; Tue, 19 Aug 2008 05:46:18 -0400 Original-Received: from [199.232.76.173] (port=40265 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVNn7-000273-Ph for emacs-devel@gnu.org; Tue, 19 Aug 2008 05:46:17 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:45331) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVNmy-0008LX-3Z; Tue, 19 Aug 2008 05:46:09 -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 02A0F8004; Tue, 19 Aug 2008 18:46:06 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EE41A1A25C3; Tue, 19 Aug 2008 18:46:23 +0900 (JST) In-Reply-To: <20080818210927.GD2615@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:102633 Archived-At: Alan Mackenzie writes: > 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. That's a very strange philosophy of freedom. Freedom *means* that you may do something without concern for interference from your government or your neighbors. That doesn't mean it's ethically right to do, of course. But you have to argue from a different ethical principle than freedom. > 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. But Alan, I have accepted your principles, except the one that says anything you can imagine is probable enough to worry about. And unfortunately, I can't challenge your arguments because you haven't posted one (except that fallacious argument from the authority of Richard Stallman). You have only posted assertions. I grant the conceptual possibility that you assert, but I deny its importance. I claim it is both extremely unlikely to come to pass, and that we can deal with the process of it arising in other ways. And I've supported both claims with concrete technical details and policy proposals. > 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. I guess I should deduce that you are in favor of closing airports so that planes will stop falling out of the sky on innocent people? The analogy is quite exact, you see. > 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. I really don't see it. Emacs developers won't touch the module, requests for support will be directed to the vendor, and surely vandalism/netrage by hackers is not to be attributed to Emacs but rather to the hackers themselves. What damage to Emacs's reputation do you envision? > Again, I'm thinking about the Community's freedom, not just yours as an > isolated individual. I object to your implication that I care only about myself. > 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. Bad things are possible. Stipulated. As with closing airports to prevent mid-flight crashes, some policies to ameliorate the possible bad things are stupid; there are better ways to deal with them. I think GNU's refusal to allow dynamic loading in Emacs is such a stupid policy, because there are better ways to address potential problems. > 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. I don't speak for Tom, but my analysis falls short of perfection. As I say, you should apply such standard to yourself, as well. And you are mistaken. My analysis focusses purely on the *lack* of freedom-destroying effects for *anybody*. Once we have some effects to talk about, I'll worry about whose ox is getting gored. > I think we differ because our axioms differ. I think we differ because I've gone beyond axioms to offer concrete analysis, and you haven't. > You and T regard only the freedom of the informed automous hacker > as important. I am very offended. I could not have imagined that you would stoop so low. > 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. I claim it cannot be imposed. Please rebut. > 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"). Depends on what you mean by "rapidly". Overnight? No. In two or three years? Yes, I think that can be done, and that's fast enough. > For the third time, our basic axioms seem to differ. They do. However, for the sake of this discussion, I've adopted yours. Except for the axiom that "dynamic loading leads to unfree Emacs", which I consider a proposition to be proved or disproved. > I don't think you see the point I'm making, and your analysis is > oblivious to that point, so I disregard it. Maybe. No. I understand your point. "Introducing a module loader could cause Emacs to become non-free." That's scary. In the light of day, though, I don't believe it's going to happen. Just like I don't believe there's a mass murderer waiting in the rear seat of my car. Possible, yes, and people have been killed by such. But very very rare, and much better dealt with by locking the car than by selling it. OTOH, I do know that benefits (so far of modest size) will certainly happen. For example, you're the same Alan Mackenzie who's been annoyed by the Emacs build process recently, right? Wouldn't it be nice if you could just disable the broken feature you don't like, or even just not build that module and use yesterday's build of the module with today's core? How about if you are developing new C code, and can change and reinitialize it in your running Emacs with a turnaround of about 5 seconds on a reasonable machine? Of course those conveniences don't stand up against the nightmarish scenario of microsoft.dll. Except that they are *certain*, based on my personal experience with the feature, whereas IMO the scenario of microsoft.dll becoming popular has *vanishing* probability, and even if it does occur, I believe that it is nearly certain that we can disestablish microsoft.dll. > > You haven't even described what a "non-free Emacs" would look like. > > That's unwarranted and manifestly false. I'm sorry, but what is "warranted" for me to say is *my* call, and "manifestly false" would imply that you provided a description that a reasonably intelligent person would see as plausible and something that can be responded to in a reasonable way. You haven't provided any such thing, yet. I discuss below why "microsoft8.dll" is technically implausible, and I've provided a number of reasons to believe it's managerially implausible, too. > 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' I can't find anything about disabling `defun', and that's not plausible anyway. All defun really does is establish a value for the function cell (the primitive is defalias), and add some properties like the documentation string. You'd have to also disable funcall, apply, and eval. Really you'd probably have to replace both the Lisp interpreter and the byte-code engine, and since there is no documented API and semantics for those, the FSF would have no problem getting a subpoena for Microsoft's source code if it was at all compatible. > and only allowing signed (by MS) Lisp libraries to be loaded. Again, the technical difficulties of accomplishing this in GNU Emacs are enormous. Remember, GNU Emacs's security features were designed by the guy who posted his password for somebody else's system in a public place. And who do you think would use such a thing? Word users are used to such restriction, but they'd piss their pants at the threat of being saddled with Emacs. I'd bet a majority of Emacs users, including all gurus would refuse to use it, so there goes internal suppport. Making such a thing popular would require enormous resources put into support. How could that be imposed? > This scenario would be essentially impossible without Emacs linking > into external binaries. False. It would be possible, and possibly cheaper, simply to build such an Emacs-alike from scratch, as Richard himself did. This would have the benefit that *all* of such an Emacs could be proprietary, too. > Tom, in his reply, simply failed to address this central issue of > my post. An apology, please. I'm not in a position to apologize on behalf of Tom. I offer you my apology, but it's not clear to me for what. I still don't see a description of a (feasible) non-free Emacs nor one that can't be achieved without a dynamic loader. All you have is your assertion that this is a real danger, and all I've done is point out (repeatedly) that you are simply making bare assertions. > > 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. What do you think "for starters" means? It's not a complete argument, but you really do have to answer it since you have claimed that Emacs itself would become non-free. In the case of microsoft8.dll, the user still has the source, they still have the right to redistribute Emacs, etc. So how has Emacs become non-free? Even if the DLL is loaded in site-start, you can disable that. (Well, I can, in XEmacs.) > For the fourth time, I reject your axiom that the measure of freedom is > solely that of individual informed autonomous hackers. It's not my axiom. Please provide a quote of me asserting that axiom. > > 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' No need for a binary module: (fmakunbound 'defun). > and prevent all but digitally signed code from being loaded. I don't know how to do this without taking over eval and the bytecode engine. That's going to be very difficult, even without worrying about the fact that the only documentation of the semantics at that level is the source, and thus the author of microsoft8.dll is very vulnerable to a copyright infringement suit. > > 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? Reload a patched C object into a running Emacs. Manipulate Emacs data structures, and provide new ones. Very little that a separate process can't, but it can do everything a lot faster. > 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? Look in the modules directory of XEmacs. In the case of the Canna module, no such command exists, so you need to link to Canna. Although there's also a network protocol so you could use just Lisp. > Up to now, you and Tom have been asserting that calling external binaries > is critically important and very useful. No, I haven't. I've simply said I don't see enough risk, even given the nightmarish consequences you envision, to outweigh the benefits I see.