2016年6月

2016 年 6 月 21 日,Fedora 项目组宣布 Fedora 24 Linux 操作系统正式发布!支持桌面、服务器、云端和嵌入式设备。

在延期了四次之后,Fedora 24 正式版终于发布了,现在就可以下载啦!包括几个不同的分支:Fedora 工作站、Fedora 服务器和 Fedora 云端,以及官方 Fedora 变体(即 Fedora Spins)——支持 Xfce、LXDE、KDE、MATE/Compiz、Cinnamon、Sugar 等桌面。

当然,用户也可以在 Fedora 24 实验室找到更多变体,包括设计套件、游戏、机器人套件、科学、安全实验室等。不过,在这些所有的版本之下,都用的同样的核心部件,即 Linux 内核 4.5.7 和 GNU C 库 2.23。

你可能已经注意到了这个 Linux 4.5.7 内核是 Linux 4.5 内核系列的最后一个版本,而 Fedora 开发者已经承诺他们将会在未来几周将该发行版升级到 Linux 4.6 系列,在这个版本发布前已经没有时间重新测试 Linux 4.6 内核了。

GNOME 3.20、KDE Plasma 5.6、Mono 4.2、GCC 6 等等

Fedora 24 工作站版本中加载了 GNOME 3.20.2 桌面环境,Fedora 24 KDE Plasma Spin 带的则是 KDE Plasma 5.6 桌面。Fedora 24 的所有分支都是用 GCC 6 编译器构建的。

在 Fedora 24 中使用 网络管理器 NetworkManager 1.2 来管理网络连接,此外还包括了 Mono 4.2、Boost 1.60、Node.js 5.10、Python 3.5、Ruby 2.3、Golang 1.6 等等。

下载地址

更多下载类型,请访问: https://getfedora.org/

今日关注

期待很久的 Solus 1.2 "Shannon" 正式发布。从最终用户的角度来看,最先注意到的的可能是这次搭载了优雅简洁的 Budgie 桌面环境的最新版本。另外,这一版本对许多的软件都进行了优化,比如更好的游戏体验。Solus 1.2 是第一个使用了 Arc 图标主题的操作系统。旧版本用户可以通过包管理器进行更新。

新闻摘要

基于 Linux 面向 NAS 解决方案的 Rockstor 3.8-14 操作系统发布。这一版本新增了给硬盘断电的接口来节能降噪,同时提供了浏览查看日志的方法,修复了30多个 bug,并且为付费用户提升了更好的用户体验。目前已经可以下载体验了。

qBittorrent 3.3.5 发布。这一版本增加了许多新特性,比如种子管理模式,管理 cookie 的全新的对话框,以及对特殊临时目录的支持。另一个期待已久的新特性就是当添加了种子之后的提醒展示。在这一版本之后,可以通过点击鼠标右键选项来对标签进行排序了。另外,用户可以通过 qBittorrent 3.3.5 运行 shell 脚本了。

Zenwalk 8.0 发布在即,最后一个候选版本发布进入测试阶段。这一版本支持 Linux 4.4.13 内核,使用了最新的各种软件发行版本,比如 LibreOffice 5.1.3 办公套件、Chromium 51.0 等。值得注意的是,这一版本提供了 Xfce 4.12 最新的桌面布局,使用了 PolicyKit 体系结构,用户可以不用获取 root 权限就能够执行许多管理员操作,比如修改用户密码、语言环境等。目前也已经可以下载体验了。

Peppermint 7 预计6.30号发布。Peppermint 是基于 Ubuntu 的 GNU/Linux 发行版。现有稳定版本是 Peppermint 6 ,基于 Ubuntu 14.04.2 LTS。这是一款轻量级、设计良好、快速、稳定的计算机操作系统。敬请期待。

即将到来的 Linux 4.7 内核的第四个候选版本发布。已经可以从官网下载体验了。

NetOS 8.0.2 发布。在这一版本中,VLC 媒体播放器替代了原有的 Parole,完善了对 Docker 1.11 Linux 容器引擎和 UEFI 的支持。不过这只是8.0系列的第二个更新版本,并没有非常多的新特性。

编者按:这个消息是几个月前曝出的,也许我们该对基础软件的安全问题更加重视。

谷歌披露的一个严重漏洞影响到了主流的 Linux 发行版。glibc 的漏洞可能导致远程代码执行。

