Date: Mon, 05 Jan 1998 20:46:27 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Terry Lambert <tlambert@primenet.com> Cc: AdamT@smginc.com, freebsd@atipa.com, freebsd-hackers@FreeBSD.ORG, freebsd@core.acroal.com Subject: Re: Informix on FreeBSD (maybe) (fwd) Message-ID: <XFMail.980105204627.shimon@simon-shapiro.org> In-Reply-To: <199801051923.MAA27274@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980105204627.shimon>