FreeBSD updates ... or lack of them

[vermaden]

One thing that is pretty shitty about FreeBSD is its updates ... or lack of them, we have a working 'infrastructure' for patches that is currently used for security patches, the freebsd-update utility, but other important patches sych as these [1] will not be in *RELEASE* and in 'production ready' system until next 'big' RELEASE (8.3-RELEASE) which will propably happen after a year ... and that sucks a little

[1] http://blog.vx.sk/archives/24-Backported-patches-for-FreeBSD-82-RELEASE.html

 

[SirDice]

Perhaps it's a good idea to include patches that improve stability, like bugfixes, on a monthly basis. In my opinion stability is also a factor when it comes to security. As long as they don't add or change functionality I don't think it would be a problem to include them in a RELEASE.

 

[vermaden]

IMHO it would be great to have a 8.2.x-RELEASE (8.2.1-RELEASE, 8.2.2-RELEASE) every month or when its needed to add every usefull update that increases stability, its not about performance updates, only RELIABILITY updates, if not, the we should forgot about 'stable as rock' sign that used to stick to FreeBSD.

 

[dbi]

IMHO it would be great to have a 8.2.x-RELEASE (8.2.1-RELEASE, 8.2.2-RELEASE) every month or when its needed to add every usefull update that increases stability, its not about performance updates, only RELIABILITY updates, if not, the we should forgot about 'stable as rock' sign that used to stick to FreeBSD.

I believe those major.minor.patchset "releases" exist but they are named in the form
A.B-RELEASE-pX

root@gate ~ # freebsd-update fetch install
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 8.1-RELEASE from update3.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 8.1-RELEASE-p2.
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.

No new features, security updates only.
8.1 has two patchsets for now.

For the base system it looks quite normal - slow development model, bugs hardly slip in the production-ready code but one has to wait longer for new features. The ports are the opposite case - fast development, but no time for QA. I personally prefer the former model.

 

[gkontos]

IMHO it would be great to have a 8.2.x-RELEASE (8.2.1-RELEASE, 8.2.2-RELEASE) every month or when its needed to add every usefull update that increases stability, its not about performance updates, only RELIABILITY updates, if not, the we should forgot about 'stable as rock' sign that used to stick to FreeBSD.

Thumbs up, I am with you here.

 

[SirDice]

No new features, security updates only.
8.1 has two patchsets for now.

Yes, but no bug fixes. Even if there's some panic inducing bug that wasn't found during the release cycle, it won't get fixed. So you either have to move to -STABLE or wait for the next -RELEASE. -STABLE adds functionality so this may not be an option for production systems.

 

[vermaden]

So you either have to move to -STABLE or wait for the next -RELEASE. -STABLE adds functionality so this may not be an option for production systems.

In other words ... Shit, meet Fan

 

[dbi]

Could you, guys, please, show me a bug in a "RELEASE" version that was fixed in the corresponding "STABLE" version and then wasn't backported to the "RELEASE"?

 

[gkontos]

Could you, guys, please, show me a bug in a "RELEASE" version that was fixed in the corresponding "STABLE" version and then wasn't backported to the "RELEASE"?

A recent one and very serious affected 8.1-RELEASE. Fixed in stable, never made it to official errata.

 

[Galactic_Dominator]

Could you, guys, please, show me a bug in a "RELEASE" version that was fixed in the corresponding "STABLE" version and then wasn't backported to the "RELEASE"?

There is no "backporting" to speak of, unless you're referring to an MFC from HEAD to STABLE. Once in STABLE, everything makes it into the next RELEASE unless it's reverted. HEAD is only branched on major version updates, eg FreeBSD 9.0 will be a HEAD branches of something in the future.

 

[gordon@]

One thing that is pretty shitty about FreeBSD is its updates ... or lack of them, we have a working 'infrastructure' for patches that is currently used for security patches, the freebsd-update utility, but other important patches sych as these [1] will not be in *RELEASE* and in 'production ready' system until next 'big' RELEASE (8.3-RELEASE) which will propably happen after a year ... and that sucks a little

[1] http://blog.vx.sk/archives/24-Backported-patches-for-FreeBSD-82-RELEASE.html

I think it's a pretty simple explanation. Releases are very time and resource consuming to pull together. The RELENG team is worked enough without additional releases to cut on a monthly basis.

 

[vermaden]

I think it's a pretty simple explanation. Releases are very time and resource consuming to pull together. The RELENG team is worked enough without additional releases to cut on a monthly basis.

