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.
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?
A new goodie tool.
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
"The need of a new partition manager stems from the fact that none of the existing GUI partitioning tools supports all modern storage technologies"
Does the backend -and kickstart, support all those "modern storage technologies"?
That's the important part. For a GUI-based installation, the ability to format -and install into, a single root partition is good enough for me.
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!
If their liveCD installer is any indication, I'm not going to touch this with a ten foot pole. Its behavior is essentially random, whether it comes to partition numbering, free space reporting, and partition creation.
https://xkcd.com/927/
I sure hope it won't be the geniuses who brought us the incomprehensible "new Anaconda" interface several Fedora releases ago.
And aimed at the same audience.
I hate the FOSS mentality sometimes. So much unnecessary reinventing the wheel when all that's need is some enhancement of an existing tool. It seems like it'd make much more sense to take GParted, a very mature, well-supported and proven tool, and extend its feature set to incorporate the "modern technology" they require, rather than create a whole new tool almost from scratch and deal with an unproved base. They can either work with the GParted developers to incorporate these new features, or fork it and do the work themselves.
Reusing existing tech is supposed to be the whole fucking POINT of FOSS - it's freely available code, take it and use what's already been developed and use it as a base to create something new/better. So many people though want to start from scratch because they believe that their implementation will be better. It's one of the reasons I see so many music players that do 90% of what Winamp can do for example, each player though doing a different 90% than the other. No-one seems to be able to collaborate in FOSS.
For surely they will want to integrate it.
mark my post.
"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."
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?
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!!
//How to know if an important back-end component of Linux will soon be replaced
if (component.name=="linux-kernel*") { false; }
else if (component.inventor=="Red Hat") { false; }
else { true; }
Indeed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Which means you actually understand partitioning and do not need some cretin "manager" to do it for you. Same here, although I use gparted for resizing and things like that.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
It was DOA as far as I was concerned. Redhat basically told the world "we don't care about the desktop" and it shows. Now, I still rely on Centos but I prefer debian and my users get mint. Fedora gets to make the false insinuation that they are redhat till stuf blows up or changes in midstream. It's not redhat and it's not a standard linx desktop. Fedora is what's left over after a bunch of junior hacks get done dicking around for the day. You get to pick up the pieces. Nobody in their right mind uses Fedora. It's just Like working on the zune. Fedora is what a free edition of windows would be with a lot less polish. I wish Microsoft would just release their own version of linux and get it over with. You Linux guys are no disciplined enough to stick with a project and see it through.
I agree with parent, and grand-parent. Now-a-days I use gdisk, though.
When I switched to Gentoo 10 years ago (from SuSE), I /had/ to learn fdisk.
Personally I feel anyone serious about learning Linux, should install and manage a Gentoo/Funtoo box for at least a year. I honestly find some of the stuff in RHEL/CentOS kind of cumbersome after having used Gentoo/Funtoo and all the handy tools that come with it for so long.
Good point. One sign of the cretinization of Linux use (also called "entering the mainstream") is that there are more and more people that can just use specific tools, but have no idea what they are actually doing. There people are then also "locked in" to a specific distribution. No doubt that is the intent of the tool-makers.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
"The need of a new partition manager stems from the fact that none of the existing GUI partitioning tools supports all modern storage technologies."
That would be a lie. If that is all, just contribute to Parted already. As always more will be at stake, probable things like "not invented here" and "I wanna have the power". And as a result we get to have a partition editor that needs Python??
I hope whatever its coming up with allows disk partition creation based on partition form kickstart scripts itself.
So we're stuck with either "impossible object" or "ten pounds of shit in a five pound bag".
Naming is hard, but it's not *that* hard.
I don't know about needing a completely new partition manager, but certainly needs to read GPT partitions. In GParted, there is one disk I have just for Windows7, Windows partitioned it, but GParted reads the drive as unpartitioned / available. I asked around and people were thinking it was partitioned wrong that's why invisible.... well if Windows partitioned it's own partitions wrong....
And please pick a better name than the proposed one, at least make the name pronouncable.
Take Nobody's Word For It.
when you don't need them.
Linux and Linux distros have always taken the priority to ship cutting edge features over tried-and-true software.
I think SSD partition alignment "just works" for all modern partitioning tools. It should be fine.
fdisk can do exact cylinders but complained about uefi
You probably mean GPT. There seems to a tool called gptfdisk that solves the problem.
When the partition tools jumped the shark and started using those 10^x units instead of 2^x, one can not be sure what is the actual alignment anymore.
Today it is practically always 1MB (1,048,576 bytes).
I am no partition manager expert, but if the existing most popular one is missing some features then why not implement them rather than producing yet another piece of software to fragment and complicate things. Are the existing ones that bad that they can't be improved?
Because I have a USB stick with GParted boot on it that does EVERYTHING and includes HFS, HFS+, NTFS, FAT32, ext2, ext3 and ext4. I think XFS is even in there.
Um, I don't think that is very likely:
https://lists.fedoraproject.or...
Um yes - and the two people mentioned in the Announcement have @redhat.com addresses. ;-)
Unfortunately, Mukt completely mis-reported this and Slashdot picked up their errors for the summary, which is making for a lot of confusion.
tl;dr:
1. blivet-gui isn't supposed to (and in fact cannot) 'replace' gparted in any reasonable sense of that term.
2. blivet-gui is a new application, but its backend is the Fedora installer's storage management code, which is a very old codebase. There is no new storage management backend being written here.
3. Lennart and systemd have nothing at all to do with this.
4. It wouldn't really be practical to 'contribute' this to gparted, as it would involve completely ripping and replacing gparted's backend and then very rapidly proposing significant changes to the GUI, and hence would be a project takeover by any other name.
5. blivet uses standard underlying tools for performing operations, it's just a logic/configuration layer for them.
1: what the original announcement says is that blivet-gui uses a gparted-like UI to make it instantly familiar for gparted users. It doesn't say anything at all about it 'replacing' gparted. That's a pure invention (likely based on a misunderstanding) in the Mukt article. See the original announcement at https://lists.fedoraproject.or... to verify this, if you like. There's no sense in which blivet-gui really *could* "replace" gparted, if you think about it. gparted is an independent project; Red Hat doesn't own or maintain it, so Red Hat can't stop it existing or being maintained. gparted isn't a significant component for either RHEL or Fedora: it's just a leaf package, an app like any other. It's not like anaconda uses gparted as its partitioning tool, or anything like that. So talking about blivet-gui 'replacing' gparted doesn't make any sense, not upstream, not downstream. So long as upstream gparted devs see a need to keep developing gparted, gparted will continue to exist upstream, and so long as a Fedora packager wants gparted to be in Fedora, it'll be in Fedora, whether or not blivet-gui or any *other* storage management GUI app is also in Fedora. We have lots of space in the repos.
2: the backend for blivet-gui is blivet: https://git.fedorahosted.org/g... (packaged in Fedora as python-blivet). This codebase is simply the storage management backend of anaconda (the Fedora installer) split out into its own repository. The split happened back in 2012: http://www.redhat.com/archives... . The intent was to allow for exactly this kind of code re-use. So there really isn't some kind of new NIH effort going on here: the storage management code is not new, all that's new is the light wrapper around blivet to produce a standalone GUI app rather than using it as a part of the anaconda installer. The underlying codebase has existed basically as long as anaconda has existed, which is rather longer than gparted has existed. anaconda dates back to 1999 (https://fedoraproject.org/wiki/History_of_Red_Hat_Linux ), gparted AFAICT dates back to 2004 (http://gparted.org/news.php?item=180 ).
3: Doesn't really need expanding on, but no, there is absolutely zero link to Lennart, systemd, or any other systemd developers.
4: so the reason to do blivet-gui at all, and the reason anaconda doesn't just call gparted for "partitioning" like ubiquity does, is it doesn't cover anywhere near the functionality we actually need for the Fedora (and, more to the point, RHEL) installer. gparted really is a *partitioning* tool, and there's a reason I keep referring to blivet as "storage management". It handles things that aren't just partitions. The most obvious examples are mdraid, LVM, and btrfs (insofar as btrfs acts as a volume management and redundancy system, not just as a simple filesystem like ext), but blivet has all sorts of other interesting capabilities too, primarily of interest t
I sincerely feel that Fedora's Partitioning UI is ABSOLUTELY HORRIBLE. It was the biggest *huh* and *ugh* when I installed Fedora 19 and 20. It made no sense what so ever. I remember using Anaconda like in early 2000 to install Red Hat 9 and Fedora Core something and that UI worked just fine. The new UI in my opinion only confuses users and is clearly tuned towards formatting everything the HDD might already have such as Windows NT based OS.
OpenSuse has a reasonably good partitioning UI. YAST isn't the best thing out there but gets the job done. Ubuntu had the best one last time I checked. It actually told you everything you needed to know and expressed that with smart well designed visual cues. Ubuntu's partitioning UI isn't imho perfect and it could use an "advanced mode" but so far Ubiquity is the best I've seen around in Linux world. The best "advanced mode" ships with the Debian-installer as it allows some really wicked and truly flexible partitioning schemes to be made.