219 karma · joined September 7, 2010
http://library.linode.com/troubleshooting/using-lish-the-lin...
I've completely ruined networking and disabled root logins on a Linode VPS, but could still access that same VPS as root using Lish.
From http://code.google.com/appengine/articles/life_of_write.html
There is an expected failure rate on writes as Bigtable tablets are sometimes unavailable, for example, when they are being moved or split. The presence of more indexes increases the probability of hitting an unavailable tablet as an exception will be raised if a write fails for any of the indexes. In those situations, your application will need to decide how to handle the exception. One option is to add a task to the task queue to retry the write at a later point in time. Another idea would be to respond with an error from the app and have the client retry. This tends to work with things like AJAX requests where there is client side logic which can handle an error message from the server.
(Comments like this make me want to stop reading Hacker News.) Just because the "gunpowder" is expensive doesn't stop the production of containment vessels or delivery mechanisms:
http://articles.sfgate.com/2004-10-04/news/17447495_1_antima...
http://en.wikipedia.org/wiki/Antimatter_weapon
Additionally, "antimatter" can include positrons, which are much cheaper to produce than antiprotons.
My advisor also worked on creating antimatter traps at government labs, but none of the projects had any kind of defense related purposes.
Your advisor may not have been involved in all imaginable projects related to antimatter.
There are only a handful of interesting research questions about antimatter that exist at reasonable scales. Most of those are either fundamental physics or medical in nature.
Along with research into directly producing weapons, antimatter can also be used to initiate (micro)fusion, and has been researched for space travel: http://en.wikipedia.org/wiki/Antimatter_catalyzed_nuclear_pu...
RubyPay was a points based payment system for digital content that anyone could use. Points were bought for cash, and redeemable for cash. It was released because we wanted to generate some feedback on the model.
RubyPay was closed so quickly because we realized some problems, and didn't want any live transactions going through our system that we'd later have to refund. Among some of the problems were:
1) allowing anyone to sell content without a screening process for them or the content
2) allowing consumers to redeem the points for cash, which brought a whole new set of laws into play
3) not anticipating all of the ways that fraud could propagate through the system
We're currently working on the service to address these and other issues. We've also discussed the business further with lawyers, became PCI-DSS compliant, and are in the process of forming industry partnerships. As always thanks for the feedback (there was another discussion thread on HN too), it helped us quickly pivot and iterate on our model, and probably saved us tons of time and headaches.
2) Have more free options available for small businesses and teams running the .NET stack. BizSpark is a step in the right direction, but for cash-strapped startups who want to test ideas out in a production setting, it still doesn't compete with the free open-source alternatives.
3) Focus more on getting program installations done right. For example, SQL Server 2008 has taken a step backwards in terms of installation. Errors happen quite frequently during the install/upgrade process--it shouldn't take several hours of fighting one installer to get it working properly.
4) For popular third-party programs that work correctly with Windows, it would be nice if Microsoft had an online database of checksums that Windows can transparently check the program against. If everything looks good, don't present the user with "Confirm/Deny" choices, just install it. Otherwise users become jaded and used to clicking on "Confirm" even for popups that require more thorough inspection.