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.
This falls into the category of “notes I am posting for myself so I don’t lose them”. A Logitech C910 Webcam works under Mac OS X (more or less — some users have had more success than others), but the Logitech Webcam Software is buggy and Logitech seems to be in no big hurry to fix it, as can be attested to by the many posts in their Webcams forum complaining about problems using the device with a Mac. I followed all the instructions in this thread (which was actually for OS X 10.6 but I was grasping at straws) but nothing helped – after I uninstalled and reinstalled the Webcam software, it would run fine ONCE and then after that, every time I’d try to run it again, it would crash immediately after opening. This was not always the case, but perhaps something was broken during an upgrade.
I figured out that if I go into /Users/username/Library/Preferences/ and remove the files com.logishrd.LWS.plist and com.logishrd.LWS.plist.lockfile it would then not crash on the next run attempt. So, Logitech’s software is buggy because the mere presence of these files should not cause the software to crash. Note this is with the lws220.dmg software so if they ever release a newer version it just might fix the problem.
I suppose you could write an AppleScript to delete the two offending files and then launch the Logitech Webcam Software, but I have not got around to that yet (I An Not A Programmer). My question is, why doesn’t Logitech fix their damn software instead of leaving OS X users hanging, waiting for a solution? People have been complaining about these issues for at least a year and a half now!
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!
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.
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).
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.
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.
If you’ve installed Midnight Commander and haven’t changed the default colors, when you try to access a dropdown menu you may see this:
Midnight Commander — Original Colors
REALLY hard to read that menu, isn’t it? Wouldn’t you rather see this?
Midnight Commander — Changed Colors
To fix the unreadable menus, just make sure Midnight Commander is not open, then use any text editor (such as nano) to open ~/.mc/ini:
nano ~/.mc/ini
Assuming that there is no existing [Colors] section in the file, just add this at the bottom of the file (if the second line exceeds the blog column width, just use copy and paste to get it all):
If there is an existing [Colors] section, you can try tweaking it using the parameters shown above. If you have a very recent version of Midnight Commander (which you probably will have if you are running Ubuntu), then instead of menu= you’ll need to use menunormal=, as shown here:
Note that for some reason the base_color parameter must appear, or the other items are ignored. Save the change, exit the editor, and open Midnight Commander. If you then close Midnight Commander, you may find that the position of the [Colors] section has moved within the ini file — apparently Midnight Commander rewrites the file when you close it — but if you don’t like the changes you can remove the [Colors] section to reverse the change.
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!
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:
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.
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:
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
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
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
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
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!
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.
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):
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:
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.
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:
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).
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.
EDIT: This article has been revised to show the latest information as of 2012. Note that these instructions probably will not work unless you are running a relatively recent version of OS X. Also, you really should read How to install Midnight Commander under Mac OS X (the easiest way?) before using the procedure shown here!
I have to admit, I am one of those people who dislikes Linux for one major reason: Whenever you ask for help in any online forum, the knowledgeable people all seem to be command-line devotees, and they invariably give you instructions that involve typing long, arcane commands into the command line. I hate using the command line – if I had wanted to use a command line, I’d never have moved away from MS-DOS, and i cannot understand why Linux geeks insist on using it, and on trying to get others to use it. Even users of Linux distributions such as Ubuntu have found that when they go online asking how to do some function that could easily be accomplished using one of the GUI tools, often some obnoxious twit helpful person will reply by giving a bunch of stuff (that makes no sense at all to the uninitiated) to type in at the command line. One of the things I like most about Mac OS X is that you almost never have to do anything from a terminal prompt if you don’t want to, and Mac users seem to have a healthy disdain for using a computer as if it were still the 1970’s.
Long ago, when I was using MS-DOS, there was one tool that I had to have on any system I was using: Norton Commander. The original, dual-pane file manager that made it oh-so-easy to do typical file manipulations like copying and moving files, viewing and editing text files, launching executables, etc. without typing in DOS commands. Norton Commander was such a great program that it inspired similar programs on other platforms, such as Total Commander under Windows, and the cross-platform muCommander that runs on just about anything (if it has Java installed). In the Linux world, KDE users have Krusader, and Gnome users have Gnome Commander.
Mac OS X users have a number of choices, including the aforementioned muCommander and Xfolders, both of which are free. Possibly the best alternative today is XtraFinder, which is excellent and free — it add tabs and other features to the OS X Finder, and can display dual panes in either a horizontal or vertical alignment.
However, despite your best intentions, there may come a time when you find yourself working at a shell prompt. Maybe you are working with a Linux server, or on a Mac, maybe you can’t get OS X to come up but you are able to get to a terminal prompt (in my early days of using a Mac, this happened to me twice after OS X upgrades). More commonly, you are getting a permissions error on some file and can’t understand why – that’s very rare on the Mac, but it happens, and now you find yourself in the terminal trying to remember how to change permissions or ownership on a file (by the way, in most cases you should be doing this by right-clicking on the file in Finder, then clicking on “Get Info” in the context menu, and then using the Sharing & Permissions section at the bottom of the information panel. But there are occasions when nothing else seems to work, and you want to go a bit deeper into the guts of the system). It is at those times when Midnight Commander may be the tool you want.
However, up until now there has not been a really easy way to install Midnight Commander on a Mac running OS X (at least not that I’ve seen). But now, there is a package by Rudá Moura called Rudix, which is described this way:
Rudix features a world class collection of pre-compiled and ready to use Unix compatible software which are not available from a fresh installation of Mac OS X but are popular among other Unix environments. Here you can find utilities, programming languages, libraries and tools delivered as standard Mac OS X packages.
Now, I hear some of you “cut-my-teeth-on-Unix” types screaming, “What about MacPorts? What about the Fink project?” Those are all well and good if that’s your cup of tea, but they require a much higher lever of Unix “geekiness” to install, and they add a lot of code that the typical user doesn’t need. Rudix will let you add a whole bunch of Unix utilities if you really want to do that, but if you only want a few needed utilities then the “Custom Install” button in the Rudix installation lets you select exactly what you want, and no more.
So here is how you would install Midnight Commander in Mac OS X, using Rudix:
Go to the Rudix mc: Midnight Commander page. Select the correct package for your version of OS (filename ends in .pkg) and click on the package filename. On the next page, click the package filename again to download it to your computer. When it has downloaded, double click on it to run it. You should see a screen like this:
Rudix – Midnight Commander installer
Click “Continue” and continue to do so until it has been installed. That’s all there is to it!
I should point out that this used to be a much more convoluted process, and there was a much longer set of instructions here explaining it, but all those old instructions are superfluous now.
Once you have installed Midnight Commander, you will realize that you can easily install many other utilities commonly found on Unix/Linux systems, if they are available in the Rudix package list. Personally, I would not go hog wild on this – I’d only install the utilities you actually need, as you need them. One package I typically install is wget, because so many scripts (such as those written in Perl) expect it to be present.
Edit March 28, 2008: I made an interesting discovery tonight. Normally I use iTerm as my terminal program, and Midnight Commander runs fine in that. What it does not seem to run so well under is the Terminal.app program that comes with OS X. What specifically does not work in Terminal.app, at least on my system, is the mouse. Under iTerm, mouse clicks get passed to Midnight Commander in the normal manner, but under Terminal.app that doesn’t seem to be the case. Another thing that you can do in iTerm (but not Terminal) is hold down the ⌘ (Command) key and right click on a file to select it. So, for the “best user experience”, so to speak, I’d suggest downloading and installing iTerm, which has a lot of other nice features you’ll probably appreciate (and did I mention it’s free?).
Edit April 1, 2008: If, for some reason, you want to modify the color theme of Midnight Commander, here are a couple of blog posts that show how to do that:
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
Recent Comments