Based on regtest/aports, which is a big shell workload:

• Is there another xz backdoor lurking in the workload ?
  • Can we add always-on runtime instrumentation to detect this? with O(1) memory with respect to program runtime ?
  • Theme: supply chain security
• Shell is slow, so can we use the "spaces" to run telemetry / always-on profiling?
  • how often is shell invoked in the Alpine Linux build? At Alpine Boot time?
  • Debian build / systemd boot ?
  • which shell features are used?
  • Theme: language runtime implementation
• OSH is as fast as bash, despite being written in typed Python (with GC) !
  • This is because bash is a suboptimal program!
  • Can OSH be as fast as awk / Python?
    • By another translation of the executable spec? (e.g. with tagged pointers)
    • Or with hints? Or by enhancing the metalanguage?
• How to visualize shell traces?
• Can the Alpine Linux build with abuild be parallelized and distributed?
  • something like Bazel or Nix?
  • Theme: parallel and distributed computing
• Can OSH be transformed to YSH?
  • there is no automatic design
  • Theme: program transformation
• Can we fix bugs in OSH with LLMs?
  • point LLM at busybox ash / bash source code, and ask it to implement OSH?
  • document OSH?
  • can we use the ~11,000-commit history of the Oils repo to improve results?
  • problem: changes are often bottlenecked on review
    • case study: trap builtin
  • problem: is there an objective metric for "generating ugly code" that's not maintainable by humans?
    • I guess that's why we use the commit history
    • trap builtin is another good example

Themes

• Supply Chain Security
  • Foundation for a distributed OS
• parallel and distributed computing
• program transformation / maintenance
• Generating source code changes