Re: ten thousand small processes

From: Pedram Nimreezi (Support_at_Netflag.Net)
Date: 06/27/03

  • Next message: D. J. Bernstein: "Re: The dangers of replacing malloc()" 
    Date: Fri, 27 Jun 2003 09:32:13 -0700
To: Bakul Shah <bakul@bitblocks.com>, "D. J. Bernstein" <djb@cr.yp.to>

             Far be it for me to disregard anything Professor Bernstein suggests
    but Bakul does have an extremely good point and I feel that just as
    you proved BIND wrong in many ways with the advent of DJBDNS.
    So you should in proving this point which seems to of been the cause
    of an almost outrageous malloc and memory argument.
             I would also agree with Mr. Mini, I love saying that, that maybe
    the profoundness of your concepts are mitigated by this University-like
    language which you fail to realize some of the best coders in the world
    do not understand, like the Portuguese for instance. I have a friend named
    Manuel (Whose rather famous in the PHP community and whose last name
    I won't divulge), that even though his programming is very robust his error
    messages
    show that his English is rather poor. I feel that even though this is an
    English
    speaking mailing list it does give me much joy watching the elites of
    computer science
    bicker to no end. The rest of the world should be able to enjoy this free
    spectacle as well.
    I think I lost my point just there.. but here's a simple if not rhetoric
    suggestion that will
    undoubtedly cause me more boredom... and that is: More consensus less cursing.

    At 09:12 AM 6/27/2003 -0700, Bakul Shah wrote:
    > > > Instead of complaining about wasting 78 megabytes and arguing
    > > > about why various proposed solutions fall short and why your
    > > > way is the best, why don't you come up with a patch that
    > > > saves space for small programs?
    > >
    > > Funny. Seems to me that I keep making concrete suggestions---including a
    > > detailed proposal for giving more space to malloc()---and the answer is
    > > consistently ``We really don't care about per-process overhead.'' What's
    > > the benefit of a patch for people who don't even see the problem?
    >
    >If after repeated suggestions people are not "getting it",
    >the reason is usually *not* apathy. Either you are not
    >explaining well or your starting assumptions are different.
    >But show me the code! If I like it I'll use it. "Build it
    >and they will come" -- you should be familiar with that! If
    >enough people like it, may be it will get incorporated in
    >some form. May be.
    >_______________________________________________
    >freebsd-performance@freebsd.org mailing list
    >http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    >To unsubscribe, send any mail to
    >"freebsd-performance-unsubscribe@freebsd.org"

    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"

  • Next message: D. J. Bernstein: "Re: The dangers of replacing malloc()"

    Relevant Pages

    • Re: What version of BSD should I use
      ... Well, but what about djbdns? ... Is it fully compatible with BIND? ... Peter Rosa ... To unsubscribe, ...
      (freebsd-questions)
    • RE: Bind 9 answer limit question
      ... give him a rousing RTFM. ... I did look for this answer in the bind docs before posting. ... While I'm not completely opposed to switching to djbdns, ... To unsubscribe, ...
      (freebsd-questions)
    • Re: Re[2]: Verisign fun.
      ... > I just did the same, and I am pretty happy with djbdns. ... Patches also ... If your query volume gets high enough, ... To unsubscribe, ...
      (freebsd-isp)