Google Sommer of Code 2008
wbh at conducive.org
Tue Mar 4 23:52:13 PST 2008
A cute idea for for GSOC would be to finish the installer.
We were talking about this in my local BUG, we trying to find out how to
help on that from here.
There is a few missing features in the CD.
* FDISK, you need to create the slides from another OS before
install DFBSD, i think port FDisk from FBSD or any *BSD will solve it.
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.
- 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
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)
More information about the Kernel