简单就是美

four

今天看了一个关于 gobolinux 的介绍，我觉得这个发行版有新意。

在 gobo 下，ls / ，你会看到:

2. Programs
3. Users
4. System
5. Files
6. Mount
7. Depot

复制代码

所有的程序都安装在 Programs 下面，单独占用一个目录，比如

2. /] cd /Programs
3. /Programs] ls
5. AfterStep     E2FSProgs    Htop        NTP          Subversion
6. ALSA-Driver   Ed           HTTPD       OpenOffice   Sudo
7. ALSA-Lib      Eject        Hydrogen    OpenSSH      Swfdec
8. ALSA-OSS      Elinks       IBM-Java2   OpenSSL      Synaptics
9. ALSA-Utils    Ethereal     ID3Lib      Pango        SysFSUtils
10. Ardour        Expat        IEEE80211   Patch        Sysklogd
11. Audacity      File         IMLib2      Perl         TCL
12. Aumix         Firefox      InetUtils   Pkgconfig    TeTeX
13. Autoconf      Flac         Intltool    PodXTPro     Texinfo
14. Automake      Flex         IpodSlave   Popt         TIFF
15. Bash          Fontconfig   Iptables    PPP          TiMidity++
16. ...

复制代码

每个程序的目录下面可以有多个版本共存，用 Current 链接到最新版本，比如

2. ls -l GTK+
3. total 12
4. drwxr-xr-x  10 root root 4096 2005-10-02 01:39 1.2.10
5. drwxr-xr-x   9 root root 4096 2005-08-21 05:48 2.6.7
6. lrwxrwxrwx   1 root root    6 2005-10-02 01:39 Current -> 2.6.7
7. drwxr-xr-x   4 root root 4096 2005-10-02 01:39 Settings

复制代码

你可能会问，那么 PATH 呢？Headers 呢？库文件呢？
很简单，链接到 System 下面的一个目录就好了，你看看人家：

2. ~] cat /etc/ld.so.conf
3. /System/Links/Libraries
5. ~] echo $PATH
6. /System/Links/Executables

复制代码

2. /System/Links/Libraries] ls -l | cut -b 49-
3. ...
4. libgtk-1.2.so.0 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
5. libgtk-1.2.so.0.9.1 -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
6. libgtk.a -> /Programs/GTK+/1.2.10/lib/libgtk.a
7. libgtk.la -> /Programs/GTK+/1.2.10/lib/libgtk.la
8. libgtk.so -> /Programs/GTK+/1.2.10/lib/libgtk-1.2.so.0.9.1
9. libgtk-x11-2.0.la -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.la
10. libgtk-x11-2.0.so -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.so.0.600.7
11. libgtk-x11-2.0.so.0 -> /Programs/GTK+/2.6.7/lib/libgtk-x11-2.0.so.0.600.7
12. libhfs.a -> /Programs/CDRTools/2.01/lib/libhfs.a
13. libhistory.a -> /Programs/Readline/5.0/lib/libhistory.a
14. libhistory.so -> /Programs/Readline/5.0/lib/libhistory.so.5.0
15. libhistory.so.5 -> /Programs/Readline/5.0/lib/libhistory.so.5.0
16. ...

复制代码

为了保持和传统的兼容性，gobo 也保留了 /usr/bin 等等目录，然后做链接，但是 ls 的时候会隐藏起来。

这么做除了更加符合一般人的逻辑，让人容易找到想要找的东西，还有一大好处：免去了“软件包管理器”这种东西。一个萝卜一个坑，多简单呀。软件管理，就是把一陀东西往一个地方一丢。不得不说，文件和文件夹就是简单又好用的管理方式。

回头看 openSUSE， 太复杂了，默认的软件总是很多，良莠不齐的。为了安装软件，先搞 zmd，后来搞 zypper，这些东西其实都不能提升用户的“使用体验”。因为都太 TMD 复杂了。最早 suse 有一个 YOU 来更新系统的，后来不知道变了多少次，现在用的是什么 packagekit，实在是越来越复杂，只有技术狂才对这些东西感兴趣。

我对 suse 搞两套 YAST 图形界面很反感的，qt 和 gtk，总得看来现在的情况是，两个的可用性都很烂。看看软件管理一项有多少个图标，可以看出他们是怎样不理解用户，只懂得开发的快感。

还有一个例子，设置桌面效果。suse 里面有 ccsm，太复杂了，搞了 simple-ccsm，对了，还要再来一个 kde-simple-ccsm。然后说明是，这是设置 compiz 的。或者是提示：您将要切换窗口管理器 KWin了。compiz 和 KWin 是什么东西？用户为什么要知道这么多诡异的程序的名称呢？


PS：
suse 11.1 的中文翻译正在进行中，人手很少，翻译很无趣，很多用语只有程序员才能看懂。

jin.liu

说的有道理，也有点讨厌Linux下的杂应用程序，就说音乐播放器吧。。如果有一个像foobar那样，省内存又好用的一个就好了，搞什么xmms，amarok，等等。。。

booman

老实说吧，个人觉得你所提到的yast已经算是所有Linux应用中，最体贴普通用户的一个了。而且，包管理这个东西，本来就是为了让安装和删除软件变得傻瓜才存在的，任何一个发行版，只要你愿意自己编译，都可以完全不用包管理器。要是那么容易就能让Linux变得简单易用，那MS都要颤抖了。

