Apple Seeds Rumored Golden Master Mac OS X 10.6 (10A432) to Developers

[Simon R.]

This discussion about 64-bit and not 64-bit kernel is confusing me a bit...

I have one of the first Mac Pro's and was very surprised to read that Snow Leopard components won't run 64-bit on that one. That's really arrogant of Apple to do...

However, one of the main reasons I was looking forward to SL was that it would break the 32-bit addressing space limit, so programs like Logic (when fully 64-bit) would be able to address more than 4GB of memory. Is this still the case for me on an "old" Mac Pro or will I not see that benefit?

 

[Evangelion]

Well we do know 1) it's faster even if only slightly

The bottleneck is in the apps, and the apps are 64bit

and 2) it provides greater security.

Again, I think that the key to better security is the apps, not the kernel...

We furthermore paid a premium for our computers which, in some cases, are just over a year old.

So? Are you really missing out on anything?

We furthermore know that the future is moving in that direction (fully operative 64 bit configurations).

Sure. But as things are right now, are you missing out on anything?

Now, if someone, such as yourself can provide good reasons as to why not all capable hardware configurations should be given these extra advantages, please do share.

Maybe there are more complex reasons as to why it isn't supported? Maybe it's an oversight that will be corrected? Maybe it wouldn't offer any benefits on that particular configuration?

) Apple does not desire to write any said driver updates because it wants to try and "entice" people to upgrade to newer hardware sooner than later (i.e. in other words it is stagnating support prematurely).

So, Apple is forcing Mac Pro-owners in to buying new machine because their machine does not support 64bit kernel? And what if it did support 64bit kernel, but the difference between 32bit and 64bit kernels was nonexistant? Would you still be happy because "I have more bits!"?

 

[safasule]

yawn...bring on 128 bit.

Can't wait 'til this discussion becomes relevant

 

[JohnDoe98]

Well, gee, I dunno. Maybe we are paying for OpenCL? Grand Central? Cocoa-finder? Better performance? All those little tweaks everywhere? Or do you think that 64bit kernel is the only new thing in Snow Leopard?

I think the 64bit aspect was the biggest feature and that is pretty much the driving engine behind SL and it's speed improvements (with the exception of OpenCL and GC that I'm coming to now). As for OpenCL, as I'm sure you are aware Leopard supports up to 2.1 and quite a few of the OpenCL 3.x features, though it doesn't give full support. However, Linux and Microsoft offer that 3.x support for free, so I'd expect that too from Apple. As for a Cocoa-finder and those tweaks you talk about, are those "features" that Leopard wasn't capable of handling and thus required a new OS?

Grand Central I'll grant you. It's the one thing, along with the 64bit stuff that makes SL attractive and speedy.

 

[OZMP]

So, if Snow Leopard has 32bit kernel on your machine, what do you think you would be missing, as opposed to having 64bit kernel? Could you provide some tangible examples?



Those computers run 64bit apps just fine. What exactly is the problem?



No.

G5 has been dropped from SL.

With the 1,1 MP and SL and the 32bit kernel, Its a matter of principal and a firmware update. There is nothing I can do, I am just a little dissappointed, wouldn't it be better to have every machine running SL with the 64bit kernel anyway?

 

[swampbits]

64 bits

If you want to find out if your machine is 64-bit capable, run the following command from Terminal:

sysctl hw.cpu64bit_capable

When I run it on my MacBookPro4,1 I get the following output:

hw.cpu64bit_capable: 1

1=yes
0=no

