本文目录一览：
音译Linus Torvalds
李纳斯·托沃兹(Linus Torvalds)：Linux之父
这是网上常见的翻译。
如何参与linux 内核开发
如何参与Linux内核开发
---------------------
这是一篇将如何参与Linux内核开发的相关问题一网打尽的终极秘笈。它将指导你
成为一名Linux内核开发者，并且学会如何同Linux内核开发社区合作。它尽可能不
包括任何关于内核编程的技术细节，但会给你指引一条获得这些知识的正确途径。
如果这篇文章中的任何内容不再适用，请给文末列出的文件维护者发送补丁。
入门
----
你想了解如何成为一名Linux内核开发者？或者老板吩咐你“给这个设备写个Linux
驱动程序”？这篇文章的目的就是教会你达成这些目标的全部诀窍，它将描述你需
要经过的流程以及给出如何同内核社区合作的一些提示。它还将试图解释内核社区
为何这样运作。
Linux内核大部分是由C语言写成的，一些体系结构相关的代码用到了汇编语言。要
参与内核开发，你必须精通C语言。除非你想为某个架构开发底层代码，否则你并
不需要了解（任何体系结构的）汇编语言。下面列举的书籍虽然不能替代扎实的C
语言教育和多年的开发经验，但如果需要的话，做为参考还是不错的：
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
《C程序设计语言（第2版·新版）》（徐宝文 李志 译）[机械工业出版社]
- "Practical C Programming" by Steve Oualline [O'Reilly]
《实用C语言编程（第三版）》（郭大海 译）[中国电力出版社]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
《C语言参考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社]
Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C89标准，但也用到了一些
标准中没有定义的扩展。内核是自给自足的C环境，不依赖于标准C库的支持，所以
并不支持C标准中的部分定义。比如long long类型的大数除法和浮点运算就不允许
使用。有时候确实很难弄清楚内核对工具链的要求和它所使用的扩展，不幸的是目
前还没有明确的参考资料可以解释它们。请查阅gcc信息页（使用“info gcc”命令
显示）获得一些这方面信息。
请记住你是在学习怎么和已经存在的开发社区打交道。它由一群形形色色的人组成，
他们对代码、风格和过程有着很高的标准。这些标准是在长期实践中总结出来的，
适应于地理上分散的大型开发团队。它们已经被很好得整理成档，建议你在开发
之前尽可能多的学习这些标准，而不要期望别人来适应你或者你公司的行为方式。
法律问题
--------
Linux内核源代码都是在GPL（通用公共许可证）的保护下发布的。要了解这种许可
的细节请查看源代码主目录下的COPYING文件。如果你对它还有更深入问题请联系
律师，而不要在Linux内核邮件组上提问。因为邮件组里的人并不是律师，不要期
望他们的话有法律效力。
对于GPL的常见问题和解答，请访问以下链接：
文档
----
Linux内核代码中包含有大量的文档。这些文档对于学习如何与内核社区互动有着
不可估量的价值。当一个新的功能被加入内核，最好把解释如何使用这个功能的文
档也放进内核。当内核的改动导致面向用户空间的接口发生变化时，最好将相关信
息或手册页(manpages)的补丁发到mtk.manpages@gmail.com，以向手册页(manpages)
的维护者解释这些变化。
以下是内核代码中需要阅读的文档：
README
文件简要介绍了Linux内核的背景，并且描述了如何配置和编译内核。内核的
新用户应该从这里开始。
Documentation/Changes
文件给出了用来编译和使用内核所需要的最小软件包列表。
Documentation/CodingStyle
描述Linux内核的代码风格和理由。所有新代码需要遵守这篇文档中定义的规
范。大多数维护者只会接收符合规定的补丁，很多人也只会帮忙检查符合风格
的代码。
Documentation/SubmittingPatches
Documentation/SubmittingDrivers
这两份文档明确描述如何创建和发送补丁，其中包括（但不仅限于)：
- 邮件内容
- 邮件格式
- 选择收件人
遵守这些规定并不能保证提交成功（因为所有补丁需要通过严格的内容和风格
审查），但是忽视他们几乎就意味着失败。
其他关于如何正确地生成补丁的优秀文档包括：
"The Perfect Patch"
"Linux kernel patch submission format"
Documentation/stable_api_nonsense.txt
论证内核为什么特意不包括稳定的内核内部API，也就是说不包括像这样的特
性：
- 子系统中间层（为了兼容性？）
- 在不同操作系统间易于移植的驱动程序
- 减缓（甚至阻止）内核代码的快速变化
这篇文档对于理解Linux的开发哲学至关重要。对于将开发平台从其他操作系
统转移到Linux的人来说也很重要。
Documentation/SecurityBugs
如果你认为自己发现了Linux内核的安全性问题，请根据这篇文档中的步骤来
提醒其他内核开发者并帮助解决这个问题。
Documentation/ManagementStyle
描述内核维护者的工作方法及其共有特点。这对于刚刚接触内核开发（或者对
它感到好奇）的人来说很重要，因为它解释了很多对于内核维护者独特行为的
普遍误解与迷惑。
Documentation/stable_kernel_rules.txt
解释了稳定版内核发布的规则，以及如何将改动放入这些版本的步骤。
Documentation/kernel-docs.txt
有助于内核开发的外部文档列表。如果你在内核自带的文档中没有找到你想找
的内容，可以查看这些文档。
Documentation/applying-patches.txt
关于补丁是什么以及如何将它打在不同内核开发分支上的好介绍
内核还拥有大量从代码自动生成的文档。它包含内核内部API的全面介绍以及如何
妥善处理加锁的规则。生成的文档会放在 Documentation/DocBook/目录下。在内
核源码的主目录中使用以下不同命令将会分别生成PDF、Postscript、HTML和手册
页等不同格式的文档：
make pdfdocs
make psdocs
make htmldocs
make mandocs
如何成为内核开发者
------------------
如果你对Linux内核开发一无所知，你应该访问“Linux内核新手”计划：
它拥有一个可以问各种最基本的内核开发问题的邮件列表（在提问之前一定要记得
查找已往的邮件，确认是否有人已经回答过相同的问题）。它还拥有一个可以获得
实时反馈的IRC聊天频道，以及大量对于学习Linux内核开发相当有帮助的文档。
网站简要介绍了源代码组织结构、子系统划分以及目前正在进行的项目（包括内核
中的和单独维护的）。它还提供了一些基本的帮助信息，比如如何编译内核和打补
丁。
如果你想加入内核开发社区并协助完成一些任务，却找不到从哪里开始，可以访问
“Linux内核房管员”计划：
这是极佳的起点。它提供一个相对简单的任务列表，列出内核代码中需要被重新
整理或者改正的地方。通过和负责这个计划的开发者们一同工作，你会学到将补丁
集成进内核的基本原理。如果还没有决定下一步要做什么的话，你还可能会得到方
向性的指点。
如果你已经有一些现成的代码想要放到内核中，但是需要一些帮助来使它们拥有正
确的格式。请访问“内核导师”计划。这个计划就是用来帮助你完成这个目标的。它
是一个邮件列表，地址如下：
在真正动手修改内核代码之前，理解要修改的代码如何运作是必需的。要达到这个
目的，没什么办法比直接读代码更有效了（大多数花招都会有相应的注释），而且
一些特制的工具还可以提供帮助。例如，“Linux代码交叉引用”项目就是一个值得
特别推荐的帮助工具，它将源代码显示在有编目和索引的网页上。其中一个更新及
时的内核源码库，可以通过以下地址访问：
开发流程
--------
目前Linux内核开发流程包括几个“主内核分支”和很多子系统相关的内核分支。这
些分支包括：
- 2.6.x主内核源码树
- 2.6.x.y -stable内核源码树
- 2.6.x -git内核补丁集
- 2.6.x -mm内核补丁集
- 子系统相关的内核源码树和补丁集
2.6.x内核主源码树
-----------------
2.6.x内核是由Linus Torvalds（Linux的创造者）亲自维护的。你可以在
kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循以下步
骤：
- 每当一个新版本的内核被发布，为期两周的集成窗口将被打开。在这段时间里
维护者可以向Linus提交大段的修改，通常这些修改已经被放到-mm内核中几个
星期了。提交大量修改的首选方式是使用git工具（内核的代码版本管理工具
，更多的信息可以在获取），不过使用普通补丁也是可以
的。
- 两个星期以后-rc1版本内核发布。之后只有不包含可能影响整个内核稳定性的
新功能的补丁才可能被接受。请注意一个全新的驱动程序（或者文件系统）有
可能在-rc1后被接受是因为这样的修改完全独立，不会影响其他的代码，所以
没有造成内核退步的风险。在-rc1以后也可以用git向Linus提交补丁，不过所
有的补丁需要同时被发送到相应的公众邮件列表以征询意见。
- 当Linus认为当前的git源码树已经达到一个合理健全的状态足以发布供人测试
时，一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。
- 这个过程一直持续下去直到内核被认为达到足够稳定的状态，持续时间大概是
6个星期。
- 以下地址跟踪了在每个-rc发布中发现的退步列表：
关于内核发布，值得一提的是Andrew Morton在linux-kernel邮件列表中如是说：
“没有人知道新内核何时会被发布，因为发布是根据已知bug的情况来决定
的，而不是根据一个事先制定好的时间表。”
2.6.x.y -stable（稳定版）内核源码树
-----------------------------------
由4个数字组成的内核版本号说明此内核是-stable版本。它们包含基于2.6.x版本
内核的相对较小且至关重要的修补，这些修补针对安全性问题或者严重的内核退步。
这种版本的内核适用于那些期望获得最新的稳定版内核并且不想参与测试开发版或
者实验版的用户。
如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定
版内核。
2.6.x.y版本由“稳定版”小组（邮件地址stable@kernel.org）维护，一般隔周发
布新版本。
内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定
版内核接受的修改类型以及发布的流程。
2.6.x -git补丁集
----------------
Linus的内核源码树的每日快照，这个源码树是由git工具管理的（由此得名）。这
些补丁通常每天更新以反映Linus的源码树的最新状态。它们比-rc版本的内核源码
树更具试验性质，因为这个补丁集是全自动生成的，没有任何人来确认其是否真正
健全。
2.6.x -mm补丁集
---------------
这是由Andrew Morton维护的试验性内核补丁集。Andrew将所有子系统的内核源码
和补丁拼凑到一起，并且加入了大量从linux-kernel邮件列表中采集的补丁。这个
源码树是新功能和补丁的试炼场。当补丁在-mm补丁集里证明了其价值以后Andrew
或者相应子系统的维护者会将补丁发给Linus以便集成进主内核源码树。
在将所有新补丁发给Linus以集成到主内核源码树之前，我们非常鼓励先把这些补
丁放在-mm版内核源码树中进行测试。
这些内核版本不适合在需要稳定运行的系统上运行，因为运行它们比运行任何其他
内核分支都更具有风险。
如果你想为内核开发进程提供帮助，请尝试并使用这些内核版本，并在
linux-kernel邮件列表中提供反馈，告诉大家你遇到了问题还是一切正常。
通常-mm版补丁集不光包括这些额外的试验性补丁，还包括发布时-git版主源码树
中的改动。
-mm版内核没有固定的发布周期，但是通常在每两个-rc版内核发布之间都会有若干
个-mm版内核发布（一般是1至3个）。
子系统相关内核源码树和补丁集
----------------------------
相当一部分内核子系统开发者会公开他们自己的开发源码树，以便其他人能了解内
核的不同领域正在发生的事情。如上所述，这些源码树会被集成到-mm版本内核中。
下面是目前可用的一些内核源码树的列表：
通过git管理的源码树：
- Kbuild开发源码树， Sam Ravnborg sam@ravnborg.org
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
- ACPI开发源码树, Len Brown len.brown@intel.com
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
- 块设备开发源码树, Jens Axboe axboe@suse.de
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
- DRM开发源码树, Dave Airlie airlied@linux.ie
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64开发源码树, Tony Luck tony.luck@intel.com
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- ieee1394开发源码树, Jody McIntyre scjody@modernduck.com
git.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
- infiniband开发源码树, Roland Dreier rolandd@cisco.com
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata开发源码树, Jeff Garzik jgarzik@pobox.com
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- 网络驱动程序开发源码树, Jeff Garzik jgarzik@pobox.com
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia开发源码树, Dominik Brodowski linux@dominikbrodowski.net
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI开发源码树, James Bottomley James.Bottomley@SteelEye.com
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
使用quilt管理的补丁集：
- USB, PCI, 驱动程序核心和I2C, Greg Kroah-Hartman gregkh@suse.de
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, 部分i386, Andi Kleen ak@suse.de
其他内核源码树可以在的列表中和MAINTAINERS文件里
找到。
报告bug
-------
bugzilla.kernel.org是Linux内核开发者们用来跟踪内核Bug的网站。我们鼓励用
户在这个工具中报告找到的所有bug。如何使用内核bugzilla的细节请访问：
内核源码主目录中的REPORTING-BUGS文件里有一个很好的模板。它指导用户如何报
告可能的内核bug以及需要提供哪些信息来帮助内核开发者们找到问题的根源。
利用bug报告
-----------
练习内核开发技能的最好办法就是修改其他人报告的bug。你不光可以帮助内核变
得更加稳定，还可以学会如何解决实际问题从而提高自己的技能，并且让其他开发
者感受到你的存在。修改bug是赢得其他开发者赞誉的最好办法，因为并不是很多
人都喜欢浪费时间去修改别人报告的bug。
要尝试修改已知的bug，请访问网址。如果你想获得
最新bug的通知，可以订阅bugme-new邮件列表（只有新的bug报告会被寄到这里）
或者订阅bugme-janitor邮件列表（所有bugzilla的变动都会被寄到这里）。
邮件列表
--------
正如上面的文档所描述，大多数的骨干内核开发者都加入了Linux Kernel邮件列
表。如何订阅和退订列表的细节可以在这里找到：
网上很多地方都有这个邮件列表的存档(archive)。可以使用搜索引擎来找到这些
存档。比如：
在发信之前，我们强烈建议你先在存档中搜索你想要讨论的问题。很多已经被详细
讨论过的问题只在邮件列表的存档中可以找到。
大多数内核子系统也有自己独立的邮件列表来协调各自的开发工作。从
MAINTAINERS文件中可以找到不同话题对应的邮件列表。
很多邮件列表架设在kernel.org服务器上。这些列表的信息可以在这里找到：
在使用这些邮件列表时，请记住保持良好的行为习惯。下面的链接提供了与这些列
表（或任何其它邮件列表）交流的一些简单规则，虽然内容有点滥竽充数。
当有很多人回复你的邮件时，邮件的抄送列表会变得很长。请不要将任何人从抄送
列表中删除，除非你有足够的理由这么做。也不要只回复到邮件列表。请习惯于同
一封邮件接收两次（一封来自发送者一封来自邮件列表），而不要试图通过添加一
些奇特的邮件头来解决这个问题，人们不会喜欢的。
记住保留你所回复内容的上下文和源头。在你回复邮件的顶部保留“某某某说到……”
这几行。将你的评论加在被引用的段落之间而不要放在邮件的顶部。
如果你在邮件中附带补丁，请确认它们是可以直接阅读的纯文本（如
Documentation/SubmittingPatches文档中所述）。内核开发者们不希望遇到附件
或者被压缩了的补丁。只有这样才能保证他们可以直接评论你的每行代码。请确保
你使用的邮件发送程序不会修改空格和制表符。一个防范性的测试方法是先将邮件
发送给自己，然后自己尝试是否可以顺利地打上收到的补丁。如果测试不成功，请
调整或者更换你的邮件发送程序直到它正确工作为止。
总而言之，请尊重其他的邮件列表订阅者。
Linux操作系统具有哪些特点
LINUX系统的主要特点。\x0d\x0a1、开放性：特别是遵循开放系统互连(OSI)国际标准。\x0d\x0a2、多用户：操作系统资源可以被不同用户使用，每个用户对自己的资源(例如：文件、设备)有特定的权限，互不影响。\x0d\x0a3、多任务：计算机同时执行多个程序，而同时各个程序的运行互相独立。\x0d\x0a4、良好的用户界面：Linux向用户提供了两种界面：用户界面和系统调用。Linux还为用户提供了图形用户界面。它利用鼠标、菜单、窗口、滚劢条等设施，给用户呈现一个直观、易操作、交互性强的友好的图形化界面。\x0d\x0a5、设备独立性：操作系统把所有外部设备统一当作成文件来看待，只要安装驱劢程序，任何用户都可以象使用文件一样，操纵、使用这些设备。Linux是具有设备独立性的操作系统，内核具有高度适应能力。\x0d\x0a6、提供了丰富的网络功能：完善的内置网络是Linux一大特点。\x0d\x0a7、可靠的安全系统：Linux采取了许多安全技术措施，包括对读、写控制、带保护的子系统、审计跟踪、核心授权等，这为网络多用户环境中的用户提供了必要的安全保障。\x0d\x0a8、良好的可移植性：将操作系统从一个平台转移到另一个平台使它仍然能_其自身的方式运行的能力。Linux是一种可移植的操作系统，能够在从微型计算机到大型计算机的任何环境中和任何平台上运行。
企业开源指南：开源项目管理工具
为了让开源项目办公室顺利运行，您需要正确的工具。这些关键的任务工具将用于追踪各部门的目标与指标，从工程部门和法律部门到行政领导部门、公关部门与营销部门，同时给予员工收集数据、提供开源软件运行快照和管理公司内部开源软件日常使用所需要的全部资源。
-- Todo
开放源代码的战略性应用之路，起始于一个精心策划、组织与授权的开源项目办公室，以指导和管理开源的创建、分发和使用。但这仅仅只是第一步。为了让开源项目办公室顺利运行，您需要正确的工具。这些关键的任务工具将用于追踪各部门的目标与指标，从工程部门和法律部门到行政领导部门、公关部门与营销部门，同时给予员工收集数据、提供开源软件运行快照和管理公司内部开源软件日常使用所需要的全部资源。
本指南提供了如何开始您的开源工具集建设的详细信息和场景，包括用于跟踪和管理您的开源项目的最重要工具的信息。指南中提及的许多工具已由Linux基金会和该领域的其他领导者创建并开放源代码，可以免费且便捷地为您的项目所使用。您还可以找到一个仪表盘安装程序的示例，该程序融合并展示了多种工具的信息。
一旦您的开源项目办公室启动运行，就应该同时收集合适的软件工具，这些工具允许您的开发团队管理、跟踪、指导和推进其开源项目、开源贡献与开源发布。
在您开始您的开放源代码之路时，使用正确的目标工具还将使开发人员和其他员工的工作更为轻松，也将提供更好的结果，并将成为公司开源项目的成功协作与沟通的基础。
公司所需的开源工具有哪些？早期的讨论大多认为，这取决于公司的业务、产品和服务，以及公司如何服务它的客户和员工。由于开源项目办公室制定了规划流程和战略地图，因此可以选择那些能整合进公司的目标、流程和基础架构的工具。
最终，知道您将需要使用哪些工具的唯一方法，就是了解您想要对开放源代码进行何种操作。
以下是开源项目办公室选择所需管理工具的基本步骤：
这些工具一旦被选定，在落地使用之前，还需要一些额外的准备：
当您在选择工具时，实施操作有助于记忆，当然这也可能会影响您的决定。例如，具有陡峭学习曲线的工具可能需要更多的培训。
在认识到达成组织的目标上你团队的需求，以及自身情况和基础架构的潜在限制之后之后，接下来要做的就是要 探索 并了解那些已准备就绪且可供您使用现有工具。由于大多数工具本身就是开源的，所以如果它们一开始并不能满足您的确切需求，您的开发团队可以联系这些工具的开发者，看看他们是否可以协作根据新的用途添加一些特性。
讽刺的是，许多开源项目办公室并不经常直接使用其他公司开发的工具，或与其他公司合作来开发他们管理开源项目所需的工具。通常，他们想要这样做，但包括 Facebook 和微软在内的许多企业已经拥有现有的工具套件，这些工具套件在真正成为一个合作议题之前就已经实现。由于他们已经拥有了自己的工具集并进行了投资，他们似乎并没有很大意愿采用其他公司的工具。
这就是现在才刚开始构建自己的开源项目的公司具有显著优势的地方。由于他们现在正在建立自己的开源项目办公室并进入开源领域，因此他们不必为受到这样的限制而烦恼。
相反，他们可以聪明地利用别人的成功经验与失败教训，并利用近年来领先的公司所创建的成熟工具来构建自己的开源工具箱。 Linux 基金会的开源行业组织，TODO Group，一直致力于组装一个装满工具的 “Open Source Program Office in A Box” 入门套件，这将使公司能够通过一套紧密结合的预先组装工具开展开源工作。入门套件目前尚未开发完善，但希望最终可以让公司付出更少的初始努力，更轻松地部署和配置他们所需的工具。从事这个项目的 TODO Group 成员包括 Adobe、Capital One、Comcast、Facebook、谷歌、eBay、IBM、微软、三星和 Twitter。
除了适当的工具之外，公司还应该有中央仪表板，以便他们实时监控和跟踪他们的开源项目和开发情况。许多公司可能已经拥有了用于现有开发工作和应用程序的仪表板，并且能够将现有仪表板与其开源工作整合在一起。否则，他们应该创建或采用新的仪表板来改进其开源部署的管理。
正在出现越来越多的用于管理和报告开源项目的工具，这一趋势已经非常明显。如果您的开源项目刚刚开始，那么将您的研究集中在几个您启动和运行所需的基本工具上会更有帮助。
随着您的项目不断发展，以及使用这些工具的经验越来越丰富，您可以开始采用新的工具，来帮助自动化并简化您的流程，响应业务需求的增长。切记，新选择的工具将用于内部文化和流程的补充和支持——而不是引导它们。
以下章节列出了几个基本的工具类别，几乎所有开源项目日常使用的工具都可以划分到这些类别。这有助于您对该研究有系统性的认识。
为满足公司的更多需求，自动化工具变得越来越庞大且规模化。它们可以准确地告诉您谁正在为您的项目做出贡献，并且可以帮助您消除那些减慢项目进度的程序摩擦。
据微软表示，在其开源项目办公室里，大约有 8000 个仓库在 GitHub 上托管，涉及约 11,000 名贡献者，而在 2016 年约有 40,000 个内部请求应用于开源项目。为了管理这些请求，以及所创建的代码和正在更新的代码版本，公司转而使用可以自动化解决混乱的工具。不仅如此，由于数百个项目中很可能会共用同一段代码，因此必须对其进行仔细跟踪，以便在出现安全错误时，可以快速绘制并修复所有的软件影响。在如此大规模的情况下，自动化非常关键，手动更新几乎是不可能的。
那些有助于管理关键任务的工具，也是需要考虑和获取的。例如用于项目管理、跟踪项目质量状况，以及确保开发人员、开源社区和其他公司内部人员之间的清晰且快速沟通的。
大多数通过开源项目办公室开发的企业软件项目都使用 GitHub 作为其集中托管和开发的平台。
GitHub 是一个在线源代码管理站点，它允许开源开发人员在一个中央“存储库”或存储空间中管理和存放他们的代码，参与者可以协作并开发他们的代码。如今，大约有 6400 万个开源代码项目在 GitHub 上托管，涉及大约 2300 万个开发人员。
GitHub 用户可以添加代码、查看已提交的代码、申请更改、获取并提供反馈，以及使用该服务提供项目管理。GitHub 使用 Git Version Control System ，这是由 Linux 创建者 Linus Torvalds 开发的开放源代码项目，为代码和合作开源人员提供了组织机构。每位“贡献者”都有他们正在处理的项目存储库的副本，他们可以在自己计算机中的副本里进行更改，然后将其提交回项目以供未来纳入。然后，“ 拉取请求(pull request)”（ 示例 ）或代码贡献会被项目组织者审查、讨论、修改，最后批准或拒绝。
代码扫描和合规工具也很重要，它们有助于追踪代码起源和许可要求。关注被引入自身基础架构、产品和服务中的开放源代码以确保符合许可证的要求，对于公司来说是很重要的。
例如，您的应用程序可能包含数千个开源组件。为了保护您的公司免于法律纠纷，了解这些细节是至关重要的。在风险较高的情况下，用户必须根据其业务在风险谱中的所处位置，深入了解代码，从而深入地审核并验证他们所说的许可证。（请参阅我们关于使用和分发开放源代码的指南。）
如前所述，GitHub 是服务于目前大多数开源项目办公室的专业源代码管理系统。但是 GitHub 本身并不能满足项目代码管理的所有需求——特别是当您大规模发展的时候。
开源世界中所使用的一些工具旨在通过添加欠缺的功能来改进GitHub本身，例如支持检查开发者原产地证书（DCO）语句，以确保代码可以被合法授权且应用于开源项目中。
GitHub 在代码审查方面也存在一些不足之处，所以有其他可用的工具可以自动将有问题的代码发回给创建它的贡献者，然后要求他们检查并做出必要的修改。GitHub 没有办法强迫任何人检查他们的代码，而这些聪明的工具解决了这一问题，使工作流程得以改善。
其他 GitHub 特定工具的功能用于提高 GitHub 的性能指标，这些功能通常针对特定项目，而不是提供给整个组织详细信息。对于在多个 GitHub 项目中维护许多开源代码库的公司而言，需要更好的工具来组织和汇总它们，使之有意义。亚马逊、Netflix 和微软提供了大量这样的工具来帮助完成这些任务。
以下是一些最流行和实用的源代码管理工具，可以简化并帮助您的 GitHub 运作：
随着开源项目的发展和成熟，监控和跟踪开源项目的整体质量是企业开源项目的核心任务。为了实现这一目标，您必须收集相应的工具，这些工具应当能够反映单独的开源项目的执行过程并反映单独的开源项目在数十、数百甚至数千个项目中被它们的社区接收的过程。同时，这些工具还必须兼具转化能力， 能够将收集的数据转化为体现整个开源组合中整体项目性能的有意义的、实用的且可操作的信息。
这其中的关键是，您收集到的数据应当可以转化为关键且有用的信息 – 而不是些无用的指标，例如详细说明项目已记录了多少“观察者”明星，自项目开始以来有多少贡献者参与了该项目，亦或是缺乏重要背景资料的其他指标。
最好的项目质量监测工具还必须帮助项目团队对支持他们工作的社区做出回应，同时鼓励贡献开发者的参与和多样化。这意味着这些工具可以帮助保持人员快速响应社区成员发布的问题或反馈，以便他们保持热情参与，且不会感到厌倦并转向其他项目。
一些开源社区有大量的贡献者，而其他一些开源社区则成员较少。项目质量监测工具需要能够适用于各种规模的项目。
以下是一些最受欢迎且实用的项目数据统计和项目质量跟踪工具：
TODO Group 还提供了一个 很好的附加工具列表 ：
当然，开源的发展并不仅仅关于代码的开发。它还需要在企业内外部从事项目工作的不同群体之间以及公司开源项目办公室的工作人员之间建立良好的沟通与合作。
为了达到上述目标，开发人员可以依靠他们可能已经应用于其他项目的工具，例如 Internet Relay Chat（IRC） ，开发人员可以发布 与开源开发相关的问题并快速收到回复 。另一个例子是 TWiki ，它是一个开源企业 Wiki 和 Web 协作的平台，开发人员可以在其中讨论代码和项目及相关主题。
此外，企业还可以通过社交媒体平台，门户网站，开源项目存储库和其他能够进行输入、提问和讨论的平台促进沟通交流。
其他有用的工具还包括 Facebook 公司的 mention-bot ，它可以通过自动关联潜在审查者来获得拉取请的快速输入周转以审查代码。当 GitHub 目变得太大导致社区成员无法订阅项目的所有通知时，这一工具尤其值得推荐。
然后是 Slack ，这是一个在线团队项目管理与沟通平台，在这一平台中用户可以访问和共享消息和文件，管理工作流程，搜索信息等等。Slack可以通过设置接收支持请求、代码签入、错误日志和其他任务的通知。
除此之外，当谈到公司参与和支持开源时，不要忘记您公司的公关与营销人员。包括 Twitter、Reddit、Facebook、LinkedIn、Google+ 等网站在内的社交媒体帐户以及企业内外部的博客和网站的使用都是非常重要的。客户关系管理（CRM）软件以及电子邮件群发和新闻简报可以帮助公司让客户了解他们的开源进展。
当谈到企业为开源项目提供并应用的工具时，按理说最重要的是那些帮助企业管理自身企业规模 GitHub 操作的工具。GitHub 是一个可以提供许多操作的完美平台，但对于谷歌、微软、脸书、Twitter、LinkedIn 等大型的复杂公司而言，使用标准的 GitHub 产品可能会有很多限制。
大型企业通常需要更多的功能，包括如身份管理、设置和权限管理，安全性和双重身份验证执行，以及深入理解和跟踪代码存储库的方法。
因此，这些大型企业常需要构建专门的自动化工具来处理诸如入职、离职、安全策略执行以及给予开发人员请求的存储库访问权限等任务。
为满足自身的特殊需求，微软构建了自己的工具来处理诸如此类的任务，以简化和改进其开源项目。微软在 GitHub 上运行良好 ，拥有约 1,345 个存储库，迄今为止涉及约 3,580 名开发人员。
微软创建了一款定制的自助服务—— GitHub management and onboarding portal ，用于组织其项目、存储库和团队。在其最简单的层次上，基于 Web 的门户允许开发人员将他们的微软公司ID映射到他们的GitHub ID，这可以提高系统安全性并帮助简化参与大量重要项目的大量开发人员的组织工作。
该门户还允许员工使用 GitHub 和微软进行身份验证。其创建了员工身份的一个“虚拟链接”，以便根据他们的工作角色向他们提供任务所需权限以完成工作。如果员工离开公司，可根据需要调整系统以删除或重新分类其访问权限。
门户运行在一台或多台云服务器上，并依靠缓存来帮助进行会话和减少 GitHub API 的压力。微软门户平均每天可提供约 1000 名独立用户作为其工程师的工具，这是该公司不断发展的开源工作的一部分，该工作现在包括超过 10,000 名正在使用、贡献和发布开放源代码的工程师。
没有人认为使公司进入开源世界是一件简单的事情。但其他许多公司，包括微软和谷歌等巨头已经在您前面这样做了，而且已提供了详细的路线图、代码和建议等，这将使您自己的开源旅程变得更加轻松。
开源项目办公室的创建和选择一系列关键工具来开始开源工作，选择权掌握在您手中。它们很可能已经激发了开发人员的极大期望，开发人员中的许多人可能已经自发为开源项目做贡献（或在工作中，隐秘地）。
通过开源项目的合作并邀请其他人与您合作，您的公司可以获得不可估量的收益，且能通过节能和创新推动公司发展。
拥有正确的工具对于授权贵公司的开放创新至关重要。
Linux 简介
Linux 内核最初只是由芬兰人李纳斯·托瓦兹（Linus Torvalds）在赫尔辛基大学上学时出于个人爱好而编写的。
Linux 是一套免费使用和自由传播的类 Unix 操作系统，是一个基于 POSIX 和 UNIX 的多用户、多任务、支持多线程和多 CPU 的操作系统。
Linux 能运行主要的 UNIX 工具软件、应用程序和网络协议。它支持 32 位和 64 位硬件。Linux 继承了 Unix 以网络为核心的设计思想，是一个性能稳定的多用户网络操作系统。
Linux 的发行版说简单点就是将 Linux 内核与应用软件做一个打包。
目前市面上较知名的发行版有：Ubuntu、RedHat、CentOS、Debian、Fedora、SuSE、OpenSUSE、Arch Linux、SolusOS 等。
今天各种场合都有使用各种 Linux 发行版，从嵌入式设备到超级计算机，并且在服务器领域确定了地位，通常服务器使用 LAMP（Linux + Apache + MySQL + PHP）或 LNMP（Linux + Nginx+ MySQL + PHP）组合。
目前 Linux 不仅在家庭与企业中使用，并且在政府中也很受欢迎。
目前国内 Linux 更多的是应用于服务器上，而桌面操作系统更多使用的是 Windows。主要区别如下
比较WindowsLinux界面界面统一，外壳程序固定所有 Windows 程序菜单几乎一致，快捷键也几乎相同图形界面风格依发布版不同而不同，可能互不兼容。GNU/Linux 的终端机是从 UNIX 传承下来，基本命令和操作方法也几乎一致。驱动程序驱动程序丰富，版本更新频繁。默认安装程序里面一般包含有该版本发布时流行的硬件驱动程序，之后所出的新硬件驱动依赖于硬件厂商提供。对于一些老硬件，如果没有了原配的驱动有时很难支持。另外，有时硬件厂商未提供所需版本的 Windows 下的驱动，也会比较头痛。由志愿者开发，由 Linux 核心开发小组发布，很多硬件厂商基于版权考虑并未提供驱动程序，尽管多数无需手动安装，但是涉及安装则相对复杂，使得新用户面对驱动程序问题（是否存在和安装方法）会一筹莫展。但是在开源开发模式下，许多老硬件尽管在Windows下很难支持的也容易找到驱动。
HP、Intel、AMD 等硬件厂商逐步不同程度支持开源驱动，问题正在得到缓解。使用使用比较简单，容易入门。图形化界面对没有计算机背景知识的用户使用十分有利。图形界面使用简单，容易入门。文字界面，需要学习才能掌握。学习系统构造复杂、变化频繁，且知识、技能淘汰快，深入学习困难。系统构造简单、稳定，且知识、技能传承性好，深入学习相对容易。软件每一种特定功能可能都需要商业软件的支持，需要购买相应的授权。大部分软件都可以自由获取，同样功能的软件选择较少。
编程经典语录
篇一：程序员9条经典的编程语录
2013年伊始，告别短暂的小长假，我们又回到了紧张的工作氛围中，在这篇文章中，我收集了几条非常有趣的且广受欢迎的编程术语，为广发编程爱好者加波助澜，就像Linus Torvalds说的那样，我们因为兴趣而编程。 2013年伊始，告别短暂的小长假，我们又回到了紧张的工作氛围中，在这篇文章中，我收集了几条非常有趣的且广受欢迎的编程术语，为广发编程爱好者加波助澜，就像Linus Torvalds说的那样，我们因为兴趣而编程。
1. 在水里行走和以一个需求规格进行软件开发类似，即如果水或需求都被冻结住，那么行走和软件开发都会变得很容易。-——Edward V Berard
2. 不要担心程序异常，如果它总是正确的话你早就失业了。——软件工程Mosher定律
3. 设计的附加价值高于它所增加的花费。——Thomas C. Gale
4. 没有好的团队就开发不出好的软件，但绝大多数的软件开发团队看起来就像不健全的家庭一样。——Jim McCarthy
5. 我才不关心我的代码是否能在你的机器上工作！我们不会给你提供机器。——Vidiu Platon
6. “靠代码行数来衡量开发进程就好比用重量来衡量飞机制造的进度。”——Bill Gates
7. “程序员的问题是，不到太晚，你永远不会知道他在做着些什么。”——Seymour Cray
8. “大部分好的程序员编程并不是为了钱或名望，而只是因为纯粹的乐趣。”——Linus Torvalds
9. “有两种生成一个软件设计方案的途径。一个是把它做得如此简单，以致于明显不会有漏洞存在；另一个是把它做的如此复杂，以致于不会有明显的漏洞存在。”——C.A.R. Hoare
篇二：程序员经典语录
1. 选择当前科技领域的一个小子集，亲近它、拥抱它，并且尝试推进这个小领域的发展。
2. 理解不同数据结构和算法的优缺点，不单是内存中，还有磁盘上的表现。
3. 首先深刻理解你所在的领域，然后抛开计算机，像普通用户那样观察和体会。
4. 时刻准备好（包括能力和心理上）向深层探索，不仅仅是一两层，而是好几层。要知道，是否能在编程时势如破竹，与你所能达到的技术深度关联紧密。
5. 运用你的想象力，总是问这样的问题“还有更好的办法吗？”跳出固有的思维模式，最好的实现方式也许还没有人尝试过。
6. 永远不要过早退出，不要两次编写同一段代码，不要将一个变量命名为另一个变量的子集。如果不理解这些规则，也许你会争辩，不过一旦你这么做了，它们就能帮助你写出更好的代码，否则你将永远停留在初级程序员的水平。
7. 学习如何进行基准测试，学会的那一天，你会发现世界将变得不同。
8. 学会如何分辨琐事和细节，只将精力集中于细节。
9. 不要总是向你的用户和管理者妥协，有时应该让他们知道，他们自以为的并不是那么重要。
10. 写一个框架，无论你是否计划使用它。这个过程会让你学到靠其他方式无法学到的东西。
11. 把学到的东西教给别人，无论是口口相授还是文以载道，你都会发现自己也能从这个过程中收获良多。
12. 找到旁人写的这样一些代码——它们实现了重要的功能，但写得并不够聪明。重写它们，然后告诉自己永远不要犯相同的错误。
13. 在人生的某个时候，运营你自己的事业（服务或产品）。你能从中学到当职员时无法领悟的编程技巧 你认为最具争议的编程观点是什么？
C#专家Jon Skeet曾在StackOverflow上提出这个问题。这里列举最热门的前10条讨论。
1. 业余时间不以编程为乐者，永远赶不上那些以此为乐的同行
即使最聪明、最有才华的人，若只是将编程作为工作，就永远成不了真正优秀的程序员。以编程为乐的人会在业余时搞些小项目，或者摆弄各种编程语言和编程思想。
2. 唯一能放之四海而皆准的最佳实践，是“用脑子思考”
太多人喜欢追逐众多时髦技术，想方设法把各种方法、模式、框架用到不适合的地方。新技术和名人大牛的观点并不等于适用于实际情况。
3. 依赖Google没什么错
这种言论肯定会让那些学富五车的饱学之士恼火。但重要的是能真正理解，并给出成功的编程解决方案，让客户和老板满意。
4. 大多数注释是代码的糟糕重复
我们大部分时间是在维护其他人（或我们自己）所写的代码，而糟糕、错误、过时和误导性的注释也是代码中最令人纠结的因素之一。
5. XML被大大高估了
许多随波逐流的人没动过脑子就跳上了XML这条黑船。XML用于Web应用不错，因为它本来就是干这个的。此外的问题定义、设计思路应该尽量不用XML。
6. 程序员生而不平等
经理往往认为“程序员A=程序员B”，因为他们工作的年头差不多。但实际上，他们的效率可能相差十倍甚至百倍。
7. 将Java作为最适合大学教学的第一门语言令人费解
第一门编程语言应该重在学习控制流和变量，而不是对象和语法。此外没有调试C/C++内存泄漏经验的人，根本无法完全理解Java的初衷。
8. 若你只会一门语言，无论多么精通，仍然不够优秀
任何人如果只局限于一门语言，都无法充分发挥自己的潜力。而且缺乏求知欲和探索意愿，都不符合优秀程序员的特质。
9. 性能真的很重要
尽管可以通过购买更强劲的CPU、硬盘和内存提升性能，但若这样想的人少一些，我们也许能在1GHz的CPU上运行更多程序。
10. Print语句是有效的调试方式
用System.out.println之类的输出语句调试代码的方式挺好。这经常比正式的调试要快，而且可以比较不同运行的输出结果
篇三：101条经典计算机语录
1、计算机没什么用.他们只会告诉你答案.(巴勃罗毕加索,画家)
2、计算机就跟比基尼一样,省去了人们许多的胡思乱想.(萨姆尤因,作家)
3、他们拥有计算机,他们也还可能拥有其他的大规模杀伤性武器.(珍内特雷诺,美国前女司法部长)
4、跟计算机工作酷就酷在这里,它们不会生气,能记住所有东西,还有,它们不会喝光你的啤酒.(保罗利里,吉他手)
5、如果汽车能赶上计算机的发展周期的话,一辆今天的劳斯莱斯仅值100美元,每加仑要跑100万英里,每年还得爆炸一次,把里面的人杀个精光.(Robert X. Cringely,技术作家)
6、计算机总是越来越智能的.科学家告诉我们说不久它们就能跟我们对话了.(这里的它们,我指的是计算机.我怀疑科学家永远都不能跟我们对话.) (Dave Barry,幽默作家)
7、我最近注意到,在共同文化中,那种对计算机变得智能化并最终掌控世界的妄想恐惧症几乎彻底消失了.据我所知,这跟MS-DOS的发布基本是同步的.(Larry DeLuca)
8、计算机会不会思考这个问题就像问潜水艇会不会游泳一样.(Edsger W. Dijkstra,图灵奖获得者)
9、活了一百年却只能记住30M字节是荒谬的.你知道,这比一张压缩盘还要少.人类境况正在变得日趋退化.(Marvin Minsky,人工智能研究的奠基人) 信任
10、这座城市的中央计算机告诉你的?R2D2,你不该相信一台陌生的计算机!(C3PO,星球大战中的翻译机器人)
11、永远不要相信一台不能扔掉一扇窗户*的计算机(斯蒂夫沃兹尼亚克,苹果联合创始人)
12、硬件:计算机系统中可被踢的部分.(Jeff Pesis)
13、今天大部分的软件都很像上百万块砖堆叠在一起组成的埃及金字塔,缺乏结构完整性,只能靠强力和成千上万的奴隶完成.(阿伦凯,图灵奖获得者,面向对象创始人)
14、我终于明白'向上兼容性'是怎么回事了.这是指我们得保留所有原有错误.(Dennie van Tassel)
15、有两样重要产品出自伯克利:LSD和BSD*.我们不相信这是个巧合.(Jeremy S. Anderson)
16、2038年1月19日,凌晨3点14分07秒(UNIX中的世界末日*1970年1月1号之后的2^32秒)
17、每个操作系统都差不多 我们都一样的烂.(微软的高级副总裁布莱恩瓦伦蒂尼这样描述操作系统的安全状况,2003)
18、微软有出了个新版本,Windows XP,据大家说是'有史以来最稳定的Windows', 对我而言, 这就好像是在说芦笋是'有史以来发音最清脆的蔬菜一样' (Dave Barry)
19、互联网?那个东西还在吗?(Homer Simpson)
20、网络就像是个母夜叉.我每转到一处都会看见小个的按钮命令我提交*.(Nytwind)
21、想想看吧,已经有一百万只猴子坐在一百万台打字机旁,可Usenet就是比不上莎士比亚.(Blair Houghton)
22、计算机软件产业最为惊人的成就,是其持续不断地放弃硬件产业的惊人成果和稳定性.(Henry Petroski)
23、真正的创新经常来自于那些贴近市场、但无力拥有市场的的小型初创公司.(Timm Martin)
24、人们常说,伟大的科学学科就像是站在其它巨人肩膀上的巨人.人们也说过,软件产业正如站在其他侏儒脚上的侏儒.(Alan Cooper,交互设计之父)
25、这无关比特、字节和协议,而关乎利润和损益.(郭士纳,IBM前CEO)
26、我们是微软.反抗是徒劳的.你会被同化的.(保险杠贴纸)
27、不管演示在彩排的时候有多好,一旦在观众面前展示时,演示不出错的几率与观众人数成反比,与投入的金钱总额成正比.(Mark Gibbs)
28、专利大多数都是垃圾.浪费时间去阅读这些专利是愚蠢的.只有专利持有人才会这么干,还得强迫自己才会看.(Linus Torvalds,LINUX创始人)
29、控制复杂性是计算机编程的本质.(Brian Kernigan)
30、复杂性杀死一切.它把程序员的生活给搞砸了,它令产品难以规划、创建和测试,带来了安全挑战,并导致最终用户和管理员沮丧不已.(Ray Ozzie)
31、进行软件设计有两种方式.一种是让它尽量简单,让人看不出明显的不足.另一种是弄得尽量复杂,让人看不出明显的缺陷.(C.A.R. Hoare)
32、好的软件的作用是让复杂的东西看起来简单.(Grady Booch,UML创始人之一) 易用性
33、不管那些计算机书籍如何宣称,只需记住,你并非'傀儡'.真正的傀儡是那些无法设计出易于使用的硬件和软件的那些人,尽管他们是技术专家,因为这是普通消费者赖以生活的东西.(Walter Mossberg,科技专栏记者)
34、软件供应商在努力尝试让他们的软件更'易于操作' 迄今为止,他们最好的办法就是翻出所有的老手册,然后在封面盖上'易于操作'这几个字.(比尔盖茨)
35、有个老套的故事说有人希望他的计算机能像他的电话机一样好用.他的愿望实现了,因为我已经不知道该如何使用自己的电话了.(BjarneStroustrup,C++之父)
36、任何一个傻瓜都会用电脑.很多都会.(Ted Nelson)
37、只有两个行业把客户称为'用户'*.(Edward Tufte,信息设计大师)
38、程序员在跟宇宙赛跑,他们在努力开发出更大更好的傻瓜程序,而宇宙则努力培养出更大更好的白痴.到目前为止,宇宙领先.(Rich Cook)
39、你们当中很多人都知道程序员的美德.当然啦,有三种:那就是懒惰、急躁以及傲慢.(Larry Wall,Perl发明者)
40、程序员的问题是你无法预料他在做什么,直到为时已晚.(Seymour Cray,超级计算机之父)
41、那就是这些自认为痛恨计算机的人的真实面目.他们实际上真正痛恨的是糟糕的程序员.(拉瑞尼文,科幻作家)
42、很长时间以来我一直困惑不已,为什么一些又贵又先进的东西会一点用都没有.直到我突然想起,计算机不就是一台愚蠢之至却拥有难以置信的做聪明事能力 的机器嘛,而程序员不就是聪明绝顶却拥有难以置信的.干蠢事的能力的人嘛.一句话,他们简直就是天生绝配.(比尔布莱森,旅游文学作家)
43、不像学学涂涂画画也能让某人成为专家级画家,计算机科学教育不会让任何人成为一名编程大师.(埃里克雷蒙,开源运动领袖)
44、一个程序员是经历以下事情后仍能证明自己是严格的专家的人:他可以历经数不清的捶打,可取材于无关紧要的文档,用上面的争议数据作出模糊假设,并以 此计算出测微精度的无数片面理解的答案,并由一个不可靠、脑袋充满质疑、公
开宣称要让一个倒霉透顶、没有指望、毫无防备,要求第一时间获得信息的部门狼狈 不堪、令人生厌的人使用一台准确度有问题的仪器去实施.(IEEE网格新闻杂志)
45、运气好的黑客能用几个月的时间 - 生产出一个小规模的开发团体(比如说,7-8人)历尽艰辛一起工作了一年多才能做出来的东西.IBM经常报告说某些程序员的生产力要比其它工人高百倍,甚至更多.(Peter Seebach,黑客)
46、最好的程序员跟好的程序员相比可不止好那么一点点.这种好不是一个数量级的,取决于标准怎么定:概念创造性、速度、设计的独创性或者解决问题的能力.(兰德尔E斯特劳斯,科技作家)
47、伟大的车工值得给他几倍于普通车工的薪水,但一个伟大的软件代码作家,其价值则要等同于一个普通的软件写手的价格的1万倍.(比尔盖茨)
48、就算它工作不正常也别担心.如果一切正常,你早该失业了.(Mosher的软件工程定律)
49、靠代码行数来衡量开发进程就好比用重量来衡量飞机制造的进度.(比尔盖茨)
50、写代码的社会地位比盗墓的高,比管理的低.(杰拉尔德温伯格,软件与系统思想家)
51、首先学习计算机科学及理论.接着形成自己编程的风格.然后把这一切都忘掉,尽管改程序就是了.(George Carrette,杰出软件工程师,开源推广者)
52、先解决问题再写代码.(John Johnson)
53、乐观主义是编程行业的职业病;用户反馈则是治疗方法.(Kent Beck)
54、迭代者为人,递归者为神.(L. Peter Deutsch)
55、布尔值最好的一点是,就算你错了,也顶多错了一位而已.(无名氏)
56、数组的下标是从0开始好还是从1开始好呢?我的0.5的折衷方案,以我之见,没有经过适当考虑就被否决掉了.(Stan Kelly-Bootle)
57、只有两种编程语言:一种是天天挨骂的,另一种是没人用的.(BjarneStroustrup,C++之父)
发表评论