Subject: Re: sysv ps(1) implementation [was: ps(1) sysv silliness]
To: NetBSD Userlevel Technical Discussion List <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 06/08/2000 17:37:18
On Thu, 8 Jun 2000, Greg A. Woods wrote:
[mv/ln/cp linked; okay it was those three...]
[mkdir/mknod not; i remember now it was that mkdir had to be setuid
because the _rename_ call hadn't been implemented yet, that was it!
so mkdir was, more or less (modulo GC and error checking)
link(path, cp = strspl(path, "/."));
link(getcwd(), cp = strspl(path, "/.."));
# (I think they were all separate in 4.2BSD too, but I've only the
# AT&T-free 4.3 distributions online at the moment.)
Yes, they were separate in BSD.
# Note how small those programs are too! ;-) And note that V7 had more
# error checking in mv.c than sysIII.
# > In the above cases, it makes a LOT of sense to have the hooks
# > in a single binary, otherwise code is duplicated, space is wasted,
# > cache is lost (if you think cache isn't important, you have never had
# > to run a shell script which did a lot of chown/chgrp and other linked-
# > binary stuff on a BIG tree or a lot of files, and you had the script
# > handy but no time to write another one).
# There are at least two kinds of code sharing and I really do not like
# the one you describe above where everything is linked together. If I
# wanted that then I'd run some big monolithic system (like Multics! ;-).
I didn't say that EVERYTHING should be linked, but if the operations are
_similar enough_, they should be linked.
Would you, for example, have a separate program to handle symbolic links?
Would you write chown and chgrp to be separate programs?
I'd keep cp/mv/rm separate, obviously.
But there are places where code sharing makes sense.
# Shared libraries are bad enough but shared static binaries are horrid
# hacks suitable only for extreme situations like the boot floppy or
# embedded systems!
"Shared libraries are bad enough." And you say *I* resist progress?!?
I think shared libs are saving us from overrunning disks and memory.
BSD: The cure for the common OS.