几个月前,Linux 用户都在竞相给一个可以使系统暴露在远程代码执行风险中的核心 glibc 开放源码库的严重漏洞打补丁。这个 glibc 的漏洞编号被确定为 CVE-2015-7547,题为“getaddrinfo 基于堆栈的缓冲区溢出”。

glibc,或 GNU C 库,是一个开放源码的 C 和 C++ 编程语言库的实现,是每一个主流 Linux 发行版的一部分。谷歌工程师们在他们试图连接到某个主机系统时发生了一个段错误导致连接崩溃,偶然发现了 CVE-2015-7547 问题。进一步的研究表明, glibc 有缺陷而且该崩溃可能实现任意远程代码执行的条件。

谷歌在一篇博客文章中写道, “当 getaddrinfo() 库函数被使用时,glibc 的 DNS 客户端解析器易受基于堆栈缓冲区溢出的攻击,使用该功能的软件可能通过攻击者控制的域名、攻击者控制的 DNS [域名系统] 服务器,或通过中间人攻击方式(MITM)进行破坏。”

其实利用 CVE-2015-7547 问题并不简单,但它是可能的。为了证明这个问题能被利用,谷歌发布了论证一个终端用户或系统是否易受攻击的概念验证(POC)代码到 GitHub 上。

GitHub 上的 POC 网页说“服务器代码会触发漏洞,因此会使客户端代码崩溃”。

Duo Security 公司的高级安全研究员 Mark Loveless 解释说 CVE-2015-7547 的主要风险在于依赖于 DNS 响应的基于 Linux 客户端的应用程序。

Loveless 告诉 eWEEK “需要一些特定的条件,所以不是每个应用程序都会受到影响,但似乎一些命令行工具,包括流行的 SSH[安全 Shell] 客户端都可能触发该漏洞,我们认为这是严重的,主要是因为对 Linux 系统存在的风险,但也因为潜在的其他问题。”

其他问题可能包括一种通过电子邮件触发调用易受攻击的 glibc 库 getaddrinfo() 攻击的风险。另外值得注意的是,该漏洞被发现之前已存在于代码之中多年。

谷歌的工程师不是第一或唯一发现这个 glibc 安全风险的团体。这个问题于 2015 年 7 月 13 日首先被报告给了 glibc 的 bug跟踪系统。该缺陷的根源可以更进一步追溯到在 2008 五月发布的 glibc 2.9 的代码提交时首次引入缺陷。

Linux 厂商红帽也独立找到了 glibc 中的这个 bug,而且是在 2016 年 1 月 6 日,谷歌和红帽开发人员证实,他们作为最初与上游 glibc 的维护者私下讨论的部分人员,已经独立在为同一个漏洞工作。

红帽产品安全首席软件工程师 Florian Weimer 告诉 eWEEK “一旦确认了两个团队都在为同一个漏洞工作,我们会合作进行可能的修复,缓解措施和回归测试,我们还会共同努力,使测试覆盖尽可能广,捕捉代码中的任何相关问题,以帮助避免今后更多问题。”

由于缺陷不明显或不易立即显现,我们花了几年时间才发现 glibc 代码有一个安全问题。

Weimer 说“要诊断一个网络组件的漏洞,如 DNS 解析器,当遇到问题时通常要看抓到的数据包的踪迹,在这种情况下这样的抓包不适用,所以需要一些实验来重现触发这个 bug 的确切场景。”

Weimer 补充说,一旦可以抓取数据包,就会投入大量精力到验证修复程序中,最终完成回归测试套件一系列的改进,有助于上游 glibc 项目。

在许多情况下,安全增强式 Linux (SELinux) 的强制访问安全控制可以减少潜在漏洞风险,但是这个 glibc 的新问题例外。

Weimer 说“由于攻击者提供的任意代码的执行,会对很多重要系统功能带来风险。一个合适的 SELinux 策略可以遏制一些攻击者可能会做的损害,并限制他们访问系统,但是 DNS 被许多应用程序和系统组件使用,所以 SELinux 策略只提供了针对此问题有限的遏制。”

在揭露漏洞的今天,现在有一个可用的补丁来减少 CVE-2015-7547 的潜在风险。


via: http://www.eweek.com/security/linux-systems-patched-for-critical-glibc-flaw.html

作者:Michael Kerner 译者:robot527 校对:wxy

本文由 LCTT 原创翻译,Linux 中国 荣誉推出

阿里云云栖大会6月15号在厦门盛大召开,我们有幸和阿里云资深总监李津面对面进行了交流,就阿里云在云计算方面的一些发展和战略进行了较为深入的讨论。

