2017年10月

rules of coding nasa

引言: 你知道 NASA 顶级程序员如何编写关键任务代码么?为了确保代码更清楚、更安全、且更容易理解,NASA 的喷气推进实验室制定了 10 条编码规则。

NASA 的开发者是编程界最有挑战性的工作之一。他们编写代码并将开发安全的关键任务应用程序作为其主要关注点。

在这种情形下,遵守一些严格的编码规则是重要的。这些规则覆盖软件开发的多个方面,例如软件应该如何编码、应该使用哪些语言特性等。

尽管很难就一个好的编码标准达成共识,NASA 的喷气推进实验室(JPL)遵守一个编码规则,其名为“十的次方:开发安全的关键代码的规则”。

由于 JPL 长期使用 C 语言,这个规则主要是针对于 C 程序语言编写。但是这些规则也可以很容地应用到其它的程序语言。

该规则由 JPL 的首席科学家 Gerard J. Holzmann 制定,这些严格的编码规则主要是聚焦于安全。

NASA 的 10 条编写关键任务代码的规则:

  1. 限制所有代码为极为简单的控制流结构 — 不用 goto 语句、setjmplongjmp 结构,不用间接或直接的递归调用。
  2. 所有循环必须有一个固定的上限值。必须可以被某个检测工具静态证实,该循环不能达到预置的迭代上限值。如果该上限值不能被静态证实,那么可以认为违背该原则。
  3. 在初始化后不要使用动态内存分配。
  4. 如果一个语句一行、一个声明一行的标准格式来参考,那么函数的长度不应该比超过一张纸。通常这意味着每个函数的代码行不能超过 60。
  5. 代码中断言的密度平均低至每个函数 2 个断言。断言被用于检测那些在实际执行中不可能发生的情况。断言必须没有副作用,并应该定义为布尔测试。当一个断言失败时,应该执行一个明确的恢复动作,例如,把错误情况返回给执行该断言失败的函数调用者。对于静态工具来说,任何能被静态工具证实其永远不会失败或永远不能触发的断言违反了该规则(例如,通过增加无用的 assert(true) 语句是不可能满足这个规则的)。
  6. 必须在最小的范围内声明数据对象。
  7. 非 void 函数的返回值在每次函数调用时都必须检查,且在每个函数内其参数的有效性必须进行检查。
  8. 预处理器的使用仅限制于包含头文件和简单的宏定义。符号拼接、可变参数列表(省略号)和递归宏调用都是不允许的。所有的宏必须能够扩展为完整的语法单元。条件编译指令的使用通常是晦涩的,但也不总是能够避免。这意味着即使在一个大的软件开发中超过一两个条件编译指令也要有充足的理由,这超出了避免多次包含头文件的标准做法。每次在代码中这样做的时候必须有基于工具的检查器进行标记,并有充足的理由。
  9. 应该限制指针的使用。特别是不应该有超过一级的解除指针引用。解除指针引用操作不可以隐含在宏定义或类型声明中。还有,不允许使用函数指针。
  10. 从开发的第一天起,必须在编译器开启最高级别警告选项的条件下对代码进行编译。在此设置之下,代码必须零警告编译通过。代码必须利用源代码静态分析工具每天至少检查一次或更多次,且零警告通过。

关于这些规则,NASA 是这么评价的:

这些规则就像汽车中的安全带一样,刚开始你可能感到有一点不适,但是一段时间后就会养成习惯,你会无法想象不使用它们的日子。

此文是否对你有帮助?不要忘了在下面的评论区写下你的反馈。


作者简介:

Adarsh Verma 是 Fossbytes 的共同创始人,他是一个令人尊敬的企业家,他一直对开源、技术突破和完全保持密切关注。可以通过邮件联系他 — [email protected]


via: https://fossbytes.com/nasa-coding-programming-rules-critical/

作者:Adarsh Verma 译者:penghuster 校对:wxy

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

云集成高级编排器 Cloud Integrated Advanced Orchestrator (Ciao) 是一个新的负载调度程序,用来解决当前云操作系统项目的局限性。Ciao 提供了一个轻量级,完全基于 TLS 的最小配置。它是 工作量无关的、易于更新、具有优化速度的调度程序,目前已针对 OpenStack 进行了优化。

