Comparing, BSD versus Linux distributions' Development

My Approach
I am an old guy interested in Linux over 15 years or so and using Linux ONLY for over the past 8 years.
I have tried almost all except ARCH and Absolute Linux (very difficult in the past not NOW with Manjaro and Absolute Linux Live available, it is manageable-It was only installable image, then).
I loved the Live Image where I can run on RAM (one need at least 4 GB RAM for virtual testing-very SLOW and draggy) and see the effects.
I only use Debian now.
All the other distributions I love are on portable external devices (single or multiple).
I love KDE plasma desktop.
The Western Desktop of RubeccaBlack is beautiful. 
Open BSD has a live CD for booting with Internet connection.
If you have a SLOW Internet it takes over 5 hours.
What I do is install it on a external disk and go to sleep and check its funtionality in the morning, leisurely.
I am OLD and LAZY now.
The warning for young guys is that, one has to be patient to USE or TEST Linux.

It a large COLLECTIVE ENTERPRISE unlike Microsoft or Apple.

By the way, RubeccaBlack probably a derivative of Open Mandriva is an excellent Linux distribution (short on packages, though) to try.



Reproduction

Comparing, BSD versus Linux distributions' Development  
Comparing-apples-to-BSDs asks: 

I was reading one of the old articles from the archive. One of the things mentioned was how the BSDs have a distinct approach in terms of packaging the base system relative to userland apps, and that the Linux distros at the time were not following the same practice. Are there Linux distros that have adopted the same approach in modern times? If not, are there technical limitations that are preventing them from doing so, such as some distros supporting multiple kernel versions maybe?

DistroWatch answers: In the article mentioned above, I made the observation that Linux distributions tend to take one of two approaches when it comes to packaging software. Generally a Linux distribution will either offer a rolling release, where virtually all packages are regularly upgraded to their latest stable releases, or a fixed release where almost all packages are kept at a set version number and only receive bug fixes for the life cycle of the distribution. Projects like Arch Linux and Void are popular examples of rolling, always-up-to-date distributions while Fedora and Ubuntu offer fixed platforms.

Basically, with few exceptions, Linux distributions all fell into those two categories where the rolling releases were constantly changing and fixed releases tended to fall behind (or out of date).

The BSDs, in contrast, tend to take an alternative approach. Operating systems like FreeBSD and OpenBSD provide a fixed core (or base) operating system. The base tends to be small, stable, and only changes in small evolutions on a set schedule. The cores of the main BSD branches are fixed. Meanwhile most applications which you can install on the BSDs (LibreOffice, Firefox, the desktop environment, etc) are kept up to date with their upstream versions. The base operating system is fixed and stable while the applications the user runs can be kept up to date with the latest and greatest. This allows the BSDs to offer close to cutting-edge applications without risking a routine update breaking the core of the operating system.

A big part of why the BSDs have this stable core (and updated third-party applications) while Linux distributions tend to take an all-or-nothing approach to version upgrades is the BSDs are developed with all the core operating system components as part of one large project. The FreeBSD kernel, command line tools, filesystems, and base libraries are all handled by the same team. Third-party applications (typically called ports) are made available by another team. In other words, FreeBSD is a whole operating system with almost all the key parts made by one organization.

Linux distributions, on the other hand, are mostly collections of third-party components that are wedded together and managed by a package manager. Debian and Slackware, for the most part, don't develop much of their own software. Most of the work these projects do is to take separate components and weld them together to make an operating system out of independently developed parts. The Linux kernel is made by one team, the core libraries by other teams, the installer by another team, the userland tools by yet another team - all of them operating with their own separate goals and schedules. Linux distributions are made up of hundreds, sometimes thousands, of packages made by teams other than the one publishing the distribution.

This means that Linux distributions do not have one core operating system with key components managed by one team. The kernel, C library, init software, and userland tools come from separate places and their updates are generally not coordinated. This makes it hard for Linux projects to maintain a small, static core while end-user applications get updated.

While difficult, it is not entirely unheard of for some Linux distributions to attempt to maintain a small, stable core platform while regularly updating desktop applications. Some projects take a semi-rolling release approach. If you have used PCLinuxOS or Chakra GNU/Linux you will have seen this in action. The kernel, lower level graphics libraries, and core tools tend to upgrade slowly while desktop applications are updated as new releases come out. Semi-rolling releases can work for a while, but eventually the core components need to "jump ahead" occasionally to keep up.

Some Linux projects attempt to make an image of an operating system and add third-party bundles or containers on top of them. The Fedora CoreOS distribution does this. It maintains a fixed core on which people can add containers or package bundles. The core system in this case is not necessarily fixed, but because it is updated as a whole (rather than as individual packages) the idea is that the core image should always work. The core image approach allows for faster upgrades and keeps the core system somewhat isolated from the applications running on it, but lacks flexibility compared to the semi-rolling and BSD approaches.

A more flexible, and increasingly common solution, is to have a minimum Linux distribution that runs portable packages, such as Flatpak or Snap packages. Portable packages ship with their own dependencies, making them independent of the core operating system and therefore able to update separately from the base distribution and they can be frequently upgraded. The base distribution can then act as a long-term support (LTS), fixed release that is rarely upgraded, much the same way the BSDs handle upgrades. Unfortunately, portable packages are often very large, do not integrate with the host desktop properly, and managing them requires a second package manager to be installed on the operating system.

One more solution is backports. A backport is an updated program which is built to run on an older, fixed-release distribution. Generally backports are kept in their own, separate package repository and added to LTS distributions such as CentOS, Debian or Ubuntu. A backport can be handled by the distribution's default package manager, which is convenient when compared to portable package solutions. However, backports are rarely well tested (compared to the core package repositories), and in my experience, frequently break things on the parent distribution. This makes backports flexible but adds risk of breaking functionality or dependencies on the base operating system.

In short, while there are technical hurdles (such as distributed development) which make it harder for Linux distributions to provide the same sort of base platform isolated from third-party applications, it is possible for Linux distributions to offer this approach. There are several solutions available, each with their strengths and weaknesses. None of these approaches is exactly the same as the BSDs, but some of them are similar and offer some of the same benefits.