It would seem logical that iBooks and iTunes U would be available in versions for OSX as well, but there’s no sign of that. Or is Apple planning on running iOS apps on OSX in something like the iOS simulator? What’s going on here? As it stands now, it makes no sense.

Install tftp-hpa using the “server” variant like so:

sudo port install tftp-hpa +server

Then go into the preference file (which isn’t in the same place as most plist files):

sudo pico /Library/LaunchDaemons/org.macports.tftpd.plist

…and remove the “-s” command line parameter, while changing the path to “/private/tftpboot/”. The “-s” parameter forced a chroot which won’t allow tftp to follow symlinks outside the given path, making netbooting impossible.

Then, and this is the crucial step, change the block size to max 512 by adding the “-B” option with the value “512″. What seemed to be happening in my installation is that the client requested a block size of 8192, the server approved it, and things just stopped working. Probably something to do with the switches I have, but crimping it to 512 fixed the problem. Of course, if you’re doing netbooting on a regular basis, or run diskless workstations, 512 may be intolerably slow, so then it could be worth experimenting with higher values.

I ended up with a plist file for tftp-hpa looking like this:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd" >
<plist version='1.0'>
<dict>
<key>Label</key><string>org.macports.tftpd</string>
<key>ProgramArguments</key>
<array>
        <string>/opt/local/bin/daemondo</string>
        <string>--label=tftpd</string>
        <string>--start-cmd</string>
        <string>/opt/local/sbin/tftpd</string>
        <string>-B</string>
        <string>512</string>
        <string>-L</string>
        <string>/private/tftpboot/</string>
        <string>;</string>
        <string>--pid=exec</string>
</array>
<key>Debug</key><false/>
<key>Disabled</key><true/>
<key>OnDemand</key><false/>
</dict>
</plist>

After modifying the file, stop and restart tftp-hpa by:

sudo launchctl unload /Library/LaunchDaemons/org.macports.tftpd.plist
sudo launchctl load -F /Library/LaunchDaemons/org.macports.tftpd.plist

It’s entirely possible I never needed to switch tftp servers from the default to tftp-hpa, but now I did, I don’t know if I’ve got the courage to switch back to try the original. Checking the man pages for the original tftpd server, I can find no setting for max block-size, so maybe tftp-hpa is necessary after all, just to be able to crimp the blocks enough.

First, open System Preferences…:

Then, select “Accounts”:

Once in the accounts panel, you’ll see your accounts to the left. Chances are you’ll only have one, while I have a bunch on this system. The one you have will probably have the subtitle “Admin”:

You’ll see a checkbox to the right that says “Allow user to administer this computer”, but you can’t unselect this unless there is at least one other account that is set to “administer this computer”, so we need to create another account with that ability first.

So, click the “+” down to the left, and what you’ll see then is this:

See to it that the dropbox at the top says “Administrator”, then fill in the rest as you wish. You can use the same password for this account as for your regular account, but see to it that it is a strong password (long and complex). I see no reason why you should necessarily choose another password here. It could look like this, when you’re done:

Click “Create Account” and this is what you should see in the “Accounts” pane:

Now you can select your original account and deselect “Allow user to administer this computer”:

You’ll probably be asked to reboot at this point, at least if you were logged in as “Noobie Json” as in this example (which I wasn’t). Once you start up again, log in as “Noobie Json” or whatever your account is called, not as “NoobieAdmin”. You should probably never log in as “NoobieAdmin”, ever.

From now on, whenever you need to do something that requires admin level rights, the system will ask you to provide an admin username and password in a dialogbox. For example, if I try to delete an application from “Applications”, the system pops up a dialog box and I have to provide the “NoobieAdmin” credentials:

Now, this never happens without me knowing exactly why it happened, so don’t ever go input your admin credentials unless you know why you should. If you have any doubt, click on the “Details” and it will tell you a little bit more:

In this particular case, “Details” didn’t tell me much I didn’t already know, but when in doubt, in may often tell you exactly what you want to know. If some malware is requesting admin credentials, the app that issued the request will be clearly shown.

If you’re really paranoid, click the double arrow to the right and you’ll see the entire folder hierarchy leading to the app that requested the credentials. Just in case some malware called itself “Finder” for instance. In this case we’ll see that “Finder” is part of “Core Services” which in turn is in the System/Library. Totally kosher, in other words:

