[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release plans

From: Johannes Weiner
Subject: Re: Release plans
Date: Tue, 19 Aug 2008 01:27:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)


Alan Mackenzie <address@hidden> writes:

>> 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.

How about fset'ing defun to something new?

You still have not answered to what I said yesterday: This
microsoft8.dll `functionality' does not in any way rely on the feature
proposed here.

And if you would want to do Bad Things, what prevents you from calling a
non-free binary with Emacs' process interface?

See, I really believe in your points that this feature has the potential
to be abused.  But to me it is not obvious how it would open a _extra_
possibilities besides doing it more technically advanced.

The libotr bindings I have in mind would also work with the process
model.  Just hack up an executable that can be controlled by
command-line arguments to wire up your elisp stuff with libotr.

But frankly, I only have seen such irksome solutions by people with low
motives and little technical interest.  Look at how bad programs like
matlab are distributed: they dump themselves into /opt including all the
shared libaries they need while totally ignoring the rest of the system,
not giving a damn about standards.

So if I had other motives than technical cleverness and elegance, it
seems I would already be able to interact really close with non-free
software (not the ssh case but with an executable abstraction of a
non-free library!).

But I have no way right now to implement pluggable bindings in a sane
way that I would consider better than an ugly hack.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]