如何说服运维选择 Debian/Ubuntu 而不是 CentOS？
因为本题火药味太浓，所以新建了一个中立的问题：&a href=&/question/& class=&internal&&Debian、Ubuntu和CentOS哪一个发行版运维成本最低? - Linux&/a&&br&&br&====================&br& 更新&br&&br&我觉得这还是和看问题的角度和价值观有关系。更多的，我是希望站在技术团队整体的角度来看这个问题，而不是站在开发的角度看运维的问题。而且在职责上我认为我是有权过问的。&br&&br&价值观上的区别：很多人认为“稳定”最重要。而我认为“敏捷”最重要，而“敏捷”能带来稳定。运维也不是让你把服务器部署好没事闲在那，运维工作也是要持续改进的。&br&&br&但现在大家看问题的角度，甚至开发人员的角度都是：“运维工作我们要尊重运维的意见”。而我认为的逻辑是：“运维工作应该为技术团队提供敏捷灵活的基础设施服务以及相关技术支持”。我心里已经有答案了，用Docker。但是假设Docker不存在的情况下，我还是想继续讨论一下这个问题。&br&&br&我的确瞧不起那些“不懂装懂”的运维，但对于真正有能力的运维，我绝对是尊重的。顺便说一下我也很鄙视“只会使用一种编程语言”的程序员，尤其是java程序员。&br&&br&对于那些还在坚持说“开发不应该管运维的事，运维应该用自己熟悉的发行版”的人，我感觉你们的职业生涯快到头了。对于那些坚持说 CentOS、Redhat比Ubuntu好的人却不能说出理由，援引案例，只是一味的恐惧、担心，所以要待在自己的舒适区的人，我感觉真的是有问题的。&br&&br&对于那些说Linux都一样的人。好吧，看来我们对“都一样”的定义不同。&br&&br&问题不是我不能接受CentOS，而是各位运维大爷很鄙视Ubuntu。我们真的有尝试去接受CentOS，但是太他妈难用了，我们真没空在部署上花太多时间。&br&&br&还有人说，大公司的运维制度，开发与运维的分工。开发完全不用碰正式环境，东西丢给运维就行了。事实真的是这样吗？开发真的不能、不需要、不会去碰正式环境吗？有多少公司是在严格执行这种制度？这种制度在实际使用中行的通吗？效率高吗？有多少公司，运维实际上还是给了开发人员在正式环境的权限的？&br&&br&最后想说点事实，Ubuntu占领了越来越多的市场份额，也不乏大公司使用，难道大家都瞎了吗？&br&&br&====================&br&
更新&br&&br&我相信运维选择CentOS或许有一定的道理，但我也认为那些道理都比较牵强。从各位运维大牛的答案上来看，貌似主要还是因为他们会用CentOS，也没说出CentOS好处是啥。一副我们运维用啥你管不着的语气，虽然貌似有点道理，但总有一种很心虚的感觉。&br&&br&给了一个反对者赞，是因为他至少有条理的反驳了我的观点，而大部分的回答完全没有说出一点靠谱的理由的，就是在说你的理由不充分，所以我的理由就充分了。至于说可以在测试环境玩ubuntu的就谢谢了，不用你教。我们现在讨论的就是正式环境。&br&&br&====================&br&&br&本人开发，喜欢用ubuntu server，但我遇到的运维清一色的都要求用centos。问他们为什么，他们也说不出个所以然来，只是说ubuntu不好，问题很多，口气反正是挺吓人的。主要观点无非两点：&br&&br&1. 安全性。CentOS比Ubuntu安全。&br&2. 稳定性。Ubuntu更新太频繁，没有CentOS稳定。&br&&br&而我认为应该用Ubuntu的原因主要是：&br&1. 更新及时。有些基础工具CentOS要比Ubuntu落后好几个版本，对于喜欢尝试新技术的开发者来说，逐个手动安装依赖是个很痛苦的事。&br&2. 资料丰富。遇到什么问题，在网络上比较容易找到答案。&br&3. 社区支持。因为Ubuntu社区庞大，有些工具虽然没有在apt源收录，但是基本都会提供Ubuntu下的安装过程。&br&综上，我认为使用Ubuntu的运维成本更低。&br&&br&&br&补充：&br&&br&之前的标题表达不够准确，我主要指在新项目启动时的发行版选择，而不是对既有稳定运行的服务器的发行版选择。&br&&br&发现没几个认真回答的。我和运维沟通的时候也是这个状态，爱搭不理的，拽的很，完全没有团队意识，生怕别人触碰了他的领地。&br&&br&还有建议用权利手段进行胁迫的，也是够了。选择一个OS而已，不至于。我就想知道开发和运维有没有可能好好聊天？能不能真正的说出些靠谱的理由来，不要用职位来说事。我如果想把某个运维fire了也不是办不到，但是至于吗？我只是想以理服人。
因为本题火药味太浓，所以新建了一个中立的问题：==================== 更新我觉得这还是和看问题的角度和价值观有关系。更多的，我是希望站在技术团队整体的角度来看这个问题，而不是站在开发的角度看运维的问题。而且在职责上我认为我是有权过问的。价值观上的区别：很多人认为“稳定”最重要。而我认为“敏捷”最重要，而“敏捷”能带来稳定。运维也不是让你把服务器部署好没事闲在那，运维工作也是要持续改进的。但现在大家看问题的角度，甚至开发人员的角度都是：“运维工作我们要尊重运维的意见”。而我认为的逻辑是：“运维工作应该为技术团队提供敏捷灵活的基础设施服务以及相关技术支持”。我心里已经有答案了，用Docker。但是假设Docker不存在的情况下，我还是想继续讨论一下这个问题。我的确瞧不起那些“不懂装懂”的运维，但对于真正有能力的运维，我绝对是尊重的。顺便说一下我也很鄙视“只会使用一种编程语言”的程序员，尤其是java程序员。对于那些还在坚持说“开发不应该管运维的事，运维应该用自己熟悉的发行版”的人，我感觉你们的职业生涯快到头了。对于那些坚持说 CentOS、Redhat比Ubuntu好的人却不能说出理由，援引案例，只是一味的恐惧、担心，所以要待在自己的舒适区的人，我感觉真的是有问题的。…
的「切换发行版代价太大」。运维可不只是装软件，从机器采购、装机、预配置环境、录入 cmdb、监控、业务部署、回收或者专用其他，这整个生命周期已经全部自动化了，如果要切换一个发行版，需要全部适配一遍，这还不包括换发行版之后不兼容的东西，比如自己维护的内部软件仓库之类。那么，重新换一遍之后带来的收益是什么呢？ 稳定？灵活？如果换带来的收益不是远大于（换带来的成本+不换带来的损失），还是歇歇吧。我们就碰到过要求换线上发行版的，理由是现在用的不稳定，换一个稳定的、文档多的。我给的要求的拿出详细的稳定性报告，证明要用的的确比现在的稳定。才考虑换。闷头拍脑袋就要换，就好像运维找开发说，PHP 部署起来比 C、Python 什么的方便多了，以后不准你们用其他语言写业务，只准用 PHP，楼主你会同意么？没错，我们用的是 Ubuntu，开发们想换 CentOS，要我说，换 CentOS 不如换 Redhat，然后买服务。
作为一个苦逼运维，我们作为服务部门，如果开发大爷们真对os有特定要求，那是一定要满足的；但是前提是你的要求是合理的~题主说的几点，我随便代表你们运维回你几句：1.更新及时：生产环境首要是稳定，你要用最新版可以，说个用最新版的理由先，没有这个特性你代码就写不下去了？或者有了这个巨NB的新特性，我可以少造1000个轮子，开发效率提升100%？2. 资料丰富。都是linux，资料基本共通的，这个理由是个什么鬼？3. 社区支持。同2----------------------------------------------------为什么我要匿名呢，因为我要开始不友善的攻击楼主了lz你待的是小公司吧，你们公司生产环境和测试环境不分的么？测试环境你爱用Ubuntu就ubuntu，爱怎么折腾怎么折腾，运维都懒得管你；至于生产环境，你管得着么你？你是开发，你只要提需求，运维评审后，理由充分，有什么不给装的？至于生产环境用啥os，和你一个开发有个毛线关系？生产环境不是为了满足你追求新技术的地方！-----------------------------------------------------老实说，题主你描述的越多，显的你水平越low啊，因为你们公司的运维水平太low啊，一家公司的运维水平和开发水平明显正相关啊；运维的价值体现在装软件？“Ubuntu太简单了，如果大家都用Ubuntu，运维的价值无法凸显，运维就是要把系统弄的不那么方便才“安全””这句话我简直无力吐槽------------------------------------------------------明显 的答案比我说的更好更细致；-------------------------------------------------------补充几点：1.选os和选ide差不多，弄到最后就上信仰了要，完全没必要；我作为一个运维，用过centos,suse,debian,同代次的发行版的差异明显没有造成工作量上的巨大差异，倒是发行版的大版本升级，反而会带来业务改造的工作量2.开发和运维明显是合作关系，大家平时相互体谅下，都是为了工作；另外在某些开发鄙视运维什么都不懂的时候，运维也许也在私下里传“那个XXX，平时叼的很，指手画脚，结果代码上线，三天两头core，天天到我这里没上线前要我们装这装那，结果测试和我说tps简直感人”尊重他人也是尊重自己3.作为运维，装软件真的只是日常工作中很小的一部分；难道作为开发，装软件占据了你大量的工作量？大家都有太多的事，何必在这种普通运维和开发都没有决策权的事上，非要挣个一二三？
用docker，你用ubuntu做开发，他用centos跑container，就可以了。
而我认为应该用Ubuntu的原因主要是：1. 更新及时。有些基础工具CentOS要比Ubuntu落后好几个版本，对于喜欢尝试新技术的开发者来说，逐个手动安装依赖是个很痛苦的事。2. 资料丰富。遇到什么问题，在网络上比较容易找到答案。3. 社区支持。因为Ubuntu社区庞大，有些工具虽然没有在apt源收录，但是基本都会提供Ubuntu下的安装过程。综上，我认为使用Ubuntu的运维成本更低。第一点只是说明了对开发者的好处, 并不能得出"使用ubuntu的运维成本更低"的结论.第二点, 先不提究竟哪个发行版资料丰富, 这两个不是都是linux么, 具体的linux相关的资料都是一样的啊, 当然如果先用了ubuntu, 并且也按照ubuntu特定的东西去找的花, 肯定是这个的资料多了啊, 另, 试试找英文资料....., 最后, centos对运维来说已经有很完善的资料了, 所以这一点得不出"使用ubuntu的运维成本更低"第三点, 有哪个特定常用的东西没有fedora/centos的支持么? 非要举出特例的话自然另当别论了, 不过笼统的讲, 也得不出"使用ubuntu的运维成本更低"的结论吧事实上, 楼主忽略了最重要的问题了感觉, 对于一个生产系统来讲, 最主要追求的并不是"成本", 而是"稳定"尤其是楼主提出的第一个原因, 恰恰是稳定的大忌的这也是为什么Redhat要在RHEL之外, 另外资助搞一个Fedora的原因, 就是为了让一些新的技术/软件, 先进入到Fedora的社区中, 等这些新的软件经过了社区的检验, 迭代之后, 确保了稳定性之后才会进入到RHEL中的因为老版本的软件虽然没有一些新的特性, 没有特别fancy的效果, 但是, 毕竟经过了多年的实践检验, 是切实可用的.并且, 除了Fedora的试验场之外, Redhat还有大量的QA员工来做对每一个RHEL的发布做大量的测试(最终都会进入到CentOS), 还有一个硬件兼容性的团队来专门保证每个RHEL的硬件兼容性, 这些都是RHEL/CentOS作为一个生产系统的操作系统所必须的, 所有的这一切, 都是为了追求生产系统的稳定可靠.Redhat内部是把团队分成Project 和Product两部分的project的team就专门工作在开源社区, 自己搞自己的product team则会基于某个project的release再进行测试(功能测试, 性能测试, 兼容性测试等), backport fix,文档等工作, 最后作为产品提供给付费客户举个例子, Hibernate 社区版发布了4.0, 但是产品化的hibernate并不会跟进的, 还会停留在3.5等4.0的社区版经过了一段时间的用户反馈(这个的反馈是很高效的, 因为社区中用的人很多, 社区的JIRA基本上每天都会有很多JIRA被open, 包括bug, 不兼容等等问题), 然后发布4.0.1, 再反馈, 再发布4.0.2, 再反馈, 再发布4.0.3这时候, 经过了几次的社区反馈加bug fix release的迭代之后, 基本上4.0这个大版本的问题就会都被发现了, 然后, product team就开始介入了, 他们还会有专门的QA再做更详尽的测试, 然后按照不同的需求, 看是可以只做bug fix backport 还是需要把某些用户需要的new feature也port到老的3.5上, 然后发布一个3.5.1 的产品可以看到, 一个产品的艰辛诞生历程.....所以, 如果你们有足够的人力和资源来对新的版本的软件来进行足够的测试, 并且再发现问题的时候有能力能自己fix(假设都是使用的开源软件), 那么追求新版本没有问题(但是就不要说节省成本了, 这些是需要消耗大量成本的), 如果没有这个能力, 还是老老实实使用别人的成果吧注: 前Redhat员工
运维的流程是需要积累的，切换发行版代价太大。我们公司倒是从一开始就是用 ubuntu 了。
1. Java/Python之类带vm的语言不关心OS.2. 如果你写C/C++的话, 你应当学会静态链接一切依赖. 实在无法静态链接的, 也要把so一起打包并修改LD_LIBRARY_PATH.3. 理论上, 你根本就没有登录线上服务器操作的权限.你看, 一个合格的rd根本就没必要care OP用什么OS.另一方面, OP为了部署/监控等, 肯定都是积累了一堆脚本的. 你上来就让别人换OS, 那你要不要帮别人测试脚本兼容性啊?
也许互联网初创公司的稳定观和我的不一样，宕机重启一下就好了，所以才会这么认为我认为“敏捷”最重要，而“敏捷”能带来稳定。像我这样去年要花几个月在定位底层bug的开发人员表示，碰到最头疼的就是kernel底层bug，特别是软硬件适配的问题，要和硬件人员合作解决。这类问题敏捷一点用也没有，要么你有一票高手，什么都能cover住，要么你买RHEL，它至少保证在redhat认证硬件上在绝大部分应用场景是不会出问题的，出了问题也有redhat的人帮你看，几年来redhat在社区的代码贡献率不是第一就是第二，还是可以信任的。所以也可以理解很多人选centos，kernel一样嘛虽然没有服务。当然我也理解，题主所在公司可能根本不关心无缘无故宕机挂死之类的故障，只要业务能快速修改上线就好了。这时题主要做的就是向运维保证，改完后的宕机问题都由我来解决，老板的怒火我来承担。只有这个作为前提，运维才可能答应。
公司每个人都要各司其职，开发的不要过问运维的实现。你提你的合理需求，就好像架构师说他的架构，他也没有管你具体tab是2个空格还是4个空格吧？开发要管运维的东西，除非是开发也要干运维的活，否则对别人的工作方式加以评价就是不尊重。评价的应该是结果而非过程。在我看来，只要运维能解决开发提的需求，哪怕他用Android我觉得也不应该过问。
首先我认为理想的生产环境是Gentoo，然而这并不是随便一个人就能玩得起来的。那么退而求其次，至少，公司里要保证生产服务器、测试服务器和开发机运行环境的统一（用Debian、RHEL、Ubuntu、CentOS、Fedora等等都可以，只要保证运行环境统一），因为混乱的运行环境大大提高了找Bug的时间成本，同时混乱的运行环境增加了出现Bug的风险。然后我想批评一下题主的一些看法。我认为使用Ubuntu的运维成本更低。不知道你讲的是哪方面的成本：时间、金钱还是人力？话你没有讲清楚，我觉得题主对运维这件事也不怎么了解。具体情况我不想展开说，我就举个例子：我认为Windows Server的运维成本更低，线上服务真要是出了什么大事，还可以找来MS的售后做技术支持——你看，自己很省事吧——正版Windows Server不便宜哦。所以，既然是开发，就不要对开发之外的领域不做了解就指手画脚。而且在职责上我认为我是有权过问的。这又是什么意思呢，题主是技术总监还是CTO？那就是说一名不怎么懂运维的开发，就去做了技术团队的老大？您这不是笑话么？很多人认为“稳定”最重要。而我认为“敏捷”最重要，而“敏捷”能带来稳定。这话说的...... 现在真是什么人都敢把“敏捷”挂在嘴边了。研发团队用“敏捷”，那是为了迎合业务的需要。不是说敏捷能带来稳定，而是不论用什么样的方法，稳定运行都是技术部门追求的最基本目标，是及格线。稳定运行 -& 业务保障 -& 业务迭代 -& 敏捷开发 -& 稳定运行 ......没有这个觉悟的话，还是要多做几年开发才行。顺便说一下我也很鄙视“只会使用一种编程语言”的程序员，尤其是java程序员。这年头也是谁都敢来随手黑一发。一方面，只会用Java的程序员不外乎两种——二本三本院校毕业生，培训机构毕业生——职场新人嘛。职场老人要多关心多爱护，该指导的要指导，该骂的也要骂，这也算是职业操守吧。结果就有人这么一通鄙视，满级大号和新手号比装备，秀优越？另一方面，科技以人为本。Java不仅解决了技术上的问题，还顺便解决了教育和就业上的问题，为行业发展做了多大贡献，然后就被题主这样的人黑来黑去的。最后，但是假设Docker不存在的情况下，我还是想继续讨论一下这个问题。讨论嘛，讨论一下而已。
已有帐号？
无法登录？
社交帐号登录有用过fedora和centos的吗_百度知道
有用过fedora和centos的吗
edora 是一个知名的Linux发行版。Fedora 是一个独立的操作系统。它由一个强大的社群开发、开放源码的软件和开放的标准，可运行的体系结构包括 x86（即i386-i686）、强大的操作系统。它允许任何人自由地使用、稳定. 的支持，无论现在还是将来, Inc，得到了 Red Hat，这个社群的成员以自己的不懈努力。Fedora 项目由 Fedora 基金会管理和控制，提供并维护自由, x86_64 和 PowerPC，是一款由全球社区爱好者构建的面向日常应用的快速、修改和重发布
为您推荐：
其他2条回答
有的，体验相当不错
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁在 CentOS 7.x / Fedora 21 上面体验 PHP 7.0_服务器应用_Linux公社-Linux系统门户网站
你好，游客
在 CentOS 7.x / Fedora 21 上面体验 PHP 7.0
来源：Linux中国&
作者：Linux
PHP是一种为我们熟知的通用服务器网页脚本语言。非常多的在线网站都是用PHP编写的。PHP这些年来一直在持续进化，丰富其功能，变得易于使用，更好地组织的脚本语言。目前PHP的开发团队正筹备下一个PHP版本的发行，名字是PHP 7。现在的PHP版本为PHP 5.6，可能你清楚PHP 6已经流产了，PHP 7的支持者们不希望下一个重要的版本被其他分支混淆，即过去已经停止很久的PHP 6。所以决定下一个PHP主要的发行版本叫PHP 7，而不是PHP 6。PHP 7.0预计在今年十一月份发行。
在下一代主要PHP版本里有一些不错的功能：
为了改善执行效率与内存占用，新的版本添加了PHPNG功能。
引入了JIT引擎来动态编译Zend操作码为自然机器码，以此来达到更快的处理性能。这项功能允许随后的程序调用同一份代码，这样会运行快很多。
AST（抽象语法树）是最新添加的功能，它可以增强支持PHP的扩展性和用户应用。
添加异步编程功能以支持同一个请求中的并行任务。
新的版本会支持独立的多线程网页服务器，这样可以使用一个单独的存储池处理很多并发的请求。
在/上安装PHP 7
让我们来看看怎样在CentOS 7和Fedora 21安装PHP7。为了安装PHP7，我们首先需要克隆php-src 仓库。当克隆工作完成，我们再配置和编译它。进行下一步之前，我们要确保已经在LInux系统下安装了如下的组件，否则PHP编译会返回错误中止。
所有上面提到的要求可以使用Yum软件包管理器安装。以下一条命令即可完成：
yum install git autoconf gcc bison
准备好开始安装PHP7了吗？让我们先创建一个PHP7目录，作为你的当前工作目录。
mkdir php7
现在克隆php-src仓库，在终端里运行下面的命令。
git clone https://git.php.net/repository/php-src.git
工作应该会在几分钟后完成，这里是一个样例输出，你应该会在任务完成时看见。
[root@localhost php7]# git clone https://git.php.net/repository/php-src.git
Cloninginto'php-src'...
remote:Counting objects:615064,done.
remote:Compressing objects:100%(127800/127800),done.
remote:Total615064(delta 492063), reused 608718(delta 485944)
Receiving objects:100%(615064/615064),152.32MiB|16.97MiB/s,done.
Resolving deltas:100%(492063/492063),done.
让我们来配置，编译PHP7，在终端运行下面的命令，开始配置工作：
cd php-src
./buildconf
下面是./buildconf命令的样例输出。
[root@localhost php-src]#./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.69(ok)
rebuilding aclocal.m4
rebuilding configure
rebuilding main/php_config.h.in
使用下面的命令，继续配置进程：
./configure \
--prefix=$HOME/php7/usr \
--with-config-file-path=$HOME/php7/usr/etc \
--enable-mbstring \
--enable-zip \
--enable-bcmath \
--enable-pcntl \
--enable-ftp \
--enable-exif \
--enable-calendar \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--with-curl \
--with-mcrypt \
--with-iconv \
--with-gmp \
--with-pspell \
--with-gd \
--with-jpeg-dir=/usr \
--with-png-dir=/usr \
--with-zlib-dir=/usr \
--with-xpm-dir=/usr \
--with-freetype-dir=/usr \
--with-t1lib=/usr \
--enable-gd-native-ttf \
--enable-gd-jis-conv \
--with-openssl \
--with-mysql=/usr \
--with-pdo-mysql=/usr \
--with-gettext=/usr \
--with-zlib=/usr \
--with-bz2=/usr \
--with-recode=/usr \
--with-mysqli=/usr/bin/mysql_config
这会花去不少的时间，当完成后你应该会看到如下面的输出：
creating libtool
appending configuration tag "CXX" to libtool
Generating files
configure: creating ./config.status
creating main/internal_functions.c
creating main/internal_functions_cli.c
+--------------------------------------------------------------------+
|License:|
|This software is subject to the PHP License, available inthis|
| distribution in the file LICENSE.By continuing this installation |
| process, you are bound by the terms of this license agreement.|
|If you donot agree with the terms of this license, you must abort |
| the installation process at this point.|
+--------------------------------------------------------------------+
Thank you forusing PHP.
config.status: creating php7.spec
config.status: creating main/build-defs.h
config.status: creating scripts/phpize
config.status: creating scripts/man1/phpize.1
config.status: creating scripts/php-config
config.status: creating scripts/man1/php-config.1
config.status: creating sapi/cli/php.1
config.status: creating sapi/cgi/php-cgi.1
config.status: creating ext/phar/phar.1
config.status: creating ext/phar/phar.phar.1
config.status: creating main/php_config.h
config.status: executing default commands
运行下面的命令，完成编译过程。
&make&命令的样例输出如下所示：
Generating phar.php
Generating phar.phar
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
clicommand.inc
directorytreeiterator.inc
directorygraphiterator.inc
pharcommand.inc
invertedregexiterator.inc
Build complete.
Don't forget to run 'make test'.
活儿干完了，该安装PHP7了，运行下面的命令安装它。
make install
成功安装的进程的样例输出应该像这样：
[root@localhost php-src]# make install
Installing shared extensions:/root/php7/usr/lib/php/extensions/no-debug-non-zts-/
Installing PHP CLI binary:/root/php7/usr/bin/
Installing PHP CLI man page:/root/php7/usr/php/man/man1/
Installing PHP CGI binary:/root/php7/usr/bin/
Installing PHP CGI man page:/root/php7/usr/php/man/man1/
Installing build environment:/root/php7/usr/lib/php/build/
Installing header files:/root/php7/usr/include/php/
Installing helper programs:/root/php7/usr/bin/
program: phpize
program: php-config
Installing man pages:/root/php7/usr/php/man/man1/
page: phpize.1
page: php-config.1
Installing PEAR environment:/root/php7/usr/lib/php/
[PEAR]Archive_Tar- installed:1.3.13
[PEAR]Console_Getopt- installed:1.3.1
[PEAR]Structures_Graph- installed:1.0.4
[PEAR] XML_Util - installed:1.2.3
[PEAR] PEAR - installed:1.9.5
Wrote PEAR system config file at:/root/php7/usr/etc/pear.conf
You may want to add:/root/php7/usr/lib/php to your php.ini include_path
/root/php7/php-src/build/shtool install -c ext/phar/phar.phar /root/php7/usr/bin
ln -s -f /root/php7/usr/bin/phar.phar /root/php7/usr/bin/phar
Installing PDO headers:/root/php7/usr/include/php/ext/pdo/
恭喜你，PHP7已经安装在你的Linux系统上了。安装完后，进入PHP7安装文件里的sapi/cli里面。
cd sapi/cli
验证一下PHP的版本。
[root@localhost cli]#./php -v
PHP 7.0.0-dev (cli)(built:Mar28201500:54:11)
Copyright(c)1997-2015The PHP Group
ZendEngine v3.0.0-dev,Copyright(c)1998-2015ZendTechnologies
PHP 7也，这个即将到来的版本主要关注执行效率的提升，它的新特性致力于使PHP较好满足现代编程的需求和趋势。PHP 7.0将会有许多新的特性、丢弃一些老版本的东西。在接下来的日子里，我们希望看到新特性和弃用功能的具体情况。希望你喜欢！
CentOS 6.3 安装LNMP (PHP 5.4,MyySQL5.6)
在部署LNMP的时候遇到Nginx启动失败的2个问题
安装Nginx php5-fpm MySQL(LNMP环境搭建)
《细说PHP》高清扫描PDF+光盘源码+全套教学视频
CentOS 6中配置PHP的LNMP的开发环境&
PHP 的详细介绍：PHP 的下载地址：
更多Fedora相关信息见 专题页面
更多CentOS相关信息见 专题页面
作者： 译者： 校对：
原创翻译， 荣誉推出
本文永久更新链接地址：
相关资讯 & & &
& (12/05/:04)
& (09/13/:27)
& (08/07/:59)
& (11/13/:10)
& (08/19/:24)
& (08/06/:28)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款}