OSX very rarely asks for admin rights, so there is very little risk of you getting into a habit of just entering your credentials without thinking. Yes, the first day you use your new Mac, you will do this a number of times until it is all set up, but after that, it becomes a rarity.

I’m guessing the mono libraries are simply put in too early in paths, which may cause the problem, but since I’ve got actual work to do, I’ll just roll my eyes and get on with life.

Update: the above did solve most of my problems, but not all. After perusing more forums than I’d like to peruse, I hit on a remark from one of the Macport developers that you should always reinstall the entire Macport system after every major OSX upgrade. In other words, I installed my Macport under Leopard, then upgraded to Snow Leopard, so it got unhinged. The solution is to entirely remove the /opt/local directory contents, then reinstall Macport from source. Personally, I find it a little bit scary (like, is Macport really the only system using opt/local?) so I tarballed the directory first, just in case. But I don’t think that is necessary, but time will tell.

Anyway, after reinstalling Macport this way, the rest seems to have straightened itself out.

To my everlasting regret I got me a Canon Lide 60 scanner a couple of years ago. Canon’s hardware is pretty nice, but their driver support stinks, especially for OSX. This scanner costs me on average much more work than it should to keep going. Same for my Pixma 5200 Canon printer, by the way. Awful.

Anyway, I needed to scan a page from a mag to show on a slide. Hooked up the scanner, tried Canon Toolbox, and sure enough “Failed to open driver”. Internet next, user groups, downloads, complicated shit about uninstalling, reinstalling, rebooting the Mac Pro ten times. No joy. After a few hours (!) of this, I got an inspiration: hey, since I saw “Twain” mentioned, maybe Acrobat Pro 9 (CS4) could import it, instead of using Canon Toolbox? Sure enough, Acrobat found the scanner, looked it over, and promptly crashed.

And then I got my second inspiration: check out OSX Preview. And yes, that one worked. Not only that, but it automatically calibrated the scanner, proceeded to analyze the page, divided it into sections, scanned it, and served it up already partitioned into useful chunks. See the screenshots below. All the time I was just sitting there watching, doing nothing. The only thing I had to do was select the image and hit cmd-R twice to turn it the right way up.

Jeez, that innocent looking little Preview app is becoming mighty useful for any number of things.

I probably should mention that the driver I installed came in a file called “lide60osx11131en.dmg” to be found, somehow, on Canon’s support site. It installs both the drivers and the toolbox, but the toolbox doesn’t work.

• I’ve got almost ten different email accounts
• I subscribe to tens of mailing lists
• I want mailing lists to be automatically moved to dedicated folders
• I want the same folder setup on different machines
• I want messages read on one machine to be marked read on all the others
• I used three different Macs to read mail on
• I want to be able to get at both inboxes and discussion list folders even through webmail
• I want all mail to be available offline as well
• I don’t want to depend on my web host to not lose my saved mail
• My regular inbox should only contain stuff I need to act on, everything else is either deleted or moved to a single (or possibly a few) archive folder
• That archive folder must automatically be available and updated on all my machines and webmail client
• Oh, I almost forgot: everything should be available on the iPhone as well, of course

Hey, that’s not too much to ask, is it? But until now, there was always something screwing it up. Now I think I’ve got it beat. Since I didn’t find all that much on the ‘net about this, but I did find little scraps here and there, I figured I ought to collect my notes here for posterity. Everything that follows was done on Snow Leopard, both client and server side.

Step 1 – Make it all IMAP

First things first. Change all your accounts in OSX Mail to IMAP. There’s no way to do this with POP3 access. I’m not going to describe how to do this, since it’s not rocket science and no secret tricks are involved. Take care so you don’t lose messages, though. (Not that I know why you should, but I felt I didn’t want to take responsibility if you found a way to screw up the only storage you had of those priceless emails.)

Step 2 – Get yourself an OSX Server