这次谈话是在李津(以下简称李)、Linux中国的创始人王兴宇(以下简称王)之间展开的。通过这次讨论让我们对阿里云有了更新的认识。

话题是先从 HTTPS 云加速引开的

王:在之前已有消息说阿里云在开发 HTTPS 云加速的服务,而业界,包括国内已经有云加速服务商提供了 HTTPS 云加速服务。不知道阿里云这方面的进展如何?

李:阿里云的 HTTPS 的云加速其实从技术上已经完成了,目前还在调测一些用户体验的部分,技术上并不是障碍,关键是易用性。HTTPS 云加速事实上是基于 CDN 做的,但是这里还有一些需要完善的部分,CDN 本身是一种管道,解决了从 CDN 到用户的加密传输,但是还需要解决从源站到 CDN 节点间的传输。如果用户本身没有支持 HTTPS ,那么还需要考虑从源站到 CDN 节点之间的传输问题,而部署 HTTPS 对于不少客户来说还是比较复杂的,很多用户希望有一键部署的体验。

此外,对于已经部署 HTTPS 的用户,他们还是愿意将其私钥放在自己控制的服务器上,而不是放到阿里云的 CDN 节点上,对于这种情况下,有两种方式:一种是采用伪密钥的方式,即由 CDN 提供证书给客户,另外一种是客户将自己的 SSL 证书上传,这可以是上传到一个信任的第三方的黑盒中。

窦:说到证书服务,阿里是否有计划建立自己的 CA 或者购买一家 CA 服务商?

李:CA 服务商最重要的不是颁发证书,而是要对所颁发证书的可信性进行背书。颁发了证书就要确保该证书所保护的信息具备起码的安全水准,有些 CA 服务商这方面做的还不够。不仅仅是用户购买就颁发证书,而且要对客户进行检查和判断,判断是否达成安全可信标准。CA 服务商不是一个生意,更多的是一种保障的能力。

王:如果阿里云提供 CA 服务,是否会采用类似 Let’s Crypt 这种免费模式?

李:如果不叠加更多安全服务,是可以采用免费摸,但是如果叠加了比如扫描检查等增值服务,就需要商业收费模式。这些年来,对于安全方面的承诺,需要越来越慎重, CA 证书代表的是信任所传递的责任。

云计算的新形势下,基础运维的变化

窦:云计算让运维行业迎来了第二春,对运维人员的界定也在发生变化。那么您认为将来运维行业会发生什么变化?

李:首先,云计算是从运维上发展起来的一个方向,而不是一个自顶向下的变化。其次,随着 DevOps 的流行,开发和运维在某种程度上是融合的,今天的运维人员已经有能力和空间去做一些更应该去做的事情了,而不仅仅是守在机房整理机架。运维是什么?按照 Google SRE 的说法,就是站点的可持续性的保障。

窦:随着云计算的发展,传统的互联网公司的基础运维部分会越来越少,这部分过渡到了云计算平台服务商了。

李:从使用者的角度看,基础运维会越来越少,而业务运维会越来越多。云计算平台不会提供所有服务,但是会尽量提供各种原子性的服务。比如说,在我看来,MySQL、Cache 现在就是一个原子性的服务,而不像过去,是一个解决方案。现在的业务运维就是快速地用原子化的部件搭建自己的业务系统,支撑业务运维,就像乐高积木一样搭建。今天很多云服务商都喜欢用乐高积木来比喻其服务,其实就是指这些服务会形成标准件,用户可以用这些标准件来搭建自己的业务系统。

当然这种标准件会让客户丧失部分的自主权,比如说某种原子化部件不存在怎么办?有两种方式,如果确实是一种原子性的产品,那么云计算服务商一定会提供的;如果是当下急需或个性的需求,那就可以客户自己做。非常有意思的是,每个大的云计算服务商背后都会有一个云市场,你自己做出自己的原子化部件,也可以将它放到云市场上去。

窦:在这个方面我发现一个问题,比如说他们已经做出来了这个原子件,但是有一天云计算厂商发现这个东西不错,我也要做这个,那你怎么平衡这个关系?

李:这个事情从某种程度上讲一定会发生。为什么呢?原子化的就是抽象化的,如果云技术服务商发现它已经成为大多数人所需要的一个东西,就会向下抽象,让它成为服务平台的一部分。那么对于上层厂商来说该如何发展呢?他们应该向上走,将这个东西做的更细分、更好。这就是一种倒逼机制,就像是假如你要做一个杯子,而你的杯子的生产成本已经远远高于通用化制造的杯子,那你肯定会被淘汰。但是如果你把这个杯子变成陶瓷的、变成有收藏价值的,那就可以做了,不会被通用化制造的杯子挤压到没有市场。