General non-technical discussion of 32-bit vs. 64-bit: Running in 64-bit (whether it's just a 64-bit app running in a 32-bit kernel, or 64-bit kernel with 32-bit apps, or both) will require more memory to do the same functionality. Why? Because all memory addresses (references to other areas of memory) will require 8 bytes (8bits/byte * 8 bytes=64 bits), whereas with 32 bits will require 4 bytes (8bits/byte * 4 bytes=32 bits). Make sense? This simple explanation is avoiding the common hackery on Intel chips with things such as PAE, which is not so simple a discussion.

Depending on the CPU and the mix of instructions, one can be "faster" than the other. In some situations, 32 bit can be faster than 64 bit, and vice-versa.

I would say that unless you have more than 4 GB of memory installed, you shouldn't be too concerned about not running a 64-bit kernel. On the other hand, if you've got a top-of-the-line Mac Pro maxed out with RAM and are running serious workloads, then having a 64-bit kernel would be advantageous.

 

[German]

And what if it did support 64bit kernel, but the difference between 32bit and 64bit kernels was nonexistant? Would you still be happy because "I have more bits!"?

There a big differences:

e.g.

- More Security: NX-Bit - http://en.wikipedia.org/wiki/NX_bit
- More Performance - and not only more registers. There is no more need for that 4/4 Split, that makes XNU (32Bit) a slower.

"But while all other common 32 bit operating
systems like Linux, Windows and the BSDs
split the address space into 2 GB for user and 2
GB for kernel (2/2) or 3 GB for user and 1 GB
for kernel (3/1), the i386/x86_64 version of
XNU uses a 4/4 split: While the kernel is running,
the user's data is not mapped into its address
space, and while user code is running, the
kernel is not mapped. So user and kernel can
each have 4 GB of address space with the disadvantage
of being less efficient in copying of
data between user and kernel. But this way,
kernel mode can map more devices into its address
space (like video cards with a lot of
memory), and manage more RAM, thus pushing
out the limit when a true 64 bit kernel is
required."
http://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf

Also here: http://events.ccc.de/congress/2007/Fahrplan/attachments/1053_inside-macosx-kernel.pdf

 

[cal6n]

Well we do know 1) it's faster even if only slightly and 2) it provides greater security.

In theory, yes but in practical terms, we know nothing of the sort.

We also know many hardware configurations are capable of running it and only require a driver update. We furthermore paid a premium for our computers which, in some cases, are just over a year old. We furthermore know that the future is moving in that direction (fully operative 64 bit configurations).

Shall we wait until we get to that future before we start blubbing? No, let's not.

We also know competing companies offer far superior driver support and provide that support for a longer duration than does Apple...

No we don't. We only have the claims of that company and its shills. Claims that consistently turn out to be rubbish.

Now, if someone, such as yourself can provide good reasons as to why not all capable hardware configurations should be given these extra advantages, please do share.

I probably is a driver issue, seeing as successive iterations seem to include more machines.

But if it is only a driver issue, as it certainly seems to be at this point, what reason can there be other than either of these repugnant alternatives: 1) Apple is too lazy to write new drivers or 2) Apple does not desire to write any said driver updates because it wants to try and "entice" people to upgrade to newer hardware sooner than later (i.e. in other words it is stagnating support prematurely).

Or 3) Oh, I don't know. Let me just make up some rubbish like your examples. How about: all the staff responsible for writing 64 bit drivers are working on bringing all the drivers for the relevant hardware up to date according to a sensible schedule that's only known within Cupertino, just as it should be.

Your whole post basically sums up your petulance and your lack of understanding of the hardware, the software and the engineering realities behind such a huge update as this. But you don't care about any of that. You just want it all and you want it now!

I get so sick of the offensive stench of entitlement that pervades these boards sometimes!

[/RANT]

 

[3dwarehouse]

Wrong

This is the macrumors article from october 12, 2007, 14 days before they released it on october 26, 2007.

Apple had expected to declare their upcoming Mac OS X 10.5 Leopard Gold Master this week. "Gold Master" status is given the final shipping version of the software which is sent to duplicators for distribution.

Based on our sources, Apple had not quite reached that goal, but today released an internal "GM candidate build" which could represent the final version of Mac OS X Leopard, if no other issues are found.