其设计决策和创新方法在对安全性、可扩展性、可用性和可部署性的要求下进行:

  • 可扩展性: 初始设计目标是伸缩超过 5,000 个节点。因此,调度器架构用新的形式实现:

    • 在 ciao 中,决策制定是去中心化的。它基于拉取模型,允许计算节点从调度代理请求作业。调度程序总能知道启动器的容量,而不要求进行数据更新,并且将调度决策时间保持在最小。启动器异步向调度程序发送容量。
    • 持久化状态跟踪与调度程序决策制定相分离,它让调度程序保持轻量级。这种分离增加了可靠性、可扩展性和性能。结果是调度程序让出了权限并且这不是瓶颈。
  • 可用性: 虚拟机、容器和裸机集成到一个调度器中。所有的负载都被视为平等公民。为了更易于使用,网络通过一个组件间最小化的异步协议进行简化,只需要最少的配置。Ciao 还包括一个新的、简单的 UI。所有的这些功能都集成到一起来简化安装、配置、维护和操作。
  • 轻松部署: 升级应该是预期操作,而不是例外情况。这种新的去中心化状态的体系结构能够无缝升级。为了确保基础设施(例如 OpenStack)始终是最新的,它实现了持续集成/持续交付(CI/CD)模型。Ciao 的设计使得它可以立即杀死任何 Ciao 组件,更换它,并重新启动它,对可用性影响最小。
  • 安全性是必需的: 与调度程序的连接总是加密的:默认情况下 SSL 是打开的,而不是关闭的。加密是从端到端:所有外部连接都需要 HTTPS,组件之间的内部通信是基于 TLS 的。网络支持的一体化保障了租户分离。

初步结果证明是显著的:在 65 秒内启动一万个 Docker 容器和五千个虚拟机。进一步优化还在进行。


via: https://clearlinux.org/ciao

作者:ciao 译者:geekpi 校对:wxy

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

docker

之前的文章中我们提到可以通过容器创建一个我们自定义过的镜像,那么我们是否可以直接通过基础的镜像直接自定义镜像呢?答案当然是可以的,在 Docker 中我们可以从名为 Dockerfile 的文件中读取指令并且自动构建镜像。在本文中,将介绍 Dockerfile 的基本语法以及基本知识。

1、Dockerfile 是什么?

Dockerfile 其实是一份文本文档,里面包含了用户可以用来操作镜像的一些指令。通过顺序执行这些指令,最后得到一个自定义的镜像,这有点类似于我们的 shell 脚本。

2、Dockerfile 示例

接下来先看一个 Dockerfile 示例:

FROM centos
LABEL maintainer="Locez <[email protected]>"
ENV TEST="This is a test env"
COPY nginx.repo /etc/yum.repos.d/nginx.repo
RUN yum update -y && \
        yum install -y nginx
COPY nginx.conf /etc/nginx/nginx.conf
COPY index.html /usr/share/nginx/html/index.html
COPY index_files/ /usr/share/nginx/html/index_files/
EXPOSE 80
CMD ["/usr/sbin/nginx","-g","daemon off;"]

在上面我们可以看到 Dockerfile 中的一些指令,通过名称我们也可以猜到这些指令大概是干嘛的,其中有一些对文件的操作,因此我们先来看看用于存放 Dockerfile 的这个目录的目录结构:

# tree .
.
├── Dockerfile
├── index_files
│   ├── 145049z4og8xyjhx4xy8go.jpg
│   ├── 222746e5vh38d7ey3leyps.jpg
│   ├── 88x31.png
│   ├── archlinux-splash.png
│   ├── bdshare.css
│   ├── Best-Linux-Markdown-Editors.png
│   ├── core.js
│   ├── docker-icon.jpg
│   ├── hadoop-pic1.png
│   ├── jquery_002.js
│   ├── jquery.css
│   ├── jquery.js
│   ├── MathJax.js
│   ├── pic.gif
│   ├── raspberrypiraspberry-pi-logo.jpg
│   ├── script.js
│   ├── scrollup.png
│   ├── share.js
│   ├── style.css
│   └── z_stat.js
├── index.html
├── nginx.conf
└── nginx.repo

1 directory, 24 files

构建镜像

在当前目录下执行以下命令构建镜像:

# docker build -t locez/nginx .
Sending build context to Docker daemon 1.851 MB
Step 1/10 : FROM centos
 ---> 196e0ce0c9fb
Step 2/10 : LABEL maintainer "Locez <[email protected]>"
 ---> Using cache
 ---> 9bba3042bcdb
