From: Wladimir <laanwj@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Random order for clients page
Date: Tue, 10 Jul 2012 09:12:15 +0200 [thread overview]
Message-ID: <CA+s+GJAknsVKZf-xhPK1URKBcvMPQW1MSTnxnu8gPPtxw_KAMw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgT10nf=8TJxYrT4WBNdYUiSU7qQNDTjjbTSuMktn2QVpw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4617 bytes --]
Just my two cents -- I'm against removing the overview page or moving it to
the wiki. I think other open source clients deserve a mention on the
bitcoin.org page.
Many new people are looking for a good Android client, for example. Rather
than randomly searching on Google or the app store, it's much safer to
follow the link from bitcoin.org. Others are looking for a light clients
because they think the Satoshi one is too heavy.
Again, rather than following random links on a search engine or wiki (not
all users have the common sense required for this) it may be better if they
follow links "audited" (or at least discussed) by this community. I agree
with Jim here.
The reference client is already first in that it can be downloaded directly
from the main page of bitcoin.org. That should stay that way for the
considerable future, as it's the most proven. The position in the alt
clients list is less important. That said, I'm not a big fan of randomized
order because it's confusing. Come back to the page and it's different.
Some other neutral ordering is probably possible.
Wladimir
On Tue, Jul 10, 2012 at 5:05 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner <etotheipi@gmail•com> wrote:
> > What a feature matrix is good at though is it allows you to very quickly
> > find the specific feature or general criteria you're looking for without
> > reading through all of the text. So it might be a useful addition maybe
> > not on Bitcoin.org, but certainly on the wiki.
>
> I'm generally not a fan of feature matrixes, they encourage "checkbox
> decision making"— which is seldom very good for the decider, though
> it's much loved by the marketing department that puts together the
> matrix. But just becase something is loved by marketing departments
> for its ability to set the agenda in variously biased ways doesn't
> mean its a great thing to emulate.
>
> Take the matrix Luke linked to for example[1]. Now imagine that we
> tunnel MyBitcoin from a year ago and drop it into that table. It
> would have every light green, except 'encryption' (which wouldn't have
> been green for bitcoin-qt then either). It would basically be the
> dominant option by the matrix comparison, and this is without any
> lobbying to get MyBitcoin specific features (like their shopping chart
> interface) added, not to mention the "_vanishes with everyone's
> money_" feature.
>
> I don't think I'm being unreasonable to say that if you could drop in
> something that retrospectively cost people a lot into your decision
> matrix and it comes out on top you're doing something wrong.
>
> In tables like this significant differences like "a remote hacker can
> rob you" get reduced to equal comparison with "chrome spoiler", and
> it further biases development motivations towards features that make
> nice bullets (even if they're seldom used) vs important infrastructure
> which may invisibly improve usage every day or keeps the network
> secure and worth having. "Of course I want the fastest startup! Why
> would I choose anything else?" "What do you mean all my bitcoin is
> gone because the four remaining full nodes were taken over and reorged
> it all?"
>
> I wouldn't expect any really important features which don't have
> complicated compromises attached to them to be omitted from all
> clients for all that long.
>
> Basically matrixes make bad decision making fast, and by making it
> fast it's more attractive than careful decision making that always
> takes time. The text is nice because it contextualizes the complete
> feature set and helps you understand why different clients exist, what
> problems they attempt to solve, and what compromises they make. ...
> without making the unrealistic demand of the user they they know how
> to fairly weigh the value of technical and sometimes subtle issues.
>
>
> [1] https://en.bitcoin.it/wiki/Clients
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 5818 bytes --]
next prev parent reply other threads:[~2012-07-10 7:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-09 15:54 Amir Taaki
2012-07-09 16:04 ` Gregory Maxwell
2012-07-09 16:09 ` Amir Taaki
2012-07-09 16:39 ` Stefan Thomas
2012-07-09 16:55 ` Harald Schilly
2012-07-09 17:21 ` Luke-Jr
2012-07-09 17:46 ` Gregory Maxwell
2012-07-09 18:03 ` Alan Reiner
2012-07-09 18:29 ` thomasV1
2012-07-09 18:18 ` Amir Taaki
2012-07-09 18:30 ` Mike Hearn
2012-07-09 22:26 ` Stefan Thomas
2012-07-09 22:37 ` Mike Hearn
2012-07-10 2:36 ` Stefan Thomas
2012-07-10 2:44 ` Alan Reiner
2012-07-10 3:05 ` Gregory Maxwell
2012-07-10 7:12 ` Wladimir [this message]
2012-07-10 9:11 ` Stefan Thomas
2012-07-13 15:20 ` Daniel F
2012-07-09 23:07 ` [Bitcoin-development] Wiki client list (was: Random order for clients page) Luke-Jr
2012-07-09 18:48 ` [Bitcoin-development] Random order for clients page Gregory Maxwell
2012-07-09 20:44 ` Jeff Garzik
2012-07-09 17:33 ` Nils Schneider
2012-07-09 18:24 ` Amir Taaki
2012-07-09 18:54 Jim
2012-07-09 18:57 ` Gregory Maxwell
2012-07-09 19:14 ` Alan Reiner
2012-07-09 20:13 ` Gary Rowe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+s+GJAknsVKZf-xhPK1URKBcvMPQW1MSTnxnu8gPPtxw_KAMw@mail.gmail.com \
--to=laanwj@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox