[Macpartners] Mac OS X 10.4 "Tiger" Update

[Kerem B Limon]

Quoting Albert Willis <awillis at MIT.EDU>:

> 
> On Jul 12, 2005, at 9:52 AM, Stephen Dowdy wrote:
> 
> > I’m sure Jerry Grochow would love to have his budget increased so  
> > that he could provide more services and you wouldn’t have to wait  
> > over 2 months to get full support of Tiger.  Perhaps you should  
> > take your argument to Apple for releasing a OS upgrade that breaks  
> > so many applications.  No one would hesitate to bash Microsoft if  
> > they released an new OS that causes so many problems.

I wanted to write earlier to comment, but chose not to do so in order not to
inflame any side of this argument, but Steve's last comment above about
Microsoft vs. Apple was very astute. Just because their market share is smaller
and they can bully a cult of users into upgrading by artificial hardware
dependencies to disregard some of the problems doesn't mean Apple should get
off the hook as easily.

> Just to shed some light on the situation, most of the problems that  
> are attributed to Tiger are really 3rd-party software vendors that  
> have had developer releases of Tiger since July 2004 and did not have  
> updated products when Tiger shipped on April 29, 2005. Yes, Tiger had  
> a number of problems when it shipped, which it to be expected when a  
> new operating system ships. In the nearly twelve years I've worked  
> here, I have yet to see a bug-free release of an operating system.  
> Compared to some previous operating system releases and technology  
> transitions (NT to Windows 2000, Mac OS X 10.0, Windows 95/98/ME come  
> to mind), this one isn't so bad. However, high profile applications  
> such as SAPgui are affected, so it seems worse than it really is and  
> that it's happened during end of the fiscal year buying and desktop  
> renewal.
> 

No one in their sane mind expects entirely bug-free transitions with our current
level of OS development on any platform. But frankly, those are not fair
comparisons. the 9x/Me to NT-based OS transitions are more like the Classic
System to X transition, where an entire code-base and underlying structure of
the OS was changed from scratch, with binary compatibility/emulation
environments thrown in for transition ease. These were both giant overhauls and
bugs/issues were almost guaranteed to happen. And the NT 4.0 to 2000 transition
was a difference of 5 years in OS techology and a major overhaul that took
several years to bring about. Neither is the case with Panther-to-Tiger, a
single increment point release (and if it isn't, Apple shouldn't call it so)
over at most a couple of years and of the same operating system. And I note
that *none* of the prior examples tied my choice of the OS release to the
hardware I use, at least during a long period of time over which the transition
took place.

