Am 30.10.2011 23:02, schrieb Lennart Poettering: > On Mon, 24.10.11 13:05, Chris Adams (cmadams@xxxxxxxxxx) wrote: > > Here's an attempt to summarize the rationale for merging /bin, /sbin, > /usr/sbin into /usr/bin with different words collecting the various points > raised: > > a) the split between sbin and bin requires psychic powers from > upstream developers: > > The simple fact is that moving binaries between these dirs is really > hard, and thus developers in theory would need to know at the time > they first introduce a binary whether it *ever* might ever make sense to > invoke it as unprivileged user (because in that case the binary > belongs in /bin, not /sbin). History shows that more often than > not developers have placed their stuff in the wrong directory, see > /sbin/arp, /sbin/ifconfig, /usr/sbin/httpd and then there is no smart > way to fix things anymore since changing paths means breaking all hardcoded > scripts. And hardcoding paths in scripts is actually something we > encourage due to perfomance reasons. The net effect is that many > upstream developers unconditionally place their stuff in bin, and > never consider sbin at all which undermines the purpose of sbin > entirely (i.e. in systemd we do not stick a single binary in sbin, > since we cannot be sure for any of its tools that it will never > ever be useful for non-root users. and systemd is as low-level, > system-specific it can get). > > b) The original definition of /sbin is fully obsolete (i.e. the "s" in > sbin stood originally for "static" binaries) > > c) /bin vs. /sbin is not about security, never has been. Doing this > would be security by obscurity, and pretty stupid, too. > > d) splitting /bin off /sbin is purely and only relevant for $PATH, and > $PATH is purely and only something to ease access to the tools in it > for shell users. The emphasis here is on "ease". It is not a way to > make it harder for users to access some tools. Or in other words: if > your intention is to hide certain tools from the user in order not to > confuse him, then there are much better places for that: the > documentation could document them in a separate section or so. I > don't think it makes any sense at all trying to educate the user by > playing games with what he can see if he presses TAB in the shell. On > top of that users who use the shell are the ones who react allergic > to this kind of attempts of forced education anyway. So just drop > this nonsense. > > e) the split between sbin/ and /bin is effectively made redundant already, > since both are listed in the $PATH of all users already since a > couple of Fedora versions. And due to d) the split hence has no > reason to exist, at all. > > f) splitting things up complicates stuff. If you want to keep things > separate you really need a good reason for that. We should always > focus on simplifiying things. And merging things into /usr does just > that: it drastically simplifies the complexities we have collected > over 30+ years of Unix heritage. > > g) given that some distros place certain binaries in other places than > others, merging the dirs has the big benefit that the four paths are > equivalent and scripts from other distros work on ours, regardless > where the other distros place their stuff > > h) the split between /usr and / was mostly about early boot > initialization: i.e. a minimal system was available in / which was > just good enough to find the full OS stuff in /usr. But that hasn't > worked in ages, and the discussion for split off /usr is over and the > install option got removed from anaconda (though you can still > install things like that by hand if you really want to shoot yourself > in the foot) > > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > i) The separation between minimal boot system in / and full system in > /usr is obsoleted by initrd in a way: the new minimal boot system is > the initrd. Stacking multiple levels of "minimal boot system", one > after the other is a stupid game. So let's stick to the one we really > need which is initrd, and forget about the one that we don't need > anymore, and is broken since ages. > > j) having all static, distribution-provided, sharable OS stuff in a single dir > in /usr simplifies read-only setups drastically. I think we should > ensure that having the OS itself read-only is something that works > right-away without having to enable special modes that do this which > involves a ton of less-than-beautiful hacks. Being able to make the > libc and other core libraries fully read-only without also having to > make /etc read-only and without having to add a junkload of r/o bind > mounts is highly desirable. > > k) having all static, distro-specific, sharable OS in a single dir > makes snapshots of the OS independetly of its state and configuration > truly atomic. In a btrfs world doing 5 snapshots of /lib, /lib64, > /bin, /sbin and /usr instead of just one is not atomic, and hence > racy, and ugly, and boooh! > > l) having a clear separation between sharable data > (i.e. /usr) and everything else is highly desirable for > network setups, and for container setups. > > m) Upstream build scripts can be vastly simplified, since autoconf does not > know about the separation between / and /usr (and never did), and > getting autoconf right in the context of the split traditional is immensly > difficult, with the effect that almost nobody got it right. And we > have quite a few components who never even tried (i think Plymouth?) > > n) Harald has done the work for testing and showed that merging the dirs > works, and that the path towards it is pretty clear and managable, > and that it creates no major issues on the way. > > o) we have somebody who wants to do the work. > > And that's all I could come up with for now. Putting this together I am > all in favour of this simplification. As a developer it would make > things a lot simpler for me. Packagers will have things much simpler > (after the transition) too, and finally administrators have the major > benefits of the atomicity of the btrfs snapshotting, and for network and > especially container setups. And those three are absolute killer > features in my eyes. > > Lennart > updated https://fedoraproject.org/wiki/Features/UsrMove and added a large FAQ. So, some of the other questions and concerns might be answered there already. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
