Category: Apple

Link: Using a Raspberry Pi as an AirPlay Receiver

The Raspberry Pi is a versatile little computer that provides the perfect sandbox to start creating some fun and interesting projects. One popular project is as an AirPlay receiver, allowing us to stream audio from an iOS device or computer using iTunes to our Raspberry Pi that’s connected to a set of speakers.

In this tutorial, I’ll show you how to set up a Raspberry Pi to be used as an AirPlay receiver so you can stream audio from any iOS device, iTunes or compatible AirPlay software such as AirFoil.

Full article here:
Using a Raspberry Pi as an AirPlay Receiver (mac tuts+)

Video and Link: Turn a Raspberry Pi Into an AirPlay Receiver for Streaming Music in Your Living Room

Few things are better than kicking back on the couch and streaming your favorite album wirelessly to your stereo from your phone. It’s a remarkably easy thing to do with AirPlay, but if you don’t want to pay for Apple’s solutions, a $35 Raspberry Pi does the job remarkably well.

Full article:
Turn a Raspberry Pi Into an AirPlay Receiver for Streaming Music in Your Living Room (Lifehacker)

Installing Linux in place of OS X on an older Mac

Former title: Installing Ubuntu Linux (or Mythbuntu) in place of OS X on a Mac Mini (changed because this article is now less specific to Ubuntu or the Mac Mini).

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

All computers have their day in the sun, and then something new comes along that makes them less desirable. I have a Mac Mini that I acquired sometime around the time OS X Leopard came out, probably in 2009. As time went by it became slower and slower and I finally replaced it. However, it seemed a bit of a shame to have it just sitting in a closet doing nothing, so I decided to see if I could put Ubuntu Linux 12.04 (at that time the most recent LTS version) on it. I started out by trying to follow the instructions on this page (the Single Boot/MBR option) but ultimately it turned out to be not nearly that complicated. NOTE THAT THIS WILL NOT GIVE YOU A DUAL BOOT SYSTEM; THIS IS REPLACING OS X WITH UBUNTU LINUX, AND ALL YOUR EXISTING DATA ON THE HARD DRIVE WILL BE ERASED!!! YOU HAVE BEEN WARNED!!!

Also: THIS IS FOR EXPERIMENTAL AND INFORMATIONAL PURPOSES ONLY. This is what worked for ME. This MAY or MAY NOT work for you. It may even brick your system (if that should happen, try doing a PRAM reset before you totally panic). It did not do that to me, and I have never heard of anyone having that problem, but your hardware may be a bit different than mine, so I make NO guarantees!!! Here’s all I wound up having to do:

  • Connected a USB keyboard and mouse.
  • Before proceeding I made sure I had the latest firmware upgrade – that is very important since you can’t do it once you have installed Ubuntu, and the rest of this might not work if you have old firmware. Another thing you can’t do is disable the startup chime so if you don’t want that after Linux is installed, find a way to turn it off before proceeding (I wanted it, and it’s used in the instructions that follow, so I didn’t search for a way to disable it, and I don’t recommend you do either).
  • Inserted my old OS X Leopard installation CD (any OS X installation CD that works with the Mac should be fine for this procedure)
  • Rebooted while holding down the “C” key
  • Accepted the default language (English) and pressed Enter
  • From the top menu bar, I selected Utilities | Disk Utility
  • In Disk Utility I selected the internal hard drive in the left hand side panel. You have to select the drive itself (it shows the brand name of your drive), not the partition
  • Clicked the Partition tab, selected 1 Partition under the Volume Scheme (instead of Current)
  • Clicked the Options button and selected “Master Boot Record”
  • Clicked the Continue button (this erases the hard drive)
  • When the above finished, I quit Disk Utility, then quit the installer
  • The Mac rebooted — at that point I clicked and held the leftmost mouse button until the CD ejected
  • Inserted the Ubuntu Install CD, then power cycled the Mac Mini
  • At the startup chime I pressed the “C” key to boot from the CD
  • When the Ubuntu CD boots, you are given the option to install Ubuntu directly, or to try Ubuntu (which takes you to the Ubuntu desktop). As it turns out, I could have simply ran the installer. Instead, I did it from the desktop because I was following some instructions that said you have to type in some things during the install, and you need to have access to a terminal window to do that. But when I tried to type those things in, Ubuntu rejected them with errors, so I just let it complete the install (answering the questions it asked during the install). I did NOT select any special partitioning, etc. – I pretty much did a plain vanilla installation, generally accepting the defaults except where they weren’t appropriate or weren’t what I wanted.
