Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Hotspots

A Road to Daytona

Start by turning right at N de Anza Blvd.


Get It

Try It

There are those who have voiced unreserved praise for OS X 10.5 Leopard and there are those who incessantly criticise it. The truth has to be somewhere in between. This is an account of what it's like to boot into Leopard - as opposed to Tiger and previous releases of OS X. It's empirical and covers only a limited gamut of experiences and mostly from the POV of the standalone user.

1. Booting up. The gray screens seem to take longer with 10.5.2 than they did with 10.5.0 but boot times are still fast. And that 'appendix' window is finally gone - it was just smoke and mirrors with Tiger anyway. Now today you go straight from the gray screen to the login window.

The login itself seems to go a lot faster and of course this is always good.

Some people complain they don't immediately see their menu bar but this is trivial at best - some people would be happy if they didn't see it at all.

2. Appearance. Leopard windows look better. The new look is distinctive and very ergonomic in a way OS X has not been for some time. The Panther makeover left a lot of people scratching their heads; Tiger was a bit better; but Leopard really takes a giant step and makes things finally look good.

There is a single black line around all windows today. It's subtle but it makes a difference. There's also a single black line between toolbar and content view and it has the same effect. The darker unified toolbar background brings out the colours of the glyphs better.

The menus have curved corners today and the default selection colour is a bit off the beaten track, looking to some like an 'industrial blue'. But for others it works well.

The transparent menu bar has startled some but others say reliance on a 'Mac' menu bar is the real mistake.

Some people don't like the new 'shelf' appearance to the dock but frankly it looks good. It's not going to look fabulous when moved to the side and today you get the 'no glass' appearance when you move it. But where it is things look good.

3. Window shadowing. It's just too much. Preview just an excellent job of capturing screen dumps with the total window shadow intact and reverts to PNG as a default format. But placing these pictures online simply doesn't work. They look unwieldy.

The extra shadow - some would say the obscene shadow - seems to enhance the three dimensional aspect of the screen but with all this work writing new algorithms for shadowing you'd think someone would figure out what to do with congruent windows.

Shadowing isn't additive: if you place two windows on top of one another the shadowing gets darker. Which of course real life shadowing never would do. With all the work implementing such advanced concepts as window/view transparency and shared pixels you'd think someone could address this issue as well. It would be a major hack but it can be done.

4. Quartz. Or wherever the flaw lies: since Tiger there have been serious embarrassing rendering issues with OS X. Things get 'left behind' - things like half a scroll bar, parts of a menu bar belonging to the formerly active application, and so forth. Wherever this error lies it has to be fixed. And it's been bad since 29 April 2005 so it's high time someone started looking into it. Face it: you don't need a bug report for this. A bug report in this context is only a way to 'change the subject' and avoid having to look into the issue properly. There are namely serious things wrong with the rendering code. They need to be fixed. Now.

5. Complexity. Scurrying around inside Leopard one quickly realises the basic system has become more complex by an order of magnitude. This is not good. The answer to issues or perceived projected issues is not to increase complexity but to increase simplicity. This is something Apple never seem to grasp. And ultimately their systems - like MacOS - just start to fall apart.

Unix is an eminently simple system. That's its strength. As Apple take their 'perverted' branch of Unix and go farther and farther away from the original both in design and implementation they risk tripping up over their own feet, something which if they don't get some sense soon is going to be inevitable.

Paths to simple things like temporary directories are getting ridiculous. Look in /var/folders to see what you've got. Temporary subdirectories with names exactly 27 bytes long? Why? Sorry but the world outside is not that dangerous. If you keep on introducing 'features' which jeopardise your security you don't remedy this by the use of further features that only make your system messier - you rethink those original 'features' until you get them right.

6. Document control. It's crazy and indefensible. Today Leopard mutilates your files when you save them. It actually saves your work to a new physical file it's saved somewhere else (in a temporary location) and then 'moves' this file into place. It doesn't actually open your files for writing.

