LWN: Comments on "Making life (even) harder for proprietary modules"

Making life (even) harder for proprietary modules

daenzer — Wed, 20 Sep 2023 07:53:39 +0000

> Going forward both nVidia's proprietary and F/OSS userspace build on top of the same kernel driver and device firmware. That driver can be mainlined and kept up to date with ongoing kernel developments.

While the open source nvidia driver might be mainlineable in principle, Nvidia have not committed to doing so. So I wouldn't hold my breath.

(I don't know if they have committed to phasing out the proprietary driver in favour of the open source one)

> This is effectively identical to what AMD has been doing for many years now, [...]

Still quite a long way off, really. The amdgpu driver has been upstream for almost a decade (after years of preparation), and it contains pretty extensive documentation of how the hardware works.

Being an upstream driver, amdgpu has to maintain backwards compatibility with older firmware versions. I don't know if Nvidia have committed to doing the same for their open source driver.

Making life (even) harder for proprietary modules

cstrahan — Wed, 30 Aug 2023 17:50:46 +0000

> But it does little or nothing to make the computer code more available to be examined or fixed, more open.

Sure. But it does make things better in a couple important ways: If NVIDIA wants to shove critical functionality into firmware blobs, at least the experience of using NVIDIA GPUs will suck equally everywhere. In practice, that means that they'll either work harder (than they would writing Linux kernel module code) to get things right, or if they can't, then they can be punished in the market, and we can all opt to acquire competing cards.

And while you and I would prefer to have access to all of the code, this move is still better than before for another reason: while the GPU may be stuck with buggy firmware blobs, at least that's not running in kernel space, with the power to crash your system.

Maybe an analogy would help: If I order food delivered, the delivery driver may take a crazy, convoluted route through town, and he may curb his vehicle, or get in a wreck, etc, and I don't have any control over that. But do you know what the delivery driver *isn't* going to do? Any of the above to *my* vehicle. If I *could* control the delivery driver's actions, I would have them safely and optimally delivery my food, but because I can't, at least I'll be happier knowing that they can only total their own car, while my car is sitting safely in my garage.

Having the proprietary NVIDIA kernel module loaded is like handing your keys over to a delivery driver you have never met and trusting they won't financially ruin you.

Making life (even) harder for proprietary modules

Wol — Mon, 28 Aug 2023 18:32:19 +0000

Yup. The GPL is, unfortunately, as clear as mud (but it's not its fault).

It's full of assumptions as to what a derived work is (which is a matter for the law, not the GPL).

It's full of assumptions as to what is copyrightable subject matter (which again is the law, not the GPL).

The GPL is only clear when you're talking about statically linked binaries, which are rare as hens teeth on linux ...

And although my favourite system (Scarlet) is GPL, if I tried to use the GPL try to to stop people shipping systems chock full of binaries, with only the publically available source made available to the customer, I'd probably be on an extremely sticky wicket ...

Oh, and what happens if I build my own kernels (which I do, I run gentoo). All these (allegedly) proprietary modules which the kernel refuses to run, they CAN'T be GPL violations, because it was me that created the binary, and it's me running the binary, so the GPL doesn't apply.

Cheers,
Wol

Making life (even) harder for proprietary modules

mb — Mon, 28 Aug 2023 16:00:29 +0000

>However, the interoperability here is well-defined: obey the GPL.

It's by far not that well-defined.
It's rather that some developer had the opinion that using a certain symbol would surely be a GPL violation. That is not well-defined at all.

Making life (even) harder for proprietary modules

mathstuf — Mon, 28 Aug 2023 14:09:36 +0000

DRM is bad. However, the interoperability here is well-defined: obey the GPL.

Interoperability with the typical DRM-protected resource is illegal (according to the US-based DMCA at least, probably effectively exported to elsewhere via treaties by this point). There are some exceptions, but they are subject to change every 3 years by the Library of Congress (and also subject to lobbying efforts).

Making life (even) harder for proprietary modules

irvingleonard — Mon, 28 Aug 2023 13:34:55 +0000

So, is DRM good? Is it bad? Does it depend on who wields it? (it's ok when "we" do it). Would be crazy to think some distro(s) might end up having DRM-less kernels (patched) or maybe the possibility of installing/running both?

Making life (even) harder for proprietary modules

mjg59 — Fri, 11 Aug 2023 18:38:44 +0000

They could special-case the GPL compatibility in a similar way to GFDL 1.3 existing to allow Wikipedia to relicense to CC.

Making life (even) harder for proprietary modules

BenHutchings — Fri, 11 Aug 2023 16:34:41 +0000

CDDL has an upgrade clause, so in fact they can relicense it. However, in doing so they would also be relicensing everything else that's under CDDL 1.0 (that doesn't say "no license upgrades").

Netgpu and the GPL

Wol — Fri, 11 Aug 2023 15:56:32 +0000

"reason to believe".

The problem with that is the people who don't bother to check the facts (ie most of us, most of the time).

As I put it, "your reality is not my reality", or as Einstein would put it, "what you observe depends on where you are standing". There are too many people who cannot understand how anyone else could have a different point of view. (One only has to look at the recent "heated discussion" over Free Software and Open Source :-)

So let me rephrase your comment - Once someone's tinted glasses have given them reason to believe you have acted in bad faith ... it happens, and it probably happens far more often than it should ...

We've seen it happen here, where people just refuse to accept that somebody else (Red Hat, anyone) might have had good grounds for doing what they've done.

Cheers,
Wol

Netgpu and the GPL

Karellen — Fri, 11 Aug 2023 15:38:43 +0000

Once someone has reason to believe that you repeatedly act in bad faith, they will be suspicious of everything you do, even if it appears to be reasonable on its face.

Making life (even) harder for proprietary modules

Wol — Fri, 11 Aug 2023 10:27:29 +0000

And 60 years ago, when your mainframe was (still is?) a bunch of individual boards all working together.

Somewhere I remember it being discussed, and how it's all just a trade-off. Back in the days of winmodems and winprinters, the cpu was cheaper than dedicated power on the network card / in the printer, so cost conscious manufacturers moved all the compute into the cpu. Before that, the cpu was too slow and dedicated silicon was a better choice. Now with powerful GPUs it's swinging the other way - separate GPUs are both cheaper and faster.

And even with things like AMD's APUs, I get the impression they are actually a CPU and a GPU sharing the same chip, so they are actually separate silicon, just right next to each other to make things run faster with shared cache and physical proximity.

Cheers,
Wol

Making life (even) harder for proprietary modules

jengelh — Fri, 11 Aug 2023 08:18:52 +0000

>moving the proprietary code off the CPU into a processor inside the GPU

Ironic to see how we're going back to how things were done ~30 years ago, when functionality was in fact on the daughterboard and didn't take up so much resources of the main system (particularly CPU cycles?).

Making life (even) harder for proprietary modules

kpfleming — Thu, 10 Aug 2023 13:22:06 +0000

Even the "Debian recovery" image available at OVH for bare-metal dedicated servers has ZFS built in. This made my life much easier the last time I rebuilt a machine there :-)

Making life (even) harder for proprietary modules

net_benji — Thu, 10 Aug 2023 12:49:20 +0000

"At that time, Hellwig merged a patch intended to make that method more difficult."

Maybe it's pedantic but I would say that Christoph Hellwig *submitted* that patch. It was *merged* to mainline Linux by other people.

Making life (even) harder for proprietary modules

intelfx — Thu, 10 Aug 2023 02:11:39 +0000

> I mean that the OpenSource driver doesn't need a special firmware for it.

Then this does not address GP's concerns at all.

> Noveau still used firmware for reclocking, even on older devices

Nope, they wrote their own PMU firmware for supported devices.

Making life (even) harder for proprietary modules

dvdeug — Thu, 10 Aug 2023 00:37:07 +0000

This seems to have been overruled by Petrella v. Metro-Goldwyn-Mayer, Inc., 572 U.S. 663 (2014), where the Supreme Court said "Laches cannot bar a claim for damages brought within the three-year window. By permitting retrospective relief only three years back, the limitations period takes account of delay."

Making life (even) harder for proprietary modules

intelfx — Wed, 09 Aug 2023 21:59:03 +0000

> Furthermore, attempting to tinker with those cryptographic locks exposes oneself to massive civil (and possibly criminal) liabilities in most jurisdictions

Could you please point out how exactly "attempting to tinker with cryptographic locks" on the hardware I legally own exposes me to liabilities "in most jurisdictions"? I fear I might need to turn myself in and report most of my friends and relatives :-)

