4 ms·

> Improve linuxolator, and run Linux tests on linuxolator as part of FreeBSD CI. This is the worst thing they could actually do because people will just run th

> Improve linuxolator, and run Linux tests on linuxolator as part of FreeBSD CI. This is the worst thing they could actually do because people will just run the Linux versions and there would be even less demand for anyone to bother with a FreeBSD version.

im_down_w_otp 7y ago
That was my thought as well. Thinking back to OS/2 Warp's similar approach. Unless FreeBSD has really, really strong differentiating capabilities that are in super high demand _already_, and insufficient Linux interop is a switching impediment, then focusing on Linux interop with otherwise low differentiation/demand seems likely to further lower FreeBSD differentiation & demand. Were I them, I'd pick a couple really strong niches to try to dominate for a little while to drastically differentiate. Maybe in SDN or SSI clustering or something. Create the absolute best platform in that regard while still having familiar tools available for general purpose use cases... and _then_ work to trivialize the on-ramp to FreeBSD from Linux et. al. FreeBSD needs to find some way to be a part of the meme, "Nobody ever got fired for going with..."
stingraycharles 7y ago
Not necessarily. It can also actually increase adoption because it fixes friction: there might always be a few tools or docker containers or whatnot which are not ported to BSD, and this provides an answer to that. Microsoft has the “embrace, extend, extinguish” mantra for a similar reason.
- uncle_j 7y ago
  > Not necessarily. It can also actually increase adoption because it fixes friction: there might always be a few tools or docker containers or whatnot which are not ported to BSD, and this provides an answer to that. It tells developers that users will put up with the compatibility layer. Also setting up these compatibility layers has its own set of complications e.g. random things not working, sub-optimal performance etc. The only people that have pulled it off has been Microsoft with WSL and there has been problems with that. I for a laugh setup basically a Xubuntu desktop and I had lots of odd errors being reported in the console.
- emaste 7y ago
  Exactly this. I use FreeBSD exclusively for my development, but there are a few pieces of proprietary software that are only available as Linux binaries (like FPGA toolchains), and having a viable Linux ABI layer means that I do not need to resort to having an entire second operating system in a VM or another machine.
magic_quotes 7y ago
> people will just run the Linux version Don't worry, there are more than enough stumbling blocks in Linux emulation to ensure it would never be as convenient as native applications. For example, if you pass LD_LIBRARY_PATH with FreeBSD libraries to the Linux program it will predictably blow up in your face. Now, imagine running a shell script which calls FreeBSD and Linux executables. Linuxulator is really a method of last resort and it always requires special care for each individual application.
- trasz 7y ago
  This one is trivially solved using jail or chroot. Otherwise, there’s the path translation mechanism (/compat/linux) specifically for this purpose.
  - magic_quotes 7y ago
    Nah, not quite the same. Jail makes it easy to avoid calling FreeBSD binaries from the Linux process by accident. If you must mix-and-match commands, jail is exactly of zero help.
asveikau 7y ago
I personally find the Linux support "good enough", and it's one reason I choose FreeBSD over OpenBSD on a few machines. OBSD is great, they got rid of Linux emulation for reasons I understand entirely, but it is on the other hand very handy to run the occasional Linux binary, mostly for a handful of closed source stuff that is never going to port to *BSD.
- 3xblah 7y ago
  If I am not mistaken, I think NetBSD was the first to add Linux binary compatibilty. It is certainly useful. It is easy to exclude when compiling the kernel if it is not needed. I have used /emul/linux for running closed source Linux binaries.
toast0 7y ago
> This is the worst thing they could actually do because people will just run the Linux versions and there would be even less demand for anyone to bother with a FreeBSD version. The alternative is that people will just run the Linux version on Linux. From my perspective, Linuxolator's job is to let me run commercial software that is released for Linux and unlikely to be released for FreeBSD; for example, whatever JNI garbage SuperMicro needed for their Java KVM; I had to keep an old Java 7 JRE around for that because they wouldn't update to fit into the security model of Java 8, so they're really unlikely to build for FreeBSD, especially in a competent way. Of course, if I had a choice, I would use a native build / something with at least source available, so I could build it natively; but if it's a sometimes run utility, I'm ok with something terribly hacky.

