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

111–120 of 158 posts

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

#111

Post by harryvederci »

tonyarkles wrote: post #94
harryvederci wrote: post #63

Interesting CGI content linked on there. I've been reading about / hacking on CGI recently, and it's been kinda fun! Question: One thing I keep reading is how inefficient it is to start a new process for each incoming connection. Could someone explain to me why that's such a bottleneck? I imagine it being an issue back when CGI was used everywhere, people moving away from CGI, and forgetting about it. But hasn't ther…

I’m smiling at your question! Yes, it’s less efficient than having a persistent server, but as all things are, it exists in a spectrum. The load time for one of these processes is going to be almost trivial. I’m on mobile right now, but I would guess that it would be in a handful of milliseconds, especially when the binary is already in cache (due to other requests). But if you want to compare this against a lot of t…

Thanks for your response!

I guess I should do some benchmarks comparing different technologies.

> Things like Serverless go the opposite way and tore both your incoming request through a complex set of hops, and also your backend database requests.

I didn't know about that, thanks. If you know some good resources on the topic, feel free to put them in a reply to this message!

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

#112

Post by harryvederci »

lelanthran wrote: post #77
harryvederci wrote: post #63

Interesting CGI content linked on there. I've been reading about / hacking on CGI recently, and it's been kinda fun! Question: One thing I keep reading is how inefficient it is to start a new process for each incoming connection. Could someone explain to me why that's such a bottleneck? I imagine it being an issue back when CGI was used everywhere, people moving away from CGI, and forgetting about it. But hasn't ther…

> Interesting CGI content linked on there. > >I've been reading about / hacking on CGI recently, and it's been kinda fun! > >Question: One thing I keep reading is how inefficient it is to start a new process for each incoming connection. Could someone explain to me why that's such a bottleneck? I imagine it being an issue back when CGI was used everywhere, people moving away from CGI, and forgetting about it. But has…

I'll read those articles you shared, thanks!

Currently the CGI stuff I'm working on is to run stuff on a cheap shared host, so I'll have to check which category of servers that Apache falls in.

Once an application I'm running on a shared host becomes successful enough, I'm probably going to want to move to a different environment, but I'm still interested in what that would mean for performance :)

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

#113

Post by lanstin »

foxfluff wrote: post #85
lanstin wrote: post #55

Earlier quoted context omitted.

No? Asking for code nav and you get three answers. Asking for this and you get crickets. In the 90s I worked at a place where we embedded TCL into all the apps, and rolled our own templating systems. I had to do a little string stuff in C after few years of go, and it sucked. Ugg. buf[len] = ‘\0’; Using go, I thought I was getting back to low level stuff but this C experience made me appreciate strings in Go. Web ser…

> buf[len] = ‘\0’; So why didn't you use one of the bazillion library functions or third party libraries that terminate strings for you? I feel like most of the criticism is coming from people who punish themselves by rejecting library functions and then telling that strings are hard. Doh.

I like to see the terminating nul in there, just in case my math was off earlier. I had strdup and so on. I was just way more work than go. And I was writing a LD_PRELOAD that I didn’t want to drag in any extra dependencies other than libc. Trust me, it is faster and safer and more fun in Go than C.

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

#114

Post by jolux »

rossy wrote: post #46
theamk wrote: post #2

It seems pretty crazy to write web-facing apps in C, with no memory safety at all. (They do have "pledge" but even in the most restricted case, this still leaves full access to database)

It seems like the database libraries they recommend for security, ksql and sqlbox, mitigate the risk with process separation and RBAC, so the CGI process doesn't have full access to the database. It's definitely contrary to modern assumptions about web app security, but it's interesting to see web apps that are secure because they use OS security features as they were designed to be used, rather than web apps that do…

Process-per-request is just infeasible with any significant amount of load.

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

#116

Post by scrame »

FpUser wrote: post #50
littlestymaar wrote: post #24

Earlier quoted context omitted.

> Pair it with a better, more modern, and safer native-compiled language and get the same effect. Zig, Nim, Go, hell even Carp. I love how trollish it is not to talk about Rust in that context.

Your message looks like a perfect example of trolling to me.

This entire thread is a troll, or a demonstration of Poe's law.

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

#117

Post by ainar-g »

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…

Considering that it's a stack that uses OpenBSD, my first thought would be Perl, although it's not a language that one could call “modern”, heh. It's included into the base system and has rich libraries for text processing, (Fast)?CGI, HTML, and all that.

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

#118

Post by foxfluff »

lanstin wrote: post #113
foxfluff wrote: post #85

Earlier quoted context omitted.

> buf[len] = ‘\0’; So why didn't you use one of the bazillion library functions or third party libraries that terminate strings for you? I feel like most of the criticism is coming from people who punish themselves by rejecting library functions and then telling that strings are hard. Doh.

I like to see the terminating nul in there, just in case my math was off earlier. I had strdup and so on. I was just way more work than go. And I was writing a LD_PRELOAD that I didn’t want to drag in any extra dependencies other than libc. Trust me, it is faster and safer and more fun in Go than C.

Alright, yea, if you're working under constraints like that, C sucks more than it has to.

It just doesn't feel fair to criticize C without mentioning that your experience comes from working under such unusual constraints. "Strings are hard, C sucks" is quite different from "strings are hard, C sucks when you can't rely on libraries." Also feels unfair to say you get crickets when you ask for a lib but actually you weren't even willing to use one. (There are tons of string libraries for C, it's impossible to miss them if you look around.)

Even then, if you're stuck working with only libc and your own code, there's a very high chance you're doing something wrong if you're doing math on strings and terminating them manually. There's a fair selection of libc functions that do all the math for you and will always output a properly terminated string if your inputs are a buffer & valid size and strings.

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

#119

Post by jamal-kumar »

visireyi wrote: post #33
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…

we really love to see what we can get away with using nothing other than what's available in the base distribution pkg_add sqlite3 Can't get away.

OK to be honest let me amend that, because you make a valid if not snarky point!

We like seeing what we can get away with using what's available in the base distribution and a few well-chosen, well-audited packages

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

#120

Post by lelanthran »

harryvederci wrote: post #112
lelanthran wrote: post #77

Earlier quoted context omitted.

> Interesting CGI content linked on there. > >I've been reading about / hacking on CGI recently, and it's been kinda fun! > >Question: One thing I keep reading is how inefficient it is to start a new process for each incoming connection. Could someone explain to me why that's such a bottleneck? I imagine it being an issue back when CGI was used everywhere, people moving away from CGI, and forgetting about it. But has…

I'll read those articles you shared, thanks! Currently the CGI stuff I'm working on is to run stuff on a cheap shared host, so I'll have to check which category of servers that Apache falls in. Once an application I'm running on a shared host becomes successful enough, I'm probably going to want to move to a different environment, but I'm still interested in what that would mean for performance :)

> Once an application I'm running on a shared host becomes successful enough, I'm probably going to want to move to a different environment, but I'm still interested in what that would mean for performance :)

Depending on what you are doing and what language you are using, a $5/m DO droplet might be sufficient. I once ran a single multi-threaded server, serving a simple binary protocol, and over a 2 day period it handled sustained loads of up to 30k concurrent connections.

To get it that high, I had to up the file descriptor limit on that host.

Post reply on HN