Live data from Hacker News

Reading OpenBSD source code daily

blog.tintagel.pl

51–60 of 86 posts

Re: Reading OpenBSD source code daily

#51
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

A lot of us learned this way from John Lions' Unix Commentary. There have been similar books for Linux and Apache. (They didn't have a concordance for the Linux Core Kernel Commentary so I wrote one and sent it the author who mentioned it in the second printing.) But I think for OpenBSD something like SourceGraph is more than enough.

I would recommend the SourceGraph people post browsers for Linux, L4, Xen, LLVM, ... and other great open source infrastructure projects. You'll drive more interest in your product in a helpful way.

Re: Reading OpenBSD source code daily

#52
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

[deleted]

Re: Reading OpenBSD source code daily

#53
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

There's a tool called OpenGrok that pretty much does this except it's free and open source and it works on C code.

Someone has it run on the openbsd code here: http://bxr.su/OpenBSD/ and it should produce a much more useful representation of the code, see http://bxr.su/OpenBSD/lib/libutil/bcrypt_pbkdf.c#98

Mozilla also has one called DXR which is designed for their large, C++ heavy codebases: https://wiki.mozilla.org/DXR

Re: Reading OpenBSD source code daily

#54
post #36
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

I never got around to really testing it, but still remember when OpenGrok was announced, way back when - apparently it's still active. I've been wondering if it would make a good front-end/source-browser component for a trac[t]-like product (with something else for vcs and bug tracking etc): https://github.com/OpenGrok/OpenGrok There's also a list of similar tools at Gnu.org: https://www.gnu.org/software/global/links…

Looks like someone has opengrok run on openbsd here: http://bxr.su/OpenBSD/lib/libutil/bcrypt_pbkdf.c#98

Results seem pretty good.

Re: Reading OpenBSD source code daily

#55
post #46

I love this idea in part because it's the very opposite of the way I tend to work, which is to drive very hard to get a surface understanding of a thing in order to make a very targeted change. I learn lots along the way with this approach, but don't often get the deep, wholistic understanding of existing systems that only comes with repeated exposure over a long time. Some kinds of understanding involve a no shortcu…

> but don't often get the deep, wholistic understanding *holistic

How embarrassing. That's what I get for thumb-typing a comment on the bus before I've had my cofveve.

Re: Reading OpenBSD source code daily

#56
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

There's a tool called OpenGrok that pretty much does this except it's free and open source and it works on C code. Someone has it run on the openbsd code here: http://bxr.su/OpenBSD/ and it should produce a much more useful representation of the code, see http://bxr.su/OpenBSD/lib/libutil/bcrypt_pbkdf.c#98 Mozilla also has one called DXR which is designed for their large, C++ heavy codebases: https://wiki.mozilla.org…

OpenGrok looks wonderful. Thank you for pointing it out!

Re: Reading OpenBSD source code daily

#57
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

> I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and if I wanted to discuss a piece of code with my CS lab partners, I couldn't just share a link.

When you say something vague yet absolute like you "had all of the various language support modes configured," that is a big indication that you did not have them configured. There are about four major modes for C/C++. Searching and cross-reference is done with external tools. The only time I ever thought searching was slow was when using the grep that came with Mac OS X. There is absolutely no way that online tools can beat ag or rg for code searching, especially if you have an SSD. Exuberant ctags and GNU Global work for cross-referencing and support dozens of languages. And you have Magit and VC mode right there to track down source code history.

Re: Reading OpenBSD source code daily

#58
post #50
post #31

Completely agree. But the tools don't make this very easy. Back in college I was working on patches to OpenSSL, Chrome, Firefox, Apache, etc., to add support for TLS-SRP, and it was a huge pain to jump into these massive codebases and try to understand them. I was using Emacs and had all of the various language support modes configured, but go-to-definition and cross-references barely worked. Searching was slow, and…

Just some honest feedback on your pricing that's hopefully helpful: Your Enterprise plan is at least an order of magnitude more expensive than what many organizations would pay for something like this. E.g. a Jira license for 2000 people costs $24,000 yearly[1], licensing this for the same amount of users would be $1,200,000. This is way more than organizations of that size tend to pay for top-tier support contracts…

Granted, Jira ends up costing way more than $24,000 yearly, because all plugins need to be purchased for all users, and Jira tends to require employing at least one full-time admin. All-told, it's more in line with a few hundred thousand dollars yearly.

With that said, $1.2 million for 2,000 users yearly for a code-search tool is some pretty insane Kool-Aid pricing, and it prevents me from even recommending it to my bosses - I'd be laughed out of the room.

Post reply on HN