Ten Reasons To *NOT* Use ZFS (Sun's new filesystem)

[[H]omer]

In response Sun Microsystems' announcement of the release of their new
"blazingly fast" filesystem, ZFS.

http://www.sun.com/2004-0914/feature/

Ten Reasons To *NOT* Use ZFS:

1. The License (CDDL) "has some complex restrictions that make it
incompatible with the GNU GPL"

http://www.gnu.org/philosophy/license-list.html

2 . ZFS does not support the necessary extended attributes and ACLs to
enable the implementation of SELinux security. Instead Sun prefers the
deployment of its own security software "Trusted Solaris", which is
not FOSS and runs at a cost of "$995 per seat for the Standard Edition
Desktop System to $79,495 for the Certified Edition Data Center
Server."

http://www.eweek.com/article2/0,1895,1641823,00.asp

3. This is primarily a Solaris product, and has nothing whatsoever to
do with Linux. The possibility of future Linux support cannot be ruled
out, however - at what cost - both in financial *and* license terms?

4. This is a product for the server room, not the desktop. The main
bottleneck on a desktop system is the underlying storage hardware
itself, not the filesystem. If you have the budget and requirements
for a Solaris server, then buy a Solaris server, otherwise there are a
myriad of other (IMHO) better solutions. Remember, Trusted Solaris is
not Open Solaris.

5. Linux already has a (arguably) superior filesystem in the form of
Reiser4, which is much more extensible and uses a dancing trees
system, which in itself is a great improvement over the old block tree
method employed by ZFS. Yes Reiser4 does not currently support SELinux
extensions either, but then the book's not closed on Reiser4
development, and it *is* Free, after all.

6. ZFS is a product of Sun Microsystems, developers of Sun Java. The
distribution license for Sun Java has caused so much controversy over
at Debian that they're threatening to pull the package from non-free
and even dissociate with Sun's legal team, the SPI. Sun Java is
subject to draconian export restrictions imposed by the US government,
against any country not favoured by the US, and its DLJ dictates that
"you do not combine, configure or distribute the Software to run in
conjunction with any additional software that implements the same or
similar functionality or APIs as the Software"

http://download.java.net/dlj/DLJ-v1.1.pdf

This would preclude distributing GNU GCJ and Sun Java on the same
system. Do you really want Sun dictating to you what software you have
on your computer?

Do you really want software from this company on your system? Frankly
you might just as well install Microsoft Windows and be done with it.

7. Sun is claiming all kinds of performance benchmarks, but the
"blazing performance" has yet to be independently verified, and few
comparisons exist between ZFS and any other high performance
filesystem. Ultimately Sun are motivated by money, not integrity, so
if their motivations are questionable, then so are their claims.

8. Despite their rivalry and even previous court battles, Sun is
rather too close to Microsoft for comfort.

"A year ago you could say we were moving from the courtroom and
entering the computer lab," Ballmer said, summing up the rivals'
progress. "Twelve months later I think we're poised, thanks to the
work of hundreds of engineers on both sides, to leave the computer lab
and enter the market place together."

http://www.internetnews.com/dev-news/article.php/3504976

9. After SCO made ridiculous claims about being the owner of Linux IP,
Sun apparently agreed with them, since they entered into a business
agreement to license Unix from SCO.

http://www.newsfactor.com/perl/story/21894.html

10. 64 bit architectures have been around for years, and are in fact
virtually mainstream these days, and yet Sun (having released a 64 bit
version of Java) have yet to release a 64 bit Mozilla plugin for it, to
enable Java Applets on Gecko based browsers. The Linux AMD64
self-extracting file of Sun Java JDK (jdk-1_5_0_07-linux-amd64.bin) is
some 41.76 MB ... the missing plugin (libjavaplugin_oji.so) is only
*77 bytes* !!!

And *why* does Sun refuse to include a tiny 77 byte Mozilla plugin
with their 64bit Java? Because, apparently, they think that there are
no 64bit versions of any Gecko browsers available, or to be more
precise, because Mozilla does not distribute a 64bit binary
upstream???

A company that employs such retarded logic, and has such a slow
response to technological change, cannot be trusted to keep pace with
changing hardware trends in other sectors of the market, such as
storage hardware for example. Imagine that you had paid a considerable
amount for new storage solutions, either at home or at work, only to
discover that Sun's "blazingly fast" filesystem was completely
unsupported on that hardware. How long might you have to wait for your
($995 - $79,495) Trusted Solaris with ZFS to be redeployed?

I used to be under the impression (or at least ever hopeful) that Sun
might one day wake up to the FOSS trends in the industry, and
reconsider their licensing and methods, but with each new announcement
from Santa Carla they just get worse.

--
K.

[Tim Smith]

In article <tpcpm3-...@sky.matrix>, [H]omer wrote:
> Ten Reasons To *NOT* Use ZFS:

...

> 5. Linux already has a (arguably) superior filesystem in the form of
> Reiser4, which is much more extensible and uses a dancing trees system,
> which in itself is a great improvement over the old block tree method
> employed by ZFS. Yes Reiser4 does not currently support SELinux

How do you know ZFS is using the "old block tree method"?

...

> 6. ZFS is a product of Sun Microsystems, developers of Sun Java. The
> distribution license for Sun Java has caused so much controversy over at
> Debian that they're threatening to pull the package from non-free and even
> dissociate with Sun's legal team, the SPI. Sun Java is subject to
> draconian export restrictions imposed by the US government, against any
> country not favoured by the US, and its DLJ dictates that "you do not
> combine, configure or distribute the Software to run in conjunction with
> any additional software that implements the same or similar functionality
> or APIs as the Software"

Did you mix up two editor buffers while writing this post? The above
doesn't seem to have anything to do with ZFS. Or are you laboring under the
weird notion that ZFS is implemented in Java?

...

> 10. 64 bit architectures have been around for years, and are in fact
> virtually mainstream these days, and yet Sun (having released a 64 bit
> version of Java) have yet to release a 64 bit Mozilla plugin for it, to
> enable Java Applets on Gecko based browsers. The Linux AMD64
> self-extracting file of Sun Java JDK (jdk-1_5_0_07-linux-amd64.bin) is
> some 41.76 MB ... the missing plugin (libjavaplugin_oji.so) is only *77
> bytes* !!!
>
> And *why* does Sun refuse to include a tiny 77 byte Mozilla plugin with
> their 64bit Java? Because, apparently, they think that there are no 64bit
> versions of any Gecko browsers available, or to be more precise, because
> Mozilla does not distribute a 64bit binary upstream???

Another case of editor buffer mix up?

--
--Tim Smith

[[H]omer]

Tim Smith wrote:
> In article <tpcpm3-...@sky.matrix>, [H]omer wrote:

>> Ten Reasons To *NOT* Use ZFS:
> ...
>> 5. Linux already has a (arguably) superior filesystem in the form
>> of Reiser4, which is much more extensible and uses a dancing trees
>> system, which in itself is a great improvement over the old block
>> tree method employed by ZFS. Yes Reiser4 does not currently support
>> SELinux

> How do you know ZFS is using the "old block tree method"?

Because Jeff Bonwick, Sun's team leader for ZFS, told me:

http://blogs.sun.com/roller/page/bonwick?entry=seek_hole_and_seek_data

>> 6. ZFS is a product of Sun Microsystems, developers of Sun
>> Java. The distribution license for Sun Java has caused so much
>> controversy over at Debian that they're threatening to pull the
>> package from non-free and even dissociate with Sun's legal team,
>> the SPI. Sun Java is subject to draconian export restrictions
>> imposed by the US government, against any country not favoured by
>> the US, and its DLJ dictates that "you do not combine, configure or
>> distribute the Software to run in conjunction with any additional
>> software that implements the same or similar functionality or APIs
>> as the Software"

> Did you mix up two editor buffers while writing this post? The
> above doesn't seem to have anything to do with ZFS. Or are you
> laboring under the weird notion that ZFS is implemented in Java?

Did you mix up your reading glasses with your beer glasses, or has
your terminal case of Alzheimer's caused you to forget the following
line?:

>> Do you really want software from this company on your system?

I was, as if I should need to spell it out for you, making the point
that a company that distributes software under such restrictions, is
not the sort of company I would want to obtain software from, be it
Java, ZFS, or anything else. I would hope that others agree, which is
why I asked that (albeit rhetorical) question.

>> 10. 64 bit architectures have been around for years, and are in
>> fact virtually mainstream these days, and yet Sun (having released
>> a 64 bit version of Java) have yet to release a 64 bit Mozilla
>> plugin for it, to enable Java Applets on Gecko based browsers. The
>> Linux AMD64 self-extracting file of Sun Java JDK
>> (jdk-1_5_0_07-linux-amd64.bin) is some 41.76 MB ... the missing
>> plugin (libjavaplugin_oji.so) is only *77 bytes* !!!
>>
>> And *why* does Sun refuse to include a tiny 77 byte Mozilla plugin
>> with their 64bit Java? Because, apparently, they think that there
>> are no 64bit versions of any Gecko browsers available, or to be
>> more precise, because Mozilla does not distribute a 64bit binary
>> upstream???

> Another case of editor buffer mix up?

Maybe you just have a really short attention span, or maybe you just
don't comprehend the fundamental principles of language, such as
paragraphs.

Here's the punchline you failed to read:

>> A company that employs such retarded logic, and has such a slow
>> response to technological change, cannot be trusted to keep pace
>> with changing hardware trends in other sectors of the market, such
>> as storage hardware for example.

There's more, if you can find your glasses (or even your spectacles)
to read it.

You might even be able to make the quantum leap from the concept of
"storage hardware" to the concept of "filesystems", without prompting
... if you squeeze your eyes shut and push your brain to its limits.

Oops.

--
K.
http://slated.org - Slated, Rated & Blogged

Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.16-1.2133_FC5
09:01:05 up 4 days, 9:17, 2 users, load average: 0.03, 0.01, 0.00

[Tim Smith]

In article <jevpm3-...@sky.matrix>, [H]omer wrote:
>> How do you know ZFS is using the "old block tree method"?
>
> Because Jeff Bonwick, Sun's team leader for ZFS, told me:
>
> http://blogs.sun.com/roller/page/bonwick?entry=seek_hole_and_seek_data

All it says there is that they are using a block tree. It doesn't say it is
the same old one that is used on other filesystems. There are a lot of ways
to do a block tree.

> I was, as if I should need to spell it out for you, making the point that
> a company that distributes software under such restrictions, is not the
> sort of company I would want to obtain software from, be it Java, ZFS, or
> anything else. I would hope that others agree, which is why I asked that
> (albeit rhetorical) question.

It's odd that you are posting in a Linux group, but apparently are unaware
of open source, and its advantages. See, with open source software, we have
no reason to care what Sun has done with Java, or anything else. If we are
looking at ZFS, we can find out everything we need to know from it and its
license.

--
--Tim Smith