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.
> All you need is a few tech “influencers” to switch to freebsd then crowds will follow.
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.
The problem of FreeBSD adoption is not really for the FreeBSD folks to solve. Fashionable, popular packages have made the explicit decision to avoid BSD support. Over the years I've run into issues with things like Node, Elixir, Visual Studio Code (or any electron app really), Python (Conda) being lax or hostile to supporting anything other than Linux/Mac/Windows.
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?
VSCode remote not supporting FreeBSD is still so annoying. It's available only as a binary and there's no real, practical reason why it couldn't work beyond Microsoft just not wanting to do so...
Have you tried it in the Linux emulation on FreeBSD? My experience is limited to just my laptop, but significant software builds for Linux (like Chrome) run fine for me. I imagine this could be the case for other things not requiring systemd.
the actual server itself probably works under emulation but the issue is then that when it ssh's in it still uses shell commands to detect the host type, which I can't so easily hack to make it look like Linux without breaking everything else.
The problem isn't in getting a random Linux binary to run. The problem is that you're running a software suite that's designed to not run on FreeBSD.
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.
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.
Because everybody runs Linux for last like 20 years. Data centers, network appliances, storage appliances, smaller devices of all kinds. It's in the open, the mindshare is colossal, expertise working with kernel and writing drivers is relatively easy to come by.
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).
> 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 have no idea why the hardware/software industry all focused on the linux kernel
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.
> this a massive pain if you happen to work on a project that isn't GPL compatible
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.
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.
Trying to spring the GPL on people because they dare to try and understand how their wifi card works is not, in my opinion, a reasonable nor appropriate use of copy-left. Copyright is for derived works, not technical knowledge (i.e. specifications) but when you vendors refuse to provide documentation and only code, they force everyone into this weird position of creating a pseudo-derived work if they dare to (or can even be accused of having!) come near the Linux kernel source. If vendors provided a simple PDF everyone would be happier because now anyone can write the driver free and clear to the best of their ability.
>I have no idea why the hardware/software industry all focused on the linux kernel as the common base for so many hardware support.
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.
Is there a specific (new) laptop you would recommend using with freebsd? One that is as compatible as you say with wifi and bluetooth drivers. I really want to use it even if just for nostalgia. I love how organised and logical the os is.
cfengine3 and puppet both work on FreeBSD, at least. Looks like people are using chef with it too. And, as you point out, Ansible treats it as any other Unix-like system.
I'm not sure what you've tried that does not work!
Ansible and Chef are inadequate tools for the job that cloud server boxes do.
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.
Yeah, what Docker (and the ecosystem around it) got right is the user experience, it's just second to none. It just doesn't matter that Illumos zones or BSD jails might be technically better when the user experience of Docker is so much better.
On the smaller end of the scale, docker-compose is fantastic for managing apps if you only have a few systems.
I remember that there of course were efforts to adorn jails / zones with an easy Docker-like UX. I hope this effort continues and will result (or has resulted without me knowing!) in a great and simple developer experience.
Okay, no. If you're going to set the bar at "must be identical to Linux" then you may as well just use Linux. Docker specifically (and anything based on cgroups) is so closely tied to Linux that you're not going to find a clone on a non-Linux platform. Nor should you.
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 tried to get cfengine working multiple times, but it's just too difficult compared to every other configuration management solution I can think off.