Important
NOTE: If, when you boot into the Ubuntu installation CD, you are greeted with a screen that asks you to “Select CD Rom boot type” but you cannot select anything because neither the keyboard nor the mouse are functional, or if you get a black screen at some point early in the install process, then you may need a special build of Linux intended for use with 64-bit Macs that use a 32-bit EFI. Such models were mostly manufactured in the last half of the 2000’s. In that case you can try the solution offered here, if you can understand the instructions, or you can see if you can find a suitable ready-made .iso file at Matt Gadient’s site (note that even though it says “late 2006 models” in the title, those builds should work with late 2006 and later 64-bit Macs that use a 32-bit EFI).

When the install was finished (after quite some time), I rebooted. The only unusual thing was that after the reboot, the screen remains white for about 20-30 seconds right at the start of the reboot. Then after that delay, it finally decides it will load Ubuntu. That still happens and while it makes the startup take a bit longer, I’ve seen worse. The reason for this (and a possible fix) can be found here: Reducing the 30 second delay when starting 64-bit Ubuntu in BIOS mode on the old 32-bit EFI Macs.

Oh, and the sound was muted by default for some reason, and the volume slider set all the way down. After I unmuted it and turned up the volume slider, the sound worked normally.

The wired network connection worked fine. I don’t use WiFi here so I did not test that. If you have issues with those, or any other issues see GNU/Linux Debian on a Macbook Pro 11-1, which contains some additional hints that may make things run more smoothly (or work at all) after installation. I would use any hints on that page only if you have one of the specific issues that the author had. Another page with possibly useful additional hacks to make this work is Mac book pro 11.3 Linux customization (2): grub and hardware, which may be helpful if you have issues with an unrecognized Intel Iris GPU or Thunderbolt, but again I would only use these if you really need them, since this article is from 2014 and such hacks may no longer be necessary (by the way, this blog has several other pages of rather technical hacks for using Linux on a Mac Book Pro, and while many users will not need any of them, you can search that site for the phrase “Mac book pro 11.3 Linux customization” to find the other articles).

The only real hitch I found was that it wouldn’t boot if I didn’t have a video display connected! I have no idea why that was the case but there is a hardware workaround described on this page. Hope you didn’t misplace your Mac Mini’s DVI to VGA adapter! I had a 100 Ω resistor handy and that seems to work fine (it’s probably about 40 or 50 years old but what the heck, carbon resistors don’t change value that much just sitting in a junk box). If you can’t find the DVI to VGA adapter, I have read that at least one user placed a resistor directly into the DVI port between pins C2 and C5; you can use this pinout diagram to find those pins. However, I have not tried this, so I make no guarantees. Either way, the point is that the resistor goes between the analog green signal output and the analog ground return. If you can’t find the adapter, can’t get this to work, or if you just don’t want to mess around with a resistor, you can try a DVI Emulator/Dummy Plug that includes an EDID chip, that may be available from Amazon or eBay. A DVI 1920×1080 or 1920×1200 model should be sufficient. Such a device fools the Mac Mini into thinking a display is connected.

After I had this running for a year or two I read that Ubuntu doesn’t control the system fan properly. You can do this in some newer versions of Ubuntu (and possibly other Linux builds) to get fan control to work. First, try using your chosen Linux distribution’s Software Center or package manager to search for and install the macfanctld package (after you check for updates). If that doesn’t work, try this (assuming you’re using a Ubuntu or Debian based distribution):

sudo apt install -y macfanctld

