Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #68320 > unrolled thread

DNS in Yosemite

Back to article view | Back to comp.sys.mac.system

Contents

  DNS in Yosemite nmassello@yahoo.com (Neill Massello) - 2015-01-12 13:48 -0700
    Re: DNS in Yosemite JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-01-12 15:57 -0500
      Re: DNS in Yosemite Otto Pylot <otto@bogus.address.com> - 2015-01-12 19:39 -0800
        Re: DNS in Yosemite dempson@actrix.gen.nz (David Empson) - 2015-01-13 23:29 +1300
          Re: DNS in Yosemite JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-01-13 11:42 -0500
            Re: DNS in Yosemite dempson@actrix.gen.nz (David Empson) - 2015-01-14 12:02 +1300
              Re: DNS in Yosemite JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-01-13 18:48 -0500
                Re: DNS in Yosemite dempson@actrix.gen.nz (David Empson) - 2015-01-14 16:05 +1300
                  Re: DNS in Yosemite JF Mezei <jfmezei.spamnot@vaxination.ca> - 2015-01-14 10:37 -0500
                  Re: DNS in Yosemite Lewis <g.kreme@gmail.com.dontsendmecopies> - 2015-01-17 02:39 +0000
              Re: DNS in Yosemite Alan Baker <alangbaker@telus.net> - 2015-01-13 18:39 -0800
                Re: DNS in Yosemite dempson@actrix.gen.nz (David Empson) - 2015-01-14 16:05 +1300
                  Re: DNS in Yosemite Alan Baker <alangbaker@telus.net> - 2015-01-13 19:13 -0800
                    Re: DNS in Yosemite dempson@actrix.gen.nz (David Empson) - 2015-01-14 17:16 +1300
          Re: DNS in Yosemite Otto Pylot <otto@bogus.address.com> - 2015-01-13 17:12 -0800

#68320 — DNS in Yosemite

Yet another article concerning the decline of Apple's software quality.

<http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/>

[toc] | [next] | [standalone]

#68321

On 15-01-12 15:48, Neill Massello wrote:
> Yet another article concerning the decline of Apple's software quality.
> 
> <http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-what-you-can-do-to-fix-it/>
> 

Hey ! I am mad. I was just about to post the same :-)

Also deals with the "duplicate machine name" problem that was discussed
here a couple of times.

The Readers Digest version: Apple rewrote mDNSresponder from scratch
into "discoveryd" written in C++ instead of C, so thei is a V1.0 piece
of software, clearly untested.

[toc] | [prev] | [next] | [standalone]

#68330

In article <54b4354c$0$29405$c3e8da3$e074e489@news.astraweb.com>, JF
Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-01-12 15:48, Neill Massello wrote:
> > Yet another article concerning the decline of Apple's software quality.
> > 
> >
> > <http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-and-wh
> > at-you-can-do-to-fix-it/>
> > 
> 
> Hey ! I am mad. I was just about to post the same :-)
> 
> Also deals with the "duplicate machine name" problem that was discussed
> here a couple of times.
> 
> The Readers Digest version: Apple rewrote mDNSresponder from scratch
> into "discoveryd" written in C++ instead of C, so thei is a V1.0 piece
> of software, clearly untested.
> 
> 

So what are us "normal" users to do? I'm not comfortable at all with
using terminal to find and copy the mDNSresponder files from 10.9
to10.10. Not to mention the fear of imploding if there's a problem with
a future update. I have a new MacBook Air coming in a week or so
already configured with Yosemite.

-- 
Deja Moo: I've seen this bullshit before. Please respond to: scasse@invalid.net
replacing invalid with sonic.

[toc] | [prev] | [next] | [standalone]

#68341

Otto Pylot <otto@bogus.address.com> wrote:

