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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1SoI2B-0006Xz-RP
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 17:46:07 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=gmaxwell@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SoI2B-0002pf-34
for bitcoin-development@lists.sourceforge.net;
Mon, 09 Jul 2012 17:46:07 +0000
Received: by pbbrq2 with SMTP id rq2so18504601pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 09 Jul 2012 10:46:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.134.161 with SMTP id pl1mr50203596pbb.29.1341855961219;
Mon, 09 Jul 2012 10:46:01 -0700 (PDT)
Received: by 10.68.59.6 with HTTP; Mon, 9 Jul 2012 10:46:01 -0700 (PDT)
In-Reply-To: <1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com>
References: <1341849295.94710.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<CAAS2fgRd0gqrxXs4Le6nydYBaG7EO=T7FrtX6QZpg3aJtAxSvg@mail.gmail.com>
<1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com>
Date: Mon, 9 Jul 2012 13:46:01 -0400
Message-ID: <CAAS2fgQRo4swDTQjPE0PmnpZ9uS+TDNQdOR6q4K70xsNJY9RfQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Amir Taaki <zgenjix@yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.1 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SoI2B-0002pf-34
Cc: "bitcoin-development@lists.sourceforge.net"
<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 17:46:07 -0000
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpage.
JS randomization doesn't imply needing JS to view the page. It implies
needing JS to see it in random order. You could also combine it with
the server-side randomization if you care about non-js being non
random, though I don't think it matters.
As others have pointed out I don't generally think the randomization
is good in principle, but if its done it should at least achieve its
goals.
> Only you have a problem with this page. I don't see why Bitcoin-Qt needs =
to be first either when it dominates the front page. It is perfectly fine a=
s it is.
I'll let other people speak for themselves, but I did consult others
before reverting your last batch of changes.
More generally, we have pull requests in order to get some peer review
of changes. Everyone should use them except for changes which are
urgent or trivially safe. (Presumably everyone with access knows how
to tell if their changes are likely to be risky or controversial)
> You are not a developer of any alternative clients, and this is a webpage=
for Bitcoin clients. I have made a change to remove a source of disputes, =
and make the process more fair and equal. Your suggestion to remove the cli=
ents page is your bias towards thinking that there should be only one Bitco=
in client that everyone uses (the one which you contribute towards).
I'm strongly supportive diversity in the Bitcoin network, and some alt
client developers can speak to the positive prodding I've given them
towards becoming more complete software. If I've said anything that
suggests otherwise I'd love to be pointed to it in order to clarify my
position.
Unfortunately none of the primary alternatives are yet complete, the
network would be non-function if it consisted entirely of multibit or
electrum nodes (and as you've noted armory uses a local reference
client as its 'server'). The distinction between multiple kinds of
clients in terms of security and network health are subtle and can be
difficult to explain even to technical users and so until something
changes there the reference client needs to be the option we lead
with. People should us it unless their use-case doesn't match. When it
does they'll know it and they'll be looking. We don't need to make one
of those recommendations a primary option.
I like the proposals of moving this stuff to the Wiki as the wiki
already contains tons of questionable (and sometimes contradictory)
advice and so there is less expectation that placement there implies
any vetting.
|
