While Linux certainly reinvents the wheel in some cases and NIHism exists everywhere, the syscall interface of an operating system is not the place where one can just lift BSD code and drop it in and expect it to work. This work needs to be done carefully in a Linux-specific way. The "NIH" approach is sort of a requirement.

Linux seems to have a policy of avoiding breaking changes. Nice for maintaining software, but it's not the best quality kernel as a result.

There is a big difference: the *BSD systems have a tightly integrated base system, where kernel and libc are adapted to changes in lockstep, and there is no stable kernel ABI.

FreeBSD ABI stability is not guaranteed between major releases (only between minor releases), while OpenBSD does not even guarantee ABI stability between minor releases.

Linux and GNU libc are separate projects, and there are pretty strong compatibility guarantees for the Linux syscall ABI; the glibc ABI is also stable, and glibc uses ELF symbol versioning to provide older deprecated functions for compatibility.

This means the system is more modular, but at the cost that interface changes like changing 32-bit time_t to 64-bit require a lot more effort and coordination.

Of course the advantage of the Linux approach is that existing application binaries will continue to run, even ones that do syscalls directly or with statically linked libc.

----

Edited to add: actually it turns out you were wrong with your claim about 64-bit time_t in FreeBSD:

Here is the current trunk header where it defines a 32-bit time_t for the i386 architecture.

https://svnweb.freebsd.org/base/head/sys/x86/include/_types....

That was on 64 bit systems; those all switched a long time ago, despite the author of that thread disliking it...

In all fairness, linux does this, on 32 bit platforms where time_t is 32 bit, to be binary backwards compatible, which is a different goal from what the BSDs do/did, which is a rip and replace approach, where you'll need to recompile applications.