On Fri, 2014-09-05 at 23:47 -0700, Adam Williamson wrote: > On Fri, 2014-09-05 at 18:03 +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. > > Well...I agree that in perfect theoretical engineering land, it'd be > nice if blivet-gui had a better privilege model. I think you're being > way too unnecessarily harsh, though, and missing a rather major point. > > blivet-gui is not 100% new code. The new bit is just the relatively thin > GUI wrapper. The really hard code - the bits that do the partitioning - > has existed for 15+ years: it's anaconda's partitioning code (lately > split out into python-blivet). And that code has *always* assumed it'll > run as root, because it's part of an installer that always does. > > If you want to use the blivet code as the base for a standalone GUI > installer and add a better privilege model, that was always going to be > a retrofitting job - even if you did it before doing this initial 0.1.x > release of blivet-gui, you're still retrofitting. It's really not a > significant difference. > > I can believe it'd be hard work, but I think you overstate the case by a > long way when you say it'd be impossible. It may be finicky work, but it > seems unlikely that it'd be easier to write an entirely new partitioning > app with all of blivet's capabilities from the ground up (with a good > privilege model) than it would be to take advantage of all that existing > code for doing the very difficult and complex work of partitioning, and > retrofit a decent privilege model onto it. well given blivet is a library, shouldn't it be simple enough to put it behind a dbus interface and have the GUI and actual operation be separated by dbus and authorized via mechanisms like polkit or similar ? That should pretty much solve the privilege separation between gui and core code. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
