On 07/31/06 10:23, Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Eric Anderson <[EMAIL PROTECTED]> typed:
On 07/31/06 09:11, Mike Meyer wrote:
In <[EMAIL PROTECTED]>, Eric Anderson <[EMAIL PROTECTED]> typed:
The patch doesn't change any current behavior, nor should it be noticed
by anyone not looking for it. However, it is useful, and it does make
our cp work just like the GNU cp, which eases the migration path for
linux->FreeBSD users.
Is emulating Linux behavior that good an idea? I mean, if I want
Linux, I can download and install a copy. The joke about "Linux is for
people who hate Windows; FreeBSD is for people who love Unix" is funny
to me *because* it seems to capture the difference between the two
systems so accurately. I like Unix/BSD because I feel like the
developers respect the user, and are willing to let the user do pretty
much anything they need to do, even if there's no obvious reason for
them to want that. I detest Windows because the developers treat the
the user like an idiot, and write software that does things the way
they think the user should want to do them - and make it impossible to
do things that the developers don't think users would ever need/want
to do. Linux seems to have more of the latter attitude than the
former. [And no, I don't think this patch has that attitude; I just
don't think that "that's how linux does it" is a valid argument:
freebsd isn't linux.]
The reasoning was not simply to make it like linux, that's just a side
effect.
That doesn't make the "to makes it more like Linux" argument a good
reason to change FreeBSD.
I suppose I'm just missing the reason *not* to commit such a simple and
n> >> useful set of options.
Feature bloat. Or, more verbosely, this doesn't add any new
functionality to the system, while adding things that we would rather
minimize.
This is a really funny reason not to. Honestly, if you believe that,
that you probably don't use cp at all, since dd can do it.
Yes, I believe that. Adding features does *not* necessarily improve a
system. If you want it added, give us *good* reasons to add it. Lack
of a good reason not to add a feature is *not* a good reason to add
the feature.
Personally, I'm neutral on this change, other than not wanting FreeBSD
to bloat any more than it already is. Given good reasons, I'd say
commit it. The reasons you just provided are specious.
You don't sound neutral at all actually, but ok. I suppose I thought
the reasons were obvious - to get a hardlinked copy of a directory tree,
one must concoct any one of a number of command lines, all using at
least one of which is much bigger in size than the patched cp I
proposed. Here are some of the commands mentioned so far that are used
by people to do the exact same thing:
-r-xr-xr-x 1 root wheel 50056 Jul 25 23:08 /usr/bin/bsdtar
-r-xr-xr-x 1 root wheel 52600 Jul 25 23:07 /usr/bin/cpio
-r-xr-xr-x 1 root wheel 36480 Jul 25 23:08 /usr/bin/find
-r-xr-xr-x 1 root wheel 90376 Jul 25 23:06 /bin/pax
And here's my patched version of cp:
-r-xr-xr-x 1 root wheel 15460 Jul 26 14:52 /bin/cp
So yes, you bloat by 160 bytes, but you can then possibly remove your
need for one or more utilities that eat up at least twice the space.
The -a option isn't as much of a useful option, but it keeps life nice
and simple for those of us with only FreeBSD systems. If the -a option
is an issue, then ignore it.
If the functionality is all that useful, then people should have
already created shell code to make this functionality easily available
via the tools that already have it. If nobody needs this functionality
often enough to have done that, is it something that we want to
enshrine in compiled code?
To me, I read this as saying: "If it was useful, it would have already
been done, and since it isn't, it must not be needed by anyone."
How does "people would have created shell code to make this easy to
do" equate to "someone would have already added an option for it"? You
claim that the code provides "useful functionality". If it's useful,
then people should be using the alternatives frequently. Command lines
that people use frequently tend to get enshrined in shell scripts, or
aliases, or shell functions, or whatever. Moving such things into
commands is a standard path for Unix code, and has been since at least
v6. So, if you want to take that step, can you show that it's really
used frequently enough to warrant getting a dedicated option?
People do make scripts to get around it, and they've posted their own
'heres what I do' on this list in this thread. People even use tools
like rsync for it too. There's a lot of people working around it in
various ways, that's what gave me the reason to post it to the list.
Anyway, it's apparent that those who are against the extra features post
louder than those who could use them, so feel free to ignore the patch
altogether if you wish.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
