There's a lot to admire in OpenBSD but sometimes the peripheral tools they deliver don't work well. The example I know best is OpenNTPD (last link in your comment). It has a bunch of problems, including relatively poor clock discipline compared to other NTP implementations. And it doesn't even try to handle leap seconds. That causes problems on the machine itself which may or may not matter to you, but it's catastrophic if that OpenNTPD serves time to other servers. Unfortunately there's a bunch of OpenNTPD servers in the NTP Pool actively providing bad time. Some details from the 2016 leap second: https://community.ntppool.org/t/leap-second-2017-status/59/1...

Again I mostly admire OpenBSD. But OpenNTPD is not the best example of their work.

Have you had a chance to look at systemd-timesyncd? I'm curious how it stacks up as a NTP client. Was thinking about switching my systems to it (from chrony) as I don't need the NTP server functionality.

This is seriously bad, but I do get why they thought OpenNTPd was necessary (bad/perfectible code in the other implementations).

Maybe I'll check that at home (where I replaced FreeBSD's ntpd with OpenNTPd).

Yeah the stock old ntpd had a lot of unused code and various security problems over the years. It makes sense OpenBSD would replace it. Just a shame they didn't do it completely. I think that describes a lot of OpenBSD tools; you're trading off some functionality for very good security.

There are better NTP implementations now. Chrony is great, it's the default in Ubuntu now. NTPsec is coming along although I haven't tried to use it myself. Also good ol' ntpd is greatly improved.

https://chrony.tuxfamily.org/ https://www.ntpsec.org/

Just wanted to +1 this.

Once had to make some changes to OpenSSH for an internal project and it was surprisingly easy to find the relevant code and make the necessary changes. One of the few times my code worked on the first compile.

Meh. Given the recent Spectre, Meltdown, etc. maybe we shouldn't focus on performance first, but security.

https://www.openbsd.org/faq/pf/perf.html

https://www.openbsd.org/crypto.html

https://www.openbsd.org/security.html

OpenBSD's niche is security -- that's the point.

How is performance related to code quality. That makes no sense. If anything, if you had to inline ASM for example, the code would suffer from readability.

using comma seperated string splitting options over normal bits or'ed together in their public API looses all credibility in their engineering abilities. it would not survive any professional code review.

Shouldn’t good performance be one of the goals of good code?

Depends on the design goals. If you want secure code, you'll make it readable. Here's true(1):

  :

A single "noop" in a 755 file.

A C true would be: https://cvsweb.openbsd.org/src/usr.bin/true/true.c?rev=1.1&c...

Here's a much faster true(1) if you need it: https://github.com/coreutils/coreutils/blob/master/src/true....

Is the gnu-coreutils true much faster? I have a hard time seeing how return 0 can be so slow.

I did say “one of the goals”.

I don’t see how those examples are relevant. Why would that last one be faster?

I agree that the OpenBSD code here is good, no more and no less than needed.

I assumed the grandparent was referring to cases where an O(n) algorithm is used where it might be O(log n) or O(1) with just a little more effort. It’s a tradeoff, sure, and in some cases linear searches can work surprisingly well, but in general I think this kind of thing should always be considered in good code.

Micro-optimizations like inline assembly for inner loops may or may not be a good idea, depending on the application. All else being equal, I’d certainly agree that good clean code would not use assembly.

How is the coreutils true faster?

I would expect the openbsd true to be the fastest, it doesn't need to spawn a subshell and it doesn't do more than the posix specification requires (afaik --help/--version should be ignored).

What are you comparing against what there? Two C executables with the same compiler flags on the same OS?