moonboots

CloudFlare's CEO says that free SSL will use SNI with ipv4 [1] and possibly non-SNI with ipv6 [2]. A CloudFlare engineer has discussed splitting the SSL handshake between servers so their many edge nodes don't need to keep customer secret keys in memory [3]. However, this sounds slightly different than the lazy loading behavior in the blog post.

[1] https://news.ycombinator.com/item?id=7910849

[2] https://twitter.com/eastdakota/status/478369486643658754

[3] http://www.slideshare.net/cloudflare/running-secure-server-s...

For what it's worth, other scrypt wrappers have had similar difficulty in locating the scrypt primitive [1]. When I first browsed the scrypt source code, I have to admit I was also distracted by the file encryption code.

[1] https://pypi.python.org/pypi/scrypt/0.6.1

These link modifications increase privacy by hiding the referer from the destination page [1].

[1] http://www.gabrielweinberg.com/blog/2010/05/duck-duck-go-sea...

For noncommercial websites, https://www.startssl.com/ offers free certificates.

For commercial websites, the cheapest certificates I've seen are PositiveSSL certificates resold by gogetssl [1]. It's $4.55 for one year or $17.25 for 5 years.

Disclaimer: I have no affiliation with either site. I've never used gogetssl, but I will probably give them a shot the next time I need a certificate.

[1] https://www.gogetssl.com/domain-validation/comodo-positive-s...

I've also experienced problems with lack of host/container separation with lxc on arch linux, e.g. shutting down container shut down the host. I suspected the problem was an improperly mounted/unmounted /dev or /sys in the guest.

I've had a much smoother experience with lxc on Ubuntu than arch. The core lxc developers work for canonical, and Ubuntu lxc bootstrap scripts are much more refined. Lxc support for arch linux is provided by the community, and at least when I tried last year, there were minor problems here and there.

On arch linux, I've found that systemd-nspawn support is much better than lxc's. The commands mkarchroot and arch-nspawn (in the devtools package) make running arch in arch straightforward.

Ideally both halves of the spacebar would default to space for accessibility, with a software or hardware toggle to change one side. For typist that use the left half of the space bar, the right half is wasted real estate.

There are some new "66 key" keyboards [1] with a similar form factor and price as the happy hacking lite except with mechanical switches.

[1] http://elitekeyboards.com/products.php?sub=leopold,compact&p...

I like the minimal ideals of the happy hacking keyboard but I think it went a little overboard. I like having an arrow cluster and page up/down for applications that don't support emacs/vi bindings. I do like how the number pad is removed. It's too infrequently used and increases the distance between keyboard and mouse.

I actually recently came across Japanese layouts because a user requested support in http://typing.io, a programmer's typing tutor I work on. I like the smaller space bar but dislike the shrunk delete/backspace key [1]. Backspace is already hard to type because of its distance from the home row. The problem is even worse for programmers because the right pinky not only needs to type most of the symbol keys, it also needs to correct typos made when these symbols are mistyped.

[1] https://discussions.apple.com/servlet/JiveServlet/showImage/...

Caps lock should not be changed despite it's ostensible uselessness. Programmers often remap caps lock (I personally use this tool [1]), and it's nice to have a big target for the pinky. Remapping is of course possible with these new keyboards, but the split key design that replaces caps lock leaves a much smaller target. In addition, I'm sure there are hunt and peck typists that still legitimately use caps locks instead of shift because it requires less coordination and hand contortions, so leaving caps lock alone also has accessibility benefits.

One area where keyboard designers aren't innovating enough is the spacebar. The left 2/3 of the space bar is rarely used by most touch typists and hogs very accessible real estate. I like how Microsoft split the spacebar on their new keyboard [2] and replaced the left half with backspace, the most commonly typed (but normally most hard to reach) key.

I'm disappointed to see thinkpad/lenovo make these mistakes given their reputation for quality laptop keyboards. I personally use an x230 [3], which has a similar chiclet keyboard as the x1 carbon in the article without the transgressions.

[1] https://github.com/alols/xcape

[2] http://techland.time.com/2012/09/20/new-microsoft-keyboard-s...

[3] http://shop.lenovo.com/us/en/laptops/thinkpad/x-series/x230/

Instead of performing OT at the DOM level, you could do it at the data/JSON level with ShareJS and continuously feed this JSON into React.

My understanding is that Adam Langley prefers AES-GCM to all the other mac-then-encrypt cipher suites in tls 1.2. He's working on AES-GCM support in NSS [1].

[1] https://news.ycombinator.com/item?id=5365601

  Also, the if c1 ~= c2 branch is obviously not constant-time, but in practice it’s close enough that it won’t matter for our case. I’d prefer XORing the two strings together and seeing if the result is 0, but Lua doesn’t seem to include a bitwise XOR operator. If I’m wrong on this, I would appreciate a correction.

LuaJIT provides bitwise operators out of the box [1], and the creator also provides an extension for regular lua [2].

[1] http://luajit.org/extensions.html

