Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753459AbbDOMFE (ORCPT ); Wed, 15 Apr 2015 08:05:04 -0400 Received: from 251.110.2.81.in-addr.arpa ([81.2.110.251]:43081 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbbDOMEy (ORCPT ); Wed, 15 Apr 2015 08:04:54 -0400 Date: Wed, 15 Apr 2015 13:03:54 +0100 From: One Thousand Gnomes To: Greg Kroah-Hartman Cc: Jiri Kosina , Al Viro , Borislav Petkov , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415130354.458abfc2@lxorguk.ukuu.org.uk> In-Reply-To: <20150415114936.GD19274@kroah.com> References: <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <20150414192429.GC26075@pd.tnic> <20150414193229.GB6107@kroah.com> <20150414194004.GG889@ZenIV.linux.org.uk> <20150414194804.GB7540@kroah.com> <20150415113727.0cfd5224@lxorguk.ukuu.org.uk> <20150415114936.GD19274@kroah.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2538 Lines: 61 > > There is no comparison between the elegance of X11 property setting and a > > chunk of proposed kernel code that is half the size of a tiny X server! > > Hey, take that up with Havoc, he made the comparison :) And it concerns me you blindly repeat it without realising its wrong. > > The dbus model is also flawed in a load of other ways in user space > > because message handling in the hands of people with no concept of > > systemic performance analysis just leads to disaster. One of the big > > reasons dbus is so "slow" isn't that dbus is "slow", it's that the > > crapware on top of it makes *thousands* of dbus queries. > > There's the issue of thousands of dbus queries, and then there's the > issue that making those queries takes a measurable amount of time. We > can fix the later one, the first one, well, not so much, but we can > provide the resources for them to make a faster system if they want to. If you fix the thousands of queries problem do you need kernel help at all. > The internet model with state in the endpoints doesn't always transfer > properly to local applications, see Havoc's email for the details about > that. URL ? (note how beautifully btw the stateless network and the URL string will become a reference to state) > > It's telling that I can lose and recover my internet connection without > > rebooting but not my desktops internal messaging. > > Yes, as those are totally different things, let's not mix the issue up > here please. They are *NOT* different things. They are fundamental properties of the underlying architecture. I worked on stateful networks and still have the scars. It is a fundamental property of stateful network that every time any key component goes castors up you lose the lot. It is a fairly fundamental property of stateless networks that equipment going castors up has no material impact on the network The internet is built upon three fundamental breakthroughs in technology - That stateless networks scale and can be reliable while stateful ones cannot scale and cannot be fixed to do so - That flow control is possible over a stateless network - That efficient data routing is possible over a stateless network Those are absolutely critical parts of any network or messaging implementation. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/