[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redhat dropping support for BTRFS
- To: silug-discuss@silug.org
- Subject: Re: Redhat dropping support for BTRFS
- From: Nathaniel Reindl <nrr@corvidae.org>
- Date: Sat, 12 Aug 2017 15:18:11 -0400
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=corvidae.org; h=content-transfer-encoding:content-type:date:from:in-reply-to:message-id:mime-version:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=mesmtp; bh=1Odi9blSWF5/C8506Enr5m3haF1iPKH+JdGc/6/wzU0=; b=OQqV4diw5W0LJsSPGK6rF71QYGCBV2h6HcWUOo0hDfNDbGHerg1yRwoBS6Y1yHQbYD6UlANcZToGK86BO3Fjhs9AnuWaF3Rw9oarZN1KloeN9VlE8q90zG4iPKfZzV3FQ7+LkczIpXm2alNVm/LYQ7J5ZGUSNv1dWCEfm2sd6TA=
- DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=messagingengine.com; h=content-transfer-encoding:content-type:date:from:in-reply-to:message-id:mime-version:references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=1Odi9blSWF5/C8506Enr5m3haF1iPKH+JdGc/6/wzU0=; b=oduJVM+9xF0U174KhaPOvfjc8tGjKLtBrPdHJ/PVUX1m3s9iuLGGODMl8GaP6sx7b1cTm8FMGKvjlsHK1lVZ1vcrCtWVv85kaaTRt7ue+lYZDtUTCV1wr0Gf5fWgbZ6xqBMNp3tcR9T7RiZX4wZi8Ymz6Jsgus970ZVEQkBitdI151n7j2uBdo0yOEkSvksOSjjqCmnUL345NPe7YOvDqhMUDAn7iMczCUBCw6qvNiFfjHL+7spNEKw0xeI36cr2iBXyIES3uWZNf1PyDaZ303+e+I+Ml87X2q1KWtRfAJoNI8G5Kp/zMLOvqlOOeLjQOGmiQfHDxvSHgRDCt+RH6A==
- In-Reply-To: <20170812172645.GA27221@osiris.store.computerroom.us>
- Organization: Southern Illinois Linux Users Group
- References: <DM5PR01MB32902E4162008AFFF532B3E6C6B60@DM5PR01MB3290.prod.exchangelabs.com><20170812172645.GA27221@osiris.store.computerroom.us>
- Reply-To: silug-discuss@silug.org
- Sender: silug-discuss-owner@silug.org
On Sat, Aug 12, 2017, at 13:26, Steven Pritchard wrote:
> Maybe if the rate of change in the btrfs code drops and the filesystem
> starts to prove itself, Red Hat will add it back in as a technology
> preview in RHEL 8.x (where x > 1).
OTOH, the strategy they intend to employ in light of this, in conjunction with the historical need to toil to manage all of the various storage components in RHEL in an additive manner, is a storage system running almost completely in ring 3 called Stratis. See <https://stratis-storage.github.io/StratisSoftwareDesign.pdf>. It should be first appearing in Fedora 28.
In general, I feel I can get more behind something like that where the code that runs in ring 0 is either extremely minimal or is a stable module that doesn't see a lot of churn or a lot of defects.
> Or maybe pigs fly, Oracle changes the ZFS license to something
> GPL-compatible, and we all stop caring about btrfs. :-/
Yeah, I don't foresee this happening either, but IIRC, the politics around this actually stems from the ZFS disapora that exists outside of Sun^WOracle. It's a similar when-pigs-fly scenario, just with actors who bear the capacity to be empathetic and have an interest in contributing to open source.
Apropos relicensing, the main point of contention from my understanding looks to be that the GPL and the CDDL fundamentally disagree on where the line around the code under its concern should be drawn. The GPL requires the whole project to be licensed uniformly while the CDDL really concerns itself only with how individual files are licensed. In addition, there's some concern about the lack of copyright assignment when it pertains to the CDDL as each individual contributor would retain their ownership over their contributions.
Ultimately, at the end of the day, I'm not particularly sure that it's uncouth for a systems distribution integrator to take a separate Linux kernel package and a separate ZFS package—barring technological restrictions—and combine them together with the functionality that would satisfy business need. GPL incompatibility does not imply non-free, and licensing a Linux distribution as a whole, complete work per the legal definition seems ludicrous to me. —n
-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.