Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BCHS: OpenBSD, C, httpd and SQLite web stack

learnbchs.org

Post reply on HN
Print view View original

11–20 of 158 posts

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#11

Post by the_only_law »

dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

I just wish there were better tools for navigating C codebases.

There’s been more than one time where I’m in some large auto tools based project trying to figure something out and there’s a call out to some dependencies I have no idea of.

Also many of the projects lack and sort of documentation or source code commenting. These aren’t someones pet project either. One of them was from a notable name in the open source community and the other one was a de-facto driver in a certain hardware space.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#12

Post by [deleted] »

dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

[deleted]

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#13

Post by newlisp »

lazyfuture wrote: post #5
dleslie wrote: post #3

I'd be fine with this, even totally on-board, if C weren't so awful with respect to text. You don't even have to worry too much about free()ing your malloc()s if you design around short-lived processes. But this is just asking for security concerns among the tangled web of string and input processing your bespoke C routines are likely to develop into. Pair it with a better, more modern, and safer native-compiled lang…

Same guy wrote a rad tool that will generate server code, schema, frontend using a markup language called ORT. Will generate Rust and typescript if ya want.

One of the most rewarding parts of back-end web application development is re-writing the same database routines and same JSON export routines over and over. Then changing the requirements and starting over. It's what makes web application developers such well-balanced folks, right?

Unfortunately, in the flux of user requirements—each addition or modification of a table column changing select routines, insertions, validation, exporting, regression tests, and even (especially?) front-end JavaScript—we make mistakes. What BCHS tools beyond the usual can help in this perennial test of our patience?

;)

https://learnbchs.org/kwebapp.html

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#15

Post by jamal-kumar »

People love to talk all sorts of trash on this kind of stack but it's really quite solid for what it does. If anyone was ever curious what a sizeable codebase in this kind of code would even look like, check out the source code for undeadly.org [1]. Yeah these people may be crazy but they're also OpenBSD developers and we really love to see what we can get away with using nothing other than what's available in the base distribution. I think a lot of what you see being written for production ends up being very similar to this kind of approach, maybe just utilizing rust or golang as the web application backend language if that's what is the more comfortable thing. Nothing but the base system and a single binary, not relying on an entire interpreter stack, sure can be smooth.

There's other examples of this kind of approach, too, writing straight C Common Gateway Interface web applications in public-facing production use - What comes to mind is the version control system web frontend that the people who write wireguard use, cgit [2] - If it's really so crazy then how come the openbsd and wireguard people - presumably better hackers than you - are just out there doing it?

Other places you see C web application interfaces include in embedded devices (SCADA, etc) and even the web interfaces for routers, which unfortunately ARE crazy because check out all the security problems! Good thing people at our favorite good old research operating system have done the whole pledge(2)[3] syscall to try and mitigate things when those applications go awry - understanding this part of the whole stack is probably key to seeing how any of it makes any sense at all in 2022. It sure would be nicer if those programs just crashed instead of opening up wider holes. Maybe we can hope these mitigations and a higher code quality for limited-resource device constraints all become more widespread.

[1] http://undeadly.org/src/ [2] https://git.zx2c4.com/cgit/ [3] https://learnbchs.org/pledge.html

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#16

Post by Ostrogodsky »

edfletcher_t137 wrote: post #14

This feels like an unreasonable eschewing of all the advancements in programmer ergonomics & tooling that have been made over the course of decades. "Just because you can, doesn't mean you should."

> "Just because you can, doesn't mean you should."

Ironically I could say the same about the JS ecosystem.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#17

Post by zephyr9 »

jamal-kumar wrote: post #15

People love to talk all sorts of trash on this kind of stack but it's really quite solid for what it does. If anyone was ever curious what a sizeable codebase in this kind of code would even look like, check out the source code for undeadly.org [1]. Yeah these people may be crazy but they're also OpenBSD developers and we really love to see what we can get away with using nothing other than what's available in the ba…

The Dunning-Kruger effect is stronger in people who spend a lot of time alone, e.g. programmers, which we will now see unfold below.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#18

Post by da39a3ee »

I’d like to love man pages but

- I feel that they are linux only. On my MacOS system I can’t rely on man x being the man page for the right version of x. I know that in principle there are environment variables that make sure i’m getting the gnu core utils version or the base homebrew version rather than the system BSD version, but it’s too many moving parts. Furthermore even if I get it right, I can’t expect people I’m working with or mentoring to get it right, hence I can’t recommend man to them for documentation. God knows about man pages on Windows.

- I feel that a small amount of plain text documentation should be stored in the executable, not separately. Isn’t it a holdover from the vastly more constrained computing environments of the 70s and 80s that we’re keeping man pages separate from the executable? Its just asking to get out of sync / incorrectly paired up.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#19

Post by synergy20 »

_wolfie_ wrote: post #8
synergy20 wrote: post #7

Earlier quoted context omitted.

well there are still many large software written in C, e.g. nginx, lighttpd, even linux kernel. I checked BCHS a few years back, the key piece is that it's Openbsd, if it's Linux it might have caught on, due to linux's popularity, good or bad. This could be useful for embedded device for example, but not so many embedded devices running OpenBSD, if any at all.

The C library used ( https://github.com/kristapsdz/kcgi ) is portable and working on linux as well. Putting this behind nginx as fastcgi seems very well doable.

there are also qdecoder or cgic or fcgi etc are totally linux ready for CGI, which by the way, all worked well. CGI is still perfect for a deeply embedded linux device.

Re: BCHS: OpenBSD, C, httpd and SQLite web stack

#20

Post by codazoda »

wk_end wrote: post #10
galdosdi wrote: post #6

Earlier quoted context omitted.

Funny to reflect that there was a time not so long ago when writing web apps (CGI usually) in C wasn't at all unusual (shortly before Perl became much more popular for this). And today, it is indeed kind of crazy.

Depends on your definition of "not so long ago" - it's certainly most of the history of the web. The point when Perl, PHP, and Java started to become the dominant web app technologies is about as far from the present day as that point was from the moon landing.

The moon landing was 1968, 26 years before PHP was created in 1994. And that was just 28 years ago.

Oops, math checks out. I’m old.

Post reply on HN