SaltwaterC

tl;dr Lennart is an ass.

You still need to provide an access key id and secret access key with that session token as returned by Security Token Service. And properly sign every request with those credentials. With a proper session token, but invalid credentials, the request fails with HTTP 400: "__type: com.amazon.coral.service#InvalidSignatureException, message: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.". Amazon still checks the signature. The same logic that could be used for IAM credentials that don't expire, without the need to check for a valid session token. If it is an Amazon screw up, that static credentials take more time to evaluate vs temporary credentials - that's not out fault. It is a pure Amazon screw up. The signing logic is still there for every API call. So (apparently?) we're back to square one: extra requests and wrapper logic for zero benefits, and worse overall experience. The session credentials aren't stateful. I specifically checked for this behavior. Therefore what you say, doesn't seem to happen in reality.

And for the love of God, don't blindly trust the documentation / what the AWS folks say. As an AWS library author myself, I had a lot of fun debugging failed requests because the smarty who wrote the signing procedure docs forgot to mention some HTTP headers that are mandatory to sign. I had to reverse engineer an official SDK in order to patch my own code. While being implemented as the docs say, the signing method failed at every request, although I had a valid session token. Trial and error is always a broken way of developing things due to broken docs. If you're an AWS employee, please send my regards to the documentation folks.

They add useless latency and another point of failure. And sometimes, the AWS APIs DO fail.

It looks like it doesn't like recursion.

The API doesn't bother me as much as the temporary authentication via STS. Temporary credentials for database access? Seriously? I am the only one who sees how ridiculous this is?

Well, since you're complaining, I added SimpleDB support to aws2js. It was like 12 lines of code actually, but since people don't ask ...

While we're at it, can the Adobe folks explain to the rest of the world when Flash is going to suck less? I mean really. Don't care about the on paper gibberish.

The Wikipedia's definition of "notable" is a heap of crap. Maybe somebody should donate Jimmy a dictionary, besides the cash he's looking for.

This is exactly what they said on their blog post:

Long term archival data is different than everyday data. It's created in bulk, generally ignored for weeks or months with only small additions and accesses, and restored in bulk (and then often in a hurried panic!)

This access pattern means that a storage system for backup data ought to be designed differently than a storage system for general data. Designed for this purpose, reliable long term archival storage can be delivered at dramatically lower prices.

Says right there on the front page: "Build by SpiderOak on the same proven backend storage network which powers hundreds of thousands of backups".

Zed has the balls to post stuff under his own name.

http://linux.die.net/man/2/fork - this explains better.

Spawning a new process is not the same thing as forking, but people often forget this bit. This post wasn't about forking.

PS: the number of update() calls isn't the issue. Increasing the ReadStream buffer from the default 40 KiB to 1 MiB makes it 0.2s slower although there are 25X less update() calls.

The comment about blocking the event loop is all about hogging the CPU with the hash computation, stuff that's not light. See the "node.js is cancer" article for more details. fs.readFile(), although non-blocking, is worse since it actually buffers the data. Some files may be larger than the system memory. Kinda impossible in this case to buffer all the bytes. Even without multiple calls to update(), node is still dog slow.

In the real world people use node.js for other stuff that web servers. Like background processing that involves a lot of I/O, therefore the bias against spawning a shell has no ground.

node hash.js – 29.661s sha256sum – 5.093s openssl dgst -sha256 – 4.567s

Updated the article as well. I usually post all the output to avoid the appearance that I made up the results. Even though they are fully reproducible up to an extent. Or that I have better things to do that making up horror stories about poor node.js performances in certain areas.

You can address up to 64 GiB of RAM with a PAE kernel. Happens that a single process can't access more than 4 GiB of RAM. But in the end, how many people actually run a process that large on a notebook?