> In article <54b4354c$0$29405$c3e8da3$e074e489@news.astraweb.com>, JF
> Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
> > On 15-01-12 15:48, Neill Massello wrote:
> > > Yet another article concerning the decline of Apple's software quality.
> > > 
> > >
> > > <http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-
> > > and-wh at-you-can-do-to-fix-it/>
> > > 
> > 
> > Hey ! I am mad. I was just about to post the same :-)
> > 
> > Also deals with the "duplicate machine name" problem that was discussed
> > here a couple of times.
> > 
> > The Readers Digest version: Apple rewrote mDNSresponder from scratch
> > into "discoveryd" written in C++ instead of C, so thei is a V1.0 piece
> > of software, clearly untested.
> 
> So what are us "normal" users to do?

Wait. According comments on that article, at least some of these issues
have been fixed in 10.10.2, which I hope will be released in the next
couple of weeks.

The suggestion to install an old mDNSResponder to work around the
problems seems risky, since that results in an unsupported system
configuration which may introduce different problems. At a minimum, if
you were to do this, it would be a good idea to restore the normal
configuration before installing any 10.10.2 or later update, or any
security update.

If you don't need to connect in to your computer using the various
remote access features that seem to be problematic (which you probably
don't on a MacBook Air), then that just leaves two potential annoyances:

1. Random failures to resolve DNS names due to the DNS resolver
malfunctioning.

I've been running Yosemite full time for about three months and I'm not
aware of encountering this one. I can't think of any instances among
locals I've helped either.

2. Duplicate machine names resulting in a (2) or higher suffix.

I haven't seen this myself, even though my system meets what appear to
be all the necessary trigger conditions: "Wake for network access" is
enabled, some sharing services are enabled, and I have devices on my
network which can act as Bonjour sleep proxies (an Apple TV and two
Airport base stations).

I am aware of other people on the Internet complaining about this, but I
haven't seen it on any computers running Yosemite for people I'm
supporting.

If it does affect you, an easy workaround is to turn off "Wake for
network access" until Apple releases a Yosemite update which fixes this,
since that will stop the computer from using a Bonjour sleep proxy (if
there is one on the network). The name conflict appears to be caused by
Yosemite seeing the computer's name from the Bonjour sleep proxy as a
duplicate after it wakes from sleep.

> I'm not comfortable at all with using terminal to find and copy the
> mDNSresponder files from 10.9 to 10.10. Not to mention the fear of
> imploding if there's a problem with a future update. I have a new MacBook
> Air coming in a week or so already configured with Yosemite.

Possibly bad timing on that computer purchase. At CES, Intel announced
the next generation of processors suitable for Apple to update the
MacBook Air, which will probably happen in February unless they need to
wait for reasons such as some other component being delayed, software
support to be ready, or to sync with another product release.
-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#68352

re: installing old mDSNresponder.

If you leave the discroverd files in place, and simply disable startup
in the .plist (or the launchdctl method), I suspect upgrades would go
smoothly since the installer will still fine the discoveryd files where
they are supposed to be and update them. If it updates the .plist, then
it is likely it will get started at next boot.

Similalry, since upgrade from older to Yosemite delete the mDSNresponder
files, it would not surprise me that the code would still remain and
still delete them.

Consider this: if I download Yosemite to upgrade from SnowLeopard, Apple
should be giving me the current version of Yosemite, right ? so even
though it may be 10.10.1, it still woudl contain all the logic for full
upgrade from Snow Leopard all the way to 10.0.0 (hence the code to
remove mDNSresponder and put in discoveryd .

[toc] | [prev] | [next] | [standalone]

#68388

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> re: installing old mDSNresponder.
> 
> If you leave the discroverd files in place, and simply disable startup
> in the .plist (or the launchdctl method), I suspect upgrades would go
> smoothly since the installer will still fine the discoveryd files where
> they are supposed to be and update them. If it updates the .plist, then
> it is likely it will get started at next boot.

Then you have two processes trying to open the same ports (one of which
would fail, possibly the wrong one), or potentially have both running at
once, resulting in unexpected behaviour.

> Similalry, since upgrade from older to Yosemite delete the mDSNresponder
> files, it would not surprise me that the code would still remain and
> still delete them.

Wrong assumption. The installer for a new version of OS X is not the
same thing as the installer for a minor version update.

An OS installer creates an entirely new /System folder hierarchy and
then copies selected items out of the old one (e.g. third party kernel
extensions). The old OS's /System is deleted during the cleanup phase.

An OS updater expects /System to contain the standard set of files from
an earlier minor version of the same major version. It patches, replaces
and/or deletes files that have changed between those versions. It
doesn't delete arbitrary unexpected files.

> Consider this: if I download Yosemite to upgrade from SnowLeopard, Apple
> should be giving me the current version of Yosemite, right ? so even
> though it may be 10.10.1, it still woudl contain all the logic for full
> upgrade from Snow Leopard all the way to 10.0.0 (hence the code to
> remove mDNSresponder and put in discoveryd .

That's because in that scenario you are using a full installer for
10.10.1, which is creating a whole new /System folder.

If you had installed 10.10.1, then hacked in mDNSResponder, then used
Software Update or the manual delta or combo update to install 10.10.2,
that 10.10.2 installer will only do what is necessary to change the
system from 10.10.1 to 10.10.2.

The combo updater would also reapply changes between 10.10.0 and 10.10.1
which hadn't been superseded by 10.10.2, but doesn't touch unknown
files, nor any files that are identical between 10.10.0 and 10.10.2.

I expect doing a full reinstall of Yosemite would clear out a hacked-in
mDNSResponder, since a fresh /System folder would be installed.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#68389

On 15-01-13 18:02, David Empson wrote:

> Wrong assumption. The installer for a new version of OS X is not the
> same thing as the installer for a minor version update.

Fair enough. I had not considered that a package may contain two install
scripts, one for full install and one for full update.

So prior to installing an update on a mDNSresponder-enabled system, one
would have to update the launchdctl (or .plist) to disable the
mDNSresponder and re-enable the yosemite discoverd.

[toc] | [prev] | [next] | [standalone]

#68395

JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> On 15-01-13 18:02, David Empson wrote:
> 
> > Wrong assumption. The installer for a new version of OS X is not the
> > same thing as the installer for a minor version update.
> 
> Fair enough. I had not considered that a package may contain two install
> scripts, one for full install and one for full update.

Wrong again. This is different distributions each with their own
installation script, not multiple installation scripts in a single
distribution.

When you get to the x.x.2 and later minor versions, there are at least
three and usually four or more different distributions of each minor
version of OS X:

1. Full installer.
2. Combo update.
3. Delta update.
4. Software Update (sometimes multiple variants).

For 10.6.8 and earlier, the full installer is distributed on DVD or CD
and there is a distinction between model-specific versions (grey backed
DVDs) and general release (retail) versions. The general release
versions were only updated occasionally, e.g. Snow Leopard had 10.6 and
10.6.3 as retail DVDs but nothing later, while versions as late as
10.6.7 are known to exist on model-specific DVDs.

For 10.7 and later, the full installer is distributed via App Store and
has been updated for each minor version. 10.7 and at least 10.7.1 (not
sure about later minor versions) were also available on USB flash drive.
Apple dropped the USB flash drive option for 10.8 and later.

The full installer (4 GB+) always installs the full operating system,
even if the same version is already there. Its script knows how to deal
with merging/moving/updating appropriate files from supported earlier
major OS X versions (back as far as 10.6 for 10.7 through 10.10).

(You can't install an older major OS X version on top of a newer one,
e.g. reinstall Mavericks to a volume containing Yosemite, because the
installer doesn't have rules to do a downgrade and there may be many
other issues such as changed file and database formats which are not
supported by components of the old system.)

The combo update (typically hundreds of MB growing to 1 GB+ for later
minor versions) only updates earlier minor versions. If installed on top
of the same minor version it reinstalls the files that were replaced or
added between 10.x.0 and that minor version (and deletes any files that
were part of any earlier minor version but not the current one).

The delta update (typically hundreds of MB) only updates the immediately
preceding minor version. Sometimes there are model-specific delta
updates for recently released models that haven't yet been merged into
the general release. If installed on top of the same minor version it
reinstalls the files that were replaced or added since the previous
minor version (and deletes any files that were part of the previous
minor version but not the current one).

Software Update (via App Store for 10.8 and later) picks the smallest
compatible update: combo if at least two minor versions out of date,
delta if no smaller update is available, or any model-specific or other
smaller update Apple has chosen to make available, conditional on
matching the specific requirements of that update. Sometimes the smaller
updates patch files rather than replacing them outright.

As long as you hadn't gone fiddling with the files in /System, all of
these should result in the same files. If you have fiddled with /System
then the full installer is the only one that is almost certain to
restore a standard set of files (at least in /System and some other
standard folders), the others may leave the system in an unstable state
due to unexpected changes.

> So prior to installing an update on a mDNSresponder-enabled system, one
> would have to update the launchdctl (or .plist) to disable the
> mDNSresponder and re-enable the yosemite discoverd.

Assuming you had hacked the system by installing mDNSResponder, then
that is the safest option for any subsequent software updates that might
affect system files (particularly minor versions and security updates,
but it is possible that other updates like Safari and iTunes might
affect files in this area).

Also make sure automatic installation of software updates is disabled.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#68413

On 15-01-13 22:05, David Empson wrote:

> Software Update (via App Store for 10.8 and later) picks the smallest
> compatible update:

Fair enough. Had figured it was a single distribution with different
scripts in it.

However, if you leave discoveryd in place but simply disable it via
launchd, wouldn't that allow for proper seamless upgrades no matter the
type of upgrade ?

At the time the files are moved, I have to assume that most processes
were terminated so whether discoveryd was or wasn,t running prior to
that wouldn't make a difference, right ?

[toc] | [prev] | [next] | [standalone]

#68469

Okay, so one time? In band camp? David Empson <dempson@actrix.gen.nz> was all, like:
> For 10.6.8 and earlier, the full installer is distributed on DVD or CD
> and there is a distinction between model-specific versions (grey backed
> DVDs) and general release (retail) versions. The general release
> versions were only updated occasionally, e.g. Snow Leopard had 10.6 and
> 10.6.3 as retail DVDs but nothing later, while versions as late as
> 10.6.7 are known to exist on model-specific DVDs.

Just as an additional data point, a friend of mine was having issues
with his MacBook1,1 and called Apple and they suggested that he update
from 10.5 to 10.6. He said he has a 10.6 DVD, but it wouldn't update his
laptop (it was for his mini, and one of those grey discs). Apple sent
him a DVD with 10.6.3 on it. I don't think they charged him anything for
it either. If they did, he didn't mention it.

10.6.8 gives him access to the Mac App Store and to at least some iCloud
features, and allowed him to update Firefox to the current version. Even
with onyl 2GB of RAM, the machine is a lot better.

Damn, I'd forgotten how slow those old Core Duo machines were.

(I ended up having to install 10.6 for him because of a silly issue with
the installer and a spurious Time Machine folder on his internal drive.)

-- 
http://2blog.kreme.com

[toc] | [prev] | [next] | [standalone]

#68394

On 2015-01-13 23:02:02 +0000, David Empson said:

> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> re: installing old mDSNresponder.
>> 
>> If you leave the discroverd files in place, and simply disable startup
>> in the .plist (or the launchdctl method), I suspect upgrades would go
>> smoothly since the installer will still fine the discoveryd files where
>> they are supposed to be and update them. If it updates the .plist, then
>> it is likely it will get started at next boot.
> 
> Then you have two processes trying to open the same ports (one of which
> would fail, possibly the wrong one), or potentially have both running at
> once, resulting in unexpected behaviour.

If you disabled discoveryd, how would there be two processes exactly?

[toc] | [prev] | [next] | [standalone]

#68396

Alan Baker <alangbaker@telus.net> wrote:

> On 2015-01-13 23:02:02 +0000, David Empson said:
> 
> > JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> > 
> >> re: installing old mDSNresponder.
> >> 
> >> If you leave the discroverd files in place, and simply disable startup
> >> in the .plist (or the launchdctl method), I suspect upgrades would go
> >> smoothly since the installer will still fine the discoveryd files where
> >> they are supposed to be and update them. If it updates the .plist, then
> >> it is likely it will get started at next boot.
> > 
> > Then you have two processes trying to open the same ports (one of which
> > would fail, possibly the wrong one), or potentially have both running at
> > once, resulting in unexpected behaviour.
> 
> If you disabled discoveryd, how would there be two processes exactly?

I was commenting on JF Mezei's hypothetical situation where a subsequent
update replaced the launchd plist for discoveryd, which would almost
certainly result in discoveryd being enabled again (since that is the
normal situation for Yosemite). That would result in a system where both
discoveryd and mDNSResponder are present and enabled.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#68397

On 2015-01-14 03:05:29 +0000, David Empson said:

> Alan Baker <alangbaker@telus.net> wrote:
> 
>> On 2015-01-13 23:02:02 +0000, David Empson said:
>> 
>>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> 
>>>> re: installing old mDSNresponder.
>>>> 
>>>> If you leave the discroverd files in place, and simply disable startup
>>>> in the .plist (or the launchdctl method), I suspect upgrades would go
>>>> smoothly since the installer will still fine the discoveryd files where
>>>> they are supposed to be and update them. If it updates the .plist, then
>>>> it is likely it will get started at next boot.
>>> 
>>> Then you have two processes trying to open the same ports (one of which
>>> would fail, possibly the wrong one), or potentially have both running at
>>> once, resulting in unexpected behaviour.
>> 
>> If you disabled discoveryd, how would there be two processes exactly?
> 
> I was commenting on JF Mezei's hypothetical situation where a subsequent
> update replaced the launchd plist for discoveryd, which would almost
> certainly result in discoveryd being enabled again (since that is the
> normal situation for Yosemite). That would result in a system where both
> discoveryd and mDNSResponder are present and enabled.

Which, if you were savvy enough to make this kind of move in the first 
place, you could deal with by way of a startup script which disabled 
discoveryd on each startup.

[toc] | [prev] | [next] | [standalone]

#68398

Alan Baker <alangbaker@telus.net> wrote:

> On 2015-01-14 03:05:29 +0000, David Empson said:
> 
> > Alan Baker <alangbaker@telus.net> wrote:
> > 
> >> On 2015-01-13 23:02:02 +0000, David Empson said:
> >> 
> >>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> >>> 
> >>>> re: installing old mDSNresponder.
> >>>> 
> >>>> If you leave the discroverd files in place, and simply disable startup
> >>>> in the .plist (or the launchdctl method), I suspect upgrades would go
> >>>> smoothly since the installer will still fine the discoveryd files where
> >>>> they are supposed to be and update them. If it updates the .plist, then
> >>>> it is likely it will get started at next boot.
> >>> 
> >>> Then you have two processes trying to open the same ports (one of which
> >>> would fail, possibly the wrong one), or potentially have both running at
> >>> once, resulting in unexpected behaviour.
> >> 
> >> If you disabled discoveryd, how would there be two processes exactly?
> > 
> > I was commenting on JF Mezei's hypothetical situation where a subsequent
> > update replaced the launchd plist for discoveryd, which would almost
> > certainly result in discoveryd being enabled again (since that is the
> > normal situation for Yosemite). That would result in a system where both
> > discoveryd and mDNSResponder are present and enabled.
> 
> Which, if you were savvy enough to make this kind of move in the first
> place, you could deal with by way of a startup script which disabled 
> discoveryd on each startup.

Which takes us back to Otto's early query about what "normal" users
should do, which is where I got involved in this thread. I wouldn't
expect a "normal" user to go to that much trouble. Manually copying some
files from a Mavericks system to a Yosemite system is hard enough
already.

Hence my advice that "normal" users should not go down this path, and
wait for Apple to fix discoveryd rather than trying to hack in a
solution to a problem which might not even affect them (or be rare
enough to only be a minor irritation).

Savvy users who are inconvenienced by the issues could try the
mDNSResponder trick, with the awareness that it may introduce other
problems, and they need to be very careful around software updates, or
come up with a way to ensure discoveryd doesn't get enabled
automatically after a future update.

If the mDNSResponder trick seems to work, the collective brain trust
isn't observing side effects, and Apple doesn't release a Yosemite
update with discoveryd improvements soon, I wouldn't be surprised to see
a developer come up with an installer package which does the necessary
steps (and includes an uninstaller). That would make it easier for a
wider range of users to apply the workaround safely.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#68393

In article <1ly7648.lsq0i21ds1buxN%dempson@actrix.gen.nz>, David Empson
<dempson@actrix.gen.nz> wrote:

> Otto Pylot <otto@bogus.address.com> wrote:
> 
> > In article <54b4354c$0$29405$c3e8da3$e074e489@news.astraweb.com>, JF
> > Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> > 
> > > On 15-01-12 15:48, Neill Massello wrote:
> > > > Yet another article concerning the decline of Apple's software quality.
> > > > 
> > > >
> > > > <http://arstechnica.com/apple/2015/01/why-dns-in-os-x-10-10-is-broken-
> > > > and-wh at-you-can-do-to-fix-it/>
> > > > 
> > > 
> > > Hey ! I am mad. I was just about to post the same :-)
> > > 
> > > Also deals with the "duplicate machine name" problem that was discussed
> > > here a couple of times.
> > > 
> > > The Readers Digest version: Apple rewrote mDNSresponder from scratch
> > > into "discoveryd" written in C++ instead of C, so thei is a V1.0 piece
> > > of software, clearly untested.
> > 
> > So what are us "normal" users to do?
> 
> Wait. According comments on that article, at least some of these issues
> have been fixed in 10.10.2, which I hope will be released in the next
> couple of weeks.
> 
> The suggestion to install an old mDNSResponder to work around the
> problems seems risky, since that results in an unsupported system
> configuration which may introduce different problems. At a minimum, if
> you were to do this, it would be a good idea to restore the normal
> configuration before installing any 10.10.2 or later update, or any
> security update.
> 
> If you don't need to connect in to your computer using the various
> remote access features that seem to be problematic (which you probably
> don't on a MacBook Air), then that just leaves two potential annoyances:
> 
> 1. Random failures to resolve DNS names due to the DNS resolver
> malfunctioning.
> 
> I've been running Yosemite full time for about three months and I'm not
> aware of encountering this one. I can't think of any instances among
> locals I've helped either.
> 
> 2. Duplicate machine names resulting in a (2) or higher suffix.
> 
> I haven't seen this myself, even though my system meets what appear to
> be all the necessary trigger conditions: "Wake for network access" is
> enabled, some sharing services are enabled, and I have devices on my
> network which can act as Bonjour sleep proxies (an Apple TV and two
> Airport base stations).
> 
> I am aware of other people on the Internet complaining about this, but I
> haven't seen it on any computers running Yosemite for people I'm
> supporting.
> 
> If it does affect you, an easy workaround is to turn off "Wake for
> network access" until Apple releases a Yosemite update which fixes this,
> since that will stop the computer from using a Bonjour sleep proxy (if
> there is one on the network). The name conflict appears to be caused by
> Yosemite seeing the computer's name from the Bonjour sleep proxy as a
> duplicate after it wakes from sleep.
> 
> > I'm not comfortable at all with using terminal to find and copy the
> > mDNSresponder files from 10.9 to 10.10. Not to mention the fear of
> > imploding if there's a problem with a future update. I have a new MacBook
> > Air coming in a week or so already configured with Yosemite.
> 
> Possibly bad timing on that computer purchase. At CES, Intel announced
> the next generation of processors suitable for Apple to update the
> MacBook Air, which will probably happen in February unless they need to
> wait for reasons such as some other component being delayed, software
> support to be ready, or to sync with another product release.

Unfortunately we didn't really have a choice. She needs a computer now
and sharing my current MacBook Air wouldn't work. I'm not a speed
junky, leave multiple apps open, or do any sort of heavy duty
processing so I'm hoping the new 8/128 Air will tie me over for the
next couple of years. I like my mid-2011 now so this will just be a
moderate improvement over what I have and will be newer.

-- 
Deja Moo: I've seen this bullshit before. Please respond to: scasse@invalid.net
replacing invalid with sonic.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.mac.system

csiph-web