Return to Answer

Market forces.

There are many more programs targeted specifically at Linux than at *BSD. A lot of software source code is portable enough that it can be compiled on both, but many software producers that ship Linux binaries do not bother to do so for the BSDs since they have smaller market shares than Linux, across the board.¹

If a piece of software is only available in binary form for a different OS, ABI emulation is one way to make it run, which is what the BSDs do.²

Once upon a time, when x86 Unix held a market majority over Linux, the iBCS feature was added to Linux to allow it to run binaries built for SCO Unix and such. Interest in this feature declined as Linux's market share increased, so that it was allowed to fall into disrepair during the Linux 2.3 development series.³ The SCO lawsuits helped usher this feature out of Linux, but I believe that's secondary to the loss of the market force that birthed the feature.

There's no technical reason why Linux couldn't some day get an iBCS-like feature for running BSD binaries, but it's not likely unless the market positions of BSD and Linux switch for some reason.

Today, there is little call for such a thing. How many binary-only programs for BSD are you aware of, which aren't also built for Linux? There must be some, but I'd guess most of them are for embedded BSDs, such as Junos. Such a feature won't be created if it doesn't allow an important set of programs to run on Linux that wouldn't otherwise run.⁴

Footnotes:

1. I'm not counting OS X as a BSD here, since that's a separate binary compatibility problem. FreeBSD, OpenBSD and NetBSD use ELF on x86, whereas OS X uses an entirely different executable format. Dynamic linkage is also vastly different on OS X than on the traditional x86 BSDs.

See this question for more on the Linux ⇔ OS X binary compatibility story.

2. FreeBSD; OpenBSD; NetBSD

3. As with certain species of shark, software that stops moving forward dies. We call this phenomenon bit-rot rather than asphyxiation when it happens to software, but the cause and effect are the same.

4. Contrast NDISwrapper, which allows Linux to run binary-only network card drivers written for Windows XP. A need is identified, and a need is filled. Where is this need to run BSD-only binaries?

Market forces.

There are many more programs targeted specifically at Linux than at *BSD. A lot of software source code is portable enough that it can be compiled on both, but many software producers that ship Linux binaries do not bother to do so for the BSDs since they have smaller market shares than Linux, across the board.¹

If a piece of software is only available in binary form for a different OS, ABI emulation is one way to make it run, which is what the BSDs do.²

Once upon a time, when x86 Unix held a market majority over Linux, the iBCS feature was added to Linux to allow it to run binaries built for SCO Unix and such. Interest in this feature declined as Linux's market share increased, so that it was allowed to fall into disrepair during the Linux 2.3 development series.³ The SCO lawsuits helped usher this feature out of Linux, but I believe that's secondary to the loss of the market force that birthed the feature.

There's no technical reason why Linux couldn't some day get an iBCS-like feature for running BSD binaries, but it's not likely unless the market positions of BSD and Linux switch for some reason.

Today, there is little call for such a thing. How many binary-only programs for BSD are you aware of, which aren't also built for Linux? There must be some, but I'd guess most of them are for embedded BSDs, such as Junos. Such a feature won't be created if it doesn't allow an important set of programs to run on Linux that wouldn't otherwise run.⁴

Footnotes:

1. I'm not counting OS X as a BSD here, since that's a separate binary compatibility problem. FreeBSD, OpenBSD and NetBSD use ELF on x86, whereas OS X uses an entirely different executable format. Dynamic linkage is also vastly different on OS X than on the traditional x86 BSDs.

   See this question for more on the Linux ⇔ OS X binary compatibility story.

2. FreeBSD; OpenBSD; NetBSD

3. As with certain species of shark, software that stops moving forward dies. We call this phenomenon bit-rot rather than asphyxiation when it happens to software, but the cause and effect are the same.

4. Contrast NDISwrapper, which allows Linux to run binary-only network card drivers written for Windows XP. A need is identified, and a need is filled. Where is this need to run BSD-only binaries?

Market forces.

There are many more programs targeted specifically at Linux than at *BSD. A lot of software source code is portable enough that it can be compiled on both, but many software producers that ship Linux binaries do not bother to do so for the BSDs since they have smaller market shares than Linux, across the board.¹

If a piece of software is only available in binary form for a different OS, ABI emulation is one way to make it run, which is what the BSDs do.²

Once upon a time, when x86 Unix held a market majority over Linux, the iBCS feature was added to Linux to allow it to run binaries built for SCO Unix and such. Interest in this feature declined as Linux's market share increased, so that it was allowed to fall into disrepair during the Linux 2.3 development series.³ The SCO lawsuits helped usher this feature out of Linux, but I believe that's secondary to the loss of the market force that birthed the feature.

There's no technical reason why Linux couldn't some day get an iBCS-like feature for running BSD binaries, but it's not likely unless the market positions of BSD and Linux switch for some reason.

Today, there is little call for such a thing. How many binary-only programs for BSD are you aware of, which aren't also built for Linux? There must be some, but I'd guess most of them are for embedded BSDs, such as Junos. Such a feature won't be created if it doesn't allow an important set of programs to run on Linux that wouldn't otherwise run.⁴

Footnotes:

1. I'm not counting OS X as a BSD here, since that's a separate binary compatibility problem. FreeBSD, OpenBSD and NetBSD use ELF on x86, whereas OS X uses an entirely different executable format. Dynamic linkage is also vastly different on OS X than on the traditional x86 BSDs.

See this question for more on the Linux ⇔ OS X binary compatibility story.

2. FreeBSD; OpenBSD; NetBSD