On my system at least, it appeared that this did cause the fan to run a bit faster but not enough that I really noticed it. Once it is installed, you can type man macfanctld at a Linux command prompt to get configuration instructions. Changes to temperature limits and minimum fan speed are made in the file /etc/macfanctl.conf.

Also, although I have not personally done this, I have read on a couple of pages that you can enable automatic reboot after a power interruption by adding one line to /etc/rc.local (this may be Ubuntu-specific, but you can always remove it if it doesn’t work):

setpci -s 0:1f.0 0xa4.b=0

If you have smb or samba installed (it is installed by default in many distributions) and find that your samba/smb log files fill up with complaints such as “Unable to connect to CUPS server localhost:631 – Connection refused”, here is a workaround. In the [global] section of /etc/samba/smb.conf add these lines:

printing = bsd
printcap name = /dev/null

Then from a command prompt restart samba:

sudo service smbd restart

Long ago I read a post on Reddit where the author said, “After months of headaches and tinkering I’ve finally found the stupid way to let Linux work properly on Macs. Just add acpi_osi=Darwin as boot parameter.” Unfortunately I did not save a link to that post so I have no idea if still valid advice, and therefore I would only try it if something (particularly Thunderbolt) isn’t working right and you can’t resolve it any other way. If you understand Linux kernel stuff see the final paragraphs of this page for a discussion of this setting, also see Section 2 on this page. If you don’t use the Thunderbolt port then you probably don’t need this, and you may not anyway.

By the way, I had intended to try Linux Mint but they no longer offer a version that fits on a CD, and I still have about a gazillion blank CDs (plus I already had Ubuntu 12.04 burned to CD) and since the Mac Mini doesn’t have a BIOS in the traditional sense, there is no way to install from a USB stick, so Ubuntu it was. For what I plan to do with this, having Mint would be no advantage. Many older Macs have issues booting from a USB memory stick, although one site I read said that they might be able to if you use UNetbootin to transfer the Linux image file to the USB stick. I did not attempt that, so I cannot say whether that works. I got it to work using a CD, but I do realize that CD and DVD burners are becoming somewhat of a scarce item these days.

Speaking of DVD’s, if you have burned some Linux distro (or maybe even Windows) to a DVD and the Mac Mini refuses to read it, it may be because it’s the wrong kind of DVD. To quote from a comment in a Reddit thread entitled “[GUIDE] How to install Windows 10 on a Late 2006 iMac (And every other old Mac)“,

IMPORTANT: iMac’s internal DVD drive is very picky when booting from DVDs. Don’t use DVD-RW or DVD+RW. Don’t use DVD+R. It will only work correctly with DVD-R discs!

Most blank DVD’s have an inscription on them somewhere indicating what type of DVD they are, although depending on how it was inscribed on the DVD it may be hard to read. Someone I know actually had this issue with one old Mac Mini, where it refused to read a DVD until they found some DVD-R’s and burned the new operating system to one of those.

Note that nowhere above did I mention a program called rEFIt, nor did I mention BootCamp. I didn’t need either of those.

Had this not worked I could have always reinstalled Leopard, but again, for what I was doing with this system (running a Tvheadend backend, for one thing) Linux was probably a better choice, but I still wanted to be able to use this as a backup regular desktop computer, should the need ever arise.

One final note: This is the xorg.conf I used with my “headless” system. It came from this blog post and I did have to save it as /etc/X11/xorg.conf and not the filename shown in the post (in newer versions of Linux I believe this location may have moved yet again, so you may need to search to find the correct location for the xorg configuration for your distro). Note this is only something you might consider using if you have installed a version of Linux that includes a desktop; you don’t need this if you have a server-only version of Linux that has no desktop installed (one where you do everything from a Linux command prompt). Note also that this won’t work if you are running the Wayland display server; you must be using the X window system (a.k.a. X11 or Xorg) for it to work:

Section "Monitor"
  Identifier "Monitor0"
  Modeline "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync
  Modeline "1024x768_60.00"  64.11  1024 1080 1184 1344  768 769 772 795  -HSync +Vsync
