auth, account and session modules all run in the same address
> space. These would break until re-architected to pass things explicitly,
> e.g. via environment variables, temp files, etc.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun h
Scott Kitterman wrote:
On Saturday, July 06, 2013 01:52:59 PM Howard Chu wrote:
Florian Weimer wrote:
* Howard Chu:
LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of
source, there's nowhere to hide any tricks anyway.)
Okay, I found a snag: the 511 bytes limit on the key
to publish the source code, by virtue of the fact that giving the modified
code to Company A is distributing it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Paul Tagliamonte wrote:
On Thu, Jul 11, 2013 at 12:19:47PM -0700, Howard Chu wrote:
Right, I want to understand AGPL's motivations is all.
I used to put similar terms on my code, back before the GPL existed.
Essentially: If you modify this code, you must send your
modifications back to me
Steve Langasek wrote:
On Thu, Jul 11, 2013 at 12:53:01PM -0700, Howard Chu wrote:
Sure, but that doesn't make it DFSG free (hint: it's likely not)[1][2]
[1]: The Dissident test
[2]: The Desert Island test
Sure, but #2 is stupid. We didn't say must send changes back
immediately. Nor would
government, then complying
with a license that can only be enforced by a government agency is probably
the least of your worries.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http
Florian Weimer wrote:
* Howard Chu:
LMDB doesn't need dirty tricks to look good. (And at only 6KLOCs of
source, there's nowhere to hide any tricks anyway.)
Okay, I found a snag: the 511 bytes limit on the key size. Berkeley
DB's disk format does not impose a limit on key or value size
suitable than MDB, but so far I haven't seen it.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
To UNSUBSCRIBE, email to debian-devel-requ
/003009.html
We're well into the 2nd decade of the 21st century. These problems shouldn't
exist any more.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project
Florian Weimer wrote:
* Howard Chu:
We can provide plenty more documentation on LMDB performance and
reliability if desired.
Can you cope with incompletely written pages (e.g., only the first 512
bytes of a page is written) or write reordering between fsyncs?
Berkeley DB doesn't deal
Florian Weimer wrote:
* Howard Chu:
We require that fsync() (actually fdatasync()) doesn't lie. Data pages
can be written in any order, as long as all outstanding data pages are
actually written by the time fsync returns. Given this constraint, you
can pull the power on a drive and the DB
Steve Langasek wrote:
On Tue, Jul 02, 2013 at 12:38:24PM -0700, Howard Chu wrote:
Don Armstrong wrote:
On Tue, 02 Jul 2013, Tollef Fog Heen wrote:
Automatic processes overwrite explicit admin setups.
If /etc/resolv.conf is a symlink to somewhere else, then it's
appropriate for automatic
Arthur de Jong wrote:
Hello list (I've put a couple of people in Bcc to try to get more
feedback),
I'm working on integrating a PAM module into nss-ldapd and am looking
for input on this. The PAM module was kindly provided by Howard Chu from
the OpenLDAP project but I'm still working
13 matches
Mail list logo
