From owner-freebsd-hackers Mon Jan 5 20:49:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA29427 for hackers-outgoing; Mon, 5 Jan 1998 20:49:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA29378 for ; Mon, 5 Jan 1998 20:48:49 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 13532 invoked by uid 1000); 6 Jan 1998 04:46:27 -0000 Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801051923.MAA27274@usr08.primenet.com> Date: Mon, 05 Jan 1998 20:46:27 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Terry Lambert Subject: Re: Informix on FreeBSD (maybe) (fwd) Cc: AdamT@smginc.com, freebsd@atipa.com, freebsd-hackers@FreeBSD.ORG, freebsd@core.acroal.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On 05-Jan-98 Terry Lambert wrote: >> IMJO, enormous amount of work. In my work, we just add some clearly >> defined subsystems to an existing product and it represents several >> engineering years of effort. There is really no need to do all that, I >> think; There is a pretty good engine out there that is lacking in >> specific >> areas which we are already addressing. There may be others. Were there >> enough interest in our work, we could generalize it so other RDBMS >> engines >> could enjoy the benefits too. Doing the reverse is very tricky; O/S >> specific changes are inherently non-portable (TerrY?). But we are >> trying >> to be as clean as we can. > > Sometimes it's worth it. If, for example, FreeBSD could export an > FS-level transactioning subsystem for use by a database (say from > a general implementation of soft updates using an event/handler > based architecture), then there would be such significant performance > wins that you'd have to be an idiot to not go for it. I tried to raise interest in doing some of this work in FreeBSD and met (almost) zero interest. I am not paricularly interested in cloning any particular database engine. I find most of them boringly similar in user features. I think that building certain facilities into an O/S that can be easily be used by database engines (with little regard to topology of the DBS) is useful. To this end I have built an in-kernel Distributed Lock Manager that is simple and easy to use and am working on developing a simple in-kernel Distributed Storage Manager than will allow DBMS developers to use a secure, transaction oriented, distributed storage medium. This is, in many cases, half the battle. > On the other hand, you're right: making something OS specific (or > even compiler technology specific) is inherently bad, mostly because > self-limiting portability self-limits the scope of the projects > relevance. WINE is a good example here: it's not WIN32, and it's > Intel-centric, so you don't get the hot guns from the Intel camp, or > any guns at all from the non-Intel camps. > > If he were truly going to clone a commercial product (preferrably, > an associative database), then there's a good chance that depending > on FreeBSD features would cause those features to migrate into > other OS's. > > Personally, I wouldn't do a clone unless (1) it was an associative > database, not a relational one, like IBM's FOCUS or RAIMA's dbVista, > and (2) There were mature OS features that, as part of my agenda, I > wanted migrated into other OS's. > > Most clone work is not worth doing unless it raises the bar across > the board. Clone work is, IMO, a tool for raising bars, and not > a useful end in and of itself. > > FreeBSD is clone work, and it's useful because it can be used by > commercial vendors. You can raise the bar for everyone, not just > those willing to give away their code under the GPL. That's why > I do FreeBSD and not Linux: Linux can raise bars as well, but the > cost of using the code commercially is too high for it to be an > effective method of encouraging across-the-board progress. Even > so, FreeBSD is frequently too conservative (read: slow to adopt > new technology) for my tastes... but at least it's faster than USL. Terry, I'll build the storage manager if you build the DBMS. Deal? :-) Simon