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

141–150 of 158 posts

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

#141

Post by xondono »

widdershins wrote: post #101
xondono wrote: post #90

Earlier quoted context omitted.

> There are plenty of good, less complex languages than C++ out there […] But C is non of them. To this day I cannot understand how anybody can claim that. C++ is so ridiculously complex that it’s not a superset of C mostly because of added keywords and rules , some of them implicit . > I suggest using a c++ compiler to write C with enum classes, std::span, either a typed std::span wrapper for malloc or std::vector ,…

You can think of simplicity in various ways - some subset of which are valid. For example, you could say that using std::unique_ptr is simpler than manual memory management, because it automates much of the process, making it less likely that a developer will make a mistake. Or you could say that the 1000s of lines of C++ std code that you will pull in represents an increase of complexity, because the mechanics are h…

I’m willing to buy that abstractions reduce complexity, but to do that they can’t be leaky abstractions. They should “just work”, and it should be easy to choose among them.

If you need to consider what’s underneath, how is that a reduction in complexity?

C++ abstractions are the opposite. You need to ponder the several options, normally tagged by their implementation details.

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

#142

Post by petee »

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.

#include

Berkeley DB with a header date of 1994 :) In base, and of course it still works.

Sqlite was removed from base, again, in 6.1 (2019) --https://www.openbsd.org/faq/upgrade61.html

with this BSDCAN '18 pdf briefly explaining the issues (unmaintainable) -- https://www.openbsd.org/papers/bsdcan18-mandoc.pdf

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

#143

Post by zephyr9 »

alexshendi wrote: post #53
zephyr9 wrote: post #17

Earlier quoted context omitted.

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

omg it's like I'm Nostradamus!

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

#144

Post by tleb_ »

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…

Careful, pre-fork as described in the given link as worker processes each handling many requests. This result therefore does not answer the question about the cost of one process per request. The one that does seems to be fork, which is way less efficient (~460 seems like a low number of processes spawned per second though, can we really not do more?).

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

#145

Post by jjgreen »

xondono wrote: post #140
jjgreen wrote: post #100

Earlier quoted context omitted.

> Mikrotik version of C ? Reference to the Latvian network kit manufacturer?

Yes, have you used any of their devices? They’re amazing in what they let you do, but their UI is a wall of settings. Doing something as simple as adding an access point will take you a full day if you aren’t familiar with it.

Never used it, but your description makes me want to try it ...

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

#146

Post by jstimpfle »

lelanthran wrote: post #81
pjmlp wrote: post #74

Earlier quoted context omitted.

And that is why most such efforts eventually die. WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that.

> WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that. Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project. 1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it…

"C strings" really aren't anything worth talking about. People take them way too seriously and then complain that they are "unsafe" or "hard to use". Look, C gives you memory to work with and the rest is up to you. Almost the only thing you want from C with regards to strings is string literals.

It should be obvious that most "string" APIs from libc like strcat, strcpy, but especially strtok are ridiculously bad and are only in the libc because of history. Don't use them.

Even strlen() is rarely a good idea to use, and you can (should?) replace strlen("abc") by sizeof "abc" - 1.

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

#147

Post by jstimpfle »

pjmlp wrote: post #82
lelanthran wrote: post #81

Earlier quoted context omitted.

> WG14 could naturally work into something like SDS for strings and arrays, but of course that is out of their goals to ever do that. Maybe it is, but even if it were, sds strings are a poor choice. I used them extensively in a private project. 1. Typedef'ing `sds` to a pointer type. This leaves no indication to the reader of code that any `sds` typed variable needs an `sdsfree`. IOW, for every other standard type it…

My point regarding WG14 wasn't to add SDS as they are, rather vocabulary types for strings and arrays in the same spirit as SDS. When they exist as vocabulary types, the ecosystem can rely on their existence and slowly adopt their use, similarly to threads support introduction in C11, for example.

Apart from plain old fixed buffers, which is what is supported by C just fine and which covers 99% of string processing needs in the areas that C as a language is suited for anyway, ... there are 14 known ways of doing "strings" depending on circumstance, so I don't think it would be a good idea to introduce one mandatory version of them into the C standard. There is already C++ which has std::string, and there are a lot of GC'ed and scripting languages that are more suited for quick and dirty string processing.

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

#148

Post by galdosdi »

LeFantome wrote: post #26
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.

I remember writing CGI scripts in Perl in 1993 ( the year before Netscape ). I am not sure when CGI even became a thing but it could not have been long before that. Not only was “not so long ago” kind of at the very beginning of meaningful web history but it was also for a very brief moment in time ( if we are talking pre-Perl ). Pre-Perl CGI may have never been a thing though as Perl is older than CGI. I recall PHP…

It is true the time when it might have been sane to write CGI in C was very brief. Perl took over almost immediately (and to my chagrin, eventually PHP ate Perl's lunch). I remember reading CGI books that would explain how to do it in either Perl or C, the justification being "in case you need C for performance" but in reality I don't think a ton of C CGI was written. There was definitely some though; I recall poking around in cgi-bin directories and finding some compiled executables (could have been another compiled language like C++) and being disappointed I couldn't view the source like with .pl files.

It really takes you back to a very specific point in time though. A magical time when every year or month software and internet technology would take big leaps and bounds. When you might do things in a way that is very manual and slow compared to today and yet it was amazing at the time.

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

#149

Post by dmux »

teleforce wrote: post #54

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

I'd like to point out that Wapp doesn't necessarily need to be run as a plain-old CGI application, I've had success running it with it's own built in web-server behind NGINX, for example.

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

#150

Post by tonyarkles »

harryvederci wrote: post #111
tonyarkles wrote: post #94

Earlier quoted context omitted.

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!

https://www.johndcook.com/blog/2011/01/12/how-long-computer-... is a decent place to start for thinking about how different timings work for things. It's a bit on the stale side, some things have gotten much faster (e.g. disk "seeks" are dramatically different with NVMe), but a lot of it has stayed similar, and some will never change (packet timing to Europe has a speed-of-light limit for now)
Post reply on HN