If this is about DMCA, then, thankfully, USA != most jurisdictions. And even then, jailbreaking is exempt.

Making life (even) harder for proprietary modules

pizza — Wed, 09 Aug 2023 21:39:00 +0000

> Does this "new" open-source code make it possible for nouveau to implement "some" support for reclocking? Yes. Will it be even remotely as useful as the hypothetical (reverse-)engineered interface to the low-level firmware? Not at all.

This "new" codebase is infinitely more useful than the current status quo, which prevents _any_ reclocking because nVidia locked things down cryptographically. Furthermore, attempting to tinker with those cryptographic locks exposes oneself to massive civil (and possibly criminal) liabilities in most jurisdictions.

nVidia has gone from actively impeding development of functionally useful F/OSS GPU drivers for their hardware to actively helping. This represents a massive improvement; why do you feel the need to dump on it for not being perfect?

Making life (even) harder for proprietary modules

Cyberax — Wed, 09 Aug 2023 21:35:34 +0000

> I don't believe that's true. The new open-source driver only works with the GSP-enabled generations, starting with Turing.

I mean that the OpenSource driver doesn't need a special firmware for it.

> For instance, one of the long-standing issues with NVIDIA's GPUs was power management, specifically reclocking. On those generations where reclocking was successfully reverse-engineered and implemented in nouveau, the driver was able to change the clocks at will (and overclocking was likely possible).

