Tweet
It is likely important to consider that for anyone to sue anyone else they must have standing. A perceived violation of the Linux license by Canonical can only be pursued by the owners of Licensed code in the Linux Kernel. Therefore, the FSF can not sue Canonical for the violation as the Linux Kernel has not been turned over to the FSF as a GNU project. It is likely the only person in a position to pursue this would be Linus or one of the licensees of the affected subsystem. So while they may posture about this all they want, it really comes down to the opinions of the individuals enforcing the license not the author of the license.
-
-
Can someone explain something to me:
Other than maturity is there any reason to use ZFS over the hypothetical vision of what btrfs will be when complete and polished? I always thought btrfs was going to be as good as (if not better) than ZFS. However the recent resurgence of interest in ZFS has me wondering, especially as btrfs is getting better and better.Comment
-
Btrfs has 2-3 times slower scrub. Significant problem with large pools. It also has the write hole.Originally posted by Iksf View PostComment
-
Are these design problems though or just issues with the current implementation?Originally posted by caligula View PostComment
-
Originally posted by Iksf View Post
When you try to use IOMMU in KVM to pass a spare GPU and your filesystem is BTRFS, and KVM freezes, making you hard reset your computer, and BTRFS is more corrupt than its repair utilities are willing to repair, you realize that BTRFS is crap. Never had an issue with ZFS and I've had multiple drives die with ZFS. I've had plenty of issues with hardware RAID and Intel Matrix RAID as well, even kicking drives out of arrays when there is no problem with the drive, even when you're using enterprise disks. Switched my root FS to XFS and it not only repaired when I went on to make KVM freeze 5+ more times, it didn't need ANY kind of manual intervention to do so. And XFS is not even meant to be the most robust filesystem. My storage-specific partitions are ZFS and, again, I have never had an issue with it. The VMs I was trying to run were on ZFS, and that also was fine every time it froze.
As far as I'm concerned, ZFS is the only reliable and robust filesystem out there.
BTRFS may have improved since kernel 3.18 (which is when I had my above issues with it) but as far as I'm concerned it's not even alpha quality. Can't imagine I'll ever touch it again. Even if the problem I hit is now fixed, it was still said at the time that it was a safe choice to use, and it was not. I thus cannot trust anyone who suggests BTRFS to me, and I wouldn't suggest you do so, either. (I think it was 3.18.7 or so, if it matters more specifically.)
I fully admit that everything I just said is anecdotal, but I still think BTRFS would probably be better termed BTRFU.Last edited by Holograph; 12 April 2016, 04:22 PM.Comment
-
Current implementation. My guess is that e.g. Canonical doesn't want to fix those because btrfs is used by other Linux vendors (Red Hat, Facebook etc). They like NIH stuff more that standard Linux solutions.Originally posted by Iksf View PostComment
-
I agree with you about BTRFS. I wasn't even trying to do anything fancy with it, just a data drive with a mirror, and I had nothing but problems with it. Mind you this was a long time ago. I haven't given it a fair shot since then and I don't know if the status quo is the same or not. But like you my first impression of it was very bad.Originally posted by Holograph View PostComment
-
from http://blog.dustinkirkland.com/2016/...untu-1604.htmlOriginally posted by Holograph View Post
You'll find zfs.ko automatically built and installed on your Ubuntu systems. No more DKMS-built modules!
and from https://insights.ubuntu.com/2016/02/...ing-and-linux/ :
The CDDL cannot apply to the Linux kernel because zfs.ko is a self-contained file system module — the kernel itself is quite obviously not a derivative work of this new file system.
And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.Comment
-
Originally posted by Holograph View PostBit of a side point but I think this perhaps exposes a weakness of the open source model. You both seem prejudiced by your first experiences of the software, with the open source btrfs obviously being far from complete when first made available vs ZFS which was complete before being open sourced.I haven't given it a fair shot since then and I don't know if the status quo is the same or not. But like you my first impression of it was very bad.
Just an interesting note.
Comment
-
That's like putting a cart before the horse though, the horse is not going to push. Does this module link to the kernel? If it loads it must. The GPL is not about protecting developers rights on their code, it's about protecting users from having to rely on something they can't modify. The point is that no matter how simple or common the links may be, they are still to the kernel itself. Every binary driver that exists today in fact violates the GPL intended purpose. But people tolerate it on desktop linux because of package management. Personally I'm certain that people will tolerate ZoL as well in the same manner.Originally posted by k1l_ View PostComment
Comment