Apple has been working against the clock to get Leopard duplicated and shipped for an October release. October 26th has been noted to be planned ship date, and Apple has already been training support staff in anticipation of its release.

The Build number for the latest GM candidate is said to be 9A581.

 

[MRU]

So ok, I'm being a tad slow to catch up on this one but......

Why wouldn't SL run in 64bit on a MacPro 1,1 ? Other than Apple 'artificially' limiting the system.

If Windows can run in 64bit on a MP 1,1 then surely it's utterly shocking and seriously depressing that Apple's new operating system will not.

This is not about whether end users will notice, but the basic principal of the thing. If Microsoft can release a new operating system that runs in 64bit on my hardware, then it's unacceptable that Apple can not be bothered to do so.

Surely the reason for 'any' leopard users to upgrade to SL is the 64bit OS under the hood. If your not going to get that - is there really any point ????

If you want to find out if your machine is 64-bit capable, run the following command from Terminal:

sysctl hw.cpu64bit_capable

When I run it on my MacBookPro4,1 I get the following output:

hw.cpu64bit_capable: 1

1=yes
0=no

MacPro 1,1

hw.cpu64bit_capable: 1

 

[JohnDoe98]

The bottleneck is in the apps, and the apps are 64bit

That's right and the Apps are programmed to take into account either 32 bit or 64 bit kernels, the latter of which are going to be faster so far as I understand the matter.

Again, I think that the key to better security is the apps, not the kernel...

The key is to both and there have been documented vulnerabilities with the way 32 bit kernels handle the memory allocations. With 64 bit kernels the allocation is fully randomized increasing security dramatically. So even if you want greater security in Apps, it sure isn't a bad idea to increase security in the way those apps function in the computer's memory.

So? Are you really missing out on anything?

Yes optimizations like H.264 Acceleration. Optimized drivers that utilize the hardware's full capacities as found on other operating system platforms + security and speed as just noted.

Sure. But as things are right now, are you missing out on anything?

See above.

Maybe there are more complex reasons as to why it isn't supported? Maybe it's an oversight that will be corrected?

Good, then there is no qualm other than with the delay.

Maybe it wouldn't offer any benefits on that particular configuration?

But it definitely would, as just noted. We're not talking crazy hypothesis but real world scenarios. The Santa Rosa platforms have 64 bit EFIs, 64 bit CPUs and would only need driver support to have 64 Bit chipsets, unlocking providing all the above noted advantages.

So, Apple is forcing Mac Pro-owners in to buying new machine because their machine does not support 64bit kernel?

They are not forcing anything, they are ending adequate support for those machines prematurely.

And what if it did support 64bit kernel, but the difference between 32bit and 64bit kernels was nonexistant? Would you still be happy because "I have more bits!"?

But as per the above the difference is not insignificant. Even if the only advantage was security, which it is not, that would be sufficient in its own right.

 

[rpp3po]

I think the 64bit aspect was the biggest feature and that is pretty much the driving engine behind SL and it's speed improvements

From a developer standpoint 64 bit is more or less irrelevant concerning speed. There are only very few computations, that benefit from it, and especially Finder, Mail, etc. should not benefit at all. Those computations, that can benefit from 64 bit, could already be used without compromise in Leopard. Everything at 64 bit makes it just a bit more comfortable for the programmer.

The one huge feature, that makes Snow Leopard fly is asynchronous control flow, and GC is only part of that equation. An event driven, asynchronous and concurrently operating Finder can really perform much better than the old centralized (single thread) approaches. The all 64-tag is mainly marketing and preparation for >4GB desktop standard times in the future.

So anybody with a machine supporting only the 32 bit kernel in Snow Leopard, calm down. You'll benefit from ALL speed improvements. The C2D doesn't need an all 64 bit environment to execute 64 bit code.

 

[Evangelion]

I think the 64bit aspect was the biggest feature and that is pretty much the driving engine behind SL and it's speed improvements

And the apps are 64bits....

