Date: Fri, 6 Jan 2006 11:20:13 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Jo Rhett <jrhett@svcolo.com> Cc: freebsd-stable@freebsd.org, current <current@freebsd.org> Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) Message-ID: <200601061120.14707.doconnor@gsoft.com.au> In-Reply-To: <20060105092448.GH1358@svcolo.com> References: <43A266E5.3080103@samsco.org> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1266678.4ed0llI9s7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [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) =46or NFS mount, read: any network file system. You can also use, say IPSEC= to=20 protect the NFS packets (although I'm not claiming it's a trivial thing to= =20 set up..) As for restricting the number of writes - that is a totally separate issue = and=20 isn't very relevant to this discussion. > > You are putting words in the mouth of core@ - > > 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 pla= ns=20 in detail what happens. You are showing a fundamental misunderstanding abou= t=20 how FreeBSD "works". Also, you just said "... the topic is always struck down ..." - what do you= =20 mean? Are you claiming someone from (or claiming to be from core) said "Don= 't=20 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 fr= om > 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=20 upgrade that way. I would *welcome* a more sophisticated method for binary upgrades that was = a=20 lot smarter. I imagine pretty much everyone else would too. > > Unless you mean "core@ 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= =20 isn't necessary to version the base system, or package it specially to do=20 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=20 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=20 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=20 settle disputes. The way forward is to achieve consensus and have working=20 solutions. If you supply a working framework then I think you'll find a lot of support= =20 materialises. The problem is when you are just proposing vapourware solutio= ns=20 everyone steps in and wants it done their way. Code speaks louder than words :) =2D-=20 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 --nextPart1266678.4ed0llI9s7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDvb7G5ZPcIHs/zowRAnY0AJ9Ny5aDvmRhRlYzB9iVANDTHK0IbACfdG9f 8VJRrdpxZqqee85xpei2O3Y= =oKH9 -----END PGP SIGNATURE----- --nextPart1266678.4ed0llI9s7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601061120.14707.doconnor>