举例说, AWS 上有两家存储服务商,DropBox 和 Box,那这两家公司有生存空间么?其实他们都是做数据文件的共享,而文件共享其实是 AWS 的基础服务。这两家做的是数据增值服务,如果这种增值服务对所有人来说都是标准服务需求的时候,它就会被 AWS 所提供,那么这两家厂商就不停的被底层的厂商倒逼着不停地提供更多的增值服务。但是它们越做新的增值服务,就和用户越贴近,挖掘到的需求对用户的帮助就越大。这个时候产业是良性的。但是如果厂商固守在数据存储上,那这个“游戏”就结束了。

我们再换个例子说,比如手机里面,之前任何一个智能手机里面都有一个“日历”应用的厂商,但今天还有日历厂商么?很少了,因为这种需求已经是一个通用的需求了。但是“万年历”还存在,这是因为“万年历”这个数据是独特的,也不是通用的需求。但是普通的日历、农历是通用的需求,所以就被底层厂商“吃”掉了;同样,“手电筒”应用也是,它成为了手机自身的功能。

安全服务的边界

王:刚才我们提到了安全问题,我们知道阿里云给客户提供了很多安全服务。做安全实际上存在一个矛盾,在效率和安全之间是存在一定的抵触的。据我所知,阿里云至少在两个层面上为客户提供了安全服务,一个是在云的层面上提供了云防火墙;另外一个是在主机层面提供主机安全防护。这里我想知道,阿里云在安全方面的策略是如何的?因为如果安全方面厂商做的太多,会影响到客户的使用,但是如果有些服务不做的话,一些安全问题就会导致客户应用的问题,甚至会造成安全事故的蔓延。

李:安全的最大问题是:安全的边界。如果这个边界说不清,就会出现你说的这个问题,多做、少做都不对。第二个问题是,安全边界是个大家认知的问题,道德和法律的差异,法律是本分、道德是情分,这是有差别的。在安全方面,阿里云做了三个层面:业务安全、主机安全和平台安全。业务安全是防止客户被入侵,保障客户应用的安全,是从外向里看;而主机安全是从主机向外看。还有一个层面是平台本身的安全。

安全一定是要划清边界的,因为不可能包揽百分百,这就一定要和用户说清楚那些部分是不能包揽的。安全里面 30% 是技术的问题,70% 是人的问题,但今天有没有什么办法让人的部分降低到那怕是 50%?让使用更便捷一点?但是这里有个问题是,当你管的多了时候,客户怎么确认你管的这么多是合适的?

窦:很多人对安全的保姆模式还处于一个认可的过程,对保姆模式的信任也没有建立起来。

李:首先是你说的客户不一定相信,不是你说了客户就会相信,这是一个很正常的事情。那只能是在一开始的时候就尽量将事情说清楚。其次是,能以授权的方式存在的就一定要以授权的模式做,让客户随时可控。

当时“安骑士”这个事件之后,在我们内部反思过这个问题。在我看来,第一个,授权做的不清晰;第二个,给用户做的可上可下的提示不明确。如果它是可上可下的、授权清晰的,那就是个用户自我选择的问题。然后是,“安骑士”你到底都做了什么?这个你得给客户提供审计报告出来。

不只是“安骑士”,包括阿里云做的所有东西,都应该提供专业的审计报告。比如说一台主机,服务商进行了维护调整,环境上有了变化,它可能都会对用户发生影响。这个时候,作为用户,我都看不到就没有安全感。那么这个时候应该以一种什么样的方式将这个报告提供出来?所以,我们今天就将各种服务,比如 RDS 的维护日志、用户自己的操作日志都让用户能看到。而且如果用户使用了多种服务,如何将多个报告融合在一起,这也需要我们大量的工作。

企业的开源发展的四个阶段

王:阿里云做了许多产品,也开源了许多产品,阿里云在开源方面的战略是如何的?

