1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1SoMaE-0002VK-2F
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 22:37:34 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=mh.in.england@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SoMZt-0002qp-KO
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 22:37:34 +0000
Received: by weyr6 with SMTP id r6so5480571wey.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jul 2012 15:37:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.86.133 with SMTP id p5mr32988342wiz.17.1341873427275; Mon,
09 Jul 2012 15:37:07 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.19.13 with HTTP; Mon, 9 Jul 2012 15:37:07 -0700 (PDT)
In-Reply-To: <4FFB5A7E.7020604@justmoon.de>
References: <1341849295.94710.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<CAAS2fgRd0gqrxXs4Le6nydYBaG7EO=T7FrtX6QZpg3aJtAxSvg@mail.gmail.com>
<1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com>
<CAAS2fgQRo4swDTQjPE0PmnpZ9uS+TDNQdOR6q4K70xsNJY9RfQ@mail.gmail.com>
<1341857882.56956.YahooMailNeo@web121006.mail.ne1.yahoo.com>
<CANEZrP1vwDubXrY3eoq4P4SAN=GK06iVaVx4pMWZKmBwQc9awg@mail.gmail.com>
<4FFB5A7E.7020604@justmoon.de>
Date: Tue, 10 Jul 2012 00:37:07 +0200
X-Google-Sender-Auth: v823ddcZraDgV2Zy9R2bF7ivpxI
Message-ID: <CANEZrP3Y3nvRwiPw66bDhp01JnE-zVurw5MnxPzR-bi5H8h4Aw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stefan Thomas <moon@justmoon.de>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1SoMZt-0002qp-KO
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Random order for clients page
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 22:37:34 -0000
> I strongly agree, but this is *why* I suggested moving it to the wiki. I
> recently had to choose an XMPP client and I looked on xmpp.org - after a
> frustrating experience with their listing [1]
Probably because their listing is even more useless than any of the
proposals that were presented here. Thank goodness it didn't end up
like that. Their table doesn't even attempt to list features or
differentiating aspects of each client.
I think the XMPP guys have pretty much given up on directly marketing
the system to end users.
> - more up-to-date (anyone can update them)
Fortunately reasonable clients don't appear/disappear/change that often.
> - more in touch with users:
I think by "users" you mean, geeks who understand wiki syntax. Because
that's what it'll end up trending towards. I don't believe a wiki
would reflect the needs of your average person. It's still better to
have these arguments here and try to find a user-focussed consensus
than hope one will converge from a wiki.
> If you want to see "the result of
> internal politics", the current client page is a good example. We
> couldn't agree on the columns for a feature matrix, so now we just have
> walls of text.
Inability to agree on columns isn't why the page looks like that. I
know because I'm the one who argued for the current design.
It looks like that because feature matrices aren't especially helpful
for newbies to make a decision, especially when the "features" in
question were often things like how they handled the block chain or
which protocol standards they support, ie, things only of interest to
developers.
It's much easier to communicate the differences to people with a short
piece of text, and maybe if there is no obvious way to explain why
you'd want to use a given client, that's a good sign it's not worth
listing there. Otherwise you end up like xmpp.org.
> Some of the options that are de-facto the most popular
> with users like BlockChain.info or just using your MtGox account are not
> mentioned at all.
It's true that bitcoin.org needs to be conservative. That said, I'd
like there to be sections for them too, actually. I agree that risk
isn't purely about how it's implemented and that whilst we might like
to push particular ideologies around protocols or code licensing, that
isn't especially relevant to end users who have different priorities.
Track record counts for a lot as well.
|