This is so bad words can't possibly express. One can guess there were a lot of support calls from hopeless users who couldn't understand why they couldn't save read-only files. These same users probably wonder why they have to sign in to Yahoo to send and receive mail, why their video rentals don't come up in the same format they saw at the theatre, and why it's such a bad idea to race away from a fast food drive in with a cup of hot coffee squeezed between their thighs. That basic system behaviour - and security - is undermined for the sake of this group is unforgivable.

7. The little things. Of which there are myriad. Who thought through the mnemonic feature of table views and did not see its timer conflicted with that of the double click? Who decided that the keyboard mask used to flag shortcuts isn't to be a mask any longer but an absolute? Efficiency can't be an issue here - someone is just being 'Puritan' - 'you can't have other keys pressed when you want this shortcut'. In terms of system functionality it provides no enhancement whatsoever - just makes itself a royal pain. It might be a simple clerical error; but why isn't it fixed?

This is one of many situations in Leopard where the people responsible for the code are damned if they do and damned if they don't. If these mistakes are mere 'typos' there's no excuse - there was never any reason to go into this code anyway. And if someone's been assigned to trim up the code for the transition to 64-bit then they have to have the perspicacity and the professionalism to leave well enough alone. Yet what's seen time and again with OS X is the exact opposite.

If however all or any of these gaffes are not mere 'typos' but actual design decisions then it's even worse. For this means in such case someone actually purported to have thought through these issues and still came up with such a wacky and unprofessional conclusion.

8. /home & /net. It seems no one yet knows what they're for but a few souls more awake than most notice the system itself trips up over them. Navigating to at least one of them with a trusty tool like Finder can get you a spinning beach ball. The directories seem to cache info for a brief period of time but once that interval's run out you're back to square one again. For what reason no one knows.

9. Development tools. There are snags here. Xcode insists on the right to create a CVS repository in the user home root directory regardless of whether said user is going to use CVS. And if Xcode can't create the directory it just crashes. Put in raw terms: 'it's simply idiotic'.

The Xcode help system is - dependent on Spotlight? Hello? Clue: not everyone thinks Spotlight is great and a few people think it's teh suck. This so much resembles the type of crap Microsoft pull by forcing developers to install their IE cruft. It's a bad idea and it's disrespectful.

Interface Builder looks brilliant but how practical is it? It's got two humungoid inspector panels that take up half the screen. Aware they're painting themselves into a corner on this one the developers made changes to the basic functionality of IB which end up making it harder to use. Not to speak of the cryptic and unhelpful icons that replace clear plain text so you can really see what's going on.

These new formats? And refusing to create objects.nib? What kind of nonsense is that? objects.nib files run fine on all OS X releases. Look at Safari for example. It's still got eighteen (18). They can't be all that bad. And if you don't need the new whiz-bang doodads added on too late they're far more efficient.

Instead of making this eminently available the trend is to go in the other direction. And save - along with keyedobjects.nib - a file called 'designable.nib' which is only used in the development phase (by Interface Builder). Some of these monster files grow to half a megabyte or more - for a keyedobjects.nib file that probably is no more than twenty kilobytes (20 KB). Something's wrong in both the design and implementation here.

And finally: startup times. These two apps today under Leopard are sluggish. They should be faster. After all: the system itself is faster. Again: complexity is the enemy and these applications are getting complex for no reason. Complexity always kills.

10. Executable code. The compiler and linker for Xcode on Leopard are somewhat more efficient than on Tiger. Actually it can't be said exactly why executables are more lean and mean but generally they are. And this is always welcome.

11. Application disasters. It's not fair to lump applications into the operating system itself but in these cases it's about the two 'killer apps' on the web today and in both cases Leopard has egg on its face.

As per usual Safari adds a lot of impressive eye candy but what do you say of a company releasing a product that can be consistently crashed right out of the starting gate? The Safari team have a reputation for going after the big game and ignoring the flaws. Try 'inspect element' in Safari with JavaScript turned off. You can even do this on any empty window. Boom. Crash. Three releases already and still it's not been fixed. This is another situation where they're damned if they do and damned if they don't. But in this case it's about quality control. And the lack of organised disciplined testing. For you just don't release a product that crashes reliably 100% of the time no matter what. You start sacking the people responsible instead.

