defaults write /Applications/SkyDrive.app/Contents/Info LSUIElement 1
What a busy week it’s been in the cloud file hosting world.
I don’t like ‘set and forget’ apps cluttering up my Dock/app switcher. So since that’s exactly what the SkyDrive preview is doing on my Mac, that little one liner is how to fix it.
(Assuming you’ve already downloaded and installed the SkyDrive.app preview into /Applications/, pop open a Terminal and hook up that one-liner. Tested on Lion 10.7.3. Bonus hack: The Info.plist file also is where the minimum OS requirement is stored. i.e. you might be able to get SkyDrive.app to work on <10.7 if you poke around in that file, but whatever consequences that has are definitely on you.)
Change your mind?
defaults write /Applications/SkyDrive.app/Contents/Info LSUIElement 0
will set things back to default, or just download a new copy.
Surely there are some big challenges in building a project like SkyDrive.app. So hey MacBU, or whoever’s on this, good work so far. But in case it’s not already in the pipeline, here’s one user’s humble request to put that checkbox in the prefs where it belongs.
[Shout out to you classy LaunchBar folks – the basis for this hack dates back to those halcyon days.]
A few years ago I re-purposed an old desktop PC from uni as a media and file server. A design goal was having the machine be as close to silent as possible. Noisy stuff is annoying anyway, but doubly so in a living room where silence really is paramount. To achieve that goal I used my steadfast Antec Sonata case with rubber-washer HD trays, an old fanless video card, and a new power supply with a 120mm fan (let me know when they make fanless ones for AT motherboards). The only noisy component left was the stock CPU fan which I replaced with a Thermaltake ‘quiet’ model. The result was a success if I say so myself, especially considering the total cost.
Last week that Thermaltake CPU fan hit the dust. The bearings just gave up. Luckily, that failure didn’t cause any other damage and since the motherboard is a few years old the replacement Zalman model fan was cheap. Unluckily, this Zalman was significantly noisier than what it replaced, despite claims of silent operation.
The solution was wonderfully simple: I attached a resistor to the red wire connecting the CPU fan to motherboard for slower RPM.
For a project that has lasted for so long and been so affordable I’m stoked how cheap and easy the simple solution was. EE FTW.
CLI junkies, this one’s for you.
Mac OS X doesn’t ship with an official package manager in a Unix/Linux sense. And why should it? Apple has a proven track record targeting the casual technology user ready to trade a credit card number for convenience, and this approach earns buckets of money. Thus the recent introduction of the Mac App store should come as no surprise. (And personally as a fan of ‘Internet as change agent’ I love that it will, even marginally, help reduce carbon emissions – Apple already plans to remove boxed software from its retail stores.)
Unlike in the smartphone world, software distribution for both producers and consumers on PCs/Macs has been traditionally been ‘everybody is on their own.’ On Windows there are standard 3rd party conventions, such as NSIS, and Microsoft/Apple-sanctioned ways of packaging software for distribution (.MSI and .PKG respectively). But developers/ISVs are not required to use them, and many don’t. (I’m looking at you, Adobe – your Mac installers are seriously the worst I’ve ever seen! Sometimes devs have reasonable grounds (read: limited time/resources) to employ them, but VISE and other Java-based installers I’ve encountered are unabashedly gross.)
Let’s jump away from the commercial side of computing for a moment and talk open source. Command line junkies (read: me) are into simple, lightweight solutions. We probably won’t ever use the Mac App store, preferring traditional open source package managers. We’re the folks comfortable at the command line and with modifying config files. Debian’s apt, Gentoo’s portage, FreeBSD’s ports, Red Hat’s yum are our bread and butter. The philosophies between us and the App Store’s target audience couldn’t be more different.
Speaking from the command line junkie perspective, I recently made the move from Darwin ports to homebrew. The best experience so far was the first one:
brew install git
It pulled the source and ‘just worked’ with minimal messing with my existing system.
ports, we’ll chat again when
port install git
doesn’t start weirdly compiling perl 5.8 on top of the perl 5.10 already supplied, supported by Apple, and working fine, thank you very much.
Interesting experience today: every single Apple Store in New Jersey was sold out of the iPhone 4 today. I know because I called them all.
A couple things: One, congrats to Apple. New Jersey today is hardly a representative sample but so-called “antennagate” doesn’t seem to matter in the state. Two, I got to experience first hand with building incredulity over each successive call how much people don’t care about the inherent inferiority of American-sold iPhones. What do I mean?
At first glance the US price appears to be the cheapest, but you’re locked into a 2 year contract with a $350 early termination fee. Much worse, the phone is artificially locked to AT&T’s network. If you want to travel, count your blessings that an unlock was released yesterday but it is of course temporary and will be assuredly be patched by Apple. (Unlocked phones are different from jailbroken phones.
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).