SUSE reaffirms support for Btrfs

Posted Aug 24, 2017 15:44 UTC (Thu) by SEJeff (guest, #51588)
In reply to: SUSE reaffirms support for Btrfs by cjcox
Parent article: SUSE reaffirms support for Btrfs

This post reeks of hyperbole and falsehoods.

reiserfs was hated because it wasn't very crash safe, and while very fast, was extremely buggy. The journaling didn't work that wonderfully and it would require long fsck to recover if you were lucky when a box was powered off unexpectedly. To be fair, xfs had the same limitation at the time, but had a much smaller featureset compared to reiserfs at the time. The reason reiserfs went out of fashion was because reiser4 was too ambitious, and there was that little thing where Hans Reiser was convicted of murdering his wife. Reiser Systems went out of business and the filesystems were not well maintained after the downfall of Hans. The reason reiserfs (and reiser4) went out of fashion was because they weren't maintained very well compared to competing filesystems.

Redhat and SUSE work together plenty, look no further than SUSE's libsolv (https://en.wikipedia.org/wiki/DNF_(software)#libsolv ), which is the package dependency resolution aspect of dnf, Redhat's new shiney package manager to replace yum. Redhat AND SUSE worked together on btrfs for a long time, but Redhat sees the tech as still too immature for enterprise adoption. This isn't really that different years ago when SUSE was the first enterprise distro to officially support Xen, long before Redhat said Xen was ready for enterprise adoption. When I got to look at it, the SUSE forked Xen had a lot of limitations and omissions that made it "enterprise ready" for very specific and niche use cases. A few years later, Redhat officially supported Xen when it was actually enterprise ready. Then Avi posted KVM to LKML. Avi and his company, Qumranet, did virtualization on Linux better than Xen, and so Redhat bought them + ditched Xen, a legacy that SUSE is still sort of stuck with.

What do you even mean by Redhat "buying LVM"? Are you referring to Sistina? Sistina open sourced LVM and sent patches to Linux around Linux 2.2 (1999ish). Redhat bought them in 2003, so your argument still doesn't hold water.

SUSE reaffirms support for Btrfs

Posted Aug 24, 2017 23:49 UTC (Thu) by ThinkRob (guest, #64513) [Link] (5 responses)

I don't think it's that inaccurate, personally. I get the business reasons for why they do it, and they have enough of a history of it that we can start to draw some conclusions from their behavior.

I think that from a business standpoint, Redhat wants to make sure that they're never at the mercy of a competitor. So for some tech, that means sponsoring or even "buying" the project (although the latter is probably only useful if they have a CLA).

Really I think it's about Redhat not wanting to build a bunch of stuff on something, only to have Oracle or IBM or whomever swing by five years into a release and buy the project out from under them, then turn around and demand money from Redhat for continued access to patches/source/whatever-other-vital-asset. That would be the nightmare scenario: if Redhat added a major feature into RHEL, had customers build things that depend on it, and then half way through the support period Redhat had to choose between paying royalties to a hostile third party or eating the cost of maintenance of the project. At least "buying" the various projects gives them some budgetary freedom, since presumably there's already a community doing a lot of the heavy lifting. That frees up RH to scale its involvement as it wants, from leadership positions (ala CentOS) to "just fix the things that affect the version we shipped in RHEL."

SUSE reaffirms support for Btrfs

Posted Aug 26, 2017 4:09 UTC (Sat) by gdt (subscriber, #6284) [Link]

When you buy a open-source software company you also get the people. Often the ability to direct the future work of the software team is more important than the software as-is (which, after all, you can ship and modify for free).

Moreover, if you are a vendor offering long-term support of Linux for enterprises you might want to be able to direct the team's urgent attention to a five-year old bug, fixed for years, but which is nevertheless preventing a bank from doing its thing. The ‘community’ in this case is not useful, as their answer is “upgrade”. These occasions are rare, but it is an important capability which allows the software vendor to charge high prices to such enterprises.

SUSE reaffirms support for Btrfs

Posted Aug 28, 2017 15:52 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> At least "buying" the various projects gives them some budgetary freedom, since presumably there's already a community doing a lot of the heavy lifting.

I'm not sure what you mean by this, when Redhat "buys" a project that just means hiring the most productive members of the community, the ones working full-time on the project, so by definition then Redhat is doing the heavy lifting as the majority of the hours put in by the community.

> or whomever swing by five years into a release and buy the project out from under them, then turn around and demand money from Redhat ...
> choose between paying royalties to a hostile third party or eating the cost of maintenance of the project.

If they hire the developers of the project then they are by definition eating the nearly full costs of maintenance for a project, I don't think there is any scenario where Redhat pays royalties as opposed to hiring staff to continue maintenance as they don't ship anything they don't have a clear source license to. I doubt that Redhat ships anything where the bulk of development hours are currently paid for by someone else that they don't have a plan to full development resources on it should the maintainers stop for whatever reason.

SUSE reaffirms support for Btrfs

Posted Sep 1, 2017 0:55 UTC (Fri) by ThinkRob (guest, #64513) [Link]

> I'm not sure what you mean by this, when Redhat "buys" a project that just means hiring the most productive members of the community, the ones working full-time on the project, so by definition then Redhat is doing the heavy lifting as the majority of the hours put in by the community.

Well yeah, but they also benefit from the long tail of contributions.

> If they hire the developers of the project then they are by definition eating the nearly full costs of maintenance for a project, I don't think there is any scenario where Redhat pays royalties as opposed to hiring staff to continue maintenance as they don't ship anything they don't have a clear source license to.

That's true. I suspect I should have been clearer. I think they deliberately try to make sure they *don't* wind up in a position where they'd have to do that, and that this is one way of ensuring it.

SUSE reaffirms support for Btrfs

Posted Aug 28, 2017 19:08 UTC (Mon) by flussence (guest, #85566) [Link]

>That would be the nightmare scenario: if Redhat added a major feature into RHEL, had customers build things that depend on it, and then half way through the support period Redhat had to choose between paying royalties to a hostile third party or eating the cost of maintenance of the project.

Outside the bubble this isn't a hypothetical scenario: people already invest a lot of effort, money and time to defend the wider Linux community against becoming wholly dependent on Redhat projects (including under the fd.o umbrella).

SUSE reaffirms support for Btrfs

Posted Mar 28, 2018 17:32 UTC (Wed) by ceplm (subscriber, #41334) [Link]

At least with BTRFS you have your facts wrong. Josef Bacik was at Red Hat while RHEL was expected to be future default Linux FS. However, BTRFS was dropped on technical reasons (you may agree or not, but that isn't the point), and only then Josef left.