I recently got into a fairly heated debate on one of the Apple fora about the value of Disk Utility's Repair Permissions.
Specifically, someone suggested the repairing permissions was necessary before and after installing any patches, and could be the fix for application slowness.
Madness.
Utter madness.
Permissions are purely about files and directory access. You either have permission to open the requested file in the manner in which the application requests or you don't. The OS doesn't say - hey, I know, you've not got the right permissions, so I'll make you wait a bit, then grant you access. No, it returns EACCES straight away.
I see repair permissions being suggested as fixes for any weirdness that people can't find an instant explanation for, when, in reality, the only time you should need to repair permissions is if you're seeing permission denied in log files or similar behaviour.
Repairing permissions is very similar to pkgchk -f on Solaris. I don't recall ever recommending a customer should run this.
I worry that much of the "Windows" mentality of utilities being produced to do things that you expect the OS to do (such as tidying up thumbnail caches, or cleaning up the registry, or protecting against viruses, etc) is spreading to the Mac and even Linux world.
The other claim that was made in this same thread was that writing to large files was significantly slower than writing to small files. Apparently, this was because you had to read the file into memory and cache it before you could write to it.
What?!!!!!!!!!!!
Why the hell would you read a file into memory just so you can then write to it? It's possibly the most ludicrous statement I've ever heard.
All that happens is you open the file, get a file descriptor, fstat it, then write the data. Surely anyone who's spent 5 minutes around any flavour of UNIX should know this?
Posted by ajt [Mac] ( October 03, 2006 11:14 PM ) PermalinkI've recently had a couple of questions from folks about my blog entry on HumaneText.
One of these was around the fact that Safari now maps CMD-{ and CMD-} to moving between tabs, which are also the keybindings for HumaneText.
This can be changed with the following 2 commands, run from the Terminal:
defaults write com.apple.Safari NSUserKeyEquivalents \ -dict-add "Select Previous Tab" '@$\UF702'
defaults write com.apple.Safari NSUserKeyEquivalents \ -dict-add "Select Next Tab" '@$\UF703'
I hope this helps!
Update...
Will Critchlow tells me that you can just edit ~/Library/Services/HumaneText.service/Contents/Info.plist and change the key mapping for HumaneText in there - look at NSUserKeyEquivalents - then log out/in, and there you go...
Posted by ajt [Mac] ( May 24, 2006 10:12 AM ) PermalinkIt seems I've won a video iPod... I already own an iPod, of course (what self-respecting Mac user wouldn't?), but who could object to getting a shiny, new one?
I won it for filling in an internal survey on how much e-mail we receive, and why it's so bad...
I don't know whether my name was just drawn out of a hat, or if they chose a response that was vaguely useful (probably the hat...), but my responses are below. Most of them are straight from Merlin Mann's excellent 43 Folders site. Well worth a read, if you have the time.
Would you like to see the amount of email that you receive reduced?
Yes.
Most e-mail I receive that is not directly addressed to me is long-winded, usually irrelevant, and gets deleted instantly.
Would you like to receive better quality e-mails ?
Posted by ajt [Mac] ( March 20, 2006 09:18 PM ) Permalink Comments [1]Yes.
Because of the quantity of e-mail, I believe that the following rules should apply when sending:
Subject lines can convey whole messages: e.g.
- XYZ Meeting Tues 28/02 MOVED to 15:00
- Lunch resched to Friday @ 1pm
- REQ: Resend Larry Tate zip file?
- Thanks for the new liver?works great!
Be brief. Exceptionally brief. 1 paragraph is ideal.
Use small paragraphs - people do not, apparently, like reading dense text off a screen.
Don't bury the message. Put the one thing that you want to convey in a one liner at the top of the e-mail.
If you must be long-winded, follow rule 4, above, then explain in long and tedious detail. i.e. an e-mail should consist of:
- A one liner summarising the whole mail.
- An explanation
I strongly suggest that everyone, particularly those in senior management, read : http://www.43folders.com/2005/09/19/writing-sensible-email-messages/
It turns out that spotlight can be disabled, if you're seeing too much of a performance hit:
In /etc/hostconfig, set
SPOTLIGHT=-NO-
Then reboot!
Posted by ajt [Mac] ( May 01, 2005 01:24 PM ) Permalink |I pre-ordered my copy, having seen a friend's developer connection installs go well over the last few months, and liking what I saw in terms of features.
I thought I'd try an upgrade first, rather than clean install, play around for a bit, then do a clean install once I'd got to grips with it.
Well, the install went very smoothly, and everything seemed ok when I rebooted, but very slow. Turns out the spotlight indexer was running away, trying to index the 20 or so gigs that were on my drive.
Until... I started trying to use Mail.app. It kept hanging - it would list my mailboxes, and show me a list of messages in my mailbox, but it would just sit there spinning. tcpdump showed IMAP traffic, but nothing very interesting. So, I tried rlogging into one of our SunRay servers, and mutt-ing from there. Absolutely fine. Tried mutt from the Mac - locks up solid. tcpdump -vv port 143 shows lots of traffic, but with all tcp bad cksum errors. Weird. All other traffic looks fine.
At this point I suspected either something firewally or maybe the fact that I had Cisco VPN client, so disabled/removed both of them. And rebooted. Same problem. Fiddled some more, rebooted some more. Nothing
So, a clean install later, and everything's working as I expected.
Although... Spotlight is cool, but a real pig when it decides to index something (like the file contents of my iPod) at random times. It absolutely slaughters your machine.
One of the most significant improvements for me is the addition of a slideshow to Finder, coupled with the fact that image previews seem to build significantly quicker (thumbnails, I mean).
More rants or praise when I've played some more!
Posted by ajt [Mac] ( May 01, 2005 01:49 AM ) PermalinkMarkdown & Humane Text Service
It seems that I've been missing out doing clever stuff with my Mac. Most recently I've been reading 43 Folders, a site dedicated to "Getting Things Done", but largely, for me, a great resource of tips and tricks for "productivity toys" on the Mac.
Most recently, I've been introduced to:
Now, I couldn't see what the fuss was about. At first. Mostly because I couldn't actually get the damn thing to work.
In order to get it to work, I followed the instructions for Humane Text Service, then:
- went to ~/Library/Services/HumaneText.service/Contents/Resources
- rm forward
- ln -s Markdown.pl forward
And, suddenly, everything worked.
The beauty of it all is that you can write plain English (with a few syntax quirks), and the whole thing is completely readable. In fact, this blog entry is being written in Markdown format and is totally readable. At least, as readable as anything else I write!
The beauty of it is that it plugs into any Mac app that supports services, so I can type away in Markdown inside a textarea in Safari or Firefox, then hit convert text->html ( Cmd-{ ), and voila, I have nicely formatted HTML. Now, for most applications, I don't really need it, but it does mean that I can easily write documents in plain english for any media...
Posted by ajt [Mac] ( March 21, 2005 10:59 PM ) Permalink | Comments [3]I've played with jEdit, gVim, Emacs, HyperEdit, BBEdit, and various others - all the usual culprits that UNIX people would fight a corner for - but none of them have quite managed to be just right. The traditional UNIX ones, like vi/vim/gvim and emacs, whilst being great editors, and being what I've been brought up on, just don't fit in in the Mac environment - they're just too un-Maccy! :-) (and yes, curiously, I'm agnostic in the vi/emacs sphere - I use them both)
---Shameless Plug---
However, I recently got pointed at one called TextMate, which seems to have a great deal of the functionality that one gets from jEdit, whilst being native OS X. Highly recommended - the best feature is it's project sidebar, which is great for working on several files : where other project sidebars (like in jEdit) are able to list all files, I've not seen any that allow you to create pseudo-folders, so you can group all files relating to a particular part of the project together.
Get it from MacroMates.
---Shameless Plug---
Posted by ajt [Mac] ( November 05, 2004 04:37 PM ) Permalink | Comments [1]
The default browser on the Mac is Safari, which is great. Except it's very keen on caching, or seems to be. Which, when you're doing web page development, is a pain in the thing you sit on (no, not the chair!).
So I decided to try out other browsers. Camino, from the Mozilla folks. Great browser, happy with this. Until I notice a random extra flashing cursor in all my pages. That can't be right... So I've tracked this down to a text input field "showing through" from a different tab - if, say, I'm composing a mail in google mail, and switch to a new tab, the wretched flashing cursor from the compose box is still showing in this new tab!
So, next stop, Firefox, being a Mozilla fan. Now, Firefox doesn't, unlike every other Mac browser, understand about the location based proxy settings that MacOS X has - it expects you to set your own proxy settings. A pain, when you're moving between work and home.
Opera? Doesn't work with gmail.
Omniweb? Doesn't work with gmail.
So I find myself in this limbo state of constantly switching between 3 different browsers - I really want to use Camino, but this flashing cursor just irritates the hell out of me :-(
Posted by ajt [Mac] ( October 21, 2004 12:53 AM ) Permalink | Comments [2]