A fair comparison would perhaps be the Windows XP SP2 release on top of XP Gold
or XP SP1/SP1a. SP2 also broke a bit of things, but not nearly as much in
perspective, with ample time to test and make the transition over time, and
with no forced hardware dependency. Apple *has* to learn that if it's to grab
any let alone maintain whatever little hold they have on enterprise customers
market (and I'm not convinced this is something they want to do), backwards
compatibility and comprehensive assistance options over a long transition
period made available *at the customers' convenience* are key. Were it not for
its cult following and core competencies in select industries (where they are
very strong), do you think the platform would've survived to this day with
Jobs' vision of rushing us all forward to his preference of what OS we should
all be running (and for which, shelling out)?

> It's also problematic that developers don't follow Apple's  
> guidelines. For example, Apple has said in the past to not to use  
> kernel extensions unless you really really need to, since they could  
> break when the kernel changes, which it does with every operating  
> system update (like going from 10.4.1 to 10.4.2). The other reason to  
> not to create kernel extensions is, because they live in kernel  
> space, they can crash the entire system if they misbehave. Of course,  
> McAfee and Cisco used kernel extensions for Virex and the VPN client  
> and that's the main reason why they  didn't work under Tiger,  
> although they had ample opportunity to discover that prior to Tiger's  
> release. Of course a pre-release operating system is a moving target  
> as well; however, Tiger went golden master about 2-3 weeks prior to  
> it's release, so something could have been done.
> 

It's also not fair to dump this entirely on the developer community, either,
given Apple's market share. Apple's walking a very dangerous line, it seems (to
this unqualified outsider to their developer community), with their developers.
On one hand, their opening up easy-to-use hooks and APIs seems commendable and
the rapid flurry of development since the release of OS X in 2001 is
remarkable. On the other hand, changing the OS drastically with every point
release without backwards compatibility and pulling the rug from under people
isn't quite the way to sustain such a developer community; a commuity, it
seems, besides the big boys and girls, to be composed of many, many
small-to-one-man/woman coder teams that may not have the resources to re-learn
or re-structure their products every time. At the least, it's not friendly, at
worst, it's economically and from a marketing perspective a bad idea.

Apple is not Microsoft, and doesn't have the weight to throw around or large
customer base to rouse and often by itself rise up in protest if a vendor does
things "the wrong way". Regardless of how open and accesible you make your OS
hooks and specifications for development, until you get to that point of
influence, things are not just going to happen right all by themselves. That
means they, as the underdog, have to work harder to make things work properly
until the developer community/vendors catch on, market share rises, and this
becomes a self-fulfilling prophecy. And if Apple cannot get the commercial
vendors (with a stated interest in shipping profit-bearing code that works on
their platform) to fix things in a timely manner on or around transition time,
what does this imply for open source or not-for-profit development? We are now
seeing ripples from the same problem with open source products. OpenAFS for
Tiger still is not out, and Apple (as evidenced by Ernie Prabhakar's comments
when he visited MIT recently) who apparently doesn't consider it a revenue
generating or even viable product won't even consider devoting perhaps a
competent Apple developer to assist with development. So, there you are, with
your new PowerBook, between a rock, a hard place, _and_ your force-upgraded
hardware sitting pretty but dysfunctional.

> Part of the issue is that Apple is pushing the envelope--this is the  
> fifth major release of Mac OS X in 4 years. Every major release has  
> many new features and under-the-hood changes. Actually, Apple has  
> slowed down somewhat--they were shipping a new release every 12  
> months; the schedule is now every 18 months. They've already  
> mentioned that Mac OS X 10.5 "Leopard" will be released at around the  
> same time as Longhorn--late 2006 or early 2007. Being on this  
> schedule makes it tough on some developers to keep up.
> 

Thank God they have. Perhaps it's nice to have your pretty interface and bouncy
icons, but those of us in IT understand well that Longhorn running late (quite,
it seems at this point) a bit isn't quite so bad after all. Do any of use
really enjoy major transitions forced upon us by vendors, anyway? Why can't
those resources be targeted at incremental, smaller but to the point and
specific fixes? (Yes, this is an industry problem.)

> The reason that IS&T invests the time and effort into testing is  
> because we've learned that companies sometimes ship programs that  
> contain bugs and cause problems and would increase the burden on our  
> support resources. We often have to wait for an updated version of an  
> application before we can safely release it. For example, we've been  
> waiting for a version of Virex that we felt comfortable releasing  
> since last summer.
> 
> Finally, IS&T probably needs to develop a process that addresses the  
> different types of users on campus. Self-supporting early adopters  
> and support providers could have earlier access to a new operating  
> system than others than require a higher level of IS&T support. I'm  
> hopeful that's something we will investigate implementing at some point.
> 

Having been in IS&T (and on the Software Release Team, in fact, responsible for
some of the same work), I have to give credence to what Al writes about the
need for testing and the desire to ease the support burden.

A 'phased', early-adopter vs. conservative user with dependencies type release
is a good idea, but that assumes a number of things, not the least of which are
very, very good communication and an ability to resist pressure from
overly-eager customers who may not understand what they're getting into despite
repeated warnings. (A good local IT support team is the other factor, I am
assuming is a given with due respect to all colleagues here who work hard to
maintain their groups well.) With the Institute politics and power structures
being what they are, will you really be able to refuse support or de-prioritize
those users who take the plunge despite your advice to the contrary and create
fires to put out all over, straining your support organization nonetheless? And
that's assuming the communication was solid, loud, and direct such that you
have at least some legal standing to contest your position when that happens.
In this very example of the Tiger release, it has been unclear from the very
beginning whether the hold up on the MIT Tiger release was technical
incompatibilities, delays in acquisition of releases, testing that was
required, or licensing issues/politics; and that's not even breaking
confidences and going into the mixed messages we've been getting from all
over.

> We have more testing to do, but we may be able to give an update on  
> the status of Mac OS X 10.4.2 and related issues next week.
> 
>    -- Al
> 
> 
> ______________________________
> Albert Willis
> Macintosh Platform Coordinator - Software Release Team
> Information Services and Technology
> Massachusetts Institute of Technology
> awillis at mit.edu
> 
> 

My $0.02. Regards,
-Kerem

Kerem B. Limon
kerem.limon at mit.edu /e-mail