Step 3/10 : ENV TEST "This is a test env"
 ---> Using cache
 ---> c0ffe95ea0c5
Step 4/10 : COPY nginx.repo /etc/yum.repos.d/nginx.repo
 ---> Using cache
 ---> bb6ee4c30d56
Step 5/10 : RUN yum update -y &&        yum install -y nginx
 ---> Using cache
 ---> 6d46b41099c3
Step 6/10 : COPY nginx.conf /etc/nginx/nginx.conf
 ---> Using cache
 ---> cfe908390aae
Step 7/10 : COPY index.html /usr/share/nginx/html/index.html
 ---> Using cache
 ---> 21729476079d
Step 8/10 : COPY index_files/ /usr/share/nginx/html/index_files/
 ---> Using cache
 ---> 662f06ec7b46
Step 9/10 : EXPOSE 80
 ---> Using cache
 ---> 30db5a889d0a
Step 10/10 : CMD /usr/sbin/nginx -g daemon off;
 ---> Using cache
 ---> d29b9d4036d2
Successfully built d29b9d4036d2

然后用该镜像启动容器:

# docker run -d -it --rm --name test-nginx -p 8080:80 locez/nginx
e06fd991ca1b202e08cf1578f8046355fcbba10dd9a90e11d43282f3a1e36d29

用浏览器访问 http://localhost:8080/ 即可看到部署的内容。

3 Dockerfile 指令解释

Dockerfile 支持 FROMRUNCMDLABELEXPOSEENVADDCOPYENTRYPOINTVOLUMEUSERWORKDIRARGONBUILDSHELL 等指令,这里只选择常用的几个进行讲解,可结合上面的示例进行理解。其它的请自行查阅官方文档。

3.1 FROM

FROM 指令用于指定要操作的基础镜像,因为在我们构建我们自己的镜像的时候需要一个基础镜像。 语法:

FROM <image> [AS <name>]
FROM <image>[:<tag>] [AS <name>]

其中 [AS <name>] 为指定一个名称,在一个 Dockerfile 中多次使用 FROM 时如有需要,可用 COPY --from=<name|index> 语法进行复制。

3.2 RUN

RUN 指令用于执行命令,并且是在新的一层上执行,并把执行后的结果提交,也就是生成新的一层。基于这个问题,我们在使用 RUN 指令时应该尽可能的把要执行的命令一次写完,以减少最后生成的镜像的层数。 语法:

RUN <command>
RUN ["executable", "param1", "param2"]

3.3 CMD

CMD 指令用于给容器启动时指定一个用于执行的命令,例如上例中的 nginx 启动命令。 语法:

CMD ["executable","param1","param2"]
CMD ["param1","param2"] ### 用于给 ENTRYPOINT 指令提供默认参数
CMD command param1 param2

3.4 LABEL

LABEL 指令用于为镜像指定标签,可用 docker inspect 命令查看。可用来代替被舍弃的 MAINTAINER 命令。 语法:

LABEL <key>=<value> <key>=<value> <key>=<value> ...

3.5 EXPOSE

EXPOSE 指令用于告诉 Docker 容器监听的特殊端口,但是此时端口还没有暴露给 host ,只有当在运行一个容器显式用参数 -p 或者 -P 的时候才会暴露端口。 语法:

EXPOSE <port> [<port>/<protocol>...]

3.6 ENV

ENV 指令用于设定环境变量。 语法:

ENV <key> <value>
ENV <key>=<value> ...

3.7 ADD

ADD 指令用于复制新文件,目录,远程文件到容器中。其中 <src> 可以为文件,目录,URL,若为可解压文件,在复制后会解压。 语法:

ADD <src>... <dest>
ADD ["<src>",... "<dest>"]

3.8 COPY

COPY 指令与 ADD 指令非常相似,但 COPY 比较直观且简单,它只支持本地的文件以及目录的复制,不像 ADD 指令可以远程获取文件并解压。 语法:

COPY <src>... <dest>
COPY ["<src>",... "<dest>"]

3.9 ENTRYPOINT

ENTRYPOINT 指令也跟 CMD 指令相似,用于指定容器启动时执行的命令。当使用 ENTRYPOINT 指令时,可用 CMD 命令配合,这样在启动容器时,可以对 CMD 指令写入的参数进行覆盖。 语法:

ENTRYPOINT ["executable", "param1", "param2"]

例子:

