[farhaven]

OpenBSD is a lot faster in some specialized areas though. Random number generation from `/dev/urandom`, for example. When I was at university (in 2010 or so), it was faster to read `/dev/urandom` on my OpenBSD laptop and pipe it over ethernet to a friend's Linux laptop than running `cat /dev/urandom > /dev/sda` directly on his.

Not by just a bit, but it was a difference between 10MB/s and 100MB/s.

[sillystuff]

I think you meant to say /dev/random, not /dev/urandom.

/dev/random, on linux used to stall waiting for entropy from sources of randomness like network jitter, mouse movement, keyboard typing. /dev/urandom has always been fast on Linux.

Today, linux /dev/random mainly uses an RNG after initial seeding. The BSDs always did this. On my laptop, I get over 500MB/s (kernel 6.12) .

IIRC, on modern linux kernels, /dev/urandom is now just an alias to /dev/random for backward compatibility.

[tptacek]

There's no reason for normal userland code not part of the distribution itself ever to use /dev/random, and getrandom(2) with GRND_RANDOM unset is probably the right answer for everything.

Both Linux and BSD use a CSPRNG to satisfy /dev/{urandom,random} and getrandom, and, for future-secrecy/compromise-protection continually update their entropy pools with hashed high-entropy events (there's ~essentially no practical cryptographic reason a "seeded" CSPRNG ever needs to be rekeyed, but there are practical systems security reasons to do it).

[sgarland]

OpenBSD switched their PRNG to arc4random in 2012 (and then ChaCha20 in 2014); depending on how accurate your time estimate is, that could well have been the cause. Linux switched to ChaCha20 in 2016.

Related, I stumbled down a rabbit hole of PRNGs last year when I discovered [0] that my Mac was way faster at generating UUIDs than my Linux server, even taking architecture and clock speed into account. Turns out glibc didn’t get arc4random until 2.36, and the version of Debian I had at the time didn’t have 2.36. In contrast, since MacOS is BSD-based, it’s had it for quite some time.

[0]: https://gist.github.com/stephanGarland/f6b7a13585c0caf9eb64b...

[somat]

At one point probably 10 years ago I had linux vm guests refuse to generate gpg keys, gpg insisted it needed the stupid blocking random device, and because the vm guest was not getting any "entropy" the process went nowhere. As an openbsd user naturally I was disgusted, there are many sane solutions to this problem, but I used none of them. Instead I found rngd a service to accept "entropy" from a network source and blasted it with the /dev/random from a fresh obsd guest on the same vm host. Mainly out of spite. "look here you little shit, this is how you generate random numbers"

[craftkiller]

Qemu added support for VirtIO RNG in 2012 [0] so depending on how accurate that 10 year figure is, you also could have used that to make your VM able to use the host system's entropy.

[0] https://wiki.qemu.org/Features/VirtIORNG

[cogman10]

/dev/urandom isn't a great test, IMO, simply because there are reasonable tradeoffs in security v speed.

For all I know BSD could be doing 31*last or something similar.

The algorithm is also free to change.

[chowells]

Um... This conversation is about OpenBSD, making that objection incredibly funny. OpenBSD has a mostly-deserved reputation for doing the correct security thing first, in all cases.

But that's also why the rng stuff was so much faster. There was a long period of time where the Linux dev in charge of randomness believed a lot of voodoo instead of actual security practices, and chose nonsense slow systems instead of well-researched fast ones. Linux has finally moved into the modern era, but there was a long period where the randomness features were far inferior to systems built by people with a security background.

[tptacek]

OpenBSD isn't meaningfully more secure than Linux. It probably was 20 years ago. Today it's more accurate to say that Linux and OpenBSD have pursued different security strategies --- there are meaningful differences, but they aren't on a simple one-dimensional spectrum of "good" to "bad".

(I was involved, somewhat peripherally, in OpenBSD security during the era of the big OpenBSD Security Audit).

[sugarpimpdorsey]

Haven't they had some embarrassing RCEs in the not too distant past? It kind of calls into question the significance of that claim about holes "in the default install" - even Windows ships without any services exposed these days.

Ultimately, they suffer from a lack of developer resources.

Which is a shame because it's a wonderfully integrated system (as opposed to the tattered quilt that is every Linux distro). But I suspect it's the project leadership that keeps more people away.

[user3939382]

I’ve found the OpenBSD community to have a bad/snobbish attitude which could just be a coincidence, no idea. I’ve always liked NetBSD which I never had that problem with.

[extraisland]

My experience is that they expect you to read the docs and ask smart questions. Most of everything is in the documentations, READMEs etc.

[kaskjdhaas]

I remember a discussion with an OpenBSD developer whose answer to the lack of a journaling file system was to simply have a UPS, like any normal computer user should have (there are hobby operating systems with journaling FS, but due to the antique development model, OpenBSD developers can't do significant work like a new file system).