3. As with certain species of shark, software that stops moving forward dies. We call this phenomenon bit-rot rather than asphyxiation when it happens to software, but the cause and effect are the same.

4. Contrast NDISwrapper, which allows Linux to run binary-only network card drivers written for Windows XP. A need is identified, and a need is filled. Where is this need to run BSD-only binaries?

Market forces.

There are many more programs targeted specifically at Linux than at *BSD. A lot of software source code is portable enough that it can be compiled on both, but many software producers that ship Linux binaries do not bother to do so for the BSDs since they have smaller market shares than Linux, across the board.¹

If a piece of software is only available in binary form for a different OS, ABI emulation is one way to make it run, which is what the BSDs do.²

Once upon a time, when x86 Unix held a market majority over Linux, the iBCS feature was added to Linux to allow it to run binaries built for SCO Unix and such. Interest in this feature declined as Linux's market share increased, so that it was allowed to fall into disrepair during the Linux 2.3 development series.³ The SCO lawsuits helped usher this feature out of Linux, but I believe that's secondary to the loss of the market force that birthed the feature.

There's no technical reason why Linux couldn't some day get an iBCS-like feature for running BSD binaries, but it's not likely unless the market positions of BSD and Linux switch for some reason.

Today, there is little call for such a thing. How many binary-only programs for BSD are you aware of, which aren't also built for Linux? There must be some, but I'd guess most of them are for embedded BSDs, such as Junos. Such a feature won't be created if it doesn't allow an important set of programs to run on Linux that wouldn't otherwise run.⁴

Footnotes:

1. I'm not counting OS X as a BSD here, since that's a separate binary compatibility problem. FreeBSD, OpenBSD and NetBSD use ELF on x86, whereas OS X uses an entirely different executable format. Dynamic linkage is also vastly different on OS X than on the traditional x86 BSDs.

See this question for more on the Linux ⇔ OS X binary compatibility story.

2. FreeBSD; OpenBSD; NetBSD

3. As with certain species of shark, software that stops moving forward dies. We call this phenomenon bit-rot rather than asphyxiation when it happens to software, but the cause and effect are the same.

4. Contrast NDISwrapper, which allows Linux to run binary-only network card drivers written for Windows XP. A need is identified, and a need is filled. Where is this need to run BSD-only binaries?

Market forces.

There are many more programs targeted specifically at Linux than at *BSD. A lot of software source code is portable enough that it can be compiled on both, but many software producers that ship Linux binaries do not bother to do so for the BSDs since they have smaller market shares than Linux, across the board.¹

If a piece of software is only available in binary form for a different OS, ABI emulation is one way to make it run, which is what the BSDs do.²

The reverse case simply doesn't happen enough to make it worthwhile to add such an executable ABI compatibility layer to Linux.

Once upon a time, when x86 Unix held a market majority over Linux, Linux had the iBCS layer, which allowed it to run binaries built for SCO Unix and such. Once Linux took over the market, this feature bitrotted, and eventually got taken out; it hasn't been part of Linux since the 2.2 days. The SCO lawsuits helped usher this feature out of Linux.

So, Linux did once have a similar feature, though for a different OS. There's no technical reason it couldn't some day get one for BSD, but it's not likely unless the market positions of BSD and Linux switch for some reason.

Footnotes:

1. I'm not counting OS X as a BSD here, since that's a separate binary compatibility problem. FreeBSD, OpenBSD and NetBSD use ELF on x86, whereas OS X uses an entirely different executable format. Dynamic linkage is also vastly different on OS X than on the traditional x86 BSDs.

See this question for more on the Linux ⇔ OS X binary compatibility story.

2. FreeBSD; OpenBSD; NetBSD

Market forces.

There are many more programs targeted specifically at Linux than at *BSD. A lot of software source code is portable enough that it can be compiled on both, but many software producers that ship Linux binaries do not bother to do so for the BSDs since they have smaller market shares than Linux, across the board.¹

If a piece of software is only available in binary form for a different OS, ABI emulation is one way to make it run, which is what the BSDs do.²

Once upon a time, when x86 Unix held a market majority over Linux, the iBCS feature was added to Linux to allow it to run binaries built for SCO Unix and such. Interest in this feature declined as Linux's market share increased, so that it was allowed to fall into disrepair during the Linux 2.3 development series.³ The SCO lawsuits helped usher this feature out of Linux, but I believe that's secondary to the loss of the market force that birthed the feature.

There's no technical reason why Linux couldn't some day get an iBCS-like feature for running BSD binaries, but it's not likely unless the market positions of BSD and Linux switch for some reason.

Today, there is little call for such a thing. How many binary-only programs for BSD are you aware of, which aren't also built for Linux? There must be some, but I'd guess most of them are for embedded BSDs, such as Junos. Such a feature won't be created if it doesn't allow an important set of programs to run on Linux that wouldn't otherwise run.⁴

Footnotes:

1. I'm not counting OS X as a BSD here, since that's a separate binary compatibility problem. FreeBSD, OpenBSD and NetBSD use ELF on x86, whereas OS X uses an entirely different executable format. Dynamic linkage is also vastly different on OS X than on the traditional x86 BSDs.

See this question for more on the Linux ⇔ OS X binary compatibility story.

2. FreeBSD; OpenBSD; NetBSD

3. As with certain species of shark, software that stops moving forward dies. We call this phenomenon bit-rot rather than asphyxiation when it happens to software, but the cause and effect are the same.

4. Contrast NDISwrapper, which allows Linux to run binary-only network card drivers written for Windows XP. A need is identified, and a need is filled. Where is this need to run BSD-only binaries?