Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
O
OpenLDAP
Manage
Activity
Members
Labels
Plan
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Container registry
Model registry
Operate
Environments
Terraform modules
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Christopher Ng
OpenLDAP
Commits
6f43879a
Commit
6f43879a
authored
17 years ago
by
Howard Chu
Browse files
Options
Downloads
Patches
Plain Diff
Trim some puffery, note back-ldbm
parent
170ea9c3
Branches
Branches containing commit
Tags
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/guide/admin/appendix-changes.sdf
+11
-5
11 additions, 5 deletions
doc/guide/admin/appendix-changes.sdf
with
11 additions
and
5 deletions
doc/guide/admin/appendix-changes.sdf
+
11
−
5
View file @
6f43879a
...
...
@@ -145,10 +145,6 @@ processing time is almost invisible; the runtime is limited only by the memory
bandwidth of the machine. (The search data rate corresponds to about 3.5GB/sec;
the memory bandwidth on the machine is only about 4GB/sec due to ECC and register latency.)
No other Directory Server in the world is this fast or this efficient. Couple
that with the scalability, manageability, flexibility, and just the sheer
know-how behind this software, and nothing else is even remotely comparable.
H3: New overlays
* slapo-dds (Dynamic Directory Services, RFC 2589)
...
...
@@ -181,9 +177,19 @@ H3: New build options
* Advertisement of LDAP server in DNS
H2: Obsolete Features
in
2.4
H2: Obsolete Features
Removed From
2.4
H3: Slurpd
Please read the {{SECT:Replication}} section as to why this is no longer in
OpenLDAP
H3: back-ldbm
back-ldbm was both slow and unreliable. Its byzantine indexing code was
prone to spontaneous corruption, as were the underlying database libraries
that were commonly used (e.g. GDBM or NDBM). back-bdb and back-hdb are
superior in every aspect, with simplified indexing to avoid index corruption,
fine-grained locking for greater concurrency, hierarchical caching for
greater performance, streamlined on-disk format for greater efficiency
and portability, and full transaction support for greater reliability.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment