I'm not sure how this is significantly better than using say Rust or Go with sqlite embedded, which can be built statically and target any number of hosting platforms with less chance of memory bounds, leaks and the host of issues that tend to surround applications built in lower-level languages at any kind of scale.
It's a nice advertizement for OpenBSD, and in general, I feel the BSDs don't get enough recognition as an alternative to "Linux Everywhere"... that said, I'm not in favor of C as a core tech stack language for higher level line of business applications, which is a majority of software developed (in isolation from other, or more popular or more widely used software).
Having actually written web applications with C as my very first web-dev job, my opinion of this is... not high.
I'm sure at this point there are better abstractions to use (nobody knew how to structure a web app way back when) and there's less ad hoc templating and other string cobbling now, but I can't imagine going back unless there were compelling performance gains I needed and couldn't get any other way.
I like this little project. Nice combo. Let's take it to another level:
BALS (pronounced "Balls"): What you have when you combine [Open]BSD, Ada, Lighttpd, and SQLite. Smokes BCHS in both safety (Ada) and probably speed (web server). Especially when you rewrite the web server in Ada/SPARK with all checks on. :)
Yeah, I saw it a while back. Messed with them about using OpenSSL. Predicted problems. ;)
Yeah, low-level stuff can be painful in Ada for we apps. My main idea was to make a scripting language with type inference and annotations that would autogenerate Ada code. Its own constructs handle web safe by default. See Opa language for example.
Another idea was porting Python and stdlibs to Ada or Rust. So, you get Python or its web frameworks at user level. Underneath, you get safe, systems constructs to make abstract machine and performance-critical stuff run safer.
Using Ada as an intermediate language is an interesting idea --- it's a richer language than C, and is more well-defined than C (although it still has undefined behaviour; plus an exciting thing where certain undefined values can be illegal to even look it). And it generates excellent machine code.
But getting hold of an Ada compiler is much harder than a C compiler. And in real life there's only one Ada compiler, which is gcc, and it's developed by Adacore. If they went under then I'm not sure there'd be enough people to maintain it. So you very much get toolchain lockin. (Plus of course there's Adacore's lawyerbomb in their Gnat distribution, but that's easily avoided by getting the one at getadanow.com.)
So... dunno. Try it! It'd be really interesting to know how well it works.
"(although it still has undefined behaviour; plus an exciting thing where certain undefined values can be illegal to even look it"
You have a link that describes that stuff?
"If they went under then I'm not sure there'd be enough people to maintain it."
There's at least 3 or 4 that I know of. Theirs is best bet for combo of investment into it and FOSS friendly. And, yet, we still have liability you describe. One of reasons I pushed Free Pascal and Modula-3 for future-proofing is that even amateurs could figure out how to port toolchains. Ada? I have serious doubts that even pro's could figure it out without AdaCore et al's help haha.
"(Plus of course there's Adacore's lawyerbomb in their Gnat distribution"
What is it? News to me.
"but that's easily avoided by getting the one at getadanow.com"
Re undefined behaviour: I could be wrong there, actually. The rules are complex: http://www.adaic.org/resources/add_content/standards/95lrm/A... But if you have an undefined variable with a limited range, e.g. an enumeration, then it's possible the contents of the memory location might correspond to an invalid value for that type. So, accessing that variable in any way other than assigning to it is erroneous behaviour (of some variety). But I forget whether the compiler is required to check and error out or whether it merely can check and error out if it likes.
Adacore's Gnat distribution (at least the last time I looked at it) had the standard library GPL licensed, not LGPL licensed... thus making any binaries built with their toolchain undistributable unless they're GPL'd.
"hipster-free" really? :-) I think it's the definition of hipster: Low value framework(compared to established web frameworks), will be used a bunch of devs for corner cases OR (mostly I guess) to brag about it (on hackernews, reddit, mailing-lists, forums, chats, etc.)
That said, I'm glad it exist, the more choice we have the better :D
Hipster is one of those words whose meanings have shifted over time towards their complete opposite.
In this case I believe it goes hand in hand with the "hipster look" growing into the mainstream a few years ago. With many people going for the "I'm not like other people" mindset, ironically they ended up looking like everyone else in the "hipster" group, thus kind of reversing the meaning of the word in the eyes of most people.
<flameshield>
In the case of the programming world, Ruby/RoR used to be the go-to hipster language/framework, but even as Rails grew into the mainstream with big actors like Microsoft adopting bits and pieces from it for their own tooling the label never really left, creating a situation where you have a big popular... hipster thing.
</flameshield>
> BCHS (pronounced /biːtʃəz/, beaches) is for real development. It's a hipster-free, open source software stack for web applications. To prepare a BCHS environment, install OpenBSD. Then get started.
Referring to something as "hipster-free" automatically classifies you as hipster. It's similar to how asking "Am I cool?" automatically disqualifies you from being cool.
With sufficient sandboxing, and depending on the needs of the site in question, this is actually possible to do securely.
When you use sandboxing properly, the security of your application doesn't depend on how complex it is or how many features it has. This is a huge advantage over secure programming languages, where bugs are less likely but still some constant factor of KLOC.
That said, not every application can be sandboxed easily.
It's funny that they say that because I would say, if I did call things hipster, that this was hipster. Typically hipsters are defined as people that go against mainstream. Well this is pretty far from current, popular app dev environments.
I was actually thinking this sounded incredibly hipster -- heading towards some (in my opinion) completely inappropriate minimalism, where writing vaguely secure code will be almost impossible, and you end up having to write huge amounts of simple base code which should really be provided for you.
Yes, that's harsh, but I think starting new web server projects in C nowadays deserves the harshness.
Man, there's so much irony with using OpenBSD (an OS designed with security in mind) with a web app written in C.
While half asleep the other night, I randomly found a very obscure but also dangerous remotely exploitable buffer overflow in C++11 code I had written a while ago -- it's still very possible even with a modern C++ codebase.
Keep in mind that OpenBSD also has a very much locked down malloc in addition to everything else, so buffer overflows are more likely to crash loudly and quickly than to corrupt data and/or allow for exploits. The malloc used in glibc -- ptmalloc2 -- is absolutely terrible for pretty much anything modern, and really should be set on fire and pushed off a cliff.
Android uses dlmalloc, which is basically the parent of ptmalloc2 and rather similar. With using the NDK, I have doubts that you'd be able to mix and match mallocs. I'm not finding any benchmarks one way or another with OpenBSD's malloc, other than the caveat that in debug mode, it becomes a lot slower, so I imagine that performance is similar.
Wait, is it really true that OpenBSD's gcc is from the 4.x series?
Apart from the general idea that you shouldn't be writing network-facing software in C when good alternatives (Rust, Go, C++11, Haskell, just about anything else) exist, there's a lot of good work happening in upstream GCC. How up-to-date is OpenBSD's -fstack-protector compared to GCC 6's?
> Write portable and secure C.
If you're running on the BCHS stack, why? And how is it possible to reconcile this with the suggestions to use systrace(4), pledge(2), and capsicum(4), which aren't even portable among the vibrant BSDs?
SQLite is one of the world's most popular databases in production (I heard it's the most deployed database in the world, but I'm not entirely convinced) so it surely can't be awful at least..
For webapps, it's a mixed bag. I've run a few sites with low 6 figure pageviews per month (i.e. as big as probably 90% of all sites) on it without problems but in situations with high levels of concurrent writes, it's classically been advised against. If your app or framework of choice likes to timestamp every database record it touches or logs heavily to the database, be careful ^1.
(^1 - SQLite 3.7, which I've not played with yet, supports a write-ahead log mode which means writers and readers don't block each other. This could resolve a lot of potential performance snafus.)
> I heard it's the most deployed database in the world, but I'm not entirely convinced
That's absolutely true but not really a fair comparison. sqlite is the go-to method for storing structured data in desktop and mobile applications (Android, iOS, Windows, Chrome, Firefox, ...), accounting for many billions of installations, whereas the other things that people usually call "databases" (e.g. MySQL) obviously aren't meant for that use case.
>forget your LAMP instincts to desperately search Google and StackExchange for every parameter: man pages are your new best friend.
The amount of arrogance here is astounding. For one thing it's a trope that Linux doesn't have good documentation, RHEL has better docs than anything I've seen from BSD. C is a whole software language and AFAIK you can't just "man c" and even if you could why would you want to read the whole manual/handbook for the C programming language to figure out something trivial? You would google it anyway.
The only reason using man pages on BSD might be better than google is because 90% of the answers you'll find on google will be from a Linux perspective and you'll have to do a second search to figure out how to apply the answer to BSD. Yes, 90% of the time the Linux solution will work on BSD but the 10% of the time when it doesn't is a huge pain.
That was my first thought too, but there actually might be something to it.
The thing about man pages is that they require effort and force you to develop deeper understanding about the tools you use. From that perspective, it can actually be helpful to apps quality. I genuinely think that most of web developers now (myself included) got used to solving problems by quick and dirty means. Our whole development process seems to be based on piling technical debt until we can't figure out what's going on.
I'm not actively encouraging using this stack for development, but as a wake up call it's not without merit.
>The amount of arrogance here is astounding. For one thing it's a trope that Linux doesn't have good documentation, RHEL has better docs than anything I've seen from BSD
I think you'll have to accept that many people simply don't agree with your opinion here.
Everything about how this is written is so hipster. Cool idea though.