moonboots

To use cloudflare's "rocket loader", the host domain dns record must point to cloudflare instead of the origin server. If abc.com were using cloudflare, a user's request to abc.com/page would first hit cloudflare's server. Cloudflare would then proxy the request to abc's origin server, rewrite 3rd party urls, and return the modified content to the user.

I'm not sure how well cloudflare handles http vary headers, e.g. 3rd party resources that serve different content depending on cookies or user agent. An example could be google web fonts which serves different css and fonts to different browsers.

Ubuntu Unity has some neat tricks to make scrollbars more usable [1]. Instead of requiring users to hone in on the up/down arrows or the "thumb", hovering anywhere near the scrollbar brings up a widget that compactly encapsulates all this functionality. I don't care for Unity enough to start using it day to day, but this feature struck me as clever though radical.

Google avoids waiting for dom ready in webapps like gmail, and their closure library [1] doesn't have the equivalent of jquery's $(document).ready() [2].

[1] https://developers.google.com/closure/library/ [2] https://groups.google.com/group/closure-library-discuss/brow...

Does anyone know if the related netmap project[1] is being consider for inclusion into mainline linux? I haven't seen much discussion of the project apart from a few HN and proggit threads. It looks like effort was made to make netmap compatible with existing systems, although according to the author, small portions of network drivers need to be rewritten.

[1] http://info.iet.unipi.it/~luigi/netmap/

I first heard about Hetzner when your blog post was submitted to HN. While some HN commenters claimed the title was linkbait, I think it's legitimate (though biased). Amazon can charge what they want, and you can call them out if there are significant performance/price discrepancies.

It should be noted that the AES-NI TLS speedup only occurs if you are using AES. If you are using RC4 (Google and Facebook use this), you won't benefit from the new cpu instruction. Here's another useful TLS benchmark I came across:

http://zombe.es/post/4078724716/openssl-cipher-selection

I'm not arguing that a monthly dedicated server is equal to ec2 on-demand. I'm arguing that it's closer to on-demand than a 3 year plan.

Reserved instance pricing brings the monthly price down, but for me it's not making ec2 look more appealing. The 3 year price is still 2.5 times the hetzner monthly price after initial setup fees, you lose the ability to autoscale this box, and you are locked-in for 3 years. I would argue a Hetzner box is more like ec2 on demand than reserved because it can be canceled at the end of any month. You can't spin it down immediately and stop paying, but you are definitely not locked in.

thanks

I think most people realize aws charges a premium for the ability to scale up and down, but at least for me, the magnitude of the price difference was nevertheless surprising. Some of the services Amazon offers will certainly be worth the premium for a subset of customers. However, the price difference makes other features like auto scaling moot because you can overprovision servers at Hetzner and still have a much lower price.

