[caslon]

Is it really "large sums of cash," when Microsoft's donating under $50k, Facebook's donating less than $100k, and the grand total is under $600k? That's maybe a single senior developer at one of the three companies you cited, and far less than any of those companies are spending on the GPL-licensed GNU/Linux during a given year.

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.

[csdreamer7]

Good point. Microsoft probably spends a lot more than 600K on Linux kernel developers alone to implement several of their features including Hyper-V.

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?

[rfoo]

OpenBSD developers do not need high performance, so naturally OpenBSD and its components are usually just not optimized for performance.

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.

[1] https://www.psc.edu/hpn-ssh-home/hpn-ssh-faq/

[gjadi]

It makes sense, doesn't it?

Do not accept code that you know you won't be able to maintain or test.

[rfoo]

Yeah, it totally makes sense. It just shows that people are not paranoid enough to give up their usual performant OS and invest in OpenBSD :)

[jamal-kumar]

It's enough to keep their developers working, it seems.

And it's fast enough to do batch processing of serial transactions as well as serving a web app and networking

[mattzito]

I'm 99% sure that google supports openbsd because that also includes libressl, openbgp, and other solutions in addition to openbsd - it's a "generally good for the internet" scenario.

[Teever]

Maybe so, but the bigger question is whether or not the financial contributions that these behemoth companies make matches the value that they receive.

[5e92cb50239222b]

At least they give something back. As another example, Sony took FreeBSD, added some proprietary bits on top (like their own graphical API), turning it into the PlayStation operating system family. They've made billions of dollars on that (saving countless millions by not having to develop an OS from scratch), and gave bupkis in return. Try finding them in any of donors lists. Last time I mentioned that I was downvoted to hell because apparently it's wrong to ask giant corporations to support the foundation they're building on top of, and I'm a communist for doing that.

https://freebsdfoundation.org/our-donors/

[brigandish]

Perhaps it should reflect the value they receive, they're there to make a profit. It might be better to ask whether they would receive even greater value if they put in more, and I believe they would, but perhaps they've done the maths and think differently.

[midislack]

Incredibly slow? It benchmarks a mere 2-3% behind Linux with Unixbench.

[jamal-kumar]

Hi OP here

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