And Mail. Poor Mail. Up to and including Panther Mail things were basically OK even if some people saw the empire eroding. But starting with Tiger Mail things didn't just go downhill - they fell off a bloody cliff. Overnight the mail program became the single number one best example of program design and coding gone bad. Not just on OS X but anywhere. A disgrace. And remember: this is the #2 killer app even now so the gaffes here are going to be seen by everybody.

And hey! Tiger Mail had it all! People had messages that disappeared! Hey! When you have messages disappearing it's flashing lights and sirens going off telling you there is something very very wrong with what you've done.

In such a case - a scenario no programmer wants to ever get into which is why programmers are taught to make sure they never get close to such a thing - you almost have to rip the whole thing apart and start all over.

Face it: if you have such bugs in the code there is something seriously wrong with the people who wrote it. Bugs that happen reliably are relatively innocuous; bugs that totally screw things up but only occasionally mean you have something very serious indeed going on. And you can't easily find the mistakes in a macro lens - you have to gut the whole thing and start all over.

You can't count the downfall of Apple Mail from 29 April 2005 when Tiger was released - you have to count from a lot earlier when the internal testing programme began. What kind of testers did they have? Not very good obviously. What kind of testing programme did they have? Not very good obviously. And since then they have only added more code to an endemically flawed code base.

You have two alternatives. You can either live with the bugs and get a justly deserved reputation for some of the crappiest software available anywhere or you can bite the bullet and rip the program apart and start all over - and do it fucking right this time, thank you.

The Leopard Mail developers need to bite the bullet but they never will.

  • Drafts folder that only appears on the whim of the program and can make messages inaccessible.
  • Incorrect colour coding and text rendering.
  • Cropping issues are mostly gone but drafts saved as plain text always come back as rich text. Yet if you go to the menu the program tries to tell you it's already plain text. This is a significant boner as it indicates the programmers don't have enough control over what they're doing internally. There should be no way this can ever screw up in any program. But the Mail developers found a way. A first year computer science course way.
  • You have to sometimes tab out of text fields for the program to notice you've edited something.
  • Window frames are saved erratically at best.
  • The program can burp and complain a message can't be sent because there are no recipients when there are in fact recipients. Somebody's not looking in the right places and somebody needs to reconsider their career options.
  • The spinners are just too big. It could be argued the Tiger spinners were too small but this is overcorrecting and it's not tasteful.

12. Code signing. First question many ask: why? Leopard applications are today 'signed'. They're also aware of whether they've been tampered with. But this 'signing' cannot be removed and it can include junk files the user has every right to remove - junk files more intelligent developers wouldn't have left there in the first place.

It also includes services menu entries - more clutter for the services junkyard - as these are located in Info.plist and this file is also part of the code signing. So suddenly you're stuck with that crap on your services menu whether you like it or not (and you don't like it). This is another design gaffe the OS developers can be expected to solve in another ten years.

テヲワロ:
チヰヰレュ ドヮャ
1 ドヮユラヮラヴュ ヌワワヰ
ッヵヰュヲヴラヮワ、 ッチ 95014

