Jeffrey P Shell: Mac OS X

Moving Toulouse

Sat, 11 Jan 2003 19:24:27 GMT

Industrie Toulouse has moved to A new home (toulouse.amber.org) and a new publishing system. Most of the archives will be there soon. The Radio site will remain up indefintely, but no new content will appear here.

Some quick Safari Tips and Links

Thu, 09 Jan 2003 19:41:15 GMT

I'm generally liking Apple's new Safari web browser. I think it will actually open up some interesting competition in the "Mac OS X" browser world, at least between Safari and the Mac OS X native Gecko browser, Chimera. There's already been a lot of talk about Safari, these are just a couple of links and downloads that have stuck out for me:

Dave Hyatt's Surfin Safari weblog. Dave is the lead developer of WebCore, the rendering side of Safari. He's responding quickly to a lot of criticism and is already noting significant process in newer builds.
Speaking of newer builds, this slashdot journal details how to get at Apple's open source WebCore frameworks and replace Safari's rendering engine with newer builds.
Mike Pinkerton responds from a Chimera developer view.
Safari Enhancer is a tiny utility application that enables some hidden features of the Sarari beta, namely a handly little Debug menu.

I see some people posting huge lists of all of the other things that Safari should do. Stuff that. I say keep it small, lean, simple, usable. Now, if Apple really wants to improve my web browsing experience, they'd come up with a way for me to sync my Bookmarks up over iSync/.Mac! I was reading some of the links above this morning before coming in, along with some Zope 3 posts that I just wanted to remember when I came in to work. I was all set to bookmark them, but then realized that I wouldn't have the bookmarks when I came into the office. Urgh. This is happening all too much lately.

State of the desktop?

Tue, 10 Dec 2002 08:21:18 GMT

The theme of today's conference was decentralization....
The theme of today's conference was decentralization. The first time the term appeared in DaveNet was in the first piece of 2001. That's another DaveNet tradition, like the Thanksgiving essays. I try to make the first essay of each year somehow express the most important idea of the year-ahead. It's always a guess. Some years I nailed it, desktop websites were the big idea of 2001, as we prepared Radio 8 for the market (it shipped in January 2002). And Werbach was right to pick it as the theme for the future in software-based technology. There's so much power on the desktops, both in the machine CPU and the human CPU, that isn't being well used in the centralized Internet architecture. [Scripting News]

Pfeh to the desktops. There's a lot of power in them, but I'm positive I'm not the only one using three machines throughout the day. There's nothing worse than realizing that the data you need is held hostage at home or at work - wherever you're not. There are plenty of times when I don't mind the separation - work's work, home's home. But there are certainly things that go in between. I've been a fairly happy subscriber to Apple's .mac services, using my iDisk to ferry a few common documents and preferences (standardizing the subscriptions on all my instances of NetNewsWire Lite, Chimera bookmarks, etc). I'm using Apple's iSync Beta to keep two desktops, a laptop, and an iPod all synced up with the same address book and calendar data (I have a palm too, but I seldom use it any more). Microsoft's "Active Desktop" vision wasn't entirely wrong. The implementation wasn't quite right, and definitely premature. But the lines between the desktop, the local network, and the global network, are fading away. Rendezvous makes local networking absolutely unbelievable in Mac OS X (well, it's believable to those who used the old AppleTalk, but it's remarkable in the internet age). I don't know. The desktop web site idea isn't too bad (I'm using Radio right now), but I'll always prefer the "Zope" "Everything is done through the web" model. It's the comfort of knowing that fixes, updates, etc, can happen from anywhere, with pretty damn good security.

Docks and Dashboards

Mon, 02 Dec 2002 22:19:59 GMT

