Re: Linuxconf
Raul Miller <rdm@test.legislate.com> wrote:
> rdm> Finally, before we even think about integrating an RDBMS into debian's
> rdm> core, we'd need to tackle the same issues Microsoft tackled when they
> rdm> "invented" ODBC from (invented is in quotes, because I'm told that
Anderson MacKay <iris@_domain_of_your_mail_address_> wrote:
> Not sure I follow you.
You need an abstraction layer between subsystems, or you're dooming
people who use our stuff to many nights of hair pulling.
> But if you want a simple (relatively) implementation of an RDBMS,
> there's always Python's Gadfly ... uses a single file for the whole
> database (IIRC), reasonably fast, only in memory, nice portability
> since it's in Python. Yes, you give it standard SQL. A further idea
> might be to use Linuxconf as a sort of lower-level driver, and have a
> Debian "configuration manager" at a higher level that's RDBMS-based
> ... I agree with Jules that it adds a -lot- of flexibility. However,
> you don't want to have more and more software required for system
> recovery, so why not have this hypothetical RDBMS-based system manage
> Linuxconf? (Some famous Comp. Sci person was once quoted with "Any
> problem in Computer Science can be solved by an additional layer of
> indirection." I concur. :) </lurk>
Ok, let's say we go with the python implementation. Now, let's say a
year or two from now some other sql implementation becomes significantly
better for some cases (mysql, postgress, gnu sql, k-lite, whatever). If
we haven't provided an abstraction barrier we'll spend longer untangling
the python dependencies than we did to put the system together in the
first place.
If you're saying you don't know why someone would want to switch,
another system may
(1) be more robust (or more stable)
(2) bne more efficient (time, memory, disk, whatever)
(3) have a better user interface (or better interfaces of other kinds)
(4) have better administrative controls (simpler, cleaner, ...)
(5) be important for some application (or desktop environment, or...)
(6) be more familiar (to the folks running the system, or to us)
(7) be more complete (complete database implementations cover a lot of ground)
Also, the primary advantage of sql is its portability. If you're going
with a system specific implementation, python is a far better language.
And so is perl. And so on... [This is why most sql performance tuning
requires you go outside of the sql -- yes, it's really clever that you
can specify an O(n^3) algorithm to compare adjacent values in a squence,
and it's even more clever that better implementations can automatically
recognize this case and provide a better algorithm, but that's not why
people choose SQL.]
Anyways, RDBMSes are one area where it's critical to tackle your
inteface issues up front. And system administration is an area
where minimalism is a virtue.
--
Raul
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: