Slashdot Mirror


Fedora To Get a New Partition Manager

sfcrazy writes Developer Vratislav Podzimek has announced the next-gen partition manager for Fedora, blivet-gui. It is eventually going to replace GParted, the most popular GUI based partition manager, found in all major distros. The new tool is named blivet-gui after the blivet python library (originally Anaconda's storage management and configuration tool). The need of a new partition manager stems from the fact that none of the existing GUI partitioning tools supports all modern storage technologies. Fedora's Anaconda base supports all, though, and is hence chosen as the back-end for this new tool. The application is only a few months old but is already looking nice and useful. Features like RAID and BTRFS support are being worked on. Vojtech Trefny is the other developer working with Vratislav on blivet-gui. Here's the announcement.

18 of 170 comments (clear)

  1. So.... by Anonymous Coward · · Score: 4, Insightful

    Fedora is going to replace GParted none of the existing GUI partitioning tools supports all modern storage technologies. Theyre replacing it with blivet-gui which doesnt support features like RAID and BTRFS.

    That hat too tight?

    1. Re:So.... by ysth · · Score: 3, Insightful

      No, we need such a command line tool or possibly library with a command line tool wrapped around it. The GUI is entirely optional and certainly shouldn't be bundled.

    2. Re: So.... by Guy+Smiley · · Score: 5, Interesting

      In typical open source fashion, their replacing a tool (GParted) that doesn't support a few features they want with a new one that (at least initially) didn't support _any_ features at all because it was written from scratch.

      Why not just fix GParted to add the few missing features instead of writing a completely new too? The new one will of course itself not support all the features GParted had, but instead be chok full of new bugs that will take years to find and fix...

      Why is it that everyone wants to reinvent the wheel instead of using and improving the tools we already have?

    3. Re: So.... by bored · · Score: 5, Insightful

      I considered moderating you, but I think this is really a case of <whine> "C++ is haaardddd, learning it enough to understand how to plug in a new module is going to take me months. Instead I'm going to rewrite it" </whine>

      Or similar bullshit by people who think "scripting" languages are appropriate for base system tools. Now you will have python dependency hell every-time you want to do something simple like repartition your disks. Oh, and is that project python 2 or python 3? On and on..

      Frankly, its fsking stupid and its another sign that redhat is jumping the shark.

      Plus, do you really want to depend on the skills of some "leet" hacker that thinks python is an appropriate tool for this?

    4. Re: So.... by thegarbz · · Score: 3, Insightful

      In typical open source fashion, their replacing a tool (GParted) that doesn't support a few features they want with a new one that (at least initially) didn't support _any_ features at all because it was written from scratch.

      Why not just fix GParted to add the few missing features instead of writing a completely new too? The new one will of course itself not support all the features GParted had, but instead be chok full of new bugs that will take years to find and fix...

      Why is it that everyone wants to reinvent the wheel instead of using and improving the tools we already have?

      In the typical open source fashion people thinking they're experts will blindly criticise someone's decision without understanding it. How about you start with blivet-gui is not a partition manager and then work onwards from there with your understanding.

      Blivet-gui is a standalone implementation of the storage manager used during the install process. Yes it can partition, and in the true open source fashion it uses another program to do so (parted), but that's a small subset of what they want to use it for which is more like be a one stop shop for all disk management, volume management, and RAID management.

      Please put the pitchfork away.

    5. Re: So.... by DrXym · · Score: 3, Informative

      Or similar bullshit by people who think "scripting" languages are appropriate for base system tools. Now you will have python dependency hell every-time you want to do something simple like repartition your disks. Oh, and is that project python 2 or python 3? On and on..

      gparted is a graphical tool for editing partitions and already has a raft of dependencies. One more won't make a difference especially since python is used increasingly in core distributions for scripting instead of bash.

      Secondly, perhaps the reason that gparted is considered a mess is precisely because it mixes up the graphical parts and the low level stuff in one package, a problem compounded because the installer also has its own partition editor. Fedora appears to have written a layer called blivet to abstract out partitioning from the installer GUI and therefore it makes sense that they use it in the desktop also.

  2. The origin of the term "blivet" by Nimey · · Score: 3, Informative

    Ten pounds of shit in a five-pound bag, i.e. a nasty, dirty situation. It seems to have originated around the 1940s as US military slang.

    --
    Hail Eris, full of mischief...

    E pluribus sanguinem
    1. Re:The origin of the term "blivet" by Anonymous Coward · · Score: 3, Funny

      Ten pounds of shit in a five-pound bag,

      A fantastic deal! if you're a dung beetle.

    2. Re:The origin of the term "blivet" by Anonymous Coward · · Score: 4, Informative

      http://en.wikipedia.org/wiki/Blivet

      It is a poiuyt, devil's fork or widget, is an undecipherable figure, an optical illusion and an impossible object. It appears to have three cylindrical prongs at one end which then mysteriously transform into two rectangular prongs at the other end.

  3. Why not contribute to gparted? by sayfawa · · Score: 4, Insightful

    Instead of making another program, I wonder what was wrong with sharing the code with gparted so that they could incorporate support for more filesystems?

    TFA didn't say if that option had been explored.

    --
    Free the Quark 3 from asymptotic confinement! Bring your charm! Don't get down! All colours and flavours welcome!
    1. Re:Why not contribute to gparted? by Burdell · · Score: 5, Informative

      Because (as usual) the summary got it wrong. This is not a partition manager, it is a disk/filesystem manager. Partitions make up one part of that, but it is also intended to manage LVM, RAID, btrfs filesets, etc. I believe it uses the parted library on the backend for partitions.

      This is based on the years-of-development code used in the backend of anaconda, the Fedora/Red Hat installer. The code has been pulled out, split up into a library, and set up for stand-alone use (after install). I believe the intention is that anaconda keeps using the library, but now there will be the same interface during install and afterwards for managing disks and filesystems.

  4. Re:Damn the GUI! by phantomfive · · Score: 4, Interesting

    Yeah, another example of NIH coming from RedHat.

    --
    "First they came for the slanderers and i said nothing."
  5. We have a winner! by dbc · · Score: 4, Informative

    "RedHat is also known for having a bad case of Not-Invented-Here as well as wanting more control over a significant piece of their distro."

  6. What does it support that others don't? by dbc · · Score: 3, Interesting

    Not flamage, this is data-seeking. The announcement only vaguely states that existing tools don't support all modern storage technologies. So, what are the technologies where blivit gets a "yes" and gparted gets a "no" in the "supports " column?

    1. Re:What does it support that others don't? by eulernet · · Score: 5, Funny

      slashdvertisement:

      Blivet: yes
      GParted: no

  7. Command line? by ToasterMonkey · · Score: 3, Interesting

    I'm completely fine seeing things move away from the older "GUI driving non-interactive commands in the background" model, to GUIs and CLIs that are built on shared libraries, because that potentially gives us THREE usable interfaces. However, is it normal for a CLI to lag behind the GUI now in Linuxland?

    I see that blivet comes from Anaconda, so I expect some integration there.
    It seems like a good CLI could be used to avoid the awkward practice of writing out a kickstart partition fragment from the pre section. We could just drive Anaconda's partitioning directly from %pre with shell logic instead of pooping out Anaconda-ese to be parsed later.

    So where's my damned anaconda partitioning CLI already, this would affect more [important] people than yet another partition GUI!!

  8. Re:How to know if a component of Linux.. by Nimey · · Score: 5, Funny

    Could be worse: it could have been written by Lennart Poettering.

    --
    Hail Eris, full of mischief...

    E pluribus sanguinem
  9. Anaconda's base supports all? by Antique+Geekmeister · · Score: 3, Insightful

    The only reason that "anaconda's base supports all" is because anaconda, and kickstart tools, have the ability to support '%pre" scripts that allow manual use of hte command line partitioning tools to tune the partitioning as desired, and completely skip anaconda partition. Anaconda has never, and from all signes will never, be able to support all disk management and partitioning tools.

    Since it's a Python based wrapper for the actual system tools used, features can be added. But there will be inevitable mismatches between configurations manageable through anaconda, and configurations manageable through command line tools for new disk and filesystem tools. And anaconda's use in system critical critical tools like kickstart mean that it _must_ be thoroughly tested before updates. This will slow feature addition in a way that gparted, or other tools, need not support.