For as long as it's been possible, I've had my "Mac OS X" dock placed on the right side of the screen, pinned to the top (instead of the default middle). I even had Mac OS 8/9 doing this for as long as the Applications Menu could be torn off and manipulated to look like a dock. It's the NeXTStep place to put it. Generally, I like the Dock, and how it combines application launching and running application management into a single widget (as well as offering shortcuts to documents and access to minimized windows). It's especially nice in comparison to the plethora of taskbar/launchbar/dock options found in Windows (although Windows XP does take some nice steps to clean up cluttered taskbars) and the stuffed-full-of-applet bars often found in Gnome and KDE. Those bars all have their purposes and uses, but I prefer simplicity and the Mac OS X dock gives it generously. An especially nice feature (when it's actually used) is that applications can have their own Dock Menus. Certain applications take good advantage of it, others ignore it completely. Radio 8 uses it well, offering quick access to the page I'm currently using to write this post, as well as to some other quick actions. Apple's iTunes uses it well, offering quick access to track controls (next/previous/play/pause) and the title and artist of the current playing track. And Brent Simmons' excellent NetNewsWire Lite makes the dock a very useful headline scanner (see screenshot). Having access like this a click away in the Dock is very useful - I often run up the dock with my Mouse checking info from certain applications while keeping them in the background. So, Applications that use the Dock Menu well make me happy.

Some applications, however, do not use it at all, but they should! Apple's new (young) iCal calendering application doesn't use it at all, but wouldn't it be handy if it displayed events and todo items for the current day (or week or month, based on configuration)? Similarly, Mac OS X's built in chat program, iChat forgoes a dock menu in favor of a global menubar item. There's some good reason for this - you can be signed in on iChat without the program running - but it's annoying when doing my little dock information crawl to have to go somewhere else for timely information. My instincts (rightly) take me to the dock first, menu bar second, and as such I'd like to change my status and check my buddy list from the Dock where I generally do so many other little tasks (like pausing iTunes when stepping out of the office). So, where do dashboards fit into this? It's interesting to see the progress in Microsoft's MSN 8 offering. MSN 8 has a dashboard which you can attach to one side (left or right) of the screen and configure with parts updated with information from various MSN Sources. Paul Thurrot gives a detailed review (with screen shots). Some interesting things are the flyout windows, like this one based on the MSN Calendar component. It shows current appointments with shortcuts to add new ones. This dashboard concept is a major part of Longhorn, the code name for the next major revision of Windows. The point of all this is rapid access to constantly changing information. Generally, I like the concept. But, looking at the size of the dashboards for MSN 8 and Longhorn makes me like Mac OS X's dock all the more. All of the items on it are still normal items on the system, not specialized objects (the Docklings that existed briefly in Mac OS X's life were a bad idea, and I'm glad to see them gone). Notification of change is done on the icon itself (Apple's Mail and iChat programs, along with AOL for Mac OS X and NetNewsWire, add a number to their icon indicating the number of newly received items), and allows the dock to remain small and out of the way. The Dock - quick launcher, control strip, task switcher, window holder, information center, easily usable with 32x32 icons. Nice.

Thoughts on Interface Cruft, pt. 3: Documents vs. Applications

Tue, 12 Nov 2002 01:32:47 GMT

One response to the "When Interfaces Go Crufty" article is this one by John Gruber. Some of Johns responses are in the same area as mine, so I'll quote liberally. First, Matthew Thomas writes:

We have the power, in today[base ']s computers, to pick a sensible name for a document, and to save it to a person[base ']s desktop as soon as she begins typing, just like a piece of paper in real life. We also have the ability to save changes to that document every couple of minutes (or, perhaps, every paragraph) without any user intervention.

And Mr. Gruber responds (after mentioning dislike for automatic behavior in applications):

Even if you don[base ']t default to the actual desktop, there[base ']s no other default folder location that would be suitable for all new files. I don[base ']t save my Perl scripts to the same folder as my grocery list. Nor do I want applications choosing file names for me. If you don[base ']t choose the names for your own files, how do you identify them when you try to reopen them later on?

Since reading Mr. Thomas's article, I've examined my own behavior and application usage more closely. And I'm somewhere in the middle of the two viewpoints. And it's not just because I'm a developer and have Python classes that I definitely want to keep separate from my Quicken files, but because there really is room for both.

Applications like personal information managers (at least, Palm Desktop, Microsoft Entourage, and Apple's iCal and Address Book) and personal finance managers like Quicken are all auto-saving applications. In the case of the above mentioned PIM's, one rarely deals with the actual data files. iCal, Address Book, and Entrourage all keep their data off in their own hidden database. You can export data, but you never really open your "Entourage Calendar" - you open the application. Even Quicken (at least on the Mac configurations I've used over the past few years) is this way. I know where my Quicken file is located, but I always launch Quicken itself, and all of my data shows up. Granted, these are all essentially single-document applications (you're always working with the same data set) and curiously enough, tie in to handhelds very directly. And in almost all handhelds, from the Newton to the Palm (and I assume Pocket PC), there's no manual "Save" action for the majority of data managed in them - you turn them on and just start scribbling/typing.
As I've said before, OpenDoc offered an interesting solution. For most OpenDoc documents, you started from the file system by opening a piece of "stationary". It's similar to the starting templates in Office and AppleWorks, but at the file system / operating environment level. Opening a stationary document would fire up an OpenDoc shell and place you in an editor for the default document part, and at first save, you'd have to enter a name/place for the document. Windows has the "New" (or is it 'Create'?) file/contextual menu in the Explorer from which you can make not only new folders, but at least some pieces of content. So you could go to "proposals", bring up the "New -> WP Document" (shrug) menu item, and be given a new empty file for a particular application. You name it, open it, and go. I don't use Windows often, so I haven't really seen how well this menu item is suported by third party applications. But it is a nice idea.
But, when it comes to big documents and applications, I like the current way of doing things. One reason is that since subscribing to .Mac and using its iDisk, I share some documents (namely a rather large OmniOutliner document) between work and home and sometimes in between. Auto saving would be bad due to iDisk's speed (which is not horrible, but it's definitely not fast like local drives). Another reason, as Mr. Gruber points out, is that life is often full of temporary scratch documents. And there are so many different documents for different purposes that it just doesn't make sense for some situations or fields.

The reason for so much variety could, however, be due to interface cruft. We're running on heavy old operating systems with shiny new interfaces (and sometimes ugly new interfaces). The handhelds, particularly the Newton, had a chance to be actually new, and to approach how the operating system and applications performed in a very different way than the desktop operating systems. On the Newton, you just entered in data in the Notebook and then - optionally - filed it into Folders. You could also route the data (mail/print/fax/beam), or combine it with other Newton applications (entering "dinner with Kate" and clicking "Assist" would make the Newton go "oh! Shedule! Tonight, 8:30, Dinner" and find entries in the address book that match "Kate". Contrast this with a five step "Create New Calendar Entry" wizard. But again - this is generally in the PIM category of data. It's a curious breed of data. I'm not sure I want to get involved in the "there should be no 'Quit' command". There are so many applications of varying sizes and purposes out there that I doubt it will go away any time soon. The big case-in-points are the professional applications, from the Office type of applications to the Adobe and Macromedia product families, which are often very large applications, and also the Pro Tools / Final Cut Pro type applications. These applications offer a lot of functionality and people tend to stay in them longer. Adobe GoLive 6.0.x is a very large application, and when I'm using it, I keep it open even if I have no open documents at the moment, just to make it easier to switch to. I'd be very frustrated if I closed a particular window and it caused the whole application to unload itself. In the case of Quicken, there are so many windows that open up and use for control, which one would be the reigning "close this and the whole thing goes" window? On the other hand, there are the utility applications. Apple's iCal and Address Book both go away when you close the main window. Other smaller apps do the same. This effect is probably completely unnoticed on Windows since the global X app killer button is so ubiquitous, and multi-document apps and single document ones are harder to distinguish. I'll (probably) wrap up my random thoughts in the next post in this series, in which I plan to talk about some applications and developers on Mac OS X that are leading the way away from cruft, and a look at where the major desktop operating systems are (finally) headed.

Thoughts on Interface Cruft, pt. 2: Application Organization

Mon, 11 Nov 2002 16:01:56 GMT

Continuing my thoughts on Interface Cruft (sparked by this paper by Matthew Thomas), this is a quick post about one of the things that "Mac OS X" gets right (or at least - more right than others ";->"). "Mac OS X" is more of a system of compromises than it is a new operating system, due to the challenges of integrating the Unix and Mac OS environments, and due to compromises the NeXT team took to try to make NeXTStep friendly to certain environments (by building on Unix) while putting a nice Object Oriented shell on top of it. The most interesting piece that has been used from NeXTStep 1.0 up to Mac OS X 10.2 is the use of Packages on the file system. These are objects on the file system that appear as a single item to the higher level operating environment, while they are actually file system directories that are full of smaller objects. The most common examples of this are applications. In Mac OS X's finder, bring up a contextual menu on an Application (especially well written Cocoa applications like OmniOutliner or NetNewsWire Lite) and select "Show Package Contents". A new Finder window will show up, most likely with a single folder titled "Contents". Inside there will be executables (with the ability to hold executables for multiple platforms) and resources (icons, Interface Builder documents) at the very least. But the package can also contain Help Files, PlugIns (which can be managed via the "Show Info" command in the Finder), other frameworks, scripts, and even other applications (OmniOutliner has "OmniGroupCrashCatcher", an application for reporting crashes to the Omni Group). Essentially, it's a way of doing what the traditional Mac OS did with its resource fork in a manner that's friendlier to traditional file system expectations. It can also be viewed as a way of Object Encapsulation. There's one very clear advantage: since most Mac OS X applications are self contained, they can be freely moved around, shared, whatever. I can use iChat to send a friend a copy of NetNewsWire Lite by just going to the Applications folder, and dragging and dropping the application into the iChat window. Contrast this with Windows, the Linux desktop environments, and the classic Mac OS. The last time I downloaded Mozilla for Mac OS 9, the folder that Mozilla unstuffed to was filled with folders and odd little Mozilla support items, and the Mozilla application was just another icon in the middle of the mess. On Mac OS X, all of that is contained within the executable Mozilla package. If you open up the package contents of Chimera and drill down to the "Contents/MacOS" folder, you'll see all of the Chrome, Components, and Plugins folders. But instead of cluttering up the Finder, it's all contained cleanly within the Chimera package. This also means that you can (optionally) put the local Applications folder onto the Dock, and have rapid access to all applications, similar to the Applications sub-menu off of the Windows Start Menu. Unlike the Windows start menu, which is essentially the old Program Manager from Windows 3.x, the items in the Applications Menu are the real deal, not some pointer to an executable buried in the messy Program Files directory. This also means that - with a few exceptions - removing an Application is simply a drag to the trash. The few exceptions are applications that are installed which also extend the system (things like iSync, or even iTunes which comes with device drivers). Writing about the Windows start menu, Matthew Thomas writes:

And naturally, rearranging items in this menu is a little bit less obvious than moving around the programs themselves. So, in Windows 98 and later, Microsoft lets you drag and drop items in the menu itself — thereby again breaking the general guideline about being able to cancel a click action by dragging away from it. This Programs menu is the ultimate in cruft. It is an entire system for categorizing programs, on top of a Windows filesystem hierarchy which theoretically exists for exactly the same purpose. Gnome and KDE, on top of a Unix filesystem hierarchy which is even more obtuse than that of Windows, naturally copy this cruft with great enthusiasm.

So, while "Mac OS X" has made a lot of compromises in order to be friendly with long-running expectations of a user interface, and to be friendly with Unix expectations of file system layout, it does do a lot of things right. There are plenty of sore spots (including interface irregularities between different Apple produced iApps), but there is a pleasant clean feeling to it all. Generally, there are few alarms and few surprises. As "Mac OS X" continues to grow, I imagine that the situation will improve. And, for all of its cruft, the future of Windows has some interesting developments as well. My next post on this subject will deal with some individual applications on Mac OS X that are taking the right steps away from interface cruft.

Microsoft Share Source CLI release supports Mac OS X

Sat, 09 Nov 2002 20:20:07 GMT

An interesting development on the .NET front - Microsoft's Common Language Interpreter (CLI) can be compiled and run on Windows XP (naturally) and also on FreeBSD and "Mac OS X", which essentially brings C# to Mac OS X.

Thoughts on Interface Cruft, pt. 1.

Fri, 08 Nov 2002 06:23:38 GMT

Matthew Thomas writes an interesting post titled "When good interfaces go crufty". It's an interesting read and he raises a lot of good points: why we have to manually save (still!); the reasons for the "Quit" command in programs, etc. That latter one was one of the things that Compound Document Systems like OpenDoc were supposed to save us from. When you opened an OpenDoc document, there was no "File" menu (it was replaced by "Document", at least when using Apple's OpenDoc Framework (ODF)), and there was no "Quit" command. When you wanted to start a new document, you were supposed to find the right stationary to start from. Stationary, in Mac OS terms, represents documents that upon opening are pre-populated, but are flagged as a New Document, so that the first time you did hit "Save" you'd have to choose a new name. The Office Suites (both big ones like Office and small ones like AppleWorks / MS Works) do similar on their startup screens. OpenDoc was significant because it put such functionality basically at the Operating Environment level instead of the Application Level. Unfortunately, OpenDoc was killed before there was really enough computing power to make it work - it was painfully slow on the Macs that existed at the time. And, even though the paradigm should have been common to people who used the office suites (big and small), it was still really awkward to shift away from the application-centric paradigm. "And the world has suffered for our silence..." Windows has been interesting. From the whole "New >" contextual menu item that showed up in Windows 95 where you could create new text, picture, etc, documents to the more recent usage of multitasking to spawn separate instances of Applications for each document that still feel like a single multi-document interface (Internet Explorer on Windows has been like this for a while, Office has gone this way). But MDI on Windows can be just...weird, due to what Windows marks off as an application. It could be that I'm just used to the Mac. But, doing some Zope development on Windows lately, it was hard to figure out when TextPad would spawn a new application instance, and when it would open a text file in the main TextPad window. So, on the Mac side, how are things in this area? I don't think that the application -> quit paradigm is going to go away anytime soon, partially because of Cruft. But things are changing. For one thing, due to Mac OS X's memory management, it's not that big of a deal to keep an application running even with no documents open. And many such Applications respond intelligently to the dock - when you click the Finder, IE, Terminal or other apps that are already running with no documents open, you'll get a new window (this behavior is often configurable). It varies between applications, but most of the time the apps do the right thing. When my cable modem was installed and my home iMac was still running Mac OS 9, I watched the serviceman click the running IE icon numerous times, obviously expecting a browser window to pop into view. I'm cutting off this post here. It's late, I'm fresh home from the bar, but I hope to post more on this soon. It's a topic that interests me. It's interesting contrasting Microsoft's Tablet PC with the designs of the venerable Newton. I think that the Newton was one of the more interesting Operating Systems in recent memory, while Tablet PC is kindof like Mac OS X 10.2 with Ink recognition - basically Windows XP with...handwriting recognition... Nothing dramatically new. But there are interesting designs that are going deeper into the heart of Apple's and Microsoft's offerings that could be indications of where things are going. And again - I'll have to promise to try to get back to this topic very soon.

Project and Thought Management and Collaboration

Fri, 11 Oct 2002 15:40:28 GMT

Glancing through MacCentral, I came across iStorm - a LAN based document collaboration tool for "Mac OS X". For $20 two people can collaborate, chat, share, etc. Site licenses for more concurrent users are also available. iStorm uses Rendezvous for easy document sharing on a LAN, and includes chat functionality for brainstorming / arguing over document sharing. An upcoming version includes a blackboard with integrated TeX editing for scientific document collaboration (or for some of us to just use the pretty little symbols). It looks really cool. I would like to throw this up as a shell around OmniOutliner documents, but I'll take what they give me now. I'm also checking out TinderBox, but it would take collaborative editing to convince me to move outside the small, fast, comfortable world of OmniOutliner.

On .Mac, part 1.3 - availability wrap up

Tue, 08 Oct 2002 08:53:01 GMT

Without going into too much details, tonight after mad birthday celebrations (where I spent too much time being tired drunk instead of too-much-dancing drunk), I came home to an email from Apple concerning the .Mac outages. Their claim, which I believe, is that there have been equipment problems. They claim the vendor has not been able to promise no more problems in the future, and work is underway to install new equipment. Hopefully this works out well for them and for us subscribers, and it's nice to be notified. In the past, when the service was free, I didn't mind outages and interruptions, but as web services get integrated more and more into desktop applications and environments, service availability is going to be a critical issue. Hopefully having paying subscribers will offset the high cost of service availability. Large scale web services like .Mac, whatever Microsoft .NET My Services morphs into, and other large offerings require more than just a single web server sitting in California. Backup, caching, and location issues abound for service providers. Even Userland's "Radio" servers have had problems in the past (but have run smoothly now for months). Other services, like LiveJournal have also had availability issues, and in fact LiveJournal is closed to free accounts that don't come in off of a referral. There are some other weblogs about Web Service Strategies that have better details than I can offer about the aspects of web services beyond SOAP, REST, or however the basic protocal is spelled for you.

On .Mac, part 1.2 - more availability issues

Mon, 07 Oct 2002 16:54:36 GMT

There are still occasional, but very annoying, outages and/or hiccups in Apple's .Mac system. I hope it's just a side effect of the millions of semi-idle accounts that are set to expire in a week or two. Now that I and many others are paying for the service, I expect better continuity of service - especially now that I use many of the offerings. From Backup to iSync, email to iDisk, .Mac is becoming a significant piece of my Macintosh experience. Hiccups affect that experience negatively. This is one of the most important aspects of the interconnected web services based world - if a piece of the chain goes down, the ripple effect can be significant. Since many of the .Mac services are in a transition phase from the simpler free iTools offerings to the new for-pay integrated .Mac offerings, some hiccups are understandable. But the issues - whatever they may be - better be solved soon. I still have to promise that part 2, about the web applications on .Mac, is coming soon.

On .Mac, part 1.1 - extended services, availability

Mon, 30 Sep 2002 05:02:29 GMT

As a followup to "On .Mac, part 1 - Services", my hopes and wishes for iSync to be released and offer a unique service over .Mac came true - somewhat. iSync is in public beta form, and for some reason or another, much of the .Mac network went down for approximately three hours last night. Myself, and a number of other users, found ourselves locked out of registering machines with our .Mac accounts. Apple fixed the problem earlier today, and registration seemed to go well. Now I have the task in front of me to actually unify my Address Books and core calendars down to the unified and synchronized unit I've been craving.

On .Mac, part 1 - Services

Sat, 28 Sep 2002 18:19:12 GMT

The story's been going around about Apple extending .Mac memberships. To recap what .Mac is, it's Apple's new umbrella name for their internet services, in some ways reminiscent of .NET Services. It's also a rebranded entirely-for-cost version of Apple's previous iTools services. This for-cost issue has caused a lot of contention in the online Macintosh community as this feature that was supposed to be "free for life" is now $50-$100 per year. But, as the so-called dot-com era has show us, "Free For Life" often means "free for the lifetime of the provider, which is often very short indeed". The other free disk space services were often slow, had difficult to use web interfaces, and ultimately - they're gone. Aside from Hotmail and Yahoo's free mail services, most of the other major ones are gone - although to my surprise, my Excite account is still alive, but the email account was (unsurprisingly) wiped out. And even Hotmail's for-free feature set keeps shrinking - and with good cause. It's a huge strain to provide service and uptime for these services, a fact that no one appreciates when things are running well but everyone will raise a ruckus about when services go down. If you take the current list of Apple's iTools accounts and multiply it by the basic size of services offered under the old free banner (20Mb iDisk space, 5Mb Email storage), the resulting amount of disk space involved is immense. Many of these accounts are hardly ever used - until I paid for my .Mac account, I seldom used the iDisk. Many people admit to having multiple accounts for varying reasons too. The reasons include forgotten passwords (so they just created a new account), running multiple sites, or just setting up an account quickly for assorted other reasons and then discarding the account. But on Apple's side, whether any of these accounts are commonly used or not, they're expected to be available instantly. A friend of mine who previously worked at a company that did messaging services for large corporations told me about their system - they had boxes and systems that theoretically could house thousands and thousands of accounts on a single machine. But the company's biggest selling point was uptime guaruntee, and these boxes needed to be restored from a backup in less than an hour. This was impossible to do if you maxed out a machine's potential - a restore could take 22 hours. So, hard limits (500 accounts) and high prices were put on these services because of the work involved in the service availability guaruntee. So Apple has many of the same issues to deal with, I'm sure. If the Backup software Apple offers to its .Mac users stores its files to iDisk, my iDisk data had better be there when I need it! And of course, I always expect my mac.com email to be available (and over the years since iTools started, there have been downtimes, but nothing major and nothing recent). So, a couple of weeks ago, I payed for my subscription. Partially, it was to keep the email address (which I don't use too much any more, except for some mailing lists), but it was also because I was interested in what .Mac (and similarly, whatever Microsoft's .NET services turn out to be, which may be MSN 8) means to the continued integration of the internet and web into more common pieces of our computing life beyond the browser. Apple has done a good (and arguably sneaky) job of integrating .Mac into "Mac OS X":

It's very easy to mount your iDisk in the Finder, and since switching iDisk's protocol from AppleTalk to WebDAV (I believe), the connection stays up forever (AppleTalk would time out, and I don't know how well it survived a 'sleep' operation). Speed is pretty good.
It's very easy to same to the iDisk from any application. And not just to the iDisk itself, but directly into its top level folders. This can be done without even expanding the navigation browser of any save-file dialog.
The integration with the iApps, particularly iPhoto and iCal are nice. Neither app requires a .Mac membership to work, but using .Mac offers some nice conviences for sharing photos and calendars. And iPhoto, like Windows XP, offers nice integration with other web services for ordering prints and photo books directly from the application.
If the conspiracy theory I'm sticking with about why Apple's extended the discount .Mac signup period hold true, then we should be seeing iSync soon. And iSync might offer the most compelling reason yet to use .Mac (I hope and hope and hope it does) - doing palm like synchronization of Calendars and Contacts between Macs, using .Mac as the central repository/transport. How this turns out remains to be seen, but it's my not-so-secret wish for the future.

I expect there to be more services in the future, and since I and many others are now paying for those services - Apple now has a bigger incentive to make sure the services keep humming along. And, since I and many others are now paying for those services, the users have more incentive to actually use them. I've been a fairly happy subscriber thus far, and in the next post I'll talk about the impressive Web Applications Apple has running, and some ruminations about the state and use of different web application servers.

iCal, vCal, .Mac, .NET My Services, etc...

Sat, 21 Sep 2002 19:27:12 GMT

Want A Date? We All Cal With ICal (Thanks to Scripting News for the link) Whats interesting about this (to me) is that Apple went ahead and and said, "lets use a standard format (vCal) for this thing, and just upload it to the server. Lets let each individual machine sort out what to do with the information containted in a calendar." Contrast this with Microsofts .NET MY Web Services initiative, where calendar sharing was to be one of their for pay features. MS was claiming that federation, or the ability to have more than one host for the information, was part of the plan from the beginning. But because they owned the xml structure and were tightly controlling how the whole business worked, no-one on the outside woud have a leg up on how to implement a federated server. (I suppose you could buy the federated server package from MS?) In contrast, Apple went with two established standards (vCal & DAV) and didn't try to own the file format. If there is information that must be shared, the file format should be in the public domain and subjected to peer review. Don't go crazy with that, since you've got to ship sometime and mistakes can be fixed (as long as you always leave one bit in a bit field to mean: more data coming!) Note that vCal isn't XML. It doesn't need to be. XML and vCal are just file formats. [Steve Zellers' Radio Weblog]

vCal is a decent format. I really like the concept of iCal as a subscriber/client of multiple HTTP served calendars. The day iCal was announced, I threw together a 24Tix calendar of upcoming shows as a Python Script - so it's dynamically updated with new shows as they're put in the system. It took a few minutes, basically of reverse engineering an iCal export in vCal format, and then tracking down the vCal spec to see what else I could/should do with the system. As a result, we have this calendar (subscribe), complete with venue information. There's still one missing piece - I still want one personal calendar, even across three machines (workstation, home iMac, iBook). I guess this is where calendar servers come in to play, and maybe it is what .NET My Services could offer. At MWNY, Steve Jobs hinted that the upcoming iSync application could sync multiple Macintoshes over .Mac. Just the notion of this one feature is enough for me to pay for .Mac (which I did do, just a couple of days ago). There's part of me that thinks that the Backup software offered as part of .Mac (or usable separately) could be used to get a cheap version of this now. But I'm a little leary. And I'm a little leary of using Backup because, again, I have three machines. Two of which are in active use. And as I learned during my recent iMac clean re-install, Mac OS X is very easy to restore to if you just preserve some aspects of your home directory (the layered architecture of how Mac OS X handles preferences is a delight compared to the overstuffed system folder of the classic Mac OS). Will Backup let me back up both machines to the same account without trampling on each other? I guess I'll find out sooner or later. So, I still have a dream of being able to easily maintain one calendar, one address book and even one quicken file across multiple machines. I'd love to be able to sync Quicken (even if it just meant "copy the file") to my iBook when traveling (I use Pocket Quicken on my palm, and love it, but sometimes I've wanted to have the full package there (primarily before Pocket Quicken 2.0)) and a couple of OmniOutliner outlines as well. I want to sync up from my iMac while brushing my teeth before heading to the office, and sync down to my G4 Workstation when I get there. And then do the same thing before I leave the office. This is the service that I want - especially if conduits can be made to do it intelligently, like Pocket Quicken - but between Macs instead of a Mac and a Palm. If iSync can deliver on this, than the $50 I shelled out for .Mac will be more than worth it.

hosing the system.

Tue, 10 Sep 2002 17:13:57 GMT

I had severe problems this morning trying to install Chimera 0.5 (a fully native Mozilla based Mac OS X browser) that took many restarts and some terminal trickery to finally abate. I still don't know the extent of the problem, which is likely unrelated to Chimera itself. But - heads up! quick explanation of the problems I saw - when trying to copy the new version of Chimera over the old, the Finder would completely freeze up at the beginning of the "Preparing to copy..." process. When trying to throw version 0.4 in the trash, and then emptying the trash, the same problem occured. Then, the Finder would freeze up after login, leaving the system unusable. Even trying to copy the new Chimera in via the Terminal would freeze things up. And all of these freezes spread rapidly to other parts of the UI level (ie - force quit was unavailable, new applications couldn't be launched, etc). Ugh. Very bad.

Mac OS X 10.2's FTP and WebDAV issues with Zope

Sun, 01 Sep 2002 02:39:15 GMT

[Mac OS X Hints]: Avoid Finder FTP services in 10.2. Sadly, they're right. FTP Services in the Finder are really sub-par, similar to where WebDAV Services were in Mac OS X 10.0. Even if the FTP Services work, I've had issues with file permissions. I was very happy to mount a Zope server via FTP, go into a Python Script object, and open it up very quickly in Apple's simple TextEdit editor. I made some changes, and tried to save, only to get permission warning after permission warning, with no changes saved. So I tried WebDAV editing of Zope objects from the Finder. I was able to open, edit, and save a file, only to go to the "Zope" server's management screens to see that the SQL Method I was trying to edit had turned into a plain File object. Looking at the Undo Log (Zope's default object database keeps historical transactions that can be rolled back), I noticed that the save command had resulted in a page full of WebDAV operations - and that I had not actually saved to the old object in Zope, but that Mac OS X's WebDAV 'File System' support had renamed the old object, put the new one in as a fresh upload, and then removed the original. As such, Zope had no clue what the new incoming data should be, so it simply made a generic File object. Fortunately, I was able to use Zope's undo capabilities to get my original SQL Method back in place, and I went back to the old standby of editing in the TextArea or via XEmacs' FTP support. sigh. Hopefully a nearby update to Mac OS 10.2 will fix the FTP support so that the upper layers of the OS don't freeze up. And it would be especially nice if the file permissions problem went away too.

Industrie Jaguar

Sun, 25 Aug 2002 05:19:44 GMT

So, Jaguar, Jagwire, Jaguar. It's time for the industrie report to join the countless others. Interesting items:

Command-tab now working like Mac OS 9's. A lot of people requested this one - it's similar to Windows cmd-tab switching too. Previously, Mac OS X tabbed through applications in their order in the dock. Now, a single command-tab will switch with the last used application. While this is mostly a good thing, a feature I used a lot has been lost - in Mac OS 10.0 and 10.1, after hitting 'cmd-tab', 'cmd-SHIFT' would cycle backwards. It made cycling easy as there was less of a chord to hold down. Now, the behaviour in Jaguar is like that in Windows - it's 'cmd-shift-tab' to cycle backwards. sigh.
The built in Windows networking is wonderful. Hopefully, I won't have to use this feature much longer, but it's going to be nice during the remainder of one of my projects.
Even better - integrated FTP in the finder!. FTP joins WebDAV as volumes that can be mounted through the Connect to server.... Gnome has offered some similar features (at least with WebDAV and Eazel), but this is something that's been long overdue for OS X, especially with the lack of any decent free FTP client for simple transfers. (There are good FTP/transfer tools out there like RBrowser, an old school NeXT Workspace Manager like app that includes SSH and other transfer modes.)
bash is finally included in the BSD layer, as is Python 2.2 and Ruby 1.6.7. The latter two came as part of the developer tools CD (which is in the box!). It's nice to finally see Python with Mac OS X officially (even though it's 2.2 and not 2.2.1).
Having "Python" 2.2 come along on the free Developer Tools CD is just too cool not to mention again. And ditto for Ruby.
The Terminal application allows the window to be split. A very nice feature.

Some bad things:

None of my Macs are happy to see me. The little smiling bootup Mac that has been with us for so long is gone. Of course, with Mac OS X's usual uptimes and very good sleeping habits, it's not often that we see him any more. But it is surprisingly jarring to just get the graphite Apple at startup. If there was ever a negative feedback campaign to wage, this might be it.
Most of the time, performance on my old home iMac DV SE 400 is improved, even though it can't take advantage of Quartz Extreme. Sadly, there are some things that seem to be worse - namely, getting the folder contents menus in the Dock. The new (and very pretty) 'beach ball' cursor comes up too much. (Urgh, this seems like a memory sleep/wake issue. A few minutes later, and it's running fine)
The Help application launches much quicker, (see my post, "Helping Help"), but can take a VERY long time to load a page initially. I think many of the new help pages either need to be indexed, or actually downloaded from Apple's servers (which may just be beleaguered by many many requests today as everyone's installing and looking at Help). Once running, it's alright. Better than before, but still not as fast as it needs to be.
Getting out of the 'cmd-shift' habit in favor of 'cmd-shift-tab' is kindof annoying. But, I tend to use LaunchBar as much (or more) for task switching anyways. And LaunchBar is still working fine.
Sherlock 3 is a disappointment when compared to Watson. I guess this isn't really a bad thing - the smaller company still has a better product than the big company's imitation. However, I think both Sherlock and Watson (such an interesting pedigree - Sherlock 2 inspired Watson, which inspired Sherlock 3) use the same Movie listing service, which doesn't acknowledge the theatre just a couple of blocks away. For the most part, I think these two tools are cool, but sometimes, services like My Yahoo! are just as useful, or more. shrug

