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

51–60 of 158 posts

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

#51

Post by Zababa »

exdsq wrote: post #45
Zababa wrote: post #23

Lots of opinions but little facts in the comment. I'd love to see an experiment with people using that and their preferred web stack. Is this really slower to develop? By how much? Is this really unsecure? Is this really simpler, faster?

I’d wager a good portion of my salary that a skilled BCHS developer is slower than a skilled Django/RoR developer to build a usual web app (with auth, payment gateways, admin panels, etc). Not to say BCHS doesn’t look like a laugh to use.

I would too, but I'd like some hard data on this. For example, how much slower? 2 times? 10 times? 100 times? Is this an initial cost or a cost paid on all features? Is maintenance easier? Harder?

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

#52

Post by pull_my_finger »

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

Imagine if you were a C developer who needed to create some web do-dads, this is probably a fantastic stack. If there was 1 right solution for the perfect stack we'd all be using it.

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

#53

Post by alexshendi »

zephyr9 wrote: post #17
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.

I propose an amendment to Godwin's Law to include "Dunning-Kruger" , "Dunning-Kruger-effect" and "Dunning-Kruger effect".

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

#54

Post by teleforce »

SQLite author is an avid Tcl user and he recently introduced a small, secure and modern CGI based web application called wapp [1],[2].

[1] Wapp - A Web-Application Framework for TCL:

https://wapp.tcl.tk/home

[2] EuroTcl2019: Wapp - A framework for web applications in Tcl (Richard Hipp):

https://www.youtube.com/watch?v=nmgOlizq-Ms

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

#55

Post by lanstin »

zephyr9 wrote: post #27
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…

Is there a good string-manipulation C library?

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 servers in C are crazy bad idea, especially if they are spitting out html. Lisp would be better. Node would be better. Go would be better.

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

#56

Post by _ofdw »

littlestymaar wrote: post #24
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…

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

If we'd just rewrite all of the things in Rust we could solve computer bugs forever, and world hunger too.

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

#57

Post by na85 »

jimbob45 wrote: post #21
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…

Why would you ever choose C anymore? The killer feature of C++ is “you don’t pay for what you don’t use”. There’s virtually no reason ever not to use C++.

>Why would you ever choose C anymore?

I can't speak to why you'd want to use C in a web stack, but I can weigh in in the more general sense:

A while ago I thought I'd try my hand at the Cryptopals challenges, and I figured, hey all the security guys know C (and python, but ugh) so I'll use this as an opportunity to really learn C. Prior to starting that project, I "knew" C, in the sense that I took CS036 which was taught in that small subset of C++ that might as well be C.

So I jumped in and it felt really liberating, at first. You want to compare chars? It's just a number, use >= and Then by about the 2nd set where you have to start attacking AES ECB I realized I was spending more time debugging my mallocs/frees and my fucking off-by-one errors than I was spending on actually learning crypto. I stuck with it until I think part way through the third set but by that point I couldn't take it any more.

So I bailed out of C and never looked back. I can see how a certain type of programmer (who is more practiced with malloc/fastidious with their array indices and loop bounds than I am) can really enjoy C for a certain type of work. But I can actually say now, hand on heart, that I know C; and I don't like it.

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

#58

Post by RTFM_PLEASE »

da39a3ee wrote: post #18

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…

OpenBSD pages (https://man.openbsd.org/) absolutely rock and other, proper BSDs do quite well.

Also, man pages are for more than just system utilities (man(1)). Which binary should hold pledge(2) (https://man.openbsd.org/pledge), exactly?

Your man pages should be updated when the associated tool is updated.

You are describing a MacOS issue, with its terrible package management, and frustrating toolchains.

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

#59

Post by spudwaffle »

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…

How is the overhead of creating a process per-request in this type of system?
Post reply on HN