blivet-gui announcement

[David Cantrell]

On Fri, Sep 05, 2014 at 06:03:58PM +0200, Lennart Poettering wrote:
> On Fri, 05.09.14 11:52, Matthias Clasen (mclasen at redhat.com) 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 at redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT