3 ms·

I thought it was implied that bin vs sbin is a permissions thing. What is outdated in that link? I use Fedora 39 Atomic and, as far as I can tell, even it follo

I thought it was implied that bin vs sbin is a permissions thing. What is outdated in that link? I use Fedora 39 Atomic and, as far as I can tell, even it follows these conventions (and even added /var/userlocal for themselves).

throwanem 3y ago
Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large. Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup. I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr. I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some. edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found. [1] https://landley.net/history/mirror/index.html https://landley.net/history/mirror/index.html

throwanem 3y ago

Strictly, the difference between /bin and /sbin versus their siblings in /usr has to do with what you can fit on the RK05 disk pack that the system boots from. If it comes up too broken to mount the DECtape (or if you're lucky and your institution's not cheap, the second RK05) where /usr lives, you'd better be able to fix it with whatever's in /, because until you do that's all you've got. Hence keeping some binaries there, but not too many; your root volume is only a couple megabytes large. Too, if /usr is on tape, that's a lot slower in random access than even a contemporary disk, which matters because you also don't have enough core memory to avoid paging binaries - so even things you might not need to fix a broken system still may be worth putting in /bin if you can afford the space, if they're frequently enough used to be worth the speedup. I believe the difference between /bin and /sbin per se had to do with dynamic versus static linking, with /sbin reserved for statically linked versions of binaries critical to bring up or repair a system - after all, if something in /bin is linked against libraries in /usr/lib, then you still won't be using it if you can't mount /usr. I'm not so sure about that part, though; it's been a very long time since any of this mattered at all to how Unix is operated in practice, and it is really only of interest to those curious about how the constraints of early hardware informed the evolution of historical filesystem layout conventions. Even I'm not old enough to have actually worked with such systems, although I don't miss it by much, and am certainly old enough to have studied a great deal more about them than some. edit: If you're really interested in the topic, then you should certainly spend some time with Rob Landley's collection of historical documents [1], which Google is apparently no longer competent to find based on their content - some of this I was actually looking for in the course of composing this reply, and only found it when I happened to search the name on a mailing list message linked in another reply here. So much for "information wants to be free" - apparently on today's Internet there's no money left in making information able to be found. [1] https://landley.net/history/mirror/index.html https://landley.net/history/mirror/index.html