jaylevitt

Some history, for those not in the know:

http://www.techdirt.com/articles/20110707/03264014993/riaa-a...

http://www.techdirt.com/articles/20100712/23482610186.shtml

http://www.salon.com/technology/feature/2000/06/14/love/prin...

Spoiler: bands get about 20% of what the label gets. Your album can sell 1 million copies and your band might still owe the label $500,000. Labels take 10-20% off the top for breakage fees. Breakage. As in vinyl records that broke during shipping.

Picture of Don Walsh or Jacques Piccard, first to descend into the Mariana Trench?

Actual recruiter cold-call question in 2011: "So Rails, is that like Java?"

I'll bite - what parts of the patent can't be done with bog-standard techniques? I took a look and it seems obvious in retrospect, though so many things do.

A few years back there was a theft ring in Boston that stole HID headlights from Audis. I put a sticker on mine...

WARNING: DEFENSIVE SPRAY MAY BE HARMFUL OR FATAL

Nobody touched them.

Wait - didn't he have a photo that showed the employee tearing up his documents?

Doesn't that mean the McDonalds executive is outright lying?

Since Thunderbolt is also some sort of PCIe port, couldn't you have the GPU be internal to the Cinema Display, and transmit only the GPU code over Thunderbolt? Or are significant parts of the screen drawn by the CPU directly these days?

True - it's a marketplace, eBay for livery services.

No, monit doesn't manage services. Monit tries to follow clues you've given it about what's running, it polls them once in a while, and if something appears to be not running (as measured by the instructions you've given it), it runs the one-liner you've given it that should start the thing up again.

Monit does a thing that approximates managing a process, for certain values of "approximates", "managing", and "process". Supervisory process management is one of Linux's absolute weakest points. I cut my teeth on fault-tolerant HA minicomputers, and it pains me to think that 30 years later, we still don't have a way to say "make sure apache is always running. period."

As a great blog pointed out, there is exactly one process that KNOWS when a service has stopped running, and it doesn't need .pid files or polling or anything else to tell it: process 1.

I'm not a systemd advocate - I don't know enough about it, and we're using Ubuntu so I'll end up learning upstart anyway - but read this, it's way more eloquent that I can be:

http://dustin.github.com/2010/02/28/running-processes.html

Boston has standardized on a way of metering taxis.

Taxis get a government-sponsored monopoly - a limited-quantity medallion - which allows them the right to pick up a passenger anywhere in a given territory (e.g. Boston, but not Cambridge). In exchange, they are required to pick up ANY passenger when on duty (they cannot legally decline to drive you somewhere), and they are required to charge you pre-determined rates as measured by a pre-determined meter.

Livery, or "black sedan" services, are not permitted to pick up arbitrary passengers who are hailing a cab. However, they are also not required (or allowed) to have a medallion, and they are not bound by any metering or pricing regulations at all.

I believe the theoretical distinction is that when hailing a cab, you are in a position of no negotiating power - you are limited to whatever cabs happen to drive by. "Being able to hail a cab" is a public utility. So the city has pre-negotiated a generally acceptable contract.

In contrast, you (pre-2012) are negotiating a contract with a livery company. You can choose any livery service you want from a phone book or directory, you can ask about their rates, pick a specific time, perhaps choose the type of car, etc. There's no "certified" locked meter, because the price is something you negotiate, and you have a choice of vendors.

Here's where Uber flips the industry on its head. Medallion owners tolerated livery companies, because without the medallion, livery services were restricted to pre-arranged rides, and most livery services couldn't offer a large enough fleet to provide low dispatch times without advance notice.

Uber forms a communications network linking ANY interested livery driver with ANY interested passenger. You pre-arrange the ride, but you pre-arrange it minutes before pickup. And Uber provides an Internet-era dispatch system; they've replaced grumpy dispatchers, two-way radios, and kickback systems with two iPhones (yours and the driver's) with built-in GPS. They can route your "call" directly to the closest in-network driver. Uber isn't a florist; they're FTD.

As far as I can tell, Massachusetts doesn't have any statewide regulation of livery services; each town has its own rules. Worcester apparently had a "12-hour rule" that defined what qualifies as a "pre-arranged ride", but that's been suspended or something.

So IANAL, but here's the situation as I see it:

- Uber isn't operating a livery service, period. They provide a dispatching network that's used by licensed livery drivers. - Livery drivers don't have to use any kind of meter. They charge a negotiated price. With an Uber driver, you have negotiated a price based on "mileage as the iPhone GPS records it".

Which gets back to "which measurement devices used in trade are regulated in Massachusetts"? See my cup-of-dice comment elsewhere.

OK, but how does MA decide which equipment is considered a measuring device used for trade? Are grocer's scales and gas pump meters a special case that's explicitly regulated, or is anything that (a) takes a measurement while (b) in the path of a transaction regulated?

My supermarket sells cheddar for $8/pound. When they take some cheese and price it, the scale that decides it's 8 oz of cheese is a regulated scale.

But my co-worker's friend sells D&D dice for $5/cupful. Is that cup a measuring device that would technically need to be certified by DWM for trade use?

And if not, what is the bright-line test for whether the Uber app is a cup or a scale?

More importantly, Uber is neither a cab NOR a private car service.

It's a communications network that links private car services with people who want to get a ride from the private car service.

Sure, but Akamai is the "big iron" of CDNs - you can run your own custom code in a JVM at their edge locations. So I kinda think anyone in the market for Akamai isn't getting SSL termination advice on HN :)