Noveau still used firmware for reclocking, even on older devices. See: https://www.phoronix.com/forums/forum/linux-graphics-x-or...

Making life (even) harder for proprietary modules

intelfx — Wed, 09 Aug 2023 21:02:04 +0000

> No. The firmware has always contained a ton of functionality (power management, command processing, etc.), and the new open source driver works fine with "old" firmware.

I don't believe that's true. The new open-source driver only works with the GSP-enabled generations, starting with Turing.

> Some of "secret sauce" remains in the closed userspace part, just like with AMD. But I don't believe that they actually moved functionality that is important for the kernel driver into the firmware.

Let's discuss an example.

For instance, one of the long-standing issues with NVIDIA's GPUs was power management, specifically reclocking. On those generations where reclocking was successfully reverse-engineered and implemented in nouveau, the driver was able to change the clocks at will (and overclocking was likely possible).

Now, I did not look at the "new" open-source kernel driver code, but I bet that the reclocking decisions are made entirely by the "new" proprietary firmware, while the kernel driver merely indicates the desired power state (or maybe even less than that, maybe it's only possible to indicate the upper limit). I also bet that there is zero support for overclocking, such that it remains a Windows-exclusive feature.

Does this "new" open-source code make it possible for nouveau to implement "some" support for reclocking? Yes. Will it be even remotely as useful as the hypothetical (reverse-)engineered interface to the low-level firmware? Not at all.

Making life (even) harder for proprietary modules

paulj — Tue, 08 Aug 2023 16:42:16 +0000

This is the irony, Oracle can't ship ZFS with Linux cause of the licence.

This is also the answer to NYKevin's question: Oracle could make more money by relicensing ZFS to be GPL compatible as that would allow them to ship ZFS with Oracle Linux, and market it as "We invented it, so we can support it best!".

The slight problem there is that a lot of ZFS on Linux development has been done outside of Solaris, and most (all?) of the Sun ZFS developers have long left Sun/Oracle.

Making life (even) harder for proprietary modules

Wol — Tue, 08 Aug 2023 14:53:34 +0000

> Thanks for that, but for purposes of my own understanding, how is this current scenario materially different from the delays from initial infringement-to-enforcement in SCO v IBM (which I think is _still_ not quite technically over) and more recently, Oracle v Google? Ultimately both were more about ongoing infringement, no?

Firstly, it's very easy to sue in the US even when you have no case.

Secondly, certainly in the SCOG case we think the initial aim was to get IBM to buy them off, and then (for SCOG) it turned into an existential fight for survival plus a fraud to milk the company. So they were simply prolonging the case any which way they could.

And then, when you really have a case, it gets summarily dismissed (WP vs MS) - based on a mis-direction by a Judge I believe. WordPerfect thought that the statute of limitations had been stayed by Netscape vs MS, only to discover when they tried to litigate using Netscape as precedent, that it hadn't and they were out of time. I think what they *should* have done was launch the suit and at the same time ask the Judge to stay the case until NS vs MS was over. But either counsel misled them, or they mis-understood counsel.

Cheers,
Wol

Making life (even) harder for proprietary modules

pizza — Tue, 08 Aug 2023 11:43:35 +0000

> You can't just do that. The US gives you three years from the date of the infringement to file a (civil) suit, and most other jurisdictions have similar statutes of limitations (although they may not all be exactly the same length). See 17 USC 507.[1]

Thanks for that, but for purposes of my own understanding, how is this current scenario materially different from the delays from initial infringement-to-enforcement in SCO v IBM (which I think is _still_ not quite technically over) and more recently, Oracle v Google? Ultimately both were more about ongoing infringement, no?

The SCO debacle in particular is where the Linux kernel's Developer Certificate of Origin came from, and I think it's safe to state that, regardless of any technical/stylistic/etc issues, there's no way [Open]ZFS would ever get accepted into the mainline without "signed-off-by: legal@oragle.com" or shipping [Open]ZFS binaries as part of OracleLinux.

Making life (even) harder for proprietary modules

NYKevin — Tue, 08 Aug 2023 05:39:25 +0000

You can't just do that. The US gives you three years from the date of the infringement to file a (civil) suit, and most other jurisdictions have similar statutes of limitations (although they may not all be exactly the same length). See 17 USC 507.[1]

They could still sue for ongoing infringement after that point, assuming Canonical continues to distribute ZFS, but common law jurisdictions may apply the doctrine of laches if the plaintiff was aware of the infringement and intentionally delayed enforcement to prejudice the defendant, regardless of whether the statute of limitations applies. See for example Danjaq LLC v. Sony Corp., 263 F.3d 942 (9th Cir. 2001).[2] The key quote (in my opinion):

> Next, we conclude that claims of infringement stemming from re-releases of Bond movies on DVD have been "delayed" for purposes of laches. On the one hand, we recognize the seemingly paradoxical nature of this conclusion. After all, how can it fairly be said that a lawsuit filed in 1998, relating to a DVD released in 1997 (to take the example of Dr. No) was "delayed"? The answer is simple: Where, as here, the allegedly infringing aspect of the DVD is identical to the alleged infringements contained in the underlying movie, then the two should be treated identically for purposes of laches. It would be incongruous indeed to hold the opposite — to say, that is, that McClory's claim for infringement on a re-release survives, despite the dismissal for laches of the same claim regarding the original work. This exception would effectively swallow the rule of laches, and render it a spineless defense. In analogous contexts, similar theories have been roundly rejected. See, e.g., Hot Wax, Inc. v. Turtle Wax, Inc., 191 F.3d 813, 821-22 (7th Cir. 1999) (trademark case; rejecting the argument that each new instance of infringement must start the clock anew on laches: "Without the availability of the application of laches to a claim arising from a continuing wrong, a party could, theoretically, delay filing suit indefinitely."). We decline to reach such a result here.
>
> For similar reasons, we reject McClory's argument that laches may never bar a claim for infringement brought within the statute of limitations. We have already determined that laches may sometimes bar a statutorily timely claim. Kling, 225 F.3d at 1039; Jackson, 25 F.3d at 888. And, although such an application of laches may be unusual, see Telink, 24 F.3d at 45 n. 3, it is appropriate here. Even leaving aside the special circumstance of re-releases, we conclude in any event that McClory's extraordinary delay and the extraordinary prejudice to Danjaq render laches appropriate despite the statute of limitations. Id. at 46 n. 5 ("If the defendant can show harm from the delay, the court may, in extraordinary circumstances, defeat the claim based on laches, though the claim is within the analogous limitations period.").

[1]: https://www.law.cornell.edu/uscode/text/17/507
[2]: https://casetext.com/case/danjaq-llc-v-sony-corporation

Making life (even) harder for proprietary modules

james — Mon, 07 Aug 2023 12:47:48 +0000

And Oracle Linux has no USP over other Linux distributions, except that you can get support from the same company that supports your database if you're unfortunate enough to have an Oracle database.

I'm saying that it would be worth Oracle's while to allow ZFS into the Linux kernel and support it on Oracle Linux: this wouldn't negatively affect commercial Solaris (since its days are numbered), but would benefit Linux in general and Oracle Linux in particular.

Making life (even) harder for proprietary modules

pizza — Sun, 06 Aug 2023 22:41:09 +0000

> Hasn't Canonical been doing this for years now? Where's the lawsuit?

Perhaps Oracle doesn't think Canonical has deep enough pockets to be worth suing, and is biding their time unti a more lucrative target (if only Canonical in a few more years) presents itself?

As both the stewards of CDDL and copyright holder of most of the ZFS codebase, Oracle could make this problem go away completely if they wanted to. Yet they have not.

Making life (even) harder for proprietary modules

DemiMarie — Sun, 06 Aug 2023 17:16:04 +0000

And nobody is claiming that the ZFS license is being infringed.

Making life (even) harder for proprietary modules

NYKevin — Sun, 06 Aug 2023 17:06:16 +0000

Hasn't Canonical been doing this for years now? Where's the lawsuit?

Making life (even) harder for proprietary modules

cyphar — Sun, 06 Aug 2023 14:18:54 +0000

There are OpenZFS packages available on basically every Linux distribution. Usually the only extra steps needed to get access to your data from a recovery USB stick is to enable a particular repository and install the package.

I highly doubt this will ever stop being the case. But even if that does happen, because ZFS is multi-platform you can always use FreeBSD or Illinois in a pinch. The same cannot be said for most of Linux's filesystems.

Making life (even) harder for proprietary modules

pizza — Sun, 06 Aug 2023 12:46:46 +0000

> "it's complicated, but arguing over ZFS on the internet is not a productive use of anybody's time. The kernel developers should either send Canonical a C&D letter, or stop whining."

As I said in the message you replied to; its not the kernel authors that Canonical (or the other kernel devs) should worry about; Instead it's Oracle's lawyers, who are well known for suing over software licensing minutae.

Making life (even) harder for proprietary modules

mpr22 — Sun, 06 Aug 2023 11:50:44 +0000

Anyone who runs ZFS in production on multiple machines is probably capable of building their own recovery image with ZFS support.

Making life (even) harder for proprietary modules

wtarreau — Sun, 06 Aug 2023 04:19:02 +0000

> I trust OpenZFS with data more than anything from native kernel code

It's not a matter of trust. Any FS may fail, and any system may fail to boot due to manipulation errors or FS corruption, and the day it fails you need to know how you can recover your data when your server is sick. It's where there is a big difference between booting the server from a random distro's USB stick and copy all the data over night onto a USB external drive, and having to go through the complex hoops of building the kernel that supports your FS from another machine (possibly someone else's when it's your dev machine that died). If you know that regular distros include support for your FS on the default boot images, that could be OK. Otherwise it's really a pain.

Making life (even) harder for proprietary modules

NYKevin — Sun, 06 Aug 2023 03:38:47 +0000

> Oh, it's a lot more than the linux kernel community saying this -- Sun folks are on the record saying the CDDL was intentionally drafted to be incompatible with the GPL, and pretty much every F/OSS lawyer (other than the ones on Canonical's payroll) also agrees on this front.

