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:

Dependency hell? If everything is this easy to install then it shouldn’t be a problem.

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.

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.