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 -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