EndSection
Section "Screen"
  Identifier "Screen0"
  Device "VGA1"
  Monitor "Monitor0"
  DefaultDepth 24
  SubSection "Display"
    Depth 24
    Modes "1920x1080_60.00" "1024x768_60.00"
  EndSubSection
EndSection

Create an “Unmount” service in Mac OS X

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

I have been having a problem with a couple of different USB devices that I occasionally connect to my Mac.  I would attempt to eject them and they would immediately remount themselves.  Therefore, it was almost impossible to do a “clean” disconnect of the device.  If you’ve had this problem you’ll know exactly what I’m talking about, and if you haven’t then you don’t need this article.  If you choose to use the information here, bear in mind that even though it worked for me I have no idea what it will do on your system, so use at your own risk or don’t use it at all!

I found that I could “Unmount” rather than “Eject” the devices using Disk Utility and then they would not automatically remount, but it was a bit of a pain to have to go to Disk Utility every time I wanted to unmount a device.  Automator to the rescue! Here are the three steps to create and use an “Unmount” service in OS X:

1. Fire up the Automator application and when it comes up, tell it you want to create a Service:

2. Create an Automator workflow exactly as shown here (click on the image to enlarge it).  Note that the top part must say “Service receives selected Folders in Finder” and after that there is one step, “Run Shell Script”, in which you’ll pass input as arguments. In the text field simply put hdiutil unmount $1

Save the workflow using an appropriate filename (I suggest “Unmount”). It will be saved in your ~/Library/Services/ directory.

3. To use the service, open your /Volumes directory in Finder and select the volume you want to unmount, and right-click on it (or however you bring up the context menu in Finder on your system). Near the bottom you should see a menu selection for “Services” and in a sub-menu you should find your “Unmount” service:

Click on that and your volume should be unmounted (if you have Hardware Growler installed from any version of Growl, including the free forked Lion version, then you should get a Growl notification of the unmount). I will note that this has no error checking other than that built into the command-line hdiutil program, so while it probably won’t hurt anything if you try to unmount something that’s not unmountable (such as a file), I’d still try to be careful.

If you have a problem with devices that refuse to unmount the then you could use the same procedure to create a “Force Unmount” service. I’d still create the regular “Unmount” service as shown above, but if you sometimes have the problem that the device won’t unmount the normal way then simply follow the above steps again except name the service “Force Unmount” and add the -force flag, like this:

hdiutil unmount -force $1

Or if eject normally works, but sometimes you want to force it, you could create a “Force Elect” service using:

hdiutil eject -force $1

I do not guarantee anything with regard to the use of the -force option (I read about it here), so if you go that route and lose data, don’t blame me.  As I said, you use this stuff at your own risk.

Happy unmounting!  And if this doesn’t work for you the way it worked for me, I’ll tell you up front that I have no clue why, and that’s partly because I don’t understand why a plain old eject attempt fails on some systems (as I say, eject actually does work, but then the device immediately remounts).  It’s all a mystery to me!

Links: OS X Notifier App Growl Goes Closed Source, but a free forked version (that works in Lion) is available

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Here’s a few links on this issue:

OS X Notifier App Growl Goes Closed Source (Slashdot)

Episode 47 – Fork You Growl! Interview with Perry Metzger (from The Basement Coders Developer Podcast — if you care at all about Growl you should listen to this, preferably before spending any money on their allegedly broken App).

[growl-discuss] Growl 1.2.x for Lion source for XCode 4.1 (including a fixed HardwareGrowler)

Patched version project page on bitbucket

Download page for forked version

Growl-1.2.2f1.dmg direct download link (if it doesn’t work check the link above — there may be a newer version).

EDIT: Link to Growl Source Installation information for Growl 1.3 — it appears that after the Slashdot article was published, the Growl developers decided to release the source to Growl 1.3 (making the headline of the Slashdot article and this article inaccurate in the process).  However, this does not mean that the problems with the new version have been fixed (as of the date of this article) — it probably only means that they didn’t like the bad publicity about not releasing the source and decided to address that issue, in an attempt to blunt some of the criticism.

