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

[cross post to -current removed]

On Thu, 5 Jan 2006 19:54, Jo Rhett wrote:
> On Fri, Dec 23, 2005 at 11:36:11AM +1030, Daniel O'Connor wrote:
> > On each 'client' PC..
> > NFS mount /usr/src and /usr/obj
> > installkernel
> > reboot
> > installworld
>
> Works fine on home computers behind firewalls.
>
> Useless on public servers that don't run RPC.
> Useless on flash-based servers where minimizing writes is necessary.
> 	(mergemaster does far far far too many writes)

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

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

> > You are putting words in the mouth of core_at_ -
>
> Sorry.  As said before, the topic is always struck down and nobody from
> core has ever stood up to say "we'll support this".  I don't know whose on
> core this week, nor will I at any given time.  I just know that core has
> either struck it down or been Silent.

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?

> A good binary update mechanism shouldn't be just the network.  Updates from
> flash devices, ISO images, etc should all work much the same way.

Absolutely.
In fact you could put /usr/src and /usr/obj on a CD/DVD/Flash drive and 
upgrade that way.

I would *welcome* a more sophisticated method for binary upgrades that was a 
lot smarter. I imagine pretty much everyone else would too.

> > Unless you mean "core_at_ said they would not support packaging the base"
> > which is different.
>
> People have clearly identified the problems that prevent a useful binary
> update mechanism from working, and what they need from core.  Some have
> asked for core packages, others have other ideas, and some have said
> "anything that gives me versioning ability" and

and..?

Anyway, so what? Nothing stops you writing such a system, 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.

> > This is not true - I don't see it as being mandatory to be able to apply
> > binary updates. (Case in point - freebsd-update works fine without it)
>
> 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..

> 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

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

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 :)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C