Leopard
My leopard upgrade experience was extremely positive. Thankfully, I didn’t experience any of the difficulties some have had - this account by the veritable Wincent Colaiuta filled me with dread, but thankfully none of his woes were visited upon me. I was cautious about upgrading, and waited a couple of days so that early bugs could be found by early adopters, I’m glad that I did, since I did have APE installed (although by what, I have no idea) and I made sure to run disk utility’s repair function on the install disk before attempting the upgrade.
That said, there are a few observations I’ve made:
Mail 3.0
I decided to do a clean install of Mail, since most of my “archive” mail is still sitting on a machine in Japan, and all messages in the local instance of Mail were kept on the server. I also decided to use this opportunity to switch to IMAP exclusively.
The IMAP imports went well, though took an awfully long time, during which Mail.app refused to quit.
I imported my RSS bookmarks from Safari, since I’d prefer to not be distracted by them during web usage. The import went well, though updates of the feeds seem unreliable and it sometimes takes a couple of restarts to “force” an update. Another unexpected behaviour of RSS in Mail.app is its desire to automatically download all attachments in an RSS feed - leading to quite a surprise as it proceeded to start downloading every single railscast from the entire railscast feed, well over a gig of movies, and refused to quit while in process. I had to force quit mail and delete the Railscast archive to avoid the massive, and slow, download.
MacPorts and custom compiled software
I switched to MacPorts some time ago, reducing the need to custom compile software and, more importantly, eliminating (in theory) the dependency hell that custom compilations can sometimes launch you into. I decided to take the opportunity to nuke /opt and reinstall from scratch - the old repository was, well, old, and I was getting the occasional weird error from the still very much in development macports software.
But now - I have a problem. Apple’s taken the laudable step of upgrading the version of ruby installed with the OS. They’ve got a new build of subversion in there too, and even included rubygems - and Rails! What to do? For example, there are two good ways to install MySQL on this system - port install mysql-server, or download and install the binary. Because I wanted to go with Apple’s pre-install of ruby and rubygems/rails, I thought it maybe better if I installed the binary version. But then gem install mysql, for the native ruby mysql bindings, bombs out. Great, dependencies - exact what I’m trying to avoid, and so early in the customisation process, too!
Anyway, for now I am using the Apple installs, mindful of the possible need in the future to just go ahead and port install duplicates over the top of the bundled software. Furthermore, Ruby 1.9 is supposedly around the corner. What will be the recommended upgrade path then?
I can’t really work out why Apple isn’t going with MacPorts officially here. The project is amateur, but it’s certainly “blessed” by Apple - so why not build it into the OS? There are now 3 ways to go installing a lot of open source software on MacOSX - use the included but rapidly outdating and dependency-locked installs, install manually from source, or use the supposedly official MacPorts package management system. All three leave software in different places. Which one gets used will come down to your $PATH. It’s not exactly elegant, and seems like a recipe for hard-to-troubleshoot problems in the future.
That said, I got everything up and running with no real problems, although postgresql refuses to build in the current Port incarnation.
Interface
A lot of what I think about the interface has already been written in the unbelievably long ArsTechnica review of Leopard, but I’ll save you the 2 hours reading that and list my general thoughts:
- I don’t like the unpredictable, uncustomisable, ugly icons of the new “collection” folders in the dock.
- I don’t like the loss of the “drill down” folder browsing mode
- The new dock wastes space and is gratuitous in its eye candy - eye candy which is, if anything, functionally inferior to the preview incarnation
- I don’t mind the new translucent menubar
Favourite App updates
Safari, Terminal and Mail are hugely improved, and I think this will make most of the positive difference in my daily work with the OS. I like Spaces, too. Spotlight is also much, much better - basically, Spotlight in Leopard is what it should have been all along, which allows me to jettison QuickSilver.
to be continued ..
October 31st, 2007 at 9:19 pm
Don’t forget to mention the loss of the positional slider bar in the preview window in Finder. Now I can no longer skip halfway through a song without actually loading QT, iTunes etc., or, more annoyingly, skip halfway through an episode of something to see if I’ve already seen it or not…
November 2nd, 2007 at 4:49 pm
I pretty much agree with most of your comments.
I’ve also seen problems with Mail.app not noticing that RSS feeds have updated and requiring either a manual refresh (from each feed’s contextual menu) or a restart of the app.
Although I really like Spaces I haven’t yet internalized it in my workflow. In my initial experiments with it I quickly realized that I had to think in an app-centric way rather than a task-specific way. Basically, you need to keep all windows belonging to a particular app in the same space or your application switcher behaviour will be at best counter-intuitive and at worst a nuisance.
And that means that I’ve yet to find a real use for Spaces because my work pattern tends to be task or project-oriented rather than app oriented (eg. a Terminal window showing the source folder of a particular project, the accompanying Xcode windows, perhaps a Finder window showing the build folder etc). When you work this way Spaces doesn’t really help you because you can’t have one project per space. It seems suited only to completely unrelated tasks which use entirely different apps, and in my workflows there are all too few tasks that you can think of in total isolation like that.
Your comments on MacPorts are very interesting, and highlight precisely why I don’t use systems like MacPorts and Fink. At a time like this when Apple rolls out a new release you’re entirely dependent on your upstream maintainers to be on the ball. There a a lot of packages to be updated, and it is inevitable that some things you need won’t be ready yet.
In such cases your only recourse is to hack the portfile to get things working, and if you’re going to engage in manual fiddling then it defeats the purpose of using the package manager anyway. And if you’re going to have a dual-track system in which you rely on the package manager for some things and then install some things manually on top of that, then once again you’ve just lost one of purported benefits of using a package manager (isolation of installed packages from the base system).
I’m of the opinion that all these package managers have the wrong focus. They should be focussing on submitting patches upstream so that projects build on Mac OS X out of the box without any problems. It’s like symptomatic relief rather than treating the underlying cause. Installing anything should be a simple case of:
curl -O http://example.com/foo.tar.bz2
tar xjf foo.tar.bz2
cd foo
./configure && make && make check
sudo make install
And if that doesn’t work then any patching that a system like MacPorts does to get things working is just a band-aid; and I abhor band-aid solutions to this kind of thing.
Dependency hell? If everything is this easy to install then it shouldn’t be a problem. Look at the README and install the prerequisites. And the above really is that easy. The steps should basically be exactly the same for all projects. And if you’re hard-core enough to type fink install foo then you should be able to type the above. The kind of open source software we’re talking about here is exactly the kind that’s used and needed by “command line geeks”; for all the rest there are basically already GUI-level click-to-install packages, or there should be.
November 2nd, 2007 at 5:42 pm
Wincent,
thanks for the comments.
I share your feelings about Spaces. I was very eager to try it out, and indeed enjoyed myself for a time arranging things and switching between them - but I’ve run into the exact same situation you have. I also tend to operate in “tasks” and having virtual desktops doesn’t really help. For example, right now I’m doing a whole lot of CSS editing and so am constantly switching between CSSEdit, Textmate, safari and firefox. I’m finding that it’s not really any gain in productivity putting them all in different spaces - sure, the screen looks cleaner, but switching is, if anything, less intuitive, especially since I don’t cycle them consistently. Sure, I could memorise their “space” positions but what’s the point - we have command-tab already. What would help is a bigger screen, but unfortunately Leopard hasn’t provided me with that! So yeah, I agree with you 100% on that. Nice feature, but I’m struggling to think how it’s useful in my particular situation.
And now to your well-known dislike of package management systems! Man, did a port maintainer poison your dog once or something?
Package management is an obvious and highly useful task that is ideally suited for automation. The point isn’t to save typing configure make install - any idiot can do that! The point is to maintain, automatically, a consistent and up-to-date collection of compiled software in a standardised, easy-to-maintain way.
You comments about focus miss the point somewhat, I feel. Almost all programs I have ever installed on MacOSX did indeed install without any real problems, so I don’t feel like there’s much work to do there.
And your point about relying on upstream maintainers is equally odd. As bottom-level consumers of open source software, we are already completely dependent on the efforts of everyone above us in the chain. All the port maintainers do is maintain a database of current versions, dependencies, and configuration options for Mac systems. Don’t you agree it’s much better for this to be done once, well, for millions of people, rather than every single person having to do it all themselves?
I am surprised you can’t see the benefits. Have you ever tried to install something like ImageMagick? It’s an absolute nightmare of very, very lengthy READMEs, about 10 dependencies which must all be researched, located, downloaded, and installed themselves - some of them, of course, having their own dependencies. Every single one will have to be configured to use your preferred install location - I really like /opt/local, since it’s genuinely local, completely isolated, and can be blown away without consequence at any time.
Anyway, installing the likes of ImageMagick without package management will take you an hour or two of pointless, frustrating work. Updating it? Ha! Who wants to go through all that again?
With a properly working package management system it’s a single command. And then upgrading it, including all dependencies to their proper versions, is another single command. In fact updating everything you’ve installed, all at once, everything, is a single command. It’s a very compelling proposition!
However, yeah. The move to leopard has definitely had some rough edges, and in hindsight I probably should have waited a few days for the bugs to be ironed out before nuking /opt and rebuilding from clean. However, having said that, it’s obvious Leopard has made enough changes to start breaking builds for popular packages - who’s to say the build wouldn’t have been broken anyway, even if you did do it yourself?
I can’t help but think we’re talking about two different things here. You say:
Huh? My Leopard install had 30 or 40 different packages installed. Even in the best-case scenario, imagining dependencies just don’t exist, I would have had to manually look up, wget, configure and install 30 packages! And of course they all have dependencies, almost everything does. And then imagine if something basic needs to be upgraded urgently - say a security hole in OpenSSL! I’d have to go and recompile anything that relied on that! It’s a nightmare to do it manually - you may as well be using precompiled binaries. Package management systems are one of my very favourite things about unix-like systems.
I just did a port list installed, and I’ve got *39* packages on this system already. Almost all of them dependencies for the 5 or 6 “big” things I installed. 39!
Anyway, we’ve been through all this before, and I think we’ll have to agree to disagree.