The BSD troubles rather than wars: it wasn't a spat between BSD distros, it was BSDi and UC (Berkeley) getting sued by USL.

It cast a long shadow over the viability of Berkeley at the height of the UNIX wars, and just as Linux was appearing as a completely independent and unencumbered UNIX supported by the maturation & advocacy of GNU and the FSF.

In retrospect, it's probably a good thing. BSD splinters have largely become incompatible with each other, whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences.

We probably would have had BSD wars for real not long after, if it had become popular. To some extent, this is by design, as there's no culture or ethos that pushes people back together.

> whereas Linux distro splinters have (largely) remained compatible due to licensing and cultural differences.

Seems to me this had nothing to do with licensing or culture, but rather that if you wanted your distribution you'd use the upstream kernel and build your own userland with blackjack and hookers and whatever direction you were interested in, so there's some measure of strong relatedness in the kernel everyone shares. You might add a few modules or patches, but few people bother (or need) to fork the kernel itself.

Since BSDs are systems, if you want to go your own way you fork the entire system (that's literally the genesis of both OpenBSD and Dragonfly).

On the other hand, if BSDs had been more popular, one of these splinters might have dominated the market as much as Linux does, due to the many positive feedback effects of being the most successful free OS.

The BSDs aren't really much better in that regard once you leave the base install, and their hardware support is substantially worse.

I will agree hardware still lags but for the target of servers and serving its fine.

As far as BSD being a mess after base I completely disagree. Using and understanding a package manager makes life pretty simple.

That said if the Linux community did that they would probably realize how silly containers are :)

Linux uses a bunch of package managers, it doesn't solve anything yet creates the problem of "X isn't in the repo, now what?".

If you dont understand that you need to automate and manage your own packages (including containers) for Linux, which meet your requirements, then no framework will help you.

You also need to do this for any pipeline for any OS.