If you're used to vi keybindings, and you use Python interactively, you're going to do a lot of cursing on OS X. This is because the readline library (responsible for keybindings and history) is GPL licensed and thus not distributed by Apple.
Here's a quick fix.
Add a file called .editrc with the following content:
Add a file called .pythonrc with the following lines:
import rlcompleter import readline
Add a line to your .bashrc which makes Python run .pythonrc when it starts interactively:
Start python from the commandline and voilà, enjoy history and vi keybindings and all that good stuff. Tested on 10.9.2 (Mountain Lion).
On the surface, it looks pretty cool. Especially because iTerm2 can talk to tmux. From the iTerm2 wiki: When you run "tmux -CC", a new tmux session is created. An iTerm2 window opens and it acts like a normal iTerm2 window. The difference is that when iTerm2 quits or the ssh session is lost, tmux keeps running. You can return to the host you were ssh'ed into and run "tmux -CC attach" and the iTerm2 windows will reopen in the same state they were in before.
That's pretty useful!
A problem that I'm now bumping into, is that when I'm SSH'ing into the remote machine where tmux runs, I'm forwarding X11. This is useful because vim supports the X11 clipboard. That way, if I copy text from vim and paste it on my local machine, layout is retained.
Without the X11 clipboard, I'd have to simply "hard-copy" whatever is on the terminal screen. Vim's line numbers will be copied along. I also couldn't copy more than one screen.
In order to make this work, when ssh opens a session and starts the shell, it sets the environment variable $DISPLAY. Vim then reads it when it starts.
However when detach tmux, log out and log in again via ssh, DISPLAY is set again to some other value. All shells in your tmux session now have an old/stale value in DISPLAY. Tmux has some commands for this, but it's not automatic. And if that would work, vim has to be restarted again as well.
It would be nice if you could simply configure the DISPLAY variable but this doesn't work -- the ssh server has an option called X11DisplayOffset but the client doesn't. So there's no way to configure this based on the user.
In summary: X11 forwarding and tmux don't work very well.
Then I connect over a VPN, and use scp to see how much time it takes to pull over a 100 MB test file. With the Apple adapter:
$ scp testbox:~/tmp/a.log . a.log 100% 100MB 3.0MB/s 00:33
And now with the USB 3 based adapter:
$ scp testbox:~/tmp/a.log . a.log 100% 100MB 2.9MB/s 00:34
Huh weird, no difference. I'll go and check where the bottleneck lays. VPN? scp?
Not using VPN gives the following result:
$ scp gateway.company.tld:a.log . a.log 100% 100MB 16.7MB/s 00:06
That's somewhat better. Testing without scp, but with wget instead shows roughly the same number:
$ wget http://www.company.tld/some_video.mov 100%[====================>] 126,805,954 16.0MB/s in 7.6s
Now I test it on a different machine, within the company network:
$ wget http://www.company.tld/some_video.mov 100%[====================>] 126,805,954 64.1M/s in 1.9s
That's better. So the bottleneck is apparently the physical (ethernet) connection I've got, which is VLAN'ed to provide a guest network. Oh well.
Long story short: better check this guy's test results. You should be able to get up to 110 MB/s.
I'm running a little comparison of the file system of a Mavericks install and a Mountain Lion install, to see what's new and what has disappeared.
So far, I found that Mavericks added the following drivers:
Mavericks also added Ruby 2.0 (up from 1.8 in Mountain Lion).
I found a number of apps in /System/Library/CoreServices that are new:
There's also a number of new drivers in the /System/Library/Extensions folder:
In the /System/Library/Frameworks folder, there are a number of new libraries:
In /usr/bin, there are a bunch of new executables:
Recently I got a MacBook Air, but it wasn't within my budget to get the bigger SSD. The standard SSD is advertised as 128 GB. In practice, this means 112 GiB, so I went looking for additional ways to get some extra storage space.
First and most cheapest, you can get an external harddisk. On one hand, it's very cheap. On the other hand, you have to remember taking it with you, and it's another wire and another device on your desk.
As an extension to that, there's the various wireless external harddisks. This Lifehacker article lists a few: Add Wireless Storage to Phones, Tablets, and Laptops with Wi-Fi Drives.
There's a number of USB-sticks that are so small, you can just leave them in. Here's a nice list of them:
Of these, I really like the Verbatim Store 'n' Stay because it seems the smallest of the bunch.
There's also a number of solutions that use the SD-card slot. They're basically adapters that take a micro-SD card. They're sized such that they sit flush with the outside of the MacBook.
I've got it fitted with a 16 GB micro-SD and it seems to work fine. There is no loss of speed noticeable, when comparing with the micro-SD-to-standard-SD-adapter that came with this card.
Articles, chronologically (latest first):
Not yet finished. Maybe will never be finished. Maybe they'll get deleted. Who knows?