ENTRYPOINT ["top","-b"]
CMD ["-c"]

上面的 -c 参数可以在启动时覆盖 docker run -it --rm --name test top -H。 如果要覆盖 ENTRYPOINT 指令则用 --entrypoint 参数启动容器。

3.10 VOLUME

VOLUME 指令用于为容器创建一个挂载点,这个挂载点可以用来挂载 本地文件/文件夹 也可以用来挂载 数据卷。其中若在启动一个新容器时没有指定挂载目录,则会自动创建一个数据卷,当容器被销毁时,数据卷如果没有被其它容器引用则会被删除。 语法:

VOLUME ["/data1","/data2"]

3.11 USER

USER 指令用于设置执行 RUN, CMD, ENTRYPOINT 等指令的用户以及用户组。默认为 root 用户。 语法:

USER <user>[:<group>]

3.12 WORKDIR

WORKDIR 指令用于设置 RUN, CMD, ENTRYPOINT, COPY, ADD 等指令的工作目录。 语法:

WORKDIR /path/to/workdir

4 总结


本文从一个具体的例子出发,讲述了如何利用 Dockerfile 构建镜像,然后解释了 Dockerfile 文件中的指令的语法,有关更多内容可访问官方文档。

5 参考资料


今天,Canonical 公司发布了 Ubuntu 17.10,这个版本不是 LTS 版本,因此其支持期只有 9 个月,支持到 2018 年 7 月。

Ubuntu 17.10 的代号是 Artful Aardvark (巧豚)。正如大家知道的,Ubuntu 发行版的代号是由两个单词组成的,分别是一个形容词和一个濒危动物名。从第四个版本开始,就按照字母顺序,从 D 开始逐个使用。这是 Ubnutu 发布了 26 个主版本以来,唯二剩下没用过的字母(另外一个是 C,最开始的三个版本没有按字母顺序来,分别是 W、H、B)。

Artful Aardvark (巧豚)

重大变化

这次的 Ubuntu 17.10 虽然不是重要的 LTS 版本,连 Ubuntu 官网的介绍中都将其视作是明年的 Ubuntu 18.04 LTS 的前奏,但是这个版本其实还是有几个处女式创新:

  • 这是第一个放弃 32 位支持的主版本,不过 17.10 的官方风味版本还会继续支持 32 位。
  • 这是七年来 Ubuntu 主版本第一次放弃 Unity 用户界面,改投 GNOME 怀抱,目前采用的是最新的 GNOME 3.26.1。
  • 这是第一次默认使用 Wayland 显示服务器,而 X.Org 显示服务器则是可选的。当然如果你的机器不支持 Wayland ,会自动回退到 X.Org。
  • 默认不再安装 Python 2,Python 3 更新到了 3.6。

我们可以先看一下官方的宣传视频:

新的变化

除了上述重大改变之外,Ubuntu 17.10 还有这些新改变:

桌面版

  • 新的由 GNOME 带来的 Caribou 屏幕键盘替代了原来的 Onboard,铺平了将来的触摸屏体验之路。
  • 相同的用户体验。虽然更换了 GNOME,但是从桌面布局到键盘快捷键均保持了一致,这要感谢那些主题和扩展。
  • 熟悉的 dock。从 11.04 开始,dock 就是 Ubuntu 发行版的特色,在这个版本中,它还继续在那里,不增不减——不过现在它可以随意移动到左边、右边和底部。
  • Ubuntu 17.10 使用 Linux kernel 4.13。
  • 交换分区现在改成了交换文件,这便于你随时根据系统需求伸缩,也可以很方便的安装到各种机器上。
  • 由于默认使用 GNOME 桌面系统,GDM 也替换 LightDM 成为了默认的显示管理器。并且现在登录屏使用 1 号虚拟终端,而不是之前的 7 号虚拟终端。
  • 七年来,窗口控制按钮首次从左边回到了右边。
  • 免驱动打印现在支持 IPP EverywhereApple AirPrintWi-Fi DirectMopria 设备。
  • “设置”应用重新进行了设计。
  • “系统日志” 被替换为“日志”,这是来自 systemd journal 的日志查看器。
  • 官方风味版的 Ubuntu GNOME 停止更新,因为现在 Ubuntu 使用的就是 GNOME 。
  • 但是如果你想试试更上游的 GNOME,你可以安装 gnome-session,并从登录屏幕选择 GNOME 。如果你喜欢的话,也可以安装 vanilla-gnome-desktop 基础包来获得更多的 GNOME 核心应用。

