If the news in this Phoronix article comes to pass and the 6.18 kernel gets rid of write_cache_pages, it’s really bad for ZFS on Linux.
www . phoronix . com / news / Linux-6.18-write-cache-pages
1 Like
What forum is that?
2 Likes
pmh posted the correct link - I’m too new and the bbs software wouldn’t allow me to post a hyperlink without including unnecessary spaces.
I linked it.
1 Like
What is the justification for this? 
GPL zealotry.
The GPL is not a license. It is RMS’ political agenda cast into license form. And his agenda is to destroy copyright once and forever by the means of copyright.
He has publicly stated that again and again and again.
Why one would slap this on one’s own software product fails me. Everything I personally produce is BSD licensed.
Kind regards,
Patrick
1 Like
Could also be a swipe at bcachefs with no regard for potential collateral damage…
1 Like
Because you don’t want someone taking the code you distributed for free, and charging for it. Pretty simple concept, really–not everyone agrees, and fair enough, but the concept shouldn’t be that obscure.
I understand that idea. What I personally find problematic is that any code built on top of that, linking to that, … by the license forced to be made available under the same license.
That’s where CDDL - a perfectly open source license by the criteria of the Open Source Initiative - vs. GPL breaks. And it is GPL that is the problem, by trying to force the GPL on the CDDL licensed parts.
If I integrate my proprietary code with the Linux kernel and sell the result as a closed source product I should only be required to make the open source code on which I built available bundled with my product but not necessarily anything I wrote.
I am not charging for Linux - I am charging for the things I added. And if these are worth my price is decided in that market thing everyone keeps talking about.
I am not taking anything away, locking down anything or some such from Linux by adding proprietary code. And under which license I publish that code should be under my discretion.
Kind regards,
Patrick
2 Likes
Yeah, the linked libraries thing gets messy. I generally agree with the principle of the GPL, but its application in this context seems iffy.
One of the OpenZFS devs seems to think this isn’t as bad as it sounds:
3 Likes
Thanks @WiteWulf for the information and link.
During my own research, (after learning about the potential issue in this thread), I also saw something odd. The author of BCacheFS said that his implementation of data safety went beyond what OpenZFS did. And that things that would corrupt OpenZFS, could be recovered from using BCacheFS. (Wish I kept the link…)
Not sure I believe all of it. But it would be too easy to prove otherwise, so maybe some of that is true. After all, many of the ZFS data integrity implementations are from 20 to 25 years ago… Modern FSes should be able to learn from the past, and implement even better today.
Will continuously focus on this kernel change. GPL 2.0 is not just a license, but also a political act. I hope OpenZFS on Linux can survive this kernel break change.
But the GPL does NOT prevent that.
One can take “free” GPL code, make a fork, and charge for the fork; what the GPL requires in this case is that paying customers can access the code as well as binaries. What matters is that code never escapes the GPL virus. Pretty simple concept…
The GPL is a death cult.
Yes, but you must release that code under the GPL–so those paying customers can freely redistribute it. You don’t have the option, legally, of distributing only a binary, or further restricting the paying customers’ use of that source code.
And some of us even think that’s a good thing.
If you follow the rabbit hole long enough, it already had a proposed resolution at the time I posted my previous response, (6 days ago).
Turns out the guy who prototyped a “fix” for that so called “change”, has also done other OpenZFS fixes. I vaguely, (but don’t quote me), recall him being one of the people who helped fix the block cloning bug in OpenZFS.
1 Like