I'm not sure that's a fair characterization of the issue. The SFLC has a long and nuanced post on the issue (see [1]) which I would summarize as "it's complicated, but arguing over ZFS on the internet is not a productive use of anybody's time. The kernel developers should either send Canonical a C&D letter, or stop whining."

[1]: https://softwarefreedom.org/resources/2016/linux-kernel-c...

Making life (even) harder for proprietary modules

willy — Sat, 05 Aug 2023 19:10:11 +0000

Oracle Linux does not ship ZFS.

Making life (even) harder for proprietary modules

pizza — Sat, 05 Aug 2023 12:58:50 +0000

> I would _love_ to see this supposed GPL vs CDDL incompatibility challenged in court, btw. So far it's only the Linux kernel community kicking and screaming they're incompatible, but both of these are FOSS licenses and those are not code, intents matter

Intents only matter when the text is ambiguous, which is not the case here.

The fundamental conflict between the CDDL and the GPL is that they both require derived works to be licensed solely under that license. While broadly similar, the licenses are not identical, and the differences (eg the CDDL has stricter patent language) become "additional restrictions" that are not allowable under the other. Therefore the licenses are incompatible.

Oh, it's a lot more than the linux kernel community saying this -- Sun folks are on the record saying the CDDL was intentionally drafted to be incompatible with the GPL, and pretty much every F/OSS lawyer (other than the ones on Canonical's payroll) also agrees on this front.

