I'd rather see that 'reversed' - i.e. - build a more capable fdisk in
DFLY with hope that it might be seen worth importing into Free/Net/Open,
or *at least* be able to do a more flexible job than those now do.
And disklabels as well. Hand in glove.
Here's why:
- At the moment, working with Free, Open, DFLY, and OpenSolaris on the
same HDD requires a bit of acrobatics.
- There seems to now be greater divergence between/among the *BSD's as
to being able to read each other's disklabels, mount and use each
other's 'flavor' of FFS/UFS (not to mention Apple's implementation of
UFS) than there is among the vast multitude of Linux ext2/3 denizens.
Even to the point where use of a *Linux* fs is the more universal way
for being able to share mounts among the *BSD's. Think detached drives.
And no - FAT is not all that practical for several reasons.
- DFLY currently has the most fine-grain ability to create slices and
partitions. But the others cannot all (any?) read those.
'progress' w/r any of the *BSD's direction as to changes, improvements
(or not) in their once-common-ancestry fs & disklabels need not be
sacrificed.
I'm not holding out wish or hope for all players agreeing to return to
'one sacred way'. Nor 'one new universal fs'. Neither is gonna happen.
But a 'legacy compatible' or least-common-denominator mode would do fine
- most especially for portable / SAN devices.
So - how about a 'flexible' DFLY fdisk to go along with a 'flexible'
disklabel that could adapt to whatever it found / was told to create?
JM2CW - but that *might* be a good place to get a cross-*BSD team together.
*snip* (other good stuff)
Bill Hacker