I’m presenting the above links so that anyone interested can check them out (and so I can find them again in the future). I will just say that I generally agree with the sentiments expressed in the podcast. I think it’s really underhanded when a project that has been free for years (and has accepted contributions of both cash and code from folks that probably thought it would be free forever) tries to go commercial, and it’s even worse when the commercial app doesn’t work as well as the previous free version.  And I won’t even get into the issue of the censorship, because the Growl developers have the right to censor whomever they want in their forums, but in this case it sure sounds like they were trying to deprive their users of the knowledge that someone else had fixed their buggy code and made it freely available.  If they choose to do that, then it’s up to others (like you and I) to let Growl users know that an alternative exists.

I hope that either the forked version gains acceptance (and exposure, since few people seem to know about it at the moment) or the original Growl developers see the error of their ways sooner rather than later. What IS it with developers turning greedy lately?  Keep in mind that had Growl not existed (and worked so well in its previous free incarnation), it’s quite likely that the Apple folks would have developed their own notification system and made it a component of OS X.

EDIT:  Two things you should know about Growl 1.3 before you fork over your two bucks:  First, due to App Store requirements, it no longer installs as a preference pane in System Preferences – it’s now an application (the podcast explains this in more detail).  And second, “Growl 1.3 and later do not have update checkers built into them, so you will need to keep up with when releases are put out”, according to the Growl Source Installation page.

Full disclosure:  I also censor comments — see my comment policy in the right sidebar — but it’s generally because they are spam or include one or more links that I consider spam, or because someone is being rude and nasty.  You can call me all the names you like, but I’m not going to approve such garbage for others to read.  However, there are right reasons and wrong reasons to censor comments or to ban a user, and I’ll leave it to the reader to decide (after listening to the linked podcast, which I strongly recommend before you form any strong opinions on this) whether the Growl folks should have banned Mr. Metzger.

Related articles

Link and comment: Slate Reprints Blue-Box Article That Inspired Jobs

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.
Blue Box at the Computer History Museum
Image via Wikipedia
From a post on Slashdot, posted by timothy on Monday October 10, @05:09AM:

Slate has reprinted the piece that Ron Rosenbaum wrote for Esquire in 1971, explaining to the world that there was an underground movement of people hacking the phone system. (Rosenbaum is now a columnist for Slate.) According to the article’s new introduction and followup piece by Rosenbaum reflecting on its impact — and to the New York Times obituary for Steve Jobs — this article inspired Jobs and Wozniak to start building blue boxes themselves, an effort that made them several thousand dollars.

It has been reported (though I can’t recall the source at the moment) that this is the article that caused AT&T to turn its employees into common thieves.  The idea that people might have access to this information frightened them so much that they literally sent their people out to steal the copies of this issue of Esquire from every public library in the country (of course they missed a few).  Although this was long before the days of the Internet and the “Streisand effect“, it did have the result that those who had access to the article had a tendency to photocopy it and pass it around, so AT&T’s ham-fisted attempt at censorship probably gave the article far more exposure than it ever would have had in the first place.

I would daresay that one article probably had a significant effect on our modern way of life.  For one thing, it taught us that “security through obscurity” doesn’t work, and for another it forced AT&T and other phone companies to modernize their phone networks (probably much earlier than they would have otherwise intended) to prevent the type of “toll fraud” made possible by the blue box, and that made it much easier for alternative long distance carriers to offer their services.

Although I never had the technical skills to build a blue box, I definitely wanted to know how they worked.  The copy of Esquire at my local library had already gone missing but I discovered they still had a copy at the Grand Rapids public library.  Apparently the librarians there had apparently been tipped off about AT&T’s attempts to make that issue disappear, so they were keeping it behind the desk and you had to request it from a librarian.  Which I did, and then promptly asked where the photocopy machine was.  The librarian looked me over and said, “You’re not going to copy that article, are you?” and I said, “Oh, yes I am!”  She clearly disapproved, but still pointed me in the direction of the copier (the alternative would have been to attempt to forcibly pry the magazine back out of my hands!).  That copy of the article went back home with me and got shared with a few interested friends, and at least two of them later got jobs in the telecommunications field.

