Date: Fri, 16 Feb 2007 19:02:50 -0500 From: Kris Kennaway <kris@obsecurity.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: doc-committers@FreeBSD.org, Joel Dahl <joel@FreeBSD.org>, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: www/en/projects/ideas index.sgml Message-ID: <20070217000250.GA84945@xor.obsecurity.org> In-Reply-To: <20070216234810.M73842@fledge.watson.org> References: <200702161712.l1GHCX81057433@repoman.freebsd.org> <20070216172621.GA80812@xor.obsecurity.org> <20070216234810.M73842@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 16, 2007 at 11:53:54PM +0000, Robert Watson wrote: > > On Fri, 16 Feb 2007, Kris Kennaway wrote: > > >On Fri, Feb 16, 2007 at 05:12:33PM +0000, Joel Dahl wrote: > >>joel 2007-02-16 17:12:32 UTC > >> > >> FreeBSD doc repository > >> > >> Modified files: > >> en/projects/ideas index.sgml > >> Log: > >> Spring cleaning in preparation for Google SoC 2007. Remove the > >> following > >> projects (based on discussions with netchild and rwatson): > > > >> - FPU subsystem overhaul: Not suitable as a Google SoC project. > >> - Process Checkpointing: Not suitable as a Google SoC project. > > > >Is this a "Google SoC projects list" or a "FreeBSD projects list"? IMO > >just because something is not an appropriate SoC project doesn't mean it's > >not suitable for someone more advanced to take on. > > The FPU subsystem overhaul port has already been done by Attilio and is > available as patches, I believe, and basically requires evaluation at this > point. That evaluation might be an appropriate project for someone to work > on (although not for SoC). > > I don't mind seeing process checkpointing on an overall project idea list, > but I think we should replace the text there with something substantially > more informative. There's a significant research literature on how you do > these sorts of things and I'm not sure we want to ask people to hack it up > without figuring out what it is we actually want out of such a project. > Otherwise, patches for something we don't want will turn up and leave > disappointment all around. In particular, there are countless reasons why > simply implementing "checkpointing" of processes in isolation is relatively > meaningless, and if required, probably best done with involvement of the > application rather than transparently in the OS. In a > clustered/distributed system, checkpointing provided by the OS is a far > more meaningful concept. If we're serious about wanting checkpointing, > let's have a session at the developer summit at BSDCan on what it is we > want and why, have a couple of people read into the research literature > here, and re-add a checkpointing project once we have something a bit more > directed to put up. OK, these two I didn't snip were just examples though; more generally I think my point holds :) Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070217000250.GA84945>