We do not need new releases even, just binary patches by using freebsd-update, with current naming for security fixes X.y-RELEASE-pZ we cound name it like X.y-RELEASE-pZsV where 's' would show the stability fix number ... no newer 'big' RELEASES needed.

 

[dbi]

A recent one and very serious affected 8.1-RELEASE. Fixed in stable, never made it to official errata.

WOW! Bye-bye, "rock solid" myth!


/me joining the "we want bug fixes in RELEASEs" crowd/

I think it's a pretty simple explanation. Releases are very time and resource consuming to pull together. The RELENG team is worked enough without additional releases to cut on a monthly basis.

That is not an excuse to leave the "production-ready" version crippled. Either the "road map" (more QA, less RELEASEs) or the development model (e.g. put bug fixes in RELEASE like it's done with security updates) should be changed.
Otherwise people like myself loose the main point of using FreeBSD - stability. It would seem there is no version suitable for mission critical tasks - "RELEASE" has unfixed bugs, "STABLE" is changing too much and we'd be better off with something like RHEL.

 

[olav]

Yeah I agree, there should be a 8.2.x release with bugfixes. But this is a FreeBSD community, can't we do this ourself?

 

[Galactic_Dominator]

If you believe so strongly in your ideas, create the infrastructure and if enough people use it and like it, it will eventually get merged into the base. That's how stuff works around here. There are enough people with enough problems already. 10 people complaining about FreeBSD design structures in the forum has about the same effectiveness as *beep**beep**beep**beep**beep*ing to /dev/null.

 

[vermaden]

@Galactic_Dominator

Sitting quiet with mouth shut pretending that the problem does not exists does not helps either.

The FreeBSD Foundation gathers money/donations, they can fund such a project, but first they must know that there is such a need for that project ...

I always has been told that FreeBSD is not for desktops/laptops/workstations ... that its all about servers, but current status quo is far from server room.

 

[Galactic_Dominator]

@Galactic_Dominator
Sitting quiet with mouth shut pretending that the problem does not exists does not helps either.

Neither does adding another person with another idea of how FreeBSD should run. Perhaps you should investigate the birth and history of freebsd-update() if you are interested how things come to pass.

The FreeBSD Foundation gathers money/donations, they can fund such a project, but first they must know that there is such a need for that project ...

They can collect funds, but they do NOT collect funds for specific projects (the section on the website is a suggestion for how the funds should be used). The reasons for this have been discussed on the mailing lists if you wish to research the why but the short story is it's legal and no amount of griping will change it. Most popular alternative option is a bounty system.

I always has been told that FreeBSD is not for desktops/laptops/workstations ... that its all about servers, but current status quo is far from server room.

Well you were never told that by me, but everyone has their opinion. I've used FreeBSD as my primary desktop for many years.

As far as suitability in the server room, I'd say most of us don't have a problem with it. It's only your artificial limitations on what is suitable that is causing your problem. Many, many people run STABLE on their production servers. Of course it's up to you to be doing the testing for such an environment but that should be occurring no matter if you're running RELEASE or STABLE.

It's not like release models such a Debian and Ubuntu are some panacea of production environments. You're just shifting the problems to a different stage and adding complexity which might work a little better if you have middle management package pushers around.

The reality is FreeBSD is no where near the size of either of those two OS's and for any solution to be considered it must be elegant in terms of efficiency and functionality.

 

[gkontos]

If you believe so strongly in your ideas, create the infrastructure and if enough people use it and like it, it will eventually get merged into the base. That's how stuff works around here. There are enough people with enough problems already. 10 people complaining about FreeBSD design structures in the forum has about the same effectiveness as *beep**beep**beep**beep**beep*ing to /dev/null.

You obviously misunderstood the nature of this post. Things never get better if people don't mention them. As far as creating a different distribution that would contain some major errata it is not as easy as it sounds, not with 10 people at least. However, if someone suggested the idea and provided some of the means to do that then I would be happy to participate.

 

[aragon]

Can we turn this into something productive and create a monolithic, rolling patch set that saves everyone from having to pick out the individual bits from the mailing lists and commit logs?

A patch set will make life much easier. Apply to 8.2-RELEASE source tree and recompile kernel - simple. In cases where userland bits need to be recompiled too, perhaps those can be documented similarly to how security advisories document them.

 

[vermaden]

Can we turn this into something productive and create a monolithic, rolling patch set that saves everyone from having to pick out the individual bits from the mailing lists and commit logs?

A patch set will make life much easier. Apply to 8.2-RELEASE source tree and recompile kernel - simple. In cases where userland bits need to be recompiled too, perhaps those can be documented similarly to how security advisories document them.

First we need to know what useful changes we can 'patch back' to RELEASE, for example if I havent seen that blog post, I would not know that there were such important changes, what to track, commits (where to check them before I fire up google)?

Second, we have one directory with 'plain/stock' 8.2-RELEASE built, next we attach needed patches and build 8.2-RELEASE in another directory, as 8.2.1-RELEASE, we do diff -r -q 8.2-RELEASE 8.2.1-RELEASE and tar up the difference and put on http as a patch, manual download can be good way for a start.

After next patches we apply them to the source and built 8.2.2-RELEASE but we now need two diffs, one versus 8.2-RELEASE another one versus 8.2.1-RELEASE for people who already 'updated', then tar up the difference and put another two files on the http for download.

Of course the size of the tarball can be greatly decreased by using bdiff ... but as for start, we can use more bandwidth.

There is also a question how to apply the patch ... (or where to extract the changes)

As for needed space for more and more 'full built trees' CCACHE and ZFS with DEDUP and will be usefull, its already in HEAD so ...

 

[mix_room]

@vermaden, if I understand the freebsd-update(8) utility properly there is no problem with you running your own server. Hence you could run your own binary release with whatever security patches you see fit.

freebsd-update -r vermaden.fbsd.8.x.security -s vermaden.server

I recon the reason why this is not officially supported by the release team is really just lack of time. I'm sure that if you were to set up the functionality, many people would be more than happy to use your, or someone elses, services.

Edit:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-update-server/article.html
Perhaps one could just run a rolling binary patch for -STABLE

 

[oliverh]

The need for such a project isn't a novum, just as the desperate cry for a stable ports-tree. But the real problem isn't the lack of ideas or a "stubborn foundation", which hoards money instead of investing it, it's the massive lack of manpower in different areas. You're talking about symptoms, it's time to talk about causes.

FreeBSD needs fresh Blood!

"/me want something ..." is a rather silly approach in Open Source and I'm not referring to you Vermaden, it's a more generic conclusion toward the crowd surrounding FreeBSD.

 

[vermaden]

I am kinda troll in that case, yelling that something needs to be done without actually doing nothing, but the same way 'has been done' for the GEM/KMS project which is now founded by FreeBSD Foundation.

Stable ports tree is other thing IMHO, I was just thinking about 'our land', updates for the FreeBSD's base system.

@mix_room

Thanks for suggestion, I may try to do something like that, if its only that simple, then it would only need an additional server for all RELEASE updates.

 

[aragon]

First we need to know what useful changes we can 'patch back' to RELEASE, for example if I havent seen that blog post, I would not know that there were such important changes, what to track, commits (where to check them before I fire up google)?

Google indexes the forums really well. I'm sure if you create a thread with a suitable title it'll get picked up soon. Keep the first post updated with the latest patch set and hopefully enough volunteers will post to the thread whenever new changes are seen in the lists and/or commit logs.

After next patches we apply them to the source and built 8.2.2-RELEASE but we now need two diffs, one versus 8.2-RELEASE another one versus 8.2.1-RELEASE for people who already 'updated', then tar up the difference and put another two files on the http for download.

If it were for me to decide, I'd just keep the patchset diffed against a fresh 8.2-RELEASE source tree. I'd say it's simpler to just csup the source tree before applying the latest patchset each time than keeping track of multiple versions of the patch.

There is also a question how to apply the patch ... (or where to extract the changes)

Download file, cd /usr/src && patch </path/to/download ?

 

[oliverh]

I am kinda troll in that case, yelling that something needs to be done without actually doing nothing, but the same way 'has been done' for the GEM/KMS project which is now founded by FreeBSD Foundation.

Stable ports tree is other thing IMHO, I was just thinking about 'our land', updates for the FreeBSD's base system.

@mix_room

Thanks for suggestion, I may try to do something like that, if its only that simple, then it would only need an additional server for all RELEASE updates.

Well, it's the same category in my opinion. If I have some tool like freebsd-update, then it's just reasonable to have a stable ports-tree. Without it, it just feels incomplete. And for GEM/KMS, it's just one guy, who takes the load ... you should read the comments to the mentioned article, I wrote there something about the somewhat bewildering condition. I don't really criticize you, it's more a critique in both directions -- users/developers. You see, I'm on your side, but there are more aspects to consider than the obvious ones.