Re: what's next for the linux kernel?
From: Howard Chu (hyc_at_symas.com)
Date: 10/07/05
- Previous message: Joe Bob Spamtest: "Re: what's next for the linux kernel?"
- In reply to: Luke Kenneth Casson Leighton: "Re: what's next for the linux kernel?"
- Next in thread: Helge Hafting: "Re: what's next for the linux kernel?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 06 Oct 2005 18:05:18 -0700 To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Luke Kenneth Casson Leighton wrote:
>
> ... but heck - we do configuration of pretty much every major service
> under the sun out of ldap, don't we?
>
> and openldap itself just got the ability to read its own
> config out of its own database, right?
>
> it's not _that_ far off, not _that_ unachievable, s/ldap/registry.
I think both you and Michael have interesting points on this topic. Fyi,
OpenLDAP now has dynamic config (accessible/modifiable via LDAP) but the
backing store is still a bunch of flat files. There were two objectives
here - (1) make every knob tunable via LDAP, and (2) don't prevent an
admin from fixing things with vi if they have to. I've spent too many
times rescuing systems in single-user mode with only /bin/sh, to ever
commit to using a binary config database.
Yes, KISS is a good policy, you just have to understand what the 'It' is
that you're talking about in each instance. Putting a filesystem driver
on top of a registry.dat file seems to provide a simple user interface,
so it *looks* like you're adhering to KISS, but the innards are still
both complex and fragile. Hell, even the simplest filesystem driver you
can write is a couple hundred lines of code.
The LDAP-enabled config engine in OpenLDAP looks more structured / more
complex than the old flat slapd.conf file, but under the covers it's all
still plain text. In one case, you're taking something very complex and
putting a simple cover on it, in the other you have very simple building
blocks and put a complex / richer interface on top of it. Guess which
design is more likely to keep functioning in the face of a system failure.
The Unix programming philosophy is about taking small simple tools and
combining them to perform more complex tasks. You could say it's one of
the world's earliest object-oriented UIs. If you don't keep that in
mind, and try to build complexity in starting at your most basic
building blocks on the bottom (i.e., the kernel) then you're going to
have a nightmare trying to keep anything you build on top of it working.
One only need look at MS Windows to see how true this is.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Joe Bob Spamtest: "Re: what's next for the linux kernel?"
- In reply to: Luke Kenneth Casson Leighton: "Re: what's next for the linux kernel?"
- Next in thread: Helge Hafting: "Re: what's next for the linux kernel?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
