In 10.5, Apple released a read-only kernel extension/filesystem to allow ZFS pools to be mounted. A later open-source project was hosted at http://zfs.macosforge.org and was announced to be part of 10.6, but shortly before the public release ZFS was yanked, and recently, the Apple-hosted MacOSForge site has closed down the ZFS project.
So, what's the status of ZFS on Mac OS X? Is it worth using? Why would anyone be wanting to use ZFS anyway?
There have been many speculated reasons on the demise of ZFS on Mac OS X. About the only thing that you can say is that (a) it has been deprecated, almost certainly for good, and (b) that no-one knows the real reason why, or at least, isn't saying.
Update Jeff Bonwick, creator of ZFS, suggests that it was a lack of an agreement on (commercial) licensing that was the blocker.
Answers from lawsuits and patent litigation to excessive licensing fees and the impact of the Snoracle deal have been suggested; another is system stability. However, the why is somewhat unimportant, since the end result is the same - Apple no longer support ZFS on Mac OS X.
Does this mean this is the end of ZFS on Mac OS X? Not necessarily. Before the project was yanked, enterprising individuals made copies of the SVN repository (on GitHub Peaceful, Dustin, AlBlue) and of the last publicly available installers and installers were cached on the google group zfs-macos).
A new Google Code project has been set up to take over the maintenance and on-going development of the ZFS extension, and a mailing list exists with 90 members, mostly from the old Apple-hosted list.
The previous ZFS builds works on Leopard and a new build for the 64-bit Snow Leopard has been made available. Work will continue and hopefully port forward some of the later enhancements to ZFS that have been made on the OpenSolaris group since the Mac fork occurred at build 72.
Whilst Apple is looking to recruit new filesystem developers, and is likely looking to extend the increasingly crufty HFS or take lessons learned from ZFS and apply those to the next generation filesystem, probably making its appearance in 10.7 or afterwards.
In the meantime, the ZFS project continues to live on in a new location.
ZFS for OSX/macOS is under active development. The project https://openzfsonosx.org/ has downloads for Sierra 10.12 from earlier in 2017 see the FAQ for details.
As an update to this, ZFS binaries have been made available from the old Apple build and ported to Snow Leopard, and many people are using these already. The code has been synchronised with the upstream OpenSolaris codebase, and more recently, Apple has released the CDDL parts of their previously available ZFS port to developers. So it looks like for the Snow Leopard timeframe at least, ZFS will live on on Mac OS X.
It is Discontinued. So support might be tough, no?
Related
after reading the apple SDK guide
https://developer.apple.com/library/mac/#documentation/developertools/conceptual/cross_development/Overview/overview.html
I'm still confused of how to make the mac app backward compatible & how to test them properly
I have an app, I run it and tested it on Mountain Lion 10.8 without any problem, however I want to make this app backward compatible so that other users can run it on a mac 10.6 - 10.7 machine.
I have an apple developer id and I can download the old versions of 10.7 and 10.6, but the problem is, I have a 2011 macbook air which is currently running 10.8, and that's the only apple machine that I have. Can I test the 10.7 and 10.6 by using vmware or parallels?
in my project settings, I set the target deployment to 10.6 (as I want 10.6 users to run my app), but should I set my SDK to 10.8 or 10.7? if I set the SDK to 10.8 but having the target deployment set to 10.6, if I fix all the xcode warnings will it run successfully on 10.6??
from the SDK drop down, I can only set to 10.8 or 10.7, but 10.6 is missing, how do I fix that?
thanks in advance
I develop on a 10.8 box and support back to 10.5. Just a couple of months ago we dropped 10.4 PPC support, and I'm still cleaning out some of the 10.2-specific code. This may get a little rant-y, but I've been doing old versions for a long time. I have some opinions on the matter.
No matter what Apple says in their docs, if you want to support 10.6, then build with the 10.6 SDK. Do not rely on distribution target.
I have had this discussion with the Xcode engineers, and while they hold to Apple's party line that you should always build with the latest SDK, they also acknowledge that it's generally insane to do so. If you build against the 10.8 SDK and mark your deployment target at 10.6, you will get no warnings for using methods that do not exist on 10.6. The only way you will discover that you've used a nonexistent method is that it might give you strange bugs when run on 10.6. That's insane.
Remember, OS X doesn't crash when you send an unknown selector. It just aborts the current runloop. So the bugs are even harder to track down then on iOS, where it crashes the app.
Sure, you can do weak linking. Talk about dangerous.... Yes, there are a few times this is useful, but the compiler gives you no warning if you don't do it correctly. If I'm going to do weak linking like this, I go the other way, linking against the old SDK and copying the new function's prototype into my implementation. That way I have documentation of every function I think I'm going to weak-link.
Download the old SDKs and symlink them into your Xcode distribution.
Guard them jealously. Apple will try to delete them every time you upgrade Xcode. Make your own copies and stick them in /SDKs or somewhere else away from Xcode. I provide a script called fix-xcode to manage the symlinks automatically. Am I bitter at Apple for their relentless insistance on deleting my old SDKs? Yes, I am.
You can run 10.6 Server in a VM legally. You can run 10.7+ Desktop in a VM legally. These are good ways to test your code.
Or you can do what I do and have a small pile of old MacBooks each with two or three partitions on them that you reboot all the time.
Now that 10.7 comes from App Store, it's a little harder to make VMs. My strong recommendation is to snapshot your image immediately after install, and make a clean backup copy of it. You'll want to be able to clone that image from time to time when you need to get back to a "raw" machine.
Get in the habit of squirreling away SDKs as they come out. 10.8 will be old some day. You might as well make a copy now while it's easy.
Whether you support individual dot-releases or not, it can be very helpful to keep around the upgrade packages for individual dot releases. When you encounter customers running non-current releases, it's nice to be able to check whether an "unreproducible" bug in fact is easily reproducible on their specific version. Whether this is worth it or not depends heavily on your product and customers. It was a life-saver for me when 10.4.11 made major changes to WebKit during a dot release...
Invest in a small NAS or a big external USB drive (though I've had trouble with those failing when used extensively, so I prefer a RAID). You'll need the space. You want to hold onto lots of VMs and lots of SDKs and sometimes even old versions of Xcode.
Adding to Rob Napier's great in-depth answer:
To use an old SDK, put the SDK (or a symlink) to it here:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
With XCode 7.3 or later, you need you to open this file and change "MinimumSDKVersion" (otherwise XCode will refuse to use the old SDK):
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Info.plist
You can install multiple versions of Mac OS on a single machine, booting between each.
The SDK should be the latest (10.8).
See 2.
One alternative to 1 that I've considered (I am in the same boat) is to create a Snow Leopard Hackintosh using an old PC and just installing Lion and Mountain Lion on my MBP.
You need to do these settings :
1.Set the Base SDK to Current version of Mac (ex. 10.7)
2.Set the Deployment SDK to older version (ex.1.4)
Other R-users may well agree that the RStudio IDE has been an extremely effective way to increase productivity. But, with the release of RStudio 0.96.122, neither 32-bit Macs nor OSX < 10.6 (Snow Leopard) are supported. I run OSX 10.6, but on a 32-bit Intel Mac; hence, my choices are
Accept that this will be the last functional release for my system and deal with its limitations.
Complain to the developers - I'd rather not.
Buy expensive new hardware, i.e. a new Mac.
Stop using R and/or RStudio - no way!
So my question is: At what point is it wise to upgrade hardware rather than keep a previous release of software such as RStudio? Is 64-bit that important for "normal" users?
Clearly RStudio is actively developed by some really clever programmers but, damn, Macs are expensive.
I'm currently facing the same issue. My guess is that you could install R on Amazon EC2. I'm going to try that myself in the coming days. I'll come back here to ask how to use a proxy to secure the result.
I'm developing something for Mac OS X. It's a port of a Windows product.
One of my boss' concerns is how it will run on older versions of Mac OS X. I know Xcode has facilities for compiling for old versions of Mac OS X, but QA would prefer to actually run the older versions of Mac OS X on a Macintosh.
Since we got into Macintosh development after Snow Leopard was released, all of our machines come with Snow Leopard (10.6). As far as I know, you can't really walk into a store to buy Leopard (10.5) and anything prior to that is basically extinct.
In a question on virtualization someone said that they've done multi-boot or multiple hard drives for other versions of Mac OS X, but I'm not sure how one would obtain the install media or the license for an old version.
I see Apple has their Mac Developer Program which touts as one of its features as "access pre-release versions of the latest software" which is cool, but I don't see it anywhere on there that old versions of Mac OS X are available. Does Apple have an MSDN-equivalent where old versions of the software are available for download?
Also, is there a reliable breakdown somewhere of the rate of upgrades/updates to Mac OS X? (i.e., what % of users still run Mac OS X 10.5, 10.4, PPC-based machines, etc.)
In case you buy an old OS X from Amazon or other retailers, note that you can not install an OS which was released before the hardware was announced. Older OSes just don't have the required driver to be able to run on a newer machine, and Apple doesn't back-port drivers for older OSes. In other words, if you buy the latest new Mac from Apple, you can't install 10.5 or 10.4 or whatever. So, you need to buy an old Mac too, not just an old OS.
The breakdown of the OS ratio really depends on the software. For example, the veritable Omnigroup publishes this version breakdown of the hits of their software update server. There are many websites which tell you the version break down, see e.g. this site.
Judging from it, I would say Snow Leopard covers half of the Macs in the world. Supporting Leopard might be worth while if you have extra resources. But I would guess people who didn't buy Snow Leopard won't typically buy a new 3rd party app, so supporting Leopard won't give you 50% increase in the number of potential buyers. (I admit this last sentence is completely subjective, though.)
Apple Developer Connection does have most older OS version available for download, but it's not quite from a complete collection (specifically, they're missing a full install of 10.4.anything for Intel CPUs). They do have the GM builds of 10.6.0 (which is Intel only), 10.5.0 (Intel/PPC universal), 10.4.0 (PPC only), 10.3.0, and 10.2.0.
As others have said, you won't be able to use older versions of the OS on newer hardware, so you're going to have to get used computers for testing -- if purchasing doesn't like eBay &c, look for a company that specializes in used equipment, like PC Recycle. For maximum coverage, I'd recommend getting an Intel Mac that shipped with 10.4 (and make sure you get the installer disks that came with it), and a PPC Mac with that's as old as possible while still having a 867MHz+ G4 CPU (so you can run 10.5 on it, and don't have to worry about weird G5 builds) (again, be sure to get its original disks 'cause an older generic installer won't work).
One option (besides acquiring old OS versions yourself) is to use the compatibility labs that Apple maintains. Lots of machines, old and new, already set up with many different versions of the OS.
I believe you can get a "day pass" to the labs for ~$100. Depending on where exactly you're located and the cost of getting to Cupertino, this may or may not be a viable option for you.
http://developer.apple.com/labs/
As others noted, a number of sellers on Amazon have boxed old versions of the OS.
Historically, people used to boot off external Firewire drives to use older or beta OS versions, but of course some of the newer machines lack Firewire ports. I know EFI does support some external boot options (netboot for instance).
It might be possible to boot newer Intel hardware using a late version of 10.4 - but I couldn't guarantee it (as another poster noted, 10.4 won't have relevant hardware drivers - but there are basic generic drivers that may work. Then again, is that a realistic test???).
As an addition to Yuji's post - there are some people who are forced to stick with Leopard or Tiger for compatibility reasons (my father can't upgrade all the machines at his school, because the A3 colour printer only has generic printer support under Snow Leopard, and they also have a lot of older Adobe software). I would say that generally this applies more with institutional customers - for educational software running on 10.4, and even running on PowerPC hardware, can still be a significant issue.
For consumer software - less so - the big spike in Mac sales came after the switch to Intel, and almost all active consumer software purchasers are on Intel machines running 10.5 or later.
The other thing that needs to be considered is that 10.4 is missing many APIs introduced in 10.5 and 10.6.
When I'm testing software I'm going to deploy or running through tests in the Windows world, I'll use VMWare images so that I can start from a fresh, known state at the beginning of each test. This has worked really well so that I can install software on different OS flavors or with other/different apps and drivers loaded. This makes it super simple to duplicate or nearly duplicate a customer's environment when addressing issues that crop up.
Now I'm tasked with doing something similar for Mac OS X. I'm far less familiar with this OS and didn't really see the same sort of thing available. I noted that the server version of 10.5 might allow this, but I'm not running that here. I've got access to 10.5 on a Mac Book and one of those Mac Minis.
Has anyone used Time Machine to put their test Mac box into a known state? Or do you have other ideas? I'm also interested in a solution for 10.4 since some of my customers run "Tiger".
I tend to test things that don't manipulate the global computer state (i.e. a lot of well written Cocoa applications) with the "Guest" account. Since Tiger (I think), the effects of using this account are wiped at logout, so you can easily get a virgin environment again.
By default, Time Machine excludes certain paths from backup. This could be detrimental to your testing strategy, depending on the system resources that your software touches. See this article for information on the exclusions. At a bare minimum, if you are going to use Time Machine to rollback, make sure nothing you are testing depends on any of the excluded files.
But, I think there is a better alternative, if you can live with Mac OS X Server: VMWare Fusion provides support for virtualizing instances of Mac OS X Server Leopard. Then you can use the same strategy you used for Windows.
From http://www.vmware.com/products/fusion/features.html
VMware Fusion boasts the most complete
OS support, supporting more than 60
operating systems in a virtual
machine, including Windows XP, Windows
Vista, and even Mac OS X Server.
Keep in mind, you cannot virtualize Mac OS X Client due to license restrictions, though.
An alternative (perhaps more lightweight) solution that I just found recently is an app called RooSwitch. It lets you swap configurations for an application. So you could have a bunch of different prefs files, cache files, etc for your app and create a named configuration for it. You can create multiple configurations to test new user setup, or to reproduce an issue using a customer's data without losing your own config. RooSwitch then lets you switch between all these different configs.
I haven't used it myself yet, but heard about it on a podcast recently and thought it sounded useful for my own development and testing.
I would like to test software designed to run on a Mac and would need a couple of OS versions (old ones, too) and maybe other Mac software to set up my (virtual) test machines.
For the same scenario on Windows, I can use the licenses available via TechNet or MSDN subscriptions. At the ADC Mac Dev Center, I couldn't find any specific information as to what is available. Does an ADC membership get me downloads of software / OS's to test against? If not, what is available?
Bear in mind that I don't believe any version of Mac OS (barring OS X Server) is licensed for use in a VM. In theory, if you want to test different versions of the OS you'll need to do either multiple installs on a single system (My first iMac came with OS 9 and OS X installed this way, not sure you could get multiple OS X versions installed on a single box) or have lots of boxes.
Yes it does. You can download the operating systems as well as betas (although not as early as "proper" beta testers).