On Tue, Jun 30, 2020 at 5:42 AM Steven Whitehouse <swhiteho@xxxxxxxxxx> wrote: > > Hi, > > On 29/06/2020 23:57, Markus Larsson wrote: > > On Mon, 2020-06-29 at 18:51 -0400, James Cassell wrote: > >> On Mon, Jun 29, 2020, at 6:43 PM, Markus S. wrote: > >>> Why not Stratis? > >> Stratis cannot be used to build the root filesystem. (It's been > >> answered elsewhere in the thread.) > > Are we sure? > > https://github.com/stratis-storage/stratisd/issues/635 > > While it might not be super there yet it seems it is technically > > working (I may be wrong I have done 0 tests). > > But given how new that is and that tolling around it isn't there it > > pretty far from being a viable default. > > It is perhaps also worth mentioning, since I've not seen it elsewhere in > this thread, that Stratis is part of the (larger) Project Springfield. > This is aimed at improving the overall storage/fs management experience, > and there are a number of parts of that landing in various places at the > moment. There is more to come, of course, but the overall aim is > improved user experience for whatever combination of fs/block devices > are in use, > This is the first time I've ever heard that codename, and you should really change it, because that name is already used for cloud-based security fuzzing from Microsoft Research. It's a great idea, though! Improving the UX of storage management is generally a good thing, in my view. Btrfs provides significant improvements in this regard, but there can be even more. Tools like SSM[1] were great attempts at making the LVM experience not suck. Cockpit does a good job of making handling storage management a lot more approachable, too. I'd be curious if you are only thinking of server cases, or if desktop cases are also being considered. Historically, projects like these from Red Hat are largely only for the server... [1]: https://github.com/system-storage-manager/ssm -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