Sure, ultimately it's up to a court and a zealous deep-pocketed plantiff to test this, but while you can probably trust a typical Linux contributor to not stir the pot, OpenZFS's rights are still largely held by Oracle, whose lawyers have shown time and time again they will happily boil the oceans if they think they can get away with it.

Making life (even) harder for proprietary modules

snajpa — Sat, 05 Aug 2023 12:18:31 +0000

I trust OpenZFS with data more than anything from native kernel code; esp. in a multitenant server environment for today's deployments. Though it might change in the longer-term future, for now MGLRU is still not quite where the ARC is in OpenZFS + bcachefs is still too young and from my point of view incomplete (eg. https://github.com/koverstreet/bcachefs-tools/issues/50). It was also easier for us to implement the uid/gid shifting mechanism into OpenZFS code before the new mount API and its ID-mapping feature.

We're forced to do our own thing since OpenVZ guys went fully their distro-only way and it's now less transparent to an outsider; we started as a kind of community-run hosting for members in 2009; now we run vanilla with custom patches for special treatment of the 1st level user-ns, syslog ns and a few other things to make it closer to full-VM experience; but unlike OpenVZ being RH-cenric based, we compose it with Nix/nixpkgs into our own live-OS release. I just painted it too rosey about being able to contribute our changes back, we'd need to double the community in size to be able to afford more devs :D and now with the inflation... crazy times :D

