# FreeBSD updates ... or lack of them



## vermaden (Mar 4, 2011)

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 (Mar 4, 2011)

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 (Mar 4, 2011)

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 (Mar 4, 2011)

vermaden said:
			
		

> 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 (Mar 4, 2011)

vermaden said:
			
		

> 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 (Mar 6, 2011)

dbi said:
			
		

> 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 (Mar 6, 2011)

SirDice said:
			
		

> 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 (Mar 6, 2011)

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 (Mar 6, 2011)

dbi said:
			
		

> 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 (Mar 7, 2011)

dbi said:
			
		

> 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@ (Mar 7, 2011)

vermaden said:
			
		

> 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 (Mar 7, 2011)

gordon@ said:
			
		

> 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 (Mar 7, 2011)

gkontos said:
			
		

> 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/



			
				gordon@ said:
			
		

> 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 (Mar 7, 2011)

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 (Mar 7, 2011)

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 (Mar 7, 2011)

@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 (Mar 7, 2011)

vermaden said:
			
		

> @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 (Mar 7, 2011)

Galactic_Dominator said:
			
		

> 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 (Mar 7, 2011)

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 (Mar 8, 2011)

aragon said:
			
		

> 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 (Mar 8, 2011)

@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 (Mar 8, 2011)

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 (Mar 8, 2011)

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 (Mar 8, 2011)

vermaden said:
			
		

> 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.



			
				vermaden said:
			
		

> 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.



			
				vermaden said:
			
		

> 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 (Mar 8, 2011)

vermaden said:
			
		

> 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.
> 
> ...



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.


----------



## dbi (Mar 8, 2011)

oliverh said:
			
		

> 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.



No, it is not. I regret you have missed the joke, but still:

FAQ section
"...We believe that our first and foremost â€œmissionâ€ is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit..."

If the comers don't express what they want the mission is guaranteed to fail.


----------



## oliverh (Mar 8, 2011)

dbi said:
			
		

> No, it is not. I regret you have missed the joke, but still:
> 
> FAQ section
> "...We believe that our first and foremost â€œmissionâ€ is to provide code to any and all comers, and for whatever purpose, so that the code gets the widest possible use and provides the widest possible benefit..."
> ...



Humor is a fine aspect of daily life, but I don't get it in this context. Most FreeBSD newbies don't recognize the seriousness of the situation. Do you know the running gag of Slashdotters? "BSD is dying" ... well, it's indeed dying, it's just a very slow and painful process and it's impossible, because the code is open sourced, to release it from it's pain and finish this unworthy state. So we have no choice, we have to do something. Facta, non verba or like the credo of the OpenBSD crowd "shut up and code". Don't ask, help. Btw. this is my kind of humor in this context, to some degree at least.


----------



## dbi (Mar 8, 2011)

"Shut up and code" is a good motto at first glance but...The community part that can code probably already does so. The bigger part can't code though. Let's say that someone following that motto learns C in 21 days  and tries to code for the sake of community. The result would be of such quality that no patch will get accepted. The bottom line: one real developer with wasted time for reviewing badly written code instead of coding and one disappointed community member.

Imagine a music band that has invited some public in the studio for the recording of an album. While the band is playing at certain point some of the visitors start shouting â€œThere! That note! You got it wrong!â€. Here the fans start arguing â€œIf you are so good why don't you get on the stage and play it by yourselfâ€. So, what is the correct solution - the band plays the tune over and over until they get it right or they invite some of the visitors to play together?

"We want this and we want that" is a necessary feedback and it is a good thing. Don't discourage people from it.


----------



## oliverh (Mar 9, 2011)

>The community part that can code probably already does so. The bigger part can't code though.

Well, the same song again and again. This saying is an image, "shut up and code". The Latin phrase I mentioned above means "deeds, not words" and this is also the same meaning of "shut up and code". Do something, there is more than just code. They need people working on ports, on documentation, money, spread the word, test it and file PRs, etc. pp.

>"We want this and we want that" is a necessary feedback and it is a good thing. Don't discourage people from it. 

Wrong, "we want it" isn't the credo of a _community_. We are talking of Open Source. You're talking about big business, like Microsoft, Apple, etc. You put your money in their mouth and at the same time you get something in return, like an operating system. You're the customer. In Open Source you're an active user, taking and contributing at the same time. 

>While the band is playing at certain point some of the visitors start shouting 

You're comparing apples with oranges. In Open Source there are active participants only. It doesn't matter how they are contributing, it's important that they do something. If you're living as a passive consumer then Open Source is surely the wrong place to stay.


----------



## gordon@ (Mar 9, 2011)

dbi said:
			
		

> "We want this and we want that" is a necessary feedback and it is a good thing. Don't discourage people from it.



What I would like to discourage is the tone of the original post. It's whiny and degrading to the people who put a lot of volunteer effort into the FreeBSD project:



			
				vermaden said:
			
		

> One thing that is pretty shitty about FreeBSD....



Gee, doesn't that phrasing make me feel like I'm encouraged to keep working on the project when I have users like this.

Seriously, please show some respect. Ask questions and tell us you'd like more frequent updates to existing release lines. I love having an engaged user base, but you need to do it with respect and maturity. Both are qualities that are lacking in the original post.

And just in case, I'd like to point out that these are my views. While I am a developer with commit privileges, this is my opinion; I don't speak for the Project, Foundation, or anyone other than myself.


----------

