Fedora To Get a New Partition Manager 170
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.
So.... (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?
Re: (Score:1)
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?
The hat is cool!
Re: (Score:3, Funny)
Are you the Judean People's Front?
Listen. The only people we hate more than the Romans are the fucking Judean People's Front.
P.F.J.: Yeah...
JUDITH: Splitters.
P.F.J.: Splitters...
FRANCIS: And the Judean Popular People's Front.
P.F.J.: Yeah. Oh, yeah. Splitters. Splitters...
LORETTA: And the People's Front of Judea.
P.F.J.: Yeah. Splitters. Splitters...
Re: (Score:2)
splitters
You call that a splitter? This [wikimedia.org] is a splitter.
Re: So.... (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?
Re: So.... (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?
Re: (Score:1, Insightful)
This is a partition editor. It gets run O(1) times on each computer, within an environment that, if python is not supported, it should not be run.
Re: (Score:1, Insightful)
Give it a rest. Someone pissy enough about not having python installed isn't a wuss using a GUI partition tool. You're the fscking stupid one.
Re: (Score:1)
Re: So.... (Score:4, 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.
Re: (Score:2)
Microsoft wasn't thoughtful enough to provide a port of Visual Basic for Linux. But there are lots of programs that deserve something between quick-and-dirty and full-on C or Java. Perl and Tcl were kind of filling that space, but one's write-only and the other isn't a complete system, but rather a way of stringing system tools together, one step up from raw shell scripts.
Python is Linux's version of Visual Basic. It's easy to understand, has a rich set of system interface libraries (which install without t
Re: (Score:2)
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.
If you do not like the new tool, continue with Gparted. I am sure the Debian guys and SUSe will arrange for the RAID stuff to be included in Gparted.
Re: (Score:2)
God knows why anyone moderated your comment as insightful.
1. Fedora / RedHat is targeting, wait for it, Fedora / RedHat. End of story.
As someone that maintains a fairly large DPI (kernel/user-land) software and a management software that uses PyGI, I can from attest from personal experience that both PyGI and PyGTK under both Fedora and RHEL are top-notch with zero dependencies issues.
2. PyGI is *far* easier to use than Qt/C++. We wrote the original management code in Qt, but switched to PyGI as it increase
Re: (Score:2)
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?
Considering that Anaconda itself is written in python, that shark is about 15 years in the rear-view mirror. They didn't pick the name "Anaconda" for nothing.
I guess that python was an appropriate tool after all.
Re: (Score:1)
Q: Why not just fix GParted?
A: NIH [wikipedia.org]
I wish this was a joke.
Re: So.... (Score:4, 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.
Re: (Score:1)
... Have your bothered to read the release message instead of rushing to press the "save" button you'd notice the following [1]:
"Why not use GParted you ask? The reason we came up with blivet-gui is that none of the existing storage management tools supports all storage technologies supported in modern Linux distributions. Anaconda does support them all so it's only logical to take Anaconda's storage backend, combine it with a nice, intuitive and in general user-friendly frontend and build a standalone appl
Re: (Score:2)
Re: (Score:2)
Fedora isn't. It just some guy choosen to announce his project on fedora-devel mailing list.
Re: (Score:1)
Re:So.... (Score:4, 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.
Re: (Score:2)
I hope this doesn't infect Debian like PulseAudio and systemd.
Are you one of those bearded fellows who tugs at his suspenders as he pines for the days of pine over a serial line or 9600kbps phone line? Do you use TECO because EMACS is too newfangled for you?
Now amittedly I'm a desktop user of Fedora so the change to systemd hasn't really affected me much (I still use the classic service commands which redirect to systemd), but... pulseaudio is better than what came before. Yes, it took time to polish the thing and iron out some issues, it didn't work by default wi
Re: (Score:2)
The execution is shit. If I mute it, it doesn't unmute without going down into alsamixer and unmuting it. Mute is one way. Isn't that shit enough?!
I use Pulseaudio on Fedora 20. Mute/unmute works just fine.
Re: (Score:2)
Without PA, the mute and unmute just work each time one presses the button for it in the keyboard.
I run pulseaudio on Fedora 20, mute/unmute works fine every time I press the button on the keyboard.
Re: (Score:1)
This is an email from Lennart Poettering to the Fedora Devel list dissing the Blivet GUI project due to implementation details:
https://lists.fedoraproject.or... [fedoraproject.org]
So Lennart Poettering actually really is involved, but in a rather different way than you would expect. :)
oh boy! (Score:1)
The origin of the term "blivet" (Score:4, 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.
Re: (Score:3, Funny)
Ten pounds of shit in a five-pound bag,
A fantastic deal! if you're a dung beetle.
Re:The origin of the term "blivet" (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.
Re: (Score:2)
I've always heard that it was six pounds. It's funnier because the bag might survive or it might break but you won't know when or where.
Re: (Score:1)
Damn the GUI! (Score:3)
"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.
Re:Damn the GUI! (Score:5, Interesting)
Re: (Score:1)
The emotional reaction to your statement is something that I had to remind myself shouldn't be said in public, so I won't repeat it here.
Keep in mind that NIH at RedHat makes very little sense in the big scheme of things, when they fund at least 60% of all open source software development. Sure, they probably don't fund any geneology software or the latest MP3 player, but you'd have very few compilers, system software, etc without RedHat picking up the bill.
So, not invented here rarely makes sense with Red
Re: (Score:2)
The emotional reaction to your statement is something that I had to remind myself shouldn't be said in public, so I won't repeat it here.
Ulrich Drepper, is that you?
Re: (Score:2)
Re: (Score:2)
It's just that much more fun to create one's own code base and fix one's own bugs than to learn someone else's
So true
Re: (Score:2)
lol-ing at your comment, and your .sig :D
Re: (Score:2)
Re: (Score:1)
"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.
Yes - the blivet storage management library supports alsmost any existing data storage technology you can come up with and then some more. Thats the reason why Blivet GUI came to be - the functionality is already there, it just needs to be exposed by a graphical user interface.
Why not contribute to gparted? (Score:5, Insightful)
TFA didn't say if that option had been explored.
Re: (Score:1)
blivet-gui is Gtk application written in Python, like all of redHat's tools. I don't know what gparted is written in, but it's probably not Python.
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.
We have a winner! (Score:5, 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."
Re: (Score:2)
Which makes them not particularly different than Canonical. Or IBM. Or Microsoft, for that matter.
Re:Why not contribute to gparted? (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.
Re: (Score:1)
It is based on the blivet storage management library:
https://github.com/dwlehman/bl... [github.com]
Which is also used by the Anaconda Fedore/Red Hat Enterprise Linux installer:
https://fedoraproject.org/wiki... [fedoraproject.org]
And Open LMI:
https://fedorahosted.org/openl... [fedorahosted.org]
But it might indeed use libparted to create the actual partitions.
Re: (Score:2)
My guess the answer is that then there would be two separate code bases, one in gparted and another that anaconda uses. Considering so much Fedora/RedHat is built around anaconda, it makes sense to reuse some of anaconda code in places other than installer.
Re: (Score:2)
Besides that fdisk and gparted have totally different missions, you mean?
Re: (Score:2)
So blivet and parted have totally different missions, I guess?
*I don't know the fuck what's so different between fdisk and parted, besides support for newer stuff like GTP partition tables.
Uses Anaconda? (Score:1)
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.
Re: (Score:1)
Last time I tried, Fedora managed to install next to Ubuntu, without problems. The only distro that without fail, trashes dual-boot, is Windows
Re: (Score:1)
Oblig. XKCD (Score:1, Redundant)
https://xkcd.com/927/ [xkcd.com]
Re: (Score:2)
An application is not a standard.
Re: (Score:2)
Technology repeats itself. Perhaps you see a message behind the surface? Do you know how often the letter "q" appears on slashdot? Do you complain about that one?
On the internet things are cool only a very short time. If it were about cooless, this would have disappeared a long time ago.
Re: (Score:2)
And you've read every one of them, just to verify your conjecture?
Who's designing the UI? (Score:1)
I sure hope it won't be the geniuses who brought us the incomprehensible "new Anaconda" interface several Fedora releases ago.
Re: (Score:2)
what do you mean several releases ago. It's still not as good as it could be in Fedora 20. IIRC it still doesn't let you individualize the packages installed, only letting you select "groups". One of my goals as a Fedora user is to NOT have to deal with the installer and I pray that "fedup" works properly so I don't have to.
Idiots (Score:2, Insightful)
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
Re: (Score:2)
that worked great for openssl http://en.wikipedia.org/wiki/Heartbleed [wikipedia.org]
their solution? a fork to libssl without all the messy kludges for various vendors/platforms.
Re: (Score:3)
Exactly - a fork, not a rewrite.
Re: (Score:2)
take it and use what's already been developed and use it as a base to create something new/better,
while letting the original developers take all the credit
Fixed that for you.
Also, making changes to somebody else's code involves the risk of introducing serious bugs. So essentially, what you are proposing is a lose/lose situation.
Re: (Score:1)
Don't let the systemd people know (Score:1)
For surely they will want to integrate it.
Pottard will have this in systemd before weeks end (Score:1)
Re: (Score:1)
Um, I don't think that is very likely:
https://lists.fedoraproject.or... [fedoraproject.org]
What does it support that others don't? (Score:4, 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?
Re:What does it support that others don't? (Score:5, Funny)
slashdvertisement:
Blivet: yes
GParted: no
Re: (Score:1)
The really big ones for me are LVM2 and encryption support. New enough version of GParted can see such containers, but won't touch them.
Re: (Score:1)
No idea what will be included in blivit in the long run, but at least AFAIK, parted lacks the following:
- lvm [1] [2].
- cryptofs [3]
- Complex software RAID setups (usually w/ lvm) [1].
- Network based storage management (iSCSI, etc).
- Gilboa
[1] https://www.gnu.org/software/p... [gnu.org]
[2] AFAIK gparted *does* support LVM, but it requires the LVM to be inactive while being used. Which more or less makes it useless when trying to management the storage on a production server...
[3] https://bugzilla.gnome.org/sho... [gnome.org]
Command line? (Score:4, 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 [redhat.com] 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!!
Re: (Score:1)
How to know if a component of Linux.. (Score:2)
//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; }
Re:How to know if a component of Linux.. (Score:5, Funny)
Could be worse: it could have been written by Lennart Poettering.
Re: (Score:2, Funny)
Hey, you watch your tone! Lennart's arguably leading Linux development almost single-handedly now. Linus might be focused entirely on the kernel, but Lennart is doing all the work on system elements that are crucial to bring Linux into modern times. After Linus, Lennart's now the most prolific (and famous) Linux contributor of all time.
Of course I'm just an AC, so there's no reason to listen to me. But I'm sure once Bennett Haselton write an a
Re: (Score:1)
It was a (poor) attempt a joke you stupid fucks. Clearly the mention of Bennett should have made it clear, as well as the suspiciously high praise of Lennart. But I suppose you're all idiots who can't grasp subtleties. Either that or you're just all stupid fucking americans.
Anaconda's base supports all? (Score:4, 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.
Do you Slashdoters really use Fedora? (Score:1)
Re: (Score:2)
Then I guess I'm not in my right mind.
I like Fedora a lot. I like the desktop environment (Gnome3 has really grown on me). Fedora moves at a decent clip to track with the latest and greatest without a lot of hassle. I have always liked RedHat/Fedora's PXE/kickstart installer. I like the big projects RedHat/Fedora is working on like FreeIPA, OpenStack packaging, GFS2, KVM, OpenLMI, CloudForms, and oVirt. RedHat has spent a lot of money buying some of the companies that created some of that software and the t
Re: (Score:2)
I have been using RedHat, Fedora, and CentOS as my personal desktop for a decade and CentOS is what I installed on desktop machines I managed. The meme that RedHat is no good for desktop is highly overblown. Just checked out CentOS 7 with Gnome, and thought the DE was still alright.
One of my favorite things about RHEL/CentOS is a truly stable "enterprise grade" release cycle, meaning each version is supported for many years, but they give you updated installers with new drivers and such to be able to use th
Lie (Score:2)
"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??
Re: (Score:3)
It's not rewriting parted. Parted can't handle all modern storage technologies as it only deals with partitions which are only one part (pun intended) of the picture. In the [your favourite distro here] installer the UI calls out a *suite* of tools just like Blivet-GUI does. Previously in Fedora this was all piled into Anaconda - but now it is split out into this "Blivet-GUI" thing.
If you bothered to read the articles or browse the source you'd know that it depended on Blivet and subprocess calls to normal
hmm (Score:1)
Blivet? (Score:2)
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.
Re: (Score:2)
Touché.
New partitioner (Score:2)
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.
The best thing about partition managers is (Score:1)
Why not add what's missing to existing tools? (Score:2)
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?
That's really odd (Score:2)
This is rumour control, here are the facts (Score:3)
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... [fedoraproject.org] 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... [fedorahosted.org] (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... [redhat.com] . 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
Re: (Score:2, Informative)
And aimed at the same audience.
Re: (Score:2)
Indeed.
Re: (Score:2)
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.
Re: Still using /sbin/fdisk here.. (Score:1)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
fdisk can do exact cylinders but complained about uefi
You probably mean GPT. There seems to a tool called gptfdisk that solves the problem.
Re: (Score:2)
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).
Re: (Score:2)
If you look at a screenshot of blivet-gui, you'll see it doesn't use the same UI as anaconda.