4 ms·

And FreeBSD apparently started in 2001: http://mm.icann.org/pipermail/tz/2004-June/012487.html http://mm.icann.org/pipermail/tz/2004-June/012487.html While it

by ivoras 11y ago

And FreeBSD apparently started in 2001: http://mm.icann.org/pipermail/tz/2004-June/012487.html http://mm.icann.org/pipermail/tz/2004-June/012487.html While it did advance the state of the art in many things, Linux really clings to reinventing the wheel in obvious cases. NIH FTW.

justincormack 11y ago
That was on 64 bit systems; those all switched a long time ago, despite the author of that thread disliking it...
abadabalinux4u 11y ago
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.
- duaneb 11y ago
  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.
noselasd 11y ago
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.
the_why_of_y 11y ago
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.h?view=markup#l115 https://svnweb.freebsd.org/base/head/sys/x86/include/_types....

by ivoras 11y ago

justincormack 11y ago

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

abadabalinux4u 11y ago

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.

duaneb 11y ago
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.

noselasd 11y ago

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.

the_why_of_y 11y ago

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.h?view=markup#l115 https://svnweb.freebsd.org/base/head/sys/x86/include/_types....