这是一个创建于 3757 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题。我是 linux 桌面用户其实无所谓了，这里主要想问一下这是不是一个好习惯。
我遇到的实际软件是 R 软件，系统自己安装的 R 只有少量包(packages )，需要用户自己补充很多包。多用户时，如果每个用户都在自己的主目录下建立包目录，会造成大量的重复。
这里假设系统管理员不懂大家需要什么包，而所有用户使用的包的版本是相同的。此时管理员决定放开 /usr/lib/R 的权限为 777 。
请问管理员的做法有无弊端？
第 1 条附言 2015-09-08 20:08:21 +08:00
R 更新了，结果大伙猜猜。。 R 从 3.2.1 更新到 3.2.2 ，自己又在 /usr/bin 建了一个文件夹，老的 3.1 里面的内容都删了，就剩下我手工弄过去的几个包了。。。
当然是认不出来了。我最后手工把这些包放回到自己 home 下的文件夹了，又回到以前的状态
===================
5 楼：
现在还不能 append ，我具体说一下。
R 的 package 就是他要用到的各种工具包，有点（我个人觉得啊，不一定对）类似于 python 中的 numpy flask 这种。
R 把默认的 package 全部放到 /usr/lib/RRO-3.2.1/R-3.2.1/lib64/R/library/中，我现在将这一文件夹递归设置成 777 权限，未来新的包也安装在此文件夹中，我并没有全部放开 /usr/lib/RRO-3.2.1 的权限。
$ ls /usr/lib/RRO-3.2.1/R-3.2.1/lib64/R/library/
base/ dichromat/ labeling/ plyr/ slam/
...(下略)(每个包是一个文件夹)
这时并不涉及到其他的 bin 、 include 等文件夹。
当然是认不出来了。我最后手工把这些包放回到自己 home 下的文件夹了，又回到以前的状态
===================
5 楼：
现在还不能 append ，我具体说一下。
R 的 package 就是他要用到的各种工具包，有点（我个人觉得啊，不一定对）类似于 python 中的 numpy flask 这种。
R 把默认的 package 全部放到 /usr/lib/RRO-3.2.1/R-3.2.1/lib64/R/library/中，我现在将这一文件夹递归设置成 777 权限，未来新的包也安装在此文件夹中，我并没有全部放开 /usr/lib/RRO-3.2.1 的权限。
$ ls /usr/lib/RRO-3.2.1/R-3.2.1/lib64/R/library/
base/ dichromat/ labeling/ plyr/ slam/
...(下略)(每个包是一个文件夹)
这时并不涉及到其他的 bin 、 include 等文件夹。
 | 1 tempdban 2015-09-05 23:58:06 +08:00 via Android 有各种弊端 各种库劫持 |
 | 2 skydiver 2015-09-06 00:01:03 +08:00 新建一个目录，放进去公用的包，然后再设置 R 的加载路径之类 这样比较合适 直接改默认目录权限不合适 |
 | 3 mkeith 2015-09-06 00:04:06 +08:00 现在硬盘很便宜啊 |
 | 4 HentaiMew 2015-09-06 00:04:20 +08:00 非常的不好，把包（虽然我不确定你这里的包具体指的什么）放进 /usr/lib 里面也很不好 |
 | 5 andyhenry OP @tempdban @skydiver @mkeith @HentaiMew 现在还不能 append ，我具体说一下。 R 的 package 就是他要用到的各种工具包，有点（我个人觉得啊，不一定对）类似于 python 中的 numpy flask 这种。 R 把默认的 package 全部放到 /usr/lib/RRO-3.2.1/R-3.2.1/lib64/R/library/中，我现在将这一文件夹递归设置成 777 权限，未来新的包也安装在此文件夹中，我并没有全部放开 /usr/lib/RRO-3.2.1 的权限。 $ ls /usr/lib/RRO-3.2.1/R-3.2.1/lib64/R/library/ base/ dichromat/ labeling/ plyr/ slam/ ...(下略)(每个包是一个文件夹) 这时并不涉及到其他的 bin 、 include 等文件夹。 这样是否也是不可行的？ |
 | 6 Comphuse 2015-09-06 00:19:59 +08:00 统计一下需求，把所有会用到的包都装上，然后把包目录 NFS export 出去，在客户端挂载为只读。 |
 | 7 lilydjwg 2015-09-06 00:31:14 +08:00 如果你的所有用户互相之间都是信任的还好。否则的话，用户 A 觉得是不是库 X 有问题啊，我去修改看看。然后用户 B 的进程就 crash 掉了。 不想重复的话，其实有个很直接的办法 zfs 。不过有其它问题。 建议用户要什么包提交请求，然后管理员帮忙安装。这个操作可以自动化进行。 也可以把那个文件交给一个专门的用户，然后授权你的用户们使用 sudo 切换到那个用户执行安装包的命令（仅能使用这一个命令）。（有被绕过的风险，但是你直接 777 风险更大，说不定哪个程序觉得 /usr/lib 下都是管理员授权的东西呢。） |
 | 8 Lanceliel 2015-09-06 01:55:53 +08:00 R 这种情况估计管理员根本不想知道用户需求……要装的包像山一样多，每一个源都慢成狗。 umask 022? |
 | 9 likuku 2015-09-06 02:57:43 +08:00 [我遇到的实际软件是 R 软件，系统自己安装的 R 只有少量包(packages )，需要用户自己补充很多包。多用户时，如果每个用户都在自己的主目录下建立包目录，会造成大量的重复。] 这些包都是有统一源提供么？假若不同人装的相同版本的包文件都一样(Byte 级别上一样)，那么可以利用 ZFS 的消除重复数据功能来解决空间问题（简单讲可以让 /home 独立为一个 zfs 卷，对其开启数据祛重功能：相近 /相似文件假若存到 zfs 上的数据块是相同的，则只保留一份数据块，多个文件只引用同一个数据块，效果就类似 dropbox 这样)。 不过，至少在 2013 年， zfs (freebsd )的 数据祛重 功能还是狠消耗系统资源，数据量上来之后，可能负载会高到系统假死。尤其在批量修改 /删除文件时，会很惨。 |
| 10 likuku 2015-09-06 02:59:39 +08:00 zfs dedupe 功能介绍： How To Size Main Memory for ZFS Deduplication : http://www.oracle.com/technetwork/articles/servers-storage-admin/o11-113-size-zfs-dedup-1354231.html |
| 11 likuku 2015-09-06 03:01:26 +08:00 当然，假若是用 linux ，也可以另外装一台 freebsd 跑 zfs 用 nfs 共享出去， linux 将 nfs 挂到 /home |
| 12 likuku 2015-09-06 03:23:42 +08:00 看来即便是 2015 年了， zfs 的 dedupe 还是很坑... ZFS dedup: tested, found wanting | JRS Systems: the blog : http://jrs-s.net/2015/02/24/zfs-dedup-tested-found-wanting/ 文末提到另一条路 zfs 的文件系统压缩功能赢了，是可以推荐的。 ZFS compression: yes, you want this | JRS Systems: the blog : http://jrs-s.net/2015/02/24/zfs-compression-yes-you-want-this/ 的确，我自己已经在生产环境使用 zfs 的压缩功能(LZ4 算法)，对于存储大量文本文件的状况，有非常好的效果，节省大量空间，效能上感觉不出与未压缩的差别。 虽然也有报道说最近一年里 zfs dedupe 也有了改进 ZFS dedupe is fixed soon - [H]ard|Forum : http://hardforum.com/showthread.php?t=1854062 |
Select Language