From owner-freebsd-hackers Mon Jan 5 11:25:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA03077 for hackers-outgoing; Mon, 5 Jan 1998 11:25:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03023 for ; Mon, 5 Jan 1998 11:24:35 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA29242; Mon, 5 Jan 1998 12:23:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpd029187; Mon Jan 5 12:23:43 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA27274; Mon, 5 Jan 1998 12:23:33 -0700 (MST) From: Terry Lambert Message-Id: <199801051923.MAA27274@usr08.primenet.com> Subject: Re: Informix on FreeBSD (maybe) (fwd) To: shimon@simon-shapiro.org Date: Mon, 5 Jan 1998 19:23:33 +0000 (GMT) Cc: freebsd@core.acroal.com, freebsd-hackers@FreeBSD.ORG, freebsd@atipa.com, AdamT@smginc.com In-Reply-To: from "Simon Shapiro" at Jan 1, 98 02:52:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk > 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. 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 Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.