Solved Is FreeBSD for Business Use . . . No Longer an Option?

patmaddox said:
The simplest way to do this is run pkg-update(8) and pkg-ugrade(8) when you want to update the software.
Click to expand...
This is a very crucial point.
"Stable/Release/Current" describes the kernel and base, it does not describe the third party applications (ports or pkgs).
Upgrading base to the next patch release (13.1-RELEASE-p1 to 13.2-RELEASE-p2) typically won't mandate updating packages, but then you run into the "13.1-RELEASE goes end of life 3 months after 13.2-RELEASE". This can be important when you are talking about ports that are kernel modules like the video DRM bits.
The 3 month window of 13.1 and 13.2 all pkgs are built against a 13.1 kernel/userland.
After that 3 month window 13.1 goes away, and pkgs are built against 13.2 kernel/userland. That is why if you are running 13.1 and try to do pkg upgrade after that 3 month period you get errors.

My typical procedure is freebsd-update to get onto the latest kernel and userland and then pkg upgrade to pick up everything else.
 
This thread made me more confused...

What I understood is if you run your own computer upgrading from .1 to .2 etc... is trivial. It becomes annoying when you have to manage more computers; also because the procedure is a bit convoluted, and the OP would avoid to step over each computer and perform the update, because in the Linux space stable/LTS means that you basically receive security updates that can be mostly performed in background without human intervention... 🤔
 
freezr said:
What I understood is if you run your own computer upgrading from .1 to .2 etc... is trivial. It becomes annoying when you have to manage more computers; also because the procedure is a bit convoluted, and the OP would avoid to step over each computer and perform the update, because in the Linux space stable/LTS means that you basically receive security updates that can be mostly performed in background without human intervention... 🤔
Click to expand...

"The procedure is a bit convoluted" is subjective, and not something I agree with. But, every person will have their own understanding.

freebsd-update(8) has cron and updates-ready commands to fetch updates in the background, and check if any have been fetched, respectively. Then you run freebsd-update install to install them, yes manually, for each machine.

If you have a fleet of servers and want more automatic updates, it's worth looking into Managing System Images with ZFS.
 
Note that Linux version updates, minor and major, often also include various third party software that gets updated too. With FreeBSD there's quite a strict separation between the "base OS" and everything else (ports/packages). As was said earlier, and deserves to be repeated, the 5 year support is for the base OS only. It does not apply to ports/packages. Packages are provided as-is. The ports tree is constantly updated, version changes, bug fixes and whatnot. The ports tree is a humongous, never-ending, rolling release. Packages are build from ports with their default settings. For each supported major version there are two package repositories, a latest and a quarterly. The latest package repository tries to keep up with the ports tree but building and distributing the packages can take some time, so it might lag a little behind. The quarterly repository is branched off from main every three months. During that three month period the quarterly ports branch only receives security and some bug (build) fixes. This does mean that you will have a large amount of package updates with Q1 to Q2 for example. For server installations that might be fine. In desktop environments that might not be so great. With desktop software you generally want to keep track of the latest packages and update often. Things are a lot more of a "moving" target in the "desktop" sphere.

For larger environments I really recommend setting up your own package repositories. For both server and desktop environments. This will give you the ultimate control. You get updates as fast as they are committed to the ports tree. You get to decide to keep them, or revert them if you run into trouble, or add your own local patches. Turn on or off certain options. Set your own default versions for PHP, Python, Java and a whole bunch of others. There's so much flexibly built into the ports tree. And best of all, all your other systems will get their packages blazingly fast (I assume you have a proper local network). Package updates are a breeze to roll out with pkg(8).
 
SirDice said:
Note that Linux version updates, minor and major, often also include various third party software that gets updated too. With FreeBSD there's quite a strict separation between the "base OS" and everything else (ports/packages).
Click to expand...

Exactly what I wanted to hear.
This brings a large degree of sanity to the whole situation.
When I ran linux, if I upgraded, you get the whole she-bang. Regardless.
Unless you jumped through hoops to prevent it.
Also, since linux appears to be just a kernel + "stuff" added on = a distro,
with every version / upgrade / update, I would kick up a
varying slew of bugs / glitches / annoyances. Totally to be expected
when you're dealing with a "hodge-podge" of complicated "stuff" all heaped together.
It's a miracle that it all works as well as it does.

FreeBSD, being one whole and complete operating system,
already adds much in the way of sanity.

I LOVE FREEBSD and I LOVE THIS COMMUNITY.
THANK YOU ALL for all your excellent help and all of your suggestions.
Will look back and refer to all as I go on...

Thanks again!
OP (Dave)
 