Of course, nowadays it would be a simple task for any modern computer to generate the same multifrequency tomes that blue boxes generated, but the last telephone company in the country to actually use that signaling method dropped it on June 15, 2006.  And now we have computers and the Internet and VoIP, but I have a feeling that much of that might still not be in existence had it not been for that one article, which literally gave birth to an entire community of hackers, many of whom later went on to do great things and to build the networks we have today.  It’s funny how one thing that seems so small at the time — in this case, one magazine article — can create such ripples throughout society.

How to install Midnight Commander under Mac OS X (the easiest way?)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog. We have used the information here to install Midnight Commander 4.8.10 under OS X 10.9 (Mavericks) and also to install Midnight Commander 4.8.12 under MacOS 10.13 (High Sierra) and in both cases it was a quick and painless install, and works great!
Midnight Commander
Image by mcastellani via Flickr

Over the many months that this blog has been available, one of the most consistently popular posts has been, How to install Midnight Commander under Mac OS X (the easy way, using Rudix). Unfortunately, at the article notes, the developer of Rudix changed his package and while you can still use Rudix to install Midnight Commander on your Mac, it’s not quite as straightforward an installation as it once was.

This morning I received a comment from reader LouiSe on that article, that read as follows:

What do you think about an up2date universal binary installer package? … http://louise.hu/poet/tag/mc/

Well, if it works I think it’s a great idea, but I don’t have the time to fully test it and since I’m still running Leopard, I have no way to test it under Snow Leopard.  So I’ll just throw it out there and say that if any of you would like to test it (at your own risk, of course) and see how well it works for you, I’d appreciate it if you’d leave a comment.  For the time being, be as careful as you might be with any software from an unknown source.  But if you’re daring enough to give it a try, this might indeed be the easiest way to get the latest version of Midnight Commander onto your Mac.

Since Midnight Commander is free and available for virtually all versions of Linux, learning to use it now will put you a step ahead for the day when you get sick of being seen as a cash cow by Apple, and are ready to move on to a computer that runs Linux.  Ubuntu Linux in particular has finally matured to the point that it is actually usable by non-geeky types, and the vast majority of the software in the Linux world is still free.  I like free software, and I don’t like watching the “spinning beach ball of death” on my Mac Mini, so unless someone gives me a newer one as a gift or something (not likely), the Mac Mini I’m using now is probably going to be the last Mac I will ever own.

Improve the Mac’s ability to display colors

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which in turn was reposted with the permission of the original author from a now-defunct Macintosh-oriented blog. It is reposted with his permission.

This article was originally posted in January, 2009.

One issue that some Mac “switchers” have encountered is that the colors on the Mac display look just a bit washed out compared to those on a PC. It’s generally not enough of a difference that anyone would complain; in fact, many new Mac users would think it was their imagination, or would attribute the difference to hardware variations (different display or graphics card).

In reality, however, there is a difference, and it is due to a configuration choice made by Apple. There is a page that describes the issue in some depth:

A solution to Mac “Save For Web” colour discrepancies

The gist of the problem is that Apple has chosen to, by default, go with a gamma setting of 1.8, whereas other systems use 2.2 as the default. On the above-mentioned page, it gives this bit of wisdom: “Unless you have a color management expert instructing you otherwise, select a 2.2 gamma and a D65 white point.” However, the white point is not as important as the gamma, and you may wish to use the default white point that has been determined to be right for your display. It’s most important to change the gamma setting, and calibrate the display in the process. How do you do this? By setting up a new color profile. This is fairly easy to do.

First of all, if you are using the “Shades” program (or any other program that gives you software control over display brightness or any other display parameter), go into the program or preference panel and turn it off before you begin this process, otherwise it may fight you at every step of the calibration process, turning an easy task into a really difficult one with less than satisfactory results.

