Category: Technical

Categories
Cool Handy Music Technical

Stream your iTunes from home

Want to listen to your iTunes music at home from work, a coffee shop, etc?

It takes two steps: setup an SSH tunnel and forward zeroconf (‘Bonjour‘) traffic.

If you do it my way everything is already installed on your Mac and, especially nice for you corporate folks, doesn’t require admin privileges.
Windows users, you’re not necessarily SOL but Windows doesn’t ship with what you’ll need.

I use this technique on Snow Leopard, but I think it will work on Tiger and higher.

  • Enable SSH on your home computer.
    System Preferences->Sharing->Remote Logon
  • Enable iTunes Sharing.
    Preferences->Sharing->Share my library on my local network
  • Still from your home computer, browse to 192.168.1.1 (or whatever your router runs on) and enable SSH port forwarding if you haven’t already. This technique definitely won’t work without this step.
  • Protip: Optionally, register your public IP with a free Dynamic DNS service so you only have to remember a single domain name.
  • At your work machine, go to a terminal and use the following two commands: 
    dns-sd -P "myTunes" _daap._tcp. local 3689 localhost 127.0.0.1 &
ssh -N -f homeComputer -L 3689:localhost:3689

    The -N means non-interactive, the -f means go to the background.
    The -L xxx:hostname:xxx enables a tunnel on the iTunes sharing port (3689).
    homeComputer is your router’s public IP address, or the domain name you hopefully setup earlier.

  • To clean up when you’re done, you can run a 
    killall ssh dns-sd

Finally, if you’re cool enough to keep your music on a Linux machine, you can also use this technique with Firefly formerly (mt-daapd).

Categories
Handy Technical

Reference: screen sharing in Snow Leopard

Posted originally for my personal reference, but since my Mac tips get lots of Google hits hope this is useful to you too.

Screen Sharing on Mac OS X Snow Leopard – very convenient to have built-in*, and I use it to logon to my Ubuntu server when the CLI doesn’t cut the mustard – infrequent, but it happens.

If you’re like me, you occasionally get an unexpected blank or white screen when you connect to your other computer. It turns out the mouse and keyboard pass through just fine but the display is all white. Fix it by getting info on Screen Sharing.app and ticking the ‘Open in 32-bit mode’ box.

* Technical addendum: I would be remiss to sing accolades of the VNC-based Screen Sharing without mentioning Microsoft’s [Citrix] Remote Desktop. It’s significantly faster than VNC due to some sweet implementation differences – to my knowledge when you connect to the Windows host it switches to a special display driver that sends small drawing instructions over the tubes that are subsequently recreated on your client. VNC, while open source and commensurately ubiquitous in Unix/Linux/Mac land, is not so smart and blindly sends a compressed image of the screen. Just sayin guys – Remote Desktop is awesome.

Categories
General Technical

Speaking of speed…

I really don’t like waiting, especially when I can avoid it. Therefore, when I got tired of waiting for my computer recently I did something about it.

On SSH and passwords

The average ssh logon time consumes what feels like 3-4 seconds on my 2007-era machines. The delay has worsened since Ubuntu 0910, which now retrieves system information on logon (in its default form, nearly useless to me). I really like the idea of seeing useful info at logon time, but bottlenecking logon – the most common act that happens – for multiple seconds is unacceptable. If you’re like me, just use your own script instead of landscape:

apt-get remove landscape-common

I banged out some bash that runs nearly instantaneously and shows only what I actually care about, and it only took some lines in .profile. simple version:

echo 'df -h' >> ~/.profile
PATH=$HOME/bin/

Finally for a really good one that totally pays for itself: think about how many times you type in a password. The net time saved by not having to spend a few seconds typing in your password each time is huge.

echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config

It’s called public key authentication in SSH, and it’s one of the best kept SSH secrets.

Categories
Technical

Decent speed boost

Just finished optimizing the page load time by recompressing several large JPGs that used to be part of every page that had a sidebar (i.e. most pages on this site).

Load times are down to an average of about .983 sec from about 1.8 sec before. Hooray for more speed.

Categories
Technical

Note on building your own RAID5

RAID5, generally speaking, is a bad idea. Unless you have some very specific needs, RAID5 increases complexity, is more prone to hardware failure and administration errors, and does not automatically back itself up. If two RAID5 member drives fail at the same time, *all* your data is SOL. Individual drives, such as a bunch of externals, are probably a better choice for most people. And if two individual drives fail, you can still get data from the rest of them.

But people are nevertheless drawn to RAID5’s speed and size; it’s a great way to effectively have a freaking gigantic drive. It’s set and forget, easy to expand in the future (with some filesystems), and for reads is substantially faster than one drive. If one RAID5 drive fails, it’s an easy fix via drop-in replacement.

Some advice: when building a RAID array, use drives from different sources. Going different brands is probably a good idea, but caveat emptor: Company A’s 1TB drive will most likely not be the same ultimate size Company B’s. The available space will quite probably be skewed by a few KB or MB.

It should go without saying, but build your array only when you have all drives in hand. To more easily allow future expansion of your RAID, when it comes partition time shave a meg or so off your smallest drive. And when you decide to expand your array, buy a drive that’s the exact same model as one already in there. It will probably be cheaper than the newest model anyway.