ツヲラヶュ:
2、850 ロラ ー メモワヵヴ 1 ヤメヹ 17 ヨワヵヲン
  1. トュメヤ ヮワヲヴヨ ワヮ ドヮユラヮラヴュ ヌワワヰ 33 ユヴ
  2. ピヵヲヮ レュユヴ ヴワ ンヴメヹ ワヮ ドヮユラヮラヴュ ヌワワヰ 413 ユヴ
  3. ピヵヲヮ ヲラョヨヴ メヴ ノ ヤュ チヮヺメ ヂレヶヤ 0。1 ロラ 1 ロラヮ
  4. ピヵヲヮ ヲラョヨヴ ヴワ ロュヲョュ ワヮヴワ ドー280 ビ ヴワヷメヲヤ ビメヮ ナワンュ 7。8 ロラ 9 ロラヮン
  5. ピメルュ ュヸラヴ 3チ ヴワ ロュヲョュ ワヮヴワ ッチー87 ビ 5。0 ロラ 5 ロラヮン
  6. ピメルュ ヴヨュ ュヸラヴ ヴワヷメヲヤ ッチー85 ビ 0。2 ロラ
  7. ピメルュ ュヸラヴ 1チ ワヮ ヴヨュ レュユヴ ヴワ ロュヲョュ ワヮヴワ ッチー85 ビ ヴワヷメヲヤ デラレヲワヹ 5。1 ロラ 5 ロラヮン
  8. ピメルュ ュヸラヴ 1チ ヴワ ロュヲョュ ワヮヴワ フビー101 ビ ヴワヷメヲヤ ヌワン チヮョュレュン 20。8 ロラ 19 ロラヮン
  9. ピメルュ ュヸラヴ 356 ユワヲ 10ヴヨ ビヴクッチー152 ヅ 0。3 ロラ
  10. ピヵヲヮ レュユヴ メヴ ヅ 10ヴヨ ビヴクッチー152クバメャヨュャワ バメンン トヷヹ ッワヮヴラヮヵュ ヴワ ユワレレワヷ ッチー152クバメャヨュャワ バメンン トヷヹ 2。8 ロラ 5 ロラヮン
  11. ピヵヲヮ ヲラョヨヴ ヴワ ンヴメヹ ワヮ ッチー152クバメャヨュャワ バメンン トヷヹ ッワヮヴラヮヵュ ヴワ ユワレレワヷ ッチー152 37。8 ロラ 40 ロラヮン
  12. ネュヲョュ ワヮヴワ ドー5 ビ ヶラメ ヴヨュ ヲメロヰ ヴワ ヌワン チヮョュレュン 242 ロラ 3 ヨワヵヲン 32 ロラヮン
  13. ピメルュ ヴヨュ ュヸラヴ ワヮヴワ ドー210 ヅ ヴワヷメヲヤ バメンメヤュヮメ 44。3 ロラ 43 ロラヮン
  14. ピメルュ ュヸラヴ 45 ヴワ ロュヲョュ ワヮヴワ ッチー57 ビ ヴワヷメヲヤ ビメヮヴメ チヮメ 4。1 ロラ 4 ロラヮン
  15. ピメルュ ヴヨュ ュヸラヴ ワヮヴワ ドー10 ヅ ヴワヷメヲヤ ビメヮ ヂュヲヮメヲヤラヮワ バメンンラヮョ ヴヨヲワヵョヨ チヲラヺワヮメ、 ノュヷ ネュヸラャワ ヅヮヴュヲラヮョ ピュヸメン 1、312 ロラ 18 ヨワヵヲン 3 ロラヮン
  16. ピメルュ ュヸラヴ 556チ ヴワ ロュヲョュ ワヮヴワ ピヘー1604ーヌハハバ ヅ 26。5 ロラ 27 ロラヮン
  17. ピヵヲヮ レュユヴ メヴ ドー10 ヅ 0。1 ロラ 1 ロラヮ
  18. ビレラョヨヴ レュユヴ ヴワ ロュヲョュ ワヮヴワ ドー10 ヅクフビー90 ヅ ッワヮヴラヮヵュ ヴワ ユワレレワヷ ドー10 ヅ ヅヮヴュヲラヮョ ヌワヵランラメヮメ 452 ロラ 6 ヨワヵヲン 50 ロラヮン
  19. ピメルュ ュヸラヴ 159 ワヮ ヴヨュ レュユヴ ヴワ ロュヲョュ ワヮヴワ ドー12 ヅ ヴワヷメヲヤ トメロロワヮヤ 85。7 ロラ 1 ヨワヵヲ 15 ロラヮン
  20. ピメルュ ュヸラヴ 85ッ ヴワ ロュヲョュ ワヮヴワ ドー10 ヅ ヴワヷメヲヤ ヂメヹ ビヴ ヌワヵラン バメンンラヮョ ヴヨヲワヵョヨ ネランンランンラヰヰラ、 チレメモメロメ ヅヮヴュヲラヮョ テレワヲラヤメ 511 ロラ 7 ヨワヵヲン 27 ロラヮン
  21. ピメルュ ヴヨュ ュヸラヴ ワヮヴワ ドー95 ビ ヴワヷメヲヤ ナメヸ ヂュメャヨュンクツメヹヴワヮメ ヂュメャヨ 90。0 ロラ 1 ヨワヵヲ 21 ロラヮン
  22. ピメルュ ュヸラヴ 261チ ヴワ ロュヲョュ ワヮヴワ プ ドヮヴュヲヮメヴラワヮメレ ビヰュュヤヷメヹ ヂレヶヤクフビー92 ヅ ヴワヷメヲヤ ツメヹヴワヮメ ヂュメャヨ 2。2 ロラ 4 ロラヮン

