Monday, March 4, 2002

John Welch wrote an article about Installers on MAC OS X that details the good and the extremely stupid of the installation experience on OS X. For the most part, I agree with him completely; Installers that kill applications from vendors other than the one that owns the installer in the first place are just plain stupid. I have no problem if Microsoft's or Adobe's installer wants to quit all Microsoft or Adobe apps, respectively, but that they want to kill *everything* running on the system as my user is either due to laziness, lack of understanding or poorly engineered software. Where I differ from John's opinion is regarding Apple's installer and the assumption that various things under /Application or /System/ will be where Apple put them in the first place. I agree that the behavior of Apple's current installer in this situation is just plain stupid; it should tell the user if it doesn't find things in a state that it can usefully deal with. However, a user should never move things that Apple installs. It is that simple. If you want to arrange your apps by category, then create an Applications directory in your home account, create aliases, and arrange it however you bloody well please. That's the whole point; your home account should contain everything that is unique to the way you use the system. Think about it. If you isolate the parts you change from the parts Apple (or certain clueless third party vendors) install, you greatly minimize the maintenance issues of your system. Furthermore, it means that you can move to a new system by just moving one folder (and installing anything that modifies the system itself-- outside of the developer arena and a handful of clueless vendors, this is relatively uncommon). It also means that the system can be a heck of a lot more secure than is otherwise possible. There is no reason that a logged in user should be able to modify the contents of /Applications, /System or, even, /Library (outside of a few group related things). If your system is configured this way (mine is), the only data that is vulnerable to attack by malicious code is the data under your home account. But that's OK-- you back that stuff up on a regular basis, right? The bottom line is this. The operating system on your computer should be treated as a transparent, but sealed, box. Understand as much as you want/can about what is inside that box, but don't touch it unless it cannot be avoided. While this is just a really good idea for an individual using a single machine-- it will save you time in the long run. This approach becomes a requirement for an environment where more than one user is expected to use a single machine or one user is expected to be able to use multiple machines. If you give me an account on your machine, the last thing I want to deal with upon login is some system that has everything moved all over hell and back. I do not think the way you do. I do not organize things the way you do. The organization of the computer you find to be them most effective is just going to piss me off. I expect the reverse to be equally as true. OS X actually does a very good job (not perfect-- but an awesome job for a 1.1 level product) of managing your user environment such that mounted home accounts "just work" across multiple machines. In a properly configured networked environment, you should be able to log into any OS X box on the network and pretty much everything should be exactly where you expect it and should work exactly as expected. More importantly, if the OS X box on your desk melts down, you should be back up and running in the time it takes to stick another freshly built out machine on your desk. (Yes, this really does work. We do exactly this at CodeFab-- as do most universities and a number of companies-- and it greatly reduces the cost of maintenance. As well, it means anyone in the company can log into any machine in the office and expect to be able to get work done effectively. It also means that upgrading someone's box is trivial-- simply drop in a replacement with the new capabilities, take the old one out, rebuild and upgrade as necessary, and it is ready to drop in on someone else's desk.) The same should hold true in the single user, single machine model of computing. I have a Titanium PowerBook. I follow the above model; unless I absolutely can't avoid it, everything is installed into some appropriate spot under my home account. Applications go in /Volumes/Data/Users/bbum/Applications, for example (I have a 48gb drive in the machine; 12 GB partition for the OS and 30+GB partition for my user account). On those occasions where I have had to rebuild the machine over the last year (twice because I had booted into OS 9 and it ate the filesystem, once because a drive exploded, and three or four times because I was upgrading from a prerelease version of the OS or dev tools), it has not been a problem. I simply archive my home account off to CDR, a firewire HD or network mounted filesystem, reformat the hard drive, install the OS, the patches, the dev tools and the handful of packages that modify the system (bad vendor, BAD! though it is kind of unavoidable for drivers right now), copy my home account back and I'm back up and running in the same environment I had before. Hours saved. Very little frustration. Updates just work. Life is good. Go Steve. I still have all the apps categories anyway I want in my ~/Applications directory. Better yet, I can log into any machine on my home network or company network and work with the machine my way without pissing off every other user in the company. I know that a bunch of people out there-- Zarf, for example are going to respond that they should be able to compute their way. Damn right you should! And what I described above is more about computing your way than is the approach of randomly modifying the system. An operating system is a complex beast. Automatically upgrading it over time is hard and requires very tight dependency management. I'm not about to claim that Apple's current software updater is any great achievement though I will say that it has yet to screw up my system whereas Microsoft's updater has blown out the occasional Windows box I have had the misfortune of having to deal with on quite a number of occasions. Computing your way does not mean you should expect that Apple is going to be able to effectively engineer a solution for every possible change you could make to the system. For every time I have had a OS 9 box successfully update itself because it was using references to various files and applications as opposed to hard coded paths, I have had problems because some stupid app or document was still referring to an app or document that was in the trash because I upgraded something. (Radio UserLand-- the app via which this rather length rant was published-- suffers from this problem on a regular basis). The bottom line is that Apple cannot hope to ever be able to predict or handle every single possible change or modification a user has made. They recognize this and, instead, have given you a system that allows you to have a highly customized user environment without having to muck with the system. It ain't perfect and there is a lot left to do, but it is a far cry better than the 'if you look at it funny, it will crash or need a reboot' days of OS 9 (see previous post). Furthermore, I know that I can sit down in front of an iMac at my sister's house, have access to the unix shell, have all my environment variables, have all the apps configured the way I like, have my Dock basically invisible (I use LaunchBar instead), and have everything in a state that she would find nearly unusable, but I find to be highly productive... ...and as soon as I log out and she logs in She can still use her machine. Now, toss in her 16 year old son who is all kinds of into burning CDs and futzing around with graphics stuff. He can arrange the desktop anyway he wants, do whatever he needs, and once he logs out neither my sister nor I have to put up with a bunch of rap mp3s littering our desktop. 9:46:18 PM  pontificate

It appears that system.verbs.builtins.html.getFileURL() breaks if your Radio installation is on a different volume than the system. In particular, it is failing to encode the volume name into the file:/// URLs. 9:47:06 AM  pontificate