Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

341–350 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#341
post #83

Earlier quoted context omitted.

Pretty much my exact experiences. Banking and large corporations: RedHat, because they buy support contracts to have guaranteed security and stability updates, and because they want some assurance that whatever (open/closed) corporate software they use will run on their Linux systems. Debian and especially Ubuntu the last years for smaller "dev" companies because the devs like to be close to the open-source ecosystem…

I'm running RHEL with free developer license on my home server for learning and some home tasks.

Statistical fluke. ;)

Re: ⁠Btrfs has been deprecated in RHEL

#342

Earlier quoted context omitted.

I think a natural follow-up question is "Why Red Hat does not have engineers to support btrfs?" That is, if the lack of engineers is a symptom, what is the cause? I'm pretty sure, had RH wanted they could either hire or assign engineers to maintain the btrfs code, take care of patches from upstream, etc. So why didn't that happen? I wonder what is your opinion on that. I see a bunch of possibilities (not necessarily…

All this talk about Oracle is just plain stupid. Oracle doesn't control anything, the community does. One core developer still works on Btrfs from Oracle, the vast majority of the contributions come from outside Oracle. Now as to > "Why Red Hat does not have engineers to support btrfs?" You have to understand how most kernel teams work across all companies. Kernel engineers work on what they want to work on, and comp…

> Oracle doesn't control anything

Oracle owns a lot of patents and I suspect both ZFS and BtrFS rely on some.

Re: ⁠Btrfs has been deprecated in RHEL

#343
post #261

Earlier quoted context omitted.

Oracle has essential control of both "nextgen" filesystems that should be used in Linux - as Sun, they developed and licensed ZFS, and they are the chief contributors of BtrFS. Their refusal to release ZFS under a license that is compatible with the GPL is keeping it out of Red Hat's distribution. This move by Red Hat must be seen as a provocation of Oracle, to force either greater cooperation and compliance in produ…

Oracle uses RHEL for their Unbreakable Linux [0] distribution. The least thing they can do is open up ZFS for the Linux community. [0] - https://linux.oracle.com/

> open up ZFS for the Linux community.

More likely they'll support it only on their Linux.

Re: ⁠Btrfs has been deprecated in RHEL

#344

Earlier quoted context omitted.

All this talk about Oracle is just plain stupid. Oracle doesn't control anything, the community does. One core developer still works on Btrfs from Oracle, the vast majority of the contributions come from outside Oracle. Now as to > "Why Red Hat does not have engineers to support btrfs?" You have to understand how most kernel teams work across all companies. Kernel engineers work on what they want to work on, and comp…

Wholeheartedly agree that btrfs isn't ready for a real customer base. I wish SuSE would have learned that lesson before they pushed it as default.

It feels like reiserfs all over again.

Re: ⁠Btrfs has been deprecated in RHEL

#345

Earlier quoted context omitted.

Wholeheartedly agree that btrfs isn't ready for a real customer base. I wish SuSE would have learned that lesson before they pushed it as default.

It feels like reiserfs all over again.

Well, I am guilty of using reiserfs selectively (and with research + design) and having a really good experience with it. Maybe I should have done the same with btrfs but I took btrfs on faith and was burned.

Re: ⁠Btrfs has been deprecated in RHEL

#346
post #224

Earlier quoted context omitted.

I get the feeling you've never had to provide support for a distribution before. There are many guarantees that Red Hat or SUSE provide that are not provided by upstream projects. Freezing the release is the only sane way of doing it, and backporting fixes is necessary. There are exceptions to this, such as stable kernels (which was started by GregKH out of frustration of the backporting problem while at SUSE). Upstr…

Sadly more and more upstream wants to have their cake and eat it to. Just look at Flatpak, that is all about moving the updating and distribution from distros to upstream.

I think Flatpak won't end up solving the problem though. Mainly because it still requires distributions to exist and provide system updates, but also because it just makes the static binary problem (that distributions were made to fix) even worse.

Honestly what I think we need is to have containers that actually overlay on the host system and only include whatever specialised stuff they need on top of the host. So updates to the host do propagate into containers -- and for bonus points the container metadata can still be understood by the host.

Re: ⁠Btrfs has been deprecated in RHEL

#347
post #346

Earlier quoted context omitted.

Sadly more and more upstream wants to have their cake and eat it to. Just look at Flatpak, that is all about moving the updating and distribution from distros to upstream.

I think Flatpak won't end up solving the problem though. Mainly because it still requires distributions to exist and provide system updates, but also because it just makes the static binary problem (that distributions were made to fix) even worse. Honestly what I think we need is to have containers that actually overlay on the host system and only include whatever specialised stuff they need on top of the host. So up…

In the end i don't see it as a technical problem, but a mentality problem.

Again and again we see that without any financial incentive, developers are loath to put any effort into backwards compatibility and interface stability.

At the same time they all want people to be running their latest and shiniest.

So in the end, what will happen is that each "app" will bundle the world, or at least as much as they feel they need to.

Re: ⁠Btrfs has been deprecated in RHEL

#348
post #330

Earlier quoted context omitted.

> So, it's a definitely a nice-to-have, but not something i need, because i can handle dpkg/apt much better then i could handle filesystem internals. I don't think you're seeing my point. You wouldn't have do anything -- it would all be done automatically as long as your file system supports snapshots. BTW, to your "I know how to use dpkg/apt": It's not about knowledge. I could well be said to be at an "advanced" lev…

You're absolutely right. Still, dpkg doesn't support snapshots out of the box. I could fiddle around with it and i suppose i could make a snapshot before running "apt upgrade", but since that never failed for me, i would touch something very stable for little apparent benefit. Let's say Debian 10 will support btrfs snapshots on updates, i'll consider using btrfs for the next installation, but not before. Did you read…

> Still, dpkg doesn't support snapshots out of the box.

Yes, but it SHOULD, just because ALL REASONABLE FILE SYSTEMS SHOULD SUPPORT SNAPSHOTS. Therefore dpkg should assume that such support is avaiable, or at the very least take advantage of it, when available.

Just to reiterate: You (impersonal!), the "ignorant user", shouldn't have to even have to think about it.

Does this make my point clear?

(I'm only being this obtuse because you're saying "you're absolutely right", but apparently not seeing my point. I'm assuming it's some form of miscommunication, but it's difficult to tell.)

EDIT: Hehe, I'm sorry, that sounded much more aggressive than I intended. I just think that us software developers could and should(!) do much better by our users than we(!) currently do. My excuse is that most of my stuff is web-only, so at least I can't do the accidental equivalent of "rm -rf /", but...

Re: ⁠Btrfs has been deprecated in RHEL

#350
post #66

Unsurprising. Red Hat has not hired upstream Btrfs developers for years, where SUSE has hired bunches. Meanwhile Red Hat has upstream ext4, XFS and LVM developers. If you're going to support a code base for ~10 years, you're going to need upstream people to support it. And realistically Red Hat's comfortable putting their eggs all in the device-mapper, LVM, and XFS basket. But, there's more: https://github.com/strati…

https://github.com/redox-os/tfs
Post reply on HN