LAMP Stack

OpenBSD is a meme
default FS doesn't even support SSD TRIM, and OpenBSD doesn't support anything modern like ZFS or BTRFS.
In the CIA triad of Confidentiality, Integrity, and Availability, availability seems to be the one that's lacking. Who cares how hack-resistant your system is if the data you're protecting is corrupted?
That's not even getting into the volume management stuff that's missing, and the snapshots, and the everything.
"b-b-but MUH BACKUPS!!"
What are you even saying? That bitrot all of a sudden doesn't exist anymore? That backups are the one and only thing you should do and should not be supplemented by a more stable filesystem?
You do realize that if the filesystem is not secure and does not protect against bitrot and corruption, your precious backups are going to be fucked, because you'll be backing up corrupted data. Who even knows how far you'll have to roll back in order to get to a clean state?
"Only two remote holes in the default install!!!!!!!"
Yay!
I hope you realize that this literally only applies to a base system install with absolutely no packages added. In other words, not exactly representative or meaningful towards... anything really
A few years ago, OpenBSD was actually in danger of shutting down because they couldn't keep the fucking lights on. How could anyone see this as a system they could rely on, when it could be in danger of ending at any time?
"B-But OpenBSD is written in strictly standards-compliant C! Clearly that's better than muh GNU virus!"
So you're not allowed to create extensions to the standard? You should only implement the standard and nothing more? Keep in mind that this is nothing like EEE, as the GNU extensions are Free Software, with freely available source code, as opposed to proprietary shite. People should be allowed to innovate and improve things.
If you're gonna be anal about standards-compliance, then why let people make their own implementations anyway? Why not have the standards organizations make one C implementation and force everyone to use it?

TRIM when?
ZFS when?
Multicore firewall when?
NFSv4 when?

Let's go into those:
TRIM is vital to properly supporting SSDs. Without it, deleting a few pages from the storage would require the deletion of the entire block before putting it all back, creating unnecessary reads and writes and ultimately causing a faster degradation of the SSD.
ZFS, and other filesystems like it, provide numerous features both for better management of your data with subvolumes, as well as better security. The security features include snapshotting, checksumming of all data and metadata, bitrot protection, excellent implementation of software RAID, and so on. Backups should of course always be made, but they can be complimented with a better FS. I can just imagine it now: An OpenBSD admin routinely backing up his system, unaware that data is being silently corrupted. By the time it's a problem, it's too late. Imagine how far back he'd have to roll back to get to a stable state? If only he had a filesystem that wasn't written in the 80s, and actually did something to protect his data. OpenBSD has best security? I think not.
PF, at least on OpenBSD, does not support more than one core of one processor. Linux's netfilter on the other hand, does. Not much else to say.
It's been 18 years since NFSv4 was originally standardized, and OpenBSD has still not gotten around to implementing it. This is quite a deficiency, as NFSv4 now allows you to authenticate connections with Kerberos, and even encrypt the data transfers. Once again, you would think such a security-focused OS would care about such benefits, but alas, no.

They liberally lift modern design from Linux. They've not been NetBSD for a long time, user. They get very angry when that's pointed out, so point it out a lot.

Nice pasta. Zig Forums needs IDs and mods who ban shills like yourself.

The dlang forum uses sqlite and is incredibly fast. A database server is overkill for 99% of websites but webdevs love to overcomplicate things.

sqlite is not incredibly fast. It literally serializes every write transaction. To stay sane (sqlite has a lock inversion problem by default), devs use IMMEDIATE mode transactions which lock the db for writes from the BEGIN to the COMMIT. The write performance is total ass.
There's no reason to use it over something like PostgreSQL if you can fit PostgreSQL in. sqlite's niche is those places PostgreSQL doesn't fit, like in Android apps, embedded systems, desktop apps, etc.. In something that might need to scale in the future like a website, it would be a huge mistake.

99% of websites just require reads, not writes, so your point is moot.
You just want to shit on something for reasons that don't apply to what is being discussed.

It's no surprise to me that you hang out in toy language communities.

99% of websites aren't forums.

You brought up a fucking forum as your example of 'incredibly fast' you niggermonkey.

I'm not whoever you think I am,

are me.

imo it's just a lack of understanding of the tech and why it's unsafe and doesn't scale.
Example: with sqlite, it mmaps the database so any errant pointer can potentially completely destroy your data on disk. It tries to protect this with an 80% solution of mprotecting all the pages then unprotecting the ones it's working on as needed (this is why it's so heavy on syscalls). That only lessens the odds of losing everything, it's not a fix. If you're using it in a language that isn't bounds checked, as is usually the case with stand-alone apps using libsqlite, and you haven't built a message-passing system to execute queries in a separate process and serialize the result back to the caller (I feel like I'm the only person to have ever done this), you're playing with fire.
As another example, libsqlite blocks and can't be trivially converted to network-style non-blocking like libpq as it's filesystem-based. If you're writing something that needs to be responsive and not choke when the disk is being used by something else, you have to build the message passing system I mentioned above along with your own system of futures. The only libraries for this I know of are from webdevs in webdev languages, you'll have to write your own for standalone apps using libsqlite. Note that asyncvfs is not a solution, if you don't know why, read about it until you do.
It's deeply into mistake territory to use it when you could have used PostgreSQL.

Ah, so you're retarded.

Defend vmd. Tell me lies about how you'd use it for real servers. And are they still unable to use OpenCL/CUDA? It's pretty funny that a "security focused" OS can't even run hashcat. It must hurt their butts that they need a Linux box to verify user password strengths. They probably just don't bother..
It barely works even on a regular x86 desktop as it has so few drivers. See above.
Oh it's totally not a clone as sosplice() is different than splice(). And vmd is different than KVM. And O_CLOEXEC is different than O_CLOEXEC (b-but that was later standardized by POSIX so it's ok). And virtio is different than virtio (b-but that was later standardized by OASIS so it's ok). And QoS is totally different and algorithms like CoDel weren't copied from Linux many years later.
They're innovators in the OS space and in no way owe all modern features to copying from Linux. I'm sure when they get around to cloning ebtables it will be the most innovative clone yet.