Hello again! It's been a bit since I've posted an update, and I've been pretty quiet in open source work during that time, despite a lot happening.

If you find this work compelling, please consider supporting my work. This is a strong signal to me that I'm on the right track.

Last month, I didn't make a ton of progress on uscope to be perfectly honest. Life has been busy. Here are the updates:

• Upgraded to Zig 0.14.0. Congrats to the zig team on a great release!
• Worked on adding Go support in the debugger (much more work is needed still, but Go DWARF parses okay now).
• Added preliminary support for the C3 programming language.
• Made a tiny bit of progress on debugging binaries built by the zig self-hosted backend. There's a good amount more to do here.
• You won't see this in any uscope code yet, but I did a lot of experimenting with eBPF and can see a path forward on using it for many interesting debugging use-cases.

Big news: I accepted a new job! I haven't announced where yet, but I will soon. I start in a couple weeks and I'm very excited! It's at a small, fast-growing company and I think we're a great fit culturally and technically.

Consequently, I predict that I'll have substantially less spare time and energy to work on uscope, at least for a while. So, in order to make sure we all get the most out of it, I'm going to be re-focusing the project in the following ways to try to make the code I've written as useful as possible to the community ASAP:

• I'm going to yanking the ELF/DWARF parsing code out in to its own standalone Zig library.
  • I think a lot of people would be tempted to build more cool introspection tools if only there were an easy-to-use library for parsing debug info that was free of license obligations
  • Gimli for rust looks great and pyelftools is great, but for folks writing C or Zig programs, there aren't any great options that are obligation-free as far as I can tell (I certainly could be missing some lesser-known libraries besides the major ones).
• I'm going to focus mostly on remote debugging since this is how I will personally use the debugger.
  • I'll be creating a headless "remote daemon" mode for the debugger that is accessible over the network.
  • This is particularly important for a Linux debugger as most of the code I care about isn't actually on my machine; it's somewhere in a data center/cloud.
• Since I'm focusing on remote debugging, I'm going to rip out the native desktop UI and instead create a web UI that will access the remote daemon from the browser (even if it's just running on localhost).
  • I'm sure this decision will be controversial, but there are many reasons to not ship a native desktop UI for Linux.
    • It's the wild west, and I cannot reasonably support all flavors of Linux desktop as a hobby project.
    • It's already been an issue for myself and my very limited user base, and it will only get worse over time.
  • At time of writing, the browser is the highest bang-for-your buck in terms of UI quality to time invested.
    • There are some really impressive native UIs out there (1, 2), but they take a ton of time and effort, and frankly I currently don't have the graphics chops to build a beautiful, professional native UI. I could learn these techniques over time, but that takes spare time and energy that I don't have.
    • I used to do a ton of web development, and I'm pretty confident I can build a reasonably good UI quickly.
    • It will be written in vanilla js and still be fast and light-weight!
  • I have a strong preference for only distributing statically linked binaries, and shipping an executable with a native GUI that's GPU-rendered is a really tall order.
    • Perhaps it's impossible? Not sure. In any case, it would be going against the grain.
    • CPU rendering is of course possible, but that comes with its own downsides (poor performance and battery draining mostly).
  • The user-supplied visualization plugin story becomes so much simpler when you're working in the browser.
    • It's important that writing plugins is approachable by the programming population at large, otherwise very few people will write them at all.
  • The uscope code is set up in such a way that adding a new UI is actually quite easy, and we can ship multiple UI types in the same binary.
    • For example, we can simultaneously support "remote daemon" mode as well as something like "cli" mode which would be akin to a more traditional gdb/lldb cli.
    • I'm mentioning this because it may be a good time to add a cli debugger, though no promises. I still think that the visual debugging story is dramatically more important than cli debugging.
    • The community can still maintain a native UI if they desire; it just won't ship as part of stock uscope.

Those are the updates, and they're pretty major ones! Come discuss on Discord if you have feedback.

I've been doing these short updates about once a month so far. Definitely expect that to slow down - there's no regular cadence to my writing on this site.

That's all for now! Thanks for reading!