Making life (even) harder for proprietary modules

wtarreau — Sat, 05 Aug 2023 11:40:04 +0000

> In the worst case, one will have to recompile a patched kernel without such useless lines of code

Sure it's always possible, but it's a pain in field. I used to have highly patched kernels for a few decades, starting with ip_masq patches + IDE hotplug patches on top of kernel 1.2.13, VM+ipchains+NFS patches in 2.0, 2.1-ac on production servers, then 2.2+vlan+knfsd+raid+reiseirfs+FSACL on many servers including at customers, I can assure you one thing: from this point I started to slow down on patched kernels, especially when it comes to my data. I remember having to borrow a SIMM DRAM at work one evening to try to fsck my out-of-tree FS running on top of out-of-tree RAID over an out-of-tree SCSI driver. You don't feel very proud of you until you see fsck complete successfully! I've later run 2.4 with loop-aes and many other patches (~200 total), but this time not on critical data. Loop-aes was only used to protect customer's traces on my laptop.

From this era I decided not to use any out-of-tree stuff to store my data: hardware drivers, block layout, file system, etc. It's far too painful, you're not free to upgrade your kernel when you want, and whatever kernel you want to try requires to first apply all the mandatory patches you're relying on, and to fix rejects by hand. I've done that for 20 years and consider it's not worth the effort and the hassle. Filesystems are pretty good nowadays, I wouldn't value the ZFS improvements enough to experience this trouble anymore. By then in 2.2, there was a motivation to patch for reiserfs, it was the first usable journaled FS which didn't require 20 minutes of fsck at boot after a kernel panic or a power outage. Now ext4 is pretty good for general use and small files in general, XFS is good on large files, btrfs is reasonably balanced and has more features. That's sufficient to me. I'll wait for ZFS to reach mainline to try it.

Making life (even) harder for proprietary modules

snajpa — Sat, 05 Aug 2023 09:37:22 +0000

I would _love_ to see this supposed GPL vs CDDL incompatibility challenged in court, btw. So far it's only the Linux kernel community kicking and screaming they're incompatible, but both of these are FOSS licenses and those are not code, intents matter. No harm to either side when combining these two works matters IMHO even more. => IMHO the licenses are not as incompatible as some paint them to be

Making life (even) harder for proprietary modules

james — Sat, 05 Aug 2023 09:03:20 +0000

How much does Oracle Linux compete with non-Linux OSes, and how much is it in a space where we've won?

Traditionally, ZFS was a reason to buy Solaris, but with that going end-of-life in 2034, very few enterprises are going to do fresh installs on Solaris. ZFS is no longer a killer feature for Solaris.

But if ZFS is a first-class filesystem on Oracle Linux, that might encourage clients to buy support from Oracle even if other distros have it. It would certainly help sell Oracle Linux instead of Windows.

Making life (even) harder for proprietary modules

snajpa — Sat, 05 Aug 2023 09:01:36 +0000

fade into obscurity? keep on dreaming :D

In case you haven't noticed, OpenZFS does not focus on a single kernel; integrating with Linux is not happening, as it isn't the project's goal. Which also makes for +1 argument that it is _not_ a derivative work of Linux. It was developed independently and while Linux was the only kernel for a while, now there are two, FreeBSD and Linux - and support for more is coming.

I guess some really, really envy what OpenZFS can do and Linux can't? But this vitriol is not the way how to persuade people to abandon working on OpenZFS and make them see the light and go re-develop it from scratch for Linux. If anything, it'll make us double down working on OpenZFS. As a cherry on top, one doesn't have to deal with the awful dev experience that the LKML brings :-D