ピワ:
ツメヹヴワヮメ ドヮヴュヲヮメヴラワヮメレ ビヰュュヤヷメヹ
1801 プ ドヮヴュヲヮメヴラワヮメレ ビヰュュヤヷメヹ ヂレヶヤ
ツメヹヴワヮメ ヂュメャヨ、 テヌ 32114

13. Active Directory. People connecting to heterogeneous networks were unable to deploy 10.5 because Active Directory simply didn't work. Period. Where was the quality control? Or is this some kind of twisted conspiracy to get people to stop connecting to Microsoft machines? Even with 10.5.2 it's still not working right. How can you take a product that's ostensibly worked OK up to now - and ruin it? This gaffe affects a lot of admins out there who are literally going to lose money because this isn't working. They can't pass the buck to the Leopard team - they get hammered because the network's not working right. They pay for the nonchalance of the Leopard team. It stinks. Three releases of Leopard and it's still not working right? A lot of people need to find new jobs in the San Francisco area. And that includes people in the HR and management corridors.

14. FrontRow. FrontRow? Yes. It's not working right either. Amazing. It's actually crashing the entire Rock Solid Foundation™. The entire system freezes. Nothing works. Crash and burn and you have to force a hard reboot. Seven hardware interfaces to deal with as opposed to the (tens of) thousands Microsoft have to deal with - talk about a dream situation - and they still can't get it right? What's going to happen over time after the fascination with the iPod and iPhone wear off? Aren't a lot of people going to begin to realise that when it comes to programming these people are still at the bottom of the barrel?

15. Caches. Leopard has caches all over the place. The immediate realisation is this can't have been organised. One team wants caches here; another wants caches there; it's anarchy. For people who don't have a clue it's not an issue - they never see what's going on anyway. But for others who do have a clue it's alarming.

And more and more SQLite is being used for these caches. Which is OK as long as you have a resident SQLite reader. Which you don't have. Representational services sans insight is never a good thing.

Leopard's ~/Library/Caches hive is a mess. You'll find an armada of domain names there for applications that never asked for them; you'll find empty sub-hives no one asked for. You'll also find hives for 'Desktop', 'Mail', and that most loveable of all OS X entities — METADATA.

But you'll also find cruft in /tmp. Weird stuff: directories containing sockets. You'd presume they're important but they're not protected and the user can always delete them without privilege escalation. Things like 'Listeners', 'Render', and the mysterious ':0'. But they can be deleted just like that.

/tmp/launchd has a socket file too but it's protected.

/var/folders/zz is a revelation. The subdirectories have been made difficult to navigate into: they all begin with a dash ('-'). There's an easy workaround of course: simply prepend './' to the names. The question is how anyone could see this as a speed bump and why they'd want a speed bump in the first place. More debilitating complexity.

Remember: there can always appear to be good reasons for doing things but if the end result means more complexity it's simply wrong.

/Library has caches too; it's just too many caches all over the place.

