4 ms·

That is not an opinion based on any marketing material - 389DS is an unreliable dog, and even today it's still built on top of an Oracle-owned database engine.

by _wmd 8y ago

That is not an opinion based on any marketing material - 389DS is an unreliable dog, and even today it's still built on top of an Oracle-owned database engine. There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all, they have been the exclusive maintainers for OpenLDAP for many, many years, and it is of course the exact same model used for 389 DS. Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any.

amyjess 8y ago
> There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all That's not what I'm saying. I'm saying that one shouldn't take their criticisms of a competitor's product seriously when they are selling their own product in the press release itself. It's a conflict of interest.
Twirrim 8y ago
> That is not an opinion based on any marketing material ... >they have been the exclusive maintainers for OpenLDAP for many, many years, I think your critical source analysis skills might need some brushing off.
MattSteelblade 8y ago
Let's break this down as an external party that uses neither products: > "That is not an opinion based on any marketing material - 389DS is an unreliable dog" The press statement you linked to reads as an advertisement. You posit a statement as fact without any information to back it up. Why is it so unreliable? > "and even today it's still built on top of an Oracle-owned database engine." Whether the product is built on an Oracle-owned database engine or not, is not a reflection of the stability of a product. It's clear that you mention this as a negative to reinforce your position, but while technically correct, looking through the history of the product, it was developed by Sun and acquired by Red Hat in 2005, years before Sun was acquired by Oracle. > "There is no need to attack Symas" @amyjess's comment simply declared your linked article as biased, which it clearly is. This is not an attack. > "Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any." Why do we have to assume the product is broken and find proof that it is not? You have posited an opinion without any sources to back it up; the burden of proof lies with you. (Edited for formatting changes)
- _wmd 8y ago
  You make a fair point, it is hard to read as a bystander. However I disagree the burden of proof lies with me. I'm not here to convince you of anything, if you want to be sure of something, you must put the effort in like everyone else. Despite that.. Just focusing on storage backends - if you have ever deployed anything that uses BDB (Subversion, Apache, 389, Exim, god knows how many more), one thing you'll become quickly familiar with is it's amazing ability to randomly get into an unusable state, despite an otherwise healthy and unrebooted machine, despite no administrative interference, despite apparently no users or no load at all (e.g. on a Monday morning in a ~10 user office). My opinions are based on having worked in infrastructure since ~2002, having deployed BDB many times, and having spent many hours trying to figure out how to get an app unbricked without losing its underlying database. I spent time as an administrator at several companies where Subversion would go down monthly or worse because BDB locking would get messed up like this, and the result is always yet another tarball of the previous database just in case poking it completely corrupts the install. I've had to handle emergency calls because Exim was spewing permanent errors to customers due to a BDB lookup randomly starting to fail. In other words over the years, like many before me, and for very good reasons, I've come to consider BDB a red flag, and where it goes trouble goes. Put in simpler terms, on a scale of software quality running from 10 ("excellent") to 0 ("crapware"), BDB sits somewhere around -7 ("you had one job"). But don't take my word for it, look at the list of common hazards listed here: https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/debug/common.html https://web.stanford.edu/class/cs276a/projects/docs/berkeley... Despite that, having deployed OpenLDAP and suffered through its.. suffering.. documentation on several occasions going back ~15 years, including during periods when BDB was the default, post installation I have never once seen OpenLDAP going down. It's very solid software, in spite of prior database engine hindrances. LMDB is of course no panacea, but having spent years with it as a developer (and maintainer of py-lmdb), I can say categorically that I would not pick BDB over it in any situation, not just due to performance concerns (which are great), but because the design is so damned simple (a single write lock, a single lock file) that I have never once seen it self-corrupt or get wedged in ways that I would have struggled to deal with in my time served an administrator.
  - dboreham 8y ago

by _wmd 8y ago

amyjess 8y ago

> There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all That's not what I'm saying. I'm saying that one shouldn't take their criticisms of a competitor's product seriously when they are selling their own product in the press release itself. It's a conflict of interest.

Twirrim 8y ago

> That is not an opinion based on any marketing material ... >they have been the exclusive maintainers for OpenLDAP for many, many years, I think your critical source analysis skills might need some brushing off.

MattSteelblade 8y ago

Let's break this down as an external party that uses neither products: > "That is not an opinion based on any marketing material - 389DS is an unreliable dog" The press statement you linked to reads as an advertisement. You posit a statement as fact without any information to back it up. Why is it so unreliable? > "and even today it's still built on top of an Oracle-owned database engine." Whether the product is built on an Oracle-owned database engine or not, is not a reflection of the stability of a product. It's clear that you mention this as a negative to reinforce your position, but while technically correct, looking through the history of the product, it was developed by Sun and acquired by Red Hat in 2005, years before Sun was acquired by Oracle. > "There is no need to attack Symas" @amyjess's comment simply declared your linked article as biased, which it clearly is. This is not an attack. > "Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any." Why do we have to assume the product is broken and find proof that it is not? You have posited an opinion without any sources to back it up; the burden of proof lies with you. (Edited for formatting changes)

_wmd 8y ago
You make a fair point, it is hard to read as a bystander. However I disagree the burden of proof lies with me. I'm not here to convince you of anything, if you want to be sure of something, you must put the effort in like everyone else. Despite that.. Just focusing on storage backends - if you have ever deployed anything that uses BDB (Subversion, Apache, 389, Exim, god knows how many more), one thing you'll become quickly familiar with is it's amazing ability to randomly get into an unusable state, despite an otherwise healthy and unrebooted machine, despite no administrative interference, despite apparently no users or no load at all (e.g. on a Monday morning in a ~10 user office). My opinions are based on having worked in infrastructure since ~2002, having deployed BDB many times, and having spent many hours trying to figure out how to get an app unbricked without losing its underlying database. I spent time as an administrator at several companies where Subversion would go down monthly or worse because BDB locking would get messed up like this, and the result is always yet another tarball of the previous database just in case poking it completely corrupts the install. I've had to handle emergency calls because Exim was spewing permanent errors to customers due to a BDB lookup randomly starting to fail. In other words over the years, like many before me, and for very good reasons, I've come to consider BDB a red flag, and where it goes trouble goes. Put in simpler terms, on a scale of software quality running from 10 ("excellent") to 0 ("crapware"), BDB sits somewhere around -7 ("you had one job"). But don't take my word for it, look at the list of common hazards listed here: https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/debug/common.html https://web.stanford.edu/class/cs276a/projects/docs/berkeley... Despite that, having deployed OpenLDAP and suffered through its.. suffering.. documentation on several occasions going back ~15 years, including during periods when BDB was the default, post installation I have never once seen OpenLDAP going down. It's very solid software, in spite of prior database engine hindrances. LMDB is of course no panacea, but having spent years with it as a developer (and maintainer of py-lmdb), I can say categorically that I would not pick BDB over it in any situation, not just due to performance concerns (which are great), but because the design is so damned simple (a single write lock, a single lock file) that I have never once seen it self-corrupt or get wedged in ways that I would have struggled to deal with in my time served an administrator.
- dboreham 8y ago