Comment Re:Is there any real uses for it? (Score 1) 107
The FreeBSD kernel is damn stable and many who's gotten into it prefer managing servers since it's usually fairly stable as a base OS.
Web-servers has historically been an easier propsition on it also (fast sendfile support).
The biggest issue is usually developers on Linux having a "works on my machine" mentality so much software requires a bit of porting effort due
to different headers and some minor differences in syscall/signal behaviours. (90% of the time you can add an #ifdef __FREEBSD__ or similar for like 5 lines of code out of millions).
Two things have made it worse in recent years though:
1: Docker itself required a fair bit of special Linux-isms that went way beyond what FreeBSD's API-compatibility layer could manage.
There was 2-3 attempts at a more "native" FreeBSD experience, but they didn't pan out or mature enough due to the above.
The way forward though seems to be the Podman project that seems better architected with less Linux-isms and the bhyve VM
(similar to the osX Xhyve port) running a core VM that Podman can fork containers out off.
2: Faster virtual machines (JIT compiled), while the core ABI iirc is the same there are some small differences in memory mapping,etc
that seems to trip up VM's sometimes and without FreeBSD specific maintainers it's support is often left behind.
Even then some package systems contain binaries that are often Linux only (This is an issue with .NET Core for example),
Dotnet Core now runs on FreeBSD but since the NuGet system includes precompiled binaries it can still be an issue.
Conversely, node/npm that works from source is sometimes better but instead runs into issues where people's native modules fail at compiling.
I'm still hanging on to FreeBSD as much as possible, but for some scenarios I'm considering Linux (or Podman maturing).
Web-servers has historically been an easier propsition on it also (fast sendfile support).
The biggest issue is usually developers on Linux having a "works on my machine" mentality so much software requires a bit of porting effort due
to different headers and some minor differences in syscall/signal behaviours. (90% of the time you can add an #ifdef __FREEBSD__ or similar for like 5 lines of code out of millions).
Two things have made it worse in recent years though:
1: Docker itself required a fair bit of special Linux-isms that went way beyond what FreeBSD's API-compatibility layer could manage.
There was 2-3 attempts at a more "native" FreeBSD experience, but they didn't pan out or mature enough due to the above.
The way forward though seems to be the Podman project that seems better architected with less Linux-isms and the bhyve VM
(similar to the osX Xhyve port) running a core VM that Podman can fork containers out off.
2: Faster virtual machines (JIT compiled), while the core ABI iirc is the same there are some small differences in memory mapping,etc
that seems to trip up VM's sometimes and without FreeBSD specific maintainers it's support is often left behind.
Even then some package systems contain binaries that are often Linux only (This is an issue with
Dotnet Core now runs on FreeBSD but since the NuGet system includes precompiled binaries it can still be an issue.
Conversely, node/npm that works from source is sometimes better but instead runs into issues where people's native modules fail at compiling.
I'm still hanging on to FreeBSD as much as possible, but for some scenarios I'm considering Linux (or Podman maturing).