>The Linux® compatibility layer has been substantially improved and now is capable of running 64-bit applications on amd64 (x86_64), 1:1 threading

What does 1:1 threading mean?

There are at least three theoretical implementations of userland threads in an Operating System:

* 1:1, where each userland thread maps directly to a kernel thread

* 1:N, where several userland threads map directly to one kernel thread

* M:N, where the kernel maintains a pool of threads and dispatches userland threads to them

History has shown that 1:1 threading has the best trade offs. It's worth more independent research if you are interested in Operating Systems.

Thanks

Or just re-use of basic structures ;)

https://en.wikipedia.org/wiki/Thread_%28computing%29#1:1_.28...: 1:1 (kernel-level threading)

Threads created by the user in a 1:1 correspondence with schedulable entities in the kernel[10] are the simplest possible threading implementation. OS/2 and Win32 used this approach from the start, while on Linux the usual C library implements this approach (via the NPTL or older LinuxThreads). This approach is also used by Solaris, NetBSD, FreeBSD, OS X, and iOS.

It's also worth noting that FreeBSD used to rely on M:N threading model (via libkse) then switched to 1:1 threading model (via libthr).

Though LinuxThreads was M:N, and Solaris migrated to 1:1 relatively recently too (as did others).

No, LinuxThreads was 1:1. Maybe you are thinking of IBM's NGPT proposal?

http://www.onlamp.com/pub/a/onlamp/2002/11/07/linux_threads....

"Relatively recently" would be Solaris 8, in 2000.

FreeBSD has supported Linux compatibility for many years and, purportedly, can run some Linux applications faster than Linux itself so FreeBSD has always been miles ahead.

In FreeBSD 6 I could get more fps in America's Army FPS game through Linuxulator on FreeBSD than through running native Linux.

Slightly pedantic, but FreeBSD/alpha ran 64-bit Linux alpha binaries back in 2000/2001 , and 64-bit DEC OSF/1 / Tru64 binaries much earlier.

I think we probably should have ripped the bandaid off, and started supporting 64-bit Linux binaries much earlier on FreeBSD/amd64

Except this is not keeping one step ahead. Windows does run 64-bit Linux binaries natively, watch https://channel9.msdn.com/Events/Build/2016/P488 (skip to 05:12).

So, Windows is catching up to parity. shrug

I don't think Windows had anything to do with this. I think the feature has been in development since before and it is released because it's what users want, not because of what Microsoft are doing.

Initial Linux64 support landed in FreeBSD11 on 2015-05-24. The code freeze for the 10.2 release started on 2015-07-03.

Those 5'ish weeks was simply not enough time to get such a major addition sufficiently settled down for inclusion in the stable release branch. As such, it is now part of 10.3R.

Wow! Thanks for pointing this out! I had no idea it was coming so soon. I'm so excited to upgrade. This is particularly useful for some niche compilers (like Poly/ML) who have special features for only linux-x86_64.

What are those special features?

Actually, I may have gotten my facts mixed up. It is Golang that only supports some compiling features on linux-x86 like shared object libraries or something along those lines. I can't remember off the top of my head and I can't seem to find what I'm looking for.

What are the limitations of the Linux compability layer?

Going by the compat.linux.osrelease sysctl, it is currently providing the kernel interface of Linux kernel version 2.6.32 (the one that ships with RHEL6). Similarly, the GNU userland that can be installed is based on CentOS6.

So, if your application requires newer kernel interfaces that were introduced in 3.x or 4.x, it will not work.