Possibly (dunno). But they refer to that on slide 7:
- We also introduced new safer APIs like reallocarray()
- I wrote a big diff for nginx to adopt reallocarray() other such techniques
- And it got rejected.
It's OpenBSD specific. But it's also just 10 lines of portable C that are permissively licensed and can be added to any project without problems. It's even in a separate source file for this very purpose [1]
how do you get off making snide comments like this? They're not doing this because of some mythical elitism that everyone and their mother seems to think openbsd has. They're doing it because they like high quality code and they were pushed this direction by nginx.
you're both being downvoted because you're both completely wrong. it turns out permissively licensed, security-focused, and easy to maintain code bases aren't easy to find outside of OpenBSD. so sometimes they have to write their own.
That'd be true if it weren't for a bunch of external projects that OpenBSD uses or which are hosted as part of OBSD but weren't invented by the OpenBSD folks (tmux is one such example). It all boils down to priorities: if your priority is security, chances are there's very little code out there you can drop in and use.
I'm excited. This is perfect for 98% of people. And apache and nginx are always available for the 2% of people that need to do something more complicated.
Confs look familiar, and it's lightweight and will be secure. Perfect.
If you're never going to use this, it's a nice reading anyway. Goes over their major concerns, their problems with other companies/OSS groups and the design of their solution.
OpenBSD was stuck on Apache 1.3 for ages because the license changes for Apache 2.0+ was incompatible. They also ended up maintaining their own fork for quite a while because patches to improve security were not being accepted upstream (I think)
Nginx:
License is fine, but it's getting feature bloat and the local patchset was getting unwieldy.
Conclusion: roll your own httpd that way you don't have to deal with this anymore.
Not really following OpenBSD, I didn't realize they considered Apache 2 license unacceptable til reading the above. For anyone else curious about the initial discussion of this, it took me some browsing to find http://marc.info/?l=openbsd-misc&m=107714762916291&w=2 (2004)
It will when you write one and focus on your priorities.
For this httpd, it seems like the problem they were solving is that they needed an httpd, and the result is about what I'd expect from the OpenBSD folks.
Rust doesn't support anywhere near the number of platforms OpenBSD does, and has portions written under the Apache 2 license, which has terms that the OpenBSD team disagree with. So the chances of any Rust code ending up in OpenBSD anytime soon are slim to none.
Correction: all of the Rust compiler is dual-licensed under both MIT and Apache 2. If you distribute the Rust compiler yourself, this means that you can pick one license or the other or both. You can also retroactively defer the choice of license until a legal challenge appears, at which point you can collapse the license superposition to your liking. This is the whole point of dual-licensing!
Color me old and skeptical about "simple," "lightweight" web servers. Does anyone else remember when nginx was touted as the "lightweight" replacement for Apache because Apache was often "overkill"? (e.g. http://arstechnica.com/business/2011/11/a-faster-web-server-... )
Now it's this new httpd that is lighter than bloated nginx.
So, maybe nginx and apache and all the other webservers out there are too big and bloated and sloppy, despite being written by smart people and used to deliver many many performant websites. That's possible.
But it is also possible that, because programmers love to start from scratch and reinvent the wheel rather than reading and understanding other people's code and rather than researching other domains, they tend to create weak web servers and tout them as "lightweight" until eventually they either die or evolve to be useful to people who actually understand the nuances of serving resources over the web, at which point they get accused of "featuritis" and the cycle repeats.
At least for now they seem to be very fixed on just providing a very basic server and not trying to cover as many use cases. (see their bugtracker for what counts as "featuritis": https://github.com/reyk/httpd/issues?q=label%3Afeaturitis )
34 comments
[ 2.9 ms ] story [ 75.2 ms ] threadWhat situation?
[1] https://github.com/robertbachmann/openbsd-libc/blob/master/s...
say, a packet filter, for example...
They're not appropriating it. They're just creating another reverse proxy.
- They need a web-server in base.
- They demand security.
- He submitted a patch for nginx to embrace new secure methods.
- It was rejected.
- Because a base server is required in base, and they don't want to maintain a fork of nginx for base: "Introducing HTTPD".
Confs look familiar, and it's lightweight and will be secure. Perfect.
It's young; not expected to be base until this fall. Give it a few months and you'll see it in there.
As a random guess, is it because Apache focuses on features, nginx on speed, and OpenBSD wanted a focus on security?
OpenBSD was stuck on Apache 1.3 for ages because the license changes for Apache 2.0+ was incompatible. They also ended up maintaining their own fork for quite a while because patches to improve security were not being accepted upstream (I think)
Nginx:
License is fine, but it's getting feature bloat and the local patchset was getting unwieldy.
Conclusion: roll your own httpd that way you don't have to deal with this anymore.
For this httpd, it seems like the problem they were solving is that they needed an httpd, and the result is about what I'd expect from the OpenBSD folks.
Now it's this new httpd that is lighter than bloated nginx.
So, maybe nginx and apache and all the other webservers out there are too big and bloated and sloppy, despite being written by smart people and used to deliver many many performant websites. That's possible.
But it is also possible that, because programmers love to start from scratch and reinvent the wheel rather than reading and understanding other people's code and rather than researching other domains, they tend to create weak web servers and tout them as "lightweight" until eventually they either die or evolve to be useful to people who actually understand the nuances of serving resources over the web, at which point they get accused of "featuritis" and the cycle repeats.
(See also http://www.joelonsoftware.com/articles/fog0000000020.html)
That sounds absolutely reasonable and like a good policy.