SirDice said:
For larger environments I really recommend setting up your own package repositories. For both server and desktop environments. This will give you the ultimate control. You get updates as fast as they are committed to the ports tree. You get to decide to keep them, or revert them if you run into trouble, or add your own local patches. Turn on or off certain options. Set your own default versions for PHP, Python, Java and a whole bunch of others. There's so much flexibly built into the ports tree. And best of all, all your other systems will get their packages blazingly fast (I assume you have a proper local network). Package updates are a breeze to roll out with pkg(8).
Click to expand...

Something to consider for the future....

Again, THANK YOU!!
 
From your initial post:
Dave-D said:
[...] The manual says that major releases (for example, 13.0-RELEASE) will be guaranteed support for 5 years.
Click to expand...
I think, when mentioning "The manual", you're referring to the webpage* FreeBSD Security Information:
[...]
The FreeBSD support model

Under the current support model, each major version’s stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release.

The details and rationale behind this model can be found in the official announcement sent in February 2015.
Click to expand...
Based solely on this quoted text, I can understand that you might conclude you'd want/need a stable version, especially when used to (very) different Linux support models.

As mentioned, the announcement from 2015 about the changed support model gives detailed information. However, IMO, the quoted abstract on the web page could benefit from a little more explanation**. My attempt:

---

The FreeBSD support model​

The current branch is a development branch, FreeBSD versions that come from this branch are not supported.

For each FreeBSD major version there is a related stable branch that is explicitly supported for 5 years. That stable branch evolves during its lifespan, with minor user impact. A stable version comes from a stable branch, however, a FreeBSD stable version is a development version and generally not considered suitable for a production environment. A supported stable branch is used as the basis for a new point release.

For each supported major version one point release at a time is supported, with one exception. From the moment a new point release is released, the old point release remains supported for a period of three months (an overlap intended to plan and ease the administration of the upgrade of minor versions). When that period ends the old point release has reached its End of Life (EoL) and is no longer supported.

The details and rationale behind the FreeBSD support model can be found in the official announcement sent in February 2015.
---

I think together with the very insightful schematic drawing below from anlashok***, you have have a compact overview of FreeBSD's branches, versions and support model.
freebsd_versions-png.15184


___
* During a quick scan of the FreeBSD Handbook I couldn't find it there.

** I think the (short) abstract creates an apparant stark contrast between the support of a stable branch and a release branch, where in reality it is more nuanced, as Eric A. Borisch also mentioned earlier. "supported for 5 years" versus "is only supported for three months after the next point release" used in the same sentence emphasizes this apparant contrast.

*** anlashok has drawn it for the situation at the end of 2022 (Edit: At that time two point releases of a major version were supported—12.3-RELEASE and 12.4-RELEASE). See also this thread referenced earlier.
 
Last edited:
Eric A. Borisch said:
-STABLE and -RELEASE are bit confusing, but that’s where we are. You want -RELEASE. I know it says the stable branch is supported for five years, but the actual supported artifacts are snapshots of the stable branch — these are the point releases. It’s a developer-speak user-speak impedance mismatch.
Click to expand...
I agree that this naming convention is highly confusing: The thing that is stable (adjective) is the kit that is called RELEASE (noun). The thing called STABLE (noun) is not stable (adjective).

As a FreeBSD user, you have to absorb that super early. The second thing to absorb is the segregation between the "base OS" on the left side, and the "packages / ports" on the right side. An addition to that is learning that packages and ports are sort of the same thing, except packages are downloaded pre-compiled, ports is things you compile yourself. The naming there is also very confusing: If I say for example "Installing the package Elephant-3.14 was painful, because it took 42 minutes to compile", I'm really talking about a port.

