Java程序辅导

C C++ Java Python Processing编程在线培训 程序编写 软件开发 视频讲解

客服在线QQ:2653320439 微信:ittutor Email:itutor@qq.com
wx: cjtutor
QQ: 2653320439
Linux-Kernel Archive: Re: RFC: per-socket statistics on receive Re: RFC: per-socket statistics on received/dropped packets From: Mark Mielke (mark@mark.mielke.cc) Date: Wed Jun 12 2002 - 00:20:04 EST Next message: Rusty Russell: "Re: [PATCH] Futex Asynchronous Interface" Previous message: Adam Luchjenbroers: "Parallel Port and USB Device Drivers" In reply to: Richard Guy Briggs: "Re: RFC: per-socket statistics on received/dropped packets" Next in thread: Pekka Savola: "Re: RFC: per-socket statistics on received/dropped packets" Reply: Pekka Savola: "Re: RFC: per-socket statistics on received/dropped packets" Reply: Sean Hunter: "Re: RFC: per-socket statistics on received/dropped packets" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Tue, Jun 11, 2002 at 11:57:26PM -0400, Richard Guy Briggs wrote: > On Tue, Jun 11, 2002 at 08:41:19PM -0700, David S. Miller wrote: > > From: Bill Davidsen > > Date: Tue, 11 Jun 2002 18:41:16 -0400 (EDT) > > Actually your arguments sound like you have a solution to your problem > > and you want everyone to use it even if it doesn't help them. Have you > > some emotional tie to SNMP, like being an author? > Basically Bill, if you don't like this policy, fork the code. That is > one of the strengths (and weaknesses) of open source. If your tree > works better and gets wider use, then something about it must be better. > If not, then maybe it wasn't. This community works on reputation > capital (and some diplomacy). To some degree (i.e. I know it is not intentional), this comes across as blackmail. Sorta like "if you want to play ball with me, you play by my rules, otherwise you can go find your own diamond and your own friends to play with." I would still like to see David's logic as to why the approach is bad. So far it amounts to 1) David doesn't like it, 2) David doesn't see a need for it, or can see other less adequate methods of approximating the same effect, and 3) David suspects that it will effect the performance of all users to provide a limited gain for some applications. 'Reputation capital' is earned. I would like to see it 'earned' in practice given a real requirement from a real developer on a real world class application. Statements such as 'the most important thing I do is say no', don't convince me that a reputation is deserved. The extreme of this is that an automaton could say no to everything. Yes, I might be testing David... is it fair? Well, the requirement was fair, so how could it not be fair? I (and Bill) are just asking for some logic to show us where we are wrong. Linus can pull the "I'm god, and that's that" gig. Fine. How far does the godhead extend? Who else can pull this gig? I am waiting in anticipation to be shown the error of my ways using proper logic and iron clad reasoning... :-) Cheers, mark -- mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ - 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/ Next message: Rusty Russell: "Re: [PATCH] Futex Asynchronous Interface" Previous message: Adam Luchjenbroers: "Parallel Port and USB Device Drivers" In reply to: Richard Guy Briggs: "Re: RFC: per-socket statistics on received/dropped packets" Next in thread: Pekka Savola: "Re: RFC: per-socket statistics on received/dropped packets" Reply: Pekka Savola: "Re: RFC: per-socket statistics on received/dropped packets" Reply: Sean Hunter: "Re: RFC: per-socket statistics on received/dropped packets" Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:24 EST