moonboots

I'm not sure if understanding HTTP/1.1 is enough to bridge a websocket connection between client and backend websocket server. However, there is a 3rd party tcp proxy module for nginx that allows proxying websockets:

https://github.com/yaoweibin/nginx_tcp_proxy_module

In terms of diffs, nginx 1.2.0 adds only a few bugfixes to the 1.1.19 release. However, this release is significant in that it marks the 1.1.x dev branch to stable.

The main feature of the 1.1.x branch I've used is http/1.1 reverse proxying. Previously in 1.0, nginx spoke http/1.0 with reverse proxies. This upgrade allows nginx to make persistent connections with backend servers instead of creating new connections whenever it forward requests.

I like the article, but the fat, fixed header is killing an otherwise great design. Making the header absolute (not stick to the top of the window) would leave more vertical screen space for the crisp graphics and typeface.

The initial grc command aliases commands like 'ping' to a modified command that processes the output[1].

[1] https://github.com/mxcl/homebrew/blob/7bbe7e9311ce95a141bf5f...

This script inserts terminal escape sequences into text. These sequences are just text that the terminal interpret as color transitions.

Ascii.io transforms these terminal escape sequences into html/css, so Grc should work fine with it.

Lars Bak, who leads chrome's v8 team and was tech lead for java's hotspot vm, argues that javascript is a competitive 'bytecode' even compared to java or CLI bytecode [1]. Among other things, Bak claims that javascript source is more compact than traditional bytecode.

  [1] about 3/4 into this interview: http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine

If javascript were any worse, it may have been sidelined entirely before it had a chance to improve, and we would be using proprietary application stacks like iOS even more heavily for client side development.

This reminds me of Google Wave's operation transformation protocol except without the collaboration component [1]. Client edits are reflected instantly and client state is synchronized and reconciled with the server's.

[1] http://www.waveprotocol.org/whitepapers/operational-transfor...

The github repo for 0xdata's new "h2o" database is still empty, but there's another interesting project containing highly concurrent in-memory java data structures: https://github.com/0xdata/high-scale-lib

Here's a talk that Cliff gave a while back about writing a lock free hashmap: http://video.google.com/videoplay?docid=2139967204534450862

Yes

"Primary architecture" in this context just means first class architecture. Both x86 and x86-64 are already primary architectures in Fedora while ARM is currently a secondary architecture.

The netscape rewrite became Firefox.

I would not want one rogue site evicting the caches of all other sites.

Thanks, I thought the client may have already downloaded some of the full size photos, so zipping on the client would reduce download sizes. In your uservoice feedback, there are a few votes for full size zooming, so this client zipping may be useful if you implement zooming. This method also simplifies server architecture as the frontend server now only needs to reverse proxy image request to s3.

Have you considered jszip and/or webworkers to perform the zipping on the client?

xmonad

SPDY improves upon keep-alive by reducing the number of connections that need to be created and in eliminating blocking.

SPDY reduces the number of persistent HTTP connections between client and server from around six (depending on browser) to one. High latency connections increase the time required to create these initial connections, and round trip times have not been consistently declining despite bandwidth improvements.

HTTP requests over each keep alive connection are blocking, i.e. the server must response before another request can be made. SPDY addresses this blocking by multiplexing requests and responses. Note that the head-of-line blocking that jganetsk mentioned is a separate issue.

I'm not sure what you mean by lack of domain specific information and hints. A SPDY proxy shifts the expensive aspects of HTTP from high latency client-server connections to proxy-server connections where they are comparatively cheaper due to lower latency.

Backblaze quoted this price before the flood at $120 for 3TB. I'm not sure if post-flood prices are back to these prices or what range of prices you can expect at this volume.

This figure doesn't include redundancy. Backblaze uses raid6, so the usable capacity is actually 117TB per pod[1]. With this configuration the final cost should be closer to $1.6 million.

  [1] http://hardware.slashdot.org/comments.pl?sid=2341206&cid=36834390

For reference, this amount of data would require 190 backblaze storage pods ($7,384 for 135TB) totaling $1.4 million.

The jQuery core team has discussed supporting advanced compilation with the Google Closure compiler. When compiled with user code, unused portions of jQuery would automatically be removed. This allows for minimal bloat without needing to manually assembling micro js libraries.

They should change to a more performant web server, maybe something like deft.

He should have invented TeX.

I can't help but think that the NSA would have taken the letter more seriously if had been typed.

http://www.nsa.gov/public_info/_files/nash_letters/nash_lett...

security by obscurity

"Tali published her research on her site, but we knew it deserved a larger audience, so we've cleaned it up and republished it here."

Good catches

The spaces in filenames can be handled by having grep and du communicate with null delimited strings instead of newline delimited, e.g.

  grep --files-with-matches --null "todavida..." *
  du --summarize --total --files-from=<($(echo $translated_file_size))

I still prefer a simple shell script for these use cases. Here's a snippet for the translated file size calculation:

  translated_files=$(grep "todavida no ha sido traducida" *)
  total_size=$(du --summarize . | cut -f 1)
  translated_file_size=$(du --summarize --total $(echo translated_files) | tail -n 1 | cut -f 1)
  echo "translated size: ${translated_file_size}KB/${total_size}KB $(($translated_file_size/$total_size))%"

Top C++ sounds complicated to me.

I'm not seeing how BrowserID differs from the standard email verification sign up. I went through the sign up process (enter email, click link in verification email, enter password, sign in with password). I also read Mozilla's 'really short version' explaining browserid (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol) and will give the longer version a shot.