Not as bad as you might imagine. The Apple Mini OSX Server is pretty cheap. Set it up as safe as possible, using mirrored drives. If you have a NAS with RAID, you could set up iSCSI to that. I’m not going into this here either, it’s a separate subject, but I will assume you have an OSX Server at least. Most of what I’m telling you below can also be done on a webhost, but I didn’t want to have maybe gigabytes of mail storage entrusted to some cheapo webhost out there. But you decide, of course.

Step 3 – Enable webmail on your OSX Server

Since OSX Mail doesn’t seem to allow folder management under IMAP, that is, there is no way I can see that allows you to add new IMAP folders server-side, you need to do that using webmail. You only need it when adding or removing folders, not a daily thing.

Assuming you have your user account on your OSX Server, that your DNS is set up right and that you can access your email account on the OSX server over IMAP, you now have to enable webmail on that server. That isn’t in the most obvious place, so I took a screenshot to help you find it (click image for full size):

You have to check the “Mail” checkbox. Actually, I didn’t do that here, I selected the “default” on port 443 (upper pane) and checked it there, so that webmail is only available over HTTPS, not plain HTTP:

Step 4 – Create your folders

Via a browser, log in to your webmail account on the OSX Server. It does come with SquirrelMail already installed and running (if you did step 3 at least). Once in SquirrelMail, click the “Folders” link and you get the following screen:

The first field lets you create a folder. Leave the “as a subfolder of” set to “INBOX”, that’s a pretty good choice. It may not seem all that intuitive, but the OSX Mail client will not show these contents as part of the regular collection “Inbox” even though it’s a subfolder, so leave it set that way. As you create subfolders, you see them in the left listbox down below.

When you return to the main screen in SquirrelMail and refresh the folders (click “check mail”), you’ll see this:

…which doesn’t seem right. It looks as if your new folders are children under “Sent Messages”, but that’s just an interface bug in SquirrelMail. Don’t worry about it.

Step 5 – Back to OSX Mail

Just quit OSX Mail and restart it, it’ll find the new folders. Now, if it doesn’t, check the IMAP Path Prefix field, which you can find if you go to preferences, accounts, select the account, then go to the “Advanced” tab:

If it says “INBOX” in that field, just empty it and try saving, quitting and restarting OSX Mail. I’m not sure if it should or should not have the “INBOX” set there, but try either way if you have a problem.

Step 6 – Rules

Now comes the fun part. You can set up mail rules in the OSX Mail client that move messages into one of the new subfolders you created, even though the original mail came in on another mail account. Think about this for a while until it sinks in. The rules let you move messages from one IMAP server to another, not just between folders on the same server or you client machine.

So, I’ve got mail rules that sorts mail coming in on several different IMAP accounts. As they match different rules, these messages are effectively moved from the original IMAP server somewhere in the USA to my own IMAP server in the backroom, and all those sorted messages are now available in real time from all my Macs and my iPhone (and iPad once I have one). I do have public IPs, so my OSX server is available to me from anywhere, which helps, of course.

You can still easily see where the messages originated, since the “To:” field does not change when you move the messages. If you open a message in the common archive and click “Reply”, OSX Mail client will automatically select to reply from the account the message was originally sent to, not from the account that your archive is in. Exactly as I’d want it to.

Oh, wait, there’s more

I can easily add another IMAP account that is shared with coworkers, and move or copy messages there, manually or automatically, say for support or some mailinglist I want to share with them all. Think about that for a sec.

It becomes even neater if you have MobileMe and you have set mail accounts and mail rules to synch across your machines. I don’t even need to set up the rules as they change. I change them on any one of the machines, and the other machines update the rules. I may, occasionally, have to enable the rules (I don’t know why), but their content is updated.

This is so cool.

Update: You can actually create the IMAP folders just as easily from inside OSX Mail. Just go to the right IMAP account in the side panel, then click the “+” down on the left, select “New Mailbox” and if you scroll far enough, you’ll find your IMAP accounts if one is not already selected. Select one of those and you can create a folder on the IMAP server. It was too obvious for me, I guess.

The theories as to the reason why are, generally speaking: f*ck Adobe, preserve performance on the iPhone and iPad, and/or make multiprocessing efficient on these devices. With regard to that last, the theory goes that the OS figures out how the app works and hooks into the app and the app framework, but if there’s a compatibility layer in between, that becomes very difficult and inefficient. Actually, purely technically, without any fanboyisms, it does make sense to me.