16. METADATA. Leopard is 'metadata gone wild'. The extended attributes API is being abused. Here are a few of the XAs that appear on all sorts of files not only whether you want them or not but whether you need them or not.

  • com.apple.diskimages.recentcksum - just trying to imagine what this is used for makes seasoned developers weak in the knees.
  • com.apple.metadata:kMDItemAttributeChangeDate - apply the above here as well.
  • com.apple.TextEncoding - a true example of 'do we really need this?' And the answer is a categorical 'no'.
  • com.apple.quarantine - placed on everything you download from the web. It disappears as soon as you access things locally. Is this a morbid fear of Oompa Loompa? It's certainly misplaced apprehension.
  • com.apple.XcodeGenerated - anything Xcode creates - even a directory - gets this blob. Why? Hey - it does no good whatsoever.

And then there are the countless SQLite files that litter all over the place in the name of metadata. Who needs them? As one developer once quipped: 'metadata sucks balls'.

17. DTrace. DTrace is very cool. So are a lot of the new things with Leopard. But people aren't going to be able to focus on them as long as they're still distracted and annoyed - and hampered in their work - by all the architectural and coding gaffes present. And as for DTrace: the original authors at Sun Microsystems aren't too pleased. Apple are more and more behaving like a Microsoft subsidiary.

Better to stop there with reaching the company's lucky number. There are good things with Leopard but the system as a whole is not ready for the big time yet. Dave Cutler had a project called 'Daytona' once upon a time. It was the project immediately following the first ever release of NT. He froze the specs and had his Tribe and the hundreds of other core developers go back over the code and improve it and clean it. It's hard to get an ear with management if all you want to do is improve code that's already been released; it's almost impossible to not get an ear if you come with a whiz-bang idea for a new feature.

But operating systems aren't supposed to be about features. A system like Leopard is supposed to be about stability and reliability. From a programmers perspective. And above all it's supposed to be static. What works today is supposed to work tomorrow - not be broken tomorrow.

So many people write in a fury about everything that's changed under the bonnet of Leopard for no apparent reason. It's one thing to change the appearance of a system to give potential clients the idea the system itself has been improved; it's quite another idea to change the inner workings of a system no ordinary users ever see - and thereby breaking application code - for no reason at all save 'change for the sake of change'. And worse still when through increased complexity it makes the system less reliable. That is never good. Period.

Leopard needs to be a platform people can rely on, can build on. It needs to get outside its fortress and become available to companies and developers everywhere. It needs to cross hardware boundaries. Self respecting corporations are never going to put their trust - and their money - in an IT solution that on both the hardware and software sides is bound to the same mysterious erratic company.

A company that today earn more money off iPods and iPhones than they do off computer hardware and software. A company with no major clients to speak of - only the perennial fanboy constituency who parade outside the stores to buy half a dozen licences at most - and perhaps an iPod shuffle and an iPhone. Take away these PDAs and you don't have much. And today this company have got themselves so boxed into a corner they officially are not even making the feeblest attempts at marketing for the government and enterprise sectors anymore. Take away the iPod and the fanboys and they have nothing. Worse still: even if they keep these markets they have no room to expand - they already have all they can get. And it's not much.

To provide a system that attracts companies and developers: you need a solid reliable and above all static fundament. Were companies and developers suddenly able to access these 'technologies' you'd see the Leopard teams going through a baptism of fire. Feedback from users important? They'd be overwhelmed. They'd either learn to do it right or break. Hopefully they wouldn't break.

Above all Leopard needs something like what Dave Cutler did: a 'Daytona'. The system's already into its third release - which means it's about a third of the way through its life cycle - and it's still not good enough for what 10.5.0 should have been. And you can't blame the iPhone. There are no excuses.

Leopard needs something akin to Cutler's 'Daytona'; unfortunately as of today it can't even qualify for a gocart race.

'If the song title is so long it must scroll from left to right to show the whole song name then when the album artwork and info flip from one side to the other (as a song is playing) you start to see some jerkiness. Eventually this causes the image to stop somewhere between the transition from one side to the other and shortly after that the music stops and the machine freezes.'

See Also
Technically Sound: Leopard
Apple Discussions: Front Row Locking Up
Apple Discussions: Front Row Freezes on Songs with Long Titles

This article was composed on OS X Leopard 10.5.2, a platform many would like to see become their preferred platform.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.