Comment by alexhutcheson | Hacker News Reader

Comment by alexhutcheson | Hacker News Reader

Quick summary:

- Port several container and virtualization systems (OpenStack, OpenNebula, oVirt, CloudStack, Kubernetes, Docker, Podman, …) to FreeBSD.

- Improve linuxolator, and run Linux tests on linuxolator as part of FreeBSD CI.

- Make kerberos work.

- Port more SDN software to FreeBSD and improve the documentation for it.

- Add interfaces to hardware sensors (fans, voltage, temperature, etc.)

- Add an implementation of Multipath TCP.

- Make SecureBoot work.

- Support writing kernel modules in C++ or Rust.

- Improve end-user HOWTO docs on how to use specific 3rd party software (mail server, web server, display server, etc.) with FreeBSD.

- Review existing docs and remove outdated information.

- Add a "cloud" section to end-user docs.

- Use doxygen or a similar system to generate additional developer docs from source code.

- Polish and improve DTrace.

- Make default options for ports packages consistent.

- Create "meta-ports" for specific use-cases (webserver, database, etc.)

- Revise default settings to target improved performance on modern machines.

- Add fuzzers and Clang sanitizers to FreeBSD CI.

- Make the CI system more visible.

[I'm not the author, just a guy reading the post. Add a comment if I missed anything important]

> 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.

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..."

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.

> 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.

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.

> 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.

This one is trivially solved using jail or chroot. Otherwise, there’s the path translation mechanism (/compat/linux) specifically for this purpose.

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.

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.

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.

> 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.

Don’t forget vsyscalls.

I didn't see that in the post.

You’re correct. I should’ve replied to a different thread.

In my experience gettimeofday() as a vsyscall is a substantial performance benefit to PHP web applications.

I read the list and added that in thinking it’s relevant to growing the FreeBSD user base.

What about vsyscalls?

Reply on news.ycombinator.com