Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SoIJW-0007GS-IF for bitcoin-development@lists.sourceforge.net; Mon, 09 Jul 2012 18:04:02 +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=etotheipi@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 1SoIJV-0000Pt-BN for bitcoin-development@lists.sourceforge.net; Mon, 09 Jul 2012 18:04:02 +0000 Received: by weyr6 with SMTP id r6so5303014wey.34 for ; Mon, 09 Jul 2012 11:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.93.68 with SMTP id cs4mr31342980wib.14.1341857035208; Mon, 09 Jul 2012 11:03:55 -0700 (PDT) Received: by 10.194.8.39 with HTTP; Mon, 9 Jul 2012 11:03:55 -0700 (PDT) In-Reply-To: References: <1341849295.94710.YahooMailNeo@web121003.mail.ne1.yahoo.com> <1341850157.18601.YahooMailNeo@web121006.mail.ne1.yahoo.com> Date: Mon, 9 Jul 2012 14:03:55 -0400 Message-ID: From: Alan Reiner To: Gregory Maxwell Content-Type: multipart/alternative; boundary=f46d043892bdec466c04c4696fb8 X-Spam-Score: -0.6 (/) 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 (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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 X-Headers-End: 1SoIJV-0000Pt-BN 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 18:04:02 -0000 --f46d043892bdec466c04c4696fb8 Content-Type: text/plain; charset=ISO-8859-1 I generally agree with Greg. I don't see anything he's said or done as anti-alt-client. As an alt-client developer, I'm happy to see my client on the main page, but I'm also happy if that "clients" page is simply an acknowledgement that there's more to the Bitcoin world than just the Bitcoin-Qt client, and a link of where to find more information (i.e. the wiki). I would still * prefer* to have the page the way it is, because I think alt clients should be more accessible and word will spread better where it is now -- but I also recognize the inherent difficulty of gaining any kind of consensus of how it should be organized, what goes on the list, etc, and no matter how you do it, someone will complain about it being unfair or not right. We either have to have a "czar" who is trusted to make responsible decisions, and complaints of being unfair or recommendations for improvements can go through that person, but ultimately it is that person who makes the call. Or we just move it to another page that is less strictly controlled and where these things matter less. Trying to gain consensus among an amalgamation of developers all with competing priorities and "products" is a terrible way to try to agree on stuff. -Alan On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell wrote: > On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki 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 > as 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 clients page is your bias towards thinking that there should be > only one Bitcoin 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. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --f46d043892bdec466c04c4696fb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I generally agree with Greg. =A0 I don't see anything he's said or = done as anti-alt-client.

As an alt-client developer, I&#= 39;m happy to see my client on the main page, but I'm also happy if tha= t "clients" page is simply an acknowledgement that there's mo= re to the Bitcoin world than just the Bitcoin-Qt client, and a link of wher= e to find more information (i.e. the wiki). =A0I would still prefer= =A0to have the page the way it is, because I think alt clients should be mo= re accessible and word will spread better where it is now -- but I also rec= ognize the inherent difficulty of gaining any kind of consensus of how it s= hould be organized, what goes on the list, etc, and no matter how you do it= , someone will complain about it being unfair or not right.

We either have to have a "czar" who is truste= d to make responsible decisions, and complaints of being unfair or recommen= dations for improvements can go through that person, but ultimately it is t= hat person who makes the call. =A0Or we just move it to another page that i= s less strictly controlled and where these things matter less. =A0Trying to= gain consensus among an amalgamation of developers all with competing prio= rities and "products" is a terrible way to try to agree on stuff.=

-Alan




On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell <g= maxwell@gmail.com> wrote:
On Mon, Jul 9, 2012 at 12:= 09 PM, Amir Taaki <zgenjix@yahoo.co= m> wrote:
> JS randomisation is bad. People shouldn't need JS to view a webpag= e.

JS randomization doesn't imply needing JS to view the page. It im= plies
needing JS to see it in random order. =A0You 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 as it is.

I'll let other people speak for themselves, but I did consult oth= ers
before reverting your last batch of changes.

More generally, we have pull requests in order to get some peer review
of changes. =A0Everyone should use them except for changes which are
urgent or trivially safe. =A0(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 webp= age for Bitcoin clients. I have made a change to remove a source of dispute= s, and make the process more fair and equal. Your suggestion to remove the = clients page is your bias towards thinking that there should be only one Bi= tcoin client that everyone uses (the one which you contribute towards).

I'm strongly supportive diversity in the Bitcoin network, and som= e 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<= br> 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'). =A0The 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<= br> does they'll know it and they'll be looking. We don't need to m= ake 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.

---------------------------------------------------------------------------= ---
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d043892bdec466c04c4696fb8--