Re: Android port of Emacs

[Gregory Heytings]

> > If that process was as trivial as you say it is, distros would not 
> > exist. Users will have to do that every time they want to upgrade their 
> > packages. And the same programs will be installed twice on their device 
> > (unless they want to use Emacs exclusively).
>
> And most users will wish to use Emacs exclusively: its features are much 
> richer than that of the Termux application.

It seems to me that you extrapolate too much from your own experience. 
Óscar, who started this subthread, now said both that the process of 
building the Termux packages is not at all "trivial" but rather "quite a 
chore", and that he wants to continue to use Termux.

Independently of his or mine experience, Emacs is, in any case, not 
suitable replacement for GIMP or Audacity, for instance.

> > > If you want to argue over this, I ask you to first describe in detail 
> > > the procedure used to execute binaries, and then how you propose to 
> > > prevent it from being used, while keeping the ability to debug 
> > > programs.
> >
> > I won't do that.  I'm not a student and you're not a teacher here.
>
> Then the only conclusion I can reach is that what you said earlier was 
> wrong.

The correct conclusion would have been that I don't want to play by your 
"you should first demonstrate your technical knowledge before speaking 
here" rule.

> > Not only will Termux not have to adopt that "solution", but they 
> > unequivocally said they will not do that, and they already have another 
> > solution, of which they say that it's the only correct solution.
>
> Their ``other solution'' is to rely on yet another feature obsoleted by 
> Android: sharing files between APK packages, using android:sharedUserId.
>
> [...]
>
> In fact, the approach I have taken is the only approach that Android has 
> not discouraged or decided to remove in the future.

There is a huge difference between using an obsoleted and discouraged, but 
still supported, feature, that merely "might be removed in a future 
version of Android" (which does not mean "will be removed"), and using a 
hack to directly violate the explicit "write xor execute" security policy.

Despite the fact that it is obsoleted and discouraged, its intended use 
(distributing an app with optional add-ons instead of distributing a large 
monolithic app) seems legitimate, so it is also possible (and IMO 
probable) that if that feature is indeed removed at some point, another 
mechanism to achieve the same goal will exist.  (And yes, I am aware that 
other similar mechanisms already exist, but AFAIK you cannot achieve the 
exact same goal with any of the already existing ones.)

How can you believe that you alone know better, and unquestionably so, 
than a whole team of developers, who have been working on the Android 
platform and have been developing Termux for several years, and who 
carefully considered (and publicly discussed) all alternative solutions, 
including the one you have taken, before deciding which one they would 
adopt?

And, by the way, why do you provide an android-use-exec-loader variable to 
disable that hack, and do you explain in its docstring that it "may prove 
to be problematic for various different reasons", if it is indeed a good 
solution?  Its most obvious limit, apart from the overhead it introduces, 
is that, given that a ptrace'd process cannot ptrace'd again, it becomes 
impossible to use a debugger with that hack.