Modern software development is driven by fashion and trends. All you need is a few tech “influencers” to switch to freebsd then crowds will follow. FreeBSD was and remains my first love, but not being fashionable there is nowhere i can use it.
As someone who would like to switch to FreeBSD but cannot, let me give you a few counterpoints. I also loosely follow actual fashion trends in clothing.
I actually think that FreeBSD is already fashionable. It scaled up WhatsApp and Netflix, two of the most impressive startups! Tarsnap uses it. It seems pretty stable, and I would be perfectly fine adopting it.
Where would I adopt FreeBSD? In two places – on the desktop/laptop, and on the server.
On the desktop/laptop: I need perfect screen resolution on my laptop and external monitor, Bluetooth and Wi-Fi, and a way to correctly use my plugged-in microphone and headphones. Ubuntu delivers all of this with some grumbling, and MacOS and Windows do it flawlessly. What does FreeBSD do? Reports seem to say that Wi-Fi and Bluetooth are problematic.
On the server: I need a compelling way to manage thousands of servers if needed, and something like Ansible won't cut it. For whatever reason, distributed systems on top of FreeBSD seems to be something that the community refuses to build on. I'm not sure what kinds of frameworks WhatsApp and Netflix built to manage their servers, but none of it seems to be public.
So, I kind of disagree; I think FreeBSD is fashionable but fails to be utilitarian enough. Fix the problems on the desktop/laptop; or deliver a way of showing how to scale up quickly with FreeBSD, and you'll get your adoption.
I'm not sure what you've tried that does not work!
What is needed but is sort of missing:
- A way to run containers. I see that *BSD may have had container-like features (e.g. jails) long before Linux containers existed. The truth us that the prevailing format is Linux-style containers. Ideally one should be able to run ready-made containers in Linux compatibility mode. An ability to build a native container from a Dockerfile is as important.
- An orchestration engine based around containers. Ideally a port of a subset of k8s, but smaller tools the class of Nomad or Docker Swarm would be a good start.
- A good replacement for Docker / Podman / Containerd, preferably with a modicum of compatibility / convertibility from those. You want an easy local development environment.
I bet bits and pieces of it sort of kind of exist, and the kernel is capable enough. Now someone should put (quite) some effort in building that for real, releasing under a reasonable open license, and maintaining it for years.
This is to say nothing of (desktop /laptop) hardware compatibility yet.
On the smaller end of the scale, docker-compose is fantastic for managing apps if you only have a few systems.
Insofar as encapsulating a container in a file-like format, the primitives are all there: you can export a ZFS snapshot of your jail to a file. Higher level tooling is there as well: iocage has an export subcommand.
Building jails is an exercise left to the reader. I've always found Dockerfiles to be archaic and generally unpleasant to deal with such that I feel like the lack of a Docker compatible template file is a feature not a bug. While I use ansible and some shell scripts, things like Nomad already support (iocage) jails.
I have no idea why the hardware/software industry all focused on the linux kernel as the common base for so many hardware support. The amount of chips supported in the linux kernel is mind boggling.
I worked with FreeBSD in my early career. How do I miss the `make world`. So easy, all-in-one, clean and elegant system.
Everybody runs Linux because it's free, there is no danger of closed private forks gaining any traction, there is no danger of it playing MongoDB. So everyone can safely pick it and invest into it. The pace of progress is very high because of that, and anything broken would be fixed very-very soon.
Because of that ability to rely on Linux being a common thing that nobody can privatize, huge companies like Red Hat and Canonical could form, and entities like IBM, Oracle, Intel, Google, etc could keep investing in the development.
All the above is sort of problematic with FreeBSD. It's too cathedral on one side, and has too few strings attached to hold to it on the other side. So it remains the choice of connoisseurs who need its particular technical brilliance (e.g. the network stack) or its very permissive license (see PlayStation).
grsec is a counter example to this claim
> Grsecurity fully complies with the license of the Linux kernel, the GPLv2. Since grsecurity is delivered as a source code patch, it is not possible under the terms of the GPL to offer a free version under an actual restriction that it be used only for evaluation purposes. Any customer receiving a grsecurity patch receives all the GPL-granted rights and responsibilities, including the right to redistribute patches in their possession or even to sell them to others.
Forks are completely fine. A lot of hardware, often not even esoteric, is supported by non-mainline kernel versions.
I'll die mad about it.
So many in the OSS community applaud vendors for upstreaming a driver to the Linux kernel even though they haven't given any basic form of documentation. Not only is this a massive pain if you happen to work on a project that isn't GPL compatible (back to square one, legally required to clean room implement the algorithm if you want to work with Linux source), but you still have no idea how the device actually works and what the sharp edges are (good luck writing bug fixes!). It's utterly baffling that people have generally accepted Linux as if it is the only FOSS kernel that anyone should ever care about.
Good. And I hope that continues to be the case.
The harder life is for non-copyleft licensed software and ecosystem the more society stands to benefit and the more the software industry stands to redeem itself.
Give and get back some
Sharing it all
Path we know best
we're having a ball
Give and get zeros
Give and get ones
Given to you but
Not you to us
For those of us that treasure freedom, through diversity of ideologies there is strength. Why one would actively put a pox on those with nearly the same goals as yourself is beyond me. But, hey… you do you.
Example #2124 out of 251295912931, BSD devs were absolutely hardcore adamant to stick to CVS and SVN as their source control for years after the rest of the world has moved on.
For config management all of the usual suspects should work and all will be painful to scale in non-FreeBSD specific ways. The Opscode related nightmares finally subsided sometime during the pandemic. Was there a specific package you had trouble with?
If memory serves uname(3) should return Linux when you're running a Linux binary, but then you're back to running a hostile program and working around anything that may arise once you have to break out of the Linux userland.
They've always been fine for me, and sound is more reliable than Linux. What went wrong for you?