(Don't tell the OP, he's already confused enough, but there is a move underway to turn the base into a package. While this is a really good idea from an engineering viewpoint, it will make that confusion even worse, because now the base is also a package, except you don't treat it like a package.)

Allow me to be openly critical: While FreeBSD is a great OS, and delightful to install, manage and operate, its insistence on anachronisms and peculiar language really doesn't make it easier. The documentation is excellent, except it uses unfamiliar terms.

And there are two other things that people who have been Linux for a long time really can't get over: (1) The whole system is designed such that compiling everything (base and packages/ports) from scratch is easy and painless (but perhaps slow if you have a small computer). Try that on a RedHat machine, where finding sources and patching/compiling them is between hard and impossible. (2) Upgrades of the base system are fast, painless, reliable, and non-disruptive. My current FreeBSD machine was installed somewhere around version 9.X, and is right now running 12.4, all with upgrades. Of those perhaps 12 upgrades, none went sideways, none required repairs. The typical minor upgrade takes me 5 minutes, including one reboot if the kernel changes. Major upgrades take a long time, perhaps 15 minutes. Upgrades have been so reliable for me that currently I don't even appreciate the value in boot environments, since "what could possible go wrong". (And yes, I will re-install my system soon, one of the reasons being to move to root on ZFS, boot environments, and from a 32- to a 64-bit environment.)

Compare that to Linux, where major upgrades (for example Debian Stretch -> Buster -> Bullseye) are discouraged, because an upgrade usually doesn't get the system right.
 
ralphbsz said:
...there is a move underway to turn the base into a package. While this is a really good idea from an engineering viewpoint...
Click to expand...
I'm going to go ahead and disagree with you here. As a Gentoo refugee, I've experienced the "everything is a package" approach, and I don't care for it. I love the current model of having a base system that is explicitly and certainly not a rolling release. I think the stability you rightly praise in the next few paragraphs is a direct result of this approach.

ralphbsz said:
...(1) The whole system is designed such that compiling everything (base and packages/ports) from scratch is easy and painless (but perhaps slow if you have a small computer). Try that on a RedHat machine, where finding sources and patching/compiling them is between hard and impossible. (2) Upgrades of the base system are fast, painless, reliable, and non-disruptive. My current FreeBSD machine was installed somewhere around version 9.X, and is right now running 12.4, all with upgrades. Of those perhaps 12 upgrades, none went sideways, none required repairs. The typical minor upgrade takes me 5 minutes, including one reboot if the kernel changes. Major upgrades take a long time, perhaps 15 minutes. Upgrades have been so reliable for me that currently I don't even appreciate the value in boot environments, since "what could possible go wrong". (And yes, I will re-install my system soon, one of the reasons being to move to root on ZFS, boot environments, and from a 32- to a 64-bit environment.)

Compare that to Linux, where major upgrades (for example Debian Stretch -> Buster -> Bullseye) are discouraged, because an upgrade usually doesn't get the system right.
Click to expand...
This. Even back in the bad old days when the only way to upgrade was to rebuild from source, I never had a Freebsd upgrade go sideways on me.

On Linux it seemed like every other update broke some major subsystem like, X, or network, or left you with an unbootable system. I'm embarrassed about the fact I tried to make it work for so long.

Edit: And then there was Windows, where they'd cram "upgrades" down your throat whether you wanted them or not, and about half the time they broke stuff. You want the ability to not be screwed regularly? You get to pay extra.
 
I remember when I brought the STABLE vs RELEASE issue up a year ago or so I was immediately stoned to death by fellow daemonologists - "it has always been like that and should remain so henceforth, you mortal!" Happy to see more and more people joining the camp of reason, supporting the idea that a development branch shouldn't be called "stable". The way the current nomenclature makes sense is to think that naming was done by developers for developers, not end users.
 
blackhaz said:
I remember when I brought the STABLE vs RELEASE issue up a year ago or so I was immediately stoned to death by fellow daemonologists - "it has always been like that and should remain so henceforth, you mortal!" Happy to see more and more people joining the camp of reason, supporting the idea that a development branch shouldn't be called "stable". The way the current nomenclature makes sense is to think that naming was done by developers for developers, not end users.
Click to expand...

So now you understand and it's no longer a problem. Right? Right.

When users understand they are reading things not targeted at them, they get a better understanding of how things work.
 
It's not the point. It's not about me. Way too many people are getting bogged down in The Great Swamp of the Stable Release when encountering FreeBSD. Instead of draining the swamp we say - no, let them suffer. There is no reason whatsoever in the Observable Universe to call a development branch stable.
 
Those "too many people" should read "FreeBSD-STABLE is the development branch from which major releases are made." in the handbook and forget about it, they are not interested in tracking it outside of starting yet another bikeshed discussion about its name.
 
This discussion was very helpful to me as a newcomer.

Perhaps of interest to people here, the FreeBSD Foundation, where I work as of April this year, has started an Enterprise Working Group to address priority gaps that may slow FreeBSD adoption as a general purpose enterprise server OS.

The attached image is the charter.

If you would like to help with this work, please complete this Google Form: https://forms.gle/21cBw8xMRdLMz9MD6 and I will add you to the Google Group.
 

Attachments

  • Screenshot 2023-08-23 at 10.48.02 AM.png
    Screenshot 2023-08-23 at 10.48.02 AM.png
    281 KB · Views: 65
Erichans said:
I couldn't find an "explicit presence" of the Enterprise WG in general or specifically on the Foundation website; I presume there isn't one (yet). I found this though (WG Meeting #1 - 21 Aug 2023):
Click to expand...
hey - this blog went live today: https://freebsdfoundation.org/blog/recap-of-first-meeting-of-the-freebsd-enterprise-working-group/

There isn't a great spot in the current Foundation site structure for this sort of thing, but I will see what I can do to make it easier to find.
 
You must log in or register to reply here.
Back
Top