In fact it is good recursive code, mathematically speaking. It's just that some compilers are bad at it aka doing brute force instead of tail recursion. The main selling point of these "interpreted" languages is the programmer productivity. Now why the hell one would have to write more complicated algorithms just to go around the compiler? C does this just fine. The 0.6 seconds to 5 minutes difference for the same simple algorithm shows that something is fundamentally broken.

Not having to backup because the data is "in the cloud" is just a pipe dream. Wake up, people!

Redundancy is good. It saves your ass when the critical piece of infrastructure that should not fail, fails.

Can you post something that actually means something?

Thanks. Missed that one. My "3rd party" language support is not perfect.

There isn't an original article. In fact, my article isn't something to give the node.js police ideas on how to "fix" various stuff. This is about how various runtimes handle bad recursion. In fact, V8 isn't stupidly slow compared to PHP, CPython, and the de facto Ruby implementation.

If you aren't writing recursive code, then the valuable information for you is NULL. Otherwise, it may give you some food for though.

This may be the subject for a part 2. Aka more intensive testing for the implementations that actually perform. And other recursive algorithms (such as the classic factorial). I didn't test the language (implementation!) performance, but the recursion and how the various implementations can actually handle the bad recursion algo.

A proper testing suite that tests various aspects of a specific runtime takes time. I am aware of that, but I am not aware of any test suite that does this.

Buzz marketing. These days nobody gives some attention to a purely technical article without any incentives. Seriously, on HN usually it matters who wrote the article, not the factual contents of it.

One of the reasons I get why people advise against certain levels of optimization without understanding its implications. As I write few lines of C code, usually I don't bother with deep understanding of all the concepts of compiler optimization.

Good catch.

fib|⇒ gcc -O4 fib.c -o fib fib|⇒ time ./fib ./fib 0.65s user 0.01s system 100% cpu 0.657 total fib|⇒ gcc -O3 fib.c -o fib fib|⇒ time ./fib ./fib 0.66s user 0.00s system 100% cpu 0.657 total fib|⇒ gcc -O2 fib.c -o fib fib|⇒ time ./fib ./fib 1.54s user 0.00s system 100% cpu 1.535 total fib|⇒ gcc -O1 fib.c -o fib fib|⇒ time ./fib ./fib 0.00s user 0.00s system 0% cpu 0.001 total

For some reason, it hates the O1 flag. Printing the result brings it close to the result without the optimization.

Did you ever bother to read the HTTP vs. the FTP specs? "Remotely close" rings any bell?

The point is moot. HTTP is just the transport protocol in this case. Doesn't have to say that it has to be the front end service that talks to the end user web browser. The OP of the "cancer" article made up that shit. I can bind the listener of a node service to an UNIX Domain Socket and talk HTTP over that socket with a front end web server, instead of plain TCP (reduces the IPC latency). It is IPC between distinct components. It delegates the dynamic page generation to another service. It is a text interface, although sometimes, well, most of the times, the binary protocols outperform the text based protocols therefore the theory is crap. Isn't this "UNIX way" enough for some people? Forget the part that says: any IPC adds extra latency to the request - response paradigm aka the opposite of the stuff a web stack should do.

Can you tell me at least one example from the myriad xGI protocols for interfacing a web server with an application server that actually brings any benefit over having plain HTTP/1.1 and a reverse proxy? Does it help to have yet another protocol for doing basically the same task: IPC between a couple of servers? Any xGI client (aka web server) is basically a reverse proxy for an IPC protocol. Does it say somewhere, carved in stone, that this protocol must be other than HTTP? I think that most people that spend the time engineering yet another xGI solution simply don't see the forest for the trees.

PS: nobody stops anybody to drop a scgi.js or fastcgi.js module for node.js if that keeps people warm at night. But maybe I'm one of those tired of this shit: engineering yet another xGI protocol for every programming language that floats around the web. NIH syndrome, I'd say. At least HTTP is ubiquitous, while most servers already HAVE a reverse proxy handler.

Old wordpress.com gag ... X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.