Other nice things in Jaguar:

The new "putting the 'find' back in 'Finder'" feature is more than welcome, although I wish you could save queries. Hmmm, maybe there's an AppleScript I can write. Anyways, it's MUCH faster than Sherlock 2 was in previous Mac OS X versions, and supports criteria to find files by extension (finally, I can find ALL of my OmniOutliner documents!). Now, Apple just needs to integrate Be's BFS file system... ";->".
The UI tweaks in Aqua are simple, but effective. Buttons and tabs aren't quite so beveled anymore. The effect is strongest on the tabs, and it really looks nice in a way that's hard to explain.
The Finder's View Objects settings for Folders has some nice additions, such as the ability to "show item info" (like disk space usage, or how many items are in a folder), resizing of the text, placement of the text underneath the icons or to the right, and more.
When Folders and Get Info boxes open and close in the finder, they scale in and out rapidly, providing a nice Quartz take on a classic Mac OS visual cue.
The Open With contextual menu for documents in the Finder is a godsend, as is the ability to warn about Classic starting up and being given a chance to stop it (in case a picture wants to open up in Photoshop 6.0 when all you want is Preview). This is a long overdue Mac OS feature that some old contextual menu plugins dealt with nicely in the Classic Mac OS days.
Services in the Finder! Now I no longer have to stare at that greyed out Services > Mail > Send File menu option that worked fine in the old NeXTStep/OpenStep/Rhapsody days.
Integrated scanning with Image Capture. I haven't fully tried this out, but the thought of it's made me happy. My scanner is fully supported (with colorsync profile!), so I'm happy.
Improved Energy Manager, on par (or better) than in the classic Mac OS. Finally, I can tell my iBook again to run full throttle (don't sleep, keep the display on for a long time, etc) when plugged in, and to be a bit more conservative when not.

I'm still undecided about iChat and some of the other larger so-called 'features'. I'm using Mail.app at home, and I have to admit I'm already impressed with its Junkmail feature compared to other ones I've used. Mail also has a new feature where it can highlight replies to a certain message, and hopefully a near-future revision will actually support hierarchical threading. There are other interesting things tucked away in the Applications/Utilities folder. The Apple System Profiler has been rewritten, possibly in Cocoa (or the lines between Carbon and Cocoa are getting very nicely blurred). There's an ODBC Administrator, and the very intersting Directory Access utility. NeXTStep was very smart in its use of NetInfo, but the rest of the world has since moved on to LDAP, OpenDirectory, ActiveDirectory, and so on. Jaguar looks like it can integrate with many different directory services in network environments where its necessary. Very cool. The Directory Access application lists directories available to this computer. It also lists available methods of discovering network services. Generally, Jaguar presents a better overall computing experience on top of one that I was already happy with. Mac OS X continues to walk the lines between effective simplicity, common idioms (many of which its predecessor helped to popularize), and being feature rich. There are still some rough spots that I imagine will be smoothed out by 10.2.3. This is an upgrade where the first reaction might be "hmm, this isn't all that much, what's all the fuss?", but it's all the little things. This is really a significant upgrade, and an impressive base platform for Mac OS X's future, just as 10.0 and 10.1 were impressive bases to lead us to this. Bill Bumgarner put it thus: "Digging under the hood is also very interesting -- it is clear that 10.1 laid a foundation that supports a much greater development velocity."

Helping Help

Tue, 20 Aug 2002 07:10:16 GMT

If there is one thing that I desparately think needs improvement in Mac OS X, and is hopefully fixed in 10.2, it would the Help. The current Apple Help application is notoriously slow at launching. Help should be instant. The new Help application looks better from some of the screen shots that have been floating around, I just hope it performs better.

7 free .Mac weeks

Tue, 20 Aug 2002 06:12:45 GMT

It looks like Apple's caught on to what many potential .Mac customers are doing - waiting until the last minute to purchase the discount upgrade price. The reason so many are waiting? .Mac membership is valid for one year from the date purchased. As a result, many would-be upgraders are waiting until the last minute to eke out the most value out of their purchase (and I think that once iSync and other utilities are in place, .Mac will actually be worth its price). So, this evening, I get a notice from Apple that if I convert from a trial account (the status bestowed on all current iTools users) to a paid membership before September 30, 2002 (when the discount upgrade ends), it will be valid until September 30 2003, regardless of purchase date. Alright. Maybe I will have to upgrade now. If Apple's promise of being able to synchronize calendars, contacts, and certain files between multiple Macs holds true, I'll be in heaven. I've got three calendars and three address books running right now (and this is with my iBook off the network). I can't wait to get it all down to one.

New Power Mac system design

Tue, 13 Aug 2002 15:41:44 GMT

Finally, some new motherboard designs from Apple.

Integrating the Mac OS and Unix Environments

Tue, 13 Aug 2002 07:32:21 GMT

This paper is a good read as we near Mac OS X 10.2. Possibly one of the most underappreciated engineering feats has been combining the single-user focused Mac OS and multi-user Unix environments. It's also an interesting reminder of the very different design goals, and the sort of feats and concessions that were made to bring the Mac OS out at a [relatively] affordable level. A couple of paragraphs could probably be used to explain the problems facing the myth of Desktop Linux:

This makes for an interesting system architecture. The ideal result is a system that can be the sort of reliable server platform we use today to host high-volume web sites, file services, network gateways, and engineering computation services while also being the simple to use home computer platform of choice. This is a daunting task, because the server platform goals mandate a certain level of complexity (high security, performance tuning parameters, various network servers, etc.), while for most home users, simplicity overrides other concerns.

Unix and Mac OS have evolved independently of each other, and there are fundamental assumptions made in one system which cause numerous failures in the other. The capabilities of the available file systems, the networking protocols, and the user/system model are profoundly varied, often in ways which cannot be rectified without changing the architecture of system components. Additionally, people use the systems in very different ways and expect different behavior from them.

Other issues such as file system layout, packaging, and so forth are also discussed in the paper.

.Mac doing what .NET still can't?

Fri, 09 Aug 2002 16:22:01 GMT

It's no wonder that Microsoft is having such a tought time with .NET - it lives two lives under the same moniker. The first is familiar to all developers, and that's the .NET Framework and development tools / systems (ASP.NET, ADO.NET, etc). I think Microsoft has done a decent job with this part of the system - so far as I can see. But the other half - the services - is where MS seems to be struggling. And not just Microsoft, it's the whole Web Services camp. Eric Knorr wrote up this article in ZDNet, and Doug Kaye summarized it as "that the easy part of the web-services stack (SOAP, WSDL, UDDI) is nearly complete, but the upper layers (authentication, business processes, security) are in turmoil." But Microsoft most of all is getting slapped around for Passport/Hailstorm/".Net My Services". So, there's something very curious about Apple's revamping of their previously free iTools services into .Mac. Much ballyhoo has been made about the pricing (which really comes down to a little more than $8/month, a little less than $5 a month for current iTools users who upgrade - I do wish Apple actually offered a monthly pricing option though), but there hasn't been much talk about .Mac's more serious aspects. The first of which is - Apple now has their own "universal identification" service, similar to Passport. I don't see Apple trying to open Passport up to a plethora of different web sites as a usable login in the same way Passport is currently being used, but the use of the .Mac account with iChat is an interesting sign. For those not in the know, iChat is a new instant messaging client built in to the upcoming Mac OS 10.2. What makes it interesting is that it uses AOL's AIM network, but unlike other AIM clients, you don't need an AOL account/"screen name" to use the service. Your .Mac login can be used instead (or, if you choose, you can use a normal AOL login with iChat as well). So suddenly, you're using the .Mac identification system to gain access to a different network. Hmmm. And while Apple is not listed as a Liberty Alliance member, AOL is. I would not be surprised to see .Mac's Identification scheme getting accepted into or somehow otherwise used with the Liberty Alliance, who are trying to make a challenger to Passport. But Apple continues to do things in that lovable Apple way - quietly doing what everyone else is doing (yet somehow pulling it off), and then acting like it is their own idea. And when I say pulling it off - they really are. iPhoto integrates web services (it's unknown whether it's SOAP, XML-RPC, or some other mechanism) to allow ordering of Prints and Books online - but without ever leaving iPhoto (or being presented with anything resembling a "web UI"). It communicates with iTools/.Mac to generate web based photo albums, and makes them editable in an understandable way. The upcoming iCal calendering and task list program uses .Mac and/or WebDAV to share and synchronize calendars (finally!). And another upcoming application, iSync, is the bees knees. Apple is touting it as a single way to synchronize the plethora of devices we have, but the secret weapon of iSync which alone makes .Mac membership worth it is the ability to syncronize multiple Macs!. I'm sure I'm not alone in having three Macs in my life - my iMac at home, my G4 tower at work, and my iBook in between. I sync my Palm at home, but frequently need my Address Book and Calendar at work. If I have my iBook with me when traveling, it's much nicer to use than my Palm, but is never up to date with addresses and other items. With iSync over .Mac, I can synchronize my calendars at work to my home machine, and then put them on my Palm. I'll finally have one address book again (alright, two - my current cell phone isn't fancy enough to play with iSync) instead of five. This all sounds vaguely similar to some of what was (vaguely) promised for what used to be called .Net My Services. The big difference - it's going to be installed and working on thousands and thousands of desktops soon.

Fri, 21 Jun 2002 16:09:56 GMT

I'm a little concerned about my Power Mac G4 Workstation (G4/400, 320 MB Ram). It seems much more sluggish than either my iBook (G3/500, 384 MB Ram) or my iMac (G3/400, 256 MB Ram), which are all running Mac OS 10.1.5. Granted, the Workstation tends to have a higher workload than the others. But even at a fresh startup, applications take longer to launch, and Mozilla 1.0 has a harder time keeping up with my typing on the G4 than on the iMac. When all the current projects die down, it's time to find a good defragger and find a good RAM tester. I think one of my DIMM's is seriously mismatched. :/

AppleScript Studio + Zope experiments

Wed, 19 Jun 2002 14:56:23 GMT

Experiment: AppleScript Studio, Zope, XML-RPC. I want to try something. I think I can figure out a way to use AppleScript Studio to write an app to use XML-RPC calls to Zope to display Zope's object tree in an NSOutlineView. It initially seems like it will be pretty trivial, but I have some reading to do. Updates forthcoming... [via hoarfrost: zope, etc.]

Nice. This is something I've meant to do, but never got all that far into AppleScripting the NSOutlineView. I did get this done, which I was pretty impressed with for my first time doing that much AppleScript - I came up with a good looking (and completely frivolous) application that worked within an incredibly short timespan.

Zope and Mac OS X Portal

Tue, 11 Jun 2002 21:35:05 GMT

There's a new Zope on Mac OS X portal, with links to binaries of Zope and some products (MySQL DA, TransactionAgents).