Stable vs Stable...

Would you be interested in a Stable (as in Debian) branch where you get only security updates?

  • Not really

    Votes: 12 52.2%

  • It would be interested

    Votes: 3 13.0%

  • I need it

    Votes: 0 0.0%

  • Not again...

    Votes: 8 34.8%
  • Total voters
    23
  • Poll closed .
freezr

freezr

Hi folks,

I was always "obsessed" with the latest and greatest (software) therefore I always preferred using (Linux) rolling distros.

However that changes, in the last five years I moved to stable (Linux) distros, such as Debian and Devuan, and eventually ended up with FreeBSD.

Now I really like the FreeBSD model, the base system is stable while third party software is fairly updated and you get new software almost as it was a rolling distro, whether you are in quarterly or latest branch.

But what if you need a "stable" as in Debian, FreeBSD workstation for production?
Is that possible without holding the packages, and missing important security update?

For what I understand from the handbook, the FreeBSD stable branch moves slower but it might be affected by bugs and vulnerabilities...

26.5.2. Using FreeBSD-STABLE​

FreeBSD-STABLE is the development branch from which major releases are made.Changes go into this branch at a slower pace and with the general assumption that they have first been tested in FreeBSD-CURRENT.This is still a development branch and, at any given time, the sources for FreeBSD-STABLE may or may not be suitable for general use.It is simply another engineering development track, not a resource for end-users.Users who do not have the resources to perform testing should instead run the most recent release of FreeBSD.
Click to expand...

I made a pool out of it, you can either reply or select an answer... 😉
 
freezr said:
But what if you need a "stable" as in Debian, FreeBSD workstation for production?
Is that possible without holding the packages, and missing important security update?
Click to expand...
Releases already provide this, right now.

For example, at the time of writing you could easily opt to use 13.5 which is an older release, but one which gets maintained until next year. See also the release information.
 
cracauer@ said:
I was talking about ports. Sorry if that wasn't clear.
Click to expand...
Does Debian et al actually maintain "stable" branches for the applications (our ports?)

Rereading the OP it almost sounds like a combination of:
RELEASE for base
Quarterly plus security updates for packages/ports

In isolation, not a bad idea, but packages/ports depends on the maintainer routinely applying security patches. I think a port relies on the upstream source to actually apply the patch, then maintainer bumps the upstream version and hopes it builds cleanly.

I think the question is really "is there a way to get security updates into ports quicker?" That almost feels like "latest" for ports, but I have seen quarterly update in between for things like firefox, etc.

Maybe the OP can clarify exactly what they think would be on this new branch they are suggesting?
 
cracauer@ said:
Yeah. It's insane.

And sometimes it backfires. There have been Debian backports for security fixes that were incorrect.
Click to expand...
Yep, been there with RedHat. They keep the base release number the same but then backport the heck out of everything, sometimes wrongly. Hard to explain "Our RHELx.y has that CVE applied because we are at RHELx.y-metadata-z" and then "prove it".

It's a lot of work, but I think if a business is truly committed, follow RELEASE for base and maintain their own ports tree following latest, if a maintainer can't update quickly enough, business picks up the change and creates a pull request for the maintainer. That would at least try to push the change back upstream make it easier on the port maintainer. But that alone should be a dedicated position for the business and the person needs to understand the "how do I update ports" aspect. Something good for a graybeard approaching full retirement age :)
 
At the risk of moving a little away from the main discussion but... I also can't help mention that when it comes to issues like these then I also often wonder... why this need to (fully?) rely on "the powers that be" to keep you safe?

For example... at the time of writing I'm in the middle of setting up my new (14.2) server; it's going to be hosting my email services, web services (a (modded) Minecraft server 😎), etc.

My point being: I'm not going to fully rely on the FreeBSD project and/or the port maintainers to keep things safe. I'm also keeping a close eye on generic security alerts that involve my main "open" services (Apache, Postfix, Cyrus IMAPd, etc.). It wouldn't be the first time that the Apache project released a patch which only found its way to the ports collection several days later, yet I had already implemented it manually myself; courtesy of that same Ports collection (and Git).

IMO being a Unix / FreeBSD admin also comes with its own set of responsibilities.
 
ShelLuser said:
At the risk of moving a little away from the main discussion but... I also can't help mention that when it comes to issues like these then I also often wonder... why this need to (fully?) rely on "the powers that be" to keep you safe?

For example... at the time of writing I'm in the middle of setting up my new (14.2) server; it's going to be hosting my email services, web services (a (modded) Minecraft server 😎), etc.

My point being: I'm not going to fully rely on the FreeBSD project and/or the port maintainers to keep things safe. I'm also keeping a close eye on generic security alerts that involve my main "open" services (Apache, Postfix, Cyrus IMAPd, etc.). It wouldn't be the first time that the Apache project released a patch which only found its way to the ports collection several days later, yet I had already implemented it manually myself; courtesy of that same Ports collection (and Git).

IMO being a Unix / FreeBSD admin also comes with its own set of responsibilities.
Click to expand...

Ironically I follow the Debian security mailing list to be notified of fixes in software that I use (on FreeBSD).

I just wish they would drop firefox and chromium from it. They always have CVEs anyway.
 
ShelLuser said:
Releases already provide this, right now.

For example, at the time of writing you could easily opt to use 13.5 which is an older release, but one which gets maintained until next year. See also the release information.
Click to expand...

I didn't think about it, for a stable (Desktop) environment the solution would be the older release... 🤔
 
