Hacker News new | past | comments | ask | show | jobs | submit login
Voltron: A hacky debugger UI for hackers (github.com)
260 points by okanesen on Apr 12, 2016 | hide | past | web | favorite | 73 comments

Sometimes my girlfriend reminds me that its kinda fucked up that I get excited when the things I need to understand are presented to me in a more readable way but still look like the Matrix to her.

My wife looks over my shoulder and refactors my code.

It makes sense actually. The imaginary world in the matrix trilogy is inspired from the unix hacker folklore [1]. So if you're a hacker, it's not surprising that what's on your screen looks like what's on the screens in the Matrix.

[1] as shown here https://www.youtube.com/watch?v=0PxTAn4g20U

I could barely restrain my excitement when I first saw the green-screen scrolling visuals in the Matrix, especially the scene at the end where Neo looks underneath the surface of the world. It was the first time Hollywood's cinematic license had created something that looked the way my internal experience felt, and that was a powerful moment after years of eye-rollingly ridiculous movie computer cheese.

I could barely restrain my excitement when I first saw the Social Network. I think that movie did a particularly good job of showing real-world hacking.

(Your HN profile link appears to be broken.)

(Thanks, I removed them.)

I saw this before and it always looked like a nice pice of software. The sad part is, it is still at "0 releases".

To the developers of this software: please provide a stable release that can be packaged for the popular package managers/distributions. That will help to spread the word about your work and make it easily accessible.

Not everyone uses the Github "releases" feature, you can have a release without putting it on there. They've currently released it on pip.

Not having a git tag for your release would be bad style. Actually, releases should always be tagged in order to make them reproducible. Everyone should be able to see what is in a release.

Releasing software properly means that you actually care for this. Please do not just dump a git repo somewhere and expect distributions to pick up from there.

RTFM? Release versions are on pip. Unfortunately most distros think they have the one holy package management solution. pip IS a release and distribution system. With the current popularity of Python, it is only going to be a matter of time before apt / rpm / etc support working through it.

It is trivial to generate a .deb from nearly any pip module...

sudo apt-get install devscripts python-all-dev python-stdeb; cd path~to~pip; python setup.py --command-packages=stdeb.command bdist_deb

It's trivial to do a lot of niche catering and die by a thousand cuts. It's also trivial to install pip.

I'd hardly call debian and its derivatives 'niche', but whatever floats your boat...

It's not niche in terms of OS deployment, perhaps, but a user's request for a `deb` file over traditional python packaging certainly is.

Perhaps, but this is to answer the call of 'os-native' packaging. I'd figure between msi+pkg+rpm+deb you'd have most of the bases covered.

Death by a thousand cuts! Pip is enough for anyone with google.

This sounds crazy but we are actually in a situation where it is preferable to deploy python libraries via APT

> With the current popularity of Python, it is only going to be a matter of time before apt / rpm / etc support working through it.

LOL, not gonna happen. Ever.

Yep, just like what happened with CPAN and PEAR / PECL. Perl and PHP were / are popular too (so are ruby and node and go and Java and C++ and ...) and yet they still have their own independent package managers despite sometimes having very outdated versions of some modules in an distro's packaging system.

Hm, I wish my package manager understood pip. I always forget to upgrade pip along with my distro packages.

cough Arch User Repository, the one holy package management solution calling in cough ;)

Indeed. Can't remember last time I installed a package using pip. This one, particularly, sits at https://aur.archlinux.org/packages/voltron-git/


There was actually already a v0.1 release on PyPI and had been for some time, it just wasn't tagged on GitHub. The README says to use `pip install voltron`.

I've just never been a fan of console-based debugging. The greatest thing an IDE brings to the table for me is debugging against a GUI editor window.

I recently discovered you can use GDB from inside Emacs. [1]

Before, I always used some awkward IDE to debug with a live source view, then switched back to my editor to fiddle with code... but with this things are finally unified!

(Of course, to use it you first have to be able to tread water in Emacs...)


many-windows mode is really nice. But this offers memory dumps, which I miss from codewarrior.

From the screenshot it appears as if they're debugging a program, for which they don't have the source code. Debugging against an editor window probably wouldn't help here.

I guess the news here is that they now use Capstone. I haven't tried either, but I'm excited for a de-facto standard open-source disassembler. A lot of great tools could come out of it. Now if we had something of similar quality for decompilers...

...after IDAPro is pried from many cold, dead hands.

Wow that looks a lot like softice

I've never used SoftICE, but my first thought was that it looks a lot like MacsBug.

I've always felt grumpy at the amount of work I have to do to convince gdb to show me anything useful when I'm trying to debug a program; it feels like debugging through the wrong end of a telescope. This screen shot feels like an immediate shot of relief - "oh THERE it all is, whew". I don't know if I'd even use all that information very much, but the sense that "all the context is right there in front of you" is a powerful one.

Very close. http://commandercat.com/img/ms06007/softice-1.png

It was a great app.

Definitely inspired by other debuggers (OllyDbg, Immunity Debugger, etc) that were inspired by SoftICE :)

Seems good. Actually what I like most is that it appears to be well documented, so it might be worth a try. I always found cumbersome to use console based debuggers, and wonder if there's any real advantage once the learning curve as been climbed.

Reminds me of gdb-dashboard [1] with the additional debugging engines supported. Very nice.

[1] https://github.com/cyrus-and/gdb-dashboard

Can those alternatives debug without the source, which seems like one of the features of voltron?

Adding to your possible alternative list:

* vim https://github.com/joonty/vdebug

You're getting downvoted because this is not a code editor, it's a frontend for several debugger backends that would mostly be used when you don't have access to source code.

Do people outside of MS actually use WinDbg?

