j2d2j2d2

That is correct. However, the purchasing power of non monetary items is not effected by inflation.

I think you're conflating two ideas.

First, inflation internal to the US manifests itself, often enough, as higher prices.

Second, the reason this is good for exports is because it usually also takes less of the foreign currency to purchase our goods.

HTML5 is part of the way there but many browsers still crap out over trivial stuff. For example, for a long time (still might be true), Chrome would go nuts if someone tried to play an audio link that produced a 404 error.

So, this isn't a comprehensive answer, but hopefully shines some light on where HTML5 actually is with regard to providing an experience similar to a native app.

The DMCA provides the clear guidelines you're referring to. Grooveshark also falls back to the DMCA and their willingness to comply as evidence that they are legal.

I think the biggest issue for music startups (disclaimer: I used to work for one) is probably that the startups that try to do it legally and correctly are still competing against the ones that border on being illegal, or are straight-up illegal. Users don't care, but startups might get sued.

All of that aside, I agree that Grooveshark has built a great product. But I'd be kidding myself if I didn't also say the first song I searched for was Metallica and I got a massive list of songs I could listen to. I'm sure they wouldn't be happy.

"I/O has been done wrong for the last 30 years,” he said, referring to the fact that Node.js allows servers to react to specific events."

This statement shows how hype-oriented this team is. Node.js hasn't invented anything new. On top of that, it reimplemented 30 year old concepts badly.

I don't want to start a language war, but a simple comparison of Erlang (which is 20 years old) and Node.js will send this point home:

1) http://stackoverflow.com/questions/3887433/advantages-of-erl...

2) http://journal.dedasys.com/2010/04/29/erlang-vs-node-js

"Whether you think you can, or you think you can't -- you are right." — Henry Ford

Maybe Google just doesn't want to fight the RIAA and prefers to fight Grooveshark. Maybe fighting the RIAA would open up a debate on the legality of YouTube, which Google also wouldn't want.

"It doesn’t take much. But it takes more than nothing." - excellent way of putting it.

It's like having a mohawk in the IT dept.

You might like my tornado inspired mongrel2 handler, called Brubeck. It uses eventlet for concurrency too.

https://github.com/j2labs/brubeck

demjson looks crazy fast.

Thanks for pointing this out.

I am going to do some follow up tests to cover the advice I got here. I will include this, tnetstrings and decodes too.

Great point, thanks.

I didn't mean to knock the decision about choosing Gearman. I was just interested in your thoughts on comparing the two.

That's correct that ZeroMQ isn't a server. I tend to describe it as a sockets layer that has messaging semantics. If a host isn't up, you can still send messages to the socket. It queues them up, like you'd expect a messaging system to do.

So this also means you can open a socket to a host that doesn't exist. Imagine you turn a server on with no clients up yet. A PUSH socket will block. When you connect a client, by opening a PULL socket, the message exchange starts.

These socket types can be inproc, ipc, tcp or pgm. inproc is an in process queue. ipc is basically unix sockets. tcp is... and pgm is pragmatic general multicast.

To build a broker, you'd probably use something other than PUSH/PULL sockets. You would use REQ/REP (request/reply) sockets. These sockets give you synchronous communication. The request sends a request and is guaranteed a response.

I think their doc explains the rest better than I could, I recommend reading this: http://zguide.zeromq.org/page:all

I think this description offers the gist of how REQ/REP, and their nonblocking counterparts XREQ/XREP, can be used to basically script together your ideal broker for many conditions.

When you use REQ to talk to REP you get a strictly synchronous request-reply dialog. The client sends a request, the service reads the request and sends a reply. The client then reads the reply. If either the client or the service try to do anything else (e.g. sending two requests in a row without waiting for a response) they will get an error.

But our broker has to be non-blocking. Obviously we can use zmq_poll(3) to wait for activity on either socket, but we can't use REP and REQ.

Luckily there are non-blocking versions of these two sockets, called XREQ and XREP. These "extended request/reply" sockets let you extend request-reply across intermediate nodes, such as our message queuing broker.

Or zeromq?

You might also enjoy this "USE KDE!" rant from a bunch of years back.

http://tech.slashdot.org/story/05/12/13/1340215/Torvalds-Say...

If tags were used, they should be weighted. Not everyone will agree on what the tags should be, but the top 5 should be close.

I think last.fm has used this kind of model successfully.

Weights can combat the chaos from users entering anything, but allows for evolution.

Brooklyn Law Incubator & Policy Clinic (BLIP) offers a full-service, pro bono law firm for NYC tech startups and policy initiatives.

* http://www.brooklaw.edu/academics/clinicalprogram/theblipcln...

This post should consider the time of the industries. It would be more appropriate to compare VC's to the record labels of the 60's up through the late 90's.

The reason the analogy is ever made to begin with is not rooted in the nuances of these two industries. It comes simply from the big hits nature of both industries and how they both survive off the massive winnings of a very small group of rock stars.

Would love to see this ported to coffeescript.

I think this touches on PHP's real security issue.

It's easy to get going quickly but becomes an issue fast. Smart people tend to move away from PHP, but startups find this difficult.

Hiring is then an issue and the bad practices persist.

The existence of one bug doesn't imply complete disaster everywhere. It should be treated as an anecdote. Good science demands it.

Good science would also suggest Tumblr should get some experts to help them discover anything else that might be lingering, which they're planning to do. Much like a peer review process.

Your attitude is important for those in the security industry as it pushes things forward, but remember that not everyone has the time to spend on it that you might. It can either be an asset or the bane of your existence. As an asset, you get paid for the things you understand because others don't. As the bane of your existence, you fight society for not knowing what you know.

Tumblr is hiring. Maybe you should apply and help them fix it?

I fail to see how that isn't also a human error?

I think you fail to give them credit for what they're attempting. Security is the focus of many readers of HN, but Tumblr's focus is the user experience.

This isn't to say security isn't important, but they're rushing to make Tumblr as fun to use as possible so they can survive.

Yes, they received money. They also have monstrous growth. Now they can afford to expand the engineering processes beyond, "get it working" to "make it work really well and securely".

Good things are still to come from Tumblr so let's go easy on them when they use duct tape instead an arc welder.

Aren't all bugs effectively a human error at some level? In this case, the human wrote bad PHP.

I hope Tumblr will keep us more in the loop on this than when they were down for 24+ hours.

My favorite thing about dr chrono is that these guys aren't the usual YC young kids.

Who said everyone has to agree? If you don't like coffee script, don't use it.

It's that simple.

The CMS strategy strikes me as being very similar to how Azuls concurrent GC works.

Could anyone with better understanding of GC comment?

Lost me at hipster...

I was clarifying since you didn't say so explicitly. Best to be clear.