Go to System Preferences, click on Displays, then go to the “Color” tab, then click on “Calibrate”:

System Preferences-Display-Color Tab
System Preferences-Display-Color Tab

Then follow the instructions. BUT, before you change the setting of your display’s contrast (using the control on the display itself), make a note of the current setting. You will be changing it as part of the calibration process but once you are all finished, you may decide that you want to go back to that setting, or something reasonably close.

During the calibration, when you are asked to adjust the monitor’s brightness, it will say to set it to where you can “just see” the oval:

Display Adjustment screen
Display Adjustment screen

The only problem is, Apple’s idea of “just seeing it” and yours might be a bit different. We wound up using a setting that was a bit more than where the oval was just barely perceptible, but still a bit less than where the two halves of the surrounding rectangle started to appear as different, and that seemed to work best. Originally we tried setting it where the oval was just barely perceptible, but then after the adjustments were completed we couldn’t get a monitor setting that we liked (everything was too dark for our liking, particularly on some of the wallpaper).

When you get to this screen:

Target Gamma Selection
Target Gamma Selection

You want to select the “2.2 Television Gamma” because that is the setting used on most non-Apple computers, and therefore that is the setting that most graphics (including those on the Web) are adjusted for. This is the setting that Apple probably should have used in the first place – at least they give you the option to use it, but we think it should have been the default. On the next screen you’ll be asked to select a target white point:

Target white point selection
Target white point selection

We suspect that “D65″ and “Native” are very close on modern displays (perhaps even identical). You can try both and see which works best, or you can just go with the recommendation from the above-mentioned article to use D65.

EDIT: The second time I attempted to do this, the display calibrator crashed before I could save the settings.  If it happens to you, try this: In Finder navigate to Macintosh HD/System/Library/ColorSync/Calibrators/Display Calibrator.app and right-click on the application, then click on “Get Info”, and when the information panel is displayed, you should see a checkbox for “Open Using Rosetta.”  Check that box, and the problem goes away (at least it did for me, and for the people who posted replies in this thread).

When you are all through, you are likely to see color in places that only looked grey or washed out before. That is because Apple’s default color profile and gamma setting tends to wash out certain colors. But, unless you have just acquired your Mac, it will look strange to you, because it’s not what you’ve become used to. You may have to try adjusting the monitor’s brightness and contrast to get something you like. The interesting thing is that whites may seem “whiter” than before and that may throw you a bit, but it will also show how screwed up Apple’s default color profile is. Try it for at least a day or two before you decide you don’t like it. We found that by setting the monitor’s contrast back to the original setting (the one we told you to note in the previous paragraph) and then using the brightness to adjust the monitor for best picture yielded the best results, but your results may be different.

If you decide you really hate the calibrated profile, you can always go back to the default Mac color profile for your monitor, but then you can expect displays on other computers to look strange. Keep in mind that if you’ve gotten used to looking at washed out colors, it may take some time to adjust!

Stop entering passwords: How to set up ssh public/private key authentication for connections to a remote server

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which in turn was reposted with the permission of the original author from a now-defunct Macintosh-oriented blog. It is reposted with his permission. Comments dated before the year 2013 were originally posted to The Michigan Telephone Blog.

This article assumes that you are already able to ssh into a remote server using a password (that is, that your account has been created on the remote system and you are able to access it). Here’s how to set up ssh public/private key authentication so you don’t have to use the password on future logins, or so you can use Public Key authentication with MacFusion.

First, open a terminal or iTerm window as we will be using it for most of the following operations. First, navigate to your home directory, and see if there is a folder called .ssh. Note that Finder will NOT show you this directory unless you have it set to show all file extensions, so since we are at a command line prompt anyway, it’s easiest to just type “cd ~” (without the quotes) to go to your home directory in Terminal or iTerm and type “ls -a” (again without the quotes – always omit the quotes when we quote a command) to see if the .ssh directory exists. If it does, go into the directory (”cd .ssh”) and see if there are two files called id_rsa and id_rsa.pub (use “ls -a” again). If either the directory or the files do not exist, you will need to create them.