李:阿里云做了很多中间件,最流行的是 dubbo。为什么它会很快的流行呢?首先它是一个简单的应用,其次是它被阿里淬炼过,保证了其稳定性。我最近在管理开源社区方面的事务,发现它的社区非常大,使用文档、案例、手册等庞大无比,我非常惊讶,远远超过我的预期!社区对它的贡献非常大。我想说的是,在它刚刚推出的那一刻,它是不成功的,但是随着社区对它的完善,包括我们自己还不断的对它做升级。它变了,它变成了一个很庞大的东西。在它刚刚推出的那个时候,它是不够简单易用的,但是随着社区对它的贡献参与,它就变得简单易用了。之所以这样,是因为它有了更多的使用案例。

我认为开源有四个阶段:

第一个阶段是拥抱开源,就是你去用开源软件,这样让你可以最快地有能力达到一个基本的技术水准上。

第二个阶段是回馈开源,比如你可以将你的一些补丁反馈给社区。比如阿里就对 mysql、hadoop 等做了很多贡献。

第三个阶段是融合开源,你的产品别人是否支持?之前是我反馈给社区,而现在别人是否在开源产品中支持你,比如在 Hadoop 源码中支持你,在 Docker 源码中支持你。我拥抱你,你拥抱我,互相接纳。

第四个阶段是回报开源,当你已经被开源社区接受的时候,那这个时候你要有选择性的回报,将一些产品开源出去。这里是有你自己的商业诉求在里面,比如说你有一个方向性的东西你看不清,那么开源出来,大家一起来做,这种情况就比如说 Google 开源它的深度学习。另外一个做法是是将之前换代的产品开源出去。

阿里集团有一个开源委员会,旗下的各个商业部门都有参与,用来决策如何开源,以什么原则,什么节奏去开源。

结语

经过长达一个小时的深入沟通,我们对许多问题进行了探讨和了解,从阿里云这里能够看到,国内的顶级互联网企业,已经跳出了巢臼,能够更大的从产业、文化、趋势方面对运维行业、云计算领域乃至于互联网行业进行深远的布局。

以上,由 Linux 中国的老王为您独家披露。

算法复杂度这件事

这篇文章覆盖了计算机科学里面常见算法的时间和空间的 大 O Big-O 复杂度。我之前在参加面试前,经常需要花费很多时间从互联网上查找各种搜索和排序算法的优劣,以便我在面试时不会被问住。最近这几年,我面试了几家硅谷的初创企业和一些更大一些的公司,如 Yahoo、eBay、LinkedIn 和 Google,每次我都需要准备这个,我就在问自己,“为什么没有人创建一个漂亮的大 O 速查表呢?”所以,为了节省大家的时间,我就创建了这个,希望你喜欢!

--- Eric

图例

绝佳不错一般不佳糟糕

数据结构操作

