4 ms·

That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP

That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". It is simply one company attacking a competitor's product. And of course the article contains direct links to both a page where you can buy support packages for OpenLDAP and something called "OpenLDAP Gold".

reqa 8y ago
To clarify for others: You are talking about Symas. Univention is a Linux distributor that builds their products based on Debian and is in no way related to Symas. See e.g. https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer https://wiki.debian.org/Derivatives/Census/UniventionCorpora...
_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.
gargravarr 8y ago
I agree with the bias aspect, as soon as they mentioned Univention I realised it was a sales pitch. Feels like ambulance-chasing!
ti_ranger 8y ago
> That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". The article says: "This is a guest post from Univention." Howard Chu's company is Symas, not Univention (a different consulting company who does provide support contracts for open-source software including OpenLDAP). Yes, there is a link to a blog post by Symas that relates to the announcement, but not in the article being discussed here. If you meant the Symas blog post, you should be more clear on that.
- amyjess 8y ago
  I was directly replying to a comment that linked the Symas post and recommended it over OP's article. I don't think I could've been more clear.
  - reqa 8y ago
    Ok, thanks for clarifying your comment!

reqa 8y ago

To clarify for others: You are talking about Symas. Univention is a Linux distributor that builds their products based on Debian and is in no way related to Symas. See e.g. https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer https://wiki.debian.org/Derivatives/Census/UniventionCorpora...

_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.

gargravarr 8y ago

I agree with the bias aspect, as soon as they mentioned Univention I realised it was a sales pitch. Feels like ambulance-chasing!

ti_ranger 8y ago

> That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". The article says: "This is a guest post from Univention." Howard Chu's company is Symas, not Univention (a different consulting company who does provide support contracts for open-source software including OpenLDAP). Yes, there is a link to a blog post by Symas that relates to the announcement, but not in the article being discussed here. If you meant the Symas blog post, you should be more clear on that.

amyjess 8y ago
I was directly replying to a comment that linked the Symas post and recommended it over OP's article. I don't think I could've been more clear.
- reqa 8y ago
  Ok, thanks for clarifying your comment!