As for a Cocoa-finder and those tweaks you talk about, are those "features" that Leopard wasn't capable of handling and thus required a new OS?

rewriting Finder in Cocoa is a major change and it thus reserved for major upgrade of the OS. And usually new features are reserved for major releases, point releases are for bugfixes.

Besides, SL costs only $29, it's hardly going to break your back-account now is it?

There a big differences:

e.g.

- More Security: NX-Bit - http://en.wikipedia.org/wiki/NX_bit

IIRC, NX-bit is a feature of the CPU, and not feautre of the "bitness" as such. 32bit kernel can support is just fine, at least Linux does:

"The availability of the NX bit on 32-bit x86 kernels, which may run on both 32-bit x86 CPUs and 64-bit x86 compatible CPUs, is significant because a 32-bit x86 kernel would not normally expect the NX bit that an AMD64 or IA-64 supplies; the NX enabler patch ensures that these kernels will attempt to use the NX bit if present."

- More Performance - and not only more registers. There is no more need for that 4/4 Split, that makes XNU (32Bit) a slower.[/quote]

Again: isn't the bottleneck in the apps? About memory, a straight quote from Apple.com:

"Today’s Mac computers can hold up to 32GB of physical memory, but the 32-bit applications that run on them can address only 4GB of RAM at a time. 64-bit computing shatters that barrier by enabling applications to address a theoretical 16 billion gigabytes of memory, or 16 exabytes."

Even if your kernel is 32bit, your apps are 64bit, and they can take advantage of lots and lots of RAM and extra registers.

The main benefits of 64bits are there, even with 32bit kernel.

 

[loveturtle]

I get so sick of the offensive stench of entitlement that pervades these boards sometimes!
[/RANT]

Yeah, I think macpro1,1 owners are just mad that apple keeps ******** on them. Not only can we never get decent video cards in our 3k workstations for no legitimate reason but now we can't get 64bit. sigh.

Anyway, since everyone keeps asking for a reason why us macpro1,1 owners would be sad because "there's no difference" i'll give you one example that annoys me every day. Memory. I've got 10gb of ram yet if I mess around in vmware for a while all of a sudden I start swapping like crazy and performance takes a ****! now why the hell would I be swapping when I have 6gb of free memory? oh yeah, because it's not really 64bit..sure the "application" can have access to larger address space but the kernel can't. great, cute, adorable. also, i've been using zfs since 10.5 came out and I'm hoping to continue with 10.6, ZFS ARC cache is in the kernel, I sure would like it to be able to use my memory....so great..10gb of ram that can't be used for anything useful.

Oh yes, but of course I can open large photos in photoshop! what else would I want to use my memory for? As usual, bare minimum all the time.

 

[commander.data]

MS is intentionally developing Compute Shaders to compete against OpenCL, they both do the same thing. Compute Shaders isn't for graphics only, it can do pure math work just like OpenCL. They are very similar in that nature.

http://www.electronista.com/articles/08/07/23/directx.11.with.gpgpu.tech/
Direct form MS's Mouth, http://www.microsoft.com/downloads/...2B-53EA-4F80-84B2-F05A360BFC6A&displaylang=en

http://www.techreport.com/articles.x/17321/2

I think DirectX 11 Compute is still under NDA, so I don't want to go into that yet. Other than the obvious thing we mentioned before, which is that OpenCL is a standalone, complete compute solution you can use for protein folding and particle analysis never touching the pixel, and you have the option of interopping it very closely with OpenGL, so you can use it for image processing and feeding into and feeding out of the OpenCL pipeline.

Versus the approach that DirectX 11 Compute takes, which is . . . "super shaders", which are like general-purpose C shaders. But those shaders exist within the context of the DX graphics pipeline, so it's intended to soup up your graphics applications but you'd probably find it more difficult to write, you know, a general-purpose animation package. There's a difference in approach.