We [IBM JIT for J9 team] use WinDBG as part of our tools to debug problems that show up on Windows.

I use it often via gflags to start on process startup, because WinDbg startup is a lot faster than letting the process crash, windows showing the error dialog, and then clicking in the visual studio version selector to select Visual Studio.

Mostly Microsoft or Windows device driver developers, but also people who want to reverse engineer device drivers.

There's many DRM / anti-hacking tools that rely on windows drivers to hook Windows kernel APIs at the lowest level they can.

Yeah security people use WinDbg a lot.

A few friends of mine that do memory forensics made extensive use of WinDBG to debug memory translation code. In the memory forensics developer community (yeah, very specific) WinDBG is one of the most reliable tools to use.

Does it work with disassembly-flavor att ?

No syntax highlighting for AT&T syntax atm. It still displays it, just not highlighted. Feel free to add a Pygments lexer for it and send me a PR :) I'll probably get to it some time, but there's other stuff ahead of it in the queue.

Cat it be used in a more traditional use case with source available and locals/watch/etc views?

It has a "command" view which executes a debugger command and displays the output each time the debugger "stops" (ie. whenever you step over an instruction or a line of code, or hit a breakpoint, etc). So anything you can do with a debugger command, you can stick in a view.


$ voltron v c "fr v"

$ voltron v c "source list -a \$rip"


<This is where I was being stupid before. I have removed that stupidity.>

I think you misread the title. It is a system for composing UIs for hackers running debuggers, not a UI for 'hackernews'.

This is a debugger, not a HN reader. Maybe you commented on the wrong post by accident.

Reminds me of softice

It reminds me of the emacs gdb mode.


Please stop spamming HN. It's a nofollow link anyway.

Can't you do this with tmux instead?

Read on, this is exactly how it is meant to be used. You can run the various `voltron view` commands in separate panes.

This would be a nice example configuration: https://github.com/tuxotron/voltron-tmux

Reminds me of visual studio

Looks like a nice operating system, but it seems to lack a decent editor..

Edit: Downvoters, can you care to explain? I would actually like someone to reinvent Emacs (or Vim, for that matter) as something more general.

(This is not an operating system.)

For lack of a better word, yes! You're taking it too literally - if I wrote something else, then I couldn't make a subtle reference to Emacs.

I wish this project success, and if it will be successful, it will no doubt evolve into having it's own scripting language and other things. Basically, it will become "operating system" like Emacs.

PS. It's unfortunate that people here downvote for misunderstanding a common reference.

> It's unfortunate that people here downvote for misunderstanding a common reference.

No, people here downvote for saying things that don't actually add to the conversation. "Hey, I know an old joke about Emacs!" doesn't add anything to the conversation here. (Voltron is not particularly Emacs-like; its readme says in its second paragraph that it "doesn't aim to be everything to everyone"; it's not a thing anyone is going to spend all their time in; the parallels it would take to make the reference apposite really aren't there.)

Also, I think you botched the joke; "... but it seems to lack a decent debugger" would have fitted the pattern better. (But it still wouldn't have been either very funny or very insightful.)

Oh, and I downvoted your second comment for complaining about being downvoted; I have a policy of always downvoting waah-I-was-downvoted comments when I see them. (Unless what they're complaining about is a very clear injustice, which it isn't here.)

Actually, I didn't botch the joke - it was you who missed the subtle point I was making. I think that, paradoxically, this may evolve eventually to more complete (operating) system with an editor, just like Emacs has a debugger.

That's why I asked the question, and made a clarification (which unfortunately killed the reason for being subtle) - your "doesn't add anything to the conversation" missed the point! (Actually, downvoting without a comment doesn't addd anything to the conversation either.)

It looks like your original post doesn't actually say any of those things. There's a line between subtle and uncommunicative.

I think the 1st does, if you're willing to entertain the idea that it's not just the old joke about Emacs. The 2nd one actually explains it quite well.

In any case, I think that downvoting without a comment crosses that line too. Sadly, the only guy who was willing to explain his disagreement with my original comment got downvoted too.

> I think that downvoting without a comment crosses that line too

You're not being "downvoted without comments". gjm11 has made the effort of explaining to you why he's downvoting you. Expect a lot of people to feel the same way.

Your comment was unnecessary, unjustified, insulting and you're still defending it. Don't be surprised.

I wonder what you think was insulting in it? I was not particularly defending it, merely explaining the original intent; I don't see any insult in it. (Actually I wish people would discuss the valid point I made, as marssaxman did below, rather than the segway.)

gjm11 explained his downvote, but after I asked. He was also downvoted (temporarily) for some reason.. I don't understand why calm debate about why something was downvoted is a source of so much emotions, that people have to downvote it as well.

It makes me unhappy when people downvote without commenting, because it doesn't add to a discussion either.

Why on earth would this project evolve in such a way? I don't see what would push it in that direction, so I don't understand why it strikes you as an inevitability.

(Assuming here a very successful project.) It's simple - people will want scripting. That's where it will start. Once you have scripting, mods will come - useful things like integration plugins for languages, for instance. Then you will need parameter and configuration system, for things like keyboard shortcuts and themes. Then will come its own packaging system for those mods. Eventually, it will evolve into a complete ecosystem on its own. It happened with every bigger IDE out there, and they are much less hackable than this purports to be. All this is just a consequence of making system hackable.

Is there any type of project for which this would not be true?

I can't think of any example. Maybe some other sort of software than the ones for programmers, say, graphic editors - there are some that are pretty hackable but they aren't being hacked too much despite having users.

That's why it's so striking, that the developers here seem to declare to fight this "almost a natural law". They want something hackable, yet they want the thing to have very specific purpose, but I think, if it will succeed, it will take life on its own. I think they should plan for it and embrace it, instead.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact