I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.
Hell no, NTP does a good job. Don't have other services changing the clock (also counts for bitcoin). Right tool for the right job! |
|
|
|
I've thought about NTP, but this is more secure.
IMHO there is no reason for a modern system to not run a NTP client/daemon. |
|
|
|
I would compare that make your own client to capitalism, where as if we were to force everyone to release everything so the field was completely level would be loosely like communism.
There we have the whole "FOSS is commie" discussion again.  I think the use of which FOSS license isn't so much of a deal. I mean, there are a lot of licenses that fall under the OSI definition. And MIT is not so bad. I normally put my software under the GPL, because I like the fact that it is copyleft. But if another dev thinks an other license is better, who am I to judge (I didn't write any code for it). This is the same discussion as GPL vs. BSD (MIT being almost like the BSD license). |
|
|
|
You should specify which ebuild is yours so that others know. Currently there are two ebuild versions in the repository.
Message says: "bitcoin-0.3.11 ebuild from BioMike" |
|
|
|
My current ebuild is now also available from github.  Please test. |
|
|
|
|
domo is not usable in this case (bitcoin doesn't use the standard gettext localisation (po) dir). Bitcoin doesn't handle gettext directly, as far as I can see, so no dependency on gettext.
|
|
|
|
|
I've also made an start/stop script and I see 2 problems that I also encountered and was challenging to find a good solution to overcome them:
1) Your bitcoind runs as root. A possible bug that would cause some attacker to run his/her own commands through bitcoin gets root access. <edit>Ugh... it does change user</edit>
2) Stopping bitcoind is done by sending a signal to the daemon. I don't know how good bitcoind tries to close its databases, but I've had once a database corruption when killing the daemon. On the bitcoin chat people advised me to to send the rpc stop command to stop it (and call start-stop-daemon later again to clean it up), checking the debug log can give some information if it is closing right (flushing the database files). Best would be that bitcoind closes itself properly after receiving a kill signal.
|
|
|
|
|
Some interesting tips in there (last part), especially the domo command. The gui/daemon flags aren't a big issue currently. Development of an ebuild isn't working to an end point, but always ongoing. Splitting isn't useful here, can be done, but the package is IMHO to small for a split.
|
|
|
|
|
On my side, documentation (readme and license) are installed, and a .desktop menu entry is made when the gui is installed (to start bitcoin from the menu). Did some permission fixing for /var/lib/bitcoin (daemon), but not validated yet if it is correct.
|
|
|
|
wxGTK 2.9 is already in tree. I've already send mizerydearia an ebuild with makefile to build bitcoind and bitcoin based on use flags with autodetected berkdb, cflags and ldflags. Also localisation files are installed based on LINGUAS. For bitcoind init.d script is installed that seem to work fine under the bitcoin user. The ebuild isn't finished yet, but it is getting along. |
|
|
|
Give them some time.... it's not like that the only thing they do is checking their email for donations. |
|
|
|
|
Ach, Nederlands, Vlaams... misschien zelf Zuid-afrikaans.. Lijkt genoeg op elkaar om elkaar verstaanbaar te maken.
|
|
|
|
So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?
Phenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as "only works on AMDs K10" but rather as "tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future". Ah. Ok. Thank you for the info. |
|
|
|
... -march=XXXX means the compiler expects the binary will only be run on amdfam10.
That's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler. So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this? |
|
|
|
- Built with -march=amdfam10, which makes -4way slightly faster
Doesn't -march break abi with older systems? |
|
|
|
|
I used the live ebuild as a base to make a new ebuild against 0.3.10. The daemon seems to build fine, but for the graphical client I still need to adjust the Makefile (whole wxGTK part is missing there), but the ebuild already takes most of wxGTK into account. The daemon/graphical client are build on basis of use flags.
|
|
|
|
|
Ok, put my 35 btc in the escrow.
|
|
|
|
1) Remind that you will need to fix the header. I don't understand this. Which header? # Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/app-mobilephone/lightblue/lightblue-0.4.ebuild,v 1.3 2010/03/27 17:57:36 arfrever Exp $
That header 4) /home/bticoin? I don't see where I misspelled bitcoin. Which file? My mistake. I meant to write /home/bitcoin. My point is that this should be /var/lib/bitcoin. 5) Strip optimizations from the Makefile and let the user provide them (or strip them properly) I am uncertain what "optimizations" are. Things like "-msse2 -O3 -march=amdfam10". Gentoo users normally specify them themselves in /etc/make.conf. 6) Don't build static code. I have a Makefile that builds dynamic code. If you want I can send it to you. You will need to make changes to it. I am not familiar with which parts of code are static and could be converted to dynamic. I only prepared an ebuild because it seems nobody else has. I am not skilled enough to perfect the ebuild, however, if anyone else would like to contribute towards making it better, I set up a git repository: http://github.com/mizerydearia/bitcoin_gentoo_ebuildI can help you with that. One other thing that might be nice is an init.d script to start and stop the daemon at boot. <edit>oh... it's already there.</edit> |
|
|
|
Some things: 1) Remind that you will need to fix the header. 2) wxgtk is only needed when building the gui, not the daemon (make that use flag dependable) 3) gtk+ is then dependency of wxgtk, don't ask for it yourself. 4) Check other programs if and how they use wxwidgets through eselect (you can have 2.6 and 2.8 slotted on the same system, you will need 2.9) 4) /home/bticoin? 5) Strip optimizations from the Makefile and let the user provide them (or strip them properly) 6) Don't build static code. I have a Makefile that builds dynamic code. If you want I can send it to you. You will need to make changes to it. Valuable reading material: http://devmanual.gentoo.org/http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml |
|
|
|
So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?
This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network". I've never objected this change/idea, just asking if this was possible and to what extent. What's wrong with getting informed? |
|
|
|
|
Show Posts
