cloudrck

Yeah, Litecoin seems pretty legit. I should be getting 830Kh/s and up with the R9 290

Have you looked into making a plugin for GoCoin? It would cover Bitcoin and Litecoin? I'm looking at the API now. Also, I ordered an AMD 290 from shopblt.com so I can do some real mining. Can't wait until it ships.

Simply because they can, they have little incentive to stay on top of the ball with the market share they have.

I kick myself for not paying attention to Bitcoins when it was piratical to mine with common hardware. This is why I'm serious about Litecoin and may look into Dodgecoin. http://www.washingtonpost.com/blogs/style-blog/wp/2014/01/21/dogecoin-helps-jamaican-bobsled-team-in-its-quest-for-sochi/

That's what I was thinking. Seems I'm too late to the game with SHA256. I may stick with scrypt Also, I should add my earlier settings gave me a high number of hardware(HW) errors. So I was wasting mining time. This seems more stable @ 120Kh/s export DISPLAY=:0 export GPU_USE_SYNC_OBJECTS=1 export GPU_MAX_ALLOC_PERCENT=100 cgminer --scrypt -o stratum+tcp://lite.wemineltc.com:3334 -u cloudrck.1 -p x -I 11 -w 64 --shaders 512

In order for any currency to catch on, there needs to be business and consumers that take the initiative to utilize them and make it a viable option. Has anybody looked at the ASIC hardware platform for bitcoin/sha256 mining? I saw a $60USD USB ASIC miner that gets 1.6+Gh/s that uses 2Watts of power. So far there are no scrypt miners on the market, but there is a company that is releasing one soon. Edit: Just got an email saying Tigerdirect accepts Bitcoin

I bumped up the engine clock from 800Mhz to 900Mhz, upped the voltage +0.025 and changed settings to cgminer --scrypt -o stratum+tcp://lite.wemineltc.com:3334 -u cloudrck.1 -p x -I 13 -w 128 --shaders 512 --thread-concurrency 4000 Now I'm getting 150Kh/s with a 4 degrees C increase in temperature at the moment.

Interesting, I may need to increase my voltages/OC a bit. I haven't increased my intensity past 13 yet. I may try before I leave tomorrow. Right now it's fine at 13 allowing me to use my desktop without issues.

I got a low profile video card, so it doesn't have the "umph" the regular cards of my series have. Which one gives you better results, cgminer or bfgminer? Mines are export DISPLAY=:0 export GPU_USE_SYNC_OBJECTS=1 export GPU_MAX_ALLOC_PERCENT=100 cgminer --scrypt -o stratum+tcp://lite.wemineltc.com:3334 -u cloudrck.1 -p x -I 13 -w 128 --shaders 512 --thread-concurrency 4000

Yeah I bought my Radeon 7750HD for gaming a couple years back. I haven't had time to tweak anything and I just started a few days ago but I get around 135Kh/s using Cgminer on my Linux desktop. What mining software and settings do you use?

Hey you want to move our conversations to another off-topic category, I feel we are hijacking this guys thread? What GPU do you use?

Mining for bitcoin is extremely impractical unless you have a ASIC, if you want to mine with standard hardware, I would go with Litecoins and/or Dogecoin that both use scrypt.

Thanks but no dice. I'm going to try to use blesta on a non-SSL setup and dig deeper, this is going to be "one of those issues".

Thanks for the reply, this is what I have https://github.com/cloudrck/blesta-nginx/blob/master/sites-available/blestav3 In addition, I added client_max_body_size increased to 3M or more with the same results.

Does anyone else have issues trying to upload files via the Support Manager in Blesta? Uploads work fine using Nginx/PHP and Nginx/RoR with plain HTTP. But with Blesta and HTTPS it doesn't seem to work. The folder is writable. Blesta gives this error Nginx logs 2013/12/17 08:14:51 [warn] 2651#0: *50775 an upstream response is buffered to a temporary file /var/lib/nginx/fastcgi/7/05/0000000057 while reading upstream, client: 111.111.111.111, server: my.cloudrck.com, request: "GET /admin/clients/viewinvoice/23/107/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "my.cloudrck.com", referrer: "https://my.cloudrck.com/admin/clients/view/23/" 2013/12/18 04:17:46 [warn] 2650#0: *58956 an upstream response is buffered to a temporary file /var/lib/nginx/fastcgi/8/06/0000000068 while reading upstream, client: 111.111.111.111, server: my.cloudrck.com, request: "GET /client/invoices/view/105/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "my.cloudrck.com", referrer: "https://my.cloudrck.com/client/" 2013/12/18 13:29:55 [error] 2653#0: *63423 client intended to send too large body: 1670524 bytes, client: 111.111.111.111, server: my.cloudrck.com, request: "POST /client/plugin/support_manager/client_tickets/reply/108/ HTTP/1.1", host: "my.cloudrck.com", referrer: "https://my.cloudrck.com/client/plugin/support_manager/client_tickets/reply/108/" I've searched online and saw a few people with the same issues but with no solution. This appears to be an issue with using SSL. My client_max_body_size setting doesn't seem to matter.

I don't know why I bother trying to help some people. Not again. And Ubuntu 13.10 is no where near "bleeding edge".

It is in this case. You check relevant logs until you find something useful, I shouldn't have to spell it out. PHP, Nginx, dmesg, syslog, etc. If Nginx is his sole HTTPD than they should be in his sites error_log. PHP depending on his setup. Looks like he got it fixed. May I suggest http://tldp.org/LDP/intro-linux/html/index.html

Check your logs.

This statement doesn't even make sense, you need to re-read what the site says. If you're learning than you need to not accept clients and do research. There are enough inexperienced hosts out getting hacked, we don't need to add more.

You're overlooking the real issue. Whether or not a certificate message appears or not the connection is still unsecure. You don't want to spend $8 for an SSL cert? Then get a free Class 1 at StartSSL. There is no reason to not spend a few bucks for added security. You shouldn't even consider forcing HTTP, if I see someone can't take the effort to get a SSL certificate I move right along. Learn what your Nginix code means and understand what it does before you use it. Than you will understand why it isn't giving you the desired result. Than get a SSL cert.

Yeah I've been looking into this as well. Been meaning to setup a dev area.

This is still present. Can't believe I didn't notice it until now. Easy fix On both: plugins/support_manager/views/default/client_tickets_reply.pdt plugins/support_manager/views/default/admin_tickets_reply.pdt <div> <img src="http://gravatar.com/avatar/<?php echo md5(strtolower(trim($this->Html->_($reply->email, true))));?>?s=120" /> </div> Should be: <div> <img src="https://secure.gravatar.com/avatar/<?php echo md5(strtolower(trim($this->Html->_($reply->email, true))));?>?s=120" /> </div>

Same issue here. The user/pool is created. But not the CT. Found out default template didn't have the right path. Error was:

http://proxmox.com/proxmox-ve/features

You left no alternatives when you incorrectly made assumptions and ignored help. Did you bother to look through your logs as suggested? Suhosin does what it is configured to do, it doesn't know what's valid or not. I would ask for you to post your rules to help future customers who use Suhosin.