服务器版

  • qemu 从 2.8 更新到了 2.10。需要注意的是,默认增加并启用了镜像锁定功能,一般来说它会更安全,但是在有些旧场景下会有问题。
  • libvirt 更新到了 3.6。
  • DPDK 更新到了最新的稳定版本 17.05.2,这使得它可以与 Open vSwitch 2.8 集成。Open vSwitch 更新到了 2.8,需要注意是的,从 2.7 开始,你就需要通过 dpdk-devargs 指定 dpdk 设备了。
  • DNS 服务器 Bind9 更新包括了 2017 年 7 月 11 日新发布的 密钥签名密钥 Key Signing Key (KSK),从 2017 年 10 月 11 日开始,该密钥将用于签名根区密钥,根区密钥用于签名实际的根区。已运行的 Bind 9 会根据 RFC 5011 自动更新其锚点密钥,而 2017 年 10 月 11 日回滚事件之后新安装的 Bind 9 将需要这个包或手动更新密钥。

更多变化,可以参考发行公告

下载

从 17.04 升级

如果你希望使用长期支持版本,建议你安装 Ubuntu 16.04 LTS。如果你在使用 Ubuntu 17.04,你可以按以下方式升级到最新版本。

桌面系统升级:

  • 在系统设置中打开“软件与更新”。
  • 选择“更新”选项卡。
  • 设置下拉菜单“有新的 Ubuntu 版本时提醒我”为“任何新版本”。
  • 按下 Alt+F2快捷键,并在命令行窗口输入 update-manager -c
  • 更新管理器将打开并提示你“新的发行版 17.10 已经可用”。如果不工作,你可以运行 /usr/lib/ubuntu-release-upgrader/check-new-release-gtk
  • 点击“升级”并按屏幕提示进行。

服务器系统升级:

  • 如果没有安装的话,请先安装 update-manager-core 软件包。
  • 确保 /etc/update-manager/release-upgrades 中的 Prompt 设置为 normal
  • 在命令行运行 sudo do-release-upgrade 启动升级管理器。
  • 按屏幕提示进行。

通过在云计算、大数据和标准 API 上的企业及社区的协作,我很高兴 OpenMessaging 项目进入 Linux 基金会。OpenMessaging 社区的目标是为分布式消息分发创建全球采用的、供应商中立的和开放标准,可以部署在云端、内部和混合云情景中。

阿里巴巴、雅虎、滴滴和 Streamlio 是该项目的创始贡献者。Linux 基金会已与这个初始项目社区合作来建立一个治理模式和结构,以实现运作在消息 API 标准上的生态系统的长期受益。

由于越来越多的公司和开发者迈向 云原生应用 cloud native application ,消息式应用和流式应用的扩展面临的挑战也在不断发展。这包括平台之间的互操作性问题, 线路级协议 wire-level protocol 之间缺乏兼容性以及系统间缺乏标准的基准测试。

特别是当数据跨不同的消息平台和流平台进行传输时会出现兼容性问题,这意味着额外的工作和维护成本。现有解决方案缺乏负载平衡、容错、管理、安全性和流功能的标准化指南。目前的系统不能满足现代面向云的消息应用和流应用的需求。这可能导致开发人员额外的工作,并且难以或不可能满足物联网、边缘计算、智能城市等方面的尖端业务需求。

OpenMessaging 的贡献者正在寻求通过以下方式改进分布式消息分发:

  • 为分布式消息分发创建一个面向全球、面向云、供应商中立的行业标准
  • 促进用于测试应用程序的标准基准发展
  • 支持平台独立
  • 以可伸缩性、灵活性、隔离和安全性为目标的云数据的流和消息分发要求
  • 培育不断发展的开发贡献者社区

你可以在这了解有关新项目的更多信息以及如何参与: http://openmessaging.cloud

这些是支持 OpenMessaging 的一些组织:

“我们多年来一直专注于消息分发和流领域,在此期间,我们探索了 Corba 通知、JMS 和其它标准,来试图解决我们最严格的业务需求。阿里巴巴在评估了可用的替代品后,选择创建一个新的面向云的消息分发标准 OpenMessaging,这是一个供应商中立,且语言无关的标准,并为金融、电​​子商务、物联网和大数据等领域提供了行业指南。此外,它目地在于跨异构系统和平台间开发消息分发和流应用。我们希望它可以是开放、简单、可扩展和可互操作的。另外,我们要根据这个标准建立一个生态系统,如基准测试、计算和各种连接器。我们希望有新的贡献,并希望大家能够共同努力,推动 OpenMessaging 标准的发展。”

