I'm not a coder. I couldn't create a kernel if my life depended on it. I couldn't code a hungry cat to catch a mouse. 1/2 or more of what I read in code is gibberish to me.
But, one thing is pretty sure. Linus Torvalds wrote Linux, and his programming background came directly from Unix. OF COURSE he is going to write the same commands he has used a thousand times in the same way. OF COURSE there are going to be lines that look very much the same, sometimes even identical.
Linus Torvalds started linux; out of the current code he authored a few percent. Linux is now massive, and this is a pretty large amount of it for one guy to have written, but his main job these days is on managing code submissions from others. This case is really unrelated to Torvalds; if submitted code was plagiarized he wouldn't have been responsible or known about it, and it's really fairly unrelated to Linux; if SCO were to have succeeded Linux wouldn't disappear, but certain companies like IBM, SGI, etc, would have needed to pay some cash and redo some code.
Torvalds is not on trial here.
Also, as a guy who had his own code plagiarized, I am very wary of special pleading to try and excuse such behavior. We need to look at the facts of the case; we can still use Linux (I do) and at the same time be completely, absolutely opposed to it being tainted with plagiarized code.
The truth is that code was reused (if not copied, exactly, in the same way you don't submit a copied essay which you've taken from a classmate) from a UNIX derivative, which is now (somewhat disputably) owned by SCO.
That is understandable (even if illegal and arguably inethical); there's a dying version of UNIX which no-one seems to be the definite owner of, why not reuse useful snippets from it for the sake of compatibility and efficiency? Well this whole mess is exactly why; when in doubt write your own goddamn code, always.
We should be just as mad at SGI and IBM for being lazy and careless as we are annoyed that a company like SCO exists only to litigate and not do anything useful.
But please do not try and excuse or downplay this behavior. Linux is not going away, and we want justice to always be done because next time it'll be some other company using code from Linux (or one of your projects).
These are not small words like "kissing" that are under dispute, this is not about reusing some very common routines that everyone uses, that's just silly. Rather it's about companies wanting to maintain compatibility with legacy versions of UNIX and doing so by referring directly to the legacy UNIX at best, and plagiarizing their code at worst.
Trying to imply that this is some nonsense that should be dismissed just because you like Linux is like playing down and ridiculing the evidence of the murder of Hans Reiser's wife because you like ReiserFS. It's even sillier in some ways because Linux isn't at stake in the case like ReiserFS was. (An extreme analogy I know, but valid).
Always support justice, always maintain strict ethics when using your code as you would expect others to for your own code. If everyone did that companies like SCO couldn't exist, and more money would go to coders and less to lawyers.
I'm afraid this isn't the strong case you're making it out to be. I can see from somebody who isn't familiar with standards how similar comments and identical function names could perhaps be considered copying. However, much of the code here is either directly taken from BSD or the headers are shared/copied on person for the sake of a standardized ELF implementation. Read more on ELF, but the gist is that IBM and a bunch of other UNIX vendors openly wanted a standard binary format to be shared across platforms so that it could be understood and linked in a conventional way. Now of course McBride is making some silly argument about how ELF wasn't IBM's to open for council, but there's a pretty le
I'm currently using a CF based root, but I've got a crappy celeron (Pentium III era) laptop running zfs root currently. It's balls slow, but that's really the laptops fault (and it only has 1GB of memory). I managed to do a portupgrade when the last portupgrade was done around FreeBSD 7. It finished just fine after a day or two (putting the CPU at full load for two days by compiling on a compressed zfs volume no less should be enough of a testament of its stability). I wouldn't have any experience with the USB problem as I've only made quick USB boot devices for recovery consoles when dealing with UFS dumping.
That, is a mistake. I strongly recommend you do some reading about the base requirements for ZFS on FreeBSD as well as its many shortcomings (at least compared to the OpenSolaris implementation).
Just a couple of the shortcomings I've hit against in the past couple months:
* stability issues. Even with the supposed "stable" 8 RELEASE and the 'required' ZFS tuning and hardware, I've had ZFS lock the system. It would appear the only significant difference between the 7.3 and 8 ZFS implementations is that in 8, they've removed the "EXPERIMENTAL!" warning on the opensolaris driver.
* boot mechanisms. There is no 'official' way to boot off a ZFS zpool, and all the ways that exist to get around that shortcoming are poor compromises, won't work from one release to another, or require use of unstable code (USB boot device, grub2, etc.)
* ZFS requires a *minimum* of 4GB of RAM for supposed stable operation. It will use that memory, even on an infrequently accessed file server. You will have stability issues with less, even with the recommended FreeBSD ZFS tweaking.
* Compared to Linux or OpenSolaris, FreeBSD stability - largely related to device drivers - is pathetic and amateur.
* A general "unprofessional asshole" attitude on the mailing lists. "I've discovered a bug, here it is" seems to result in things like "we're not going to fix that, we'll replace the system in the next release" or similar - if any response is made at all (admittedly, the only list I'm currently following is freebsd-usb).
* ALong those lines, the inclusion of incomplete/dysfunctional systems (presumably) simply on the basis of superior design.
Zones, however, would probably be pretty well implemented via jails. Those are cool. But ZFS is, IMO, not a good choice for picking FreeBSD. FreeBSD does a subset of things very well (networking, documentation, infrastructure design and naming), but ZFS is, unfortunately, not one of them (yet).
I'm very concerned that Oracle is going to kill ZFS off. It is one of the coolest, most useful things to come to storage in a long, long time. Hopefully the Linux folks can pull their pants up quickly and come out with something feature comparable.
What sort of hardware were you running this on? I did just fine with 4 disks and 64 bit hardware (very cheap 64 bit hardware). It was only when 4 disk became 12 disks did I need a faster processor, but now it's humming along just fine with a mini-ITX board. My dedicated intent log (single SSD) is actually being choked by the PCI bus right now, but apart from that I've seen flushes to disk of 465MB/sec and I run it stably for months on end. I eventually popped another 2GB of memory in the machine just because it was dirt cheap. I'm using an onboard crappy nforce controller, a Silicon image controller (can't remember the exact chipset, but it's a SATA3 based card), an adaptec SaS controller, and a really really garbage priced RocketRAID controller.
And since when did the GPT ZFS bootloader ever require grub2? You've been able to install a ZFS on root config for a long time now. The only thing to watch out for is the break in ABI between userland and kernel during a run of "freebsd-update". Ways around this include: building from source to update (not really that difficult), using a seperate cheap UFS root or special emergency console based environment, or booting into single user mode after the reboot and mounting the zfs partitions forcibly without using the zfs userland utilities (now supported).
I'm not trying to call you out on these things, I just want to know why your experience with FreeBSD is so much different than mine.
none, I prefer my operating system without a condom. It's more fun that way:). I also stripe without parity (mainly because I don't care what happens to my windows installations).
which affect everybody that make me consider more and more everyday to do egressive filtering on my external firewall. Granted, I'm usually the only one using my machine and I typically am careful with my browsing habits on any platform (linux, freebsd, solaris or windows; javascript can be nasty). Stuff like this makes me feel really vulnerable on my windows based machines, though.
Do we really want to add to the possibility of failure rates with more electronics in front of a given device? Surely there are much better caching technologies out there than can take advantage of SSDs, in both software and hardware.
Who said that it had to be write-through for it to sync to disk fully? Why not just do a full disk sync when powering down? Nobody said that the secondary cache had to be emptied, one can easily detect a dirtied page on the cache. The advantage of write back caching could still easily be felt while the operating system is booted and running. Either way none of these are as elegant a solution as separate volumes, anyway. Who knows how well this thing can even perform when doing the caching, does anybody have any realworld performance data for this?
Why not wait for the I/O to complete? And in the event of a software implementation, who said that it had to be cached at the block level? You could easily move both if they were NTFS formatted and see both in cache and out of cache contents. This largely relies on the type of implementation, of course, but you never see people using high end raid controllers saying "OH MAN, I CAN'T RISK THERE BEING UNFINISHED I/O ON THE NVRAM!". Either it gets committed or not.
One disadvantage that some people have sort of eluded to was what happens when this device fails? Is your data obtainable at that point? It certainly isn't in the even that a RAID controller fails (for the majority of them). You have an added loss of data integrity by doing this.
While I agree that vista is terrible and I could care less about windows 7, it is still implementable in XP. Even if nobody bothers to implement a utility to do this in software easily for XP (which can definitely be done with the win32 API using simple calls to generate "logical" folders without the need to even touch its driver API), why not put all the fast access stuff on the SSD and use hard disks for the bulky storage?
Also, in case you don't read the replies above (which I suspect you haven't because you haven't acknowledged this reply to any extent, ReadyDrive already allowed for this feature in software.
Even further research indicates that microsoft DID do that. ReadyDrive/ReadyBoost can use mulitple devices for on disk caching with their disk prefetching.
There is nothing new or impressive about this device.
Other than that it is compatible with applications and peripheral drivers designed to run on the majority operating system for home and office PCs, which has no support for ZFS.
There are a number of options:
Firstly:
Use a different machine with samba if you want to give the storage to your windows hosts. This option isn't for everybody, but over gigabit while it will be a third of the bandwidth with regular SATA, you definitely will notice the benefits (especially for async I/O, the dedicated slog device removes a lot of overhead).
Secondly:
It wouldn't be difficult to implement this as a software solution in windows to be quite honest. Caching models/algorithms are anything but complicated and one could easily write this in userspace or kernelspace. ZFS happens to do this on the file system layer, but it could easily be written on a much higher level of abstraction. There is nothing here that requires an ASIC design level of logic other than maybe freeing some bandwidth on your SATA bus for the bleeding in and out of cache to disk.
Thirdly: Microsoft wrote off a feature in vista for moving swap to a dedicated disk (although this was forever possible since windows 2000 simply by specifying a different "page file"). Who's to say that microsoft wouldn't add that to their storage API under the disk management MMC. I can easily see an "add cache device" option being feasibly done.
Or, you can just use ZFS and turn on the L2ARC, which will use the SSD as a cache for the hard disks and not need any custom hardware.
Exactly what I was thinking, I think you may have even beaten me to the post. This seems like something a good operating system can implement with relative ease without even needing a custom tailored filesystem to do so. Not that that doesn't help.
ZFS? Hybrid storage pools have been around for a long while, and exist as a pretty well balanced software solution to this problem. Hybrid solid-state/magnetic disks were in the market as well which used a similar technique. There is nothing new or impressive about this device.
IMHO F-Spot is absolutely garbage, and not because it's written in C# and requires mono libraries. It's absolute garbage because last I tried it (in 9.04) it would not even think of the option of renaming files on an import if there was a filename conflict between what's on your card/import source and what's already in your album. How often do cameras name pictures the same thing after you've reformatted the card? Or how often do you use different cameras which use the same naming conventions? The lackluster features in f-spot on top of it's inability to manage your tags easily make it garbage. It also has severe instability. If you ask me, digikam serves a much better purpose than F-spot ever did. If they can sacrifice the 100 or so MB for the QT libraries and throw digikam on there, they ought to (and ditch mono+f-spot while they're at it). For anything that digikam cannot do, I use GIMP on my Ubuntu machines.
Does. I'm actually the president of an organization that prominently supports and promotes free software (Laboratory for Recreational Computing).
http://pohl.ececs.uc.edu/
While Sun has finally come around on open source. They still seem to do it with trepidation and even hamper some of their own works. If IBM purchases them, hopefully that will change. I would love to see them take the cuffs off of Java, OpenSolaris, MySQL, and zfs. By cuffs, I mean different things about different projects. (licensing, open up development, etc)
ZFS is not under strict licensing or hampered in any way. The CDDL is not restricting it at all, it is the GPL that is not allowing it into the Linux kernel. Most of the BSD world has adopted ZFS with open arms, as well as Apple. I personally would not like to see Sun go, and as a student I'd like to take advantage of their OpenSPARC program while I still can.
instruct Gentoo users, why don't you just write an ebuild? After all, you did build this on Gentoo, why not add it into portage? There's not even an overlay!
Slashdot Mirror
gah, that's supposed to say "on purpose" not "on person".
I'm not a coder. I couldn't create a kernel if my life depended on it. I couldn't code a hungry cat to catch a mouse. 1/2 or more of what I read in code is gibberish to me.
But, one thing is pretty sure. Linus Torvalds wrote Linux, and his programming background came directly from Unix. OF COURSE he is going to write the same commands he has used a thousand times in the same way. OF COURSE there are going to be lines that look very much the same, sometimes even identical.
Linus Torvalds started linux; out of the current code he authored a few percent. Linux is now massive, and this is a pretty large amount of it for one guy to have written, but his main job these days is on managing code submissions from others. This case is really unrelated to Torvalds; if submitted code was plagiarized he wouldn't have been responsible or known about it, and it's really fairly unrelated to Linux; if SCO were to have succeeded Linux wouldn't disappear, but certain companies like IBM, SGI, etc, would have needed to pay some cash and redo some code.
Torvalds is not on trial here.
Also, as a guy who had his own code plagiarized, I am very wary of special pleading to try and excuse such behavior. We need to look at the facts of the case; we can still use Linux (I do) and at the same time be completely, absolutely opposed to it being tainted with plagiarized code.
The truth is that code was reused (if not copied, exactly, in the same way you don't submit a copied essay which you've taken from a classmate) from a UNIX derivative, which is now (somewhat disputably) owned by SCO.
That is understandable (even if illegal and arguably inethical); there's a dying version of UNIX which no-one seems to be the definite owner of, why not reuse useful snippets from it for the sake of compatibility and efficiency? Well this whole mess is exactly why; when in doubt write your own goddamn code, always.
We should be just as mad at SGI and IBM for being lazy and careless as we are annoyed that a company like SCO exists only to litigate and not do anything useful.
But please do not try and excuse or downplay this behavior. Linux is not going away, and we want justice to always be done because next time it'll be some other company using code from Linux (or one of your projects).
These are not small words like "kissing" that are under dispute, this is not about reusing some very common routines that everyone uses, that's just silly. Rather it's about companies wanting to maintain compatibility with legacy versions of UNIX and doing so by referring directly to the legacy UNIX at best, and plagiarizing their code at worst.
Trying to imply that this is some nonsense that should be dismissed just because you like Linux is like playing down and ridiculing the evidence of the murder of Hans Reiser's wife because you like ReiserFS. It's even sillier in some ways because Linux isn't at stake in the case like ReiserFS was. (An extreme analogy I know, but valid).
Always support justice, always maintain strict ethics when using your code as you would expect others to for your own code. If everyone did that companies like SCO couldn't exist, and more money would go to coders and less to lawyers.
I'm afraid this isn't the strong case you're making it out to be. I can see from somebody who isn't familiar with standards how similar comments and identical function names could perhaps be considered copying. However, much of the code here is either directly taken from BSD or the headers are shared/copied on person for the sake of a standardized ELF implementation. Read more on ELF, but the gist is that IBM and a bunch of other UNIX vendors openly wanted a standard binary format to be shared across platforms so that it could be understood and linked in a conventional way. Now of course McBride is making some silly argument about how ELF wasn't IBM's to open for council, but there's a pretty le
Here's the crappy machine I have running on ZFSRoot:
/ /tmp /usr /usr/ports /usr/ports/distfiles /usr/src
[adam@bsdtop ~]$ uptime
9:11AM up 48 days, 10:26, 2 users, load averages: 0.42, 0.31, 0.26
[adam@bsdtop ~]$ uname -a
FreeBSD bsdtop 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Wed May 26 05:45:12 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
[adam@bsdtop ~]$ zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
ad0s1d ONLINE 0 0 0
errors: No known data errors
[adam@bsdtop ~]$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 4.32G 31.1G 18K none
tank/root 27.9M 31.1G 27.9M
tank/tmp 18.0M 31.1G 18.0M
tank/usr 3.66G 31.1G 2.15G
tank/usr/ports 1.22G 31.1G 346M
tank/usr/ports/distfiles 905M 31.1G 905M
tank/usr/src 299M 31.1G 299M
tank/var 626M 31.1G 626M
/var
[adam@bsdtop ~]$ dmesg | grep -i celeron
CPU: Intel Celeron (896.69-MHz 686-class CPU)
I'm currently using a CF based root, but I've got a crappy celeron (Pentium III era) laptop running zfs root currently. It's balls slow, but that's really the laptops fault (and it only has 1GB of memory). I managed to do a portupgrade when the last portupgrade was done around FreeBSD 7. It finished just fine after a day or two (putting the CPU at full load for two days by compiling on a compressed zfs volume no less should be enough of a testament of its stability). I wouldn't have any experience with the USB problem as I've only made quick USB boot devices for recovery consoles when dealing with UFS dumping.
We're moving the OpenSolaris installs to FreeBSD
That, is a mistake. I strongly recommend you do some reading about the base requirements for ZFS on FreeBSD as well as its many shortcomings (at least compared to the OpenSolaris implementation).
Just a couple of the shortcomings I've hit against in the past couple months:
* stability issues. Even with the supposed "stable" 8 RELEASE and the 'required' ZFS tuning and hardware, I've had ZFS lock the system. It would appear the only significant difference between the 7.3 and 8 ZFS implementations is that in 8, they've removed the "EXPERIMENTAL!" warning on the opensolaris driver. * boot mechanisms. There is no 'official' way to boot off a ZFS zpool, and all the ways that exist to get around that shortcoming are poor compromises, won't work from one release to another, or require use of unstable code (USB boot device, grub2, etc.) * ZFS requires a *minimum* of 4GB of RAM for supposed stable operation. It will use that memory, even on an infrequently accessed file server. You will have stability issues with less, even with the recommended FreeBSD ZFS tweaking. * Compared to Linux or OpenSolaris, FreeBSD stability - largely related to device drivers - is pathetic and amateur. * A general "unprofessional asshole" attitude on the mailing lists. "I've discovered a bug, here it is" seems to result in things like "we're not going to fix that, we'll replace the system in the next release" or similar - if any response is made at all (admittedly, the only list I'm currently following is freebsd-usb). * ALong those lines, the inclusion of incomplete/dysfunctional systems (presumably) simply on the basis of superior design.
Zones, however, would probably be pretty well implemented via jails. Those are cool. But ZFS is, IMO, not a good choice for picking FreeBSD. FreeBSD does a subset of things very well (networking, documentation, infrastructure design and naming), but ZFS is, unfortunately, not one of them (yet).
I'm very concerned that Oracle is going to kill ZFS off. It is one of the coolest, most useful things to come to storage in a long, long time. Hopefully the Linux folks can pull their pants up quickly and come out with something feature comparable.
What sort of hardware were you running this on? I did just fine with 4 disks and 64 bit hardware (very cheap 64 bit hardware). It was only when 4 disk became 12 disks did I need a faster processor, but now it's humming along just fine with a mini-ITX board. My dedicated intent log (single SSD) is actually being choked by the PCI bus right now, but apart from that I've seen flushes to disk of 465MB/sec and I run it stably for months on end. I eventually popped another 2GB of memory in the machine just because it was dirt cheap. I'm using an onboard crappy nforce controller, a Silicon image controller (can't remember the exact chipset, but it's a SATA3 based card), an adaptec SaS controller, and a really really garbage priced RocketRAID controller. And since when did the GPT ZFS bootloader ever require grub2? You've been able to install a ZFS on root config for a long time now. The only thing to watch out for is the break in ABI between userland and kernel during a run of "freebsd-update". Ways around this include: building from source to update (not really that difficult), using a seperate cheap UFS root or special emergency console based environment, or booting into single user mode after the reboot and mounting the zfs partitions forcibly without using the zfs userland utilities (now supported). I'm not trying to call you out on these things, I just want to know why your experience with FreeBSD is so much different than mine.
none, I prefer my operating system without a condom. It's more fun that way :). I also stripe without parity (mainly because I don't care what happens to my windows installations).
It's likely that they don't want to store the butt tons of mpeg-2 video without compressing the streams first.
which affect everybody that make me consider more and more everyday to do egressive filtering on my external firewall. Granted, I'm usually the only one using my machine and I typically am careful with my browsing habits on any platform (linux, freebsd, solaris or windows; javascript can be nasty). Stuff like this makes me feel really vulnerable on my windows based machines, though.
The feature he is describing is actually somewhat useful in the instance that you are cloning from one image to the other.
You setup cachefs in linux.
Do we really want to add to the possibility of failure rates with more electronics in front of a given device? Surely there are much better caching technologies out there than can take advantage of SSDs, in both software and hardware. Who said that it had to be write-through for it to sync to disk fully? Why not just do a full disk sync when powering down? Nobody said that the secondary cache had to be emptied, one can easily detect a dirtied page on the cache. The advantage of write back caching could still easily be felt while the operating system is booted and running. Either way none of these are as elegant a solution as separate volumes, anyway. Who knows how well this thing can even perform when doing the caching, does anybody have any realworld performance data for this?
One disadvantage that some people have sort of eluded to was what happens when this device fails? Is your data obtainable at that point? It certainly isn't in the even that a RAID controller fails (for the majority of them). You have an added loss of data integrity by doing this.
While I agree that vista is terrible and I could care less about windows 7, it is still implementable in XP. Even if nobody bothers to implement a utility to do this in software easily for XP (which can definitely be done with the win32 API using simple calls to generate "logical" folders without the need to even touch its driver API), why not put all the fast access stuff on the SSD and use hard disks for the bulky storage?
Also, in case you don't read the replies above (which I suspect you haven't because you haven't acknowledged this reply to any extent, ReadyDrive already allowed for this feature in software.
Even further research indicates that microsoft DID do that. ReadyDrive/ReadyBoost can use mulitple devices for on disk caching with their disk prefetching.
There is nothing new or impressive about this device.
Other than that it is compatible with applications and peripheral drivers designed to run on the majority operating system for home and office PCs, which has no support for ZFS.
Do you not remember the hybrid SSDs that were touted at the beginning of SSDs inception? http://en.wikipedia.org/wiki/Hybrid_drive
There are a number of options: Firstly: Use a different machine with samba if you want to give the storage to your windows hosts. This option isn't for everybody, but over gigabit while it will be a third of the bandwidth with regular SATA, you definitely will notice the benefits (especially for async I/O, the dedicated slog device removes a lot of overhead). Secondly: It wouldn't be difficult to implement this as a software solution in windows to be quite honest. Caching models/algorithms are anything but complicated and one could easily write this in userspace or kernelspace. ZFS happens to do this on the file system layer, but it could easily be written on a much higher level of abstraction. There is nothing here that requires an ASIC design level of logic other than maybe freeing some bandwidth on your SATA bus for the bleeding in and out of cache to disk. Thirdly: Microsoft wrote off a feature in vista for moving swap to a dedicated disk (although this was forever possible since windows 2000 simply by specifying a different "page file"). Who's to say that microsoft wouldn't add that to their storage API under the disk management MMC. I can easily see an "add cache device" option being feasibly done.
Or, you can just use ZFS and turn on the L2ARC, which will use the SSD as a cache for the hard disks and not need any custom hardware.
Exactly what I was thinking, I think you may have even beaten me to the post. This seems like something a good operating system can implement with relative ease without even needing a custom tailored filesystem to do so. Not that that doesn't help.
ZFS? Hybrid storage pools have been around for a long while, and exist as a pretty well balanced software solution to this problem. Hybrid solid-state/magnetic disks were in the market as well which used a similar technique. There is nothing new or impressive about this device.
IMHO F-Spot is absolutely garbage, and not because it's written in C# and requires mono libraries. It's absolute garbage because last I tried it (in 9.04) it would not even think of the option of renaming files on an import if there was a filename conflict between what's on your card/import source and what's already in your album. How often do cameras name pictures the same thing after you've reformatted the card? Or how often do you use different cameras which use the same naming conventions? The lackluster features in f-spot on top of it's inability to manage your tags easily make it garbage. It also has severe instability. If you ask me, digikam serves a much better purpose than F-spot ever did. If they can sacrifice the 100 or so MB for the QT libraries and throw digikam on there, they ought to (and ditch mono+f-spot while they're at it). For anything that digikam cannot do, I use GIMP on my Ubuntu machines.
Does. I'm actually the president of an organization that prominently supports and promotes free software (Laboratory for Recreational Computing). http://pohl.ececs.uc.edu/
reappear in front of the team one day, with bloodstain and mud all over his body, and yelled "I'm single, AGAIN!".
Hans Reiser?
purchased. Too bad I'm at work, can't wait to give it a shot on a linux box. Wonder if it will work in freebsd with linux binary compatibility.
While Sun has finally come around on open source. They still seem to do it with trepidation and even hamper some of their own works. If IBM purchases them, hopefully that will change. I would love to see them take the cuffs off of Java, OpenSolaris, MySQL, and zfs. By cuffs, I mean different things about different projects. (licensing, open up development, etc)
ZFS is not under strict licensing or hampered in any way. The CDDL is not restricting it at all, it is the GPL that is not allowing it into the Linux kernel. Most of the BSD world has adopted ZFS with open arms, as well as Apple. I personally would not like to see Sun go, and as a student I'd like to take advantage of their OpenSPARC program while I still can.
instruct Gentoo users, why don't you just write an ebuild? After all, you did build this on Gentoo, why not add it into portage? There's not even an overlay!