Topic: Just received official email from BFL, my Jale's are on the way... (Read 2465 times)

Changed password, made it more random and longer, thanks for noticing everyone.

Woosh, there went their customers passwords.
I hope they salted their hashes. 
I hope they hashed them.

Tell that to Facebook.

The reason Facebook hasn't migrated away from PHP is because it has incumbent inertia (it's what's there) and Facebook's engineers have managed to work around many of its flaws through a combination of patches at all levels of the stack and excellent internal discipline via code convention and style - the worst attributes of the language are avoided and coding style is rigidly enforced through a fairly tight culture of code review (failing to adhere to the style and "going cowboy" by writing sloppy code results in pitiless mockery by one's peers). Engineering management has never had to take a strong hand here; this arose largely due to key internal technical leaders just sort of corralling everyone else along.

There is also a lot of industry precedent indicating that re-writing an entire codebase in another language is usually one of the worst things you can do, so at all levels there is a reluctance to do that. The preferred strategy is to write new components in a de-coupled manner using a better language of choice (C++, python, Erlang, Java, etc); this is easily facilitated by Facebook's early development of thrift, an efficient multi-language RPC framework. This also helps avoid the worst effects of PHP: it can be totally avoided in subcomponents where the language is grossly-unsuitable. The broad effect is that the overall codebase slowly evolves away from depending as heavily on PHP, with the components that are still in PHP being written in tightly-controlled, disciplined ways by veteran members of the staff.

Tell that to Facebook.

PHP isn't very good for scaling, every request is a totally separate action and it doesn't look like they're using caching. What PHP is good for is small stuff because it's quick and easy to understand.

I agree... someone is going to get ... schooled ... tomorrow.  I'm very displeased at the moment.

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[08004] [1040] Too many connections' in /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Abstract.php:129 Stack trace: #0 /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Abstract.php(129): PDO->__construct('mysql:host=loca...', 'zend_admin', '3ErK5wqJ6bTUgxk', Array) #1 /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Mysql.php(109): Zend_Db_Adapter_Pdo_Abstract->_connect() #2 /var/web/bflweb/library/Zend/Db/Adapter/Abstract.php(315): Zend_Db_Adapter_Pdo_Mysql->_connect() #3 /var/web/bflweb/application/Bootstrap.php(203): Zend_Db_Adapter_Abstract->getConnection() #4 /var/web/bflweb/library/Zend/Application/Bootstrap/BootstrapAbstract.php(667): Bootstrap->_initCharsetDB() #5 /var/web/bflweb/library/Zend/Application/Bootstrap/BootstrapAbstract.php(620): Zend_Application_Bootstrap_BootstrapAbstract->_executeResource('charsetdb') #6 /var/web/bflweb/library/Zend/Application/Bootstrap/BootstrapAbstract.php(584): Zend_Application_Bootstrap_BootstrapAbstract->_bootstrap(NULL) in /var/web/bflweb/library/Zend/Db/Adapter/Pdo/Abstract.php on line 144

I agree... someone is going to get ... schooled ... tomorrow.

 I'm very displeased at the moment.

PHP isn't very good for scaling, every request is a totally separate action and it doesn't look like they're using caching. What PHP is good for is small stuff because it's quick and easy to understand.

BTW, disabling diagnostic errors on public-facing sites is COMPSCI101 stuff. If this happened on a webapp I'd worked on I would be fired on the spot.

These database driven sites just don't seem to be able to handle a moderate number of hits without some elaborate server setup.

EDIT: They just said in the shoutbox it has been changed already.

Fer chrissakes, the incompetency...

PDO->__construct('mysql:host=loca...', 'zend_admin', '3ErK5wqJ6bTUgxk', Array)

No, your Jalapeno is not on it's way.

BFL just sent you a nice letter with lots of yadda yadda. The interesting part is this here:

"Please be advised that [1]due to the adjustments described above, we need your confirmation prior to release of your order into the final build queue and on to final delivery.  It may also be a good time to [2]review your purchase altogether relative to the bitcoin market as this is the last opportunity to do so.  If your order is not confirmed, it will be canceled and your money will be refunded. "

They did this because of legal reasons - to be on the save side:
[1] They screwed up power and performance, so they want to get your OK.
[2] They screwed up shipment dates - and know that it will take a long, long time before your units will be shipped - and difficulty will have sky rocketed and you only make a fraction of the Bitcoins that you would have made had BFL shipped on time. They want to get your OK for that too.

Basically it's like a blank check for BFL: "OK we screwed up big time but you have to sign here XXX and confirm that this is still OK with you".

Not that some of you guys come up with the idea of suing them ...  


Wake up, people!
They're doing this not because they are such a customer-friendly company - they are doing this for a reason.