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...
[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...

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 increased that rate of the development by 3/1. We may switch back to Qt due to performance issues and lackluster mutli-threading support (Known python limitation) and problematic Windows support. (Both of which are non-issues when it comes to *Linux* storage management)
3. I can agree that if you want to scan incoming packets at 150Gbps using software only, or write output at 1GB/s, you'd most likely need C++ or even C/asm combination. But what-exactly prevents python from calling a couple of syscalls to executing /sbin/cryptsetup / /sbin/lvm or /sbin/mkfs.ext4? What exactly makes Qt/C++ better at calling external binaries (such as the one mentioned above)?

- Gilboa

... 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 application for storage management."

So, I assume that Fedora should also throw out their Anaconda installer, and somehow write a new installer based on parted (the library behind gparted), just so they "won't reinvent the wheel"?
Beyond that, what makes you so sure its even remotely possible to add iSCSI, BTRFS, LVM and Cryptofs support to gparted? As you are so quick to judge that Fedora is reinvent the wheel due to non-technical reasons, I assume you already know from personal experience that there are no design issues in adding the "missing features" to parted.

[1] https://lists.fedoraproject.or...

Happens to me far too often on my Windows VM's, LibreOffice windows and even on the Chromebook that I use to type this message on (on normal Linux machines I have Firefox w/ VI plugin).

/* OT side note */
Actually, GCC's performance under windows *greatly* depends on the type of code being executed.
E.g. We (my company) uses GCC under both Linux and Windows, even though we support VC 2K5/8.
At least in our case, GCC (mingw-64) was ~10-20% faster than VC 2K5 and has far, far, far, broader features list (E.g. Very partial macro support, no in-line assembly, 'managed' version of CRT functions, etc)
Plus, can build the Windows binaries on our Linux build systems (a major plus) using Fedora's extensive MinGW support.

Per subject at hand, if you raise the warning level to the maximum (-Wall) and remove a couple of noise factors (-Wno-multichar), at least in my view, GCC tends to be far more informative than VC 2K5 - which in turn, tends to throw a lot of unused variable and deprecated use of CRT function warning, but nothing really major.

- Gilboa

I'll give you the benefit of doubt that you're not simply trolling.

In the last two years I've experience two SSD bricks on my main Xeon workstation (2 x X5680, 36GB RAM, 6+1 x 320GB enterprise SATA in software RAID6, running Fedora 19 x86_64).
On the other hand, the 5 (!) year old 320GB enterprise SATA drivers are working like new (hence I've yet to replace them).
Now, back when I had the SSD's I used them as a fast cache, but for the life of me I couldn't feel the difference. (Can same the same about the occasional breaking).
Sure, firefox would launch *marginally* faster, but:
1. I boot once every major kernel release (or major security issue).
2. With anywhere between 10-20GB of free RAM (depending on the number of active VMs) most of the software I used is cached.
3. Even when compiling a large project, CPU is usually the limiting factor (even w/ 48 jobs).

So, would I feel the difference on a single disk laptop? Sure!.
Do I feel the urge to add a third SSD to my workstation? Do I trust them enough with my work? Doubt it.
Guess I'll have to see how the Linux kernel's bcache works and how well it handles bricked SSD's.

- Gilboa

Semi-OT: A word of friendly warning:
A couple of months ago (year?) I bricked a 120GB Intel 520 w/ the latest firmware (not sure
if it was 400i) w/ ext4 on Fedora x86_64. (Second bricked SSD in 12
months)
A *very* short power shortage crept under my APC UPS and bricked the SSD.
Amazingly enough, the power shortage didn't crash the machine - which
continued working off the main HDD software RAID array.
Luckily for me I rather distrust SSDs (see below) and use it as fast
cache-of-sort, so I only lost a couple of hours of work. (If any)

IMHO SSDs have one huge drawback: Unlike HDDs that can be partially
recovered from more-or-less any type of damage by recovering data
around bad sectors or replacing a fried controller board, SSDs complex
write scheme and the resulting complex firmware usually means that any type of
damage / firmware error will completely bricks it leaving more or less zero
chance of getting the data back.
On the top of that, we (as in all of us) have 40+ years worth of
experience in predicting the life cycle (and death) of HDDs. There's
far less information about the life cycle of SSDs.

Case of point: A couple of days after this incident a family member lost one of his HDDs.
Unlike my dead SSDs, with some work I managed to recover 95% (or more) of his files.

Don't get me wrong. SDDs will replace HDDs in the end - but in the mean time, I'd keep SSDs for non-critical tasks.

- Gilboa

Back in 2001-2002, I had a GF3 (?) running on a A7M-266D which had some issues - most of them related to the default AGP driver which was rather funky.
The irony was that Windows 2K exhibited the same issues (BSODs).
It took a while for the machine to reach rock solid status. (On both OSs, though I slowly stopped using Windows all-together more-or-less at the same time).
By 2004, I no longer had any serious issues with nVidia drivers (at least as far as I remember).

All in all I must have installed nVidia cards on >100 different Linux machines. (Both for myself, friends, co-workers, etc).
Pretty solid track record if you ask me...

- Gilboa

Linus' screw you comment aside, I'm not certain the Linux users as all, consider nVidia to be anti Linux.
I'd image only a small minority stick to the "open or die" attitude.

- Gilboa

Note to self: Writing comments after 20h+ work is known to produce interesting results....
I meant 2002 :(

- Gilboa

Not sure I fually understand your main point, but I've been using nVidia Linux drivers since, 1992 (*gasp*) on *many* different machines, ranging from top of the line Xeon/Opteron workstations w/ Quadro cards down to ATOM notebook with ION chipset and all in all, nVidia Linux support has been nothing short of exemplary.

BTW, While not ideal, Optimus can be used with some pain under Linux, using bumblebee.
Me and my co-workers have been using it on our i7 laptops (running Fedora 18/x86_64).

- Gilboa

Actually, the IDF F4s, F15s, F16s and Kfir C-2s faced a lot of MIG-23's in the first Lebanon war.
As far as I recall the war ended at 86:0.

- Gilboa

". In the area of drivers, kernel"

I call bullshit.
As someone that in the past ~8 years have been maintaining a *separate* proprietary kernel tree that includes a fairly large OS dependent multi-platform kernel library and multiple drivers (all in all, > 250K LOC covering everything from files to networking) I can can only wonder if why this stupid claim haven't died a horrible, horrible death long, long ago..
All in all, I doubt that I spent more than 2 hours *per* kernel release to track the latest kernel API changes. *

BTW, when asked (by Phoronix, I think), nVidia Linux kernel engineers more-or-less shared the same experience. (And I assume that their code based is somewhat (...) bigger than mine).

Care to share opposite experience?

- Gilboa
* I which I could have said the same about maintaining a *small* portion of this code base across different Windows versions and even, at times, across different SP releases.

*Come-on* people. English may not be my first language, but anyone what basic fourth grade reading comprehension skills should have understood that "Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany" means I was being sarcastic and that I **do not** believe the U.S. can be compared to Nazy Germany. This ain't rockets science.

Guess I should have marked the post with "Sarcasm" in huge, bold, capital letters...?

- Gilboa

Re-read my comment *SLOWLY*.

Now idea how this:
"Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany. (And no, Mein Kampf is *not* what I meant, you illiterate pi^H^H^H^H^H^H.)" Could be understood as me comparing the U.S. to Nazi Germany.
(Quite the opposite, It was a sarcastic remark about the OP's "America is is just as bad as the Nazies" post)

English may not be my first language, but come on!

- Gilboa