On Sun, Nov 16, 2003 at 07:24:00PM -0700, Brent Jones wrote: > > On Nov 16, 2003, at 9:22 AM, Richard Coleman wrote: > >Robert M.Zigweid wrote: > >>I'll admit to being mostly a lurker here, but isn't the point of > >>/sbin to be statically linked. That's what the 's' stands for? > >>Second question. This seems to imply that /sbin and /bin both have > >>to have the same behavior? I have no problem with /bin being > >>dynamically linked, but what if I want /bin to be dynamic and /sbin > >>static? > >>Regards, > >>Robert M. Zigweid > > > >I'm not sure what that would accomplish. If a system was broken such > >that the dynamically linked binaries in /bin didn't work, the > >utilities in /sbin wouldn't be enough to fix the system. For > >instance, you wouldn't have a shell or "ls". > > This is just a case of OS evolution. /sbin used to be the place where > the statically linked recovery things would be placed, in case the > shared libraries got hosed. The only things that needed to be > statically linked though, were system utilities, which is why people > probably started to associate the "s" with system, rather than static. > > When this happened, you started to see the duplicates that used to > exist in /bin (or /usr/bin) and /sbin disappear. Since you still need > a place to have statically linked recovery utilities, /rescue was > created. Now you see the duplicates in /bin (or /usr/bin) and /rescue > instead. Do you have any references for this? Every single place that I can find explains /sbin as "system binaries". I have also never heard of there ever being duplicates in /bin of the files in /sbin. -- <Insert your favourite quote here.> Erik Trulsson ertr1013_at_student.uu.seReceived on Sun Nov 16 2003 - 19:21:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:29 UTC