If you look at a screenshot of blivet-gui, you'll see it doesn't use the same UI as anaconda.

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 to an enterprise audience (iSCSI, FCoE, blah blah buzzwords buzzwords). We've been interested for a while in the idea of having anaconda's GUI for actively changing disk layout be a separate process, and just having a GUI for assigning mount points within anaconda itself (or something along those lines), and this is a step towards that, as well as probably just being a useful tool for people. We can't use gparted for this purpose, because it's just not capable enough. It's really only a GUI wrapper for libparted. blivet sits on top of libparted...and also on top of btrfs-progs, cyrptsetup, device-mapper, lvm2, and mdadm (among others). It's inherently more capable and more complex. This is why we can't just "contribute" this work to gparted - they're really fairly different beasts, you can't just "contribute" blivet to gparted in much the same way you couldn't just "contribute", oh, say, the backend of emacs to the frontend of nano. It'd be a ground-up rewrite by stealth, effectively. the gparted you got out would be nothing like the gparted you started with. (to discount the humdrum technical fact that they're not written in the same language, of course.)

5: even if you consider blivet as if it wasn't one of the longest standing storage management codebases around and thus accuse it of NIH, it doesn't really work, as it just sits on top of perfectly standard tools. blivet *uses* libparted (via the pyparted wrapper). it uses e2fsprogs to create ext partitions, mdadm to create mdraid arrays, dosfstools to create FAT partitons, btrfs-progs to handle btrfs devices, lvm2 to handle LVM. it's really a logic and configuration layer on top of those tools.

Yup. From the start of the ruling:

"We transferred the case to this court on our own motion. [FN3] We now conclude that the answer to the reported question is, "Yes, where the defendant's compelled decryption would not communicate facts of a testimonial nature to the Commonwealth beyond what the defendant already had admitted to investigators.""

So: don't admit the disks are yours, don't admit you know they're encrypted, don't admit you can decrypt them. (Of course, "don't say anything at all", the old standby, covers all of those, thus once more proving its value.)

"The details of the Imitation Game aren't secret, or even hard to find, and yet no one seems to reference it."

Except, well, at least four of the stories I've seen on the Turing test this week. It really doesn't seem that obscure.

"Kevin Warwick gives the bot a thumbs up"

That's a point *against*, not a point in favour.

Adam's Law of British Technology Self-Publicists: if the name "Sharkey" is attached, be suspicious. If the name "Warwick" is attached, be very suspicious. If both "Sharkey" and "Warwick" are attached, run like hell.

So, either they got attacked by someone who was able to both deface the website and *sign code with their GPG key*, or the announcement is genuine.

I think the obvious response is precisely identical in either case...

yeah, it may be worth adding a note about that on the download page...but one of the things that'll be done as part of fedora.next is a complete revamp of that site area, so i'll wait till that's in planning to suggest the idea. thanks.

It's not just about the install image, it's actually about building useful stuff into each product (and also allowing the same things to be configured in different ways in the different products, which is another part of why they can't just be package sets). For instance, the 'role' management for Server: https://fedoraproject.org/wiki... .

That's what the *live* installer does - because that's all a live installer can do, really, unless you make a live image with a DVD-size package repository, which not many people really seem to want.

The *non live* installer still lets you choose the deployed package set.

The three product approach isn't simply about the deployed package set, though. It involves really rather a lot more than that. Hard to go into details in a Slashdot comment, but see https://fedoraproject.org/wiki... .

Er...no and no? That wasn't a question about her reason for leaving, it was just a general question about Fedora's future.

Disclaimer: I work for RH, but I have nothing at all to do with any of this stuff (I work on Fedora).

AFAICS, the WSJ alleges #2, but we are very clearly stating that WSJ is wrong and it's just #1 (we'll support your RHEL install no matter what you have running on top of it, just like we always have, we just won't support the OpenStack bit if it's not RH OpenStack, or whatever the hell we call it, I don't know.)

"How many of us liked shop? How many young people should be training for skilled manufacturing and service jobs rather than getting history or political science degrees?"

I don't know, perhaps you could ask someone who could give you an answer based on prior experience - like an economic historian?

Carpenter Who Cut Off His Fingers Makes "Robohand" With 3-D Printer, Cuts Off Other Fingers With 3-D Printer

"The next time your mail goes down, should we know the name of the guy whose code flaw may have caused that?""

Two words for you: "git blame".

A leading contender for the Francis Fukuyama Award For Public Fatuousness.