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.

By what strange theory does Slackware support systemd? And how is the conversation being "held back"? At least on LQ, I think it's been discussed to death to the point where there's really nothing new to say about it.

I can say one thing for certain: you do not know that anything concerning systemd in Slackware is likely or not. Hell, *I* don't.

A seemingly good idea that will fall apart as soon as someone overdoses on sedatives and their next-of-kin sue. Good luck with persuading a judge that some getout clause in a 3pt font prevents any liability attaching...

You're confusing the cost of legitimate operations with the cost of searching the key space. You don't want legit users to bear too much cost since everyone ends up paying that over and over, but you do want the cost of searching to be high since that's not something that people should be doing.

You don't need such fancy protective gear when doing Everest, which is just cold and lacking in oxygen, not outright chemically hostile and hot as hell. (Some volcanoes are even worse. The ones that spew fluorine gas (or hydrofluoric acid) are just awful...)

You're wrong there. It's used quite a lot in high-capacity digital image storage. Libraries, that sort of thing. You might have the space and time to waste on using standard JPEG and you might not care too much about the compression artefacts, but libraries really do care. (A billion high-resolution images is only a medium-sized library...)

This statement is bogus. 3rd parties cannot sue under copyright law. VLC is developed by multiple parties, some of whom wanted VLC in the app store & others who didn't.

Portraying this as Apple & VLC vs the FSF is a misrepresentation of the situation.

Is d) going to be "Profit!"?

If you think that's viable, you're spending too much of your life waiting at stop lights.

They still beat wireless through a 2' load-bearing stone (or brick) wall. Which is the GP's point.

Don't worry. They're just as bad in many other european countries too.

Fortunately for him, Terry Gilliam appears to be still alive. Terribly selfish that, not dying on you just so that you could lazily use a cliché like that.

Technically, it's about ensuring that you get what you think you have paid for and ensuring that you can use what you have paid for for whatever you want to. These things are absolutely fundamental to a free market even being possible.

I know it's enterprise software, but you're really not supposed to shove it up your ass each time you use it.

The way to deal with these people is to ignore whether they have the second hostage (assume he's already dead, even if that's technically premature) and to bomb the area, preferably with something like white phosphorous incendiaries. It also needs to be done soon, because people regard such actions less favourably when it is longer from the event which the punishment is being meted out for. Make it very clear that once someone starts killing hostages, reprisals will come. If you don't, the next damn terrorist group will think they can get away with this sort of thing too; you're not protecting those already captured, you're protecting everyone else.

It's a shame, but being this nasty is the only way of hammering home to idiots that fucking with is a seriously bad idea (unless you can act with more precision and kill just the terrorists). And it does work: it's been proved to work over and over throughout history. It probably needs to be accompanied with a full apology to any innocents caught up in the crossfire to mitigate incidental downstream trouble.

Pfffft, screw chipped squirrels, I want Squirrel Chips!