Well, Microsoft might advertise a lot of things, but the implementation is important. In this case, actual implementers like nVidia see Compute Shaders in DX11 as more limited in scope than OpenCL. There is a lot of overlap but OpenCL should be broader. Admittedly, Neil Trevett is Khronos President so he might be more biased towards OpenCL, but he is an nVidia Vice-President so he speaks for nVidia too and would best know the distinction between C for CUDA, OpenCL, and CS in DX11.

 

[German]

IIRC, NX-bit is a feature of the CPU, and not feautre of the "bitness" as such. 32bit kernel can support is just fine, at least Linux does:

OK, but only für 64Bit Code -> OSX

- More Performance - and not only more registers. There is no more need for that 4/4 Split, that makes XNU (32Bit) a slower.

4/4 Split... with the disadvantage of being less efficient in copying of data between user and kernel.

Source: Inside the Mac OS X Kernel
http://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf

 

[Evangelion]

That's right and the Apps are programmed to take into account either 32 bit or 64 bit kernels, the latter of which are going to be faster so far as I understand the matter.

There's not going to be a major difference between the two. Or do you think that "it has to be faster because it has more bits!"?

The key is to both and there have been documented vulnerabilities with the way 32 bit kernels handle the memory allocations. With 64 bit kernels the allocation is fully randomized increasing security dramatically. So even if you want greater security in Apps, it sure isn't a bad idea to increase security in the way those apps function in the computer's memory.

I don't think memory-randomization is dependant on the bitness of the system....

Yes optimizations like H.264 Acceleration. Optimized drivers that utilize the hardware's full capacities as found on other operating system platforms + security and speed as just noted.

And what makes you think that there would be any tangible difference between 32bit kernel and 64bit kernel?

See above.

Again: what are you missing out on?

But it definitely would, as just noted.

Such as? What makes you think that the features you are thinking of requires 64bit kernel?

They are not forcing anything, they are ending adequate support for those machines prematurely.

No they aren't. Those machine will work fine, and they will work fast.

But as per the above the difference is not insignificant.

To end-users it pretty much is.

 

[JohnDoe98]

No we don't. We only have the claims of that company and its shills. Claims that consistently turn out to be rubbish.

So you deny benchmark tests that demonstrate dramatic speed differences between Nvdia hardware on a Mac and Windows platform, attributed solely to the updated drivers found on the Windows platform but not available to Mac users because Apple hasn't updated their drivers yet?

You also deny that Windows and Linux have fully 64 bit OSs for the same hardware configurations that are currently left out of SL?

I probably is a driver issue, seeing as successive iterations seem to include more machines.

Of course it's a driver issue, that's the entire point of this debate.

Or 3) Oh, I don't know. Let me just make up some rubbish like your examples. How about: all the staff responsible for writing 64 bit drivers are working on bringing all the drivers for the relevant hardware up to date according to a sensible schedule that's only known within Cupertino, just as it should be.

That's fine but the point then is the software shouldn't be released until that staff has successfully brought the drivers to all relevant (i.e. capable) hardware.

Your whole post basically sums up your petulance and your lack of understanding of the hardware, the software and the engineering realities behind such a huge update as this. But you don't care about any of that. You just want it all and you want it now!

Wrong. I don't care when they release it. I'd be happy to wait till next year, and I'd also be happy to pay an extra 30$ if they provide full support for all capable hardware.

I get so sick of the offensive stench of entitlement that pervades these boards sometimes!

Right it's wrong to think that one is entitled to what one has paid for. It is furthermore wrong to think that when one pays for premium products that they deserve premium quality as compared to the market place.

 

[German]

So anybody with a machine supporting only the 32 bit kernel in Snow Leopard, calm down. You'll benefit from ALL speed improvements. The C2D doesn't need an all 64 bit environment to execute 64 bit code.

