They are related because it's possible and likely that in future the network will need various global upgrades, eg to scale better, support new transaction types or fix security bugs like the one last September.
If most nodes don't auto update then doing that kind of thing will become much harder.
Topic: Version 0.3.20.2 released (Read 5837 times)
Hi,
there seems to be something mixed up.
1. Development of Bitcoin's protocol and overall functionality as a system
2. Bitcoin as a end user software
For now Bitcoin as a system comes into existence only by means of the software (and its UI) which serves as a reference implementation.
My point is that auto-updating is a UI feature and thus almost irrelevant for Bitcoin as a system (and its success).
Rather than throwing more (UI-related) work in here, things like that should probably better be moved out of the way of busy people like Gavin.
I think auto-update is definitely very convenient for the average user, even for a lot of technical sophisticated people, I suppose.
Still, feature rich user experience should better be left to sophisticaed UI clients with all the user experience bells&whistles eg. auto-updates.
An idea for an easy-to-use UI: I just came across Adobe AIR which might be used to bundle bitcoind with bitcoin-js-remote by tcatm, thus creating a desktop alternative for the wxBitcoin client with an appealing, feature rich UI and built in auto-updating. Has anybody experience with this programming environment?
regards,
Marco
there seems to be something mixed up.
1. Development of Bitcoin's protocol and overall functionality as a system
2. Bitcoin as a end user software
For now Bitcoin as a system comes into existence only by means of the software (and its UI) which serves as a reference implementation.
My point is that auto-updating is a UI feature and thus almost irrelevant for Bitcoin as a system (and its success).
Rather than throwing more (UI-related) work in here, things like that should probably better be moved out of the way of busy people like Gavin.
I think auto-update is definitely very convenient for the average user, even for a lot of technical sophisticated people, I suppose.
Still, feature rich user experience should better be left to sophisticaed UI clients with all the user experience bells&whistles eg. auto-updates.
An idea for an easy-to-use UI: I just came across Adobe AIR which might be used to bundle bitcoind with bitcoin-js-remote by tcatm, thus creating a desktop alternative for the wxBitcoin client with an appealing, feature rich UI and built in auto-updating. Has anybody experience with this programming environment?
regards,
Marco
Even Chrome doesn't auto-update on Linux.
Actually I believe it does now.
unless you count standard dpkg/apt (which is not what I meant originally)
Even Chrome doesn't auto-update on Linux.
Actually I believe it does now.
For Linux it's harder yes. Though it could just be a matter of having the wrapper app poll a remote server to find a static DSO.
For Windows/MacOS (where there'll be a larger population of casual users anyway) there is
http://code.google.com/p/omaha/ (don't know how easy it is to reuse)
http://sparkle.andymatuschak.org/
I think Microsoft provide a tool (OneClick?) that can make it easier to install and update Windows apps from the web.
For Windows/MacOS (where there'll be a larger population of casual users anyway) there is
http://code.google.com/p/omaha/ (don't know how easy it is to reuse)
http://sparkle.andymatuschak.org/
I think Microsoft provide a tool (OneClick?) that can make it easier to install and update Windows apps from the web.
Maybe someone could open a Debian/Ubuntu repo already...Or is there already one?
Bitcoin client in Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578157
(link to Jonas repo in thread)
Some usefull utils, miners, etc.:
https://bitcointalksearch.org/topic/not-oficial-bitcoin-apps-debianubuntu-packages-2207
(inside 2 repo: Tuxsoul's and my)
P.S.
My opinion: autoupdate -- it's another useless "make me a cofee" function.
There are two types of people running BitCoin nodes - dedicated, technically sophisticated users who have understood Satoshis paper, who can read C++, understand asymmetric crypto and so on. And then there's everyone else.
The latter group aren't reviewing changes to the node software, and as they don't understand BitCoin in depth they are implicitly trusting other people who say it works anyway. So automatic updates can only benefit them by keeping their software secure against flaws that are found.
The former group either wouldn't use the auto-updated version and would continue to download the builds as posted, or would decide they trust Gavin/Satoshi implicitly and accept the auto updates, perhaps doing a review of the changes later on.
Writing a full auto-updater for all three supported OSes would be a pain. Even Chrome doesn't auto-update on Linux. It would be much better to just get it into a repo or the Apple App Store, though maybe we need an autoupdate mechanism for Windows.The latter group aren't reviewing changes to the node software, and as they don't understand BitCoin in depth they are implicitly trusting other people who say it works anyway. So automatic updates can only benefit them by keeping their software secure against flaws that are found.
The former group either wouldn't use the auto-updated version and would continue to download the builds as posted, or would decide they trust Gavin/Satoshi implicitly and accept the auto updates, perhaps doing a review of the changes later on.
Maybe someone could open a Debian/Ubuntu repo already...Or is there already one?
There are two types of people running BitCoin nodes - dedicated, technically sophisticated users who have understood Satoshis paper, who can read C++, understand asymmetric crypto and so on. And then there's everyone else.
The latter group aren't reviewing changes to the node software, and as they don't understand BitCoin in depth they are implicitly trusting other people who say it works anyway. So automatic updates can only benefit them by keeping their software secure against flaws that are found.
The former group either wouldn't use the auto-updated version and would continue to download the builds as posted, or would decide they trust Gavin/Satoshi implicitly and accept the auto updates, perhaps doing a review of the changes later on.
The latter group aren't reviewing changes to the node software, and as they don't understand BitCoin in depth they are implicitly trusting other people who say it works anyway. So automatic updates can only benefit them by keeping their software secure against flaws that are found.
The former group either wouldn't use the auto-updated version and would continue to download the builds as posted, or would decide they trust Gavin/Satoshi implicitly and accept the auto updates, perhaps doing a review of the changes later on.
I think we should just not expose version numbers directly. Internally the software identifies itself using block chain indexes as the version number, that does fine (or dates). Numbers like 0.3.20.3 are quite intimidating for regular users and make the software look much rougher than it really is.
Google Chrome has the right idea IMHO. No user visible version numbers, silent and automatic updates. It'd be good to get it auto updating for those who want that (yeah i know, patches patches :-).
Google Chrome has the right idea IMHO. No user visible version numbers, silent and automatic updates. It'd be good to get it auto updating for those who want that (yeah i know, patches patches :-).
-1
I'm fine with silent updates normally, but when it comes to Bitcoin: Don't we always say that "if the Bitcoin developers did X [insert evil plot here], people won't use the new version". This argument is kind of defeated by silent automatic updates, no?
Don't get me wrong, I trust the current developers, but if we are going around making arguments for Bitcoin's security, those arguments should have rock-solid footing.
-1 disagree.
I think we should just not expose version numbers directly. Internally the software identifies itself using block chain indexes as the version number, that does fine (or dates). Numbers like 0.3.20.3 are quite intimidating for regular users and make the software look much rougher than it really is.
Google Chrome has the right idea IMHO. No user visible version numbers, silent and automatic updates. It'd be good to get it auto updating for those who want that (yeah i know, patches patches :-).
Google Chrome has the right idea IMHO. No user visible version numbers, silent and automatic updates. It'd be good to get it auto updating for those who want that (yeah i know, patches patches :-).
+1
Any news on the availability of the Mac build?
Thank you for your efforts!
Thank you for your efforts!
The tag is v0.3.20.2, and it is signed by my ([email protected]) gpg key.
oh, i'm sorry! somehow git didn't fetch the tag at first (had to pass --tag)
I think we should just not expose version numbers directly. Internally the software identifies itself using block chain indexes as the version number, that does fine (or dates). Numbers like 0.3.20.3 are quite intimidating for regular users and make the software look much rougher than it really is.
Google Chrome has the right idea IMHO. No user visible version numbers, silent and automatic updates. It'd be good to get it auto updating for those who want that (yeah i know, patches patches :-).
Google Chrome has the right idea IMHO. No user visible version numbers, silent and automatic updates. It'd be good to get it auto updating for those who want that (yeah i know, patches patches :-).
- tag these minor releases in git, too
- sign tags with gpg (git tag -s -u )
- sign tags with gpg (git tag -s -u
The tag is v0.3.20.2, and it is signed by my ([email protected]) gpg key.
RE: roadmap for v0.4 : I worry that we'll spend time creating a roadmap and then... people will work on whatever strikes their fancy. So the 0.4 release will end up being completely different from what the roadmap says.
That said, I'll start a roadmap thread; maybe we CAN all agree on priorities and find people to actually work on the highest priority stuff.
two little suggestions:
- tag these minor releases in git, too
- sign tags with gpg (git tag -s -u )
would probably help those of us compiling from source being a little bit more sure that it's actually the right source, that is definitively supposed to work.
of course we still have to trust gavin (and his key) but its a whole lot better than trusting github, or whatever place one clones the git from
- tag these minor releases in git, too
- sign tags with gpg (git tag -s -u
would probably help those of us compiling from source being a little bit more sure that it's actually the right source, that is definitively supposed to work.
of course we still have to trust gavin (and his key) but its a whole lot better than trusting github, or whatever place one clones the git from
Four version numbers??
Yep, better increment only the third number even for small bugfixes (and we should really write a roadmap so we can have 0.4 soon instead of 0.3.693).
Four version numbers??
The maxsendbuffer bug (0.3.20.1 clients not being able to download the block chain from other 0.3.20.1 clients) was only going to get
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.
The Amazon Machine Images I used to do the builds are available:
(mac build will be done soon)
If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:
... or download the new version.
worse as people upgraded, so I cherry-picked the bug fix and created a minor release yesterday.
The Amazon Machine Images I used to do the builds are available:
Code:
ami-38a05251 Bitcoin-v0.3.20.2 Mingw (Windows; Administrator password 'bitcoin development')
ami-30a05259 Bitcoin_0.3.20.2 Linux32
ami-8abc4ee3 Bitcoin_0.3.20.2 Linux64
If you have already downloaded version 0.3.20.1, please either add this to your bitcoin.conf file:
Code:
maxsendbuffer=10000
maxreceivebuffer=10000
Jump to: