6.html

介绍linux下文件和设备编程

归档和压缩后缀<p>
有时候也还要尊重一些在局部范围内流行的惯例<br>
在有些个别项目或社区中还存在着与上面命名规则并不完全一致的，同时又是定义的非常好的他们自己的命名规则。比如Apache的模块通常就采用“mod_foo” 那样的命名方式，而且模块名中还会既包含模块的版本号又包含模块可工作的 Apache的版本号。同样，Perl模块在版本号中还有形如浮点数那样的表示方式（如1.303，而不是1.3.3），所以Perl 1.303版的模块Foo:Bar的发行包一般会被命名为Foo-Bar-1.303.tar.gz。（顺便说一句，Perl项目本身在1999年末已经采用了本文前面所介绍的GNU标准命名方法）。<p>
一方面我们要寻找并尊重那些特殊社区和开发者的特殊命名习惯﹔同时对于大部分其他的项目，我们建议大家按照以上的标准命名规则来进行。<p>
尽量找一个独一无二并且又很容易输入的项目名称（前缀）<br>
项目的主名称应该可以通用于整个项目中的其他文件，同时最好她既好读又好写（输入），还容易让人记住。所以建议您在没有充足理由的时候最好不要用下划线，不要使用大写字母或部分的字母大写。那些垃圾字符会污染人类的阅读习惯，干扰人们的搜索顺序，而且这看起来有点象是市井之徒在耍小聪明。<p>
当两个不同的项目使用同样的主名称时就会产生混淆。所以最好在您第一次发布您的项目的时候就能避免这种冲突。有两个网站上的名称统计列表可以帮助您检查是否冲突，他们是Metalab索引文件(http://www.ibiblio.org/pub/Linux)和Freshmeat附录(http://www.freshmeat.net)。另外还有一个好地方是：SourceForge (http://www.sourceforge.net)，在这些地方您可以做一点名称检查的工作。<p>
<p>
<br>



<center><A HREF="#Content">[目录]</A></center>
<hr><br><A NAME="I642" ID="I642"></A><center><b><font size=+2>选择好的许可证和版权说明︰理论篇</font></b></center><br>
2.选择一个好的许可证和版权说明︰理论篇<p>
许可证的选择实际上是为您自己选择一个您与其他开发者以及用户之间的社会契约。给软件附加版权说明实际上是使得给您创作的软件和其衍生产品加上许可证的行为合法化。<p>
开源与版权<br>
任何非公共的东西几乎都有版权，有的甚至还有不止一个版权。根据伯尔尼公约（1978年成为了联邦的法律），版权并不必显式地声明。也就是说，即使没有给出版权声明，一部作品的作者仍然是持有版权的。<p>
如何确定谁是某个东西的版权所有者是非常困难的，特别是在软件行业，因为有时候软件是许多人共同编写出来的。这也就是为什么许可证在软件发布中非常重要的原因。通过设定一些指出在何种情况下可以使用的条款，许可证授予用户权利并保证用户免受版权所有者各种行为对他们造成的伤害。<p>
在私有软件领域，许可证条款总是被设计成保护版权所有者。这是一种只给用户少得可怜的权利的做法，然而这种做法却保留尽可能多的合法权利给版权所有者。版权所有人非常关键，而且许可证的逻辑是如此严密以至于那些条款中的技术上精确已经都不重要了。<p>
相反，开源软件领域，则是另一番景象﹔在这里版权是用来保护许可证的。版权所有者唯一的权利就是确保许可证的落实。如果不这样的话，将只有很少的权利得到保留而让用户面临更多的取舍。特别是版权所有者自己也不能对您已经拥有的副本更改任何许可证条款。因此，在开源软件领域，版权所有者的作用要小的多而许可证条款显得更为重要。<p>
通常一个项目的版权所有者就是该项目的首席开发人员或发起组织。项目的首席开发员易人一般就意味着版权所有者发生了变化。不过这并不是一个严格的规则，许多自由软件项目有着多个版权所有人，这种领导模式至今还没有出现任何法律问题。<p>
许多项目选择让自由软件基金会作为版权所有者，理论上来说这样更有利于开源软件受到保护并让专业的律师来处理各种法律问题。<p>
怎样才有资格被称为开源软件<br>
根据许可的目的，我们可以区别许可证赋予您的各种不同权利。复制和再发布 的权利，使用的权利，为个人目的修改的权利， 发布修改后的作品的权利。一个许可证可能会对这些权利加上一些限制或给出一些附加条件。<p>
开源原动力站点（http://www.opensource.org）就是各种对软件“开源”或 “自由”思考的结果。该站点许可证的约束条款包括：<p>
<br>
无限制的拷贝权<p>
无限制的使用权<p>
无限制的针对个人使用目的而修改的权利<p>
这些指导方针保证修改后的二进制代码的再发布权﹔这与那些要求可以无障碍的取用软件的发行商的需求相吻合。这个做法使得软件的作者们可以要求修改的原始源代码采取把原有代码加上补丁程序的方式来再发布，这样就保全了作者们的原意同时又可以让他们“审查”其他人对项目的改进工作。<p>
OSD（开放源代码定义）是对“OSI开源软件认证”证书的法律定义，实际上她和人们曾经提出的各种关于“自由软件”的定义一样好。所有标准的许可证协议（如MIT、BSD、Artistic、GPL和LGPL协议）都与该提法一致（然而有时候，比如GPL，有更多的限制条款，在选择这些许可证时请仔细理解）。<p>
值得注意的是有些只允许非商业用途的许可证并没有资格被称为开源许可证，尽管他们标榜自己是“GPL”或者其他典型的许可证。这种许可证对特殊的拥有者，或者对个人和小组有着歧视。他们对通过光盘渠道再发布的做法以及其他商业化的推广开源软件的尝试做出种种限制，从而把事情搞的非常复杂。<p>
<p>



<center><A HREF="#Content">[目录]</A></center>
<hr><br><A NAME="I643" ID="I643"></A><center><b><font size=+2>选择好的许可证和版权说明︰实践篇</font></b></center><br>
3.选择好的许可证和版权︰实践篇<p>
本节将告诉您如何将上节介绍的理论转化为实际的行动。<p>
让您自己或者自由软件基金会成为软件的版权所有者<br>
有些情况下，如果您和您的项目背后有一个有法律专家的组织支持，您可能更愿意将版权授予那个组织。<p>
采用遵照开源定义的许可证<br>
开源软件的定义（OSD）是许可证的公共标准。OSD本身并不是一个许可证﹔而是给出了某个许可证要想成为开源许可证所必须包含的一个最小集合。 OSD和其他辅助资源可以从开源原动力站点获得。<p>
如果没有特别的需要，最好不要自搞一套许可证<br>
广为人知的OSD规范许可证有着相对固定的解释惯例。开发人员（甚至用户）已经了解这些许可证的真正内涵，合理的协调了各种风险和所需的代价。因此，在各种的情况下最好采用开源原动力站点上的某一许可证即可。<p>
如果您非要制作您自己的许可证协议，最好将这个许可证提交给开源原动力站点，让他们帮您把把关。这样可以省去日后不少争论和其他开销。如果没有认真考虑过，您很难想象一个在许可证方面发生的争吵所带来的后果是多么糟糕，由于许可证这种神圣盟约是开源软件价值体系中的核心问题，人们多半会在这个问题上反目为仇。<p>
此外，如果某个许可证已经在法庭上经过了考验，将证实这个许可证所建立的解释惯例是重要和合适的。不过截至本文编撰的时候（2000年中期），还没有任何开源许可证有着被支持或者被驳倒地法律案例。一般法庭应该会根据制定许可证的发起组织的期望和实践来解释那些许可证和契约，这几乎是一定的（至少在美国以及其他有着类似法律的英联邦国家是这样）。<p>
<p>



<center><A HREF="#Content">[目录]</A></center>
<hr><br><A NAME="I644" ID="I644"></A><center><b><font size=+2>好的开发习惯</font></b></center><br>
4.好的开发习惯<p>
本章节主要内容侧重于确保程序的可移植性，这不仅限于各种Linux系统，而且也针对各种UNIX系统。对其他UNIX系统保持可移植性并非是故意卖弄技术或者是遵守黑客的礼节，而是一种保持未来Linux自身发展不分裂的保障手段。<p>
另外，如果其他人正在试图将您的项目移植到其他非Linux系统上，一个可移植性好的项目可以让您最大限度的避开各种烦人的Email质询。<p>
写标准的ANSI C程序或者可移植的脚本程序<br>
要有可移植性和稳定性，您最好只用ANSI C写程序，要不就用某种脚本语言，这样能够保持可移植性的原因是他们底层的实现对于不同平台是一致的。<p>
有资格被成为跨平台的脚本语言包括 Python、Perl、Tcl、Emacs Lisp 和 PHP。普通的老式Shell则不具有好的可移植性﹔因为他们在不同平台上的实现有许多细微的语法差别，而且Shell的外壳环境极易受到用户个性化设置（如alias设置）的干扰。<p>
遵守C程序的可移植惯例<br>
如果您用C写程序，请记住一定要完全遵从ANSI标准──包括函数原型，这样可以帮助您去掉跨平台模块的不一致性。老的K&amp;R编译器已经成为了历史。<p>
另外，不要认为一些GCC特有的特征，比如“-pipe”编译选项以及嵌套函数等，在所有平台上都有效。因为这样的选项会在其他人试图将项目移植到非Linux、非GCC系统上时起作用并被“咬”一口。<p>
使用autoconf/automake/autoheader工具<br>
如果用C写程序，记住一定要用autoconf/automake/autoheader工具来处理各种移植性的问题，用这些工具完成系统配置信息的收集，创建makefile文件。现在许多人在打算编译源码时只希望通过“configure; make”这样简单的命令就可以得到干净利落的编译，事实上大家就是这么干的。<p>
发布前要仔细地检查代码<br>
如果是用C写程序，至少在每次发布之前要记得用 -Wall 编译选项重新编译一遍并去除编译中遇到的任何错误。这么做可以帮助您发现不少没有想到的错误。要是想更彻底的检查，那就用 -pedantic 选项再编译一遍。<p>
如果是用Perl，请使用perl -c(如果可行，有可能还有-T)来检查您的代码。请坚定不移地使用perl -w和&quot;use strict&quot;。（请详见Perl文档。）<p>
发布前要仔细地检查文档和README等文件<p>
文档发布前最好用拼写检查工具查一遍。如果您看起来没有能力拼写正确，而且也不关心文档的错别字，那么其他人很自然地联想到您的代码是否也同样是乱七八糟和粗心大意呢？<p>
<p>



<center><A HREF="#Content">[目录]</A></center>
<hr><br><A NAME="I645" ID="I645"></A><center><b><font size=+2>制作项目发布包的好经验</font></b></center><br>
5.制作项目发布包的好经验<p>
这一章节主要介绍您发布的项目应该具有什么样的形式，以方便其他人下载、检索和解压。<p>
确保tar包解压时会创建一个独立的新目录<br>
新手常犯的低级错误是制作了一个解压后把文件和目录直接解压在当前工作目录的tar包，这样做潜在的危险是会把原来已有的同名文件覆盖掉。记住， 千万不要这么干！<p>
而正确的方法是：您的项目的所有档案都是存放在项目所在目录下的标准目录结构中，这样tar包就可以解压在一个特定的目录下而不是当前目录。<p>
这里有一个Makefile文件的技巧示例展示了如何完成打包工作，这里假定您的项目所在目录名称为“foobar”，而SRC变量中是一个包含所有需要发布的文件列表：<p>
foobar-$(VERS).tar.gz:<br>
@ls $(SRC) | sed s:^:foobar-$(VERS)/: &gt;MANIFEST<br>
@(cd ..; ln -s foobar foobar-$(VERS))<br>
(cd ..; tar -czvf foobar/foobar-$(VERS).tar.gz `cat foobar/MANIFEST`)<br>
@(cd ..; rm foobar-$(VERS))<p>
<br>
编写README文件<br>
应该有一个名为README或者READ.ME的文件来说明整个源码的结构信息。古老的传统告诉我们，勇猛的探索者在解开您的压缩文件包后的第一件事情就是找出README文件来阅读。<p>
README文件中最好应该包括如下信息：<p>
<br>
整个项目的简介<p>
项目的WWW站点所在的URL（如果有的话）<p>
指出开发者编译整个项目所在的系统环境，并指出项目可能潜在的移植性问题<p>
重要文件和子目录的结构信息<p>
编译/安装步骤说明，或者指明这些信息所在的文件名（通常是INSTALL文件）<p>
项目主持人和参与者的名单列表，或者指出这些信息所在的文件（通常是CREDITS文件）<p>
最近关于本项目的一些进展情况和新闻，或者指出包含此信息的文件（通常是NEWS文件）<p>
遵照标准文件命名规则<br>
“勇猛的探索者”要想阅读README文件，他们就必须首先浏览解压后项目档案所在的根目录下的文件名。这些文件名本身就在向读者传达着许多信息。如果您遵照标准的命名规则就可以给那些探索者有价值得线索以便他们更好的理解您的意图。<p>
这里列出了一些标准文件名称和他们的涵义。当然并不是所有项目发布时都必须包含所有这些文件。<p>
<br>
README或READ.ME<br>
整个项目的结构信息说明，第一个需要阅读的文件。<p>
INSTALL<br>
配置、编译和安装该项目的说明信息<p>
CREDITS<br>
本项目所有贡献者的列表<p>
NEWS<br>
本项目最近的一些新闻和进展状况<p>
HISTORY<br>
本项目的历史发展演变记录<p>
COPYING<br>
指出本项目采用的许可证条款（通常采用GNU GPL）<p>
LICENSE<br>
本项目的许可证条款文件<p>
MANIFEST<br>
本项目的所有文件列表<p>
FAQ<br>
关于本项目的纯文本格式的常见问题解答<p>
TAGS<br>
为Emacs或vi准备的tag标记文件<p>
我们可以看出来，全部大写的文件名一般表示该文件是给人阅读的文档，而不是项目的一个组成部分。<p>
编撰一个FAQ文件可以帮您很多忙。如果某个问题经常被其他人问起，就把这个问题列入FAQ文件﹔然后指导用户在向您发文或提交出错报告前首先阅读FAQ文件。一份好的FAQ文件可以给项目维护者减轻好几个数量级的负担。<p>
另外在每次发布时都保留一个HISTORY文件和NEWS文件，并列明时间信息的做法是非常有好处的。在所有其他文件中，这两个文件可以让您在遇到一些专利侵权法律问题时有所准备（虽然这种情况至今还没有发生过，不过最好还是有备无患）。<p>
为项目升级做好准备<br>
只要您打算为您的项目发布新版本，项目就必定处在不断的变化之中。有些变化是不能向前兼容的。因此您必须认真思考安装程序设计上的问题，就是说让同一项目的不同版本的代码安装后可以共存在一个系统中。这个问题对库项目的发布尤为重要，因为您不能指望所有基于这个库的应用程序都会紧跟您的API接口规范的后尘。<p>