Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Jan 1998 19:23:33 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        shimon@simon-shapiro.org
Cc:        freebsd@core.acroal.com, freebsd-hackers@FreeBSD.ORG, freebsd@atipa.com, AdamT@smginc.com
Subject:   Re: Informix on FreeBSD (maybe) (fwd)
Message-ID:  <199801051923.MAA27274@usr08.primenet.com>
In-Reply-To: <XFMail.980101145259.shimon@simon-shapiro.org> from "Simon Shapiro" at Jan 1, 98 02:52:59 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801051923.MAA27274>