I have been trying to understand how the SSH server settings are controlled on Leopard. To turn sshd on you tick the remote login box on the sharing preference pane. You can then control which users are allowed to log in by selecting them in the “allow access for” section.
But where does it store the settings? Traditionally you would have added a clause like
AllowUsers jad
to /etc/ssh/sshd_config. However OS X does not do this, instead it adds a file called
/private/var/db/dslocal/nodes/Default/groups/com.apple.access_ssh.plist
containing what appears to be a list of users in the remote login group. I have no idea what uses this file. Is it a modified version of sshd or is something cleverer at work?
And, what was wrong with the old way?
I am dictating this post using MacSpeech Dictate. It is amazing and much better than I expected at understanding what you’re saying. In addition to dictation it also allows you to control your computer, with commands such as “open mail” and “put this computer to sleep”.
When you are controlling your computer you have to be careful to use the correct language and it does take a bit of getting used to but it’s quite easy. There is an on-screen list of commands to refer to and most of them are fairly intuitive.
As far as I can tell MacSpeech Dictate seems to work in all applications. I have used it this morning in TextMate to write an XML document. Speaking “open angle bracket” is almost as easy as typing angle bracket. And long sections of text are obviously much easier to speak.
MacSpeech Dictate is able to detect commands during spoken text. Adding punctuation is easy, to add a full stop just say “full stop”. Correcting mistakes can be a little painful but can be done. Deleting a single word is done by saying “forget word” and deleting the last chunk of text that you dictated can be done by saying “forget that”.
It is really good in iChat. Being able to speak is exactly what you want when writing a chat message.
However, don’t forget to read what you wrote because it can make mistakes!
Why do some applications always generate such rubbish error messages. I am using eclipse for a project and it has just failed to start. The error on the screen was
That file contains this:
!SESSION 2008-07-08 08:34:44.307 -----------------------------------------------
eclipse.buildId=I20080617-2000
java.version=1.5.0_13
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86, WS=carbon, NL=en_US
Framework arguments: -keyring /Users/jad/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws carbon -arch x86 -keyring /Users/jad/.eclipse_keyring -consoleLog -showlocation
!ENTRY org.eclipse.osgi 4 0 2008-07-08 08:34:45.312
!MESSAGE Application error
!STACK 1
org.eclipse.swt.SWTError: No more handles
at org.eclipse.swt.SWT.error(SWT.java:3803)
at org.eclipse.swt.SWT.error(SWT.java:3695)
at org.eclipse.swt.SWT.error(SWT.java:3666)
at org.eclipse.swt.widgets.Display.createOverlayWindow(Display.java:741)
at org.eclipse.swt.widgets.Display.internal_new_GC(Display.java:2300)
at org.eclipse.swt.graphics.GC.(GC.java:149)
at org.eclipse.swt.graphics.GC.(GC.java:115)
...
Why do I need all the junk? Why didn’t the message on the screen just say something like. “Sorry, the application failed to start. The reason was - No more handles.”. Even better, it could explain what a handle is and how to fix it or provide a link to a knowledge base.
To exclude the annoying ._ files from tarballs built on OS X 10.5.x do this
export COPYFILE_DISABLE=true
Thanks to this thread for the answer.
A recent upgrade of my server to Ubuntu 8.04 beta forced me to solve an issue I have been having with the integrated MCP55 ethernet and recent Linux kernels. At boot the network interface appears to come up and shows as up in ifconfg. However, it just will not work. Eventually I found a fix on the Gentoo Wiki. However, adding the forcedeth module options specified to /etc/modprobe.d/options did not fix the problem. I think that the kernel is loading the module from initramfs and that needs to be updated as well. This is what fixed things for me.
Add the following line to /etc/modprobe.d/options
options forcedeth msi=0 msix=0
Then rebuild initramfs like this
sudo update-initramfs -u
BTW - this was the only issue I came across doing the upgrade over ssh. Everything else worked perfectly.