On Fri, Sep 05, 2014 at 06:03:58PM +0200, Lennart Poettering wrote: > On Fri, 05.09.14 11:52, Matthias Clasen (mclasen@xxxxxxxxxx) wrote: > > > On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: > > > On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: > > > > > > > > ----- Original Message ----- > > > > > Good news, everyone! We (me and CC'd Vojtech Trefny) would like to > > > > > introduce you the next generation tool for storage management -- the > > > > > **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python > > > > > library (originally Anaconda's storage management and configuration > > > > > tool) inspired by GParted and other storage management tools. Why not > > > > > use GParted you ask? > > > > > > > > Actually my question is "why not gnome-disk-utility?" :) > > > Because it doesn't work well with LVM, RAID, BTRFS and a combination of > > > them. > > > > Leaving LVM out was an explicit decision, because of all the system > > integration problems with LVM. It works fine with RAID and btrfs as far > > as I know. Do you have any concrete complaints about the RAID or btrfs > > support in gnome-disk-utility ? > > Also, note that gnome-disk-utility actually properly separates out the > unpriviliged UI from the priviliged backend in udisks. > > In this day-and-age we should not write new programs anymore that > require the entire UI stack to run as root. We should really get away > from doing something like that. In the blivet-ui docs "su" is the > recommended way to invoke the program, and that's really wrong for a > graphical one. > > gnome-disk-utility got that right. the new blivet ui did not. And this > is not something you can add as an afterthought, you actually need to > do your homework and split things up into privileged and > non-priviliged parts from the beginning. > > The blivet-ui thing in this regard is certainly not an improvement over > g-d-u, it's a step back. Blah blah blah blah blah. Don't be such a negative nelly. This doesn't have to be a competition between program A and program B. One doesn't have to "win". People have different wants, desires, needs and there's certainly room for more than one. There's certainly room for more than one /sbin/init. Vratislav and Vojtech, thank you for this announcement. Excellent work and I look forward to seeing the contributions and progress from the community. Thanks, -- David Cantrell <dcantrell@xxxxxxxxxx> Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
