[Adjust james.graham@schwab.com to greywolf@starwolf.com, please!]

Outside of the fact that it goes against the (now) de facto 
standard which has rooted itself more firmly than a matured 
anise plant, I can't see that Terry is really too far out of
line.

Terry Lambert wrote:
#You misunderstand my argument.
#
#My points are:
#
#1)      If you are going to generate FS specific commands, they
#        should be grouped by FS, such that the FS can be treated
#        as a unit.

This makes a lot of sense.  Consider the renaming of ufs to ffs that
happened some time ago.


#
#2)      The FS specific commands should be wrappered by a generic
#        FS command that takes a -T argument, but does not require
#        a -T argument if "fstyp" is implemented or if the device
#        being referenced exists in the /etc/fstab already, such
#        that iterating the /etc/fstab will identify the FS type.

Here, I differ, but only in that I'd like to see it kept as '-t'.

[religion: I can't stand upper-case options where they're not needed.]

#3)      The best way to achieve grouping currently is with FS specific
#        directories to contain the commands.

Again, outside of the de facto argument by which we currently run,
he's not out of line on this.  It would also clean up /sbin a bit.

#
#4)      The next best way to achieve grouping is by way of prefix,
#        not a suffix, since it simplifies component identification
#        without needing to determine subcomponent type.

Actually it's easier to read all the mount_* subcommands in one spot
than to look for *_mount, from a simplistic perspective.

#
#5)      The worst way to achieve grouping (since it does *not*
#        achieve grouping, it only achives differentiation) is by
#       suffix.

And I disagree here.  Try rearranging all the mount_* commands to be
*_mount under /sbin.  Unless we have a suite of commands (which, to
date, I haven't noticed either way, outside of fsck and mount) 
which would make $FSTYPE_$CMD more suitable for viewing via "ls ffs_*",
it doesn't (yet) buy us anything to change them from mount_*, dump_*,
umount_*, fsck_*...

#I am not arguing for #4 or #5, which are each "one of the two naming
#schemes".  I am arguing for the naming scheme you are omitting from
#consideration by ignoring it:  #3.
#
#> If you want to gratuitously reduce compatibility of FreeBSD with
BSDI,
#> NetBSD and OpenBSD, thats fine, but there is no rational reason to
#> consider this to be so important that switching the order makes
#> sense.

Rearranging from sbin/mount_*fs to sbin/*fs/mount doesn't seem like it
would break much if it were properly folded into the release.
Building system-specific maintenance scripts is one of those things
(as I have found) which is, as the saying goes, "subject to change
without notice".  Anything in a future release could break everything
I've ever written.  But I'm fully prepared to deal with this; I'm
aware of the pitfalls involved.

#> whereas I do see a larger learning
#> curve, broken scripts and executables, and a dozen other reasons not
#> to be gratuitously incompatible.

_What_ learning curve?  Look at it:  UNIX _is_ a learning curve
(trademarks notwithstanding, NetBSD is, for all intents and purposes,
UNIX, is it not?).  There are so many variances between commercial
and free platforms as it is that if we could actually succeed in
some sort of consolidation, it would be to our benefit.

#
#This assumes (INCORRECTLY) that scripts and users (ther than FS module
#authors) will directly reference the FS-specific commands, rather than
#referencing the wrapper commands which encapsulate the type-inference
#entirely.

Indeed; I've found it more of a hassle to reference the mount_* commands
directly.  There was one set of $CMD_$FSTYPE commands which had, at last
glance, insufficient documentation by which one could determine what
each $CMD_FSTYPE command did.  I forget whether fsck, mount or dump
was the culprit, but not all the options were documented (though
they were certainly referenced by the generic command), or the main
program was calling the _$FSTYPE command incorrectly.

#> > The only reasonably uniform mechanism for modular
insertion/deletion
#> > of supported file systems from an OS involves grouping the files by
FS.
#> 
#> Your computer doesn't care what the names of the files are. Any
#> reasonable package system (including the FreeBSD one) can handle sets
#> of arbitrarily named files and add or remove them at will. Thats one
#> of the reasons you have package systems.

No, the computer doesn't care, but grouping them would certainly
make it easier to do manual changes should the pkg_remove (or whatever)
utility fail to clean things out completely for some bizarre reason.
(Hint:  I've yet to meet a package utility which will correctly handle
 removal.)


[ Shell scripts deleted... ]

#> > Ideally, the grouping should be done on a directory basis rather
than
#> > a prefix basis so that only a single point of adjustment is
necessary
#> > to perform the insertion or deletion.
#> 
#> Your proposal would have made sense BEFORE everyone else picked a
#> scheme.

It still makes sense; it's now just a matter of what everyone else
is willing to consider.

In fact, if phased in _now_ (the sooner, the better, IMO), the
transition will be a lot smoother than if we sit and bitch about the
inconsistencies between platforms.  It's a better proposal than
either of the other two, even now.


--*greywolf;
Have a nice day.  Offer void where taxed, tithed, restricted or
otherwise prohibited.  All taxes are the sole
responsibility of the winner.  Prizes of more than one nice day are paid
out over twenty years to minimise tax liability.
NOTE:  all replies to this address [james.graham@schwab.com] may be read
by Schwab's security team.
No joke.  Reply to greywolf@starwolf.com instead.