LinuxIsHard

哎, Linux很多缺点,不过在某些人的立场来看变成了风格. 虽然我本身也是engineer, 但我很不明白Linux的设计取向, 技术追求完美的出发点不知道是什么. performance or cost or user friendly? 这是我作为engineer的追求. 但Linux上我看不到有什么地方特别表现出他们的取向.
所有可执行文件都放在/bin下是另我极其讨厌的...绝不是因为习惯问题, 我觉得这从根本上和人类逻辑思考和搜索方式是冲突的.

杨珂

引发牢骚的帖。。。

没本

Post by LinuxIsHard;1900235
所有可执行文件都放在/bin下是另我极其讨厌的...绝不是因为习惯问题, 我觉得这从根本上和人类逻辑思考和搜索方式是冲突的.

也有优点的，你不用一个目录一个目录的去设置目录权限只有root可写，其他用户只读/运行。目录多了检测权限会比较麻烦。

powersp

呵呵，其實說的還是很有道理的。然而由於歷史因素，改變文件組織的習慣是非常困難的。
然而也有例外，那就是OS X。OS X的文件結構，既不同於一般的Linux，也跟BSD很不一樣，反而倒是這個gobolinux跟它很相似（在OS X,應用程序在/Applications裡，開發工具在/Developer裡，用戶目錄在/Users，bundles和dylib在/Library，~/Library或/System/Library裡，而UNIX實用工具依然是放在/bin，/sbin，/usr/bin和/usr/sbin裡）

然而OS X的這種做法實際帶來的負面影響遠比它提供的好處多：最大的問題是文件反而更加難找了，例如一個bundle，或一個dylib，可能存在與/usr/lib，usr/local/lib，/Library/Frameworks，/System/Library/Frameworks中的任何一處甚至更多。舉例而言，我就在我的OS X上發現了不止一個sqlite-ruby庫，而且埋藏在很隱蔽的/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1和/usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1中。

而且目前已經更認了這樣一個事實：在OS X這樣特殊的文件組織裡，想尋找分散在各處的文件是很痛苦的，尤其是那些隨OS X預裝的UNIX程序。所以我最後的結論是：遵循大家約定俗成的規矩是比較好的。

马大瞎子

Post by four;1900012

我对 suse 搞两套 YAST 图形界面很反感的，qt 和 gtk，总得看来现在的情况是，两个的可用性都很烂。看看软件管理一项有多少个图标，可以看出他们是怎样不理解用户，只懂得开发的快感。

这个说法有点意思，呵呵。
不过我觉得与其说是开发人员不知道如何理解用户，还不如说是他们正在慢慢地理解用户。其实如今的Linux发行版已经较过去有了很大地改进了，LZ大概是求胜心切了。另外一个，YaST不大好用的原因可能以网络本身居多。

cobranail

Post by powersp;1900336
呵呵，其實說的還是很有道理的。然而由於歷史因素，改變文件組織的習慣是非常困難的。
然而也有例外，那就是OS X。OS X的文件結構，既不同於一般的Linux，也跟BSD很不一樣，反而倒是這個gobolinux跟它很相似（在OS X,應用程序在/Applications裡，開發工具在/Developer裡，用戶目錄在/Users，bundles和dylib在/Library，~/Library或/System/Library裡，而UNIX實用工具依然是放在/bin，/sbin，/usr/bin和/usr/sbin裡）

然而OS X的這種做法實際帶來的負面影響遠比它提供的好處多：最大的問題是文件反而更加難找了，例如一個bundle，或一個dylib，可能存在與/usr/lib，usr/local/lib，/Library/Frameworks，/System/Library/Frameworks中的任何一處甚至更多。舉例而言，我就在我的OS X上發現了不止一個sqlite-ruby庫，而且埋藏在很隱蔽的/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1和/usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.1中。

而且目前已經更認了這樣一個事實：在OS X這樣特殊的文件組織裡，想尋找分散在各處的文件是很痛苦的，尤其是那些隨OS X預裝的UNIX程序。所以我最後的結論是：遵循大家約定俗成的規矩是比較好的。

这种问题linux里也有，比如某个程序A需要libxxx.so，而另一个程序B也需要libxxx.so，而这个可恶的libxxx.so依赖libyyy或者libzzz，还有其它一些lib，并且libxxx和libzzz只能二选一，这下问题就来了，不得不为A，B两个程序各自准备一份libxxx。这种情况在linux里很常见，一些大型的软件都有这个问题，特别是官方源之外软件，常碰上这种问题。

ganloo

Post by cobranail;1900763
这种问题linux里也有，比如某个程序A需要libxxx.so，而另一个程序B也需要libxxx.so，而这个可恶的libxxx.so依赖libyyy或者libzzz，还有其它一些lib，并且libxxx和libzzz只能二选一，这下问题就来了，不得不为A，B两个程序各自准备一份libxxx。这种情况在linux里很常见，一些大型的软件都有这个问题，特别是官方源之外软件，常碰上这种问题。

你说的其实就是个ABI兼容性的问题，这个sun公司有一个严格的要求，但是对于快速开发的Linux社区，这样的限制可能不太适用。有时候开发者会觉得开发新特性并同时保持ABI兼容是很困难的事情。如果不优化的话，程序大可像Windows那样在自己的安装包中打包一个相关的库文件；但是对于大多数你可以自己编译的开源软件，那简直是个笑话。