Date: Fri, 06 Jan 2006 13:27:18 +0100 From: Marian Hettwer <MH@kernel32.de> 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: <43BE6226.5000103@kernel32.de> In-Reply-To: <20060106112329.GG54324@svcolo.com> References: <43A266E5.3080103@samsco.org> <200512231136.12471.doconnor@gsoft.com.au> <20060105092448.GH1358@svcolo.com> <200601061120.14707.doconnor@gsoft.com.au> <20060106112329.GG54324@svcolo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi there, Jo Rhett wrote: > On Fri, Jan 06, 2006 at 11:20:13AM +1030, Daniel O'Connor wrote: >> >>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) > I'm actually wondering how yahoo for instance handles this situation. To my knowledge, they have several thousand of FreeBSD based servers. Either they are all the same in regards to configuration and version, or they have some other cunning way to solve the issue of patching. > > 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. > Generally speaking: Your statement is true. You don't start writing code without an agreement that the direction choosen is a direction where FreeBSD wants to evolve. However, you (as in, you as a developer) could come up with a proof of concept. Start with an implementation like you would like to have it. And even if it's just a piece of paper and some code. Then start this thread over again, fine tune the concept and hopefully some others will jump aboard and help developing. I would like to, but I do lack knowledge in C. Shell and a wee bit of Perl is fine. Definitly too few knowledge for a project like that :-/ > >>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. > That statement ain't true. If the code solves your problem, fine. If it solves problems of others too, even better. Chances are higher that it doesn't get ignored... regards, Marian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43BE6226.5000103>