合肥网站建设介绍在Linux下装置软件需要注意的20个事项:
1.开源并不只仅是源代码
“它是开源的，这是源代码。”可能会被疏忽。多数用户实践上并不需求源代码，他们想要一个二进制文件。开发者应该提早将他们程序打包，的确需求鼓舞开发者这样做。
2.规范化界面
遗忘关于文件包格式的争论吧，它将永远不会发作。我们需求一个规范软件包图形界面管理器，能够装置一切的软件包。想象一下，Synaptic在Ubuntu和 Fedora上运转，晓得是采用Debs包还是RPMs软件包格式，那该多好啊。
3.如何运转
“我曾经装置了Foo，但是如何运转呢?”一切遵照Freedesktop.org 规范的窗口管理器，都会遵照规范XDG 关于菜单入口的桌面文件规则。装置一个图形化程序就不用埋怨了。
4.更容易地添加软件仓库repositories
添加repositories，经常是从阅读器复制粘贴很长、很神秘的文本字符串到终端。一个规范的repository文件会使阅读器启动适宜的包管理器将其添加到repository，就是呈现一个对话框“are you sure/do you trust this”。
5.更简单地源代码编译
几程序没有编译器和装置阐明呢?很多都有通用的自动生成工具。这很容易呀。那为什么不给用户生成一个Install.sh脚本呢?同时检查一下依赖关系嘛。
6.Autotools = yuck
Autotools 很慢，看起来有一种神秘感。开发者主要运用Autotools。终端用户不应该看到这种东西。
7.降低文件系统杂乱水平
真有必要把文件装置到头昏眼花的目录中吗?从软件包管理器装置程序是个不错的倡议，卸载时分也能够晓得把谁给肃清了。构建源代码可能在卸载或从系统中移除时不够人性化，特别是开发者不提供卸载文件时。
8.规范综合包
若是我们不能在单文件包格式上达成协议，规范包管理又从何谈起呢?
9.规范软件包名字
为什么不同的发行版命名同一个软件包会有不同的名字?假如在发行版本之间有分歧的命名，处理软件包的依赖关系是不是会更容易些呢?
10.规范软件包拆分
不只是软件命名需求统一，在每个发行版本里，次软件包也需命名分歧。对上游开发者来说，分歧性还有一段路要走。
11.装置后运转
假如装置一份非后台运转的软件，有可能一装置完成，就运转它。要是当装置完成后你喜欢的软件包管理器呈现一个核对窗口，是不是愈加便当?不用从菜单启动，直接单击“装置并运转”，就这么点事儿。
12.确保源代码在包数据库构建
不只是从源代码装置有点痛苦，其实，包管理器也不晓得你终究曾经装置了什么，所以依赖总是呈现缺失，处理不好。要是有一个包管理器，可以从源码包构建，不只缓解装置的痛苦，也能让我们晓得装置了什么。
13.非全包软件包
应用程序和库文件分红单独的包，惹起了依赖和其他的问题，但是这被大多数软件包管理器一切效处理。我们也能够经过窗口把一切的东西放在一个包里，这就意味着把分散在文件系统里不同版本的相同库文件聚合到了一同。
14.肃清旧的依赖
当你装置软件时，它的依赖也被装置上了。但是当你移除软件包时，这些依赖还呆在系统里，逐步填满你的硬盘。软件包管理器不只应该移除不需求的依赖，还应该随时清算系统。
15.去除 -dev软件包
当我们尝试编译源代码时，包含库头文件的-dev 或 -devel软件包会带来无量的迷惑，比方经常呈现像”libfoo not found”这样的信息。当装置GCC或Autotools时，自动装置相关的 -dev 软件包，将会减少我们的痛苦。
16.自动完成源代码软件包的装置
假如每个发行版需求不同的软件包，或许单源软件包可以处理这一状况。但是假如软件包管理器可以自动下载、编译、装置源代码，这不就处理不同包需求了吗?
17.基于阅读器的软件包管理
如今，软件包管理器图形化界面曾经很棒了，但是远程装置又得回到命令行下。运转在网络阅读器上的软件包管理器将会使得阅读和晋级远程电脑上的软件愈加便当。
18.我们需求这么多的软件包吗?
一些项目有源代码，也提供Deb和RPM包文件下载。对每个Ubuntu衍生版原本说，都有本人的软件包，别说SUSE和Fedora的衍生版了。开发者们，真的有必要让不幸的终端用户堕入深渊吗?
19.非单一目录装置
有时，软件在本人的目录里装置的想法会冒出来。嗯，看起来很有吸收力。但对我们用户来说，单击“装置”按钮运转程序，然后在菜单启动就行了。
20.从网页链接到软件管理器
普通来说，当发现想尝试软件所在的一个网址后，接着你开端在软件管理器里面寻觅软件包，或冒险运用一个未经发行版本考证的网址的软件包。是不是，从URL启动软件包管理器进而寻觅软件包，这样会不会愈加便当一些呢?
