Linux组织已安装程序文件的方式有什么好处？[关闭]

10

在Windows中，系统驱动器C:有一个目录program_files，每个程序在其下都有其自己的目录。

在Linux中，/usr/和下/usr/local/有/bin, /etc, /share, /src，等等。

因此，在Windows中，每个程序的所有文件都分组在同一目录中，而在Linux中，所有程序中的相同类型的文件都在同一目录中。

我觉得Windows组织已安装程序的方式比Linux更合乎逻辑，因此已安装程序更易于手动管理。

Linux组织已安装程序文件的方式有什么好处？谢谢。

当遇到如何在$ HOME中组织已安装的程序以供Shell在运行它们时搜索它们的问题时，我遇到这个问题？，我尝试以$HOMEWindows的方式组织程序，但是在指定程序的搜索路径时遇到了一些问题。

— 提姆
source

9

@RandallStewart您的“ 不可预测且分散的 ”是我们对DLL的合理放置和非重复。

— 罗恩·约翰

1

这是基于历史的-主要是为了能够安装几个磁盘分区，同时能够仅具有必需的必需项进行引导。类似的情况是，PC BIOS仅能看到非常大的硬盘的第一部分，因此在该第一部分中放置了一个单独的分区，其中包含启动所需的所有内容。通常称为“ / boot”。如今，对沙箱和不受信任的应用程序的需求已导致人们对此进行了重新思考-请参见例如Ubuntu快照。

— 托尔比约恩Ravn的安德森

9

首先让我指出Windows当前并未将每个程序的所有文件都放入smae目录。除了“程序文件”和“程序文件（x86）”外，还有“本地”，“ LocalLow”和“漫游”等“ Users \ <用户名> \ Appdata”目录。Windows也不总是将“ Program Files”文件夹用于程序，或者在其历史记录中始终使用该文件夹。* nix在处理文件方面更加一致。

— YLearn

5

@JAB，同意，并理解这一点。我当时指出，OP的声明“因此，在Windows中，每个程序的所有文件都分组在同一目录中”是不正确的。我也没有参加Windows注册表的讨论，Windows注册表也可以看作是存储有关Windows程序的配置和其他数据，并且不属于“ Program Files”目录。

— YLearn

2

Linux组织已安装程序的文件吗？从何时起？

— hobbs

17

在Linux中，通常在维护良好的情况下，可以映射某些逻辑。例如。：

/bin 包含最基本的工具（程序）
/sbin 包含最基本的管理程序

它们都包含引导和基本故障排除所使用的基本命令。在这里，您会看到第一个区别。某些程序不适合普通用户使用。

然后看看/usr/bin。在这里，您应该找到更多的命令（程序）选择，通常有1000多个。他们是标准的工具，但并非必不可少的那些/bin和/sbin。

/usr/bin包含命令，而配置文件位于其他位置。这都将功能实体（程序）及其配置文件和其他文件分开，但是就用户功能而言，这很方便，因为不将命令与其他任何内容混合在一起就可以简单地使用PATH指向可执行文件的变量。它还引入了清晰度。无论是什么都应该可执行。

我看看PATH，

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

恰好有六个位置包含我可以直接调用的命令（即，不是通过路径，而是通过可执行文件的名称）。

/home/tomas/bin 是我的私人可执行文件在主文件夹中的私人目录。
/usr/local/bin 我将在下面分别说明。
/usr/bin 如上所述。
/bin 上面也有介绍。
/usr/local/games是/usr/local（将在下面说明）和游戏的组合
/usr/games是游戏。不要与实用程序可执行文件混在一起，它们具有各自的位置。

现在到/usr/local/bin。这有点滑，已经在这里进行了解释：什么是/ usr / local / bin？。要了解它，您需要知道该文件夹/usr可能由许多计算机共享并从网络位置挂载。如前所述，在启动时不需要那里的命令，这与中的命令不同/bin，因此可以在启动过程的后期安装该位置。它也可以以只读方式安装。/usr/local/bin另一方面，是用于本地安装的程序，并且需要可写。因此，尽管许多网络计算机可能共享通用/usr目录，但它们中的每一个都将/usr/local在公共目录中安装自己的目录/usr。

最后，看一下PATH我的root用户：

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

它包含以下内容：

/usr/local/sbin，其中包含类型为的admin命令 /usr/local
/usr/local/bin，与普通用户可以使用的相同。同样，它们的类型可以描述为/usr/local。
/usr/sbin 是非必需的管理实用程序。
/usr/bin 是不必要的管理和常规用户实用程序。
/sbin 是必不可少的管理工具。
/bin 是管理员和常规用户必不可少的工具。

谢谢。我对如何组织要安装的程序非常感兴趣/home/tomasz/bin/，请参见unix.stackexchange.com/questions/431793/…–