Linux, Windows, BSD, ... every PC with a 64Bit-CPU is capable to use these OperatingSystems without problemens in 64Bit Mode (64Bit Kernel). So why shouldn't this work with OSX and just a few Macs (compared to PCs)? Because Apple is too lazy? Because it is a trick for the future, to find a reason that you have to buy a new Mac, when OSX will have no more 32Bit Kernel in future versions? ;-)

 

[JohnDoe98]

From a developer standpoint 64 bit is more or less irrelevant concerning speed. There are only very few computations, that benefit from it, and especially Finder, Mail, etc. should not benefit at all. Those computations, that can benefit from 64 bit, could already be used without compromise in Leopard. Everything at 64 bit makes it just a bit more comfortable for the programmer.

The one huge feature, that makes Snow Leopard fly is asynchronous control flow, and GC is only part of that equation. An event driven, asynchronous and concurrently operating Finder can really perform much better than the old centralized (single thread) approaches. The all 64-tag is mainly marketing and preparation for >4GB desktop standard times in the future.

So anybody with a machine supporting only the 32 bit kernel in Snow Leopard, calm down. You'll benefit from ALL speed improvements. The C2D doesn't need an all 64 bit environment to execute 64 bit code.

Thank you, very nice and informative post.

 

[Evangelion]

OK, but only für 64Bit Code -> OSX

But it's doable in 32bits as well. Will Apple implement it or not remains to be seen though.

Source: Inside the Mac OS X Kernel
http://events.ccc.de/congress/2007/Fahrplan/attachments/986_inside_the_mac_osx_kernel.pdf

That's two years old information from older version of OS X:

 

[loveturtle]

I really wonder why everyone is so quick to be an Apple apologist. It's always the same excuse "end users wont notice" "it's not a big deal".

People pay a huge premium on the MacPro. You know how hard it is to justify a 3k desktop PC? and they can't even put enough effort to support 64bit?

On my macpro1,1 I have ran XP64, vista64, FreeBSD/amd64, Solaris (SXCE & OpenSolaris) in 64bit mode, -ALL- of these work. Yet the company I gave such a large premium to can't be bothered to support me a couple years later and you guys want to defend that? Somehow buying a 3k workstation with the expectation of a very basic level of support is "entitlement"? Come on... I'm not really that insulted at Apple because this is what I expect from them, but it's really annoying to listen to you apologists. There's really no excuse.

 

[MRU]

I really wonder why everyone is so quick to be an Apple apologist. It's always the same excuse "end users wont notice" "it's not a big deal".

People pay a huge premium on the MacPro. You know how hard it is to justify a 3k desktop PC? and they can't even put enough effort to support 64bit?

On my macpro1,1 I have ran XP64, vista64, FreeBSD/amd64, Solaris (SXCE & OpenSolaris) in 64bit mode, -ALL- of these work. Yet the company I gave such a large premium to can't be bothered to support me a couple years later and you guys want to defend that? Somehow buying a 3k workstation with the expectation of a very basic level of support is "entitlement"? Come on... I'm not really that insulted at Apple because this is what I expect from them, but it's really annoying to listen to you apologists. There's really no excuse.

Exactly.... For me it's the 'principal' of the thing, and has nothing to do whether end users will see the difference or not. If other OS's run perfectly in 64bit on my hardware, than it seems utterly moribund that Apple's new OS can not.

 

[German]

That's two years old information from older version of OS X:

Makes no differences. 32Bit XNU (the kernel) works in that way. 4/4 Split. That may be one of the reasons, that OSX is sometimes slower compared to other OperationsSystems with 3/1 Split.

 

[needlz]

Looks like the version which has been leeked on torrent sites is fake..

Check out the release notes (10.6_snow_leopard_client_10a432_seed_note.rtf):

Using this seed and one of the K64-capable machines listed above, simply boot the Mac with the '6' and '4' keys held down to use the 64-bit kernel. Observe that uname -v reports RELEASE_X86_64. Machines listed as "Default" and all Server installs will run K64 automatically when loaded with 10A402.