From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Android port of Emacs Date: Tue, 27 Jun 2023 08:39:36 +0800 Message-ID: <87fs6d91rr.fsf@yahoo.com> References: <83v8fnslfz.fsf@gnu.org> <83edmask4z.fsf@gnu.org> <5c02371a-3c42-de66-70b7-4ed0d88cc3fa@gutov.dev> <87cz1td0ku.fsf@yahoo.com> <87cz1ta5fr.fsf@telefonica.net> <87edm645yy.fsf@yahoo.com> <87mt0ryqlg.fsf@yahoo.com> <2aa76ba11fdd1c81b2f0@heytings.org> <87o7l6y2zf.fsf@yahoo.com> <30832e8647c0d343f7d8@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39835"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?utf-8?Q?=C3=93scar?= Fuentes , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 27 02:41:07 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qDwlT-000A4m-Go for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Jun 2023 02:41:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDwkO-0007Ml-HT; Mon, 26 Jun 2023 20:39:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qDwkN-0007Md-E9 for emacs-devel@gnu.org; Mon, 26 Jun 2023 20:39:55 -0400 Original-Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qDwkL-0006iB-4g for emacs-devel@gnu.org; Mon, 26 Jun 2023 20:39:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687826388; bh=jYG7Ls500kmjQ/K93FxH1z/8MAQQ4Grb7aG2LOT+4jQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=pKPIMtrw+QAApsL1Zgcd9+2ymUzuFl4a1R3r3h8xhZbN/k1Vjz7Y91Y9E5nhK3qvKWepG/ZCUYL+WYrtw4pYyRNLH4lup6Vxy4eV3iJKpwRHdnVzrfLgUxwCUM5niBX2lq6mzlpfCjazXWasxdAWqqfMoi+AB1/yFnMRJ9LMbq/tRddiFtNhRsXmTe6P9tIJKIqkxs56s4+Soa+U2G6dZJiJMXXxVL4aQRaT0Mzgx17ScQdFqEr7DrCWzFtEqZH7H+sMHcyRQh6K6Bi019HX6Fml3wC/sIKFtPUd67ZQdyIVkxhOB6dkIQFN4RgdaXzGqNoprpSeyoUou4EFMj2WRw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687826388; bh=UbqIaGTXjzzvQQmg3UyK2QQQkXceCQoJXNptoqGN8ye=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=hk6hQBeRM4O3PwFqg9A1NyyEsQDr7O/gGIjQnSt10YexpPLB+tJnBIV9k3EfCydFTwYFi+Un8TBdii4zySzfEzSdSgOTdgrqoeMywkJdmAbVWayiPNasg7ya8boSMpgZUh++V+bljz6uXrZgzvAiw9h8/rCikn8vPcq3T56QQ2cDgjDySLC6m2c2xI933+2vj2oJSnPSd1m3Dn2Myici0cTn/DKj2x+FwlJLMGGL+1t7u/yfxnBKBLEbEn/53G5kXQ0cJQUKr/A0AggB0a0h9UIJE2K2x1ckcygwrMtuwvJoVzXtUSAMjcebsaYCy1MEppcH0WxVHrCpVgrWy3rBKw== X-YMail-OSG: 334VmEoVM1n1kCvDxzjx1sMpNEwFzEVNzUT4ErKADYwsNqv6BFUg1xLbf1DLtkC uYfk.I.wWYArc6TUgWdXaFJ7gyrFUE.8uTgNeS.5Y9Al00ajFpCh1ZIujYNaj9a4ik6T11zoXxhc HoNfxd4RZPIH787RkY0B8npkvteV5PSLj0Ga5KrGYF_JAsP2afXow.E8jEYP6pnkLvO_StTY7dHJ Exmr.2PZ4N4b3DA4GOqgIsWZ.JMoI6sd5rTGFEFrmeXYQl4JGqeR1r6eaI9.HkPPar8CZCJCttIg EggpKbGUa09BDh2Ec5ZEJf7wFmx8jUsaLJsbNbKE.RnVDIQ1bSduvvR0X8wdyO8nyXO3uixv4kf6 3pBJSAkxZlALoGXn1elA7814tprS6fjBdk9yWgicwnG1clTAkIZOZqiUuGtw9Bgk_LuMICBN2PR_ V2g_ulIx0_y9PfstDixrXNyU1kOtR7WjJ0a9V6t17oMmK98cHN9lRe2nVt2YuC25tQxDWOiT3V.N Jyncfkxb5LnjW63z04D.j6Zr11ZRcaesUQw.Kx8GpYA0H.J0PFWIoOhgbuw2gagS3QME29woX9Yi LzrZCn9SXuFNH9JMvw7yvsAX8L9fFDPvLghOUPQwMbm.YjImmiFbaCO1tDe2wUkE4VURdAsZGUvY Gbymz4psVeVxjW_45Bq06Z13wy.JfdVHBeCYZ1qinfN78AUgckNLrq5Y9bRNguyhomZXTPN3Qkfe IxLRyMyY_0X2xnYd4.pSktnqOGcMJO0yPdnEVlE082.01Pd8X8gYl4Q5RWYYEuWyFn3Il0WgWrw1 DiZRghIpQTuglEVNNGiuTO3ihgVT8oE5kzs9GOOrFv X-Sonic-MF: X-Sonic-ID: 8e719a35-df17-426c-a9fd-850384889d7a Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Tue, 27 Jun 2023 00:39:48 +0000 Original-Received: by hermes--production-sg3-748897c457-fqxqz (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID afc8628f1020a79332843b46a34ac422; Tue, 27 Jun 2023 00:39:41 +0000 (UTC) In-Reply-To: <30832e8647c0d343f7d8@heytings.org> (Gregory Heytings's message of "Mon, 26 Jun 2023 15:18:27 +0000") X-Mailer: WebService/1.1.21557 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.189.84; envelope-from=luangruo@yahoo.com; helo=sonic306-22.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:307244 Archived-At: Gregory Heytings writes: > It seems to me that you extrapolate too much from your own > experience. =C3=93scar, 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.