A shame, as BTRFS has just recently made major progress towards eradicating its only real dealbreaker, broken RAID5/6 support. It's also still got the backing of SUSE, Facebook, Oracle, and Fujitsu.
However, RedHat has decided to go for its own solution, Stratis. You can read about it in depth here stratis-storage.github.io/StratisSoftwareDesign.pdf but here are their plans from their requirements list 1.Make features easier to use in combination with each other: thin provisioning, snapshots, integrity, redundancy, multipath, encryption, hardware reconfiguration, monitoring, and a caching tier2. Simple and comprehensive command-line interface (a) Simple i. Single way to do things ii. Do not expose internal implementation details. Gives Stratis more implementation freedom, and of little value since internals are too complex to make manual user repairs practical iii. User typically will not use on a daily basis A. Consistent commands that a user can guess at, and probably be right B. Require explicitness from the user for potentially data-losing operations, such as giving a “–force” option. (b) Comprehensive i. User must master only one tool ii. Helps user learn: if task not possible through tool, it must not be worth doing (or a good idea)3. Programmatic language-neutral API for higher-level management tool integration (a) A clear next step for users after hitting the limitations of scripting the CLI (b) Encourages tight integration and use of all features by higher-level tools4. Event-driven monitoring and alerts (a) Monitoring and alert messages expressed in terms of Stratis user-visible simple concepts, not implementation details (b) Low CPU/memory overhead to monitoring (c) Only alert when action really is needed (d) Fail gracefully if alerts are unheeded5. Eliminate manual resizing of filesystems (a) Numerous problem reports throughout the years indicate that resizing filesystems is an area where users feel unease, due to potential data loss if a mistake is made. No real reason to require the user do this any more. (b) Simpler for DevOps (c) Makes storage “demand-allocated”, similar to virtual memory. Current technology allows us to manage a filesystem’s actual usage up (growfs) or down (thin provisioning).6. Initrd-capable (a) Allows root fs, all other filesystems except /boot to use Stratis. Needed for ease of use (b) Limited environment – no Python or DBus – but can use device-mapper7. Bootable (planned – see 11.6) (a) Feels like a “real” filesystem if no secondary filesystem is needed for boot (b) Enables Stratis features to be used by system image, e.g. booting from a snapshot, and allowing /boot to grow (c) Requires explicit support in bootloader (Grub2) (d) device-mapper not available8. Adaptable to emerging storage technologies (a) Persistent memory i. Block-appearing pmem can be used by Stratis ii. byte-addressible pmem see 11.69. Implementable in 1-2 years (a) We’re already behind, waiting another 10 years isn’t an option
This is just pathetic. The future will be Wayland tied to systemd (which will be required to use any graphic drivers).
Jordan Evans
Sounds good to me. I enjoy pulse audio where when I plug in a USB headset it works on all my machines. No script hacking bullshit. When I want to I can easily route audio between different sources and sinks. I enjoy systemd where I can launch applications after complex dependencies are met. I love that I don't have constant tearing on wayland and that windows don't have to redraw themselves everytime I move them around or put one on top of another. These systems are sometimes buggy as fuck, but they have reasons for existing. Particularly wayland my god X is such a piece of shit.
Dylan Cook
I assume the CLI utilities are being written in python like most projects do. They are not going to have python doing the actual FS parts.
Oliver Edwards
X is a dumpster fire, but Wayland isn't much better. This is an anecdote, but - I've never experienced any tearing with a proper xorg.conf (I don't use nVidia or a compositor, maybe that's your problem). GPU drivers will be bound to systemd, mark my words. I remember OSS just working too, and sndio + mixerctl on OpenBSD is way better than pulseaudio. Oh, and they're trashing pulseaudio (for pulsewire).
Brayden White
Its better in so many ways. First off its buffer based which means you don't have to redraw every time. Its very simple. Each program just gets a little buffer to write to. The programs are isolated. Having a connection to X does not give you access to everything on the screen. This ensures you need actual permission to screenshot.
The complaint people always have is that its not network transparent. Which sure its not.
It’s pipewire. Also, i’ve heard a lot of good things about OpenBSD’s sound system. It’s fortunate that Genode OS is using it, assuming it’s as good as you claim. If you want to know why Pulse was made, see again, specifically the opening part. Users would have consistent issues getting headphones to “just werk” without fucking around with some config. It also apparently is useful for people with more complex audio setups. In my experience it only fucks things up, but I’ve heard some positive experiences about it lately.
This. Wayland is worth it for the security alone.
Sebastian Lee
This is a good thing. People who don't need it won't need to install it. The people who do need this can install an X11 server, or VNC server, or a Windows RDC server that targets Wayland. There is nothing about Wayland that inherently prevents a network transparent display protocol.
Hunter Anderson
So, it only does very basic things like device input and display? that means that you'll need other programs for configuring devices and capturing the screen, correct? Do you really think they'll agree on a standard for these things? Answer - No. This is why we've had OSS, ALSA, pulseaudio, jack, ARTS, and (now) pulsewire.
Adrian Wright
pipewire*
Thanks for the correction.
Parker Smith
Systemd is not and will never be a dependency of Wayland. Wayland is intentionally retardedly tiny, pushing more work away from the protocol and into the individual DE projects. At most a DE or two might depend on it, but that could happen on X anyway (see GNOME)
And on that last point... Graphics drivers are in the kernel What the fuck are you on about?
Evan Baker
It was tongue-in-cheek. I'm sure RedHat wants a way to make every other init system useless, and that was just an example.
Anyone think this might have been done as a means of creating more competition between RHEL and SLES? It’ll be a war of the ZFS clones! Stratis vs. BTRFS! Let the autism begin!
