** Changed in: unity (Ubuntu) Importance: Medium => Critical -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/808109
Title: unity-panel-service crashed with SIGSEGV in g_value_peek_pointer() To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/808109/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs From [email protected] Wed Jul 20 10:56:45 2011 Return-path: <[email protected]> Envelope-to: [email protected] Delivery-date: Wed, 20 Jul 2011 10:56:45 -0700 Received: from exprod5mx201.postini.com ([64.18.0.60] helo=psmtp.com) by mail-archive.com with smtp (Exim 4.69) (envelope-from <[email protected]>) id 1Qjb0n-0003bw-JK for [email protected]; Wed, 20 Jul 2011 10:56:45 -0700 Received: from mail.ietf.org ([64.170.98.30]) by exprod5mx201.postini.com ([64.18.4.10]) with SMTP; Wed, 20 Jul 2011 17:56:45 GMT Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9121F8AA8; Wed, 20 Jul 2011 10:56:42 -0700 (PDT) X-Original-To: [email protected] Delivered-To: [email protected] Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7A21F8A97 for <[email protected]>; Wed, 20 Jul 2011 10:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L8K+zBrOmA6 for <[email protected]>; Wed, 20 Jul 2011 10:56:40 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:22]) by ietfa.amsl.com (Postfix) with ESMTP id E35A221F89C1 for <[email protected]>; Wed, 20 Jul 2011 10:56:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 2958932466F0; Wed, 20 Jul 2011 10:56:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-210.clppva.btas.verizon.net [71.161.50.210]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 5303D3228BD8; Wed, 20 Jul 2011 10:56:38 -0700 (PDT) Message-ID: <[email protected]> Date: Wed, 20 Jul 2011 13:56:29 -0400 From: "Joel M. Halpern" <[email protected]> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ronald Bonica <[email protected]> References: <[email protected]> <[email protected]> In-Reply-To: <[email protected]> Cc: "[email protected]" <[email protected]>, Noel Chiappa <[email protected]> Subject: Re: [lisp] Fwd: Anybody can participate in the IETF (Was: Why is IPv6 broken?) X-BeenThere: [email protected] X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:[email protected]?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/lisp> List-Post: <mailto:[email protected]> List-Help: <mailto:[email protected]?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:[email protected]?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: [email protected] Errors-To: [email protected] X-pstn-neptune: 92/87/0.95/90 X-pstn-levels: (S:99.90000/99.90000 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 ) X-pstn-settings: 4 (1.5000:1.5000) s cv gt3 gt2 gt1 r p m c X-pstn-addresses: from <[email protected]> [294/10] X-pstn-neptune-cave-rslt: pass Let me suggest a different phrasing Ron... It would seem reasonable to include discussion of this issue in a document. However, I do not see that it needs to be in the base specs at this stage of the game. A separate additional work item, if we have folks willing and interested in doing so, seems sensible. Yours, Joel On 7/20/2011 12:07 PM, Ronald Bonica wrote: >> One can easily imagine all sorts of ways to partition the cache, other >> than the >> one I suggested (which was to separate out highly-used mappings from >> new ones), >> if that proves to be not good enough. E.g. one could _also_ have code >> so that >> no individual client machine (i.e. source) can be the source of more >> than N% of >> the mappings, so that when a 'request' for the N+1th mapping arrives >> from that >> source, one of its oldest/least-used mappings gets evicted. Etc, etc, >> etc. >> >> It has been suggested that this might be a value-added differentiator >> for >> vendors, in fact - whose cache is most resistant to DoS? >> > > > Noel, > > At the risk of repeating myself, I think that the cache partitioning strategy > should be spelled out in the specification. If we specify it, the strategy > will benefit from wide review. > > If we don't specify a strategy, the specification should at least point out > that there is a sharp edge here, and that no strategy has been demonstrated > to address all corner cases. > > Ron > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
