Re: Android port of Emacs

[Po Lu]

Gregory Heytings <gregory@heytings.org> writes:

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

Emacs is a better terminal emulator than Termux.

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

So why are you making (false) claims about the _technical_ details of
process execution?

> 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"),

With the track record of the Android developers, it _will_ be removed.
Installing programs targeting API level 22 has already been removed in
the next version of Android, and that minimum requirement will be
steadily raised in the future.

> and using a hack to directly violate the explicit "write xor execute"
> security policy.

GNU does not take other software's fascist security policies seriously.
This is why RMS distributes Emacs files world-writable, for example.

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

Android discourages add-ons from using executables in the first place.
Binder IPC (similar to Mach RPC) is their recommended solution for such
add-ons.

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

Because I have different priorities from the Termux developers.  I am
not interested in considering the limitations of Google Play Store
policy, for example.

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

gdbserver is installed in /system/bin, so it can be run without process
tracing.  Otherwise, I'd have implemented a pass-through, just as in
proot (which, BTW, is used by a port of Vim to Android.)

Besides that, if su is installed on the Android device in question
(which is uncommon), Emacs can simply change its security context to
`trusted_app'.  For obvious reasons, su cannot work if it is being
ptraced.