——阿里巴巴高级架构师,Apache RocketMQ 的联合创始人,以及 OpenMessaging 的原始发起人 Von Gosling

“随着应用程序消息的复杂性和规模的不断扩大,缺乏标准的接口为开发人员和组织带来了复杂性和灵活性的障碍。Streamlio 很高兴与其他领导者合作推出 OpenMessaging 标准倡议来给客户一个轻松使用高性能、低延迟的消息传递解决方案,如 Apache Pulsar,它提供了企业所需的耐用性、一致性和可用性。“

—— Streamlio 的软件工程师、Apache Pulsar 的联合创始人以及 Apache BookKeeper PMC 的成员 Matteo Merli

“Oath(Verizon 旗下领先的媒体和技术品牌,包括雅虎和 AOL)支持开放,协作的举措,并且很乐意加入 OpenMessaging 项目。”

—— Joe Francis,核心平台总监

“在滴滴中,我们定义了一组私有的生产者 API 和消费者 API 来隐藏开源的 MQ(如 Apache Kafka、Apache RocketMQ 等)之间的差异,并提供额外的自定义功能。我们计划将这些发布到开源社区。到目前为止,我们已经积累了很多关于 MQ 和 API 统一的经验,并愿意在 OpenMessaging 中与其它 API 一起构建 API 的共同标准。我们真诚地认为,统一和广泛接受的 API 标准可以使 MQ 技术和依赖于它的应用程序受益。”

—— 滴滴的架构师 Neil Qi

“有许多不同的开源消息分发解决方案,包括 Apache ActiveMQ、Apache RocketMQ、Apache Pulsar 和 Apache Kafka。缺乏行业级的可扩展消息分发标准使得评估合适的解决方案变得困难。我们很高兴能够与多个开源项目共同努力,共同确定可扩展的开放消息规范。 Apache BookKeeper 已成功在雅虎(通过 Apache Pulsar)和 Twitter(通过 Apache DistributedLog)的生产环境中部署,它作为其企业级消息系统的持久化、高性能、低延迟存储基础。我们很高兴加入 OpenMessaging 帮助其它项目解决诸如低延迟持久化、一致性和可用性等在消息分发方案中的常见问题。”

—— Streamlio 的联合创始人、Apache BookKeeper 的 PMC 主席、Apache DistributedLog 的联合创造者, Sijie Guo


via: https://www.linuxfoundation.org/blog/building-open-standard-distributed-messaging-introducing-openmessaging/

作者:Mike Dolan 译者:geekpi 校对:wxy

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

Who Killed MySQL? - Epilogue

这篇漫画意在讽刺 Oracle 收购太阳微系统公司之后,对收购来的资产一个个杀死,比如 MySQL,导致大多数发行版已经不使用 MySQL ,转向它的分支 MariaDB,在此之后,Oracle 还放弃了“不赚钱的” Java EE。

然后之后,是以对开源不友善而著名的微软前总裁巴尔默——虽然现在新总裁纳德拉上台之后,微软公司乃至巴尔默都对开源的态度发生了一百八十度大转弯。

本篇漫画中涉及的一些技术方面的隐喻有:

  • SIGKILL,是一种 UNIX/Posix 信号,用于结束一个进程,不可捕获。关于 SIGKILL ,可以看看这篇漫画
  • PIPE,是 UNIX/Posix 中的一种进程通讯机制,数据可以通过管道进行传输,进行进程间通讯。此处引申为一个管道、通道,从漫画中可以看到, Java 439 进程感觉不妙的时候,其脚下已经有些塌陷的痕迹,而接着变成了一个通道——然后它就掉进去死了。
  • ulimit,是 UNIX/Linux 中用于限制资源分配的命令,可以设置系统可以分配的文件句柄数等,像 Apache 之类的服务需要足够的句柄数才能提供更高的连接数。此处,头上顶着羽毛的 Apache 表示,它要占用一些 ulimit 分配的资源(去工作了)。

via: http://turnoff.us/geek/who-killed-mysql-epilogue/

作者:Daniel Stori 译者&点评:ItsLucas 校对&合成:wxy

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