On 3/26/2012 4:32 PM, John R Pierce wrote:
On 03/26/12 2:20 PM, m.roth@5-cent.us wrote:
Yeah... but parted is user hostile. A co-worker and I, both of whom don't need GUIs, use gparted. However, that doesn't tell me where it's aligning things.
I don't think its any more user hostile than fdisk is, just perhaps less familiar.
parted(8) commits changes as you make them. Those of us who grew up with :wq and File > Save (which seems to be fading away these days) expect to have the option of quitting without saving. Automatic commit is fine if you expect it, so you plan your changes more carefully, but there's a whole lot of us with ingrained "never mind, get me out of here" Ctrl-C reflexes.
Worse, to my mind, is that parted(8) makes you explicitly give it more values than fdisk(8) does. fdisk(8) uses information it has plus reasonable guesses to provide reasonable defaults for almost every question it asks:
- parted(8) can't create partitions on a new disk until you "mklabel".
You may claim the reason for this is that parted supports many partition table types, but actually, fdisk supports more than just MBR. The essential difference is that fdisk(8) has a reasonable default, parted(8) does not. Is there a good reason parted couldn't implicitly do "mklabel gpt" if you say "mkpart" on a zeroed disk?
- fdisk(8) gives reasonable defaults when creating partitions for the start and end values. Its default start happens to be wrong in this 4K sector world, but parted(8) would be expected to fix that, if it offered a default. Why should the operator be expected to know that starting at 0 or 63 is a bad idea? Why should the operator be expected to know that "-1" means "end of disk"? Why should the operator have to do arithmetic to pack 8 partitions back-to-back?
You can trick parted(8) into doing some of the arithmetic for you; if you tell it all partitions start at 0, it offers to slide the new partition into position after existing ones. But, this again gets into specialized knowledge the user really has no good reason to have. fdisk doesn't make you think about partition start positions and it lets you give relative partition sizes instead of compute end values.
Maybe you don't see the problem. Consider this partition layout:
/boot: 500 MB swap: 16 GB /: 20 GB /home: the rest
In fdisk speak, the commands are:
n, p, 1, [Enter], +500m n, p, 2, [Enter], +16g, t, 82 n, p, 3, [Enter], +20g n, p, 4, [Enter], [Enter]
In parted speak, it is:
mklabel gpt mkpart, [Enter], [Enter], 1m, 501m mkpart, [Enter], linux-swap, 501m, 16.51g mkpart, [Enter], [Enter], 16.51g, 36.51g mkpart, [Enter], [Enter], 36.51g, -1
The fdisk sequence is more self-explanatory. The only things it makes you tell it, which it should be able to guess or figure out on it own, are the partition numbers.
The fdisk sequence is also less arbitrary. You might think the magic number 82 is more arbitrary than "linux-swap", but I tried "swap" first and got told to start over, proving it's just as arbitrary.
Oh, and realize that with parted(8) I had to manually ensure proper alignment the whole way. If parted gave a default start value, it could ensure it was always aligned.
parted(8) has its points. GPT support, partition types given by FS name instead of arbitrary MS-DOS type IDs, the ability to mkfs for *some* supported filesystem types (not all!), resizing...
Still, I'd have to agree with m.roth: parted(8) has a...um...classical UI. It's not far advanced beyond the ex(1) school of UI design.