Fast releases demand binary updates.. (Was: Release schedule for 2006)

Jo Rhett jrhett at
Fri Jan 6 03:25:52 PST 2006

On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote:
> For NFS mount, read: any network file system. You can also use, say IPSEC to 
> protect the NFS packets (although I'm not claiming it's a trivial thing to 
> set up..)
IPsec is trivial compared to the amount of code and localized databases we
use to manage system versioning information today.

> As for restricting the number of writes - that is a totally separate issue and 
> isn't very relevant to this discussion.

> In general core IS silent.
> Core isn't some governing body that decides what happens in FreeBSD and plans 
> in detail what happens. You are showing a fundamental misunderstanding about 
> how FreeBSD "works".
> Also, you just said "... the topic is always struck down ..." - what do you 
> mean? Are you claiming someone from (or claiming to be from core) said "Don't 
> do this, we won't allow it"? If so, can you supply proof?
I used to write a lot of patches to freebsd.  I used to submit a lot of bug
reports.  I've found over the years that unless you have gotten
pre-agreement from others about the nature of the patch, or agreement to
focus on the problem, neither one amounts to a hill of beans.  Installation
problems that existed in 4.4 are still alive and well in the 6.0 installer,
for example.

How FreeBSD "works" is by getting someone in the core team to care about 
the issue.  No amount of problem reports, patches or code will generate 
even a millimeter of movement otherwise.

So yeah, I take Silence as a negative.  I've got zero experience to
demonstrate otherwise.  

> I would *welcome* a more sophisticated method for binary upgrades that was a 
> lot smarter. I imagine pretty much everyone else would too.
Really?  I'm about to give up again and bring it up next year.  It's become
the annual gonzo-thread that never generates anything.

> Anyway, so what? Nothing stops you writing such a system, 

Nothing stops me, but it will become useless without constant maintenance.
And core would have no obligation to consider the effects of their changes
on this.

> and I contend it 
> isn't necessary to version the base system, or package it specially to do 
> binary upgrades. Something similar to freebsd-update could do it.
I've already spelled out the problems here.  Freebsd-update/ 
spell out the problems with their approach in their documentation.  Many
others have written on this issue.

That said, if we can actually get a real conversation going about how to
handle this then I'd love to hear your input on how to solve all of the
problems we've raised without versioning of the core.
	--but not now, in this thread.  This thread appears to be DOA and
	I'm not going to keep wasting time on this without even a hint that 
	core would be interested in a solution to this problem.
	(not a blank check, just an expression of interest)

> > freebsd-update works "fine" if you run GENERIC with no build options.
> > Back to "useful for home computers".
> So, uhh, how would your magical binary upgrade system handle custom kernels?
> Why would it be any different? You still haven't explained how this would 
> work..
Versioning of the core package would tell you WHAT you have with a query.
It's trivial to then install the matching patches.  Right now every
enterprise has to build a backend database tracking core os, installed
options, compile options, etc for every single installed system.  Or build
a checksum database that can be used to derive this information from the
system (if all systems have the CPU/RAM to spare to play this game)

> > freebsd-update is hampered by the exact problems I'm listing here.
> > Difficulty determining "what I have", no method to store "what I did" and
> > no effective backout mechanism to speak of.
> Then feel free to expand on it.
> This IS an open source project - you can see how everything is written, if you 
> want to improve it
I would be happy to write code.  See my other messages about "waste of time".
Without a comittment to the idea from someone with commit access, writing
patches or new code just sits in PRs and dies of old age.

> > Nobody that I know cares whether or not the solution manifests as core os
> > packages, but some sort of core versioning ability has to be developed and
> > supported by the core.
> I don't think core is really very relevant here - core is there to mostly 
> settle disputes. The way forward is to achieve consensus and have working 
> solutions.
Sorry, I was mixing my uses of 'core' here.  My bad.

The "unpackaged" part of freebsd needs some sort of versioning ability.

But yes, you are making my point for me.  Without core's agreement that
this is a worthwhile project (as in: to be considered - not a blank check)
no amount of code will ever amount to anything other than another
unsupported freebsd-update style project.

We need support from the freebsd core developers that this is a worthwhile
idea, and what kind of solutions would be acceptable to them.  Once we have
a direction to go in, code can be written.

> If you supply a working framework then I think you'll find a lot of support 
> materialises. The problem is when you are just proposing vapourware solutions 
> everyone steps in and wants it done their way.
> Code speaks louder than words :)

I've written far too much code for various freebsd problems, and it has
always been ignored.  Not rejected, ignored.  Unless someone with commit
rights thinks it's a good idea, writing code for freebsd is a waste of

Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation

More information about the freebsd-stable mailing list