semicomplete.com

After casually trying AwesomeWM on my mac for a short while, I decided to try to make XMonad as usable as possible under OSX without writing any HOC code. It's been an incremental process, but at point I'd call my setup _more_ than adequate. One of these day's I'm either going to update the OSX/Xmonad wiki page with my method with all of the scripts and configurations I am using under the hood... In my opinion, much of the magic of integrating X11/Xmonad with aqua involves 'capturing' key combinations (on the Xmonad side), determining how to respond, then either responding directly or emitting the correct keystrokes using xdotool (http://www.semicomplete.com/projects/xdotool/).

For example, I let xmonad capture the keysequence <Command-Tab>. Xmonad keeps track of the MRU-like window list and switches to it. If it is another window in the current workspace, xmonad can switch to it unassisted. If a 'switch' would involve switching to an aqua application, xmonad then uses xdotool to emit the <Command-Option-A> + <Command-Tab> key sequence (popping out of X11).

Take a look at this article which measures handshake latency versus encryption latency, it's very well-written: http://www.semicomplete.com/blog/geekery/ssl-latency.html :

Anyway. The point is, no matter how fast your SSL accelerators (hardware loadbalancer, etc), if your SSL end points aren't near the user, then your first connect will be slow. As shown above, 22ms for the crypto piece of SSL handshake, which means 300ms of the SSL portion above was likely network latency and some other overhead.

Once SSL is established, though, it switches to a block cipher (3DES, etc) which is much faster and the resource (network, cpu) overhead is pretty tiny by comparison.

Summarizing from above: Using SSL incurs a 3.5x latency overhead for each handshake, but afterwards it's generally fast like plain TCP. If you accept this conclusion, let's examine how this can affect website performance.

This is even more so if your site is served over HTTPS given the latency for the initial SSL handshake[1]. Even better not to load anything and have it properly cached on the client side.

If you do it right you don't even have the client send/receive an HTTP 304. For our app we have a lot of modular dependencies but we serve all of them from a unique prefix per build (eg. 'assets-SHA(build)/js/foo.js'). The second page load and beyond has zero requests for the same static asset. Whenever we have a new build of the app the unique prefix gets auto updated to force clients to use the latest versions.

For HTTPS make sure to mark your assets as public or they won't be cached:

Cache-Control:max-age=31557600, public

[1]: http://www.semicomplete.com/blog/geekery/ssl-latency.html

I've gone so far as to create a separate autossh user with separate key, with no shell access (by setting the user's shell to /bin/false). It still permits tunneling (call ssh with -N), but does not allow shell sessions. Perfect for when you want to access remote systems via a remote tunnel but do not want to give shell access on the relaying machine to the tunnel origin. It trusts that the machine originating the tunnel will not initiate a reflection attack (by making a local forward to the remote port itself on the originating machine and causing some log messages to appear until all file descriptors are in use)[1], but that's not so unreasonable.

1. http://www.semicomplete.com/articles/ssh-security/

Nobody has mentioned keynav[0] yet. "It lets you move the pointer quickly to most points on the screen with only a few key strokes."

With some software or web pages you're better off with this kind of workaround than installing browser plugins or configuring the software, especially if you use them infrequently.

Another tip: use ' in firefox to search for links when the focus is not in a text area. For instance, typing |'comment| (without the pipes) here selects a link containing "comment", and you can circle through other matches with F3 / Shift-F3 just like regular searches.

[0]: https://www.semicomplete.com/projects/keynav/

You can move the region and thus move the mouse actually:

From: https://www.semicomplete.com/projects/keynav/

> The following is the default configuration:

h : select the left half of the region
j : select the bottom half of the region
k : select the top half of the region
l : select the right half of the region
shift+h : move the region left
shift+j : move the region down
shift+k : move the region top
shift+l : move the region right
semicolon : Move the mouse to the center of the selected region
spacebar : Move the mouse and left-click