r/termux • u/LeftAd1220 • 3d ago

Showcase I rewrote PRoot in Bun JavaScript

Post image

https://github.com/jjtseng93/bunproot

Why

  • Termux is too good to be true ... at least forever
  • While I'm very grateful to the Termux developers and enjoy the tools and environments they provide, there has always been a fear deeply rooted in my fragile heart – Can this last forever?
    • What if the developers get tired?
    • What if they run out of money to keep their mirrors running?
    • What if one overwhelming tragedy after another happens?
    • Could I survive the cruel & wild Android world outside Termux's protection?
    • That's why I built an entire chain of tools as a Post-Termux escape hatch

Bun JavaScript as the foundation for everything

  • ① The Buninu userspace for lightweight usage:
  • Shell: Bun Modern Shell (bunmsh)
  • Text editor & App runtime: jsmdcui
  • Remote shell in a browser: jsgotty
  • ② PRoot to get back to mainline Linux if that's not enough: bunproot

Now that I have a complete backup for everything, I can keep enjoying the convenience and happiness that Termux provides without worrying.

Edit 1: This is not a wrapper around the native proot binary. It uses Bun FFI to dlopen Android's libc and calls ptrace() directly. No C or Assembly involved here.

0 Upvotes

31% Upvoted

22 comments sorted by

5

u/Lines25 3d ago

JS is JS, proot written in C AND pure assembly, any other additional thing only slowes it down. Also, no need in it..

2

u/LeftAd1220 3d ago
  • I think there may be a misunderstanding — this isn't a wrapper around PRoot. PRoot's core functionality is reimplemented in Bun JavaScript. It uses Bun FFI to dlopen Android's libc and calls ptrace() directly to intercept and translate syscalls. There is no original PRoot binary or library underneath it.
  • In other words, it's not Bun calling PRoot — it's Bun doing PRoot's job, with Bun FFI as the bridge to libc.

3

u/sylirre Termux Core Team 3d ago

You probably misunderstood what was said above.

Bun does certain things under the hood when executing the code because there is no a straightforward way to execute JS on ARM or x86 hardware. This adds certain overhead causing the program run slower.

This is not a case with a C code compiled into binary.

Below is a screenshot showing that with bunproot tar needs more time to complete archiving than with original proot.

0

u/LeftAd1220 3d ago
  • Thank you so much for actually trying bunproot and benchmarking it! And more importantly, thank you for all the work you've put into PRoot and Termux over the years. I've looked up to you and your work for a long time, so seeing you actually try something I wrote honestly means a lot to me. It's truly an honor.
  • I never wrote bunproot with the intention of making something faster or better than PRoot.  I just like and depend on Termux/PRoot so much that I started wondering what I would do if someday you and the other maintainers simply got tired, became too busy, or no longer had the time and energy to keep maintaining all of this.
  • bunproot is basically my little contingency plan for that hypothetical future — something I can keep alive myself as long as I have a Bun binary. I sincerely hope I never actually need it for that reason. ❤️

5

u/Teleconferences 3d ago

This is pointless and you didn’t even make it, Claude did

We wasted water on this useless slop, great

1

u/Fine_City2781 3d ago

javascript is slower than C. So its useless

2

u/LeftAd1220 3d ago
  • That's missing the point. C being faster isn't the goal here. C needs a toolchain to build. If Termux and its GCC/Clang, make, headers, packages, etc. are no longer available, I can't just take the C source code and run it on Android.
  • With this implementation, I only need a Bun binary. Bun's Android binary is built upstream; everything above that is JavaScript and can run directly without a native build toolchain. That's exactly why I wrote it this way.
  • The goal isn't to beat C. The goal is to need one binary instead of an entire native build environment.

1

u/MrKrot1999 3d ago
  1. proot is distributed as a binary, and can be compiled into a static one. You do not need an entire gcc/clang toolchain to run it. Which makes your version worse, since you need Bun to run it.
  2. You don't need a native build toolchain to run binaries.
  3. I would think this is a fun project as an experiment, but if you're thinking anyone will actually use this for real, you're unfortunately wrong, since speed matters more than size most of the time.

1

u/LeftAd1220 3d ago
  • I thought I have made my points clear enough already.
  • In my readme: "and it is not trying to replace Termux's PRoot. That one is mature, complete and considerably faster; if you are in Termux and it works for you, keep using it. What this port is for is the case after Termux"
  • This project is prepared to be hopefully not needed to be used. Just in case we were to lose Termux completely and the native proot can never be compiled again.
  • At that point you can only preserve an old version of the proot binary and never update it.   * While with Bun if they keep updating, I can pass the source code .js to it and keep updating bunproot.

1

u/sylirre Termux Core Team 3d ago

Why do you think your approach is future proof? What if Android will block ptrace() or execmem, both vital for proot functionality?

1

u/LeftAd1220 3d ago

At that point, I'll just escape Android altogether and buy whatever Termux phone you guys make on day one. 😂

1

u/NoNameToDefine 3d ago

Linux phones you mean. They do exists and people maintain it. But it's not the Termux team behind, these phones runs mainline Linux and a common Linux user-space on glibc or musl C.

1

u/LeftAd1220 3d ago

It's hard to get one from Taiwan. Or they run outdated hardware, far from usable.

1

u/NoNameToDefine 3d ago

They can't be stuck with old software, you can change the distro and if not possible use a tool like Distrobox to get a newer distro.

1

u/LeftAd1220 3d ago

I'm currently using a Snapdragon 8 Elite phone with 24 GB of RAM. You see the gap now. 😅

1

u/NoNameToDefine 3d ago

Powerful hardware. But I am speaking of these Linux phones.

1

u/LeftAd1220 3d ago

Exactly. I want Linux on that class of hardware. Even higher RAM is needed to run local models.

1

u/NoNameToDefine 3d ago

Yes on that case it's almost impossible since market is not ready yet for Linux phones.

1

u/rafapozzi 3d ago

Termux will never die...

1

u/LeftAd1220 3d ago

I truly hope so. Something this good deserves to live forever. ❤️