In the middle it is looking like Atom is in a very good place, as has PentiumM on PC104 (and PCI brethren) for a while. PPC is being squeezed-out of that arena especially with the motorola to freescale and emerson sales. IBM does not serve the likes of emerson and GE well.
I'm guessing yours is not 400MHz 4MB non-mirrored e-cache model, but I digress...
The USII was arguably the best at the right time processor to come out of Sun. Its competitors were Power3 (came out the next year), Alpha 21264, PA8500, and R12000. Nothing from Intel or AMD at the time came close. The Power3 was the closest in performance, better in some respects, but AIX was very not pleasant and the cache tended to be better on the USII for the same price. The Alpha was getting dated, but you could get ones at fast clock speeds with lots of cache, again more expensive. The HP and MIPS were showing their age at that point.
The USIII was a very bad processor in terms of MIPS, power consumption, and cost. It was also over two years late. The IIIi was a good one though. When it came out Sun had boxes with 4 USIIIi procs and 8-16GB ram at great prices. Too bad dot-com was collapsing around them at the same time.
Yeah I have had some experience with nfs in on darwin, freebsd, and linux. In all cases it has been a good idea to fix the port that lockd runs on (nfs.conf or services files typically) and add firewall rules that let the IPs you need talk. The other services like statd seem to be fine though as is by just letting portmap pick on systems where it does dynamically.
OS X had automounting growing pains that seem to have gotten all worked out circa 10.4.
In regards to Linux, a long time ago there were issues I ran into where nfs over tcp was slow. Then the nfs over tcp got good enough somewhere in 2.2. There was (and probably still is) performance issues with half duplex and nfs over udp on Linux (I have not run half duplex in ages). The nfs code base also got pretty reliable around then as well, with the exception of 2.6.8.
With regards to FreeBSD I never had any trouble (there was that week when Matthew Dillon ran a NeXT fs stress test program and fixed a number of bugs though, I guess no one was being evil in my case) until I simultaneously went to FreeBSD 6.3 clients and Solaris 10 server. I was a bit disappointed that thre was little in the logs to clue me in what was up, but looking in tcpdump gave me an idea to try tcp and that worked fine.
Based on all of that history I now think that the best course of action if you want a good nfs experience is to fix the port for lockd and opening it in firewalls and to use nfs v3 over tcp. That seems to work the best on all systems. (Oh yeah for a while there v3 on Linux was strangely much slower than v2, but that got better in that same 2.2 time frame) v3 lets you support bigger files and is generally faster and is now well supported so that is why I tend to use that.
Oh my goodness, I thought that by now Lustre and ZFS had been much better integrated when Sun bought them. That is why I thought that with ZFS you could treat it like a CFS. I work for a federal lab and it was very hyped to us for about a year. I just googled and found this message:
In fact all ZFS work is off of the roadmap in Lustre. I guess the promises made in 2007 did not pan out. It all seems even more likely dead now due to the Oracle purchase.
"That's not at all true. You can't remote mount a ZFS pool. If you present out a block device from a Solaris box, the remote box treats it like a standard SCSI device, regardless of what the remote OS is."
I did not know that. I thought you could create default zfs pool on that iSCSI device with one big fs which only uses the fs created in the larger pool on the host. That is what I meant by zfs over iSCSI. You can't do that?
So the best option is you make a ufs fs if you want to use solaris clients then?
What I know is that you can create a zfs pool and then an empty fs in it on a solaris box. Then you can do FCP or iSCSI to it. But if you have a WIndows initiator say using iSCSI you would format it as NTFS in order to use it. Likewise for Linux you would make an ext2 fs. If you have a solaris initiator you can just create a zfs fs in your pool with default options and then it is just like a zfs fs in a pool over iSCSI instead of SCSI for the client. That is what I meant by that comment. So you either create a three vols, one NTFS, one ext2, and one zfs and use a block device from your clients, wasting capacity and losing the easy reconfiguration on NTFS and ext2 (you could be really crafty about LUNs and get a volume manager running for Linux but you need to learn all that complicated stuff that zfs made so easy), or you make some zfs volumes in your pool and not lose all that. But for your Windows and Linux initiators you would need to share those fs via cifs and optionally also nfs from the solaris SAN.
I answered the question that Xsan does not use ZFS, rather StorNext FS, technology Apple paid Quantum for. The SAN in this case is an Apple computer (likely an Xserve) connected to a storage array via fiber. Then Xsan provides software that other Apple clients can use to use the SAN. You can buy some software from Quantum if you want use the SAN as a block device from Windows, Linux, Solaris, etc clients since the FS and protocol are identical.
Solaris has got it's own ways to act as a SAN but it is not Xsan.
I am so liking ZFS on Solaris that having it in 10.6 would have been reason enough for me to by an new iMac (more for the use it instead of FAT32 between my Apple, FreeBSD, and Solaris boxes than anything else really). I currently have the lowest end model of PPC G4 eMac that officially supports 10.5 (Wow did I get lucky, six years ago I was really wondering if the $ premium on the 1GHz SuperDrive model was worth it). It looks that I can put off the purchase of a new iMac until 10.7 since Apple should continue offering security updates for 10.5 until then. Hopefully by then 10.7 will have ZFS support outside of FUSE and then I will gladly open my wallet (maybe I will even have the luxury of having to make the painful decision of whether the $ premium of the bluray writer is worth it).
I'm am so glad that the entire world has not forgotten about how to use NIS to mount homedirs for all workstations. Seeing LDAP take over has been heartbreaking, since so many places just end-up using Windows as the server. I'm sorry to hear that it stopped working right with NIS and ZFS. Did you have this sort of structure:
Very many entries like this for all of the user names:
tank/home/username/export/home/username
And it was worked around by simply doing this:
tank/home/export/home
I can see how if you only had one/export/home type line in the dfs/sharetab but used a tank/home/username type of filesystem for each user that would not have worked. Your admin might get it to work by simply adding a line for each file system that was created for each user in the sharetab, ie one for each mounted under/export/home/username, you can see how things are being exported by typing share on the Solaris NFS server, there should be an/export/home/username for every filesystem mounted under/export/home. I am assuming that is the way the admin set-up zfs home dirs since then he can get quotas for the home dirs and user, as well as restrict the nfs sharing to only certain users and even from certain IPs.
They don't, Xsan uses the StorNext File System. Apple licensed it from Quantum. In fact if you buy StorNext FX or FX2 you can talk to the SAN as if it were a block device as they provide drivers/kernel extensions and tools for lots of versions of Windows (32 and 64 bit), Solaris (sparc and x86), Linux (a few 32 and 64 bit distros), AIX, HPUX, and even IRIX (basically only the BSDs, which actually matters, and the dinosaurs VMS and Ultrix are out in the cold):
Supposedly it works with FFS from basically all the BSDs. The last time I looked UFS on Apple was essentially BSD FFS UFS. The headers look like it may deal deal with an Apple Partition Map as well, so it MIGHT work with that as long as you do not use GUID instead. Solaris UFS has made some changes long ago that make things different sizes than in FFS, so mounting FFS under Solaris is not possible in any way that I know of.
The other thing is that there are various journaling schemes for FFS and that as well as extended attributes and acls are fairly recent additions. I don't know how much of that ffsdrv nor Apple UFS support.
So now that I think about, man do I wish FFS would have been the best option, but I guess not. I guess cifs on top of whatever is sadly the best option these days.
I'm thinking it could be the smaller provider with that/16 that is proxying DNS instead of comcast itself, possibly a small company that is leasing this and using some filter software of their to keep employees from browsing NSFW sites.
I guessed this URL and decided to post what is there before it gets changed, 404s, or redirects as well. Of note are that OpenCL seems to have no software backend and requires capable GPUs, Grand Central requires at least two cores (no fall-back so devs can use the same API?), and PPC is gone (even G5):
General requirements Intel Core 2 Duo (pictured, but only intel required it seems, see the next line)
* Mac computer with an Intel processor
* 1GB of memory
* 5GB of free disk space
* DVD drive for installation
* Some features require a compatible Internet service provider; fees may apply.
* Some features require Apple's MobileMe service; fees and terms apply.
Feature-specific requirements
Time Machine
Time Machine requires an additional hard drive or Time Capsule (sold separately).
Photo Booth
requires an iSight camera (built in or external), USB video class (UVC) camera, or FireWire DV camcorder. Backdrop effects when using a DV camcorder require fixed focus, exposure, and white balance.
Boot Camp
requires Windows XP with Service Pack 2 or Windows Vista (sold separately).
Screen sharing
in iChat and the Finder requires a 128-Kbps Internet connection (300 Kbps recommended).
DVD Player
requires a 1.6GHz processor or faster for improved deinterlacing.
iChat
* Audio chats require a microphone and a 56-Kbps Internet connection.
* Video chats require an iSight camera (built in or external), USB video class (UVC) camera, or FireWire DV camcorder; and a 128-Kbps upstream and downstream Internet connection.
* Backdrop effects when using a DV camcorder require fixed focus, exposure, and white balance.
* Some iChat features offer better performance and quality with higher system capabilities. More details
Exchange Support
requires Microsoft Exchange Server 2007 Service Pack 1 Update Rollup 4. Auto-setup requires enabling the Autodiscovery feature of Microsoft Exchange Server.
QuickTime X movie capture
requires iSight camera (built-in or external), USB video class (UVC) camera, or FireWire DV camcorder. QuickTime H.264 hardware acceleration
requires a Mac with a NVIDIA 9400M graphics processor.
Developer tools
require 1GB of memory and an additional 3GB of available disk space.
Mac OS X v10.6 Snow Leopard will be available in September 2009. Here's how to get it.
With every new Mac.
When it's released, every new Mac computer will come with Mac OS X Snow Leopard already installed. You won't need to do anything.
Snow Leopard Up-to-Date Program.
If you purchased a qualifying Mac on or after June 8, 2009, that does not include Mac OS X Snow Leopard, you can upgrade for $9.95.
Upgrading from Mac OS X v10.5 Leopard.
If your Intel-based Mac is running Mac OS X v10.5 Leopard, just purchase Mac OS X v10.6 Snow Leopard when it's available and follow the simple installation instructions.
Upgrading from Mac OS X v10.4 Tiger.
If your Intel-based Mac is running Mac OS X v10.4 Tiger, purchase the Mac Box Set (when available), which is a single, affordable package that includes Mac OS X v10.6 Snow Leopard; iLife '09, with the latest versions of iPhoto, iMovie, GarageBand, iWeb, and iDVD; and iWork '09, Apple's productivity suite for home and office including Pages, Numbers, and Keynote.
"SAN FRANCISCO--June 9, 2008--Apple® today previewed Mac OS® X Snow Leopard, which builds on the incredible success of OS X Leopard and is the next major version of the world's most advanced operating system. Rather than focusing primarily on new features, Snow Leopard will enhance the performance of OS X, set a new standard for quality and lay the foundation for future OS X innovation. Snow Leopard is optimized for multi-core processors, taps into the vast computing power of graphic processing units (GPUs), enables breakthrough amounts of RAM and features a new, modern media platform with QuickTime® X. Snow Leopard includes out-of-the-box support for Microsoft Exchange 2007 and is scheduled to ship in about a year.
"We have delivered more than a thousand new features to OS X in just seven years and Snow Leopard lays the foundation for thousands more," said Bertrand Serlet, Apple's senior vice president of Software Engineering. "In our continued effort to deliver the best user experience, we hit the pause button on new features to focus on perfecting the world's most advanced operating system."
Snow Leopard delivers unrivaled support for multi-core processors with a new technology code-named "Grand Central," making it easy for developers to create programs that take full advantage of the power of multi-core Macs. Snow Leopard further extends support for modern hardware with Open Computing Language (OpenCL), which lets any application tap into the vast gigaflops of GPU computing power previously available only to graphics applications. OpenCL is based on the C programming language and has been proposed as an open standard. Furthering OS X's lead in 64-bit technology, Snow Leopard raises the software limit on system memory up to a theoretical 16TB of RAM.
Using media technology pioneered in OS X iPhone(TM), Snow Leopard introduces QuickTime X, which optimizes support for modern audio and video formats resulting in extremely efficient media playback. Snow Leopard also includes Safari® with the fastest implementation of JavaScript ever, increasing performance by 53 percent, making Web 2.0 applications feel more responsive.*
For the first time, OS X includes native support for Microsoft Exchange 2007 in OS X applications Mail, iCal® and Address Book, making it even easier to integrate Macs into organizations of any size."
Most likely not, since they said they liked the way that the current Finder worked. This was a code clean-up sort of thing since Carbon is not 64-bit native.
A great mix in practice is to use a gate array in a PMC, PCI, IP, or VME card/board for that stuff but still have the beefy processor for less predicable 10s of us (ISR) and 10s of ms (realtime tasks) stuff.
Oh yes it does. It eats something like 1/4 of your physical memory by default if you want processes instead of tasks. It also adds latency and removes some determinism (no longer can you get away with a flat memory model, in PPC in particular you could often easily use the BAT registers and not have any TLB misses and in some cases treat 1MB of your L2 cache as really fast memory).
This rings true, we have had similar experiences, but one thing to note is that often what WRS did is that they took a lot of code provided by the likes of Moto who used code from the likes of Marvell and Intel to make a BSP. That's often why early on things were not great across the board. It was so bad initially that there were at least three different ways of doing PCI! Then someone would pay to get things improved and then in a later version it all got integrated and everyone got to use it. For example the networking code went through a few versions. First there was one, then there were two offered early on in vxWorks 5.x but you had to pay extra, then only the better one got rolled in. Then around 5.5 you could buy a better (but slower) stack from another vendor. Then WRS bought them and offered it at extra cost, then around 6.4 it became the only option.
There was also all the AE extensions that you had to pay for extra and became part of the base in 6.0. But the problem was like you state you had to pay all over again to go from 5.x to 6.x under a completely different model. For example in our case it was more economical to do per board (target) for a few BSPs with 2 hosts (dev boxes), but under 6.0 it became more economical to do all BSPs, unlimited targets, but a small fixed number of concurrent developers on an unlimited number of hosts. Of course we had to pay all over again and still pay for continuing 5.x support separately.
Also all that I described was for vxWorks and support, where was also the debugging and dev stuff you needed to pay for. Again as vxWorks went from 5.x to 6.x that went from 2.x to 3.x. The 2.x stuff was wxWidgets and tcl/tk based, the 3.x stuff is Eclipse based. Also you have also had in most cases at least the options of a gcc or diab tool chain. You used to have to pay extra for diab, now you pretty much always have to buy it, even if you don't use it.
With regards to the support, yeah it got pretty crappy, it used to be great, and the newsgroup was good too. Then we got a guy that worked with WRS and he was able to get them to send us source code with typically agreements like 3 people could see the code. Eventually WRS hired that guy we had but in 6.x it got a lot more simple as you can get access to a whole lot more of the source code for not much extra money.
I'm a guy that does vxWorks on Moto VME boards and now is a pretty scary time. Those boards are now made by Emerson who really have not done anything new with them and now with WRS bought by Intel, that could possibly be even worse. VME is a place the after pSOS was always the best. There were a few particular boards that had decent RTEMS, Linux, or BSD but they were always few and far between. The other thing is that except for networking vxWorks was always faster than RTEMS (across the board) and Linux (when you looked at what were the worst 5%) with respects to latency.
Slashdot Mirror
In the middle it is looking like Atom is in a very good place, as has PentiumM on PC104 (and PCI brethren) for a while. PPC is being squeezed-out of that arena especially with the motorola to freescale and emerson sales. IBM does not serve the likes of emerson and GE well.
I'm guessing yours is not 400MHz 4MB non-mirrored e-cache model, but I digress...
The USII was arguably the best at the right time processor to come out of Sun. Its competitors were Power3 (came out the next year), Alpha 21264, PA8500, and R12000. Nothing from Intel or AMD at the time came close. The Power3 was the closest in performance, better in some respects, but AIX was very not pleasant and the cache tended to be better on the USII for the same price. The Alpha was getting dated, but you could get ones at fast clock speeds with lots of cache, again more expensive. The HP and MIPS were showing their age at that point.
The USIII was a very bad processor in terms of MIPS, power consumption, and cost. It was also over two years late. The IIIi was a good one though. When it came out Sun had boxes with 4 USIIIi procs and 8-16GB ram at great prices. Too bad dot-com was collapsing around them at the same time.
Yeah I have had some experience with nfs in on darwin, freebsd, and linux. In all cases it has been a good idea to fix the port that lockd runs on (nfs.conf or services files typically) and add firewall rules that let the IPs you need talk. The other services like statd seem to be fine though as is by just letting portmap pick on systems where it does dynamically.
OS X had automounting growing pains that seem to have gotten all worked out circa 10.4.
In regards to Linux, a long time ago there were issues I ran into where nfs over tcp was slow. Then the nfs over tcp got good enough somewhere in 2.2. There was (and probably still is) performance issues with half duplex and nfs over udp on Linux (I have not run half duplex in ages). The nfs code base also got pretty reliable around then as well, with the exception of 2.6.8.
With regards to FreeBSD I never had any trouble (there was that week when Matthew Dillon ran a NeXT fs stress test program and fixed a number of bugs though, I guess no one was being evil in my case) until I simultaneously went to FreeBSD 6.3 clients and Solaris 10 server. I was a bit disappointed that thre was little in the logs to clue me in what was up, but looking in tcpdump gave me an idea to try tcp and that worked fine.
Based on all of that history I now think that the best course of action if you want a good nfs experience is to fix the port for lockd and opening it in firewalls and to use nfs v3 over tcp. That seems to work the best on all systems. (Oh yeah for a while there v3 on Linux was strangely much slower than v2, but that got better in that same 2.2 time frame) v3 lets you support bigger files and is generally faster and is now well supported so that is why I tend to use that.
Thank you for the very informative reply. One more question though:
Is there a reason you chose cifs over nfs?
Oh my goodness, I thought that by now Lustre and ZFS had been much better integrated when Sun bought them. That is why I thought that with ZFS you could treat it like a CFS. I work for a federal lab and it was very hyped to us for about a year. I just googled and found this message:
http://lists.lustre.org/pipermail/lustre-discuss/2008-March/007006.html
Containing these nuggets:
---
Wed Mar 19 18:05:27 PDT 2008
> do you know if there is any chance that there be working lustre software for
> Solaris by the end of April?
Sorry, there is no chance of this at all. Due to integration issues
this is more likely to be available around the end of the year.
> > This is completely alpha code, you probably don't want to use it at
> > this time.
It refers to this wiki, not updated for a year now:
http://wiki.lustre.org/index.php?title=Lustre_OSS/MDS_with_ZFS_DMU
---
In fact all ZFS work is off of the roadmap in Lustre. I guess the promises made in 2007 did not pan out. It all seems even more likely dead now due to the Oracle purchase.
"That's not at all true. You can't remote mount a ZFS pool. If you present out a block device from a Solaris box, the remote box treats it like a standard SCSI device, regardless of what the remote OS is."
I did not know that. I thought you could create default zfs pool on that iSCSI device with one big fs which only uses the fs created in the larger pool on the host. That is what I meant by zfs over iSCSI. You can't do that?
So the best option is you make a ufs fs if you want to use solaris clients then?
What I know is that you can create a zfs pool and then an empty fs in it on a solaris box. Then you can do FCP or iSCSI to it. But if you have a WIndows initiator say using iSCSI you would format it as NTFS in order to use it. Likewise for Linux you would make an ext2 fs. If you have a solaris initiator you can just create a zfs fs in your pool with default options and then it is just like a zfs fs in a pool over iSCSI instead of SCSI for the client. That is what I meant by that comment. So you either create a three vols, one NTFS, one ext2, and one zfs and use a block device from your clients, wasting capacity and losing the easy reconfiguration on NTFS and ext2 (you could be really crafty about LUNs and get a volume manager running for Linux but you need to learn all that complicated stuff that zfs made so easy), or you make some zfs volumes in your pool and not lose all that. But for your Windows and Linux initiators you would need to share those fs via cifs and optionally also nfs from the solaris SAN.
Is there some new development I am not aware of?
I answered the question that Xsan does not use ZFS, rather StorNext FS, technology Apple paid Quantum for. The SAN in this case is an Apple computer (likely an Xserve) connected to a storage array via fiber. Then Xsan provides software that other Apple clients can use to use the SAN. You can buy some software from Quantum if you want use the SAN as a block device from Windows, Linux, Solaris, etc clients since the FS and protocol are identical.
Solaris has got it's own ways to act as a SAN but it is not Xsan.
I am so liking ZFS on Solaris that having it in 10.6 would have been reason enough for me to by an new iMac (more for the use it instead of FAT32 between my Apple, FreeBSD, and Solaris boxes than anything else really). I currently have the lowest end model of PPC G4 eMac that officially supports 10.5 (Wow did I get lucky, six years ago I was really wondering if the $ premium on the 1GHz SuperDrive model was worth it). It looks that I can put off the purchase of a new iMac until 10.7 since Apple should continue offering security updates for 10.5 until then. Hopefully by then 10.7 will have ZFS support outside of FUSE and then I will gladly open my wallet (maybe I will even have the luxury of having to make the painful decision of whether the $ premium of the bluray writer is worth it).
I know you said UFS but you don't use any software from Veritas do you? I've seen Veritas kernel modules dick with vfs and cause trouble.
I'm am so glad that the entire world has not forgotten about how to use NIS to mount homedirs for all workstations. Seeing LDAP take over has been heartbreaking, since so many places just end-up using Windows as the server. I'm sorry to hear that it stopped working right with NIS and ZFS. Did you have this sort of structure:
Very many entries like this for all of the user names:
tank/home/username /export/home/username
And it was worked around by simply doing this:
tank/home /export/home
I can see how if you only had one /export/home type line in the dfs/sharetab but used a tank/home/username type of filesystem for each user that would not have worked. Your admin might get it to work by simply adding a line for each file system that was created for each user in the sharetab, ie one for each mounted under /export/home/username, you can see how things are being exported by typing share on the Solaris NFS server, there should be an /export/home/username for every filesystem mounted under /export/home. I am assuming that is the way the admin set-up zfs home dirs since then he can get quotas for the home dirs and user, as well as restrict the nfs sharing to only certain users and even from certain IPs.
They don't, Xsan uses the StorNext File System. Apple licensed it from Quantum. In fact if you buy StorNext FX or FX2 you can talk to the SAN as if it were a block device as they provide drivers/kernel extensions and tools for lots of versions of Windows (32 and 64 bit), Solaris (sparc and x86), Linux (a few 32 and 64 bit distros), AIX, HPUX, and even IRIX (basically only the BSDs, which actually matters, and the dinosaurs VMS and Ultrix are out in the cold):
http://www.quantum.com/Products/Software/StorNextFX/Index.aspx
http://salestools.quantum.com/getDocPRetriever.cfm?ext=.pdf&type_mime=application/pdf&filename=294835.pdf (warning pdf)
When you buy Xsan from Apple you get block level kexts and tools for OS X of course.
ZFS SAN really only has been rolled out for Solaris clients. Everything else would have to treat it as NAS via cifs or nfs.
"I've several Macs doing time-machine to networked ZFS drives."
How did you get that to work? Are you mounting a sparseimage file in OS X which you have exported from the Sun/FreeBSD box via nfs?
You might take a look at FFS UFS, form me it worked for NetBSD and FreeBSD disks I had to mount under Windows XP and Vista:
http://ffsdrv.sourceforge.net/
Supposedly it works with FFS from basically all the BSDs. The last time I looked UFS on Apple was essentially BSD FFS UFS. The headers look like it may deal deal with an Apple Partition Map as well, so it MIGHT work with that as long as you do not use GUID instead. Solaris UFS has made some changes long ago that make things different sizes than in FFS, so mounting FFS under Solaris is not possible in any way that I know of.
The other thing is that there are various journaling schemes for FFS and that as well as extended attributes and acls are fairly recent additions. I don't know how much of that ffsdrv nor Apple UFS support.
So now that I think about, man do I wish FFS would have been the best option, but I guess not. I guess cifs on top of whatever is sadly the best option these days.
Never mind, your behind a NAT. That could be doing it.
https://ws.arin.net/whois/?queryinput=!%20NET-69-253-0-0-1
CIDR: 69.253.0.0/16
NetType: Reassigned
Out of this larger block:
https://ws.arin.net/whois/?queryinput=!%20NET-69-240-0-0-1
I'm thinking it could be the smaller provider with that /16 that is proxying DNS instead of comcast itself, possibly a small company that is leasing this and using some filter software of their to keep employees from browsing NSFW sites.
I guessed this URL and decided to post what is there before it gets changed, 404s, or redirects as well. Of note are that OpenCL seems to have no software backend and requires capable GPUs, Grand Central requires at least two cores (no fall-back so devs can use the same API?), and PPC is gone (even G5):
http://www.apple.com/macosx/specs.html
General requirements
Intel Core 2 Duo (pictured, but only intel required it seems, see the next line)
* Mac computer with an Intel processor
* 1GB of memory
* 5GB of free disk space
* DVD drive for installation
* Some features require a compatible Internet service provider; fees may apply.
* Some features require Apple's MobileMe service; fees and terms apply.
Feature-specific requirements
Time Machine
Time Machine requires an additional hard drive or Time Capsule (sold separately).
Photo Booth
requires an iSight camera (built in or external), USB video class (UVC) camera, or FireWire DV camcorder. Backdrop effects when using a DV camcorder require fixed focus, exposure, and white balance.
Boot Camp
requires Windows XP with Service Pack 2 or Windows Vista (sold separately).
Screen sharing
in iChat and the Finder requires a 128-Kbps Internet connection (300 Kbps recommended).
DVD Player
requires a 1.6GHz processor or faster for improved deinterlacing.
iChat
* Audio chats require a microphone and a 56-Kbps Internet connection.
* Video chats require an iSight camera (built in or external), USB video class (UVC) camera, or FireWire DV camcorder; and a 128-Kbps upstream and downstream Internet connection.
* Backdrop effects when using a DV camcorder require fixed focus, exposure, and white balance.
* Some iChat features offer better performance and quality with higher system capabilities. More details
Exchange Support
requires Microsoft Exchange Server 2007 Service Pack 1 Update Rollup 4. Auto-setup requires enabling the Autodiscovery feature of Microsoft Exchange Server.
QuickTime X movie capture
requires iSight camera (built-in or external), USB video class (UVC) camera, or FireWire DV camcorder.
QuickTime H.264 hardware acceleration
requires a Mac with a NVIDIA 9400M graphics processor.
Developer tools
require 1GB of memory and an additional 3GB of available disk space.
OpenCL
* NVIDIA Geforce 8600M GT, GeForce 8800 GT, GeForce 8800 GTS, Geforce 9400M, GeForce 9600M GT, GeForce GT 120, GeForce GT 130.
* ATI Radeon 4850, Radeon 4870
64-bit support
requires a Mac with a 64-bit processor.
Grand Central Dispatch
requires a Mac with a multicore processor.
How to get Mac OS X
Snow Leopard.
Mac OS X v10.6 Snow Leopard will be available in September 2009. Here's how to get it.
With every new Mac.
When it's released, every new Mac computer will come with Mac OS X Snow Leopard already installed. You won't need to do anything.
Snow Leopard Up-to-Date Program.
If you purchased a qualifying Mac on or after June 8, 2009, that does not include Mac OS X Snow Leopard, you can upgrade for $9.95.
Upgrading from Mac OS X v10.5 Leopard.
If your Intel-based Mac is running Mac OS X v10.5 Leopard, just purchase Mac OS X v10.6 Snow Leopard when it's available and follow the simple installation instructions.
Upgrading from Mac OS X v10.4 Tiger.
If your Intel-based Mac is running Mac OS X v10.4 Tiger, purchase the Mac Box Set (when available), which is a single, affordable package that includes Mac OS X v10.6 Snow Leopard; iLife '09, with the latest versions of iPhoto, iMovie, GarageBand, iWeb, and iDVD; and iWork '09, Apple's productivity suite for home and office including Pages, Numbers, and Keynote.
Or even OpenGL for that matter.
Hmm... in the time that I composed and submitted that comment the PR release came back, and it appears unchanged.
Also I'm wondering what the final word will be on PPC with 10.6.
For a little bit there was a new page:
http://www.apple.com/macosx/snowleopard/
It was pretty light on details and basically had all the same info that was on this PR page that now 404s:
http://www.apple.com/ca/press/2008_06/snow_leopard.html
Here is the original that I gleaned from ars:
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/102001262931/p/9
"SAN FRANCISCO--June 9, 2008--Apple® today previewed Mac OS® X Snow Leopard, which builds on the incredible success of OS X Leopard and is the next major version of the world's most advanced operating system. Rather than focusing primarily on new features, Snow Leopard will enhance the performance of OS X, set a new standard for quality and lay the foundation for future OS X innovation. Snow Leopard is optimized for multi-core processors, taps into the vast computing power of graphic processing units (GPUs), enables breakthrough amounts of RAM and features a new, modern media platform with QuickTime® X. Snow Leopard includes out-of-the-box support for Microsoft Exchange 2007 and is scheduled to ship in about a year.
"We have delivered more than a thousand new features to OS X in just seven years and Snow Leopard lays the foundation for thousands more," said Bertrand Serlet, Apple's senior vice president of Software Engineering. "In our continued effort to deliver the best user experience, we hit the pause button on new features to focus on perfecting the world's most advanced operating system."
Snow Leopard delivers unrivaled support for multi-core processors with a new technology code-named "Grand Central," making it easy for developers to create programs that take full advantage of the power of multi-core Macs. Snow Leopard further extends support for modern hardware with Open Computing Language (OpenCL), which lets any application tap into the vast gigaflops of GPU computing power previously available only to graphics applications. OpenCL is based on the C programming language and has been proposed as an open standard. Furthering OS X's lead in 64-bit technology, Snow Leopard raises the software limit on system memory up to a theoretical 16TB of RAM.
Using media technology pioneered in OS X iPhone(TM), Snow Leopard introduces QuickTime X, which optimizes support for modern audio and video formats resulting in extremely efficient media playback. Snow Leopard also includes Safari® with the fastest implementation of JavaScript ever, increasing performance by 53 percent, making Web 2.0 applications feel more responsive.*
For the first time, OS X includes native support for Microsoft Exchange 2007 in OS X applications Mail, iCal® and Address Book, making it even easier to integrate Macs into organizations of any size."
Most likely not, since they said they liked the way that the current Finder worked. This was a code clean-up sort of thing since Carbon is not 64-bit native.
A great mix in practice is to use a gate array in a PMC, PCI, IP, or VME card/board for that stuff but still have the beefy processor for less predicable 10s of us (ISR) and 10s of ms (realtime tasks) stuff.
Oh yes it does. It eats something like 1/4 of your physical memory by default if you want processes instead of tasks. It also adds latency and removes some determinism (no longer can you get away with a flat memory model, in PPC in particular you could often easily use the BAT registers and not have any TLB misses and in some cases treat 1MB of your L2 cache as really fast memory).
One of my office mates drew the short straw and had to maintain that old stuff. Man I felt sorry for him.
This rings true, we have had similar experiences, but one thing to note is that often what WRS did is that they took a lot of code provided by the likes of Moto who used code from the likes of Marvell and Intel to make a BSP. That's often why early on things were not great across the board. It was so bad initially that there were at least three different ways of doing PCI! Then someone would pay to get things improved and then in a later version it all got integrated and everyone got to use it. For example the networking code went through a few versions. First there was one, then there were two offered early on in vxWorks 5.x but you had to pay extra, then only the better one got rolled in. Then around 5.5 you could buy a better (but slower) stack from another vendor. Then WRS bought them and offered it at extra cost, then around 6.4 it became the only option.
There was also all the AE extensions that you had to pay for extra and became part of the base in 6.0. But the problem was like you state you had to pay all over again to go from 5.x to 6.x under a completely different model. For example in our case it was more economical to do per board (target) for a few BSPs with 2 hosts (dev boxes), but under 6.0 it became more economical to do all BSPs, unlimited targets, but a small fixed number of concurrent developers on an unlimited number of hosts. Of course we had to pay all over again and still pay for continuing 5.x support separately.
Also all that I described was for vxWorks and support, where was also the debugging and dev stuff you needed to pay for. Again as vxWorks went from 5.x to 6.x that went from 2.x to 3.x. The 2.x stuff was wxWidgets and tcl/tk based, the 3.x stuff is Eclipse based. Also you have also had in most cases at least the options of a gcc or diab tool chain. You used to have to pay extra for diab, now you pretty much always have to buy it, even if you don't use it.
With regards to the support, yeah it got pretty crappy, it used to be great, and the newsgroup was good too. Then we got a guy that worked with WRS and he was able to get them to send us source code with typically agreements like 3 people could see the code. Eventually WRS hired that guy we had but in 6.x it got a lot more simple as you can get access to a whole lot more of the source code for not much extra money.
I'm a guy that does vxWorks on Moto VME boards and now is a pretty scary time. Those boards are now made by Emerson who really have not done anything new with them and now with WRS bought by Intel, that could possibly be even worse. VME is a place the after pSOS was always the best. There were a few particular boards that had decent RTEMS, Linux, or BSD but they were always few and far between. The other thing is that except for networking vxWorks was always faster than RTEMS (across the board) and Linux (when you looked at what were the worst 5%) with respects to latency.