OpenZFS Merged to FreeBSD
svnweb.freebsd.org
svnweb.freebsd.org
There are many places where it would be almost impossible to achieve this kind of share. Witness the 'compatability library' work which exists to avoid ABI blackholes running one platforms code on another platform.
BTW I have been able to carry FreeBSD ZFS LUN on a NetAPP and mount them on Debian ZFS, and vice-versa, since I started using ZFS. What we got here is better code alignment but with qualifications, ZFS has always been a common platform (with fringing differences)
I never had illumos or Solaris, I cannot comment on how well it would have worked.
> told workers in September 2006 to cut the beams that supported (his tenant's) apartment's floor... They also shut off Morrow's electricity, cut his phone line and had workers saw a hole in his living room floor from below, prosecutors said.
So yes, he has really refined leadership qualities!
https://www.sfgate.com/bayarea/article/S-F-landlords-charged...
Whatever does a rental property issue have to do with OpenZFS? What about political contributions? Are you genuinely unaware of all the crazy witchhunts, totally unrelated to the code base, that have occurred as a result of this CoC push? Have you ever heard of ESR? http://esr.ibiblio.org/?p=8609
Not much (though I think it's fair to say that when someone is praised for their "refined leadership" it's talking about more than just the quality of their code). In any case, "that other guy also said something irrelevant" isn't really to the point.
> What about political contributions?
What about them?
> Are you genuinely unaware of all the crazy witchhunts [...] this CoC push?
My confusion is because so far as I can see "this CoC push" has nothing to do with anything here, it's just something you want to talk about. The OP isn't about CoCs. The thread you replied to isn't about CoCs. The comment you replied to isn't about CoCs. Kip Macy's mistreatment of his tenants isn't about CoCs, or caused by CoCs, or prohibited by CoCs. The OpenZFS merge isn't about CoCs. (Well, quite possibly the OpenZFS project and/or the FreeBSD project have them, but so what?)
> Have you ever heard of ESR?
Yes. I don't look to him for political guidance, though.
(Two other things, besides codes of conduct, that have nothing to do with anything in this discussion aside from your apparent wish to talk about them: political contributions, and Eric Raymond.)
> Kip Macy is accused of three felony conspiracy charges, three burglary charges, two stalking charges, two grand theft charges and one felony count of shutting off service
This was big news in SF Bay Area when it happened. It was FreeBSD's Hans Reiser moment.
Another gem, Kip kicked one tenant in the chest while he was sitting on the couch and threatened him with a gun.
I am curious if he ever reimbursed his parents after they drained their retirement savings and offered their house as collateral to pay for his $500k bail, which was forfeited after Kip and his wife Nicole decided to skedaddle to Europe instead of appearing in court. Kip continued to work on FreeBSD while on the lam in Italy with full knowledge of the core team, with many members actually defending his behavior. Kip and Nicole also never showed for the civil trial and lost by default.
The original plea deal offered by the DA, before they absconded, was 6 months in county jail with charges reduced to misdemeanors. Instead, both were sentenced for 4 felonies and got 4.5 years (reduced for good behavior), with Kip ending up in San Quentin -- a maximum security prison housing California's death row.
I remember ABC News did an interview with Kip while he was incarcerated and he blamed his tenants for all his troubles. At least he can no longer (legally) possess a gun since he is a convicted felon.
https://abcnews.go.com/US/exclusive-landlord-hell-defends-te...
In all honesty I can't understand why would anyone use anything other than zfs nowadays for important data.
At a personal level, I opted out of it based on simplicity and familiarity. If I have a data drive where I need to move and mount in another box, I do not want to mess with the complexities of supporting ZFS to get at that data or the risk that the only OS I have available can't read it.
Again, this is a non-commercial environment, but I consider my data important as well. I've decided to go the route of keeping multiple backups of my data spread across multiple drives. I've already experienced bitrot several times over the years, but for me, this approach is more practical than relying on ZFS.
(And somebody's probably going to correct my ignorance and point out that beyond some release 'x', the ZFS stuff is already built-in.)
For me ZFS has been rock solid, even with power cuts during running vms(linux and windows) and a scrub.
I even managed to steal away enough ram from a server so that ZFS produced a stacktrace in dmesg, no data corruption, even on running vms.
I haven't done this to recover ZFS as written by Linux or Solaris/illumos, not sure how well that works but wouldn't be surprised if it does.
Why people aren't just using ZFS (or BTRFS) ?
Well...
Maybe because XFS is well proven in certain critical environments, especially ones which might involve frequent manipulations of large quantities of small files (think mailserver or database). Indeed, some developers will tell you in the docs that they only support XFS or ext4 and that you're on your own if you choose something else.
Maybe because ZFS and BTRFS still have their bugs, small and big (hello RAID5 in BTRFS ;-) ) and can be heavily dependent on particular implementations.
Maybe because in a virtualised environment, you loose many of the benefits of ZFS or BTRFS (they like to see the raw disk, not some abstract notation).
Maybe because the combination of XFS/ext4 plus LVM is more than good enough for most people as that route still provides snapshots etc.
Maybe because BTRFS needs babysitting[1] (don't know about ZFS, I suspect it might).
Maybe because not everyone feels the need to "keep up with the Jonses".
If I had to pick one place to put precious data that I needed to access for 10-20 years, ZFS would be it. Of course, I wouldn't put it in one place, so if I picked places to put that data, ZFS would definitely be one of them.
I've been using ZFS for over a decade, both for my personal storage systems and for work (largely backup servers), and despite heavy use and abuse, I've never once had data loss while using it. I've had some white-knuckle times, but in the end ZFS was able to recover all the data.
I say "abuse" because I was able to write a stress test program based on my usage that uncovered several ZFS+FUSE issues early in that port.
Just a data point.
The one time I lost data from a ZFS system (which was a faulty controller silently writing garbage to multiple disks in the array), ZFS told me exactly which few files were uncorrectable, and I was able to restore them from backup.
Not one single second of doubt as to which storage system I want my data on.
With btrfs you're still waiting for stuff to be properly implemented.
Redhat gave up on waiting, and is removing btrfs as a supported option in RHEL. Mostly, I assume, because the btrfs team has yet to ship something anyone in enterprise would be comfortable betting their customers' data on.
A) ZFS-on-Linux was always behind BSD ZFS until recently.
B) The license issue, so you have to compile it as a separate module using DKMS, which means having a compiler, the linux headers, etc etc. No where near as low friction as just choosing ext4 or btrfs.
Sure, but the sort of people who need ZFS are the same sort of people who are doing their storage on a SAN, and so the sort of people for whom choice of OS (for the SAN itself) can be contingent on choice of storage layer, rather than the other way around.
This is half the reason ZFS-on-Linux didn't have much momentum: most ZFS deployments were happy to just run BSD on their SAN, then serve SAN volumes out over the network (or into a hypervisor cluster) for Linux systems to consume.
FreeBSD was never really working on ZFS in a way ZOL was. Whole reason for the switch is because main contributor upstream used by FreeBSD stopped using ZFS.
ZOL had more features for a while now as well.
BTRFS is a science experiment by comparison. They tried to copy zfs features because Oracle won't release it under GPL and did a fairly poor job of it. The fact we're this many years later and their RAID5 code still has total data loss bugs pretty much sums up btrfs.
I managed to extract most of my data to another disk on another system, but it was pretty shocking. I haven't seen unfixable filesystem corruption like that since ext2 in 2001. I'd completely forgotten it was a thing, but there I was in 2019 trying to use a second linux box to salvage my data.
Of course, whenever I mention this the btrfs zealots always come out of the woodwork saying "you must not know what you're doing if you broke btrfs" or "you obviously didn't really try if you couldn't get it fixed" or a half-dozen other excuses, but in the end I've just completely given up on btrfs. It's just not worth the hassle.
It's just... Snapshot thing and replication (zfs send) are so damn easy in zfs...
> Maybe because XFS is well proven in certain critical environments, especially ones which might involve frequent manipulations of large quantities of small files (think mailserver or database). Indeed, some developers will tell you in the docs that they only support XFS or ext4 and that you're on your own if you choose something else.
XFS is great, except it doesn't do any of the things that ZFS does well. For example: snapshots (to the fantastic extent that ZFS does), multi-volume support, shared storage pooling, etc. The only thing XFS offers that ZFS doesn't is support for reflink copies on Linux (i.e. "cp -R --reflink=always src dst" for near-instantaneous copies of large directories with no extra disk usage).
> Maybe because ZFS and BTRFS still have their bugs, small and big (hello RAID5 in BTRFS ;-) ) and can be heavily dependent on particular implementations.
ZFS has been, in my experience, amazingly bug-free over the last however long I've been using it (5 years in production, more personally). ZFS has working and reliable RAID support; only BTRFS is lacking it.
BTRFS, on a stock Ubuntu install with default settings, corrupted after a power outage, and could only recover most of my data, but not all. I haven't had filesystem-related data loss since ext2 in 2001.
Also, for everyone except people running Solaris, there is (now) effectively one implementation, and it works fine.
> Maybe because in a virtualised environment, you loose many of the benefits of ZFS or BTRFS (they like to see the raw disk, not some abstract notation).
You still get point-in-time snapshots on a copy-on-write filesystem, which can support different block sizes per subvolume, on-the-fly compression, and incremental or full exports, all from a shared, extendable storage pool. Those alone are huge enough to justify it for me.
ZFS wants to see the underlying disks so that it can make sane judgements about block allocation, alignment, etc. On a VM, that shouldn't matter, because your host filesystem/SAN/etc. should be doing that anyway.
> Maybe because the combination of XFS/ext4 plus LVM is more than good enough for most people as that route still provides snapshots etc.
LVM snapshots are awful from a performance standpoint.
In ZFS, when you create a snapshot, any new data is written to new blocks (read the old block, make the change, write it to the new block), so your snapshot points to the old blocks on disk.
From what I can tell[1], LVM snapshots mean that when you write data to a block, LVM reads that block, writes it somewhere else, and then updates the original block in-place. This makes every write a synchronous write, because you have to write the old data to its new block, sync to make sure it actually gets stored, and then do your new write.
BTRFS snapshots cannot be recursive (i.e. you cannot snapshot /data/ and /data/gitlab and /data/svn and /data/backups atomically). They argue that this is a feature, but I would consider it a massive bug. LVM snapshots by their nature are not recursive because LVM has no concept that I can find of nesting.
> Maybe because BTRFS needs babysitting[1] (don't know about ZFS, I suspect it might).
ZFS, as far as I can tell, does not need babysitting. I used it for storing backups at my last job; we had a QNAP NAS exporting over iSCSI, ZFS was using the iSCSI storage, and we wrote data to it. Nothing ever went wrong, and I literally never checked on it unless the power went out or something of the sort. It was three years before I ever got around to setting up monitoring for it, because literally nothing ever went wrong so I completely forgot that there was anything to monitor. Eventually I did set it up, but it never went off. Literally set it and forget it.
In summary: ZFS is fantastic, and basically never needs to be taken care of. It does its thing and it works great, and that's it. BTRFS has corrupted itself arbitrarily after a power outage (which I thought we'd solved with ReiserFS back in 2001), LVM snapshots are slow and awful, and the tooling for LVM and BTRFS is a usability disaster while also losing a lot of features that ZFS has (like on-the-fly compression, block deduplication, etc.).
> Maybe because in a virtualised environment, you loose many of the benefits of ZFS or BTRFS (they like to see the raw disk, not some abstract notation).
ZVOL exist...You can snapshot, close, send/recv it just like dataset. You can fine-tune it like any other dataset. ZVOL works just fine for VMs.
> Maybe because ZFS and BTRFS still have their bugs, small and big (hello RAID5 in BTRFS ;-) ) and can be heavily dependent on particular implementations.
Everything has bugs. Again, you put BTRFS here just to drive your point like if it's try BTRFS then it's true for ZFS?
> Maybe because BTRFS needs babysitting[1] (don't know about ZFS, I suspect it might).
Same as above.
> Maybe because the combination of XFS/ext4 plus LVM is more than good enough for most people as that route still provides snapshots etc.
Very different kind of snapshots...
I've been using ZFS on my desktop and laptops for over a decade now. You gotta make really kick-ass FS for me to switch off ZFS even for desktop.
In datacenters many probably do, however most home/soho NAS machines are severely limited wrt memory and CPU power, which could be a limit. My self assembled NAS uses a Atom board to keep power requirements low since it stays always on, and I can't complain about its performance, however that CPU doesn't support more than 4GB RAM which is considered the minimum to properly use ZFS (NAS4free). Many cheap commercial NAS boxes used in small offices are even more limited. I wonder if there are any technical reasons preventing ZFS to operate (or be adapted to) in low memory environments.
This is mostly a myth with origins in the high-memory requirements of ZFS deduplication (which few should use, anyway). Of course, more memory allows for more caching, but that’s true of any filesystem on a “modern” OS.
I might upgrade it to something with a better processor because I do want to run de-duplication on my 14TB drive at some point.
My work backup server has "only" 32GB of RAM which is nowhere near enough to do dedup, even though there's a ton of stuff that could be deduplicated. Looks like it needs at least 64GB RAM to dedup, and that machine is maxed out.
But at home I'm in a similar situation to the parent. I'd like to set up a NAS, but I use it mostly for backups long term storage and don't want a big machine sitting idle all the time. A tiny Atom with Optane for cache and DDT might be ideal, in my thinking.
But for most of the storage use Backblaze is probably the right answer.
You could definitely put the L2ARC on Optane, but Optane is probably better suited to the ZIL (ZFS Intent Log, basically the journal so writes can be quickly acked) if you aren't using literal NVRAM.
Breaking the DDT out so it could exist on a Optane isn't currently available (again, AFAIK, but I recall hearing about some changes in that department, I don't recall specifics and may be misremembering).
I've basically never had a machine big enough to comfortably use dedup except on trivial loads. My backup boxes, where I'd really like to use it, have all fallen over when enabling dedup because of the RAM requirements.
https://forums.servethehome.com/index.php?threads/zfs-alloca...
Generally speaking, I will go with lower specs machines until I run into some actual problem. Haven't so far.
If you're talking about GFS, that's been gone for a decade, and was not a filesystem as far as the kernel was concerned.
But maybe there is also an automatic cleanup tool that deletes old snapshots after some time?
The snapshot refers to the storage blocks/records on disk, not files as such, an important distinction since ZFS can expose block storage (zvol) as well as a "regular" file system.
Since ZFS is copy-on-write, the only storage you pay for with a snapshot are the blocks that have changed since the snapshot was taken (plus a little overhead). Thus for data that does not change much, a snapshot is almost "free".
The blocks are reference counted. Once a snapshot is deleted, ZFS decreases the reference count of the blocks referenced by the snapshot. Any block with a refcount of zero is considered free and thus that space is reclaimed. This happens when the block has changed since the snapshot was taken and there were no other snapshots referencing that block.
ZFS itself has no automatic deletion of old snapshots AFAIK, but there are tools built around ZFS that allow for periodic snapshotting and cleanup.
Turns out a DAG, as is used in both ZFS and git, is a good data structure in many use cases.
Furthermore, you only "pay" their storage cost for data which actually changes. On a 2TB volume, last snapshotted 1 week ago, if only 5GB have changed since then, that's the only storage overhead (ignoring for simplicity the folder structure itself).
Also, if a single data block changes 20 times since its last snapshot, you still only "pay" storage costs for its current version + the one sitting in the last snapshot.
We need to encourage more of this :)
Edit: change heads up to hats off
Apologies if I’m being presumptuous or if this is just a late night typo. My wife speaks English as a second language so I know how confusing some of these idioms can be.
I went back to read some ZFS roadmap documentation from the Before (Oracle) Times this winter, and was reminded why my outlook for ZFS was initially rosier.
I was super excited about ZFS because if and when it got the ability to add new hard drives to an existing volume, then we had something I've always wanted: a straightforward way to grow a filesystem without having to tear it down and rebuild it from scratch.
That was still listed in future enhancements, shortly before Sun started to fall apart. Does anyone know where we are on that? Did that functionality get painted into a corner by other design concerns?
It's in that category of things that I might not use that much, but family and customers could use the hell out of and it would simplify my life just knowing it exists. I feel we are all lesser for that never making it off of the drawing board.
I wish Synology or Drobo had invested in solving this problem for everyone instead of doing their own proprietary solutions. Drobo has a whole filesystem, Synology has logical layer on top of RAID and/or btrfs to simulate this for some configurations of disk. In both cases, slapping a single higher capacity drive into the array gets you no increase in disk capacity. So every nth upgrade you are looking at 2 sequential rebuilds.
Most modern hard disks are too large/too slow for that. A write speed of 200MB/s translates to 12GB/minute, or 720GB/hour.
So, a 2TB hard disk (‘small’ for today) already would take 2½ hours to fill, and that assumes you hit 200MB/s continuously.
For a 12TB disk, “after a _day_ it goes 'ding'” would be closer to the truth.
I also think that, for most consumers, storage in the cloud is a better option than a “consumer-grade NAS”.
I'm not convinced, in the specific case of a consumer system, that every track on every disk needs to be touched during a build/rebuild. It amplifies the read and write traffic at exactly the point where any traffic is a ticking time bomb waiting to take your data away (which is exactly what happened the first time I tried to upgrade the Synology - a drive started reporting bad sectors during the verification after rebuild, but before marking the array healthy).
In a production server you might be more uncomfortable with a drive array that experiences an amortized cost spread over every read or write operation, especially one that upticks every time your total storage exceeds the previous high water mark. But even there, I think I could make a reasonable if not airtight case for that as well.
Last conversation, I believe someone told me that the cost of resilvering a ZFS array is proportional to the contents and not the capacity. I don't know if that would be true in the case of the patch being discussed.
The best any of us can expect is for the costs to be similar to the kind of service disruption you get when adding or removing servers from a cluster that is using consistent hashing with m-way redundancy. There are always m machines involved in every write, and you are going to have to move 1 to 2 nths of the data every time n changes, and that may be as high as m/n reads and writes. But 2/5th is a lot smaller than 3 reads, 1 write, 3 reads per block for 100% of the blocks in the volume. But I haven't seen a system that is anywhere near that minimum cost.
Cloud storage is a non-option.
For “most consumers”, I would think the data they create mostly is created in their phones (photos, videos), anyways, and I don’t see them syncing that to their local NAS, instead of using the more convenient sync to the cloud.
For photos, I suppose it would be good enough. Actually, perversely enough my phone does have unlimited data via its LTE connection. If only phones had the option to "download over cellular network only" instead of the reverse!
zfs get all:
zroot/var/tmp xattr off temporary
xattr=off | on
The xattr property is currently not supported on FreeBSD.FreeBSD uses a super weak permissive BSD license instead, so there is no conflict because it leaves whatever code you're trying to add to it alone, without trying to enforce any additional terms on it.
GPL violation is matter of opinion. For the opinion to be settled someone owning Linux copyright should sue Canonical and find out.
Canonical's did legal review and they have some big name open-source lawyers like Eben Moglen and Mishi Choudhary on their side https://www.softwarefreedom.org/resources/2016/linux-kernel-... They see it as a non-issue. So much that Canonical provides legal cover for all paying customers.
That was said by one lousy youtube comment without any explanation, Ubuntu has no problems with it...and i bet they have lawyers, i think it was in that vid:
https://www.youtube.com/watch?v=-zRN7XLCRhc
It's also crazy, nearly no distro has a problem shipping ultra-proprietary software (firmware), but has a big discussion about CDDL, no one wants ZFS in the Kernel tree, imagine Linus has control over it and has no clue was ZFS even is:
https://linux.slashdot.org/story/20/01/19/0059251/what-linus...
It's the difference between "mere aggregation" and "derived work". The kernel+ZFS can be considered a derived work from both, so it has to obey both licenses (GPL2 and CDDL) at the same time; on the other hand, the firmware is completely independent from the kernel, so the licenses (GPL2 and the proprietary license) apply separately to each component.
> Ubuntu has no problems with it...and i bet they have lawyers
On the other hand, Fedora has problems with it as a kernel module (but they do ship it as a ZFS FUSE module, see https://fedoraproject.org/wiki/ZFS), and they do have lawyers (Red Hat's lawyers review all the licenses for Fedora, and they consider the CDDL to be incompatible with the GPL: https://fedoraproject.org/wiki/Licensing:Main).
What?? No why?...no one of those project is derived from each other, ZFS is a module (on all platforms i think).
>and they consider the CDDL to be incompatible with the GPL
https://zonena.me/2019/01/the-cddl-is-not-incompatible-with-...
That's the important part:
>You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.
>To reiterate, executable forms of CDDL source code can be under ANY license you want.
That means your compiled ZFS module package can even be under GPL2 or 3 or beerware ;)
Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.
> > You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice [...] does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.
> That means your compiled ZFS module package can even be under GPL2 or 3 or beerware
I trust the Red Hat lawyers on this matter more than someone who is not a lawyer (from that page: "While it's true that I am not a lawyer [...]"). And from what I understand (I'm also not a lawyer), that clause in the CDDL applies only to the compiled result; but the GPL requires that, if the compiled result is distributed as GPL, the corresponding source code also be available under the GPL. So you cannot distribute your compiled ZFS module package under GPL2 unless the corresponding source code can also be distributed under GPL2.
To be fair to FSF however, they have to my knowledge never actually said anything else. What they do say is that they will enforce the license at that distinction, a conclusion RMS arrived at many years ago when apple tried to make proprietary addons to GCC. The reasoning, as provided by a consulted lawyer Eben Moglen at the time, was that a judge would likely see it as creating a single derivative work out of the linked parts, and as such you need a copyright license. This story has been mention in a few talks because so far no one has yet to challenge FSF in court and prove it wrong, which is a fight that at least Eben Moglen have been all this years willing (and possible wanted) to take up if given the opportunity.
As a bright line in the sand the concept has served FSF well, but it is not a supreme court decision that defines what a derivative work is under software. It could be that the line should be drawn much more narrower, but personally my bet is the opposite. Courts are rarely on the side that want to abolish copyright control or limit its scope.
Really? So if i compile something with gcc it is a derived work from gcc and gcc is derived work from my bin? Or when i make a firefox extension it's a derived work of firefox? Compile the nvidia module...a derived work from linux?
>I trust the Red Hat lawyers on this matter more than someone who is not a lawyer
But he can read :) but hey whatever, really not interested if linux has something good like DTrace ZFS or Crossbow, they like the NIH-Syndrome and i am ok with that too.
Yes. This is why the "libgcc exception" (https://www.gnu.org/licenses/gcc-exception-3.1.en.html) exists. The issue is that parts of runtime libraries which come with gcc are statically linked into the compiled executable; without that exception, the result would have to be under the GPL.
The same issue happens with Linux kernel modules. Many functions they need are only defined as macros or inline functions in the headers (since ZFS is a filesystem, just take a look at how many inline functions there are in include/linux/fs.h). And even outside of these, many functions are so closely coupled to the internal data structures of the kernel (and the data structures themselves are also exposed to modules) that any module using them could be considered a derived work of the kernel.
And in any case, there's an easy way to prove something does not constitute a derived work: just show that it can work outside of the codebase it's allegedly a derived work of. The reason NVidia is safe is that they provide the same driver for FreeBSD.
The parent actually explained it pretty well.
The ZFS source code probably isn't a derived work, but the compiled module might be.
As for ESX, that has gone to court:
https://www.zdnet.com/article/linux-developer-abandons-vmwar...
Ahh its ok for the driver but not for net-code?
https://www.theregister.com/2020/08/04/gpl_condom_nvidia_lin...
See that's exactly the Linux Problem...
By the way...Linus is not ok with a ZFS GPL shimlayer:
The difference is that they cannot afford to leave every Nvidia GPU owner out.
Fedora has problems with it :)
I hope I didn't write bs, however here is the talk of you want to know more and with more details: https://youtu.be/Zpnncakrelk (leaping the chasm from proprietary to open: a survivor's guide)
As usual Bryan Cantrill is just brilliant at explaining stuff.
Edit: just to be explicit: it was NOT about keeping stuff out of Linux.
He makes another poor turn when he says that the CDDL kept stuff out of Linux, but "not because of the CDDL but because of perceptions of the GPL" (i.e. IHVs didn't want to deal with the GPL). The license and the choice of using it are two different things. Sun could have written a license that was not GPL (to satisfy IHVs) but was compatible with GPL. They did not. Danese Cooper, who was part of that effort, says this was on purpose, and stated it on record ( http://caesar.ftp.acc.umu.se/pub/debian-meetings/2006/debcon... from 27:30). I guess Bryan was one of those engineers Danese mentions as "having some biases" back then. It was certainly obvious, at the time, what a careful avoidance of a license compatible with the biggest Solaris competitor would have resulted in, from a practical and commercial standpoint.
In the same talk, Simon Phipps disagrees with her assessment and later said he was furious at her spiteful comment. Now, almost fifteen years later, nobody else had corroborated her claim despite there being no reason to protect Sun anymore.
There is still a reason to protect themselves, of course, from a historical judgement that wouldn't appear particularly kind.
We haven't read the same flames, then...
Of course I haven't read every discussion about it, but I have read quite a few. I think someone would have to both confirm that the incompatibility was intentional and argue it was the correct choice to to get much hate about it.
It seems to me that Mr Cantrill is more aware of the business side, while you're more keen on the philosophical side.
Yeah twiddling the source and everything, but if you didn't choose it in the first place that wouldn't happen.
Why? Why even care about GPL? It's 100% compatible to MIT/BSD/ISC and that's enough, even Linus said that he probably would choose the ISC today, he chose mainly the GPL because GCC had it...and now they have GPLv3 (an absolute shit decision if you ask me).
Licenses are not adopted in a vacuum. The license is what made GCC what it was when Linus had to pick a license, and arguably what made Linux what it is today. A "BSD Linux" would have likely ended up the same way BSD systems have: a largely academic project routinely cannibalized by behemoth closed-source companies.
The question, yesterday and today, is really "why not care about the GPL?". The rights it grants are what made the F/OSS ecosystem what it is today. If you want to grant more rights to your users and developers, by all means use a less restrictive but compatible license like modified BSD, or MPL 2. It's easier to do that without fear of withering, now that opensource is the de-facto default choice in a lot of fields. It definitely was not as easy back in the '90s or early '00s, which is when the GPL effectively fought the war for the whole field.
If you choose to stick with pre-MPL2 derivatives, though, you are clearly not interested in granting users and developers the same basic rights as the GPL.
It's just a different vision, if you want real freedom and want to work with a community go with BSD/MIT.
>ended up the same way BSD systems have: a largely academic project routinely cannibalized by behemoth closed-source companies.
That's BS, just look at how Netflix and Dell EMC work with FreeBSD. And for example Juniper, they learned a lesson not working with the community and fell far behind because of that.
All of these licenses would have avoided the problems we see with ZFS' adoption of CDDL or other MPL1 derivatives.
Today. Not in the '90s cut-throat "pirates of SV" environment.
Obviously each project and field has a story; licensing and timing are both part of it.
I would also argue that we are eventually going to pay for the ecosystem refusal to adopt GPL3, which is effectively "closing" away the software at another layer.
MySQL was always the more popular database, true. But it was also the one technically inferior, a PHP of databases.
As for GPL3 - on the contrary, the problem is the adoption of GPL3, which forced many parties to switch to non-GPL alternatives. But it also gave boost to Open Source alternatives, putting an end to the unhealthy monopoly of GNU toolchain.
Those are the same sort of businesses that, back in the '90s, would take BSD code and ship it without giving anything back. They were using GPL code only because they could respect the letter of the license while ignoring the spirit, thanks to coincidental technological changes (the move from PCs to server-based architectures). This problem keeps coming up and promotes a parasitic business model.
We'd be better served in the long run, as an ecosystem, by trying to find business models that work with GPL3.
As far as I know there were never any serious attempts at making GPLed alternatives to Apache httpd, nginx and BIND.
> ditch patent protection [...] would create real problems for everyone
What problem, exactly?
The patent-protection clauses of the CDDL are at odds with the spirit and practice of open licenses anyway, since they are voided as soon as the relevant code is modified.
So basically, the cddl ships clauses that are pointless and likely to be disregarded in practice and in court. Losing them would make no difference whatsoever.
The CDDL clauses are not voided when the code is modified. Where did you get that idea? What you are saying is plain fantasy.
Maybe, some could say that the GPL2 is really awkward, but you have to know that Microsoft and Apple have their own opensource license too...big business is awkward.
Jesus Christ you are absolutely right I hadn't seen the issue under that light.
I keep getting down voted, maybe I am too annoying for HN. But I'll risk it in the hopes this is helpful, in the social and psychological space.
First of all, I have been in awe of ZFS since... ever. But FS were not my curiosity, OS was, so I installed OpenSolaris and Illumos in VMs, a few times to get used to how these things install. No work, just play. That's me. I was sad Apple did not adopt ZFS, but they did develop a read-only something, kernel extension, I think, don't recall. And there is some support from the generous for OpenZFS on OS X (idk about macOS). Why not ZFS? Because it is different and complicated, and it takes dedication to learn. Had Apple adopted it as the native FS, I would have been forced to learn it, so that is why it made me sad. I need that kind of motivation. But many are this way to some extent. Everyone is industrious and everyone is lazy. When you can learn easily, you learn. When you must learn, you learn. When you get older, you just want to keep doing things the old way, the way you know how, and you can do that for 12+ hours a day and yet learn nothing new.
Linus is just a man. I'm glad the penguinistas have faded into the background, and I am happy for Linux, but fail to see that it was any better than NetBSD when the fanatics were vocal. Linux would have benefitted from not changing a lot of userland stuff that was changed from *NIX for no rational reason, but probably just for ignorance and arrogance. Just MHO. But now Linux is important. It just is what it is.
So Linus is insanely industrious, and also lazy just like most. How often does he learn something new, how often does he just work like a mad dog without learning anything new? Just a man, perhaps a very smart man, but no more. And he is imperfect. And I strongly suspect, by the public evidence of the tell-tale symptoms, he has an identifiable personality disorder, and it is the one that includes the symptom of an unwillingness or inability to recognize the problem. But IIRC, he did admit to things, and supposedly took time off to work on himself. But this can't be cured by the patient, though it, oddly enough, can be cured, one of the few mental illness than can be cured, not just maintained, but only after getting evaluated by a professional, and treated, and the treatment is easy, just sitting with the pro and talking twice a month for 45 minutes for up to two years. At least my understanding of it, it can be cured in two years or less depending on its severity, though rarely ever is. This is not criticism, it is compassion. Presidents get this. Captains of industry get this. Winning NFL quarterbacks get this. And it is not any surprise the Lord of the Linux kernel can get this. And I wish him the best.
We're all allowed to be incorrect and imperfect. But those that stand out get better, because they try. But as far as laziness is concerned, because I am lazy, too, and I believe most are, I can't fault anyone for being lazy and not learning new stuff, especially in order to have a better understanding of it to be able to say something about it that makes sense.
However, those that do change themselves for the better, those that are not lazy and learn new things, should be applauded, and given gratitude for the possibility that their example will be followed... hopefully by me, too.
not going to get into particulars because it's a big topic.
Because it has literally zero competitors that can even approach its feature set? Btrfs is a trash fire, bcachefs is years out, nilfs2 doesn't actually verify its checksums, ceph/gluster run largely in userspace (so you can't run them as your root fs). What fs would you like to propose that lets us do snapshots, data integrity, and compression?
https://github.com/openzfs/zfs/pull/10018
For defrag, ZFS developers avoid to implement "block pointer rewrite" feature that's needed for defrag due to complexity. I hope BPR project start to improve features.
Now, only if Windows would also have some sort of support ;)
[1] http://build.zfsonlinux.org/zfs-features.html
You can explicity create a pool with certain features disabled.
I'm going to try FreeNAS Core tonight.
If you create the pool on pre-OpenZFS FreeBSD, you can use it on Linux, but not vice versa.
I just did this with FreeNAS (based on FreeBSD 11) and Raspbian.
There's two levels to consider though if you create a pool with explicit consideration for a system with an older version of ZFS: "-o version" and "-d"/"-o feature@...", both of which can be used to fine tune exactly what the pool can and cannot do.
I've made a list to help out doing it between ZFS-on-Linux releases. It shouldn't be hard to look up FreeBSD feature lists and do the same: https://chungy.keybase.pub/zfs-features-table.html
sysutils/openzfs/
Then... nothing further was heard about it.
Also it's pretty much impossible to grow a zfs pool and there are no consistency check tools or repair tools. So when you actually do get corruption, you lose it all.
Might have been a breakthrough around 2000 but it's time for something new.
This is flat out wrong. First you can trivially grow a zpool by adding another vdev to it. If you can't do that, you can grow a vdev, and hence the zpool using that vdev, by swapping the disks for larger disks one at a time. Once all the physical disks in the vdev are of the new, larger size, the new space will become available automatically.
Also there's absolutely a consistency check and repair tool built in. ZFS computes and stores checksums for all blocks, even when you use a single disk!. It also verifies the checksums when reading blocks. In addition you can trigger a verification of all the blocks by running a scrub command, which simply issues a read for all the blocks.
> So when you actually do get corruption, you lose it all.
Hardly. Not only does ZFS have the above, it also stores multiple copies of important metadata blocks (three copies by default), and it even takes effort to spread those blocks out on the physical disks to reduce the chance of them getting corrupted as much as possible.
I'm not saying ZFS is the perfect filesystem. But it's definitely one of the better if you care about your data.
`zpool scrub` is the consistency check and repair tool. It's happy to detect and repair everything from bit flips to realtime `dd if=/dev/random of=/dev/ada0` of a mirrored/raid-z disk.
Growing a single vdev can be impractical especially for raid-z. Adding new vdevs to a pool is straightforward.
Agree with it but other stable filesystems (XFS, ext4) are 1990s tech. ZFS is only available stable 2000s filesystem. Possibly Bcachefs is the future.
They are different enough that some of the work is split, however there's significant code sharing in things like device drivers and the like.
Ultimately each being very different is usually seen as a positive. While the <n> Linux distros are spending significant hours optimizing essentially the same userland for minor differences in use cases, the different BSDs have very different goals and results. OpenBSD has an emphasis on making a lean and consistent base system with comprehensive documentation, NetBSD has excellent tooling for cross-compiling, and a comparatively more modular kernel that lends itself to experiments like rump-kernels. I'm less familiar with FreeBSD but it's tended to emphasize features like ZFS and its own robust container solution.
In some cases these features are contradictory, as OpenBSD would be (I imagine) very reluctant to merge NetBSD's in-kernel Lua module support, or NetBSD's multithreaded "high performance" implementation of the firewall pf, "npf", in favor of its own much simpler and more secure pf. OTOH NetBSD has a stronger emphasis on backwards compatibility which somewhat limits their ability to make broad changes to the userland as OpenBSD has. Then, one is much more likely to be able to run old NetBSD binaries on new kernels. :)
Each has its pros/cons, and attracts its own users and developers. The distinguishing thing about *BSDs is the base userland and kernel are deeply intertwined, giving each more freedom to deeply tie userland tools to special kernel functionality. There are pros and cons to this too, but this means that, for example, one can use "ifconfig" to connect to WPA2 WiFi networks on OpenBSD with no other tools required, as the ifconfig userland is always released alongside a matching kernel. The various net-util packages shipped for linux have suffered from having to operate as "external" tools interfacing with a range of kernel versions. (of course, now the situation is better with ip/iw, but it sure took long enough)