As with any archival storage system, the CAP theorem applies. Clay, Acid-free, Papyrus: pick two.

What if they hire some stats bloggers and become the next Nate Silver - only with analyses that WE can all interact with and learn from?

What if this could improve statistical literacy?

"We often see rudiments of various parts in monsters."

I must ask: What animal was it that, in those days, was referred to by eminent scientists as "monsters"?

What? How many former KGB agents do you know, period?

Similarly, we don't know the names of any of those executives. That means we don't know if we currently work for them. If we work for other executives, we shouldn't assume that we can generalize this story to our experience!

In fact, since the odds of this exact management team starting a new company in exactly the same industry with exactly the same business model are close to zero, I think we can agree that it would be impossible to learn anything from this story even if we DID know all the details.

I think you're trying to argue (in multiple responses) that the evidence in the article doesn't rule out all other hypotheses, so we shouldn't take it as proof.

Sure.

It's not a formal proof. It's a narrative of a general pattern that we might want to learn from. If we can learn from narratives that are completely false - raganwald's excellent posts come to mind - then surely we can learn from narratives that are not scientifically rigorous.

I think we're all conflating "worst case" with "common case" of Save As and Duplicate.

In the worst case, the traditional filesystem behavior could lose your data if you accidentally hit "Save" instead of "Save As". In the common case, it let you save off new versions without affecting your existing version.

The (Mountain) Lion paradigm removes the worst case; you can always revert and recover. But the behavior of the common case gives the appearance of lost data, and violates both Principle Of Least Surprise and Do What I Mean.

Is there something fundamental about the API that makes you say that, or just understandable cynicism?

Robotically offering me a box seems significantly easier than robotically driving a freaking van.

I once had a co-worker, LS, who insisted on never saying the word "problem"; everything was a "challenge". Always. If the data center exploded in a fiery ball, we were experiencing massive system challenges.

I bet our VP of Operations a hundred bucks that he couldn't get LS to say the word "problem". Without missing a beat, he turned to LS and said "I'll pay you fifty bucks to say the word 'problem'." And he did.

So while I support your quest for transparency, I really can't participate - it's proven expensive for me.

...so that Fortune could publish an article saying he followed industry-standard guidelines of responsible disclosure, so that non-techies wouldn't get further ammo to say "there ought to be a law against this."

People already lie to themselves and are lied to. Millions of years of evolution have given us a brain with a remarkable ability to heal over any damage to its worldview. (See _Phantoms in the Brain._)

AR is not the gating factor here.

You're thinking too hard. He's using "blend" mode and he needs to use "dodge". Or maybe it's "burn", or "dissolve".

Has Amazon ever bumped the specs on existing hardware types? Or do they just create new hardware types? e.g. is it possible that if you get a 3-year reservation for an h1.xlarge, by 2015 h1.xlarge might have newer specs?

I had thought that EC2 reservations were upgradeable, but a quick check on the forums shows you're right, they're not. Of course, you can play your own "tiered usage" game, like laptops in IT departments, where the old h1.xlarge becomes cheap enough to use as a second-tier machine and you go reserve the h1.xxlarge for Cassandra.

There are also the network benefits (pun intended). If the rest of your app does benefit from elasticity, you've had to choose betwen:

1. Keeping your app on EC2 and working around the lack of high I/O options 2. Keeping your app somewhere else and working around the lack of EC2-style elasticity

In TFA, Netflix had chosen #1, and they used to run an extra memcached layer + I/O on 48 instances. They were able to bring this down to 15 I/O instances with no intervening cache, and lower overall latency.

That said, I'd guess the on-demand hi1.xlarge won't get a lot of usage; I imagine they offer it just for orthogonality's sake (all other instances are available both on-demand and reserved), plus the ability to try before you buy.

What's really exciting is that Amazon clearly recognizes their lack of good I/O solutions. Maybe we'll see a whole range of options stem out of this... one can hope.

First of all, no, it isn't. At a large enough scale, any metric that goes up with usage is a perfectly fine proxy for many conversations. Every day for a decade we had the same 3% of our user base online at peak doing the same transactions as yesterday. Over longer periods, the number crept up and the transaction mix changed, but "number of simultaneous users" got me accurate, if not precise, capacity planning from 27 to 1.5 million users.

Stress-testing, shared-nothing and dollar-scalable are platonic ideals, and they're not always achievable. If Dropbox had three infrastructure engineers, they probably weren't able to build proper capacity planning models, and probably couldn't afford to build a full production work-alike for stress testing anyway. (And at some scales, that's literally impossible. Our vendors couldn't physically manufacture enough servers to build a full test environment, cost aside.) I'm sure they did some simulated tests as well, but those won't tell you the whole story.

You're focused on IOPS, but you have no idea if that's what Dropbox's bottlenecks were. (Not to mention: What does IOPS mean on an EBS and S3 infrastructure?) Complex systems fall over in complex ways. You can predict the next bottleneck, but not the one after that; by the time you get there, your fix for the first bottleneck will have changed the dynamics.

It sounds like they did do stress testing, using real-world loads, on a system that was 100% similar to their production system. They ran continuous just-in-time stress tests in the Big Lab.

If your system is complex, you don't know what your capacity is, or whether the curve has a sharp knee. Think of disk I/O; if 100K simultaneous users keep your disks 50% busy, how many simultaneous users can you actually support? The answer is not 200K; the answer is "it depends".