ShelLuser said:
IMO being a Unix / FreeBSD admin also comes with its own set of responsibilities.
Click to expand...
No one is going to argue with that; it all become a tradeoff between how much work you want to do vs how much you don't want to do.

Based on the rest of your post in #8, I'm assuming you are building/rebuilding base from source, with a tweaked kernel config file are you are committed to keeping track of any daily commits to the branch you are tracking plus installing your own ports tree and building with customized options so you have only what you need and again tracking daily commits and/or UPSTREAM changes so you can stay ahead of the problems.
 
On one hand, I would like this: Being able to treat ports+packages exactly like I treat the base OS.

For example, I always run RELEASE only, and right now both my servers are on 13.4. I know that they will go to 13.5 soon, but I also expect that upgrade to be fully compatible, with no ABI changes to my own software (stuff I have compiled and installed myself), no major new features, no deprecation. And I know that in a year or so (plus or minus a factor of two), I will move to 14.x, which could be a major upgrade. It would be nice if I could treat ports+packages exactly the same way, stay within the 13.x series of them, with minor changes coming down the pipeline (mostly security fixes and bugs). As an example, I would like the Python version (currently 3.11) to stay the same within FreeBSD-13-RELEASE lifetime.

I totally understand cracauer's argument that the amount of manpower that would be required to maintain separate copies of ports+packages for 13.4, 13.5, 14.2, 14.3 and 15.0 makes this dream completely impractical. The really big Linux distributions are capable of doing that (often quite badly), but they all have way more users, and way more funding (from either support contracts or corporate donations).

The current FreeBSD model is OK, as long as one doesn't rely too much on the functionality of ports and packages. Which means that for my use (server only, with about 50-100 packages installed) it can be managed by me. With a GUI+DE environment (probably 500-1000 packages installed, plus close linkage between kernel and the DRM packages), this may be awful, but that doesn't affect me: I have outsourced that problem to Apple (and sometimes Microsoft).
 
astyle said:
This is not making any sense, because that's exactly what freebsd-update(8) does: https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-upgrading-freebsdupdate . And also, freebsd-update(8) is available in -STABLE, -RELEASE and -CURRENT ... 😲

No need for no stinking backports... Just RTFM.
Click to expand...
What I was thinking yeah

Has anyone here experienced anything breaking due to an update?
I think freebsd's package management system is perfect. It can't really logically break due to the user packages being separated from the system, this way everything is very secure and is always more or less up to date
 

It would be interested.​

If only they would add stability to ports and packages that would work adequately with Wayland. At the server level, everything is fine, but the Desktop is unsuitable for Wayland today. You have to "fight" with many applications until you stumble upon a bug again.
 
chungs said:
Has anyone here experienced anything breaking due to an update?
Click to expand...
Very few have NOT experienced anything breaking due to an update. These Forums are full of threads complaining about the dependency hell and drm-kmod being incompatible with the upgraded base.
 
I believe the specifics are that freebsd-update exists in -CURRENT and -STABLE but you can only use it to update to a -RELEASE.

People using a development version are expected to upgrade from source.
 
cracauer@ said:
Some of you still talk about updating the base system only and others about updating base+pkg.
Click to expand...
The OP in #11 implies more "pkg" than base, but to me it almost sounds like "I want the last package that worked to track all the base updates" so ports tree, tag the working version, then rebuiild the tagged every time we update base.

I treat it as more process: Follow RELEASE and Quarterly, but before actually updating either. Quarterly pkg is normally fine unless you are near/crossing a RELEASE-px boundary.
Example is 14.1-RELEASE-px going to 14.2-RELEASE-px. Quarterly was built against 14.1-RELEASE until it went EoL, so if you were running 14.2 you needed to rebuild drm-kmod from ports. Then 14.1 went away, Quarterly was built against 14.2 so drm-kmod was correct from pkg. I waited to upgrade pkgs until this point, but unfortunately ran into the "some of the pkgs didn't built" and lost access to a few applications. So just wait.
 
astyle said:
Very few have NOT experienced anything breaking due to an update. These Forums are full of threads complaining about the dependency hell and drm-kmod being incompatible with the upgraded base.
Click to expand...
Something that can easily avoided just by reading the release notes and the errata before upgrading.
 
mer said:
The OP in #11 implies more "pkg" than base, but to me it almost sounds like "I want the last package that worked to track all the base updates" so ports tree, tag the working version, then rebuiild the tagged every time we update base.

I treat it as more process: Follow RELEASE and Quarterly, but before actually updating either. Quarterly pkg is normally fine unless you are near/crossing a RELEASE-px boundary.
Example is 14.1-RELEASE-px going to 14.2-RELEASE-px. Quarterly was built against 14.1-RELEASE until it went EoL, so if you were running 14.2 you needed to rebuild drm-kmod from ports. Then 14.1 went away, Quarterly was built against 14.2 so drm-kmod was correct from pkg. I waited to upgrade pkgs until this point, but unfortunately ran into the "some of the pkgs didn't built" and lost access to a few applications. So just wait.
Click to expand...
As for the drm-kmod ports, there is now the "kmods-latest" repo which should avoid such problems in most cases.
 
  • Thanks
Reactions: mer
elgrande said:
drm-kmod ports, there is now the "kmods-latest" repo
Click to expand...
For convenience, kmods repository comes now preconfigured on 14.3-*, 14-STABLE, 15-CURRENT, quarterly and latest.

root/usr.sbin/pkg/FreeBSD.conf.latest
Code: 
# To disable a repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file, e.g.:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#   echo "FreeBSD-kmods: { enabled: no }" >> /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
 
You must log in or register to reply here.
Back
Top