[2] http://bitop.luajit.org/

Systemd provides a hook (ExecStartPre [1]) for running test commands before starting a service, e.g. checking nginx configuration before starting. However, I also prefer the flexibility of shell scripts over something like systemd's INI service definition format.

[1] http://www.freedesktop.org/software/systemd/man/systemd.serv...

My bad, I've only used the service command on Ubuntu post-upstart and thought they were more deeply related.

I agree that nginx needs supervision less than most processes because it reinvents many wheels. However, supervision is still nice, e.g. your 'service nginx' example that uses Ubuntu's supervisor Upstart.

I agree it's not worth straining to make nginx's binary upgrade work with arbitrary supervision. However, if someone created a supervisor that solves this problem (systemd), I might give it a try.

Disabling daemonization allows nginx to be monitored initially and through conf reloads but not binary upgrades (e.g. nginx 1.5.1 -> nginx 1.5.2). The binary upgrade process forks the master process, which it 'orphans' from runit and reparents under pid 1.

oops, edit: pid 0 -> pid 1

Supervision has many benefits besides automatic restarts after crashes. Supervising programs provide a consistent way to start, monitor, and log long running programs. Nginx reinvents its own interface for some of this functionality (like daemonizing, log rotating/compression, conf reloading, etc.), but it's useful for all services to work under the same interface. This is especially true for monitoring nginx's status, where a supervisor like runit is much nicer than 'pgrep nginx' or 'ps aux | grep $(cat /where/nginx/dumps/its/pid)'.

Systemd provides many knobs for tuning cpu, memory, and io settings [1] using cgroups. This deep integration is one of the reasons why systemd only runs on linux.

[1] http://0pointer.de/blog/projects/resources.html

I use runit in production for http://typing.io. I appreciate runit's strong unix philosophy (shell scripts instead of dsls). However, I'm starting to experiment with systemd because of features like properly tracking and killing services [1]. This feature would be useful with a task like upgrading an nginx binary without dropping connections [2]. This isn't possible with runit (and most process monitors) because nginx double forks, breaking its supervision tree.

[1] http://0pointer.de/blog/projects/systemd-for-admins-4.html

[2] http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_...

Rng-tools [1], mentioned in the article, can use a hardware rng's output as input to the kernel's prng. However, it needs to be configured correctly to avoid potential problems [2].

[1] http://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.h...

[2] https://news.ycombinator.com/item?id=6040975

The "--perl-regexp" flag to git grep enables perl flavored regexes, which contain explicit word boundary matching. To match only word starts, you could use the following:

    git grep --perl-regexp "\brout"

and for just word endings

    git grep --perl-regexp "outer\b"

Aggregating multiple sources of randomness has the potential to conceal bugs. In the Debian/OpenSSL bug from 2008 [1], randomness was sourced from multiple locations including the current process id. The idea was that more randomness, even the minimal amount from the pid, could only increase the total entropy. However, when the primary source of randomness was eliminated through an overzealous patch, the PRNG still emitted plausible looking numbers due to the remaining sources of low quality entropy. Had the PRNG only used one high quality source of randomness, people would've noticed something strange about their generated private keys much sooner.

[1] http://research.swtch.com/openssl

I was experimenting with integrated tools.namespace reloading in elisp as well, and I found a slightly nicer way to send commands to nrepl:

  (defun nrepl-reset ()
    (interactive)
    (nrepl-interactive-eval "(user/reset)"))

The original elisp function:

  (defun nrepl-reset ()
    (interactive)
    (set-buffer "*nrepl*")
    (goto-char (point-max))
    (insert "(user/reset)")
    (nrepl-return))

Using different domains reduces attack surface area [1]. That said, I agree that the blogspot domain and site design look amateurish.

[1] https://github.com/blog/1466-yummy-cookies-across-domains

I recommend temporarily disabling web workers, which should provide better visibility into js bottlenecks in tools such as Chrome's timeline panel [1]. Also check out this google IO talk [2] on performance debugging the WebGL/HTML5 demo "Find Your Way to Oz" [3].

[1] https://developers.google.com/chrome-developer-tools/docs/ti...

[2] https://developers.google.com/events/io/sessions/324908972

[3] http://www.findyourwaytooz.com/

I had the same experience. Fortunately, FF23 adds this feature (under the heading 'Web Console in Debugger Frame' in the linked post).

As a developer, the biggest concern I have with Dwolla is the initial friction for new users, e.g. entering their bank account number. I would like to see the complete end user signup flow featured more prominently. I didn't see anything on the topic while signing up for a developer account.

Criticism aside, I'm definitely rooting for Dwolla. I don't think they need to match the comparative ease offered with credit card purchases, but they need to be in the same ball park.

May I recommend http://typing.io for the typist in the video? Disclaimer: my webapp

CSSO [1] is a tool that removes duplicate declarations during minification instead of just warning about them. It also performs more advanced structural optimizations.

[1] http://bem.info/tools/csso/