| 1 |
Richard Yao posted on Wed, 06 Apr 2016 10:04:05 -0400 as excerpted: |
| 2 |
|
| 3 |
> That being said, this is only useful for new installs where people want |
| 4 |
> to take advantage of the Solaris way of doing management. It should have |
| 5 |
> no benefit for existing installs. |
| 6 |
|
| 7 |
I don't know enough about solaris to comment on that, but my (reverse) |
| 8 |
merging /usr and bin/sbin to / certainly had benefits for my existing |
| 9 |
install. The biggest one was no longer having the brain overhead of |
| 10 |
having to track whether something's in /usr or direct in /, or in the bin |
| 11 |
or sbin location in /usr or /. If it's an on-path executable that I |
| 12 |
didn't manually create/install myself, it's now in /bin as the fully |
| 13 |
dereferenced canonical path, tho /usr/bin /sbin, and /usr/sbin also work |
| 14 |
via symlinks, no questions asked. Similarly, libs are found in /lib64 as |
| 15 |
the fully dereferenced canonical path, tho /lib, /usr/lib64 and /usr/lib |
| 16 |
all work as well, via symlinks. =:^) |
| 17 |
|
| 18 |
There remains a slight down side in that the PM's idea of where the files |
| 19 |
are located may differ in that it's one of the symlinked versions, and |
| 20 |
various standard paths are slightly less efficient due to having to |
| 21 |
dereference possibly multiple symlinks, but automatic and fast tracking |
| 22 |
of such things while minimizing the wetware tracking load is what |
| 23 |
computers excel at, so on balance I consider it a pretty large benefit. |
| 24 |
|
| 25 |
So there's certainly benefit for existing installs. =:^) |
| 26 |
|
| 27 |
-- |
| 28 |
Duncan - List replies preferred. No HTML msgs. |
| 29 |
"Every nonfree program has a lord, a master -- |
| 30 |
and if you use the program, he is your master." Richard Stallman |
Archives