Live data from Hacker News

Reading OpenBSD source code daily

blog.tintagel.pl

61–70 of 86 posts

Re: Reading OpenBSD source code daily

#61
post #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…

>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.

In my experience, you're right; but that opinion wouldn't make for a nice long-form advertisement for your software project.

Hook them with hinting "I have a solution better than emacs" first paragraph, add a happy tale about collaboration and friendship, and then pile on the advertisement.

Re: Reading OpenBSD source code daily

#62
I've been using Typing.io as a platform for reading source code (working my way through Gitlab now) and practicing typing with the right fingers. I have a few minor bad habits to correct, and I want to familiarize myself with the codebase, it's a good way to warm up for the day.

Re: Reading OpenBSD source code daily

#63
post #58
post #50

Earlier quoted context omitted.

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…

A JIRA installation with 2,000 users probably has many fewer developers, and you'd only pay for Sourcegraph for developers. For customers where this makes a big difference, we work with them on the pricing.

But if you're a large company with 2,000 engineers, then you could be spending nearly a half-billion dollars on engineering salaries alone. If Sourcegraph makes your developers at least 0.5% more productive, then it pays for itself.

And shouldn't companies be spending 5-10% of their salary budget on getting the best tools? (That would mean tens of millions of dollars annually for this hypothetical 2,000-person company.) Companies routinely pay that for people in other roles, such as salespeople, medical professionals, stock/bond traders, etc. I think we all agree developers deserve the same. :)

Re: Reading OpenBSD source code daily

#64
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…

just installed opengrok and tried it and it's very good.

linux kernel uses LXR, might be useful too.

here is a comparison chart:

https://github.com/OpenGrok/OpenGrok/wiki/Comparison-with-Si...

Re: Reading OpenBSD source code daily

#65
post #44
post #6

Great idea. What other code bases are there that lend themselves to this? Some kind of curated genius.com for source code would be interesting.

If you're into Python, the Flask source is just awesome. I've learned a lot from that code.

Reading through Python itself is quite interesting, there's actually a MOOC somewhere that does this (ie they hack with the interpreter in the lectures), but I can't remember what it's called unfortunately.

Re: Reading OpenBSD source code daily

#66
post #6

Great idea. What other code bases are there that lend themselves to this? Some kind of curated genius.com for source code would be interesting.

I've been diving into OpenCV recently. It's a very popular library and generally pretty readable (although the code can get quite messy because they use vectorisation a lot). Since it's about as close as we have to a standard, fast, vision library, it's interesting to see how stuff gets implemented.

There are loads of little things that could be improved, so it's also a nice codebase for contributing to.

In general I think you should pick something that you use every day. There's no point reading OpenBSD for the sake of reading OpenBSD, you'll get far more value out of something familiar.

Re: Reading OpenBSD source code daily

#67
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…

On first impressions, since I have no experience with OpenGrok nor Sourcegraph, they look to serve about the same core need and provide most the same core functionality, but Sourcegraph is about what I would expect from a company providing usability and features on top of what is generally available for free.

That is, Sourcegraph looks to compare to OpenGrok like Github compares to Gitweb. At least from a cursory look.

Re: Reading OpenBSD source code daily

#68
I've fallen into doing something similar. I read the mailing lists regularly try to look over the source for something that gets a proposed patch. Because OpenBSD boils down their software to the essentials and tries to make their APIs impossible to misuse I find it pretty easy reading even though I'm not very experienced with C.

Re: Reading OpenBSD source code daily

#70
post #26

This is fantastic! I've recently decided to begin reading web browser source code, even though I understand very little of it at the moment. For now, what's been fun is to load up the same file in both Chromium and Firefox source, and compare the two and how both browsers work. Chromium source: https://cs.chromium.org/chromium/src/third_party/WebKit/Sour... Firefox source: https://dxr.mozilla.org/mozilla-central/sour…

Could also be fun to compare to the Servo source: https://github.com/servo/servo

Servo source is also on DXR, which is a lot nicer than the github source viewer since it understands Rust (and other) languages (using an LLVM compiler plugin): https://dxr.mozilla.org/servo/source/
Post reply on HN