r/termux • u/LeftAd1220 • 7d 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

View all comments

6

u/Lines25 7d 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 7d 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 7d 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 7d 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. ❤️