From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qw6Db-00054b-Fp for garchives@archives.gentoo.org; Wed, 24 Aug 2011 05:41:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2238E21C338; Wed, 24 Aug 2011 05:41:28 +0000 (UTC) Received: from mail-fx0-f53.google.com (mail-fx0-f53.google.com [209.85.161.53]) by pigeon.gentoo.org (Postfix) with ESMTP id A91D521C02B for ; Wed, 24 Aug 2011 05:40:26 +0000 (UTC) Received: by fxd23 with SMTP id 23so893374fxd.40 for ; Tue, 23 Aug 2011 22:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=J1qbDCOnWY1CCWOn6nWGTopPzeoNSC/j/LZEqKhK80o=; b=KOZ1LrSnxUwI5YyvYD1Grcj/HVaVjh2BH9R7Ul1PbtVEGGH3ZTjxh3zGQVjpr7ULqZ 8x5I6BfaGEQxiQmCBAk113RYemYyKgVLgAOncbUTcEg/tM5qjrwdAROKs9RxaC330hYH dt7+XnH0pMQp44dcOl7aw1t3x9Rr6i0qJFir0= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.223.55.203 with SMTP id v11mr6602954fag.78.1314164425725; Tue, 23 Aug 2011 22:40:25 -0700 (PDT) Received: by 10.223.105.145 with HTTP; Tue, 23 Aug 2011 22:40:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 01:40:25 -0400 Message-ID: Subject: Re: DBUS [was] Re: [gentoo-user] systemd From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 800c2a34cf70c95012701cb861254578 On Tue, Aug 23, 2011 at 4:53 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > On Tue, Aug 23, 2011 at 4:18 PM, Michael Mol wrote: > You are right, I stand corrected. And actually, D-Bus is very much > capable of restart without kicking out sessions (read Havoc > explanation in http://article.gmane.org/gmane.comp.freedesktop.dbus/7730)= . > The problem is that many apps don't handle this correctly, and the > D-Bus developers choose the "safe" option. If all the apps supported > gracefully the restart, there would be no problems. A very, very good writeup which provides a lot of explanation of the semantics of D-Bus connections. Very helpful, thanks for the link. What it tells me is that a D-Bus restart needs to be able to be done without dropping connections. I don't know the specifics of the bindings between libdbus and the daemon, but a first guess would be to spin up the upgraded daemon, hand over all live connections, and shut down the old daemon. That obviously requires newer daemons being able to talk with older libdbus (at least until the app itself is restarted), and newer libdbus being able to talk with older daemons (in the event that an app hits that vulnerable spot between when things have been installed but not upgraded). Obviously, this really depends on how much the libdbus protocol itself must be able to change going forward. > >> And, yes, upgrades on live data can be a royal PITA. Designing a >> system which can handle it requires careful attention and testing. The >> more anal you want to be about it, the more you start talking about >> writing provable and verifiable code and other stringent debugging, >> development and testing practices. > > It's a matter of cost-benefit. Given the open source community, I > think the PITA is not worth it in several cases, D-Bus being one of > them. Personally, I suspect the balance will change as there's greater and greater dependency on D-Bus on long-uptime systems. > >> Yet it's done. Last Friday, I sat at a table with someone who >> witnessed an IBM tech replace a CPU in a mainframe. Flip a switch, >> pull out the old part, insert the new part, flip the switch back on, >> everything's fine. Saturday, I listened to a guy present on how he >> dynamically reroutes live calls through a VOIP network based on >> hardware faults. > > I have seen those kind of systems. And again, it's a matter of > cost-benefit: See the difference in budgets for that kind of systems > and our open source software stack. True to an extent. I think it was four or five years ago, during the SCO lawsuit, when someone estimated the value of the Linux kernel at well over a billion dollars. Many for-profit companies contribute to the kernel and its architecture. If D-Bus becomes necessary to the operation of the majority of use cases, I suspect similar contribution paths will occur there. > >> D-Bus wants to be a core system service, and *that's* what should be >> setting its design goals, not how difficult it would be for the system >> to be worthy of the core. >> >> Again, I really don't believe D-Bus is badly-written. I just think its >> community isn't fully aware of the trends of its position in the >> system, and what responsibilities it carries. > > I think we are fully aware. The thing is, given the community > resources, D-Bus is good enough, which, as everybody knows, is the > enemy of (the impossible) perfect. Very true. --=20 :wq