Math majors, please correct me if I'm mistaken, but by my calculations, we won't be able to handle C0 speed data in CPUs until we hit 15 Phz (Petahertz) ( or 15,000,000 Ghz ) clock frequencies AND data/memory operations take 1 cycle, assuming 20 nanometer scale.

While we haven't seen the Lorentz factor (1) (mass expends to infinite as speed of light is approached), we're still only 3/15000000 of the way there. If Lorentz was correct (his theory can't be proved until we reach the speed of light or very close to it), then we'll never be able to compute at C0 speed, or even 50% of C0 speed AND convey information.

I suspect he's not, since, as I postulated above, the speed of light is NOT fixed but relative to our inability to measure in field with a refractive index less than 1.

I also believe that the reason we use a refractive index of 1 for a vacuum and not 0 is to allow for the possibility of finding a field with a refractive index of less than 1.

References: (1) http://en.wikipedia.org/wiki/Lorentz_factor

Looks exactly the same to me.

I can see the new page if I view it in an Incognito window (Chrome).

Name.com has a robust API. Godaddy has one through WildWestDomains.com, but Name.com is a better business partner.

thank you.

Genius idea. Pure genius. Kickstarter has shown that they are less about ingenuity and more about public opinion. I hope your project gets funded 10x.

Another version with faster CPU... http://store.vizio.com/ct15a2.html

Some good points, not all correct.. but we're seeing some major sites out right now that, if I were invested in them at the VC level, I'd be looking at the CTO to justify their decisions for using Heroku/AWS without at least a non-cloud backup. I may even be looking to fire someone.

>> Kudos, you also worry about hardware all of the time

Patently untrue.

I haven't thought about hardware once in three years because I have an admin whom I've personally trained that worries for me. He knows how to scale hardware and software because I've showed him how to do it properly, and he has earned my trust.

I get to spend every minute of every work hour coding solutions. If you're a business owner and YOU still worry about hardware, then you need to fire your admins and hire rockstar-level admins. My admin spends no more than 2 hours a day on colo management because he does it the right way.

>> Congrats. Inevitably, a UPS will overload, a switch will die & you'll eat some downtime too. It happens -- build redundancy into your application / service to ensure that thy facility is irrelevant when the time comes.

I use external DNS to handle dynamic re-routing to an alternate colo should connectivity or power to this one fail. Even with this setup, it would cost more than 2 times as much to do what I do on the cloud, even if I used EC2 committed instances.

What's important is NOT to have NO downtime. What's important is to be PERCEIVED to have no downtime.

Customers should never see downtime from you. It should be transparent to them, giving you a 100% uptime public personna.

>> Some good points, not all correct.. but we're seeing some major sites out right now that, if I were invested in them at the VC level, I'd be looking at the CTO to justify their decisions for using Heroku/AWS without at least a non-cloud backup. I may even be looking to fire someone.

And I'd be asking why they don't have redundancy.

>> I haven't thought about hardware once in three years because I have an admin whom I've personally trained that worries for me. He knows how to scale hardware and software because I've showed him how to do it properly, and he has earned my trust.

But not everyone using heroku / aws / etc. have this same guy, trained by yourself, available. Thus, they use a service that makes that aspect of it invisible to them.

Downtime still happens irregardless.

>> I get to spend every minute of every work hour coding solutions. If you're a business owner and YOU still worry about hardware, then you need to fire your admins and hire rockstar-level admins. My admin spends no more than 2 hours a day on colo management because he does it the right way.

Admittedly, I don't worry about it as much as I'd let on -- but there's still some aspects that I dig into by choice to make certain everything is in good working order, and that there are ample replacements on-site to mitigate the 'worst case scenario'. As a CEO, I fight on behalf of my users & clients daily, even if that means wasting mental bandwidth on what might be defined as someone elses' job.

In a perfect world none of us would have to worry about hardware or downtime. Heroku is responsible for Heroku, and AWS is responsible for AWS -- and every user thereof is responsible for themselves and their operations.

Colo. might be the answer for some of them, but it's not a perfect world either.

Well said.

You want to use UTC and convert it to your local timezone using functionality provided in most of todays languages.

For example, in PHP, you could use gmdate('Y-m-d H:i:s') to get the current time/date in UTC.

In Python, you could use datetime.datetime.utcnow().

My brain feels refreshed! Thanks for the playtime! :)

Sure it will work, for a few weeks.

Make sure you print on BOTH sides of the ad so the people in the buildings above can see it too.

You'd want to run this operation from the rooftop of a building, not the ground.

You'd also want to augment the quads so that when they reach a low battery threshold, they return to the rooftop automatically for new batteries or a new ad.

To ensure they don't collide, you could use simple IR transceivers on the sides of the quads to allow them to maintain optimal distance at all times.

Finally, if you want to get REALLY creative, you could adapt gyros to the quads to allow them to stay perfectly still, even in high winds.

Rain would now be your biggest foe.

They're still accepting accounts... Very odd. Stripe is a lot easier to use, IMHO.

Yeah - unfortunately my customers will likely have existing merchant accounts setup that they want to use, which Stripe doesn't support.