数据结构时间复杂度空间复杂度
平均最差最差
访问搜索插入删除访问搜索插入删除
ArrayO(1)O(n)O(n)O(n)O(1)O(n)O(n)O(n)O(n)
Stack)O(n)O(n)O(1)O(1)O(n)O(n)O(1)O(1)O(n)
Singly-Linked ListO(n)O(n)O(1)O(1)O(n)O(n)O(1)O(1)O(n)
Doubly-Linked ListO(n)O(n)O(1)O(1)O(n)O(n)O(1)O(1)O(n)
Skip ListO(log(n))O(log(n))O(log(n))O(log(n))O(n)O(n)O(n)O(n)O(n log(n))
Hash Table-O(1)O(1)O(1)-O(n)O(n)O(n)O(n)
Binary Search TreeO(log(n))O(log(n))O(log(n))O(log(n))O(n)O(n)O(n)O(n)O(n)
Cartesian Tree-O(log(n))O(log(n))O(log(n))-O(n)O(n)O(n)O(n)
B-TreeO(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(n)
Red-Black TreeO(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(n)
Splay Tree-O(log(n))O(log(n))O(log(n))-O(log(n))O(log(n))O(log(n))O(n)
AVL TreeO(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(log(n))O(n)

数组排序算法

算法时间复杂度空间复杂度
最佳平均最差最差
QuicksortO(n log(n))O(n log(n))O(n^2)O(log(n))
MergesortO(n log(n))O(n log(n))O(n log(n))O(n)
TimsortO(n)O(n log(n))O(n log(n))O(n)
HeapsortO(n log(n))O(n log(n))O(n log(n))O(1)
Bubble SortO(n)O(n^2)O(n^2)O(1)
Insertion SortO(n)O(n^2)O(n^2)O(1)
Selection SortO(n^2)O(n^2)O(n^2)O(1)
Shell SortO(n)O((nlog(n))^2)O((nlog(n))^2)O(1)
Bucket SortO(n+k)O(n+k)O(n^2)O(n)
Radix SortO(nk)O(nk)O(nk)O(n+k)

图操作

节点 / 边界管理存储增加顶点增加边界移除顶点移除边界查询
Adjacency listO(V+E)O(1)O(1)O(V+E)O(E)O(V)
Incidence listO(V+E)O(1)O(1)O(E)O(E)O(E)
Adjacency matrixO(V^2)O(V^2)O(1)O(V^2)O(1)O(1)
Incidence matrixO(VE)O(VE)O(VE)O(VE)O(VE)O(E)

堆操作

类型时间复杂度
Heapify查找最大值分离最大值提升键插入删除合并
Linked List (sorted)-O(1)O(1)O(n)O(n)O(1)O(m+n)
Linked List (unsorted)-O(n)O(n)O(1)O(1)O(1)O(1)
Binary HeapO(n)O(1)O(log(n))O(log(n))O(log(n))O(log(n))O(m+n)
Binomial Heap-O(1)O(log(n))O(log(n))O(1)O(log(n))O(log(n))
Fibonacci Heap-O(1)O(log(n))O(1)O(1)O(log(n))O(1)

大 O 复杂度图表

 title=

推荐阅读

贡献者

  1. Eric Rowell, creator of Concrete.js, an HTML5 Canvas Framework
  2. Quentin Pleple
  3. Michael Abed
  4. Nick Dizazzo
  5. Adam Forsyth
  6. David Dorfman
  7. Jay Engineer
  8. Jennifer Hamon
  9. Josh Davis
  10. Nodir Turakulov
  11. Bart Massey
  12. Vinnie Magro
  13. Miguel Amigot
  14. Drew Bailey
  15. Aneel Nazareth
  16. Rahul Chowdhury
  17. Robert Burke
  18. steven41292
  19. Brandon Amos
  20. Mike Davis
  21. Casper Van Gheluwe
  22. Joel Friedly
  23. Oleg
  24. Renfred Harper
  25. Piper Chester
  26. Eric Lefevre-Ardant
  27. Jonathan McElroy
  28. Si Pham
  29. mcverry
  30. Max Hoffmann
  31. Alejandro Ramirez
  32. Damon Davison
  33. Alvin Wan
  34. Alan Briolat
  35. Drew Hannay
  36. Andrew Rasmussen
  37. Dennis Tsang
  38. Bahador Saket

微软开源了 Checked C ,这是一个 C 语言的扩展版本,可以用于解决 C 语言中的一系列安全相关的隐患。正如其名字所示,Checked C 为 C 语言增加了检查。这个检查可以帮助开发者检查常见的编程错误,比如 缓存区侵占 buffer overruns 、内存访问越界、不正确的类型转换等。这些编程错误往往是造成许多重大安全漏洞的根本原因,比如 破壳漏洞 Shellshock 心脏出血漏洞 Heartbleed 沙虫 Sandworm 等。

Checked C 通过修改如何控制指针来解决这些问题,指针被程序员们用来定义他们的代码所操作的内存地址。

当指针数量一多,指针控制就往往容易忙中出乱。项目越大,跟踪它们就越困难。类似 Chromium、Firefox、Office、OpenSSL 以及其它的大型代码库在这方面都存在这样的问题,你可以从它们的变更日志中看到大量的这类问题修复。

“Checked C 允许程序员更好的描述他们想要如何使用指针,以及指针应该指向的内存范围”,微软,“这个信息可以用于在运行时环境中添加检测,以侦测错误的数据访问,而不是让错误悄悄的发生而无所察觉。”

Checked C 给 C 语言添加了边界检查

Checked C 也将允许开发者检测到他们以为 C 语言有、而实际却没有的功能误用。按编程的说法来说,这个叫做“ 边界检查 bounds checking ”的功能,用于检查变量/指针是否在它的范围之内赋值。

C# 和 Rust 已经有这样的功能了,而且还不止于此。然而,不幸的是,被广泛使用的 C 和 C++ 却没有这样的功能。微软希望只需要对现有的 C/C++ 程序做最小的改动,利用 Checked C 就可以得到安全方面的改善,这样会吸引大量的开发者开始使用 Checked C。

Checked C 项目已经放到了 GitHub 上。

这并不是微软第一次对基本编程语言做出来自己的演绎,之前,该公司的程序员们还创建了一个名为 TypeScript 的 JavaScript 的超集,它已经得到了广泛认可。