[Date Prev][Date Next]
Re: max open files
В Чтв, 18/03/2010 в 12:10 -0700, Howard Chu пишет:
> Alex McKenzie wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > Right. But how much do I pay for Apache? How much do I pay for
> > postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The
> > real issue, for me, is the version cycle. All of those packages have
> > minor updates fairly regularly, but none of them change major
> > functionality, and all of them provide packages to various linux
> > distributions, including Debian and Ubuntu. And most of them have
> > decent free support, at least via the sort of mailing list we're on now,
> > that includes those distribution packages. They may well tell you you
> > need to install the newest debian package, but they'll almost never tell
> > you that you have to recompile for basic functionality.
> Most of those projects just release source code, like us. The packages you see
> on various distros are built by the distro packagers, not by the upstream
> We'd be happy to tell you to install the newest debian package, if it was ever
> new enough. Because it usually isn't, you usually need to recompile. How is
> this any different from any other software?
> There haven't been any major changes to existing functionality in a couple of
> years now. Remember, in the X.Y.Z version number, the Z is just a patchlevel.
> If you say "I hit thus-and-such bug in version X.Y.Z" and we say "that's fixed
> in X.Y.Z+10" and you don't want to sync up with that patch, that's your decision.
This is probably an issue. If I'm correct Debian policy prevent version
upgrade, say, if Lenny have 2.4.11 version, they can't put 2.4.17 in it.
Instead, they can backport some patches from 2.4.17 back to 2.4.11 and
make it 2.4.11-1+lenny1. "they" mean maintainers. On Debian there are a
number of them, there is also a list which doesn't seem dead:
So, maybe a correct solution for this situation is to figure out what
patch solves given issue and ask maintainers to backport it. Or maybe
just file a bug on Debian.
> > Again: this is a decision the development team made. It's not because
> > it's free, it's because they chose one particular mode of development.
> "Release early, release often." That's the most viable way forward for an open
> source project. I'd say our release frequency has been too slow, really.
> > I'm not saying it's wrong, necessarily, but it drives a lot of people --
> > like me -- to look for alternatives. Right now, the system pretty much
> > works, despite the fact that I'm using and older version
> > (2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list
> > with a problem, I'll be told no one can help me unless I rebuild from
> > scratch.
> > So far, it's been easier to ... look for
> > help in the Ubuntu forums.
> As it should be. If you're running a package from a distro vendor, then you
> should be consuming their support resources, not ours. We don't know what all
> the distro packagers do, what options they use, what libraries they include.
> Some of them ship explicitly broken packages, despite our best efforts. (E.g.,
> RedHat/CentOS, linking against Berkeley DB 4.3 when we know for a fact that
> this combination crashes, and have explicitly prevented using BDB 4.3 in our
> configure script.) If you have a problem with binaries from a distro packager,
> that's their responsibility, and we can't help you work past their mistakes
> unless you recompile the source and build it properly.
> > You're right that I don't need to keep rebuilding as new versions come
> > out, but that's only as long as I don't want to ask for help: if I need
> > to change how something works, or add functionality, even if it's
> > present in the version I have installed, I have to upgrade.
> > Anyway: this is really all pretty much irrelevant to the list as a
> > whole. I just wanted to make the point that this is an issue, and
> > perhaps something the devels should think about. If they decide to
> > continue on the way they have... well, that's their option. It's their
> > project, and they can do what they want with it. But they should at
> > least be aware that people are concerned about the current methods.
> Your concerns are noted. But IMO they are misdirected. If your distro packager
> can't keep you up to date then that's an issue for you and them to deal with.
> > - -Alex
> > Kenneth Marshall wrote:
> >> Hi Alex,
> >> I think this falls into the "you get what you pay for..." camp.
> >> On the support page, they list a number of companies that provide
> >> technical support services for OpenLDAP. If the price for stability
> >> is not worth engaging one of them, then you will need to keep your
> >> software up to a revision level that the developers will support.
> >> I am curious what constant issues/bugs are affecting you. Once we
> >> have a working version, it keeps on working and there is no need
> >> to constantly rebuild your software as new releases come out. The
> >> other option that we use here is the 389 Directory server, which
> >> might be an option for you to consider.
> >> Regards,
> >> Ken
> >> On Thu, Mar 18, 2010 at 08:46:38AM -0400, Alex McKenzie wrote:
> >> I'll be honest: while LDAP does what I need it to, and is the only tool
> >> I've found that works well for my purposes, this is why I'm constantly
> >> looking for another option. Just about every request for help I see
> >> come across this list gets an initial response of "Oh, well, you're one
> >> or two minor versions out of date. You need to update to the newest
> >> version before we can help you."
> >> Software that unstable is not, in my view, really suited to a production
> >> environment. If the OpenLDAP developers -- who, overall, do an
> >> excellent job -- can't come up with a stable release every six months or
> >> so, there's a problem. If there are so many major flaws that running a
> >> month old version means it's unsupportable, that's an even bigger problem.
> >> I've been following the list for around a year, and I understand the
> >> difficulties involved in supporting old versions, but the simple fact
> >> is, most of us don't have time to custom compile all our server
> >> software. My Ubuntu-default installs of Apache, postfix, SSH, and just
> >> about everything else work fine and can be supported by their
> >> developers. It's only LDAP (and a few things in beta) that absolutely
> >> have to run the newest version at all times. I chose to accept a
> >> limited feature-set and bullied GnuTLS into working "well enough" for
> >> our limited LDAP environment, but if I ever find an alternative, I'll be
> >> moving away from LDAP to whatever that is.
> >> And please -- nobody take this as an attack. I really do respect the
> >> OpenLDAP development team, and the people on this list do their best to
> >> help everyone, even those of us using old versions. I just question the
> >> long-term viability of a system that needs to be recompiled as often as
> >> OpenLDAP seems to.
> >> -Alex McKenzie
> >> Quanah Gibson-Mount wrote:
> >>>>> --On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
> >>>>> <firstname.lastname@example.org> wrote:
> >>>>>> Well, IMHO this is a really bad excuse and I was not expecting to hear
> >>>>>> that in this list.
> >>>>>> Klements,
> >>>>>> You can get slapd source packages and change the flags as you want.
> >>>>>> Serious distribution packages as Debian packages shouldn't
> >>>>>> be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
> >>>>>> policy are very strong and help a lot stable environments to be bug-free
> >>>>>> from recent less stable versions. I use Debian as a protection from that
> >>>>>> too early versions who can potentially threat my production environment
> >>>>>> and I was very successful with Debian packages in this attempt.
> >>>>>> You can also look for support on Debian IRC channels and lists.
> >>>>> Hi Matheus,
> >>>>> I'll note that article was written by one of the Debian openldap package
> >>>>> maintainers. And it is quite correct that anyone wanting to run a
> >>>>> *stable* OpenLDAP production environment should most definitely *not*
> >>>>> use the ones provided by most Linux OS providers, *particularly*
> >>>>> Debian/Ubuntu. The reasons why this is the case have been hashed over
> >>>>> many, many times. Particularly, the use of GnuTLS which is horribly
> >>>>> broken being one of the major reasons. The fact that they are not kept
> >>>>> up to date with current stable releases is another.
> >>>>> --Quanah
> >>>>> --
> >>>>> Quanah Gibson-Mount
> >>>>> Principal Software Engineer
> >>>>> Zimbra, Inc
> >>>>> --------------------
> >>>>> Zimbra :: the leader in open source messaging and collaboration
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
Покотиленко Костик <email@example.com>