I am a (moderately active) member of Drupal community.
http://drupal.org
Drupal community could be a good reference for Bitcoin community to evolve to an open software community with many contributors and a robust issue system.

Drupal's automatic test framework is a very very notable resource to be known. Please take a look
http://qa.drupal.org/
*Every* patch pulled to the git server is run against an increasing and huge amount of tests. Indeed, no bug patch is accepted if it does not include tests to reproduce and solve the bug.

Really, this info is worrying ... Seemingly this forum is the sole way to coordinate and plan efforts.

Is Satoshi backing Bitcoin yet?

Maybe, senior members should drive Bitcoin's future with energy and confidence.

Satoshi ... please, it would be nice to know your position

cpulimit uses signals SIGSTOP/SICONT to achieve the cpu usage percent.

I have become aware of (likely) RPC interface of bitcoind, after trapped by SIGSTOP, discards commands. So, 'bitcoind getinfo' or 'bitcoind stop' fail too many times.

Manually releasing bitcoind proves this behavior

Audience: you could be interested on limiting CPU usage of bitcoind while mining (gen=1 in your bitcoin.conf) if:

• You are motivated to contribute (modest, but actually) to the global effort to verify Bitcoin transactions.
• Definitively, you are *not* suffering from BC-gold Fever.
• You do *not* want to hear roaring fans every time Bitcoin is instructed to generate hashes.
• You are an happy user of an Unix box

Assuming your bitcoin.conf file includes "gen=1", and you want to allow a 10% of CPU usage. A quite simple solution, from command line:

A more elaborated solution, i.e. this piece of code from a Bash script:

[Likely, you will need to get the cpulimit package: apt-get install cpulimit]

Please, test and feedback, JP

Subscribing

From http://bitcointalk.org/index.php?topic=589.0, interface and port is hard-coded to 0.0.0.0:8333 because

But ihmo, lock file management is the standard solution for such issues. As described by patch
http://pastebin.com/2e4hfXSS

Seemingly, there are several goods reasons to allow port configuration (or at least, network interface configuration)
  1) 8333 port is also used by another application (even at different network interface)
  2) Forwarding to several machines behind a single firewall.
  3) Test & Hack Bitcoin: To set up a farm (ecosystem) of bitcoin daemons.
  4) And all rationale at http://bitcointalk.org/index.php?topic=282.0;topicseen

Please, reconsider this feature request
http://bitcointalk.org/index.php?topic=282.0;topicseen

Dear friends, ... Bitcoin JS Remote wiki has been updated to clarify several Apache configurations tips.

Please, test and feedback:
https://en.bitcoin.it/wiki/Bitcoin-js-remote

@tcatm, you are right

Setting up RPC.url="bitcoind/" allows to configure Apache for multiple access. For instance, following Apache configuration

   AliasMatch   ^/jbc([0-9]?)(.*)$ your_prefer_pathabs_to_JSRemote_without_trailing_slash$2
   ProxyPass    /jbc/bitcoind/ http://localhost:8332/
   ProxyPass    /jbc1/bitcoind/ http://localhost:19331/
   ProxyPass    /jbc2/bitcoind/ http://localhost:19332/

allows following concurrent accesses:

   http://mydomain/jbc   .......... Access to a bitcoind listening the default rpc port (8332)
   http://mydomain/jbc1 .......... Access to another bitcoind listening a non-default rpc port (19331)
   http://mydomain/jbc2 .......... Access to another bitcoind listening a non-default rpc port (19332)

Another tip. Taking in account bitcoind talks only json (To-Be-Confirmed), ProxyPassReverse is not required.

@tcatm
thanks for adding my contribution.

I would like to propose you a tiny convenience improvement for BC JS Remote.

I am setting up BC JS Remote to access several instances of bitcoind running in the same box; more specifically a testnet-in-a-box configuration:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/

Using a fixed value for RPC.url in the settings.json file is a difficulty for multiple access, because there is no way to instruct Apache to proxy to/from every bitcoind instance.

My proposal is following behaviour; if the RPC.url field is undefined, it is automatically assigned to a value derived from the directory part of the URI. For instance,

Accessing with http://mydomain/jbc1 leads to a RPC.url value of "/jbc1/bitcoind/, and
accessing with http://mydomain/jbc2 leads to a RPC.url value of "/jbc2/bitcoind/

This allows us to setup different Proxy directives for the Apache webserver. For instance:
ProxyPass /jbc1/bitcoind/ http://localhost:19331/
ProxyPass /jbc2/bitcoind/ http://localhost:19332/

Is an interesting improvement for you?, could you code such a suggestion?

Also, I could pull a patch for BC JS Remote, my experience coding JS is limited but acceptable.

Dear friends,
I have just added a short wiki fragment with the proper configuration to access remotely Bitcoin daemon using a browser.

Thanks for a great piece of code: Bitcoin JS Remote.

Please, test and feedback:
https://en.bitcoin.it/wiki/Bitcoin-js-remote