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: Tue, 19 Aug 2008 15:52:21 +0000 Message-ID: <20080819155221.GA11524@muc.de> References: <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> <87wsidnxqp.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 1219161003 19960 80.91.229.12 (19 Aug 2008 15:50:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Aug 2008 15:50:03 +0000 (UTC) Cc: emacs-devel@gnu.org, hannes@saeurebad.de, rms@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 19 17:50:55 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 1KVTTq-000649-M8 for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 17:50:47 +0200 Original-Received: from localhost ([127.0.0.1]:45900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVTSt-0008Qm-L8 for ged-emacs-devel@m.gmane.org; Tue, 19 Aug 2008 11:49:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVTSo-0008QD-U2 for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:49:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVTSm-0008Q1-Tn for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:49:41 -0400 Original-Received: from [199.232.76.173] (port=60356 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVTSm-0008Py-OD for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:49:40 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:4821 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 1KVTSm-00064y-DU for emacs-devel@gnu.org; Tue, 19 Aug 2008 11:49:41 -0400 Original-Received: (qmail 90276 invoked by uid 3782); 19 Aug 2008 15:49:37 -0000 Original-Received: from acm.muc.de (pD9E527DD.dip.t-dialin.net [217.229.39.221]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 19 Aug 2008 17:49:35 +0200 Original-Received: (qmail 14733 invoked by uid 1000); 19 Aug 2008 15:52:21 -0000 Content-Disposition: inline In-Reply-To: <87wsidnxqp.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:102666 Archived-At: Hi, Stephen, On Tue, Aug 19, 2008 at 06:46:22PM +0900, Stephen J. Turnbull wrote: > 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 ..... What, exactly, are we getting so worked up about, then? > .... (except that fallacious argument from the authority of Richard > Stallman). That's a mischaracterisation of what I've said. I respect his opinion not because of his "authority", but because of his experience of the murky place where legality, politics, and software meet, and my own near total lack of it. > You have only posted assertions. I grant the conceptual possibility > that you assert, but I deny its importance. OK, thanks! > 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. Now who's drawing wild conclusions? > > 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. In a nice rational world that might be the case. In the world we know, it'd be "Emacs = hassle = problems, let's just ditch it." > What damage to Emacs's reputation do you envision? It's reputation for being a highly effective reliable working program which causes trouble neither for its users nor sysadmins. > > 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. OK. I got this notion from what you have written in your posts, see below. > > 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. Right. So do you agree the present issue is a matter of analysis and judgement, weighing up risks and benefits? For example, it is (or used to be) sensible to close airports during thick fog. > 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. That is clear. > > 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. A little while ago, I opined that it is more important to be free than to be aware of that freedom. I don't think your analysis has covered those Emacs users who are free by virtue of that use, but are unaware of it. They could lose freedom, possibly without realising it, if any of the Bad Things we're talking about happen. > > 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. That wasn't intended to offend, and I'm sorry it did. I was trying to get some sort of handle on why two highly intelligent, normally genial, hackers, are having such a bad tempered exchange. Please consider this extract from your email in this thread: Message-ID: <878wuw7wji.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 17 Aug 2008 01:29:53 +0900 Richard M. Stallman writes: > How does not providing dynamic loading maximize what users can > do while remaining free? > > It protects against the danger of non-free C-level add-ons to > Emacs. Stephen: All a freedom-lover has to do to avoid those non-free add-ons is ... avoid them. Further, in your post before your last one, you wrote: Stephen: I mean for starters, the GPL guarantees that Emacs remains free. So people can just say no and keep their personal freedom. That sentence "All a freedom-lover has to do ...." suggested to me that you only considered the effect on "freedom-lovers" (what I called "informed autonomous hackers") important. The sentence "So people can just say no and keep their personal freedom." reinforces this impression, in that it disregards those who can't just say no. I think Richard was concerned about protecting users who would be less able to avoid non-free add-ons, for whatever reason. These sentences of yours still suggest to me that you don't regard the freedom of the non-informed, or non-autonomous hacker with very much importance. Please comment on this. > > 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. I can't, at least, not at the level I think you want. It would need more expertise on and more interest in things like licensing, copyright, ... than I've got. Anyhow, I'm not the person that needs to be persuaded. > > 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. I don't think it could. > > 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. The bit I think you're neglecting is the free "for whom?". > > 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. Again, non-free "for whom?". If you'ld've made specific reference to people who couldn't or wouldn't take action against non-free add ons themselves, I'd accept you'd understood my point. > In the light of day, though, I don't believe it's going to happen. I don't think it would happen either, for what it's worth. > 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? Yes, it would indeed be nice. If Emacs had been structured more modularly, this would be easy. > > 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. The sentence fragment ".... only allowing digitally signed LISP or binary libraries to be COMPILED or loaded." But that's not important. The fact is, a loaded binary module could disable any part of the Lisp infrastructure. It's a mere technical problem, not even that difficult. > ..... the FSF would have no problem getting a subpoena for Microsoft's > source code if it was at all compatible. Maybe, maybe not. Who wants to go there? What would happen to Emacs in the years the court case would drag over? > > and only allowing signed (by MS) Lisp libraries to be loaded. > Again, the technical difficulties of accomplishing this in GNU Emacs > are enormous. Really? A few defadvices in the right (wrong?) place would do the trick. > Remember, GNU Emacs's security features were designed by the guy who > posted his password for somebody else's system in a public place. What was somebody saying about ad hominem attacks not all that long ago? > How could that be imposed? I don't think the module I depicted, microsoft8.dll, could be imposed. It is just too extreme, too blatant. A more subtle, insidious spoiler module might be imposable. > > > 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 a colloquial expression which means, anywhere I've lived, something like "I have a number points I could make, any one of which will refute your point, so I am going mention just one of them, in the hope you'll not be so abstruse as to carry on a long fruitless argument which you'd lose anyway.". > 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? Without the mischief module they can't access their files, since the OS puts some sort of lock on the file system. That module prevents any Lisp code other than the standard distribution libraries from being compiled or loaded, and will itself only run in an unmodified Emacs. Emacs has now become non-free for those users on that system. > Even if the DLL is loaded in site-start, you can disable that. (Well, > I can, in XEmacs.) Sure, assuming that the --no-site-start flag isn't removed from Emacs (which anyone is free to do). > > > 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. OK. I think the benefits are moderate rather than profound. David K. mentioned the Lilypond info pages having images, and how it would be helpful dynamically to load image libraries for them. -- Alan Mackenzie (Nuremberg, Germany).