There has been a lot of discussion on HN about dedicated hosting at Hetzner vs Amazon, and while they offer different pros and cons, Amazon appears to be a lot more expensive for comparable or even worse specs. Here's a comparison of two servers that have roughly comparable specs, Amazon High-Memory Double Extra Large and Hetzner ex8s:

  cpu:
  hetzner: Intel Xeon E3-1275 (4 physical cores)
  ec2: 4 virtual cores (13 "ecus" where each ecu is ~ 2007 xeon core)

  ram:
  hetzner: 32 GB ECC
  ec2: 34 GB (previous commenters have speculated that it's non-ecc because Amazon only mentions otherwise for compute units)

  disk:
  hetnzer: customizable, cheapest is 3TB disk or 120 GB SSD for 15 euros/month
  ec2: 850 GB (ephermeral)

  network:
  hetzner: 100 Mbit (incoming free, 10TB outgoing free, 7 euros/TB after)
  ec2: unknown speed (incoming free, $0.12/GB outgoing, $120/TB)

  price:
  hetzner: ~$265 for first month, $115 thereafter (includes setup fee, excludes VAT, after euro to usd conversion, 
  includes cheapest hd option)
  ec2: $648/month

There are a lot of other factors like the additional services amazon provides, failover, scaling, bandwidth quality, US ping times, reserved instance pricing, etc. It's not a straightforward comparison, but I would argue that for many users hetzner is the much faster and cheaper option.

edit: formatting, spelling

One thing to note about Hetzner, in addition to high US latency times, is the initial setup cost. For the EX4 (core i7-2700, 16 GB ram, 6 TB HD, 49 euros/month), the one time setup was 149 euros. However, I just checked and the setup cost for this server has dropped to 49 euros. I'm not sure if this is promotional or permanent.

Yeah, except for the cost of 1.5 dynos a month, you get a core i7-2600, 16 GB of ram, and 6 TB of hd space.

Heroku virtualizes dynos with linux container (lxc) [1]. The good thing is that lxc is very lightweight because it shares the host's kernel, so dynos aren't slowed by another virtualization abstraction in addition to ec2 xen. The bad thing for heroku users is that memory does not need to provisioned upfront for dynos, so spikes in memory usage of neighboring dynos can eat up all the memory in a physical machine.

[1] https://devcenter.heroku.com/articles/dyno-isolation

> 4 CPU cores (Intel Xeon X5550 @ 2.67GHz)

The cpu specs are disingenuous as well. A heroku dyno may run on an intel xeon cpu, but I would never say a dyno "has" a 4 core cpu.

Have you heard any reviews of Honelive? I've been looking for a dedicated server provider in the US with comparable prices to Hetzner in Germany.

I agree that this phishing attack probably won't lead to mass account takeovers because Google's two factor authentication is not be widespread. However, you are downplaying the risks.

The different sources of the SMS may not cause alarm. The victim may not go back to original message to verify the numbers. Many companies have multiple legitimate phone numbers. The phisher may try to find phone numbers that are variations of Google's so the user is less likely to notice.

The phishing page could be secure in the sense of having SSL and looking professional. I haven't use Google's SMS verification, but I'm hoping that the text they send raises red flags about only entering the code in Google's web site. If not, e.g. if it's just the code, I could very easily see a victim entering the code into a legimate site. If Google's SMS does have warnings, the attacker could get a domain like https://gmailgiftcardverification.com that may still get some victims to enter the verification code.

I think this is more dangerous than page directly phishing for a google password. Users are conditioned to look for google.com and a green address bar before revealing their password. On the other hand, SMS verification is relatively new, and users may be less familiar with what to expect regarding the format and origins of the text messages.

This example uses the alias directive, which can be set inside location clauses unlike the root directive. The distinction between root and alias isn't the most user friendly, but I think this setup is effectively the same as separate roots per user. Unless otherwise configured, users will not be able to access anything directly in /home, only in the user subdirectories.

That being said, I have no problems with Apache, especially if it's already in place and working.

For the userdir example, would the following link solve your problem?

http://wiki.nginx.org/UserDir

One of the reasons SPDY uses encryption is to ensure intermediate proxies do not mishandle the new protocol. A couple of SDPY devs gave a tech talk[1] where they mentioned the problems with tunneling a new protocol (in their example websockets) through HTTP (19:11 into video). Sending websockets over HTTP on port 80 only has a 67% success rate. HTTPS over 443 had a 95% success rate. The benefit of HTTPS is that intermediates cannot see or interfere with data transfer. The disadvantage is that caching and CDNs are more difficult to use.

As an interesting side note, tunneling HTTP over a random port (in the slides port 61985) had a higher success rate than port 80 (86% vs 67%). If I remember correctly, the speakers attribute this to intermediate proxies hardcoded to handle port 80, leaving other ports free of processing.

[1] http://www.youtube.com/watch?v=TNBkxA313kk

While SSDs will undoubtedly be faster that spinning disk, LevelDB is designed to address slow random writes by batching and writing sequentially.

While I'm concerned that Chrome is the only browser supporting native client (Mozilla outright rejected it), it's still awesome to see lua in the browser.

Thanks for the response. I agree that some functionality currently handled by package managers is hairy, even for other package managers. To some extent, I don't think this functionality should be managed by package managers. It would hurt usability because the user would need to set up configuration files, hook the package into the init/upstart system, and fix breakages across updates. On the other hand, I've never been a fan of running 'sudo apt-get install apache2' on a development machine and exposing a public port and running an application I don't always need every time I boot up.

This is a potential problem, but I think in practice backwards compatible updates and patches for Nix could work very similarly compared to a distro like Debian. For example, when openssl releases a security fix, Debian uses its large, mostly automated test suite [1] to verify that this new update does not break compile and (to a lesser extent) runtime compatibility and correctness.

Instead of an implicit promise of compatibility, a Nix continuous build and testing system[2] could explicitly mark openssl-dependent packages as compatible by bumping their versions. The end user would need to update a lot more packages, but these cost could be reduced by binary diffing old and new packages, which should be almost identical with the exception of dependency metadata.

[1] http://www.youtube.com/watch?v=3aoDjW1bjxo [2] http://nixos.org/hydra/

The functional approach seems to work great for sandboxing binary artifacts of packages, but configuration files and user data are more difficult to handle. Daniel Burrows, a debian apt developer, wrote an analysis of Nix a while back[1], and he brought up the problematic example of upgrading database configuration file formats. It seems difficult to seamlessly upgrade and downgrade these types of files whose semantics and syntax may change between versions. When these conflicts occur in Debian/Ubuntu, the upgrade process blocks and the user is prompted to resolve the 3-way merge.

I think packakge managers should only handle the storage of static files like executables and shared libraries. Forcing the user or another process to handle configuration files and startup/shutdown hooks has additional benefits such as making these files easier to store in version control.

[1] http://lists.debian.org/debian-devel/2008/12/msg01027.html

The separate password page is served over https instead of http like the initial page. This allows the initial page to load faster without the ssl handshake overhead while still sending the password over an encrypted connection.

What's unusual to me is that the username field is on the initial page. On most sites I've used that upgrade from http to https, only a generic login button is on the unencrypted page, e.g. creditkarma.com. Maybe facebook a/b tested this setup and found users log in more often.

The post mentions that the disk performance of Amazon small ec2 instances was poor enough to justify the relatively expensive large instances. If the blog author is on HN, were you using Amazon EBS or ephermeral storage to back Riak? I have seen different advice regarding using ephermeral storage to increase disk performance at the expense of data integrity in the event of instance termination. I remember Reddit programmers saying they run Cassandra on ephermeral storage.

You're right; it looks like a few of these features like the max range directive were also included in 1.0.

Bug fixes and security patches are applied to both stable and dev branches. Some of the recent buffer overflow patches only affect features added in 1.1.

Hopefully future changelogs can be more comprehensive and usable now that nginx has venture funding.

Unfortunately these changes aren't summarized. The differences are all the 'feature' bullets in the changes webpage from 1.1.0 to 1.2.0. I've assembled these below:

  - the $connection_requests variable.
  - $tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd and $tcpinfo_rcv_space variables.  
  - the "worker_cpu_affinity" directive now works on FreeBSD.
  - the "xslt_param" and "xslt_string_param" directives.  Thanks to Samuel Behan.  
  - the "from" parameter of the "disable_symlinks" directive.
  - the "return" and "error_page" directives can now be used to return 307 redirections.  
  - the "disable_symlinks" directive.
  - the "proxy_cookie_domain" and "proxy_cookie_path" directives.  
  - multiple "limit_req" limits may be used simultaneously.
  - the "TLSv1.1" and "TLSv1.2" parameters of the "ssl_protocols" directive.  
  - the "proxy/fastcgi/scgi/uwsgi_cache_lock", "proxy/fastcgi/scgi/uwsgi_cache_lock_timeout" directives.  
  - the "pcre_jit" directive.
  - the "if" SSI command supports captures in regular expressions.  
  - the "so_keepalive" parameter of the "listen" directive.  Thanks to Vsevolod Stakhov.  
  - the "if_not_empty" parameter of the "fastcgi/scgi/uwsgi_param" directives.  
  - the $https variable.
  - the "proxy_redirect" directive supports variables in the first parameter.
  - the "proxy_redirect" directive supports regular expressions.  
  - the "valid" parameter of the "resolver" directive. By default TTL returned by a DNS server is used.
  - support for multiple "limit_conn" limits on the same level.  
  - the "image_filter_sharpen" directive.  
  - support of several DNS servers in the "resolver" directive.  Thanks to Kirill A. Korinskiy.
  - "proxy/fastcgi/scgi/uwsgi_ignore_headers" directives support the following additional values: X-Accel-Limit-Rate,
  - decrease of memory consumption if SSL is used.  
  - the "uwsgi_buffering" and "scgi_buffering" directives.  Thanks to Peter Smit.
  - the ngx_http_upstream_keepalive module.  
  - the "proxy_http_version" directive.  
  - the "fastcgi_keep_conn" directive.  
  - the "worker_aio_requests" directive.  
  - the module ngx_http_mp4_module.  
  - the "max_ranges" directive.  
  - now shared zones and caches use POSIX semaphores on Solaris.  Thanks to Den Ivanov.
  - accept filters are now supported on NetBSD.  
  - cache loader run time decrease.  
  - "loader_files", "loader_sleep", and "loader_threshold" options of the "proxy/fastcgi/scgi/uwsgi_cache_path" directives.
  - loading time decrease of configuration with large number of HTTPS sites.
  - now nginx supports ECDHE key exchange ciphers.  Thanks to Adrian Kotelba.
  - the "lingering_close" directive.  Thanks to Maxim Dounin.