The way Schrodinger said it
"Thus, the task is, not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees."
903 karma · joined April 15, 2011
Slicehost founder, Rackspace Alumnus
jasonseats.com
"Thus, the task is, not so much to see what no one has yet seen; but to think what nobody has yet thought, about that which everybody sees."
For us at Slicehost, we had an amazingly fortuitous start, due in equal parts to strategy and luck. We saw pretty clearly that rails was picking up steam really quickly and the hosting options were pretty shitty (shared hosting at the time didn't support the versions of ruby and rails people needed not to mention the memory hungriness of the framework and dedicated was still fairly pricey with 100-200/month being dirt cheap).
So we picked a really ripe initial niche market to spend time making ourselves visible in, which we did in forums, chat rooms, etc. The luck came in that we got some pretty vocal early customers who all had a great experience and evangelized us. That was lucky because either of those factors could have easily gone the other way. They could have been quiet customers or we could have had early blips in service (we had plenty of later blips, we just had a nice patch of initial smooth sailing).
Not in the cards for me. Technically still under non-compete, but even if that weren't the case at this point I am connected to so many other hosting providers that I'd rather just support them in doing the right things and work on other stuff. Right now I run a startup accelerator and am spending my time as a full time seed stage investor.
What's your beef with the Rackspace service right now? As far as 'big' providers, besides the obvious AWS and Rackpsace, you should also consider SoftLayer and Joyent, and depending on what you are doing the PaaS providers are all getting pretty solid now - Heroku, AppFog, DotCloud, GAE even Azure (node is a first class citizen on Azure now).
If you want something that feels really VPS-y that is run by a Slicehost-style team, Linode is a definitely a solid option (mentioning them first since this is their thread). I also am a fan of DigitalOcean (they went through our accelerator and I've spent a lot of time with them), and 6sync is run by Mario Danic who was a super active early Slicehost community member.
Regarding the guaranteed capacity, this is another one we spent a lot of time thinking about. At the time EC2 made the call of guaranteeing CPU share by hard-limiting the ceiling of performance by any VM. We (slicehost and RAX) took the opposite approach of weighting CPU by vm size when under contention, but allowing for burst-ability to full core power when the box was idle. That meant that in the case of low-ish utilization customers Slice/RAX VMs had a higher higher average performance but EC2 had more predictable performance.
It's a super interesting tradeoff. People would benchmark us and we'd come out way better one day but not so hot the next and that was the reason why. The flip side of that was that EC2 is stranding CPU capacity on physical hosts that are full of underutilized VMs. Even without us describing this well to the market, customers and workloads adjusted and customers and use cases migrated to each provider according to better fit (higher 'average' performance with tolerance of variability go to RAX, hardline predictable guarantees go to EC2). We had some video transcoding services that could not deal with the volatility and preferred lower performance that was predictable (and therefore kept a lot of workload on AWS).
A similar tradeoff where AWS did it one way and we did it the other is around the expectation for persistence on local disk versus ephemeral VMs. Persistence (what we did) was more like what people were used to. ephemeral is more 'cloudy'. EBS as well as hosted datastore services mitigated the difference, but the AWS approach required legacy customers and applications to re-architect for cloud and ours was more friendly to the transitional customers or people that just wanted classic feeling hosting on demand. The AWS bet was right in the sense that more of the usage of cloud (and everything actually) is in the future and not the past, and the choices we were making were more as a gap solution (but with eyes wide open about that).
The real issue is hardware skew. We like to buy/sell and build on cloud as if it is a pure utility where every unit is equivalent, but every year processors change, go EOL, etc. As a provider you have to make a call about how much of that complexity you expose to the end customer. Some customers want complete transparency, which I understand, but the downside of that is hundreds of variations of pricing options and complications around managing heterogeneity (e.g. how do you represent simply how much available capacity there is when you effectively have 300 variations of the same 'size' instance).
Of all the component parts of compute, CPU is the one that changes the quickest. Disk capacity is easy to model, disk throughput has changed much at all (minus the introduction of SSD), memory is pretty stable (minus some increases in databus rates). All in for the typical instance in a multi-tenant virtual environment, the same today as in 2006, the two most vaguely defined attributes are cpu and i/o. With the increasing use of 10gigE as well as SSD, hopefully we finally push through the i/o piece. Not sure what it will take to get us there for a clean way to model and describe 'standard cpu' as a provider.
Also, if anyone has specific questions about Slicehost cpu priority handling circa 2006-2008 or Rackspace Cloud Servers cpu pre OpenStack, just ask and I'll be happy to answer.
Otherwise, your best bet for getting developers to buy things is to try and sell them stuff that would be boring for them to build. Most developers I know would find it very interesting to build something with machine learning or to re-architect a system several times over for scale. Not many of them would like to spend time building something better than textmate.
The problem with being a developer building for developers is that if you are interested in working on a problem your customer probably is too. People would prefer to pay you to take out the garbage.
Makes me wonder if there isn't an antitrust case here somewhere. Feels highly predatory by music license holders.
That upper end is a bit of an outlier, but it happens enough that it's not entirely rare. The median company probably has some type of prototype and is pre-revenue.
Relocation is not a must. The program does take place in Texas and in order to get maximum value, it's worth trying to figure out how to be here for the full 3 months, but there is no firm requirement and we have had success with a 'commuter' team that would come for a few weeks at a time alternating. Best case scenario, you move here for 13 weeks. One of our prior founder's wife back home called us 'internet camp'. I like to think of it more as a monastic retreat for startups ;)
If anything I think both YC and TS just reflect the wider market with some extra noise and ideally better outcomes.
I've only run 1 program thus far and it only completed 3 months ago. Wouldn't expect to see much in the way of exits after 3 months ;)
One interesting point to add though is that only integer spin particles (the force carrying bosons) can share quantum states, which means they can occupy the same point in space.
Another way to say that is to say the opposite, i.e. that half-integer spin particles (the fermions, which includes quarks that make protons and neutrons as well as leptons like the electron) cannot occupy the same quantum state as each other, which is manifest by them obeying the pauli exclusion principle.
So if you were to take two photons they can literally occupy the same point versus two electrons which cannot (with some exceptions noted below). They are both point particles and technically have no volume, but there is this extra rule about quantum states that prevent two electrons from sitting in precisely the same place if they share all other quantum characteristics.
Since this rule applies only if those electrons share all other quantum states, that means that if two electrons have opposite spins, they can occupy the same point in space. The first valence shell in a atom is the lowest state that an electron can have in a stable orbit (think of it as a standing wave that exactly lines up in a circle). There is 'room' for only one electron when you view the electron as a wave, but that shell can hold 2 electrons because there can be one of each spin type.
Anyway kind of long winded, but I think the exclusion principle is at the heart of what makes us intuitively think about the electron as having volume in space and a photon as not.
All this stuff is really really cool, but you can tell why physicists have that itchy sensation that there is some deeper explanation that is underneath all these rules.
Interestingly AWS appears to be in the camp where it's not heavily focused on uptime either.
A pretty universal truth is that you can afford to be down more than you expect. Even in the cases of Amazon's store being down when you can measure the immense cost by the second, a total cost analysis may still well show that it was a 'cheaper' event than engineering away.
One huge winner could randomly happen in an otherwise low-quality program and that incubator would appear higher on rankings forever after that unjustly since the result is very much not reproducible. In other words measuring by average could mask getting lucky.
Last week I visited the white house as a part of this program -> http://www.businessfwd.org/
The two topics I brought up with the administration were patent reform and immigration reform. Brought up all the obvious issues that play on HN frequently. Today I got a follow up email intro to someone at the USPTO and here's a copy of my reply to that person. I also pointed him to the defendinnovation.org.
Text of my message to USPTO----
The main concern I brought up during the white house visit was around software related patents and frivolous lawsuits by trolls. I'm sure you get this question often from technology and startup folks, but in my opinion it's pretty clear that the USPTO is effectively levying a giant tax on output of my industry due to issuance and complicit enforcement of patents around elementary concepts.
To me the biggest costs to our economy come in the form of -
- fear of patent conflicts prevent new companies from doing truly novel things that would generate jobs and innovation
- costs of licensing patents from trolls or patent groups impede growth of companies at the most delicate nascent stage (e.g. MPEG-LA or Intellectual Ventures)
- settlements out of court with trolls and/or direct costs of litigation to defend (for the bravest large companies who want to take a stand, e.g. google)
- giant piles of money burned litigating frivolous patent disputes between large companies as a proxy for competing directly in the market (oracle vs google)
In general software patents attract the worst elements of the free market. People and companies that take advantage of the system, who extort, abuse and profit from the structural deficiencies of the USPTO. A typical patent troll group will acquire a set of frivolous software patents covering concepts in use in literally any major piece of software so that technically every large company is an infringer. They will then approach a set of large or medium companies with a veiled threat and offer to sell a share of the patent troll entity. They give a choice to their target to get on board or take an ethical stand and if the victim chooses the later, they'll get sued for infringing and likely be forced to settle because truly there is infringement according to the drafting of the patent that was granted. It's the modern mafia.
The root cause of all of these problems are two fold
1 - granting of patents for non-novel and trivial software and concepts
2 - inability to efficiently litigate and have a patent invalidated by demonstrating that it is truly trivial
Google is a major force of good in this fight and the Oracle litigation has shown my industry a great deal of hope on this front. In particular Judge Alsup on that case showed a very keen understanding of the technology in question and how ridiculous the patent was that Oracle litigated with. That story had a happy ending, but honestly in large part because of that one judge. If this were a different court there could have been a vastly different outcome.
http://news.cnet.com/8301-1035_3-57445082-94/judge-william-a...
My question to you is simple - How can we address these root causes?
The current patent system and review system was not designed for software and is clearly failing to adapt to the current environment and pace. USPTO is granting patents at an ever increasing rate. We quite literally are in such a broken state that I would wager that every piece of software being sold today is infringing on some patent. How long until that structure completely halts the development of any innovation at all?
Too big of an issue to ignore. Thanks for listening.
That part resonated with me and after parting with my company was something I definitely missed.
If you receive a positive response at 4ft, move in to ‘arm’s length’ (about 2ft 6in)."
Reminds me of the "How To" Goofy cartoons -> http://www.youtube.com/watch?v=xxeL9bdSu-A&t=102
Is the timing attack hardening suggested in the blog post a standard approach?
If I was trying to attack a system and knew loosely that they did what he suggested (hashing then comparing vs comparing with timing exposed) , my untrained instinct would be that this is the weakest part. In other words I think this just makes the timing attack a little more difficult, but still possible, by producing specific hashes that carry out the timing attack.
When I've needed to harden comparisons against timing attacks, I've always just used constant time comparison functions, such as these ->
http://codahale.com/a-lesson-in-timing-attacks/ http://rdist.root.org/2010/01/07/timing-independent-array-co...
The intention is to increase capital available to startups because of the extra tax incentive for investors.
The highlights of the act, which include many of the suggestions in this thread-
1 - Create a new STEM visa so that U.S.-educated foreign students who graduate with a master’s or Ph.D. in science, technology, engineering or mathematics can receive a green card and stay in this country where their talent and ideas can fuel growth and create American jobs.
2 - Establish an Entrepreneur’s Visa for legal immigrants so they can remain in the United States, launch businesses and create jobs, and eliminates the per-country caps for employment-based immigrant visas, which hinders U.S. employers from recruiting the top-tier talent they need to grow.
3 - Make permanent the exemption of capital gains taxes on the sale of startup stock held for at least five years, so investors can provide financial stability at a critical juncture of firm growth.
4 - Create a targeted research and development tax credit for young startups less than five years old and with less than $5 million in annual receipts. This R&D credit is designed to allow startups to offset employee taxes, freeing up resources to help these young companies expand and create jobs.
5 - Use existing federal R&D funding to better support university initiatives designed to bring cutting-edge R&D to the marketplace more quickly, where it can propel economic growth. Require government agencies to conduct a cost-benefit analysis of proposed “major rules” with an economic impact of $100 million or more.
6 - Direct the U.S. Department of Commerce to assess state and local policies that aid in the development of new businesses.
(a) http://polis.house.gov/News/DocumentSingle.aspx?DocumentID=2...
In thinking about this, I wonder if in that scenario you'd even have to wait until next login. You could just use the weak hash as the input to your salted hash function and keep a flag of whether or not you need to 'pre-hash' the password before using your v2.0 salted hash. As users log in you could replace slowly replace the double hashed entries with single salted hash versions and flip the flag.
"PayPal, at Luke Nosek’s urging, became the first company in the history of the world that had cryogenics as part of the employee benefits package. There was a Tupperware-style party where the cryogenics company representatives made the rounds trying to get people to sign up at $50k for neuro or $120k for full body. Things were going well until they couldn’t print out the policies because they couldn’t get their dot matrix printer to work. So maybe the way get biotech to work well is actually to push harder on the AI front."
>> The "30 bits of security" means the chances of a single guess cracking a four-word passphrase would be one in 230. What's more, the two-word phrases cracked in the study provided just 220.8 (or 20,656/0.0113) bits of security. Another way of expressing the same finding is that a dictionary of slightly less than 21,000 phrases is enough to guess the login credentials that slightly more than 1 percent of people in the real world will use.
To be sure, that's a vast improvement over the security of normal passwords. Analyses of compromised passwords leaked onto the 'Net, including a corpus of 32 million plaintext codes dumped following the 2009 hack of online games provider RockYou, show that it's trivial to crack a sizable proportion of real-world codes. A dictionary of just two of the most common passwords—123456 and 12345 respectively—typically guess 1 percent of login credentials.
Say what you will about TED and TEDx being elitist and uppity, but I think it's fair to assume that was an educated audience. How was that not perceived as complete absurdity in the moment by the crowd?
It wouldn't be overwhelming to new users if they had examples of what a memorable passphrase is. You'd likely need to disallow specifically using the example passphrase but other than that, I'd be curious to see how well non-technical users respond to an interface asking them for a phrase.
>> The numbers on and analysis of his tax liability in the article are demonstrably wrong - at a level of error unworthy of The Economist. His tax liability is calculated on the value of the stock as of the date he renounces citizenship, which was last September. Today, Facebook is worth maybe $100 billion. Early this year, a private equity offering put the value at $50 billion. Last fall, who knows, and it's all subject to negotiation with the IRS - my guess is no more than $25 billion. That means he evades 75 % of the tax bite by renouncing citizenship, and will be paying at most maybe $125 to $150 million of that $500 to $600 million tax liability he would owe if he sold all his stock next week.