im_down_w_otp 7y ago

That was my thought as well. Thinking back to OS/2 Warp's similar approach. Unless FreeBSD has really, really strong differentiating capabilities that are in super high demand _already_, and insufficient Linux interop is a switching impediment, then focusing on Linux interop with otherwise low differentiation/demand seems likely to further lower FreeBSD differentiation & demand. Were I them, I'd pick a couple really strong niches to try to dominate for a little while to drastically differentiate. Maybe in SDN or SSI clustering or something. Create the absolute best platform in that regard while still having familiar tools available for general purpose use cases... and _then_ work to trivialize the on-ramp to FreeBSD from Linux et. al. FreeBSD needs to find some way to be a part of the meme, "Nobody ever got fired for going with..."

stingraycharles 7y ago

Not necessarily. It can also actually increase adoption because it fixes friction: there might always be a few tools or docker containers or whatnot which are not ported to BSD, and this provides an answer to that. Microsoft has the “embrace, extend, extinguish” mantra for a similar reason.

uncle_j 7y ago
> Not necessarily. It can also actually increase adoption because it fixes friction: there might always be a few tools or docker containers or whatnot which are not ported to BSD, and this provides an answer to that. It tells developers that users will put up with the compatibility layer. Also setting up these compatibility layers has its own set of complications e.g. random things not working, sub-optimal performance etc. The only people that have pulled it off has been Microsoft with WSL and there has been problems with that. I for a laugh setup basically a Xubuntu desktop and I had lots of odd errors being reported in the console.
emaste 7y ago
Exactly this. I use FreeBSD exclusively for my development, but there are a few pieces of proprietary software that are only available as Linux binaries (like FPGA toolchains), and having a viable Linux ABI layer means that I do not need to resort to having an entire second operating system in a VM or another machine.

magic_quotes 7y ago

> people will just run the Linux version Don't worry, there are more than enough stumbling blocks in Linux emulation to ensure it would never be as convenient as native applications. For example, if you pass LD_LIBRARY_PATH with FreeBSD libraries to the Linux program it will predictably blow up in your face. Now, imagine running a shell script which calls FreeBSD and Linux executables. Linuxulator is really a method of last resort and it always requires special care for each individual application.

trasz 7y ago
This one is trivially solved using jail or chroot. Otherwise, there’s the path translation mechanism (/compat/linux) specifically for this purpose.
- magic_quotes 7y ago
  Nah, not quite the same. Jail makes it easy to avoid calling FreeBSD binaries from the Linux process by accident. If you must mix-and-match commands, jail is exactly of zero help.

asveikau 7y ago

I personally find the Linux support "good enough", and it's one reason I choose FreeBSD over OpenBSD on a few machines. OBSD is great, they got rid of Linux emulation for reasons I understand entirely, but it is on the other hand very handy to run the occasional Linux binary, mostly for a handful of closed source stuff that is never going to port to *BSD.

3xblah 7y ago
If I am not mistaken, I think NetBSD was the first to add Linux binary compatibilty. It is certainly useful. It is easy to exclude when compiling the kernel if it is not needed. I have used /emul/linux for running closed source Linux binaries.

toast0 7y ago

> This is the worst thing they could actually do because people will just run the Linux versions and there would be even less demand for anyone to bother with a FreeBSD version. The alternative is that people will just run the Linux version on Linux. From my perspective, Linuxolator's job is to let me run commercial software that is released for Linux and unlikely to be released for FreeBSD; for example, whatever JNI garbage SuperMicro needed for their Java KVM; I had to keep an old Java 7 JRE around for that because they wouldn't update to fit into the security model of Java 8, so they're really unlikely to build for FreeBSD, especially in a competent way. Of course, if I had a choice, I would use a native build / something with at least source available, so I could build it natively; but if it's a sometimes run utility, I'm ok with something terribly hacky.