A French user has discovered that ZFS is now 'officially' supported in Leopard [French], while testing the latest build of Apple's upcoming operating system. Indeed it is now possible to create disk images or partitions formated in ZFS (screen capture included). However, it seems that it is not possible yet to install the OS on a ZFS partition.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-08-21
Speaking of OS X and filesystems, Slashdot recently had a thread going about Mac automated backup solutions. pesc brought up this gem: http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup-and-c... While the writeup is generally about backup software, it's goes into a lot of detail about how OS X handles metadata.
Brief synopsis: be glad you aren't in the business of making automatic backup software for Macs!
Member since:2006-12-16
If you decide to go ahead, drop me an e-mail. I've seriously thought about writing something like that myself.
Being a Linux guy myself, last September I bought a MacBookPro. I was on a hiatus using OSX for nearly two months non-stop. I thoroughly understand what you say about its kernel. The interface is very flashy and all, but seriously, its kernel is far worse than an unoptimized... I don't know what to compare it to.
Once I an on Linux (2.6 + CK) full time again, I feel I have unleashed the real power this machine has.
Tell me about leaving a lengthy CPU bound process like encoding an HDTV video with x264. You get a barely usable system on OSX, even nicing it +19. On Linux, I can keep doing that not only way faster than it was on OSX, but interactivity doesn't suffer at all.
I'd need to compile myself mplayer on OSX, tweaking it the way I do on Gentoo, to do a fair comparison. But still, the difference is awesome.
My 2˘.
Member since:2006-10-12
Encoding HDTV is a CPU-intensive process with a limited number of potential bottlenecks: simply pointing the finger at ‘the kernel’ isn't in the slightest bit useful, all told.
Realistically, there are only three real places that something like that could suffer: an I/O bottleneck (Linux could be more efficient at buffering than OS X), a memory-management issue (was XNU swapping when Linux wasn't, for example?), or a scheduling problem coupled with the two previous: for example, was there a resource over-allocation applied to the encoding process which makes task switches slower than they should be (i.e., causing a slow-down in both overall encoding performance and interactivity)?
What you really should be doing is profiling the encoder on both platforms to find out what's slowing it down: with a process that actually uses the kernel as infrequently is this, it wouldn't be particularly difficult to do and perform a real comparison.
Member since:2005-07-06
I'm afraid an article like that would just invite a flame-fest. But I'd be happy to summarize some of the most glaring problems that I've encountered.
1) The toolchain is just weird. If Apple was going to use the GNU toolchain, they should have done it properly, by adding support for Mach-O to BFD, and fixing the GNU tools so they could target Mach-O, just as they can target PEF for Windows. However, Apple chose to instead ship custom hacked-up versions of the GNU tools. While that is a solution, for people writing software, Darwin's "almost GNU but not really" toolchain is a complication that could've been avoided. In an ideal world, they would've used ELF like everyone else and avoided the problem entirely, but that's probably too much to ask.
2) Darwin's shared library infrastructure is... strange. Mach-O just isn't as clean a format as ELF. There are fairly arbitrary distinctions between loadable modules and shared libraries, restrictions on section types in dynamic libraries, etc. The linker is also slow, and startup of programs with extensive shared library dependencies is pokey.
3) The Mach/BSD API schism is not entertaining, to say the least. Their tracking of the FreeBSD API has stagnated since 5.x. Darwin is BSD... almost.
4) The system does not handle huge VM loads gracefully. Giant compiles won't even cause Linux to blink, while they'll cause Darwin to have very noticable hiccups.
5) I/O performance, and general system performance under high I/O loads is not steller.
6) Many primitive UNIX operations (process/thread creation, page-fault handling, etc) are much slower on Darwin than on Linux. This has been documented repeatedly, and extensively.
In the grand scheme of things, Darwin just isn't very good, at anything, except maybe low-latency audio. It just doesn't deliver what I'd expect from a modern, high-performance UNIX kernel. It's not as scalable as Solaris, its not as fast as Linux, its not as stable as FreeBSD, its not as clean and elegant as NetBSD, etc, etc, etc. It's merely "good enough", what Apple inherited when it bought NeXT, and what they surely realize is behind all of the major competition, but what they (rightly) think is not enough of a handicap in their target market to be worth the trouble of replacing.
Member since:2005-10-11
Member since:2005-07-06
Member since:
2005-10-12
"The longer I use OS X, the more it becomes painfully apparent how badly the kernel sucks...."
_______________________________
It would really be worth an article, if you can find the time, to explain this at reasonable length. Agree or disagree, it will certainly be worth careful reading. Hope you can find the time.