TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

378 点作者 kylerpalmer大约 9 年前

18 条评论

m45t3r大约 9 年前
For all people that think this is still a issue: it is not:<p>* Arch Linux: <a href="https:&#x2F;&#x2F;wiki.archlinux.org&#x2F;index.php&#x2F;Arch_filesystem_hierarchy" rel="nofollow">https:&#x2F;&#x2F;wiki.archlinux.org&#x2F;index.php&#x2F;Arch_filesystem_hierarc...</a><p>* Fedora: <a href="https:&#x2F;&#x2F;fedoraproject.org&#x2F;wiki&#x2F;Features&#x2F;UsrMove" rel="nofollow">https:&#x2F;&#x2F;fedoraproject.org&#x2F;wiki&#x2F;Features&#x2F;UsrMove</a><p>* Debian: <a href="https:&#x2F;&#x2F;wiki.debian.org&#x2F;UsrMerge" rel="nofollow">https:&#x2F;&#x2F;wiki.debian.org&#x2F;UsrMerge</a><p>* Ubuntu: <a href="https:&#x2F;&#x2F;wiki.ubuntu.com&#x2F;FoundationsTeam&#x2F;Specs&#x2F;Quantal&#x2F;UsrMerge" rel="nofollow">https:&#x2F;&#x2F;wiki.ubuntu.com&#x2F;FoundationsTeam&#x2F;Specs&#x2F;Quantal&#x2F;UsrMer...</a><p>And this is true for quite a long time. I think the last distro that did &#x2F;usr merge is Debian and this is already 3 years ago. So I find surprising that people still thinks that this is a issue.<p>The only thing that remains is the difference between bin and sbin that Fedora&#x2F;Ubuntu&#x2F;Debian still maintain (Arch Linux simply merged everything).<p>P.S.: of course, there should be still distros that use a split &#x2F;bin &#x2F;usr&#x2F;bin, &#x2F;lib and &#x2F;usr&#x2F;lib, etc. OpenWRT is one of them. However I think the major distros already migrated.
评论 #11649573 未加载
评论 #11648737 未加载
评论 #11647909 未加载
评论 #11648595 未加载
评论 #11647798 未加载
评论 #11649076 未加载
评论 #11648552 未加载
bbanyc大约 9 年前
Nitpicking:<p>If you look at the very early versions of the Unix manuals, before even &#x2F;lib was invented, there was a notion that &#x2F;bin was the &quot;system&quot; (section 1) and &#x2F;usr&#x2F;bin was &quot;user software&quot; (section 6). This fell by the wayside when they ran out of disk space on &#x2F; and started putting section 1 commands in &#x2F;usr&#x2F;bin. At some point the system&#x2F;user distinction was abandoned and everything but the games got moved to section 1 of the manual.<p>(Back in those early days &#x2F;lib files used to be in &#x2F;etc. So did &#x2F;sbin. There&#x27;s still a meaningful semantic difference between programs any user could run vs programs only useful to root.)<p>On *BSD there is no initramfs equivalent and the &#x2F; partition still serves its traditional role of the minimal startup environment. And &#x2F;home never existed before Linux - it was always something like &#x2F;usr&#x2F;home as far as I can tell.
评论 #11649638 未加载
评论 #11648759 未加载
nickpsecurity大约 9 年前
NixOS is one of the few distros that recognizes and solves this problem:<p><a href="https:&#x2F;&#x2F;nixos.org&#x2F;nixos&#x2F;about.html" rel="nofollow">https:&#x2F;&#x2F;nixos.org&#x2F;nixos&#x2F;about.html</a><p>A solution like theirs should become the default. Their transactional, package management too given the number of times my Linux packages got broken by some ridiculous crap. That even a smaller outfit could knock out two problems, one major, shows these bigger distros could be gradually knocking out such issues themselves.
评论 #11647546 未加载
评论 #11647536 未加载
评论 #11648997 未加载
ChuckMcM大约 9 年前
Interesting.<p>First there was &#x2F;bin for the things that UNIX provided and &#x2F;usr&#x2F;bin for the things that users provided. Part of the system, it lived in &#x2F;bin, optional? it lives in &#x2F;usr&#x2F;bin.<p>In SunOS 4 (and BSD 4.2 as I recall) the introduction of shared libraries meant you needed a &quot;core&quot; set of binaries for bootstrap and recovery which were not dynamically linked, and so &quot;static&quot; bin or &#x2F;sbin (and its user equivalent &#x2F;usr&#x2F;sbin) came into existence. Same rules for lib. &#x2F;lib for the system tools, &#x2F;usr&#x2F;lib for the optional user supplied stuff.<p>Then networking joined the mix and often you wanted to mount a common set of things from a network file server (saved on precious disk space) but there were things you wanted locally, that gave use &#x2F;usr&#x2F;local&#x2F;bin and &#x2F;usr&#x2F;local&#x2F;lib. Then in the great BSD &lt;==&gt; SVR3.2 merge AT&amp;T insisted on everything optional being in &#x2F;opt which had a kind of logic to it. Mostly about making packages that could be installed without risking system permission escapes.<p>When Linux started getting traction it was kind of silly that they copied the &#x2F;bin, &#x2F;sbin, &#x2F;usr&#x2F;bin, &#x2F;usr&#x2F;sbin stuff since your computer and you are the only &quot;user&quot; (usually) so why not put everything in the same place, (good enough for Windows right?)<p>File system naming was made more important by the limited permission controls on files, user, group, and other is pretty simplistic. ACLs &quot;fixed&quot; that limitation but the naming conventions were baked into people fingers.<p>The proliferation of places to keep your binaries lead to amazingly convoluted search paths. And with shared libraries and shared library search paths even more security vulnerabilities.
评论 #11648746 未加载
评论 #11650001 未加载
IshKebab大约 9 年前
I wonder what is more likely in our lifetimes - a sane Linux filesystem layout, or viable fusion power. Honestly I&#x27;m not sure.
评论 #11647569 未加载
dredmorbius大约 9 年前
Reasons why you <i>still</i> might want to keep &#x2F; and &#x2F;usr isolated:<p>1. NFS mounts. Your local or initial BOOTP image has a minimal root, your (non-root-writeable, BTW) NFS &#x2F;usr has Other Stuff.<p>2. Mount options. Root is often (and perhaps still <i>must</i> be -- &#x2F;etc&#x2F;mtab for example -- I&#x27;ve stopped closely tracking discussion to make root fully read-only) writeable. It may also require other mount permissions, including device files and suid. Other partitions <i>don&#x27;t</i> require these permissions, and there is some Principle of Least Privilege benefit to mounting such partitions without them. &#x2F;usr requires suid, but not dev, and may be nonwriteable except for OS updates.<p>3. Recovery partition. I&#x27;ll frequently stash a second root partition, not typically mounted. It has minimal tools, but enough to bootstrap the system if the primary is hosed for whatever reason (more often myself than any other). Without a clean &#x2F; &#x2F;usr split, this becomes more complicated.
评论 #11649611 未加载
Annatar大约 9 年前
The elephant in the room is &#x2F;opt, &#x2F;etc&#x2F;opt, and &#x2F;var&#x2F;opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, &quot;for third party and unbundled applications&quot;. Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can never be delivered into &#x2F;usr, because that is vendor&#x27;s namespace, and an updated version from the vendor might very well bring a production application down).<p>&#x2F;opt: application payload<p>&#x2F;etc&#x2F;opt: application&#x27;s configuration files<p>&#x2F;var&#x2F;opt: application&#x27;s data.<p>For applications with more than two configuration or data files, it is a good idea to create &#x2F;etc&#x2F;opt&#x2F;application and &#x2F;var&#x2F;opt&#x2F;application.<p>If your company is mature enough to understand what system engineering is, and employs dedicated OS and database system engineering departments, &#x2F;opt&#x2F;company, &#x2F;etc&#x2F;opt&#x2F;company[&#x2F;application], and &#x2F;var&#x2F;opt&#x2F;company[&#x2F;application] become very practical. If this approach is combined with delivering the application payload and configuration management as operating system packages, one only need worry about backing up the data in &#x2F;var&#x2F;opt, and that&#x27;s it.
评论 #11649623 未加载
评论 #11650686 未加载
josephscott大约 9 年前
I like that FreeBSD dedicates a man page, HIER(7), on this topic - <a href="https:&#x2F;&#x2F;www.freebsd.org&#x2F;cgi&#x2F;man.cgi?query=hier" rel="nofollow">https:&#x2F;&#x2F;www.freebsd.org&#x2F;cgi&#x2F;man.cgi?query=hier</a> - &quot;layout of file systems&quot;
评论 #11648029 未加载
评论 #11648063 未加载
teamhappy大约 9 年前
&#x2F;{bin,sbin} is for stuff you cannot live without (e.g., sh, mkdir, chmod, rm, ln, etc.)<p>&#x2F;usr&#x2F;{bin,sbin} is for stuff you can live without but expect to be there (e.g., make, grep, less).<p>&#x2F;usr&#x2F;local&#x2F;{bin,sbin} is for stuff you&#x2F;your local admin installed (e.g., mosh, cmake).<p>Also, I use $HOME&#x2F;{bin,sbin} for wrapper scripts, binaries that I need but don&#x27;t want to install system-wide (single-file C utils that come without man pages, stuff like that).<p>I&#x27;m not sure where the confusion comes from and I don&#x27;t really see any advantage in merging &#x2F; and &#x2F;usr. On the flip side, I do think there&#x27;s value in keeping &#x2F;{bin,sbin} as small as possible (because that stuff <i>has to</i> work).
评论 #11649370 未加载
评论 #11649343 未加载
takeda大约 9 年前
MacPorts use &#x2F;opt&#x2F;local :)
评论 #11648596 未加载
评论 #11648032 未加载
评论 #11648392 未加载
shirro大约 9 年前
The &#x2F;bin vs &#x2F;usr&#x2F;bin split makes perfect sense but I always thought &#x2F;sbin was superflous to happy to see it being deprecated by many distros.<p>I expect with the increasing moves towards app stores and sandboxing on all platforms that the days of installing packages contents all over the filesystem are limited and things like xdg-app are probably going to take over with an app being mounted into the filesystem in a sandbox as it is run.
评论 #11649712 未加载
RijilV大约 9 年前
One outcome of this that drove me nuts back in the day on Debian system was libpcre was installed in &#x2F;usr and grep was in &#x2F;bin. This meant perl regex were not supported because the maintainers of Debian didn&#x27;t want the dependency on &#x2F;usr from things in &#x2F;bin, and didn&#x27;t want to &quot;bloat&quot; &#x2F; with something as distasteful as libpcre.
SquareWheel大约 9 年前
How badly would things break if we tried to &quot;fix&quot; this split today?
评论 #11647643 未加载
评论 #11651388 未加载
评论 #11647735 未加载
评论 #11648270 未加载
paxcoder大约 9 年前
I want to react to the signature FUD: GPLv3 is clearly a superior copyleft license to GPLv2 despite Linus&#x27; latently permissive opinion on the anti-TiVoization clause.
评论 #11647767 未加载
rhabarba大约 9 年前
Today I learned that &#x2F;usr actually means user, not Unified System Resources. Damn, one less thing I can nitpick about.
chrisamanse大约 9 年前
I thought &#x27;usr&#x27; stands for &quot;Unix System Resources&quot;?
评论 #11648849 未加载
chris_wot大约 9 年前
Well this partially answers my question at <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11647487" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11647487</a>
SFJulie大约 9 年前
I love the quote in the signature :<p>GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.