In that case, and reading the 3.3.1 literally, nothing stops me, or Adobe, from implementing a translation from our own specific languages using a precompiler, as long as you end up compiling actual Objective-C code using XCode into the app. That’s what I would do, and I find it a better solution, anyway.

But the anti-Adobe conspiration theorists may claim Apple doesn’t want you to do this, either. I don’t know if they do, but let’s assume.

Now it gets interesting. There is no way that Apple can detect from the runtime code, or even the source code, that the code has been produced by a precompiler, if that precompiler does a decent job. If they want to stop that from happening, they’ll have to monitor the user’s machine for precompilers and editing tools, like World of Warcraft is monitoring for bots. What a fascinating circus that would be.

http://carlton.oriley.net/blog/?p=20

The link to the download is:

http://carlton.oriley.net/blog/wp-content/uploads/2009/12/GPGMail-1.2.1.mailbundle.zip

And it works! Go get it.

First of all, subversion server is already a part of the OSX Snow Leopard distribution, so there is no need to go get it anywhere. Mine seems to be version 1.6.5, according to svnadmin. Out of the box, however, apache is not enabled to connect to subversion, so that needs to be fixed.

We’ll start by editing the httpd.conf for apache to load the SVN module. You’ll find the file at:

/etc/apache2/httpd.conf

Uncomment the line:

#LoadModule dav_svn_module libexec/apache2/mod_dav_svn.so

Somewhere close to the end of the file, add the following line:

Include "/private/etc/apache2/extra/httpd-svn.conf"

Now we need to create that httpd-svn.conf file. If you don’t have the “extra” dir, make it, then open the empty file and add in:

<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /private/etc/apache2/extra/svn-auth-file
  Require valid-user
</Location>

Save and exit. Then create the password file and add the first password by:

sudo htpasswd -c svn-auth-file username

…where “username” is your username, of course. You’ll be prompted for the desired password. You can add more passwords with the same command, while dropping the -c switch.

Time to create svn folders and repository. Create /usr/local/svn. Then create your first repository by:

svnadmin create firstrep

Since apache is going to access this, the owner should be apache. Do that:

sudo chown -R www firstrep

Through Server Admin, stop and restart Web service. Check if no errors appear. Then use your fav SVN client to check if things work. Normally, you’d be able to adress your subversion repository using:

http://yourserver/svn/firstrep

Finally, don’t forget to use your SVN client to create two folders in the repository, namely “trunk” and “tags”. Your project should end up under “trunk”.

Once up and running, this repository works perfectly with Panic’s Coda, which is totally able to completely source code control an entire website. If you don’t know Coda, it’s a website editor of the text editor kind, not much fancy graphic tools, but it does help with stylesheets and stuff. It’s for the hands-on developer, you could say.

The way you manage a site in Coda is that you have a local copy of your site, typically a load of PHP files, which are version controlled against the subversion repository, then you upload the files to the production server. Coda keeps track of both the repository server and the production server for each site. The one feature that is missing is a simple way of having staged servers, that is uploading to a test server, and only once in a while copy it all up to the production server. But that can be considered a bit outside of the primary task of the Coda editor, of course.

You could say that if your site isn’t mission critical, but more of the 200 visitors a month kind, you can work directly against the production server, especially since rolling back and undoing changes is pretty slick using the Coda/subversion combo. But it does require good discipline, good nerves, and a site you don’t really, truly need for your livelihood. You can break it pretty bad and jumble up your versions, I expect. Plus, don’t forget, the database structure and contents aren’t any part of your version control if you don’t take special steps to accomplish that.

Coda doesn’t let you access all the functionality of subversion. As far as I can determine, it doesn’t have provisions for tag and branch, for instance. But it does have comparisons, rollbacks and most of the rest. The easiest way to do tagging would be through the command line. Or possibly by using a GUI SVN client, there are several for OSX. I’m just in the process of testing the SynchroSVN client. Looks pretty capable, but not all that cheap.

I’ll probably brag about this system some more once I get to know it better. But meanwhile, it’s the nicest computer purchasing experience I’ve ever had. Except for the Mac Pro. And the MacBook. And the iMac, of course. And the iPhone. And Apple TV.