I actually have that planned for my bitshares_delegate_tools (https://github.com/wackou/bitshares_delegate_tools), I'm currently on holidays with intermittent internet but I expect to have it running in 2-3 weeks.

I'd like to have it working with manual intervention, ie: stop 1 on demand for upgrade, maintenance, etc... while the 2nd one takes over, or using automatic detection, for instance if the client crashes, or connections count drop to 0 (happened to me last night while sleeping ) then the 2nd one could automatically kick in. Stay tuned!

All I see are init delegates. Is there something wrong with my copy of the chain?

You are probably not on the correct network. For the real one, you shouldn't be getting it from the same repo as for the dry runs, but from there:

https://github.com/dacsunlimited/bitsharesx/releases

there are a lot more than those... Actually, out of the 100 first delegates, a huge number seems disingenuous/dishonest...

All the names/delegates that were present and active during the dry runs, who were people that were making bitshares a vibrant ecosystem have been relegated to rank > 100 and even > 200, while all the first spots have been taken by whoever voted for their +10 delegates. This is a blatant case of "the rich get richer", and these people will certainly not do anything for the network except collecting their fees and sit on it while the rest of us just get disappointed and disgusted...

I have to say that I missed the moment where the votes for a transaction go to *all* the delegates that are approved, I thought that they would be divided between the number of approved delegates in a wallet, or in a round-robin fashion, but in any case I was expecting that the total sum of votes would be 100%. This would mean that a whale could only upvote one of their delegate, or more of them but then the stake would have been divided by the number of voted delegates, which would have prevented the situation we have now.

Pushing it further, I can even see that those people with high stake and their big number of delegates could collude and get, say, all their 80 delegates active, each with 25% approval, and the rest of us can keep our few percents and weep. For me, I was always attracted to bitshares because I imagined a slate of 100 different delegates, each offering something different and contributing to the network either by writing code, promoting bitshares, donating to charities, ... and making the world a better place while still building an efficient and modern financial system. This vision is kinda slipping away right now...

In any case, I think the approval rating of delegates that we have now is flawed, and something needs to be done about it. I don't think the situation as it is now could be fixed, even if people with a huge stake would get involved (invictus?) because I feel this would just lead to a race to the top where most of delegates would all have > 50% and where the difference between delegates would not be significant enough and would not be very stable. Please tell me I'm wrong.

Try:
curl --data '{"method":"about", "params": [], "json-rpc": 2.0, "id": 0}' http://xeroc:***********@localhost:19988/rpc
seems like the "json-rpc" is not required by the bitshares server (although it's more correct to have it). "id" and "params" are both required (you can set "id" to whatever you want, it's user by the server in the reply to identify the request to which it is responding).

started having problems, so I built from master, clean home dir, and now I get this:
(wallet closed) >>> about
{
  "bitshares_toolkit_revision": "b6aa9950db53ecc9753f7c4cbf2a00a3b6dff800",
  "bitshares_toolkit_revision_age": "50 minutes ago",
  "fc_revision": "6dbcba505b230ee77a0a7fe8af5f5e43c59b0b75",
  "fc_revision_age": "16 hours ago",
  "compile_date": "compiled on Jul  3 2014 at 14:41:17"
}
(wallet closed) >>> get_info
6 key_not_found_exception: Key Not Found

    {"key":31757}
    th_a  cached_level_map.hpp:51 fetch

    {"key":31757}
    th_a  cached_level_map.hpp:52 fetch

    {"block_num":31757}
    th_a  chain_database.cpp:1116 get_block_id

    {"block_num":31757}
    th_a  chain_database.cpp:1101 get_block_header

    {}
    th_a  common_api_client.cpp:1971 get_info

    {"command":"get_info"}
    th_a  cli.cpp:538 execute_command

you can't build the bitshares client on a pure debian stable release (7.x), you need at least the following from testing:
 - cmake
 - gcc 4.8 (important, it doesn't complain with 4.7 but then crashes randomly...)
 - boost 1.55

It is perfectly feasible to mix and match packages in debian, you can use pinning on your packages if you want, the solution I used myself is very simple. Install debian stable, install all the stuff you think you need. Then add the testing repositories to your sources.list, apt-get update and apt-get install the rest. Then you can comment again the testing repos in your sources list and you will have gone back to a system that's mostly debian stable, with the selected packages from testing.

Quote from: xeroc on June 26, 2014, 01:48:09 pm

Quote from: bytemaster on June 26, 2014, 01:38:45 pm

This is good news:  the forks that have occurred are not for differences in evaluation logic, but instead purely differences in timing / communication.

.. take your time .. we can go on for another 10 testnets .. I like seeing progress like this!

Can't imaging a product that is as stable and fast and reliable .. as what you are producing here .. !!

Quote from: wackou on June 26, 2014, 10:41:48 am

Quote from: liondani on June 26, 2014, 10:24:42 am

Please sent some funds to:

XTS8DpkcmJNTMnWE4hjwWQMz119XLZMm8PXFYDW88sTaLtGTSr364   liondani

sent you 100 XTS

thanks 

but because the account schould be a delegate I don't see the funds...
and the same time I don't see my account's on the directory>registered list as in past!...

well actually you don't see the funds because the transaction is still pending, looks like it got stuck while a fork happened at block 359. Sent another 100, let's see if it goes through this time...