> We should not forget that Larry & Steve are said to > be old time friends. > Apple showed great interest on ZFS (as any other OS > vendor, be it interest or envy). Who knows what > caused the decision to drop it? Maybe Steve was aware > of next Solaris happenings?
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-October/033125.html So no, I don't think it was the good old boy network that killed ZFS (at least for now) on Apple. > I see no other reason why any OS vendor would drop > such an amazing technology. > > Darwin may even be solid, but moving OSX to an > OpenSolaris base would let Apple enter a much more > solid server market, and finally we would also have > an amazing desktop for Solaris as a client. > Just think about a bright future with companies > running: > - iDesktops with OSX on iSolaris (instead of > Windows) > - iDesktops running OpenOffice (iOffice?) on OSX > (instead of M$Office) > - iServers running iSolaris with all the server stuff > you can run on (instead of Windows servers). > - iStorage based on iSolaris+ZFS etc. etc. (in this > case you may have many other compatible choices) > > Would you still need to run Windows networks? > > Let's make a petition to Mr. Jobs. ;) I'd love it. But there would be some stiff problems: * OS X apps don't just use POSIX interfaces, they also use at least some Mach interfaces. Simulating those under (not so Open)Solaris might be tough. * even BSD drivers are different from Solaris drivers, although probably closer than anything else. But Mac OS X, although borrowing a lot from BSD, has a driver interface like nothing else: IOkit, an object oriented device driver environment, allowing (with limitations) drivers to be implemented in C++. So, not only would all drivers have to be massively rewritten, but each interface can probably do some things that the other can't (without a lot of work). * different object file format (although actually, Solaris is pretty extensible in that regard...would still take some work to be compatible, though) * radically different approach to graphics and audio; I don't even begin to know enough about the deep levels of how that works on a Mac, but again, it would take a lot to adapt that to a Solaris kernel Given the existing apps base for OS X, binary compatibility as well as comparable graphics and audio performance, would be critical, IMO. And those would be difficult indeed. I certainly understand the temptation, though. The Mac GUI apps and userland frameworks are generally pretty impressive. The XNU kernel though, isn't (IMO) anywhere near as robust as Solaris, and OS X doesn't have anything close to zfs (DTrace is also a bit lame there 'cause you have to be root to use it, last I checked); I've crashed my Mac a good deal more than I've crashed Solaris boxes (give or take messing around with my own kernel code), although both are better than Windows. And while the developer IDE is impressive, other tools to examine processes aren't so good; nothing quite like pmap, for instance (although I did stumble across something that gave some limited description of process address spaces, but not to the point of spelling out what was mapped where, stack, heap, etc); or like /proc (discounting the MacFUSE /proc, which I've never gotten to continue working). (On the plus side, OS X does actually include a supported port of lsof.) Another example: on Solaris, one can delete swap (assuming sufficient RAM to page in whatever is out there); there's no obvious way to do that on a Mac. OS X is generally good enough for a desktop (and the GUI goes a long way to making one want to forgive the weaknesses of the kernel), but I don't think it's really up for being a robust general purpose server...not beyond moderate loads of OS X specific services provided to OS X clients. Even for file service to Macs, I think I'd rather run recent netatalk on a zfs-based NAS (Nexenta or FreeBSD, maybe). (I'd like it even better if netatalk knew how to stick extra metadata and resource forks into named attributes (where available), rather than scattering ._* files around.) -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
