Also, you surely couldn't be using OpenBSD for performance-critical applications; I love OpenBSD, but it's incredibly slow, which makes it a complete nonstarter for most applications in that space.
Also, you surely couldn't be using OpenBSD for performance-critical applications; I love OpenBSD, but it's incredibly slow, which makes it a complete nonstarter for most applications in that space.
One of the reasons I know it is slower is due to security.
With the security mitigations OpenBSD chose to simply disable SMT. It is a less performant, but much simpler solution than the software mitigations that Linux and Windows implement.
https://www.phoronix.com/scan.php?page=news_item&px=OpenBSD-...
Do you know of any other reasons?
One famous case: About 15 years ago, someone made a patchset called HPN-SSH [1] for OpenSSH because:
> SSH implements a multiplexed connection protocol so a single TCP/IP connection can host multiple SSH sessions at the same time. This means that SSH also has to implement a flow control mechanism in order to make sure that the network connection isn't overwhelmed. Much like TCP/IP, it uses a receive buffer to indicate how much data the sender should be sending at any one point. The developers of OpenSSH had initially set this buffer size to 64KiloBytes.
This capped scp/sftp bandwidth on a 10ms link to about 50Mbps. At that time no OpenBSD developers would like to work on this because... they don't have >10Mbps NICs (or link? I don't remember) so they never feel the problem.
Of course the thing eventually got fixed, but much later.
Do not accept code that you know you won't be able to maintain or test.
And it's fast enough to do batch processing of serial transactions as well as serving a web app and networking
In my experience I think the biggest bottleneck that I've found is filesystem performance. FFS (Fast File System) is pretty freakin slow, and you should really consider redundancy options in case one of the drives fails because its tolerance for recovery from failure isn't the best. It definitely isn't the most optimal or sometimes even viable solution for when you need performance on the filesystem to be high.
Given these things though chances are a lot lower that someone finds something filesystem-level which constitutes a way to hide malicious code or whatever (For example NTFS and hiding malware in Alternative Data Streams [1] or messing around with timestamps [2], or local privilege escalation in Linux's filesystem layer being a big vector for attack lately [3] - Hell even WSL mounting /mnt/c/ as chmod 777 which can wreck some real havok in something as basic as a few lines of python or ruby like stealing your browser session cookies [4] or just wrecking your windows install by deleting system32 like a bad prank from a decade ago [5])
[1] https://www.youtube.com/watch?v=S4MBzeni9Eo
[2] https://www.sciencedirect.com/science/article/pii/S266628172...
[3] https://blog.qualys.com/vulnerabilities-threat-research/2021...
[4] https://blog.lumen.com/windows-subsystem-for-linux-wsl-threa...
[5] https://memegenerator.net/img/instances/82246172/delete-syst...