ssh-keygen -t rsa -f ~/.ssh/id_rsa -C "your@emailaddress.com"

Replace your@emailaddress.com with your email address – this is just to make sure the keys are unique, because by default it will use your_user_name@your_machine_name.local, which might come up with something too generic, like john@Mac.local. It’s unlikely that anyone else is using your e-mail address in a key.  If this process fails with a “Permission denied” error, it might be because SELinux is enabled.  To check that theory, see How to Disable SELinux, which will show you how to disable it temporarily (for testing) or permanently.

Now, from your terminal window on your local system, execute this command:

ssh-copy-id username@remote

You can run ssh-copy-id -h or man ssh-copy-id to see the available options, but normally you don’t need any. In the event your system does not have ssh-copy-id installed, you can instead run the following three commands from a terminal or iTerm window on your local system. Whichever method you use, replace username with your login name and remote with the address of the remote system. Note that you should NOT be logged into the remote system when you execute these – these are run from a command prompt on your local system, and you probably will be prompted to enter your password (for the remote system):

ssh username@remote ‘mkdir ~/.ssh;chmod 700 ~/.ssh’

The above creates the .ssh directory on the remote system and gives it the correct permissions. If the command fails (for example, I’ve had it complain that mkdir isn’t a valid command, even though it is on just about every Unix/Linux system), then either you have copied and pasted the above line and WordPress changed the single quotes to the “prettified” versions (so change them back) or you may have to actually log into the remote system (using a password) and enter the two commands individually (mkdir ~/.ssh followed by chmod 700 ~/.ssh). Then, if you don’t already have an authorized_keys file on the remote system, go back to your local terminal or iTerm window for this:

scp ~/.ssh/id_rsa.pub username@remote:~/.ssh/authorized_keys

The above creates a new list of authorized keys on the remote system (overwriting any existing file with that name) and copies your public key to it.  If you already have such a file and don’t want it overwritten, then you’ll have to manually add the contents of your local ~/.ssh/id_rsa.pub file to the end of the ~/.ssh/authorized_keys file on the remote system.

ssh username@remote ‘chmod 600 ~/.ssh/authorized_keys’

This fixes the permissions on the authorized_keys file on the remote system. Once again, there may be the odd situation where you can only run the command within the single quotes from the remote system.

And, that’s basically all there is to it. If you are the system administrator of the remote system, but you don’t ever plan to login from a remote location as root, then for extra security edit the file /etc/ssh/sshd_config on the remote system (you’ll probably have to be root, or use sudo to do this task). Just use your favorite text editor on the remote system to open the file, and look for a line that says:

PermitRootLogin yes

And change the “yes” to “no”.

If you are still asked for a password after you are finished making the above changes, look for a line in /etc/ssh/sshd_config that says:

StrictModes yes

And change the “yes” to “no”. You’ll need to reboot or restart the ssh server for this to take effect. An alternate, and probably more secure fix is to check the permissions on your home directory – if it is not writable by anyone but the owner, then it should not be necessary to change the StrictModes parameter. For more troubleshooting hints see Debugging SSH public key authentication problems.

The above are very basic instructions for setting up ssh public/private key authentication. There are other ways to do this (including some that are arguably a bit more secure) but we wanted to keep it simple. Hopefully this will help someone who is using ssh, MacFusion, etc. and wants something a bit more secure and less bothersome than password access.

One other note:  If you find the connection drops within a minute or so, particularly after you’ve just purchased a new router, then on the client machine running Mac OS X edit the file /private/etc/ssh_config (under Linux it’s /etc/ssh/sshd_config and I don’t know what it would be called under Windows, or if they even have such a file) and add this line:

ClientAliveInterval 60

If it still stops working lower the timeout to 30. See How to fix ssh timeout problems for more information.

If you find my instructions confusing, try SSH Passwordless Login Using SSH Keygen in 5 Easy Steps.

And, for hints on making ssh more secure (particularly if you permit access from the Internet in general and not just your local network), see this article on Securing OpenSSH (via the CentOS wiki).