| |||||||||||||
I'm still confused...I'm still confused...Posted Dec 10, 2011 3:54 UTC (Sat) by pr1268 (subscriber, #24648)In reply to: Distribution quote of the week by mpr22 Parent article: Distribution quote of the week
I'm still confused... If FWIW My Slackware 13.37 system currently has 134 files in /usr/bin symlinked to their corresponding equivalents in /bin (although there is a many-to-one relationship of some files, e.g. bunzip2, bzcat, and bzip2 all symlink to ../../bin/bzip2).
(Log in to post comments)
Moving binaries to /usr/bin Posted Dec 10, 2011 4:19 UTC (Sat) by jrn (subscriber, #64214) [Link]
I suspect the idea is that if all binaries are in /usr/bin, one doesn't have to fuss about where the binaries are. :) And if /usr is mounted early enough, why not? (There are some other benefits, like /usr being easier to set up than / as a read-only filesystem.)
I don't know of any systemd bugs in this area, other than a strange altruistic propensity to warn in its log about /usr not being mounted early enough for the sake of other packages like udev.
I'm still confused... Posted Dec 10, 2011 22:39 UTC (Sat) by james (subscriber, #1325) [Link] At the moment, the situation is:
Under this proposal:
So this means that you can have a separate /usr if you're prepared to have an initrd, or you can use your own kernels without initrds if you put /usr on the same filesystem as /.
I'm still confused... Posted Dec 11, 2011 5:27 UTC (Sun) by raven667 (subscriber, #5198) [Link]
And I think this bears repeating, the first case where /usr is on a separate partition and stuff breaks during boot if it's not mounted is the _current_ case, not the case being introduced by the proposed change. There has been some effort over the previous years to audit the boot process and move binaries from /usr to / to fis this when the issue is detected but this has been scattershot and incomplete.
The proposal to just move everything to /usr and make sure it is always mounted directly after / _fixes_ this problem once and for all. The fact that this also fixes another set of thorny cases is just gravy, the fact that this has been successfully done on other big UNIX systems is a great endorsement. This doesnt have anything to do with systemd trying to eat your baby, It just exposed more pre-existing cases that were broken in the current setup.
I'm still confused... Posted Dec 11, 2011 17:54 UTC (Sun) by jrn (subscriber, #64214) [Link]
> This doesnt have anything to do with systemd trying to eat your baby, It just exposed more pre-existing cases that were broken in the current setup
Did systemd actually provoke any worse behavior? I had assumed it was just warning about this class of bugs for kicks.
I'm still confused... Posted Dec 12, 2011 4:08 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Systemd starts services as needed which probably created several service start orders that, while perfectly valid, hadnt been tested in practice and broke.
|
|||||||||||||