Hacker News Reader

Comment by Scramblejams | Hacker News Reader

Does this mean that version numbers for software in ports and pkg will be frozen and security fixes backported? That sounds like the relatively new quarterly model but with support lasting for 5 years instead of phasing out after 3 months. Given the sentiment elsewhere on this page that "this doesn't really change anything outside of providing guarantees," my guess is the answer is no.

Sure would be nice. Coming from Debian, I long for a similar model in FreeBSD.

View on HN

> Does this mean that version numbers for software in ports and pkg will be frozen and security fixes backported?

ports has already had this for some time:

http://svnweb.freebsd.org/ports/branches/

There might be semi-official repos for those somewhere as well. Or you can always build your own with poudriere.

> Coming from Debian, I long for a similar model in FreeBSD.

Oh hell no. This gives silly issues like Lenny's pigz being broken for like 4 years. Or OpenSuse's crappy model which shipped a shitty version of kde4 long after it had become stable elsewhere.

ports has already had this for some time:

I think he meant branches which are supported for an extended duration. The quarterly branches are (currently, and as far as I know this isn't going to change) supported only for the quarter in question.

If you ship software for Debian and you've been frustrated that your users get stuck with a lousy version of a dependency, I can understand that.

I've been admining Debian boxes for more than a decade so I'm aware of the drawbacks of its policies. That's why my desktop tracks unstable. But for a sysadmin, freezing everything for long periods of time makes for an enormous reduction in churn-related administration time. Having nothing but security updates to install until the next version comes out 2+ years later is excellent. For the exceptions, pinning can often solve the problem. And if pinning doesn't work, there's always building from source.

Like I said above, I'm new to FreeBSD so I'm not sure how much churn I'll have to endure, but I'm looking forward to finding out.

I understood why you like tracking a security branch as I have been admining *nix boxes for 15+ years.

Where that approach fails is that as a sysadmin one of the responsibilities is to provide good tools to the user, not reduce work for the sysadmin. The user might be a SaaS platform, developers or more traditional (l)users. Regardless, you want your platform to be stable and efficient from a user perspective. Tracking a "Security" branch only give you one of those in many cases.

It's an apples to oranges in some regards because FreeBSD OS patchsets are essentially the "Security" branch while ports is a different issue(and one the user is most likely concerned about).

Ports is a separate issue. We simply don't have the manpower to maintain old versions of 20000 pieces of third-party software for five years.

Thanks for your response, understood. I'm new to FreeBSD and as a result I didn't find the announcement clear enough to know.

Is there any chance the quarterly approach may get stretched out to cover a longer time period? Anything would be helpful to give busy sysadmins breathing room.

Is there any chance the quarterly approach may get stretched out to cover a longer time period?

To be honest, I don't pay enough attention to the ports side of things to answer this.

Reply on news.ycombinator.com