Date: Fri, 6 Jan 2006 03:23:29 -0800 From: Jo Rhett <jrhett@svcolo.com> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: freebsd-stable@freebsd.org, current <current@freebsd.org> Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) Message-ID: <20060106112329.GG54324@svcolo.com> In-Reply-To: <200601061120.14707.doconnor@gsoft.com.au> References: <43A266E5.3080103@samsco.org> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <200601061120.14707.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Agreed. > 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/bsdupdates.com 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 time. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060106112329.GG54324>