— 蒂姆

我的理解是，虽然/bin和/usr/bin的确要分离，并且实际上是在避免网络安装/usr目录的问题，但/usr和的分离/usr/local是为了区分供应商提供的文件（/usr）和计算机本身手动安装的文件（），而/usr/local与之无关网络安装问题。这个准确吗？

— 敬二

4

@ Keiji，vendor-vs-local-management是当今最常见（和常规）的区别，但是，如果您查看传统的UNIX安装，/usr-off-a-network（相对于/usr/local，local，本地）并非闻所未闻。的。

— Charles Duffy

这在2018

— 真是

7

如今，我认为这是对经典UNIX的历史继承。

在最初的UNIX版本中，程序不像现在那么大。这些程序通常由一个使用系统库的可执行文件组成。因此，没有人考虑过将由几个自己的库组成的程序。主要库是C库，每个程序都知道它的位置。

同样，UNIX环境被视为最终产品（用于准备文档）。因此，所有工具的路径是固定的。

如今，HDD（硬盘驱动器）时代的固定路径带来了一些好处。如果FSH（文件系统层次结构）在单独的磁盘分区上拆分，并将带有二进制文件和库的分区放在HDD的主要扇区附近，则程序启动的时间会快一些。

— 尤里·贡查鲁克（Yurij Goncharuk）
source

6

有明显的优势，直到今天仍然有用。将二进制文件保存在其中/usr/bin，将静态数据文件保存在/usr/share其中，并将文件保留在其中，/var或者可以对其进行修改，或者/usr/var意味着可以使用安全措施来强制执行任何操作，使其不可执行share或不可var执行（通过使用noexec标志进行装载）；var不能修改任何外部内容（在使用dm_verity或类似措施生成签名的只读媒体的系统上）；等

— Charles Duffy

3

您所看到的类似于现代Unix的系统并不是真正的传统。

通常情况下，会有相当小的/和/usr等级只有系统实用程序，然后程序分别安装到一个子目录/usr/local，然后通过创建符号链接可用。

GNU软件的一个非常典型的设置是使用

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

GNU stow实用程序创建符号链接，以使软件可在标准路径上使用，而无需向PATH变量添加任何目录（就像Windows一样，并且容易在此积累）。

但是，现代Linux发行版将所有东西都作为现成的软件包提供，因此程序已成为“系统”的一部分。因为程序包管理器负责安装，所以不需要符号链接，并且分离程序没有任何用处（但是，由于必须扫描许多小目录，因此会减慢程序的启动速度）。

如果要将软件安装到主目录中，建议您也为此使用GNU stow-这将使您可以将程序分开，如果不使用程序包管理器，这是明智的。

我的传统设置是~/software/DIR将程序安装到其中的一个目录，然后使用stow inside DIR创建目录~/software/bin，~/software/share等等。这意味着我只需添加~/software/bin到PATH变量即可获取所有已安装的软件。

使用：

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

如果程序遵循GNU约定，则进行安装。

— 西蒙·里希特
source

2

您似乎在谈论按用途（/usr/bin针对可执行文件，/usr/lib针对库）而不是应用程序包（一个目录中的C ++编译器，另一个目录中的图像编辑程序）划分单个文件的样式。尽管在Unix系统中造成这种历史的原因很多，但当今也有一些力量倾向于使类似Unix的系统趋向于此：管理系统中大多数程序的程序包管理器。

在Windows上，从历史上一直到今天，应用程序一直负责提供自己的安装程序，尤其是卸载程序，甚至现在也经常不在任何中央应用程序列表中注册自己。在这种情况下，通常最好使应用程序拥有其尽可能多的文件的“自己的”目录。尽管这并不总是可以解决的（特别是在DLL的情况下），这有助于避免与其他应用程序发生冲突。

另一方面，Unix系统自90年代以来通常都有一个单独的可接受的软件包管理器，而一组则通过此软件包管理器提供大量的常用软件。（各种Unix系统官方包管理器包括yum和aptLinux系统，pkgsrcNetBSD的，并ports为FreeBSD，通常商业Unix系统也结束了一个非官方的，但被广泛接受的包管理器，以及，如brew适用于MacOS）。

这些程序包管理器的优点是，他们可以并且确实在“拥有”的各个子目录中跟踪系统上的每个文件。由于单个组在此处分配每个文件的名称和位置，因此它们都可以使用在它们之间共享的一小组目录。这提供了各种优势，尤其是在应用程序之间共享文件并减少搜索库和可执行文件所需的路径数量方面。

也就是说，在Unix中也有“每个应用程序单独目录”安装的悠久传统，通常在/opt目录下。

— cjs
source