Xcode's Crooked Path

Oblivious of legacy? Obstinacy for its own sake?

Get It Try It

Once upon a time there was a research lab in Murray Hill New Jersey. And brilliant open minds used to congregate there, play in sandboxes, and come up with great new ideas. One of the great ideas they came up with was a new operating system.

They had all these grandiose ideas for a new operating system but hadn't had the gumption to make anything out of it. Someone made them change their mind.

And somewhere inside that kernel of an idea was another idea - the idea that everything should have its proper place and that there was always a good reason for keeping things in their proper place.

Other people across the same country on the opposite coast played with a paraplegic programming language invented by a Swiss professor for classroom use only - but now they were trying to put the language into production and things weren't going too well and they didn't seem to understand what was wrong. None of these people on the other coast had any experience with real nontrivial computer systems. Mostly just slipshod circuit boards. They liked to dress in batik shirts and huarache sandals. Surfing USA.

The people back in Murray Hill understood the wisdom of compartmentalisation. And their influence was felt far and wide. Even to the California town of Redwood City.

But you can't keep a beach bum down forever. Given traditional customer demographics, it's only a matter of time until all the new great ideas get absorbed into all the new rip-off bland ideas and progress again slows to a snail pace.



NeXT's Project Builder was a miracle of engineering. Good thinkers on a par with the ones in Murray Hill. Brilliant and above all simple and therefore extremely powerful.

Those of you out there who are computer science teachers? Ever seen the pupil who loves to run GUI debuggers but can't complete a two-line program to save his life?

It's all really about common sense and making things easier for oneself and one's colleagues. But some will never get it.

Early Unix had two major repositories of executables: /bin and /usr/bin. /bin was always on the first mount. The boot mount. It had to be there: to boot the box. /usr/bin was on the second mount along with all the user accounts. All users had their own protected directories. What a concept, hey guys?

Users - great acronyms like bwk, dmr, and ken - then had their own directories for their own programs meant for them and no one else. Great compartmentalisation.

NeXT did much of the same thing but in a Unix GUI kind of way. There was /System for files pertaining to the operating system. They were organised in a subdirectory called Library. And Library went on to grow like that plant in Little Shop of Horrors that threatens to eat Rick Moranis.

Non-system files that were germane to the local system in its entirety were organised under /. They could be in /Applications or /Applications/Utilities or /Library or wherever: the most important thing was they were not located inside user areas so all users could get at them.

Conversely, it was very important not to duplicate files - especially the read-only kind that are shared and never modified - all over the place, as this would impact deleteriously on available secondary storage.

[Yes the language is getting more difficult. Deliberately so. The idea is to get rid of stragglers who don't belong. Ed.]

But today with flash drives and daddy's wallet thicker than ever - who cares?

And now here comes Xcode 4.3.3.

Not everything in OS X is ready for Xcode 4.3.3, if ever it should be. For starting with Xcode 4.3.3, developer files are no longer in the traditional developer locations.

Users can always create ~/Developer if they want, but /Developer is gone. Today all the Xcode files are in /Applications where ordinary users can find them and go 'oh gee hey what's that'. Because we still remember these are multi-user systems, right?

Of course we do.

Xcode 4.3.3 comes with 96695 documentation files.

These are read-only files that are never modified. They're documentation files. Users don't modify documentation files. Some systems may have more than 96695; most systems won't have fewer. 96695 files.

Sizing up that monstrosity was child's play on 10.6. But because this is a later version and because Apple programmers are so bewilderingly great at both design and coding, it might or might not work. In a millennium or two.

Even dragging 4,000 files at time - something that was instantaneous on 10.6 or earlier - is a royal pain on later versions. So suffice it to say it's a shit load of megabloats.

And all this crapola - useful but still - gets loaded into a user area? So each and every individual user on the same computer has to install the same 96695 files again?

That's what the wise will in future years call (with a knowing smirk) 'Macintosh programming'.

But it's easy to remedy. As evidenced by the first screenshots above. Simply move the subdirectories to /Library/Developer and then create symlinks with the same names to the new locations.

And then pray for an influx of gurus from IBM who know how to kick butt.

[A rough estimate of the bulk of Xcode's documentation: 2,028,570,219 bytes in 4,325,360 blocks of 512 bytes each or 2,214,584,320 bytes effective disk storage. To be multiplied by the number of user accounts using Xcode. Disk space is cheap today but shouldn't you choose how it's to be cheapened? Ed.]

See Also
Learning Curve: Yours Mine & Ours
Learning Curve: Yours Mine & Ours II