> 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

Reply via email to