Canonical 在几年前曾经抛弃了 GNOME，而是用其自己定制的 Unity 来实现 Ubuntu 用户界面。不过现在，Canonical 在 Ubuntu 18.04 发行版里又重新用回了 GNOME，而放弃了 Unity。

那么问题来了：为什么 Canonical 会放弃 Unity 呢？

Christine Hall 推测，Canonical 这么做的原因很可能和钱有关。她列举了几点原因，来说明为什么 Canonical 会在 Ubuntu 系统开发上做出如此巨大的技术变化。

Christine Hall 对媒体说：

周三的声明非常明显地揭示了事情的唯一原因，那就是 Canonical 公司目前正在把资源从 Ubuntu 桌面版的开发小组撤出，因为桌面市场根本就不赚钱，撤出的资源被投入到了和云相关的系统开发上，因为公司发现这部分才是公司收入的稳定来源。

（Ubuntu 创始人）Shuttleworth 发布声明后没多久，就有媒体报道称，Ubuntu Unity 项目组有超过一半的雇员收到了解聘通知。该媒体还称，除 Unity 项目组外，Ubuntu 还有其他的部门也遭受了大面积的裁员。

“除裁撤的部门外，Ubuntu 的其他机构还是能够顺利工作的。裁员的命令直接来自于 Canonical 的创始人——亿万富翁 Mark Shuttleworth。他这么做的目的是为了吸引更多的外部投资人对 Ubuntu 进行投资。因为之前这些投资人曾经对 Canonical 留下了人事臃肿，项目专注度不够的印象。（Mark Shuttleworth 显然是要扭转这个印象。）”

换句话说，最近发生的”大新闻“（也就是放弃 Unity 以及停止开发手机版 Ubuntu 的决定）很可能只是冰山一角。在随后的时间里，很有可能，Canonical 会把精力集中到如何获取利润上，那么相应地，就可能会有更多的裁员发生，这也就意味着，那些不怎么赚钱的项目可能都会被砍掉。而 Ubuntu 桌面项目，几乎难道被砍的命运，尤其是现在还有那么多的独立开发的（当然 Ubuntu 官方”不允许“）的山寨版 Ubuntu 桌面存在。

Canonical 关于 GNOME 和 Unity 的官方声明

如果还有读者不知道这个声明的内容的话，这里就再提及一下。Ubuntu 创始人 Mark Shuttleworth 在官博宣布了关于 Ubuntu 桌面环境在技术上的重大变动：

我在这里写下这些，是为了让大家知道，我们将终止对 Unity8、手机版本和 convergence shell 的投入。从 Ubuntu 18.04 LTS 开始，默认的 Ubuntu 桌面将重归 GNOME。

我认为，多设备整合（convergence）是未来的必然趋势，Ubuntu 应当用自由软件的方式去实现这种特性，尽管现实情况有一些瑕疵，但这么做应该会受到自由软件社区和工业技术界的一致认同。然而事实并不是这样，制造商们有其他的想法和选择，我的观点则是大错特错。

在社区看来，我们的努力并不是一种创新，而是一种碎裂化。而业界呢，也没有团结起来，而是本着一种”现有的东西再烂也比没做出来的新东西要好“的消极心态，把钱投到了其他领域上。Unity8 开发团队开发出来的东西是美丽的，结实好用的，但是我还是相信市场，相信社区的选择，最终会决定哪些产品能够成长，哪些产品将会消失。

从我个人来说，这是一个非常困难的决定，因为我曾经无比相信多平台整合的美好未来，我个人也亲身参与到产品研发当中，这些无疑都是令人振奋的。我和参与项目的所有人就像是家人一样。但是我做决定是受商业限制的，个人的感情无法也无法悖逆商业。

Linux 用户对 GNOME 取代 Unity 的反应

关于 GNOME 取代 Unity 的消息，在 Reddit 的 Linux 频道引起了热烈讨论，并形成了一个很长的讨论帖：

ShibaTheDestroyer： “对我来说无所谓，真的。GNOME 是高度可定制的，如果 Canonical 脑子够用的话，他们会通过扩展的方式新界面做得和 Unity 差不多。这样用户就可以按照以前的习惯操作，而且 GNOME 得到的支持越多，Canonical 的代码库维护工作就越轻松简单。如果这一切都能做得很好的话，那又有什么关系呢？”

Csolisr： “GNOME Shell 是可定制，可扩展的。但是对于部分开发者来说，这些定制和扩展还是不够，所以才会有各种其他的分支出现，例如 Linux Mint 开发者们搞出来的 Cinnamon。”

DSMcGuire：“我猜在 GNOME 真的派上用场之前，会一直用 Unity 7 吧。”

然而，还有很多人表示，过去 3-4 年Ubuntu 在做 Unity 8 时，一直在使用基于 Qt 的 KDE，那么为什么现在要突然换成基于 GTK 的 GNOME 呢？为什么不直接用 KDE 来替换 Unity，从而把之前几年积攒的 Qt 经验都用上呢？

Edarfoc： “这帮人会（把 Ubuntu 对 GNOME 的依赖）搞得比 Debian 还重，Debian 的默认界面就是 GNOME.”

Charged_Buffalo： “这不仅仅是社区和上游的事情，这关乎到 Ubuntu 的品牌。宣称放弃 Ubuntu 手机和 Unity 8 对公司的公众形象时一个巨大的冲击。从上游来看，正如你们所提到的，可能要花一倍的时间才能用 GNOME 做出更好的桌面界面（而且谁也不知道能不能真的做到）。从 UI 的角度来看，这种技术选择也打破了 Ubuntu 喜闻乐见的橙色主题（因为 GNOME 的 UI 主题是蓝黑白的混合。），这对 Ubuntu 品牌来说绝对是有冲击作用的。”

Phyrz： “我一开始很担心，因为早上我安装了ubuntu-gnome-desktop，安装的几个小时内，gnome-tweak，控制面板和一大堆扩展来回折腾，最后好像是能用了，至少对我来说是这样。”

Whiskies： “真心希望他们选 KDE。我可不觉的 GNOME 开发者能对 Canonical 敞开心扉促成进步，因为这两个组织根本就意见相左。

KDE 目前是最好的选择，即使以往情况并不总是尽如人意。难道 Canonical 的开发者们从 Unity 中得来的 Qt 和 QML 的经验还不够多吗？这些经验技巧本来应该传承过来才对。”

Avamander： “要是放弃，Unity 干脆一早就不要开始啊，为什么要等到人们觉得它还不错的时候才放弃？这个技术都快到上小学的年纪了。”

Ubugtu： “这个变化让我觉得不可思议。Unity 是我最喜欢的桌面，Unity 8 看上去帅极了。虽然我觉得 GNOME 也还不错，但是窗体和菜单间的垂直空间浪费得太多了。”

完美阅读及发表评论，请猛击：https://linux.cn/article-8413-1.html?utm_source=rss&utm_medium=rss

用于安全事件响应的工具与资源的列表，旨在帮助安全分析师与 DFIR 团队。

工具集

• Belkasoft Evidence Center - 该工具包通过分析硬件驱动、驱动镜像、内存转储、iOS、黑莓与安卓系统备份、UFED、JTAG 与 chip-off 转储来快速从多个源提取数字证据
• CimSweep - CimSweep 是一套基于 CIM/WMI 的工具，能够在所有版本的 Windows 上执行远程事件响应
• CIRTkit - CIRTKit 不仅是一个工具集合，更是一个框架，帮助在事件响应与取证调查过程中统一
• Cyber Triage - Cyber Triage 远程收集/分析终端数据，以帮助确定计算机是否被入侵。其专注易用性与自动化，采用无代理方法使公司在没有重大基础设施/没有取证专家团队的情况下做出响应，其结果用于决定是否应该被擦除或者进行进一步调查
• Digital Forensics Framework - DFF 是一个建立在专用 API 之上的开源计算机取证框架，DFF 提出了一种替代目前老旧的数字取证解决方案，其设计简单/更加自动化，通过 DFF 接口可以帮助用户进行数字调查取证的主要步骤，专业与非专业人员都可以快速的进行数字取证并执行事件响应
• Doorman - Doorman 是一个 osquery 的管理平台，可以远程管理节点的 osquery 配置。它利用 osquery 的 TLS 配置/记录器/分布式读写等优势为管理员提供最小开销的管理
• Envdb - Envdb 将你的生产/开发/云等环境变成数据库集群，你可以使用 osquery 作为基础搜索，它可以和集群中心节点包装 osquery 的查询过程
• Falcon Orchestrator - Falcon Orchestrator 是由 CrowdStrike 提供的一个基于 Windows 可扩展的应用程序，提供工作流自动化、案例管理与安全应急响应等功能
• FIDO - Netflix 开发的 Fully Integrated Defense Operation (FIDO) 用于自动化评估/响应恶意软件入侵响应过程，FIDO 的主要目的是协助处理大量的手动工作来评估对安全堆栈的威胁与生成的大量警报
• GRR Rapid Response - GRR Rapid Response 是一个用来远程现场取证的应急响应框架，其带有一个可以管理客户端的 Python 编写的服务器
• Kolide - Kolide 是一个无代理的 osquery Web 接口与远程 API 服务器，Kolide 作为 Envdb 替代品的设计理念就是极度便携(仅有一个可执行程序)，在保持代码简单的情况下保持性能
• Limacharlie - 一个终端安全平台，它本身是一个小项目的集合，并提供了一个跨平台的低级环境，你可以管理并推送附加功能进入内存给程序扩展功能
• MIG - Mozilla Investigator (MIG) 是一个在远程终端执行调查的平台，它可以在大量系统中并行获取数据，从而加速事故调查与保证日常业务安全
• MozDef - Mozilla Defense Platform (MozDef) 旨在帮助安全事件处理自动化，并促进事件的实时处理
• nightHawk - nightHawk Response Platform 是一个以 ElasticSearch 为后台的异步取证数据呈现的应用程序，设计与 Redline 配合调查
• Open Computer Forensics Architecture - Open Computer Forensics Architecture (OCFA) 是另一个分布式开源计算机取证框架，这个框架建立在 Linux 平台上，并使用 postgreSQL 数据库来存储数据
• Osquery - osquery 可以找到 Linux 与 OSX 基础设施的问题，无论你是要入侵检测还是基础架构可靠性检查 osquery 都能够帮助你提高公司内部的安全组织能力， incident-response pack 可以帮助你进行检测/响应活动
• Redline - 为用户提供主机调查工具，通过内存与文件分析来找到恶意行为的活动迹象，包括对威胁评估配置文件的开发
• The Sleuth Kit & Autopsy - Sleuth Kit 是基于 Unix 和 Windows 的工具，可以帮助计算机取证分析，其中包含各种协助取证的工具，比如分析磁盘镜像、文件系统深度分析等
• TheHive - TheHive 是一个可扩展的三个一开源解决方案，旨在让 SOC、CSIRT、CERT 或其他任何信息安全从业人员方便的进行安全事件调查
• X-Ways Forensics - X-Ways 是一个用于磁盘克隆、镜像的工具，可以查找已经删除的文件并进行磁盘分析
• Zentral - 与 osquery 强大的端点清单保护能力相结合，通知与行动都灵活的框架，可以快速对 OS X 与 Linux 客户机上的更改做出识别与响应

书籍

• Dfir intro - 作者:Scott J. Roberts
• The Practice of Network Security Monitoring: Understanding Incident Detection and Response - 作者:Richard Bejtlich

社区

• Sans DFIR mailing list - Mailing list by SANS for DFIR
• Slack DFIR channel - Slack DFIR Communitiy channel - Signup here

磁盘镜像创建工具

• AccessData FTK Imager - AccessData FTK Imager 是一个从任何类型的磁盘中预览可恢复数据的取证工具，FTK Imager 可以在 32/64 位系统上实时采集内存与页面文件
• GetData Forensic Imager - GetData Forensic Imager 是一个基于 Windows 程序，将常见的文件格式进行获取/转换/验证取证
• Guymager - Guymager 是一个用于 Linux 上媒体采集的免费镜像取证器
• Magnet ACQUIRE - Magnet Forensics 开发的 ACQUIRE 可以在不同类型的磁盘上执行取证，包括 Windows/Linux/OS X 与移动操作系统

证据收集

• bulk_extractor - bulk_extractor 是一个计算机取证工具，可以扫描磁盘映像、文件、文件目录，并在不解析文件系统或文件系统结构的情况下提取有用的信息，由于其忽略了文件系统结构，程序在速度和深入程度上都有了很大的提高
• Cold Disk Quick Response - 使用精简的解析器列表来快速分析取证镜像文件(dd， E01， .vmdk， etc)并输出报告
• ir-rescue - ir-rescue 是一个 Windows 批处理脚本与一个 Unix Bash 脚本，用于在事件响应期在主机全面收集证据
• Live Response Collection - BriMor 开发的 Live Response collection 是一个用于从各种操作系统中收集易失性数据的自动化工具

应急管理

• FIR - Fast Incident Response (FIR) 是一个网络安全应急管理平台，在设计时考虑了敏捷性与速度。其可以轻松创建、跟踪、报告网络安全应急事件并用于 CSIRT、CERT 与 SOC 等人员
• RTIR - Request Tracker for Incident Response (RTIR) 对于安全团队来说是首要的开源应急处理系统，其与世界各地的十多个 CERT 与 CSIRT 合作，帮助处理不断增加的事件报告，RTIR 包含 Request Tracker 的全部功能
• SCOT - Sandia Cyber Omni Tracker (SCOT) 是一个应急响应协作与知识获取工具，为事件响应的过程在不给用户带来负担的情况下增加价值
• threat_note - 一个轻量级的调查笔记，允许安全研究人员注册、检索他们需要的 IOC 数据

Linux 发行版

• ADIA - Appliance for Digital Investigation and Analysis (ADIA) 是一个基于 VMware 的应用程序，用于进行数字取证。其完全由公开软件构建，包含的工具有 Autopsy/Sleuth Kit/Digital Forensics Framework/log2timeline/Xplico/Wireshark 大多数系统维护使用 Webmin。可在各种系统下进行使用
• CAINE - Computer Aided Investigative Environment (CAINE) 包含许多帮助调查人员进行分析的工具，包括取证工具
• DEFT - Digital Evidence & Forensics Toolkit (DEFT) 是一个用于计算机取证的 Linux 发行版，它与 Windows 上的 Digital Advanced Response Toolkit (DART) 捆绑在一起。DEFT 的轻量版被成为 DEFT Zero
• NST - Network Security Toolkit - 包括大量的优秀开源网络安全应用程序的 Linux 发行版
• PALADIN - PALADIN 是一个附带许多开源取证工具的改 Linux 发行版，用于在法庭上以正确的方式执行取证任务
• Security Onion - Security Onion 是一个特殊的 Linux 发行版，旨在利用高级的分析工具进行网络安全监控
• SIFT Workstation - SANS Investigative Forensic Toolkit (SIFT) 使用优秀开源工具以实现高级事件响应与入侵深度数字取证，这些功能免费提供，并且经常更新

Linux 证据收集

• FastIR Collector Linux - FastIR 在 Linux 系统上收集不同的信息并将结果存入 CSV 文件

日志分析工具

• Lorg - 一个用 HTTPD 日志进行高级安全分析与取证的工具

内存分析工具

• Evolve - Volatility 内存取证框架的 Web 界面
• inVtero.net - 支持 hypervisor 的 Windows x64 高级内存分析
• KnTList - 计算机内存分析工具
• LiME - LiME 是 Loadable Kernel Module (LKM)，可以从 Linux 以及基于 Linux 的设备采集易失性内存数据
• Memoryze - 由 Mandiant 开发的 Memoryze 是一个免费的内存取证软件，可以帮助应急响应人员在内存中定位恶意部位， Memoryze 也可以分析内存镜像或者装成带有许多分析插件的系统
• Memoryze for Mac - Memoryze for Mac 是 Memoryze 但仅限于 Mac，且功能较少
• Rekall - 用于从 RAM 中提取样本的开源工具
• Responder PRO - Responder PRO 是一个工业级的物理内存及自动化恶意软件分析解决方案
• Volatility - 高级内存取证框架
• VolatilityBot - VolatilityBot 是一个自动化工具，帮助研究员减少在二进制程序提取解析阶段的手动任务，或者帮助研究人员进行内存分析调查的第一步
• WindowsSCOPE - 一个用来分析易失性内存的取证与逆向工程工具，被用于对恶意软件进行逆向分析，提供了分析 Windows 内核/驱动程序/DLL/虚拟与物理内存的功能

内存镜像工具

• Belkasoft Live RAM Capturer - 轻量级取证工具，即使有反调试/反转储的系统保护下也可以方便地提取全部易失性内存的内容
• Linux Memory Grabber - 用于 dump Linux 内存并创建 Volatility 配置文件的脚本
• Magnet RAM Capture - Magnet RAM Capture 是一个免费的镜像工具，可以捕获可疑计算机中的物理内存，支持最新版的 Windows
• OSForensics - OSForensics 可以获取 32/64 位系统的实时内存，可以将每个独立进程的内存空间 dump 下来

OSX 证据收集

• Knockknock - 显示那些在 OSX 上被设置为自动执行的那些脚本、命令、程序等
• OSX Auditor - OSX Auditor 是一个面向 Mac OS X 的免费计算机取证工具
• OSX Collector - OSX Auditor 的实时响应版

其他工具

• Cortex - Cortex 可以通过 Web 界面逐个或批量对 IP 地址/邮件地址/URL/域名/文件哈希的分析，还可以使用 REST API 来自动执行这些操作
• Crits - 一个将分析引擎与网络威胁数据库相结合且带有 Web 界面的工具
• Fenrir - Fenrir 是一个简单的 IOC 扫描器，可以在纯 bash 中扫描任意 Linux/Unix/OSX 系统，由 THOR 与 LOKI 的开发者创作
• Fileintel - 为每个文件哈希值提供情报
• Hindsight - Google Chrome/Chromium 的互联网
• Hostintel - 为每个主机提供情报
• Kansa - Kansa 是一个 PowerShell 的模块化应急响应框架
• rastrea2r - 使用 YARA 在 Windows、Linux 与 OS X 上扫描硬盘或内存
• RaQet - RaQet 是一个非常规的远程采集与分类工具，允许对那些为取证构建的操作系统进行远端计算机的遴选
• Stalk - 收集关于 MySQL 的取证数据
• SearchGiant - 从云服务中获取取证数据的命令行程序
• Stenographer - Stenographer 是一个数据包捕获解决方案，旨在快速将全部数据包转储到磁盘中，然后提供对这些数据包的快速访问。它存储尽可能多的历史记录并且管理磁盘的使用情况，在磁盘受限被触发时执行既定策略，非常适合在事件发生前与发生中捕获流量，而不是显式存储所有流量
• traceroute-circl - 由 Computer Emergency Responce Center Luxembourg 开发的 traceroute-circl 是一个增强型的 traceroute 来帮助 CSIRT/CERT 的工作人员，通常 CSIRT 团队必须根据收到的 IP 地址处理事件
• X-Ray 2.0 - 一个用来向反病毒厂商提供样本的 Windows 实用工具(几乎不再维护)

Playbooks

• Demisto Playbooks Collection - Playbook 收集
• IR Workflow Gallery - 不同的通用事件响应工作流程，例如恶意软件爆发/数据窃取/未经授权的访问等，每个工作流程都有七个步骤:准备/检测/分析/遏制/根除/恢复/事后处理
• PagerDuty Incident Response Documentation - 描述 PagerDuty 应急响应过程的文档，不仅提供了关于事件准备的信息，还提供了在此前与之后要做什么工作，源在 GitHub 上

进程 Dump 工具

• Microsoft User Mode Process Dumper - 用户模式下的进程 dump 工具，可以 dump 任意正在运行的 Win32 进程内存映像
• PMDump - PMDump 是一个可以在不停止进程的情况下将进程的内存内容 dump 到文件中的工具

沙盒／逆向工具

• Cuckoo - 开源沙盒工具
• Cuckoo-modified - 社区基于 Cuckoo 的大修版
• Cuckoo-modified-api - 一个用来控制 Cuckoo 沙盒设置的 Python 库
• Hybrid-Analysis - Hybrid-Analysis 是一个由 Payload Security 提供的免费在线沙盒
• Malwr - Malwr 是由 Cuckoo 沙盒提供支持的一个免费在线恶意软件分析服务
• Mastiff - MASTIFF 是一个静态分析框架，可以自动化的从多种文件格式中提取关键特征
• Viper - Viper 是一个基于 Python 的二进制程序分析及管理框架，支持 Cuckoo 与 YARA
• Virustotal - Virustotal， Google 的子公司，一个免费在线分析文件/URL的厂商，可以分析病毒/蠕虫/木马以及其他类型被反病毒引擎或网站扫描器识别的恶意内容
• Visualize_Logs - Cuckoo、Procmon等日志的开源可视化库

时间线工具

• Highlighter - Fire/Mandiant 开发的免费工具，用来分析日志/文本文件，可以对某些关键字或短语进行高亮显示，有助于时间线的整理
• Plaso - 一个基于 Python 用于 log2timeline 的后端引擎
• Timesketch - 协作取证时间线分析的开源工具

视频

• Demisto IR video resources - 应急响应与取证分析的视频资源
• The Future of Incident Response - Bruce Schneier 在 OWASP AppSecUSA 2015 上的分享

Windows 证据收集

• AChoir - Achoir 是一个将对 Windows 的实时采集工具脚本化变得更标准与简单的框架
• Binaryforay - 一个 Windows 取证的免费工具列表 (http://binaryforay.blogspot.co.il/)
• Crowd Response - 由 CrowdStrike 开发的 Crowd Response 是一个轻量级 Windows 终端应用，旨在收集用于应急响应与安全操作的系统信息，其包含许多模块与输出格式
• FastIR Collector - FastIR Collector 在 Windows 系统中实时收集各种信息并将结果记录在 CSV 文件中，通过对这些信息的分析，我们可以发现早期的入侵痕迹
• FECT - Fast Evidence Collector Toolkit (FECT) 是一个轻量级的应急响应工具集，用于在可疑的 Windows 计算机上取证，它可以让非技术调查人员更专业的进行应急处理
• Fibratus - 利用与跟踪 Windows 内核的工具
• IOC Finder - IOC Finder 是由 Mandiant 开发的免费工具，用来收集主机数据并报告存在危险的 IOC
• Fidelis ThreatScanner - Fidelis ThreatScanner 是一个由 Fidelis Cybersecurity 开发的免费工具，使用 OpenIOC 和 YARA 来报告终端设备的安全状态，ThreatScanner 衡量系统的运行状态后会出具匹配情况的报告，仅限 Windows
• LOKI - Loki 是一个使用 YARA 与其他 IOC 对终端进行扫描的免费 IR 扫描器
• PowerForensics - PowerShell 开发的实时硬盘取证框架
• PSRecon - PSRecon 使用 PowerShell 在远程 Windows 主机上提取/整理数据，并将数据发送到安全团队，数据可以通过邮件来传送数据或者在本地留存
• RegRipper - Regripper 是用 Perl 编写的开源工具，可以从注册表中提取/解析数据(键/值/数据)提供分析
• TRIAGE-IR - Triage-IR 是一个 Windows 下的 IR 收集工具

（题图来自：securityledger.com）

完美阅读及发表评论，请猛击：https://linux.cn/article-8412-1.html?utm_source=rss&utm_medium=rss

最近几年中，面向数据的设计已经受到了很多的关注 —— 一种强调内存中数据布局的编程风格，包括如何访问以及将会引发多少的 cache 缺失。由于在内存读取操作中缺失所占的数量级要大于命中的数量级，所以缺失的数量通常是优化的关键标准。这不仅仅关乎那些对性能有要求的 code-data 结构设计的软件，由于缺乏对内存效益的重视而成为软件运行缓慢、膨胀的一个很大因素。

高效缓存数据结构的中心原则是将事情变得平滑和线性。比如，在大部分情况下，存储一个序列元素更倾向于使用普通数组而不是链表 —— 每一次通过指针来查找数据都会为 cache 缺失增加一份风险；而普通数组则可以预先获取，并使得内存系统以最大的效率运行

如果你知道一点内存层级如何运作的知识，下面的内容会是想当然的结果——但是有时候即便它们相当明显，测试一下任不失为一个好主意。几年前 Baptiste Wicht 测试过了 std::vector vs std::list vs std::deque，（后者通常使用分块数组来实现，比如：一个数组的数组）。结果大部分会和你预期的保持一致，但是会存在一些违反直觉的东西。作为实例：在序列链表的中间位置做插入或者移除操作被认为会比数组快，但如果该元素是一个 POD 类型，并且不大于 64 字节或者在 64 字节左右（在一个 cache 流水线内），通过对要操作的元素周围的数组元素进行移位操作要比从头遍历链表来的快。这是由于在遍历链表以及通过指针插入/删除元素的时候可能会导致不少的 cache 缺失，相对而言，数组移位则很少会发生。（对于更大的元素，非 POD 类型，或者你已经有了指向链表元素的指针，此时和预期的一样，链表胜出）

多亏了类似 Baptiste 这样的数据，我们知道了内存布局如何影响序列容器。但是关联容器，比如 hash 表会怎么样呢？已经有了些权威推荐：Chandler Carruth 推荐的带局部探测的开放寻址（此时，我们没必要追踪指针），以及Mike Acton 推荐的在内存中将 value 和 key 隔离（这种情况下，我们可以在每一个 cache 流水线中得到更多的 key）， 这可以在我们必须查找多个 key 时提高局部性能。这些想法很有意义，但再一次的说明：测试永远是好习惯，但由于我找不到任何数据，所以只好自己收集了。

测试

我测试了四个不同的 quick-and-dirty 哈希表实现，另外还包括 std::unordered_map 。这五个哈希表都使用了同一个哈希函数 —— Bob Jenkins 的 SpookyHash（64 位哈希值）。（由于哈希函数在这里不是重点，所以我没有测试不同的哈希函数；我同样也没有检测我的分析中的总内存消耗。）实现会通过简短的代码在测试结果表中标注出来。

• UM： std::unordered_map 。在 VS2012 和 libstdc++-v3 （libstdc++-v3: gcc 和 clang 都会用到这东西）中，UM 是以链表的形式实现，所有的元素都在链表中，bucket 数组中存储了链表的迭代器。VS2012 中，则是一个双链表，每一个 bucket 存储了起始迭代器和结束迭代器；libstdc++ 中，是一个单链表，每一个 bucket 只存储了一个起始迭代器。这两种情况里，链表节点是独立申请和释放的。最大负载因子是 1 。
• Ch：分离的、链状 buket 指向一个元素节点的单链表。为了避免分开申请每一个节点，元素节点存储在普通数组池中。未使用的节点保存在一个空闲链表中。最大负载因子是 1。
• OL：开地址线性探测 —— 每一个 bucket 存储一个 62 bit 的 hash 值，一个 2 bit 的状态值（包括 empty，filled，removed 三个状态），key 和 vale 。最大负载因子是 2/3。
• DO1：“data-oriented 1” —— 和 OL 相似，但是哈希值、状态值和 key、values 分离在两个隔离的平滑数组中。
• DO2：“data-oriented 2” —— 与 OL 类似，但是哈希/状态，keys 和 values 被分离在 3 个相隔离的平滑数组中。

在我的所有实现中，包括 VS2012 的 UM 实现，默认使用尺寸为 2 的 n 次方。如果超出了最大负载因子，则扩展两倍。在 libstdc++ 中，UM 默认尺寸是一个素数。如果超出了最大负载因子，则扩展为下一个素数大小。但是我不认为这些细节对性能很重要。素数是一种对低 bit 位上没有足够熵的低劣 hash 函数的挽救手段，但是我们正在用的是一个很好的 hash 函数。

OL，DO1 和 DO2 的实现将共同的被称为 OA（open addressing）——稍后我们将发现它们在性能特性上非常相似。在每一个实现中，单元数从 100 K 到 1 M，有效负载（比如：总的 key + value 大小）从 8 到 4 k 字节我为几个不同的操作记了时间。 keys 和 values 永远是 POD 类型，keys 永远是 8 个字节（除了 8 字节的有效负载，此时 key 和 value 都是 4 字节）因为我的目的是为了测试内存影响而不是哈希函数性能，所以我将 key 放在连续的尺寸空间中。每一个测试都会重复 5 遍，然后记录最小的耗时。

测试的操作在这里：

• Fill：将一个随机的 key 序列插入到表中（key 在序列中是唯一的）。
• Presized fill：和 Fill 相似，但是在插入之间我们先为所有的 key 保留足够的内存空间，以防止在 fill 过程中 rehash 或者重申请。
• Lookup：执行 100 k 次随机 key 查找，所有的 key 都在 table 中。
• Failed lookup: 执行 100 k 次随机 key 查找，所有的 key 都不在 table 中。
• Remove：从 table 中移除随机选择的半数元素。
• Destruct：销毁 table 并释放内存。

你可以在这里下载我的测试代码。这些代码只能在 64 机器上编译（包括Windows和Linux）。在 main() 函数顶部附近有一些开关，你可把它们打开或者关掉——如果全开，可能会需要一两个小时才能结束运行。我收集的结果也放在了那个打包文件里的 Excel 表中。（注意： Windows 和 Linux 在不同的 CPU 上跑的，所以时间不具备可比较性）代码也跑了一些单元测试，用来验证所有的 hash 表实现都能运行正确。

我还顺带尝试了附加的两个实现：Ch 中第一个节点存放在 bucket 中而不是 pool 里，二次探测的开放寻址。 这两个都不足以好到可以放在最终的数据里，但是它们的代码仍放在了打包文件里面。

结果

这里有成吨的数据!! 这一节我将详细的讨论一下结果，但是如果你对此不感兴趣，可以直接跳到下一节的总结。

Windows

这是所有的测试的图表结果，使用 Visual Studio 2012 编译，运行于 Windows 8.1 和 Core i7-4710HQ 机器上。

从左至右是不同的有效负载大小，从上往下是不同的操作（注意：不是所有的Y轴都是相同的比例！）我将为每一个操作总结一下主要趋向。

Fill：

在我的 hash 表中，Ch 稍比任何的 OA 变种要好。随着哈希表大小和有效负载的加大，差距也随之变大。我猜测这是由于 Ch 只需要从一个空闲链表中拉取一个元素，然后把它放在 bucket 前面，而 OA 不得不搜索一部分 bucket 来找到一个空位置。所有的 OA 变种的性能表现基本都很相似，当然 DO1 稍微有点优势。

在小负载的情况，UM 几乎是所有 hash 表中表现最差的 —— 因为 UM 为每一次的插入申请（内存）付出了沉重的代价。但是在 128 字节的时候，这些 hash 表基本相当，大负载的时候 UM 还赢了点。因为，我所有的实现都需要重新调整元素池的大小，并需要移动大量的元素到新池里面，这一点我几乎无能为力；而 UM 一旦为元素申请了内存后便不需要移动了。注意大负载中图表上夸张的跳步！这更确认了重新调整大小带来的问题。相反，UM 只是线性上升 —— 只需要重新调整 bucket 数组大小。由于没有太多隆起的地方，所以相对有效率。

Presized fill：

大致和 Fill 相似，但是图示结果更加的线性光滑，没有太大的跳步（因为不需要 rehash ），所有的实现差距在这一测试中要缩小了些。大负载时 UM 依然稍快于 Ch，问题还是在于重新调整大小上。Ch 仍是稳步少快于 OA 变种，但是 DO1 比其它的 OA 稍有优势。

Lookup：

所有的实现都相当的集中。除了最小负载时，DO1 和 OL 稍快，其余情况下 UM 和 DO2 都跑在了前面。（LCTT 译注： 你确定？）真的，我无法描述 UM 在这一步做的多么好。尽管需要遍历链表，但是 UM 还是坚守了面向数据的本性。

顺带一提，查找时间和 hash 表的大小有着很弱的关联，这真的很有意思。 哈希表查找时间期望上是一个常量时间，所以在的渐进视图中，性能不应该依赖于表的大小。但是那是在忽视了 cache 影响的情况下！作为具体的例子，当我们在具有 10 k 条目的表中做 100 k 次查找时，速度会便变快，因为在第一次 10 k - 20 k 次查找后，大部分的表会处在 L3 中。

Failed lookup：

相对于成功查找，这里就有点更分散一些。DO1 和 DO2 跑在了前面，但 UM 并没有落下，OL 则是捉襟见肘啊。我猜测，这可能是因为 OL 整体上具有更长的搜索路径，尤其是在失败查询时；内存中，hash 值在 key 和 value 之飘来荡去的找不着出路，我也很受伤啊。DO1 和 DO2 具有相同的搜索长度，但是它们将所有的 hash 值打包在内存中，这使得问题有所缓解。

Remove：

DO2 很显然是赢家，但 DO1 也未落下。Ch 则落后，UM 则是差的不是一丁半点（主要是因为每次移除都要释放内存）；差距随着负载的增加而拉大。移除操作是唯一不需要接触数据的操作，只需要 hash 值和 key 的帮助，这也是为什么 DO1 和 DO2 在移除操作中的表现大相径庭，而其它测试中却保持一致。（如果你的值不是 POD 类型的，并需要析构，这种差异应该是会消失的。）

Destruct：

Ch 除了最小负载，其它的情况都是最快的（最小负载时，约等于 OA 变种）。所有的 OA 变种基本都是相等的。注意，在我的 hash 表中所做的所有析构操作都是释放少量的内存 buffer 。但是 在Windows中，释放内存的消耗和大小成比例关系。（而且，这是一个很显著的开支 —— 申请 ～1 GB 的内存需要 ～100 ms 的时间去释放！）

UM 在析构时是最慢的一个（小负载时，慢的程度可以用数量级来衡量），大负载时依旧是稍慢些。对于 UM 来讲，释放每一个元素而不是释放一组数组真的是一个硬伤。

Linux

我还在装有 Linux Mint 17.1 的 Core i5-4570S 机器上使用 gcc 4.8 和 clang 3.5 来运行了测试。gcc 和 clang 的结果很相像，因此我只展示了 gcc 的；完整的结果集合包含在了代码下载打包文件中，链接在上面。

大部分结果和 Windows 很相似，因此我只高亮了一些有趣的不同点。

Lookup：

这里 DO1 跑在前头，而在 Windows 中 DO2 更快些。（LCTT 译注： 这里原文写错了吧？）同样，UM 和 Ch 落后于其它所有的实现——过多的指针追踪，然而 OA 只需要在内存中线性的移动即可。至于 Windows 和 Linux 结果为何不同，则不是很清楚。UM 同样比 Ch 慢了不少，特别是大负载时，这很奇怪；我期望的是它们可以基本相同。

Failed lookup：

UM 再一次落后于其它实现，甚至比 OL 还要慢。我再一次无法理解为何 UM 比 Ch 慢这么多，Linux 和 Windows 的结果为何有着如此大的差距。

Destruct：

在我的实现中，小负载的时候，析构的消耗太少了，以至于无法测量；在大负载中，线性增加的比例和创建的虚拟内存页数量相关，而不是申请到的数量？同样，要比 Windows 中的析构快上几个数量级。但是并不是所有的都和 hash 表有关；我们在这里可以看出不同系统和运行时内存系统的表现。貌似，Linux 释放大内存块是要比 Windows 快上不少（或者 Linux 很好的隐藏了开支，或许将释放工作推迟到了进程退出，又或者将工作推给了其它线程或者进程）。

UM 由于要释放每一个元素，所以在所有的负载中都比其它慢上几个数量级。事实上，我将图片做了剪裁，因为 UM 太慢了，以至于破坏了 Y 轴的比例。

总结

好，当我们凝视各种情况下的数据和矛盾的结果时，我们可以得出什么结果呢？我想直接了当的告诉你这些 hash 表变种中有一个打败了其它所有的 hash 表，但是这显然不那么简单。不过我们仍然可以学到一些东西。

首先，在大多数情况下我们“很容易”做的比 std::unordered_map 还要好。我为这些测试所写的所有实现（它们并不复杂；我只花了一两个小时就写完了）要么是符合 unordered_map 要么是在其基础上做的提高，除了大负载（超过128字节）中的插入性能， unordered_map 为每一个节点独立申请存储占了优势。（尽管我没有测试，我同样期望 unordered_map 能在非 POD 类型的负载上取得胜利。）具有指导意义的是，如果你非常关心性能，不要假设你的标准库中的数据结构是高度优化的。它们可能只是在 C++ 标准的一致性上做了优化，但不是性能。

其次，如果不管在小负载还是超负载中，若都只用 DO1 （开放寻址，线性探测，hashes/states 和 key/vaules分别处在隔离的普通数组中），那可能不会有啥好表现。这不是最快的插入，但也不坏（还比 unordered_map 快），并且在查找，移除，析构中也很快。你所知道的 —— “面向数据设计”完成了！

注意，我的为这些哈希表做的测试代码远未能用于生产环境——它们只支持 POD 类型，没有拷贝构造函数以及类似的东西，也未检测重复的 key，等等。我将可能尽快的构建一些实际的 hash 表，用于我的实用库中。为了覆盖基础部分，我想我将有两个变种：一个基于 DO1，用于小的，移动时不需要太大开支的负载；另一个用于链接并且避免重新申请和移动元素（就像 unordered_map ),用于大负载或者移动起来需要大开支的负载情况。这应该会给我带来最好的两个世界。

与此同时，我希望你们会有所启迪。最后记住，如果 Chandler Carruth 和 Mike Acton 在数据结构上给你提出些建议，你一定要听。

作者简介：

我是一名图形程序员，目前在西雅图做自由职业者。之前我在 NVIDIA 的 DevTech 软件团队中工作，并在美少女特工队工作室中为 PS3 和 PS4 的 Infamous 系列游戏开发渲染技术。

自 2002 年起，我对图形非常感兴趣，并且已经完成了一系列的工作，包括：雾、大气雾霾、体积照明、水、视觉效果、粒子系统、皮肤和头发阴影、后处理、镜面模型、线性空间渲染、和 GPU 性能测量和优化。

你可以在我的博客了解更多和我有关的事，处理图形，我还对理论物理和程序设计感兴趣。

你可以在 nathaniel.reed@gmail.com 或者在 Twitter（@Reedbeta)/Google+ 上关注我。我也会经常在 StackExchange 上回答计算机图形的问题。

via: http://reedbeta.com/blog/data-oriented-hash-table/

作者：Nathan Reed 译者：sanfusu 校对：wxy

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8416-1.html?utm_source=rss&utm_medium=rss

经常有网站管理员因为各种原因和操作，导致网站数据误删，而且又没有做网站备份，结果不知所措，甚至给网站运营和盈利带来负面影响。所以本文我们将和大家一起分享学习下如何通过 MySQL 的二机制日志（binlog）来恢复数据。

系统环境

• 操作系统：CentOS 6.5 X64  (虚拟机)；
• Web 服务：PHP+MySQL+apache；
• 网站：为方便，直接在本地用蝉知系统搭建一个演示站点；

操作步骤

1、开启 binlog 功能及基本操作

要使用 MySQL 的 binlog 日志功能，首先要在 MySQL 的配置文件中开启该功能，操作很简单。找到 MySQL 的配置文件，在文件中添加一行 log_bin = mysql-bin 即可。其实在我安装的各种 MySQL 环境中，该功能通常都是默认开启的。

开启 binlog 功能后，在 MySQL 的数据库目录下就会有诸如 mysql-bin.000001、mysql-bin.000002等文件，这就是 MySQL 的二进制日志文件。每当 MySQL 启动或手动刷新日志后都会新建一个二进制日志文件。

首先我们 MySQL 命令行中，用 show master logs 命令查看已有的 binlog 文件。

2、往站点添加数据

在网站后台文章模块里，我添加了几条测试数据。

3、刷新 binlog 日志

此前 MySQL 的 binlog 文件为 mysql-bin.000001，并且在网站后台往数据库中添加了三篇文章。现在我们刷新 binlog 日志，会生成新的 mysql-bin.000002 文件，如下：

flush logs;
show master logs;

4、删除数据

这里我把刚才添加的三篇文章都删除掉。

5、binlog 日志内容解析

MySQL 的二进制日志文件记录的 MySQL 的操作，比如刚才的删除操作，我们来看下日志文件的具体内容。

使用 MySQL 的 mysqlbinlog 命令：

mysqlbinlog /data/mysql/mysql-bin.000002

注意：因为我本地 mysqlbinlog 无法识别 binlog 配置中的 default-character-set=utf8，所以这里我在命令中加上了 –no-defaults才起作用，大家引以为鉴。

下面是日志内容部分截图：

6、恢复指定数据

在通过 MySQL 的 binlog 日志恢复数据时，我们可以指定恢复到具体时间点，这有点像服务器快照管理。所以我们现在要恢复刚才删除的那篇文章，可以从删除之前找一个时间点，并恢复到那个时间点即可。

有关 mysqlbinlog 命令的使用方法，我们可以通过 mysqlbinlog 的帮助命令进行查看，如下：

mysqlbinlog –no-defaults –help

如帮助文档所示，可以通过指定时间或指定位置来恢复数据，这里我以指定时间为例给大家演示。

我们来查看下日志文件 mysql-bin.000001，如下：

mysqlbinlog -no--defaults /data/mysql/mysql-bin.000001

通过前面操作步骤我们知道，在删除数据之前，我们生成了 mysql-bin.000002 日志文件，所以我们只要恢复到这个时间点即可，上图中我已找到了这个时间。

命令如下：

mysqlbinlog –no-defaults –stop-datetime=’2017-04-11 09:48:48’/data/mysql/mysql-bin.000001 |mysql –uroot –p123456

这时我们在看后台，发现刚才删除的三篇文章都已恢复回来了，从而到达我们期望的目的。

总结

本文和大家分享了如何通过 MySQL 的二进制日志文件恢复数据。但还是要提醒大家，在平时要做好网站数据备份，现在的一些主流 CMS 建站系统都会内置数据库备份功能，比如这里我用的蝉知系统，数据是网站的命脉，做好数据备份以避免后期不必要的麻烦或损失。

完美阅读及发表评论，请猛击：https://linux.cn/article-8417-1.html?utm_source=rss&utm_medium=rss

这是调试器工作原理系列文章的第一篇，我不确定这个系列会有多少篇文章，会涉及多少话题，但我仍会从这篇基础开始。

这一篇会讲什么

我将为大家展示 Linux 中调试器的主要构成模块 - ptrace 系统调用。这篇文章所有代码都是基于 32 位 Ubuntu 操作系统。值得注意的是，尽管这些代码是平台相关的，将它们移植到其它平台应该并不困难。

缘由

为了理解我们要做什么，让我们先考虑下调试器为了完成调试都需要什么资源。调试器可以开始一个进程并调试这个进程，又或者将自己同某个已经存在的进程关联起来。调试器能够单步执行代码，设定断点并且将程序执行到断点，检查变量的值并追踪堆栈。许多调试器有着更高级的特性，例如在调试器的地址空间内执行表达式或者调用函数，甚至可以在进程执行过程中改变代码并观察效果。

尽管现代的调试器都十分的复杂（我没有检查，但我确信 gdb 的代码行数至少有六位数），但它们的工作的原理却是十分的简单。调试器的基础是操作系统与编译器 / 链接器提供的一些基础服务，其余的部分只是简单的编程而已。

Linux 的调试 - ptrace

Linux 调试器中的瑞士军刀便是 ptrace 系统调用（使用 man 2 ptrace 命令可以了解更多）。这是一种复杂却强大的工具，可以允许一个进程控制另外一个进程并从内部替换Peek and poke被控制进程的内核镜像的值（Peek and poke 在系统编程中是很知名的叫法，指的是直接读写内存内容）。

接下来会深入分析。

执行进程的代码

我将编写一个示例，实现一个在“跟踪”模式下运行的进程。在这个模式下，我们将单步执行进程的代码，就像机器码（汇编代码）被 CPU 执行时一样。我将分段展示、讲解示例代码，在文章的末尾也有完整 c 文件的下载链接，你可以编译、执行或者随心所欲的更改。

更进一步的计划是实现一段代码，这段代码可以创建可执行用户自定义命令的子进程，同时父进程可以跟踪子进程。首先是主函数：

int main(int argc, char** argv)
{
    pid_t child_pid;

    if (argc < 2) {
        fprintf(stderr, "Expected a program name as argument\n");
        return -1;
    }

    child_pid = fork();
    if (child_pid == 0)
        run_target(argv[1]);
    else if (child_pid > 0)
        run_debugger(child_pid);
    else {
        perror("fork");
        return -1;
    }

    return 0;
}

看起来相当的简单：我们用 fork 创建了一个新的子进程（这篇文章假定读者有一定的 Unix/Linux 编程经验。我假定你知道或至少了解 fork、exec 族函数与 Unix 信号）。if 语句的分支执行子进程（这里称之为 “target”），else if 的分支执行父进程（这里称之为 “debugger”）。

下面是 target 进程的代码：

void run_target(const char* programname)
{
    procmsg("target started. will run '%s'\n", programname);

    /* Allow tracing of this process */
    if (ptrace(PTRACE_TRACEME, 0, 0, 0) < 0) {
        perror("ptrace");
        return;
    }

    /* Replace this process's image with the given program */
    execl(programname, programname, 0);
}

这段代码中最值得注意的是 ptrace 调用。在 sys/ptrace.h 中，ptrace 是如下定义的：

long ptrace(enum __ptrace_request request, pid_t pid,
                 void *addr, void *data);

第一个参数是 _request_，这是许多预定义的 PTRACE_* 常量中的一个。第二个参数为请求分配进程 ID。第三个与第四个参数是地址与数据指针，用于操作内存。上面代码段中的 ptrace 调用发起了 PTRACE_TRACEME 请求，这意味着该子进程请求系统内核让其父进程跟踪自己。帮助页面上对于 request 的描述很清楚：

意味着该进程被其父进程跟踪。任何传递给该进程的信号（除了 SIGKILL）都将通过 wait() 方法阻塞该进程并通知其父进程。此外，该进程的之后所有调用 exec() 动作都将导致 SIGTRAP 信号发送到此进程上，使得父进程在新的程序执行前得到取得控制权的机会。如果一个进程并不需要它的的父进程跟踪它，那么这个进程不应该发送这个请求。（pid、addr 与 data 暂且不提）

我高亮了这个例子中我们需要注意的部分。在 ptrace 调用后，run_target 接下来要做的就是通过 execl 传参并调用。如同高亮部分所说明，这将导致系统内核在 execl 创建进程前暂时停止，并向父进程发送信号。

是时候看看父进程做什么了。

void run_debugger(pid_t child_pid)
{
    int wait_status;
    unsigned icounter = 0;
    procmsg("debugger started\n");

    /* Wait for child to stop on its first instruction */
    wait(&wait_status);

    while (WIFSTOPPED(wait_status)) {
        icounter++;
        /* Make the child execute another instruction */
        if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {
            perror("ptrace");
            return;
        }

        /* Wait for child to stop on its next instruction */
        wait(&wait_status);
    }

    procmsg("the child executed %u instructions\n", icounter);
}

如前文所述，一旦子进程调用了 exec，子进程会停止并被发送 SIGTRAP 信号。父进程会等待该过程的发生并在第一个 wait() 处等待。一旦上述事件发生了，wait() 便会返回，由于子进程停止了父进程便会收到信号（如果子进程由于信号的发送停止了，WIFSTOPPED 就会返回 true）。

父进程接下来的动作就是整篇文章最需要关注的部分了。父进程会将 PTRACE_SINGLESTEP 与子进程 ID 作为参数调用 ptrace 方法。这就会告诉操作系统，“请恢复子进程，但在它执行下一条指令前阻塞”。周而复始地，父进程等待子进程阻塞，循环继续。当 wait() 中传出的信号不再是子进程的停止信号时，循环终止。在跟踪器（父进程）运行期间，这将会是被跟踪进程（子进程）传递给跟踪器的终止信号（如果子进程终止 WIFEXITED 将返回 true）。

icounter 存储了子进程执行指令的次数。这么看来我们小小的例子也完成了些有用的事情 - 在命令行中指定程序，它将执行该程序并记录它从开始到结束所需要的 cpu 指令数量。接下来就让我们这么做吧。

测试

我编译了下面这个简单的程序并利用跟踪器运行它：

#include <stdio.h>

int main()
{
    printf("Hello, world!\n");
    return 0;
}

令我惊讶的是，跟踪器花了相当长的时间，并报告整个执行过程共有超过 100,000 条指令执行。仅仅是一条输出语句？什么造成了这种情况？答案很有趣（至少你同我一样痴迷与机器/汇编语言）。Linux 的 gcc 默认会动态的将程序与 c 的运行时库动态地链接。这就意味着任何程序运行前的第一件事是需要动态库加载器去查找程序运行所需要的共享库。这些代码的数量很大 - 别忘了我们的跟踪器要跟踪每一条指令，不仅仅是主函数的，而是“整个进程中的指令”。

所以当我将测试程序使用静态编译时（通过比较，可执行文件会多出 500 KB 左右的大小，这部分是 C 运行时库的静态链接），跟踪器提示只有大概 7000 条指令被执行。这个数目仍然不小，但是考虑到在主函数执行前 libc 的初始化以及主函数执行后的清除代码，这个数目已经是相当不错了。此外，printf 也是一个复杂的函数。

仍然不满意的话，我需要的是“可以测试”的东西 - 例如可以完整记录每一个指令运行的程序执行过程。这当然可以通过汇编代码完成。所以我找到了这个版本的 “Hello, world!” 并编译了它。

section    .text
    ; The _start symbol must be declared for the linker (ld)
    global _start

_start:

    ; Prepare arguments for the sys_write system call:
    ;   - eax: system call number (sys_write)
    ;   - ebx: file descriptor (stdout)
    ;   - ecx: pointer to string
    ;   - edx: string length
    mov    edx, len
    mov    ecx, msg
    mov    ebx, 1
    mov    eax, 4

    ; Execute the sys_write system call
    int    0x80

    ; Execute sys_exit
    mov    eax, 1
    int    0x80

section   .data
msg db    'Hello, world!', 0xa
len equ    $ - msg

当然，现在跟踪器提示 7 条指令被执行了，这样一来很容易区分它们。

深入指令流

上面那个汇编语言编写的程序使得我可以向你介绍 ptrace 的另外一个强大的用途 - 详细显示被跟踪进程的状态。下面是 run_debugger 函数的另一个版本：

void run_debugger(pid_t child_pid)
{
    int wait_status;
    unsigned icounter = 0;
    procmsg("debugger started\n");

    /* Wait for child to stop on its first instruction */
    wait(&wait_status);

    while (WIFSTOPPED(wait_status)) {
        icounter++;
        struct user_regs_struct regs;
        ptrace(PTRACE_GETREGS, child_pid, 0, &regs);
        unsigned instr = ptrace(PTRACE_PEEKTEXT, child_pid, regs.eip, 0);

        procmsg("icounter = %u.  EIP = 0x%08x.  instr = 0x%08x\n",
                    icounter, regs.eip, instr);

        /* Make the child execute another instruction */
        if (ptrace(PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) {
            perror("ptrace");
            return;
        }

        /* Wait for child to stop on its next instruction */
        wait(&wait_status);
    }

    procmsg("the child executed %u instructions\n", icounter);
}

不同仅仅存在于 while 循环的开始几行。这个版本里增加了两个新的 ptrace 调用。第一条将进程的寄存器值读取进了一个结构体中。 sys/user.h 定义有 user_regs_struct。如果你查看头文件，头部的注释这么写到：

/* 这个文件只为了 GDB 而创建
   不用详细的阅读.如果你不知道你在干嘛，
   不要在除了 GDB 以外的任何地方使用此文件  */

不知道你做何感想，但这让我觉得我们找对地方了。回到例子中，一旦我们在 regs 变量中取得了寄存器的值，我们就可以通过将 PTRACE_PEEKTEXT 作为参数、 regs.eip（x86 上的扩展指令指针）作为地址，调用 ptrace ，读取当前进程的当前指令（警告：如同我上面所说，文章很大程度上是平台相关的。我简化了一些设定 - 例如，x86 指令集不需要调整到 4 字节，我的32位 Ubuntu unsigned int 是 4 字节。事实上，许多平台都不需要。从内存中读取指令需要预先安装完整的反汇编器。我们这里没有，但实际的调试器是有的）。下面是新跟踪器所展示出的调试效果：

$ simple_tracer traced_helloworld
[5700] debugger started
[5701] target started. will run 'traced_helloworld'
[5700] icounter = 1\.  EIP = 0x08048080\.  instr = 0x00000eba
[5700] icounter = 2\.  EIP = 0x08048085\.  instr = 0x0490a0b9
[5700] icounter = 3\.  EIP = 0x0804808a.  instr = 0x000001bb
[5700] icounter = 4\.  EIP = 0x0804808f.  instr = 0x000004b8
[5700] icounter = 5\.  EIP = 0x08048094\.  instr = 0x01b880cd
Hello, world!
[5700] icounter = 6\.  EIP = 0x08048096\.  instr = 0x000001b8
[5700] icounter = 7\.  EIP = 0x0804809b.  instr = 0x000080cd
[5700] the child executed 7 instructions

现在，除了 icounter，我们也可以观察到指令指针与它每一步所指向的指令。怎么来判断这个结果对不对呢？使用 objdump -d 处理可执行文件：

$ objdump -d traced_helloworld

traced_helloworld:     file format elf32-i386

Disassembly of section .text:

08048080 <.text>:
 8048080:     ba 0e 00 00 00          mov    $0xe,%edx
 8048085:     b9 a0 90 04 08          mov    $0x80490a0,%ecx
 804808a:     bb 01 00 00 00          mov    $0x1,%ebx
 804808f:     b8 04 00 00 00          mov    $0x4,%eax
 8048094:     cd 80                   int    $0x80
 8048096:     b8 01 00 00 00          mov    $0x1,%eax
 804809b:     cd 80                   int    $0x80

这个结果和我们跟踪器的结果就很容易比较了。

　将跟踪器关联到正在运行的进程

如你所知，调试器也能关联到已经运行的进程。现在你应该不会惊讶，ptrace 通过以 PTRACE_ATTACH 为参数调用也可以完成这个过程。这里我不会展示示例代码，通过上文的示例代码应该很容易实现这个过程。出于学习目的，这里使用的方法更简便（因为我们在子进程刚开始就可以让它停止）。

代码

上文中的简单的跟踪器（更高级的，可以打印指令的版本）的完整c源代码可以在这里找到。它是通过 4.4 版本的 gcc 以 -Wall -pedantic --std=c99 编译的。

结论与计划

诚然，这篇文章并没有涉及很多内容 - 我们距离亲手完成一个实际的调试器还有很长的路要走。但我希望这篇文章至少可以使得调试这件事少一些神秘感。ptrace 是功能多样的系统调用，我们目前只展示了其中的一小部分。

单步调试代码很有用，但也只是在一定程度上有用。上面我通过 C 的 “Hello World!” 做了示例。为了执行主函数，可能需要上万行代码来初始化 C 的运行环境。这并不是很方便。最理想的是在 main 函数入口处放置断点并从断点处开始分步执行。为此，在这个系列的下一篇，我打算展示怎么实现断点。

参考

撰写此文时参考了如下文章：

• Playing with ptrace, Part I
• How debugger works

via: http://eli.thegreenplace.net/2011/01/23/how-debuggers-work-part-1

作者：Eli Bendersky 译者：YYforymj 校对：wxy

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8418-1.html?utm_source=rss&utm_medium=rss

2016 年 Git 发生了 惊天动地 地变化，发布了五大新特性¹ （从 v2.7  到  v2.11 ）和十六个补丁²。189 位作者³贡献了 3676 个提交⁴到 master 分支，比 2015 年多了 15%⁵！总计有 1545 个文件被修改，其中增加了 276799 行并移除了 100973 行⁶。

但是，通过统计提交的数量和代码行数来衡量生产力是一种十分愚蠢的方法。除了深度研究过的开发者可以做到凭直觉来判断代码质量的地步，我们普通人来作仲裁难免会因我们常人的判断有失偏颇。

谨记这一条于心，我决定整理这一年里六个我最喜爱的 Git 特性涵盖的改进，来做一次分类回顾。这篇文章作为一篇中篇推文有点太过长了，所以我不介意你们直接跳到你们特别感兴趣的特性去。

• 完成 git worktree 命令
• 更多方便的 git rebase 选项
• git lfs 梦幻的性能加速
• git diff 实验性的算法和更好的默认结果
• git submodules 差强人意
• git stash 的90 个增强

在我们开始之前，请注意在大多数操作系统上都自带有 Git 的旧版本，所以你需要检查你是否在使用最新并且最棒的版本。如果在终端运行 git --version 返回的结果小于 Git v2.11.0，请立刻跳转到 Atlassian 的快速指南 更新或安装 Git 并根据你的平台做出选择。

[所需的“引用”]

在我们进入高质量内容之前还需要做一个短暂的停顿：我觉得我需要为你展示我是如何从公开文档生成统计信息（以及开篇的封面图片）的。你也可以使用下面的命令来对你自己的仓库做一个快速的 年度回顾！

¹ 2016 年匹配 vX.Y.0 格式的里程碑

$ git for-each-ref --sort=-taggerdate --format \
'%(refname) %(taggerdate)' refs/tags | grep "v\d\.\d*\.0 .* 2016"

² 2016 年匹配 vX.Y.Z 格式的里程碑

$ git for-each-ref --sort=-taggerdate --format '%(refname) %(taggerdate)' refs/tags | grep "v\d\.\d*\.[^0] .* 2016"

³ 2016 年做过提交的贡献者数量

$ git shortlog -s -n --since=2016-01-01 --until=2017-01-01

⁴ 2016 年的提交数量

$ git log --oneline --since=2016-01-01 --until=2017-01-01 | wc -l

⁵ 以及 2015 年的提交数量

$ git log --oneline --since=2015-01-01 --until=2016-01-01 | wc -l

⁶  2016 年添加、删除行数

$ git diff --shortstat `git rev-list -1 --until=2016-01-01 master` \
 `git rev-list -1 --until=2017-01-01 master`

以上的命令是在 Git 的 master 分支运行的，所以不会显示其他出色的分支上没有合并的工作。如果你使用这些命令，请记住提交的数量和代码行数不是应该值得信赖的度量方式。请不要使用它们来衡量你的团队成员的贡献。

现在，让我们开始说好的回顾……

完成 Git 工作树（worktree）

git worktree 命令首次出现于 Git v2.5 ，但是在 2016 年有了一些显著的增强。两个有价值的新特性在 v2.7 被引入：list 子命令，和为二分搜索增加了命令空间的 refs。而 lock/unlock 子命令则是在 v2.10 被引入。

什么是工作树呢？

git worktree 命令允许你同步地检出和操作处于不同路径下的同一仓库的多个分支。例如，假如你需要做一次快速的修复工作但又不想扰乱你当前的工作区，你可以使用以下命令在一个新路径下检出一个新分支：

$ git worktree add -b hotfix/BB-1234 ../hotfix/BB-1234
Preparing ../hotfix/BB-1234 (identifier BB-1234)
HEAD is now at 886e0ba Merged in bedwards/BB-13430-api-merge-pr (pull request #7822)

工作树不仅仅是为分支工作。你可以检出多个里程碑（tag）作为不同的工作树来并行构建或测试它们。例如，我从 Git v2.6 和 v2.7 的里程碑中创建工作树来检验不同版本 Git 的行为特征。

$ git worktree add ../git-v2.6.0 v2.6.0
Preparing ../git-v2.6.0 (identifier git-v2.6.0)
HEAD is now at be08dee Git 2.6

$ git worktree add ../git-v2.7.0 v2.7.0
Preparing ../git-v2.7.0 (identifier git-v2.7.0)
HEAD is now at 7548842 Git 2.7

$ git worktree list
/Users/kannonboy/src/git         7548842 [master]
/Users/kannonboy/src/git-v2.6.0  be08dee (detached HEAD)
/Users/kannonboy/src/git-v2.7.0  7548842 (detached HEAD)

$ cd ../git-v2.7.0 && make

你也使用同样的技术来并行构造和运行你自己应用程序的不同版本。

列出工作树

git worktree list 子命令（于 Git v2.7 引入）显示所有与当前仓库有关的工作树。

$ git worktree list
/Users/kannonboy/src/bitbucket/bitbucket       37732bd [master]
/Users/kannonboy/src/bitbucket/staging         d5924bc [staging]
/Users/kannonboy/src/bitbucket/hotfix-1234     37732bd [hotfix/1234]

二分查找工作树

git bisect 是一个简洁的 Git 命令，可以让我们对提交记录执行一次二分搜索。通常用来找到哪一次提交引入了一个指定的退化。例如，如果在我的 master 分支最后的提交上有一个测试没有通过，我可以使用 git bisect 来贯穿仓库的历史来找寻第一次造成这个错误的提交。

$ git bisect start

# 找到已知通过测试的最后提交
# （例如最新的发布里程碑）
$ git bisect good v2.0.0

# 找到已知的出问题的提交
# （例如在 `master` 上的提示）
$ git bisect bad master

# 告诉 git bisect 要运行的脚本/命令；
# git bisect 会在 “good” 和 “bad”范围内
# 找到导致脚本以非 0 状态退出的最旧的提交
$ git bisect run npm test

在后台，bisect 使用 refs 来跟踪 “good” 与 “bad” 的提交来作为二分搜索范围的上下界限。不幸的是，对工作树的粉丝来说，这些 refs 都存储在寻常的 .git/refs/bisect 命名空间，意味着 git bisect 操作如果运行在不同的工作树下可能会互相干扰。

到了 v2.7 版本，bisect 的 refs 移到了 .git/worktrees/$worktree_name/refs/bisect， 所以你可以并行运行 bisect 操作于多个工作树中。

锁定工作树

当你完成了一颗工作树的工作，你可以直接删除它，然后通过运行 git worktree prune 等它被当做垃圾自动回收。但是，如果你在网络共享或者可移除媒介上存储了一颗工作树，如果工作树目录在删除期间不可访问，工作树会被完全清除——不管你喜不喜欢！Git v2.10 引入了 git worktree lock 和 unlock 子命令来防止这种情况发生。

# 在我的 USB 盘上锁定 git-v2.7 工作树
$ git worktree lock /Volumes/Flash_Gordon/git-v2.7 --reason \
"In case I remove my removable media"

# 当我完成时，解锁（并删除）该工作树
$ git worktree unlock /Volumes/Flash_Gordon/git-v2.7
$ rm -rf /Volumes/Flash_Gordon/git-v2.7
$ git worktree prune

--reason 标签允许为未来的你留一个记号，描述为什么当初工作树被锁定。git worktree unlock 和 lock 都要求你指定工作树的路径。或者，你可以 cd 到工作树目录然后运行 git worktree lock . 来达到同样的效果。

更多 Git 变基（rebase）选项

2016 年三月，Git v2.8 增加了在拉取过程中交互进行变基的命令 git pull --rebase=interactive 。对应地，六月份 Git v2.9 发布了通过 git rebase -x 命令对执行变基操作而不需要进入交互模式的支持。

Re-啥？

在我们继续深入前，我假设读者中有些并不是很熟悉或者没有完全习惯变基命令或者交互式变基。从概念上说，它很简单，但是与很多 Git 的强大特性一样，变基散发着听起来很复杂的专业术语的气息。所以，在我们深入前，先来快速的复习一下什么是变基（rebase）。

变基操作意味着将一个或多个提交在一个指定分支上重写。git rebase 命令是被深度重载了，但是 rebase 这个名字的来源事实上还是它经常被用来改变一个分支的基准提交（你基于此提交创建了这个分支）。

从概念上说，rebase 通过将你的分支上的提交临时存储为一系列补丁包，接着将这些补丁包按顺序依次打在目标提交之上。

对 master 分支的一个功能分支执行变基操作 （git reabse master）是一种通过将 master 分支上最新的改变合并到功能分支的“保鲜法”。对于长期存在的功能分支，规律的变基操作能够最大程度的减少开发过程中出现冲突的可能性和严重性。

有些团队会选择在合并他们的改动到 master 前立即执行变基操作以实现一次快速合并 （git merge --ff <feature>）。对 master 分支快速合并你的提交是通过简单的将 master ref 指向你的重写分支的顶点而不需要创建一个合并提交。

变基是如此方便和功能强大以致于它已经被嵌入其他常见的 Git 命令中，例如拉取操作 git pull 。如果你在本地 master 分支有未推送的提交，运行 git pull 命令从 origin 拉取你队友的改动会造成不必要的合并提交。

这有点混乱，而且在繁忙的团队，你会获得成堆的不必要的合并提交。git pull --rebase 将你本地的提交在你队友的提交上执行变基而不产生一个合并提交。

这很整洁吧！甚至更酷，Git v2.8 引入了一个新特性，允许你在拉取时 交互地 变基。

交互式变基

交互式变基是变基操作的一种更强大的形态。和标准变基操作相似，它可以重写提交，但它也可以向你提供一个机会让你能够交互式地修改这些将被重新运用在新基准上的提交。

当你运行 git rebase --interactive (或 git pull --rebase=interactive)时，你会在你的文本编辑器中得到一个可供选择的提交列表视图。

$ git rebase master --interactive

pick 2fde787 ACE-1294: replaced miniamalCommit with string in test
pick ed93626 ACE-1294: removed pull request service from test
pick b02eb9a ACE-1294: moved fromHash, toHash and diffType to batch
pick e68f710 ACE-1294: added testing data to batch email file

# Rebase f32fa9d..0ddde5f onto f32fa9d (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to
# bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.

注意到每一条提交旁都有一个 pick。这是对 rebase 而言，“照原样留下这个提交”。如果你现在就退出文本编辑器，它会执行一次如上文所述的普通变基操作。但是，如果你将 pick 改为 edit 或者其他 rebase 命令中的一个，变基操作会允许你在它被重新运用前改变它。有效的变基命令有如下几种：

• reword：编辑提交信息。
• edit：编辑提交了的文件。
• squash：将提交与之前的提交（同在文件中）合并，并将提交信息拼接。
• fixup：将本提交与上一条提交合并，并且逐字使用上一条提交的提交信息（这很方便，如果你为一个很小的改动创建了第二个提交，而它本身就应该属于上一条提交，例如，你忘记暂存了一个文件）。
• exec: 运行一条任意的 shell 命令（我们将会在下一节看到本例一次简洁的使用场景）。
• drop: 这将丢弃这条提交。

你也可以在文件内重新整理提交，这样会改变它们被重新应用的顺序。当你对不同的主题创建了交错的提交时这会很顺手，你可以使用 squash 或者 fixup 来将其合并成符合逻辑的原子提交。

当你设置完命令并且保存这个文件后，Git 将递归每一条提交，在每个 reword 和 edit 命令处为你暂停来执行你设计好的改变，并且自动运行 squash， fixup，exec 和 drop 命令。

非交互性式执行

当你执行变基操作时，本质上你是在通过将你每一条新提交应用于指定基址的头部来重写历史。git pull --rebase 可能会有一点危险，因为根据上游分支改动的事实，你的新建历史可能会由于特定的提交遭遇测试失败甚至编译问题。如果这些改动引起了合并冲突，变基过程将会暂停并且允许你来解决它们。但是，整洁的合并改动仍然有可能打断编译或测试过程，留下破败的提交弄乱你的提交历史。

但是，你可以指导 Git 为每一个重写的提交来运行你的项目测试套件。在 Git v2.9 之前，你可以通过绑定 git rebase --interactive 和 exec 命令来实现。例如这样：

$ git rebase master −−interactive −−exec=”npm test”

……这会生成一个交互式变基计划，在重写每条提交后执行 npm test ，保证你的测试仍然会通过：

pick 2fde787 ACE-1294: replaced miniamalCommit with string in test
exec npm test
pick ed93626 ACE-1294: removed pull request service from test
exec npm test
pick b02eb9a ACE-1294: moved fromHash, toHash and diffType to batch
exec npm test
pick e68f710 ACE-1294: added testing data to batch email file
exec npm test

# Rebase f32fa9d..0ddde5f onto f32fa9d (4 command(s))

如果出现了测试失败的情况，变基会暂停并让你修复这些测试(并且将你的修改应用于相应提交)：

291 passing
1 failing

1) Host request "after all" hook:
Uncaught Error: connect ECONNRESET 127.0.0.1:3001
…
npm ERR! Test failed.
Execution failed: npm test
You can fix the problem, and then run
        git rebase −−continue

这很方便，但是使用交互式变基有一点臃肿。到了 Git v2.9，你可以这样来实现非交互式变基：

$ git rebase master -x "npm test"

可以简单替换 npm test 为 make，rake，mvn clean install，或者任何你用来构建或测试你的项目的命令。

小小警告

就像电影里一样，重写历史可是一个危险的行当。任何提交被重写为变基操作的一部分都将改变它的 SHA-1 ID，这意味着 Git 会把它当作一个全新的提交对待。如果重写的历史和原来的历史混杂，你将获得重复的提交，而这可能在你的团队中引起不少的疑惑。

为了避免这个问题，你仅仅需要遵照一条简单的规则：

永远不要变基一条你已经推送的提交！

坚持这一点你会没事的。

完美阅读及发表评论，请猛击：https://linux.cn/article-8419-1.html?utm_source=rss&utm_medium=rss

一些 Fedora 用户把大部分甚至是所有时间花费在了命令行终端上。 终端可让您访问整个系统，以及数以千计的强大的实用程序。 但是，它默认情况下一次只显示一个命令行会话。 即使有一个大的终端窗口，整个窗口也只会显示一个会话。 这浪费了空间，特别是在大型显示器和高分辨率的笔记本电脑屏幕上。 但是，如果你可以将终端分成多个会话呢？ 这正是 tmux 最方便的地方，或者说不可或缺的。

安装并启动 tmux

tmux 应用程序的名称来源于终端（terminal）复用器（muxer）或多路复用器（multiplexer）。 换句话说，它可以将您的单终端会话分成多个会话。 它管理窗口和窗格：

• 窗口（window）是一个单一的视图 - 也就是终端中显示的各种东西。
• 窗格（pane）是该视图的一部分，通常是一个终端会话。

开始前，请在系统上安装 tmux 应用程序。 你需要为您的用户帐户设置 sudo 权限（如果需要，请查看本文获取相关说明）。

sudo dnf -y install tmux

运行 tmux程序：

tmux

状态栏

首先，似乎什么也没有发生，除了出现在终端的底部的状态栏：

底部栏显示：

• [0] – 这是 tmux 服务器创建的第一个会话。编号从 0 开始。tmux 服务器会跟踪所有的会话确认其是否存活。
• 0:testuser@scarlett:~ – 有关该会话的第一个窗口的信息。编号从 0 开始。这表示窗口的活动窗格中的终端归主机名 scarlett 中 testuser 用户所有。当前目录是 ~ (家目录)。
• * – 显示你目前在此窗口中。
• “scarlett.internal.fri” – 你正在使用的 tmux 服务器的主机名。
• 此外，还会显示该特定主机上的日期和时间。

当你向会话中添加更多窗口和窗格时，信息栏将随之改变。

tmux 基础知识

把你的终端窗口拉伸到最大。现在让我们尝试一些简单的命令来创建更多的窗格。默认情况下，所有的命令都以 Ctrl+b 开头。

• 敲 Ctrl+b, " 水平分割当前单个窗格。 现在窗口中有两个命令行窗格，一个在顶部，一个在底部。请注意，底部的新窗格是活动窗格。
• 敲 Ctrl+b, % 垂直分割当前单个窗格。 现在你的窗口中有三个命令行窗格，右下角的窗格是活动窗格。

注意当前窗格周围高亮显示的边框。要浏览所有的窗格，请做以下操作：

• 敲 Ctrl+b，然后点箭头键
• 敲 Ctrl+b, q，数字会短暂的出现在窗格上。在这期间，你可以你想要浏览的窗格上对应的数字。

现在，尝试使用不同的窗格运行不同的命令。例如以下这样的：

• 在顶部窗格中使用 ls 命令显示目录内容。
• 在左下角的窗格中使用 vi 命令，编辑一个文本文件。
• 在右下角的窗格中运行 top 命令监控系统进程。

屏幕将会如下显示:

到目前为止，这个示例中只是用了一个带多个窗格的窗口。你也可以在会话中运行多个窗口。

• 为了创建一个新的窗口，请敲Ctrl+b, c 。请注意，状态栏显示当前有两个窗口正在运行。（敏锐的读者会看到上面的截图。）
• 要移动到上一个窗口，请敲 Ctrl+b, p 。
• 要移动到下一个窗口，请敲 Ctrl+b, n 。
• 要立即移动到特定的窗口，请敲 Ctrl+b 然后跟上窗口编号。

如果你想知道如何关闭窗格，只需要使用 exit 、logout，或者 Ctrl+d 来退出特定的命令行 shell。一旦你关闭了窗口中的所有窗格，那么该窗口也会消失。

脱离和附加

tmux 最强大的功能之一是能够脱离和重新附加到会话。 当你脱离的时候，你可以离开你的窗口和窗格独立运行。 此外，您甚至可以完全注销系统。 然后，您可以登录到同一个系统，重新附加到 tmux 会话，查看您离开时的所有窗口和窗格。 脱离的时候你运行的命令一直保持运行状态。

为了脱离一个会话，请敲 Ctrl+b, d。然后会话消失，你重新返回到一个标准的单一 shell。如果要重新附加到会话中，使用一下命令：

tmux attach-session

当你连接到主机的网络不稳定时，这个功能就像救生员一样有用。如果连接失败，会话中的所有的进程都会继续运行。只要连接恢复了，你就可以恢复正常，就好像什么事情也没有发生一样。

如果这些功能还不够，在每个会话的顶层窗口和窗格中，你可以运行多个会话。你可以列举出这些窗口和窗格，然后通过编号或者名称把他们附加到正确的会话中：

tmux list-sessions

延伸阅读

本文只触及的 tmux 的表面功能。你可以通过其他方式操作会话：

• 将一个窗格和另一个窗格交换
• 将窗格移动到另一个窗口中（可以在同一个会话中也可以在不同的会话中）
• 设定快捷键自动执行你喜欢的命令
• 在 ~/.tmux.conf 文件中配置你最喜欢的配置项，这样每一个会话都会按照你喜欢的方式呈现

有关所有命令的完整说明，请查看以下参考：

• 官方手册页
• tmux 电子书

作者简介：

Paul W. Frields 自 1997 年以来一直是 Linux 用户和爱好者，并于 2003 年加入 Fedora 项目，这个项目刚推出不久。他是 Fedora 项目委员会的创始成员，在文档，网站发布，宣传，工具链开发和维护软件方面都有贡献。他于2008 年 2 月至 2010 年 7 月加入 Red Hat，担任 Fedora 项目负责人，并担任 Red Hat 的工程经理。目前他和妻子以及两个孩子居住在弗吉尼亚。

via: https://fedoramagazine.org/use-tmux-more-powerful-terminal/

作者：Paul W. Frields 译者：Flowsnow 校对：wxy

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8421-1.html?utm_source=rss&utm_medium=rss

GDM（GNOME Desktop Manager）是一种 GNOME 显示环境的管理器，它是一个运行在后台的小程序（脚本），用于运行你的 X 会话，显示一个登录界面并在你正确输入密码后才允许登录。GDM 在各个方面胜出 xdm，也没有 xdm 那么多的漏洞。它没有使用任何来自 xdm 的代码。它支持 XDMCP，并实际上扩展了 XDMCP，带来了一些我认为 xdm 所缺失的功能（但是仍然兼容 xdm 的 XDMCP）。

背景介绍

Linux 对于高分屏的自适应不是很好，使用过程中由于屏幕分辨率较高，系统调整缩放级别系数偏大，直接导致显示窗口过大。我 Google 了相关资料，今天写一篇如何修改 GDM 登录界面和 GNOME 界面的缩放级别系数的教程。

对于高分屏，GDM 登录界面显示很大，GNOME 桌面偶尔可以自适应。

解决方法

GNOME 桌面

我们先介绍一下 GNOME 桌面缩放级别修改方式。

最简单的解决方法是打开 gnome-tweak-tool 看窗口缩放值 scale，将其调整为 1 即可。但是有时候它的值是 1 的情况下屏幕显示还是很大，将其调整为 2 没有任何改变。此时就需要使用 gsettings 命令查看 scale 值发现其实并不是 1，而是 2 。

$ gsettings get org.gnome.desktop.interface scaling-factor
unit32 2

这表示当前缩放级别实际是 2，使用以下命令调整为 1 即可。

$ gsettings set org.gnome.desktop.interface scaling-factor 1

GDM登录界面

好了，重点在这。其实修改方式跟以上方法如出一辙。

配置X服务访问权限：

# xhost +SI:localuser:gdm

打开 dconf 工具直接修改，如果没有 dconf 请先安装：

$ sudo dnf install dconf-editor

$ sudo -u gdm dconf-editor

显示如下界面：

接下去按照路径 /org/gnome/desktop/gnome/interface 进入，下拉滚动条找到 scaling-factor 选项，修改为 1。

此时重启系统，你会发现登录界面再也不是那么丑大！！！

提示： dconf-editor 还可以修改 GDM 的 GTK 主题、图标主题、光标主题、背景。

参考

• GDM wiki

完美阅读及发表评论，请猛击：https://linux.cn/article-8425-1.html?utm_source=rss&utm_medium=rss

2017年，你是否有一个小目标，打算在新的一年事业更上一层楼、代码写的更优美、对互联网生态拥有更多宏观的战略性了解？

小编精心挑选2016云栖大会、历届在线技术峰会、云栖技术直播核心资料，只把最好的呈现给你！因为资料集合过于庞大，所以分批放出，随时关注社区，可以看到全套400余份资料合集哦！

大数据、人工智能、云计算、互联网通用技术……全球技术热点一网打尽，资深专家亲授核心技术。 满足你对各类热点技术的学习需求，下载下来存起来，足够看一年的了！

版权公告：资料版权归属为云栖社区，转载请注明出处。未经允许，不可商用。如发现违规违法使用，保留追究法律责任的权利。

资料获取攻略：使用阿里云账号或淘宝账号登录后，点击感兴趣的资料标题，即可免费下载对应资料。

附上部分资料list，看了心动就快去下载吧>>http://click.aliyun.com/m/17170/

【PDF】《阿里巴巴Java开发手册（正式版）

【PDF】Blink计算引擎——蒋晓伟

【PDF】云上应用Docker化持续交付与微服务实践——易立

【PDF】电商互动营销的技术实现——郑恩阳

【PDF】云数据库十大经典案例总结与反思——罗龙九

【PDF】基于Java容器的多应用部署技术实践——魏鹏

【PDF】基于大数据的全球电商系统架构性能优化——郭东白

【PDF】阿里聚安全在互联网业务中的创新实践——方超

【PDF】企业大数据平台仓库架构建设思路——李金波

【PDF】AliSQL性能优化与功能突破的演进之路——何登成

【PDF】如何让MySQL保持高效的N个好习惯

【PDF】AliSQL行业解决方案和上云案例

【PDF】AliSQL内核定制方案

【PDF】阿里云MongoDB

【PDF】MongoDB多数据中心的方案选型之路

【PDF】MongoDB疑难杂症的分析和优化

【PDF】Terark—重新定义数据技术

【PDF】MongoDB高级设计模式：数据即服务

【PDF】互联网时代，中大型企业云端文件管理最佳实践

【PDF】服务中大型企业：基于PaaS的一体化HR SaaS软件

【PDF】通过SaaS CRM实现中大型企业销售全流程管理

【PDF】GrowingIO 用数据驱动增长的秘密

【PDF】增长和留存的秘密

【PDF】如何由传统增长走向SaaS增长

【PDF】SaaS产品的客户成功之道

【PDF】SaaS企业的三种成长个性

【PDF】聊聊涂鸦、云、硬件和平台那些事

【PDF】React 技术栈在蚂蚁金服的实践

【视频】React 技术栈在蚂蚁金服的实践

【PDF】AliSQL功能特性详解

【视频】AliSQL功能特性详解

【PDF】BeeHive：大型iOS项目解耦实践

【视频】BeeHive：大型iOS项目解耦实践

【PDF】Jstorm开源最佳实践

【视频】Jstorm开源最佳实践

【PDF】Android平台页面路由框架ARouter最佳实践

【视频】Android平台页面路由框架ARouter最佳实践

【PDF】分布式消息引擎Apache RocketMQ最佳实践

【视频】分布式消息引擎Apache RocketMQ最佳实践

【PDF】Freeline：极速编译方案的开源之路

【视频】Freeline：极速编译方案的开源之路

【PDF】由 Weex 谈品牌经营心得

【视频】由Weex谈品牌经营心得

【PDF】基于物流透明的大数据应用

【PDF】智能语音交互：大众身边的AI

【PDF】智变：人工智能革新客服行业的实践

【PDF】视觉大数据智能计算实践——从实验室到真实世界

【PDF】进化：构建基因产业的基础设施

【PDF】服务：数据驱动的基因组分析与解读

【PDF】抗击：大数据分析助力遗传病肿瘤精准医疗

【PDF】DeepStream：GPU加速海量视频数据智能处理

【PDF】区块链电子存证——打造 中国LawTech创新格局

【PDF】法链背后的秘密—— onchain 分布式账本框架

【PDF】Docker技术趋势解读

【PDF】蚂蚁金服在Docker网络技术领域的探索和实践

……

有兴趣的小伙伴可以收藏这个网址>>http://click.aliyun.com/m/17170/

附：Docker学习资料>>http://click.aliyun.com/m/17171/ 

互联网安全知多少，阿里安全专家带你深入背后的技术：

• DDoS攻防原理技术实战

在线观看：http://click.aliyun.com/m/17172/

• 移动APP漏洞风险及解决方案

在线观看：http://click.aliyun.com/m/17173/ 

• 互联网内容安全及防护

在线观看：http://click.aliyun.com/m/17174/

• 互联网业务安全及防护

在线观看：http://click.aliyun.com/m/17175/

完美阅读及发表评论，请猛击：https://linux.cn/article-8423-1.html?utm_source=rss&utm_medium=rss

• 最大  国内最大规模 K8S 生产案例
• 最热  K8S 与深度学习的最佳实践
• 最新  2017 KubeCon 欧洲大会前沿话题
• 最干  K8S 1.6 以及 1.7 特性解析干货

时间：2017 年 4 月 22 日下午

地点：北京海淀区中关村创业大厦二层报告厅

主办：K8S 技术社区、Linux 中国

协办：京东云、百度云、EasyStack、IBM

最大、最新、最热的 K8S 话题分享，K8S GeekGathering 2017 首场极客大趴华丽来袭！ 

3 月 28 日，Kubernetes 1.6 正式发布。3 月 29 日至 30 日，K8S 领域盛会 KubeCon 在德国柏林举办。会议对哪些技术热点进行了讨论？K8S 最新特性有哪些？国内有哪些最佳 K8S 技术实践？K8S 服务深度学习的关键能力有哪些？K8S 如何实现于超大规模生产环境？

由 K8S 技术社区、Linux 中国联合发起的 K8S GeekGathering 2017 上，将有来自京东云、百度云、EasyStack、IBM 的容器技术专家做客现场并分享话题：

【Topic 1】云计算的下一个时代“容器时代”

京东是全球超大规模 K8S 生产实践厂商之一，郭理靖将为您分享京东集团自身在 K8S、容器方面的实践和经验等话题。 

【Topic 2】在 Kubernetes 上使用 PaddlePaddle 进行深度学习

PaddlePaddle 是由百度开发的开源深度学习平台，服务于搜索引擎，在线广告等产品线。而 Kubernetes 所提供的容错，自动伸缩，任务打包与隔离的能力是深度学习产品所必须的。周倜将与我们分享在 Kubernetes 上进行分布式 PaddlePaddle 深度学习训练的话题。

【Topic 3】KubeCon Europe 2017 热门话题分享

3 月 29 日，K8S 领域盛会 KubeCon 在德国柏林举办。现场归来的王后明将为您带来此次 KubeCon 峰会见闻及热门议题：包括 containerd 与 CNCF 的渊源、K8S 平台的无服务器框架、如何用 K8S 作为容器和虚拟机的统一管理平面、如何应对 2 万个 Services 带来的网络性能下降问题等。

【Topic 4】Kubernetes 中的资源管理及调度

3 月 28 日，Kubernetes 1.6 正式发布。该版本中，Kuberentes 可以管理大约5000台主机 ，如何将应用更有效的部署到这些机器中，提高集群的资源使用效率并简化资源管理配置，是 Kuberentes 调度组件的主要目的。马达将为您讲解 Kuberentes 中的调度策略及资源管理能力、1.6 中新增的调度功能和 1.7 中将要实现的调度功能以及以这些功能的应用场景。

扫描二维码参与活动报名！

不能来到现场的朋友，扫描二维码进群可分享嘉宾演讲PPT！

中国第一批 K8S 技术极客集会，因为有你，更加精彩！

完美阅读及发表评论，请猛击：https://linux.cn/article-8420-1.html?utm_source=rss&utm_medium=rss

编者按：本文作者 ManateeLazyCat （王勇），开源软件开发者，是国内的著名 Linux 发行版 Deepin （深度）操作系统的联合创始人，长期领导 Deepin 操作系统的开发。

这几天看到 Ubuntu 放弃 Unity 和 Mir 开发，转向 Gnome 作为默认桌面环境的新闻，作为一个 Linux 十几年的老兵和 Linux 桌面的开发者，内心颇感良多。

Ubuntu 做为全世界 Linux 界的桌面先驱者和创新者，突然宣布放弃自己多年开发的 Unity, 相当于在桌面领域，直接放弃了战斗向微软投降，不仅仅是 Linux 桌面的悲哀，更是对于全球 Linux 黑客坚信 Linux 必胜信心的极大打击。

曾经的 Ubuntu 粉丝

我还记得 2006~2007 年，那时候我还在成都写手机游戏，当时年少轻狂的我，一直幻想自己要做最牛掰的开发者，就像科幻电影里面的黑客一样，无所不能。那时候虽然 Windows 玩的很溜，但是一直都在核心技术外徘徊，不知道如何达到个人目标。

上学的时候玩过 RedHat 6.0, 也装过 KDE/Gnome 的桌面环境，但是系统中的各种问题，比如无法使用输入法、中文字体配置很差，甚至因为显卡驱动的原因都无法正常开机，所以 Linux 对于当年的我来说，就像神话一样，只有顶级黑客才能玩的转的系统。

直到后面用了 Ubuntu 6.10 和 Ubuntu 7.04, 当时的 Ubuntu 可以说是非常惊艳，原来 RedHat 和 Suse 在桌面端的各种细节问题一扫而光，装上系统以后就可以直接用，而且还可以非常容易的安装应用软件来深入学习 Linux。可以说是 Ubuntu 带领我真正的入门了 Linux， 经过很多年的深入学习 Linux, 到后来在 Linux 上开发 Emacs 和 Haskell 相关的项目，直至后面创业做 deepin 操作系统。

从我个人来说，对 Ubuntu 系统以及背后的开发者都是怀着无比的敬畏和崇拜。

我看这么多年 Ubuntu 的发展

Ubuntu 从当年最佳的 Linux 桌面操作系统到今天宣布放弃自己研发的 Unity 桌面，已经有13年历史了，在我看来主要有以下几个阶段：

最初的惊艳

Ubuntu 最初的发展目标就是把原来 Linux 系统需要手动操作的基本配置，比如字体、输入法和显卡驱动等问题内置到操作系统中，用户不用安装系统后还需要跟乱码、中文输入以及显示等问题斗智斗勇， 可以说那个时代的 Ubuntu 是解决了当时 Linux 普及的几个重要问题，把 Linux 系统从当时只有开发者才能玩转的高手系统普及到普通的电脑爱好者就可以折腾使用。

酷炫的 Compiz 管理器

我相信很多 Linux 爱好者都惊叹于当年 Compiz 这个 3D 窗口管理器能够达到的酷炫效果，比如 3D 旋转桌面、拖动窗口的果冻效果、一把火烧掉窗口的效果…… 特别是同时代的 Windows 系统都还是非常原始的 2D 效果，甚至 XP 的窗口连窗口阴影都还没有的时候。当时的 Linux 系统的，特别是 Compiz 吸引大部分用户去尝试 Linux 系统，即使最后大家仅仅只是因为好奇或是玩玩，也大大增强了 Linux 系统的曝光率。

从另外一方面，Linux 从当年 Compiz 发展十年以后，反而是那些简单特效甚至没有特效的 Linux 系统得到最高的用户量，原因我觉得主要有两个：

• PC 这种生产力的工具最重要的是高效，非常酷炫的特效长时间用，反而会极大干扰用户视觉，进而影响用户对内容的专注力，而且时间长了也很容易引起用户的视觉疲劳，反而是 Mac 那种恰到好处的轻微动画让用户感到优雅和舒服, 这方面 Linux 发行版 Elementary OS 做的要好很多
• 任何操作系统需要长久留住用户，还是需要靠优秀的人机交互设计和丰富的应用来留住用户，操作系统只有给用户带来真实的价值，让用户工作更高效和生活更快乐，用户才会长期坚持下去，光靠酷炫的动画吸引，用户一旦视觉疲劳以后，最终还是会放弃 Linux， 因为一个操作系统不能解决用户日常遇到的各种问题，在用户心中最多就是一个好玩的玩具而已

Gnome3 vs Unity

在 2011 年底， Gnome 发布了它最新的 Gnome3 系统， 当时 Gnome3 以酷炫的特效加上 JavaScript 的插件体系而吸引了开源社区开发者的兴趣，特别是 Gnome3 内置 GJS 引擎，可以直接在桌面环境中编写 JavaScript 插件后直接 reload 即可更新桌面环境的功能和视觉效果，还有吊炸天的 inspector 特性，可以直接通过鼠标点击界面后定位到对应的代码位置，再加上 GJS 可以从屏幕顶部打开一个类似 quake terminal 的下拉调试环境，在调试环境中直接像脚本语言那样实时列出任何对象的属性和方法，立即改立即生效。

上面这些开发者特性，在那时候 Google 满天吹嘘 Html5/JavaScript 的美好未来的大环境下，对于开发者有极大的诱惑力，很多开发者都奔着 Gnome3 这些类似 Web 的开发方式而去，并贡献了大量好玩的插件。

在 Gnome3 之前， Ubuntu 一直都在用 Gnome2 桌面环境，其实 Gnome3 在 2011 年发布之前已经规划了 2 年，从当时的宣传来说是下一代桌面环境，2009、2010 年 Gnome3 还在社区发布了大量吊炸天的预览视频。作为当时桌面系统先锋的 Ubuntu 也非常期待能用上 Gnome3。 而无奈 Gnome3 一次又一次跳票，最后 Ubuntu 实在等不及了，就在 Gnome2 桌面环境后台服务的基础之上，开发了自己的 Unity UI。

当时社区也因为 Unity 和 Gnome3 的很多设计理念类似谴责 Ubuntu 在进行分裂行为。

Unity 产品的特点主要定位在几点：

• HUD 的左上角搜索设计，快速搜索应用和很多插件提供的搜索结果，这一点和 Gnome3 的 Launcher 插件体系非常像，通过插件，可以搜索除应用外的更多搜索结果（比如天气、在线视频、计算器结果等）
• 任务栏固定在左边，对宽屏更加优化，相对于程序员有更多的纵向空间
• 全局菜单，通过合并顶部栏和窗口标题栏，进一步节省纵向空间

我个人并不喜欢这些面向开发人员（而不是面向普通用户）的设计，但是撇开个人的主观设计喜好外，我认为 Unity 是相对于  Gnome3 更成熟的产品，Unity 的很多改动都是针对 PC 桌面系统的真实痛点来改进的，特别是一些程序员的用户很喜欢 Unity 诸多设计。而不是像 Gnome3 那样一味的追求平板用户体验，极大降低了 PC 桌面用户的习惯和易用性， Gnome3 的槽点我后面详细说。

不论从商业公司的独立性发展考虑还是产品质量负责的角度，我都是非常支持 Ubuntu 当时独立开发自己 Unity 桌面环境的行为，Unity 确实在随后的几年证明了自己的产品质量和设计细节都比 Gnome3 要好很多。

Wayland vs Mir

在 Gnome3 和 Unity 发展的同时，Intel 的雇员 Kristian Høgsberg 正在领导开发新的显示服务器。Wayland 相对于古老的 X11 来说最大的提升是，Gtk/Qt 这些图形库进行图形绘制时，不用像 X11 那样发送绘制消息到 XServer 来进行绘制，而是由 Client 自己进行图形绘制，Wayland 只用担任图层混合器的作用。这样不但减少了 X Client 和 X Server 之间不必要的通讯，而且因为由 Client 自己进行渲染，所以很多画面撕裂和闪屏的现象从原理上就避免了。

大家可以看一下下面的两张架构图来理解两者的差别：

Wayland 因为要彻底从技术架构上颠覆 Linux 几十年 X11 的渲染方式，不论从架构设计还是代码实现上都会非常复杂，不但要开发协议本身，还需要开发适合 Wayland 的混合器和窗口管理器，最后导致 Wayland 1.0 稳定版一再跳票。

而 Ubuntu 在独立开发 Unity 桌面环境的同时，也仿造了 Wayland 的架构开发了自己的 Mir 显示服务器，除了等不及 Wayland 稳定之外，更重要的是 Ubuntu 为了它的下一步宏伟计划“Ubuntu Touch”。按照 Ubuntu 创始人 Mark 的设想，Mir 不仅仅要像 Wayland 那样从原理上提升 Linux 图形渲染效率，而且 Mir 还得担负起手机和电脑融合的使命，可以让 Ubuntu Touch 的手机在插上显示器底座时，手机的应用通过 Mir 的支持，可以直接在外接显示器上显示手机应用窗口，最终达到“当你手机放到底座时就是电脑，拿走就是手机”的设想。

不论 Wayland 还是 Mir，虽然底层架构都非常先进，但是为了兼容现有的 X11 程序，它们分别开发了 XWayland 和 XMir 用于在新的显示服务器协议上支持现有的大多数 X11 程序（主要是 Gtk2/Qt3/Qt4 开发的大多数应用）。

具有讽刺意味的是，Wayland 和 Mir 本来就是要解决 X11 那种不适合现代 PC 场景繁琐的通讯协议，甚至很多开发者为了技术的洁癖都在大力安利 Wayland/Mir ，但是最后 XWayland 和 XMir 本身的兼容实现却比 X11 的实现更加“恶心”和繁琐，包括 Mir 的开发者最后都放弃了 XMir 的开发。

正是因为 Wayland/Mir 这样的技术无法彻底解决和大部分原本就基于 X11 协议而开发的应用的兼容性问题，最后导致基于 Wayland/Mir 开发的桌面系统从 ”解决渲染性能问题“ 转变到 “无法运行很多现有 Linux 应用”　这一个更加让用户难以接受的结果。这也是后面基于 Mir 开发的新版 Unity 难产的重要原因。

Ubuntu Touch

就像每一个程序员都有一个黑客梦一样，每一个 Linux 开发者都希望能用上纯粹的 Linux 手机操作系统，特别是 Linux 技术圈领域，大家更希望有一个面向开发者可玩性更强的 Linux 手机操作系统。

Mark 从 2011 年宣布开发 Ubuntu Touch 到 2015 年第一只搭载 Ubuntu 的智能手机在欧洲上市，Ubuntu 把大多数主力开发都投入到 Ubuntu Touch 手机操作系统的开发中，整整 4 年，世界上最好的 Linux 桌面开发团队把 4 年的时间浪费在开发一个在 PC、手机、平板和电视上拥有强迫症般统一界面的 Unity 上，而且希望 Ubuntu Touch 能够占领低端的智能手机操作系统市场，或者像 Mark 说的那样在 Android 外给世界另外一个选择。

这 4 年的时间，因为主力开发 Ubuntu Touch 的原因，Ubuntu 桌面操作系统从原来的高速创新到鲜有改动，往往版本的发布就是软件仓库更新加上壁纸更新就发布新版了，不再像原来一样，每个版本都来易用性的提升和功能增强。

而且大家都知道，2011 年 ~ 2015 年这几年正是安卓系统从起步到发展成全球移动操作系统霸主的 ４年，Ubuntu 闭门造车了 ４ 年到 2015 年发布第一台 Ubuntu Touch 手机以来，Ubuntu Touch 手机在全球销售惨淡，甚至无人问津。

Ubuntu 今天放弃自己开发的 Unity 重要原因，就是因为 Ubuntu 耗费了公司所有资源在开发一个用户根本就不会买的手机操作系统，Ubuntu Touch 可以说是 Ubuntu 最愚蠢的决策：

• 今天的手机和手机操作系统的发展就像当年 Wintel 的 PC 时代一样，芯片和硬件越来越快，硬件的快速迭代更新速度都快于软件层面的优化速度，就算最低端的手机性能甚至都比十几年前电脑更快，而手机作为现代消费品来说，用户更关心的是手机是不是新款的，能否打游戏，美颜拍照功能是否更好？智能手机时代，大家不再对低端智能手机感兴趣，所以“低端智能手机操作系统”本身就是一个伪命题
• 智能手机作为最方便的通讯和娱乐工具，能否打游戏和基本应用是大家用一款手机最最最基本的要求了，可 Ubuntu Touch 不能玩游戏、不能上 QQ 和微信，只能打开终端和一些网页应用，不要说普通用户，我想就连那些天天嚷嚷 “我们需要一款 Linux 手机操作系统” 的开发者都不会用它
• 强迫症般的统一设计：在 5 寸大屏的手机，整个任务栏切换全部在左侧，大家可以试一下，你在正常拿手机的情况下，能否方便的用大拇指去够最左侧的 Launcher, 甚至还要在手机左侧的顶部和底部上下移动？把手指移动到手机顶部左右移动查看状态栏（你的手指够的到顶部吗？然后再做左右运动？）也做为一个创新设计宣传，这些反人类的设计是我作为一个产品经理非常无法忍受的，我经常吐槽 Ubuntu Touch：Ubuntu Touch 的交互设计师平常要不就是把手机放到桌子上设计的（而不是单手体验一下），要不就是 Ubuntu Touch 手机是屏幕厂商开的，Ubuntu Touch 的很多交互设计都非常容易让手机从手里面滑落

Ubuntu Touch 不论从公司战略、产品时机、应用生态还是交互设计各方面来看都是非常愚蠢和非常失败的产品，而这一切都要怪罪于 Mark 本人开发者的产品思维和一意孤行，白白浪费了世界顶尖开发者的精力和理想。

FlatPak vs Snap

Linux 桌面发展到今天依然无法和微软以及苹果系统本身竞争的一个重要原因就是，Linux 系统软件包之间的依赖问题，系统和应用之间的紧耦合，应用和应用之间的依赖库紧耦合，只要底层库升级了，系统升级有可能会把应用升级挂，一个应用升级很有可能会导致另外一个应用无法使用。

如果把系统所有的软件包和应用的依赖打印出来，你会发现整个桌面 Linux 操作系统就像一张巨大的错综复杂的蜘蛛网，蜘蛛网的任何一环坏掉都会引起系统和应用不稳定甚至无法使用的问题，同时应用厂商为了开源社区的诸多底层库升级疲于奔命, 最后的结果是，Linux 操作系统在底层 5 万个软件包，2000 多个应用，700 个精品应用的时候，就已经非常非常的不稳定了，如果有一天 Linux 平台有上十万个应用的时候，系统和应用一定是崩溃的，因为任何底层的技术革新都会带来应用厂商的应用会失效或者因为 API 不兼容最后无法运行。

所以，为了迎接将来 Linux 操作系统应用生态爆发的那一天，Linux 操作系统必须像微软和苹果那样，在系统和应用之间构建一条抽象 API 层，有点类似微软的 Win32 API 和 .Net 的意思，只要应用遵守中间层的运行时 API 和接口以及应用之间做到互相隔离开，应用升级就不会影响到其他应用，系统底层做再多规模的底层库革新，只要革新完以后保证中间层调用接口不要变，系统的升级就完全不会影响到应用的稳定。

举一个最简单的例子，微软从 Windows XP 开始，操作系统底层技术一直在变，但是你会发现十几年前应用厂商为 Windows XP 开发的应用依然可以在 Windows 10 最新的操作系统上运行，这种类型的兼容性才是桌面应用生态赖以生存的重要技术保障。

而 Gnome 开发的 FlatPak 和 Ubuntu 开发的 Snap 就是为了解决应用之间的隔离而生的技术，这两个技术都通过 Linux 内核的 cgroups 技术，FlatPak 是通过 OsTree 来解决应用多版本的问题。通过把应用之间隔离在沙盒之内，保证不同应用之间或者应用不同版本之间完全在文件系统上进行隔离，这样就彻底解决应用之间升级互相影响的问题，而且这两种技术通过引入应用程序运行时的 runtime 接口，保证了系统和应用之间有一个稳定的接口，从侧面也保证了系统和应用之间的依赖分离。

FlatPak 和 Snap 都能解决 Linux 系统依赖的问题，FlatPak 的目标是解决 Linux 桌面现有应用的问题，Snap 则是为了解决 Ubuntu Touch 而生的。

听说 Mark 希望 Snap 不但能够运行在 Linux 上，还能运行到别的操作系统上。在我看来这也是一个错误的选择，微软和苹果找就有相关的成熟技术，根本不需要 snap, 反而是 Linux 才需要这样的技术，希望 Ubuntu 能够把 snap 的技术发展壮大，有利于 Linux 操作系统的应用生态。

Gnome 是一个比 Unity 更差的选择

从 Ubuntu 放弃 Unity 的那一刻起，Ubuntu 已经放弃桌面了。很多不了解桌面环境开发的用户会觉得 Ubuntu 不是回归 Gnome 了吗？应该是开源社区的好事啊？

桌面操作系统的用户体验和交互细节息息相关的就是桌面环境，而 Gnome3 桌面环境从各方面来说都不是面向普通用户的高质量产品。

核心开发者更关心技术折腾, 不再关心产品质量和 API 兼容性

Gnome 好的地方是开发了封装了大量基于 GObject 的库，外部开发者能够快速基于这些 GObject 库来开发程序。

但是从开发者的技术选型来说，比如最开始做 vala, gnome shell 的时候做 GJS/JavaScript, 到最近讨论用 rust, 这些都可以看出 Gnome3 的开发者更关注的是实现桌面环境后台的编程语言和技术是否是最酷最新的，追求这个世界上最先进的技术是每个开发者的源动力，但是 Linux 桌面这十几年之所以发展停止不前的重要原因是：用户喜欢一个开箱即用、美观和稳定的桌面系统，用户不关心实现这些的后台技术是否是最屌的。对于真正理想的研发团队，或者真正的顶尖开发者来说，编程语言和最新的开发库只是工具和程序表达方式而已，只要编程能力高，什么程序都是可以开发的。

而 Linux 社区的开发者，大多数开发者本身都是喜欢折腾最新技术的，因为最新的技术对于开发者来说可以学到很多新的知识，他们在新的编程语言和新的技术基础之上能够做出自己的东西，让自己更有价值和快乐，而这些都是非常自然的地方。但是我们应该考虑在先进技术的同时，面向真正的桌面用户做出稳定可靠的产品。

Gnome3 即使面向开发者都是极度不友好的，整个桌面环境就完全在一个 JavaScript 的环境中，中间没有任何整体的 API 设计和插件接口，Gnome3 的插件作者都是通过 Gnome Shell 调试器追踪到一个 JavaScript 的 Object 对象，通过属性链的方式魔改很多对象的属性方式，最后来开发出 Gnome3 的插件。不通过插件 API 接口，而是通过对象的属性来编写的插件，导致只要 Gnome3 的核心代码一改变，或者属性链中的任一一个变量发生了变化，Gnome3 插件就失效了，目前 Gnome3 在线插件的页面也只有 20% 的插件能够在最新版的 Gnome3 环境中安装运行。

Gtk+ 已经无力和 Qt 抗衡

我个人作为 Gtk+ 骨灰粉，也是 Gtk2hs 的核心开发者，对 Gtk+ 2000 多个 API 以及很多 GObject 库（比如vte、webkit、poppler 等）都非常熟悉。但是自从 Gnome3 弄伤心以后（我曾经写了 12 个 Gnome3 插件，１ 万多行代码都因为 Gnome3 各种乱改 API 后升级失效），我对 Gtk+ 的信心也随之大大降低。

特别是 Gtk+3 这个被 Gtk+/Gnome 开发者盛赞的版本，除了添加了一下 Overlay 的控件和 CSS 属性功能外，再没有大的功能改进。反观 Qt, 从 Qt4 时代的各有千秋到 Qt5 的大幅度提升质量和功能，包括最新的 QML 大大提升了图形应用程序的开发（虽然 QML 对显卡兼容性还是有点问题）。

Gtk+ 的很多 API 至今多有很多隐藏的小技巧，需要多年的踏坑经验才能完全掌握，而 Qt 本身的 API 设计要优秀的多。

Gnome3 不是一个产品质量的桌面环境

• JavaScript 本身不适合作为桌面环境这种常驻程序的开发语言，不论在执行速度，特别是在内存的控制上非常容易导致长时间运行不关机，内存越用越多的情况
• Gnome3 除了窗口管理器 mutter 是单独一个进程外，所有的桌面模块（任务栏、顶部条、启动器、工作区）都是在同一个进程中运行，这样就导致只要有任何插件发生错误，整个桌面环境的所有模块都会连带崩溃而无法使用
• Gnome3 的整个设计理念都是面向平板的，比如托盘区域默认隐藏，任务栏要戳一下热点才能显示，启动器图标过于巨大等，这些设计都会严重的影响PC日常使用的习惯和易用性

所以 Gnome3 与其说是不如 Unity 桌面环境（我相信 Ubuntu 的 Mark 也知道），还不如说 Ubuntu 彻底放弃在桌面上的创新和主力研发，彻底向微软投降了。

开源社区 vs 商业产品

从最初的 RedHat 放弃桌面系统，Suse 和微软深入合作，2016 年 Ubuntu 移植 Bash 到 Win10, 到如今 Ubuntu 放弃 Unity 和 Mir 后，这么多年，大家在开源事业上努力奋斗，但是从最开始的斗志昂然到如今的放弃，为什么开源的桌面系统做不好呢？

我个人也在带领团队开发 deepin 操作系统，这么多年开发 Linux 桌面操作系统的经历，我个人对于开源社区和商业产品的理解有几点：

Geek 是这个世界的革命先锋，但不能以 Geek 理念做产品

电脑极客在以飞快的速度在改变世界，正是有这些非常聪明的极客和开源黑客，全世界的科技发展，特别是开源技术的在最近十年获得了极大的发展。

电脑极客在所有人的类型是非常稀少的，这些全世界 1% 的人用各自的聪明才智推动开源运动的发展，包括 Ubuntu 的 CEO Mark 本人也是极客中的极客、曾经的 Debian 开发者，在推动 Ubuntu 初期解决了很多 Linux 桌面易用性的问题。

电脑极客与其说是一种职业，还不如说是一种生活方式，电脑极客希望全世界都像电脑运行那样：刚正不阿、完美、统一的美，没有一丝一毫的例外情况，所有的结果都应该在预计和期望范围。

但是不能用极客的思维去做产品，因为这个世界本质就是混沌的、有各种各样缺陷、更强调社会习惯和协作，而普通用户组成的非电脑社会，更多人只在乎这个社会都在怎么使用电脑？大家在流行使用什么？他们更在于电影明星在用什么，模仿各种潮流，而不在于一个程序员内心在想什么。

Ubuntu 最开始推崇 Unity，是从产品质量和公司的掌控力出发的，开源社区指责的分裂我觉得是不客观的。但是后面为了统一 PC、手机、平板、电视的整个操作界面，所有界面都基于左侧任务栏＋顶部任务栏＋搜索导向的 Unity 启动器来设计的，从极客爱好者来看，这是一种从程序代码到总体实现的一种统一，一种认为世界会赞赏的方式来构建 Ubuntu 系统。

反观我们自己作为一个普通人，我们会怎么对待这几样设备？

• PC: 作为生产力工具，比如要写一个文档，写段代码，做一个复杂的表格和图像时，PC 绝对是生产力的代表，但是因为 PC 大多数都需要一个人在固定的地方长时间的工作，所以现在 PC 不是沦落了，而是专注于工作环境的计算平台，所以 PC 感觉给人很严肃很累，而人做为一个天性懒惰的动物，大多数人是尽量干完工作就离开 PC 的，但是无论如何，PC 作为整个社会的生产力工具，确实必不可少
• 手机：手机作为大家最顺手的工具、玩游戏、聊天、浏览页面等，可以说是现代人的第三只手，大部分时间都离不开手机这种移动计算设备
• 平板：一种非常轻量的电脑，不需要过多的知识，不需要看着密密麻麻的的键盘，只用直觉化的操作即可
• 电视：我能想到的最佳状态就是，躺在沙发上，拿着遥控板，看电影，上下左右确定，这就是最常用的操作

我们认真的总结，即可发现这几个设备的常用交互方式：

• PC： 鼠标＋键盘
• 手机：大拇指
• 平板：食指
• 电视：遥控板

所以电脑极客经常问的一句话 "为什么不做手机操作系统？”，更多的时候是在问 "为什么不能像 PC 那样把别的计算平台做的更加赋予生产力？”，所以当初 Ubuntu Touch 追求的　“同一套 Unity 界面，让不同的计算平台用统一套界面和交互设计来满足”，这本身就是一个伪命题，或者说是电脑极客自己的一厢情愿。

这几个计算平台不论从使用场景、用户交互习惯还是用户对这些计算设备的期望都完全不同，当初微软融合电脑和平板本身，都已经让喜欢 PC 的用户大大不爽，最后迫使微软停止融合的设计，改回最初的 PC 操作设计。而 Ubuntu 所有计算平台的操作融合更是错的非常离谱，当第一代 Ubuntu Touch 手机推出市场后，先不论应用的稀缺，光是操作系统就和主流的　“看到图标就点，返回就按 Home 键”　的主流手机操作系统截然不同，最后惨淡收场。

所以，极客本身是世界革命的科技先锋，但是不能用极客思维去做产品，因为极客毕竟还是这个世界上的非常少数的人，极客思维本身无法代表更为广泛的普通用户。

底层技术的革新需要采用温水煮青蛙的方式，而不是激进的踏进沙漠去构建大海

很多人经常问我　“deepin 什么时候用 wayland?" ，我首先想回答的是　“合适的时候就会用”，但是我更想回答的是　”deepin 只会推动稳定的技术和产品给用户，而不是拿用户当小白鼠”。

Wayland 和 Mir 本身都是非常革新的显示技术，我相信也是 Linux 未来显示技术的主流，但是作为现阶段来说，Wayland 依然不是一个稳定的产品级方案：
１、显卡厂商原来都是基于 X11 的 libGL 进行驱动编写的，虽然现在很多显卡厂商也在往 Wayland 迁移，但是整体的显卡驱动兼容性还不如 X11, 直接的问题就是，一旦用了 Wayland 后，桌面系统会相对于 X11 更容易遇到花屏和无法登入图形界面的情况
２、Wayland 本身就是对于 X11 协议是一种颠覆，大量的现有 Linux 程序依然是 Gtk+2/Qt4 开发的，这些应用程序依然无法在 Wayland 运行，而新的 Gtk+3/Qt5 虽然都已经对 Wayland 进行了支持，但是这类应用还非常少，导致移植到 Wayland 会有大量的应用程序无法使用，虽然有 XWayland 项目，但应用兼容性和重写的问题短期之内还不会有很大的改善
３、在 X86 这种 CPU 性能过剩的平台，Wayland 的性能提升并不明显，最起码普通用户无法察觉这种性能提升，我认为 Wayland 现阶段更适合那种能够完全控制显卡和应用本身，并且对渲染性能特别敏感的计算平台，不适合 PC 这种开放式的高性能计算平台

在显卡厂商逐渐支持 Wayland 改善显卡驱动的情况下，在 Linux 桌面，我觉得应该大力把桌面环境已经应用迁移到 Gtk+3/Qt5 的图形库上，等有一天显卡厂商驱动兼容性足够好以后，通过修改窗口管理器和移植应用的方式，直接把上层的桌面环境和应用软件整体迁移到 Wayland 上。

当迁移完成后，用户在显卡驱动以及应用方面完全感受不到差异的时候，才能说是负责任和持续的迁移方案。而不是很多开源社区的用户说的先迁移到 Wayland 上去再说，这样会导致使用 Wayland 的时候，让用户同时面临显卡驱动和更加匮乏的应用生态问题。

如果打个比方，整个开源社区是整个世界，革新技术是革命领袖的话。任何一个 Linux 桌面系统从 X11 迁移到 Wayland 更应该考虑策略和渐进的替换方式，而不是一脚踏进沙漠以后要构建整个海洋。任何一项革新的技术除了技术先进性一定要考虑革命时期的群众基础，只有在革新的时候解决用户的问题，得到用户支持，这样的技术革新才能完成底层核心技术的切换，否则就和当年 Intel/HP 大力推崇的安腾 CPU，虽然各种技术先进，但是因为不兼容现有操作系统和应用，最后不得已而抛弃。

安卓生态时代，不要做 Linux 手机操作系统，这不仅仅只是一个技术问题

Linux 桌面面对的是微软的生态帝国，如果拼尽全力，可能还有 1% 的成功可能性。而 Linux 手机操作系统面对安卓的时候，会死的一点都不剩的。

为什么会这么说？因为微软花了几十年构建的生态帝国，是靠当时微软在 PC 行业的势，当时的时势加上微软自身的努力（只有做过操作系统生态的团队才能理解微软当年有多苦逼）做到今天的地步的。做操作系统系统这种承上启下＋白菜钱白粉心的企业一般都是前期是孙子后期是爷的命，前期遇到硬件应用和各种各样奇怪的问题，操作系统厂商各种背锅（为啥别的操作系统没有这个问题？）干各种不是操作系统应该干的活，以一己之力推动整个生态的发展。而现在 PC 的所有生态和需求都已经定型了，微软不会鸟你，也没有各种不懂的媒体跟风干扰你（他们最多就说 PC 是夕阳产业，哈哈），你和你的团队只需要一点一点的努力，用十倍于微软苦逼的努力，只要在某些行业和开源社区做出成绩，就会有用户认同你，PC 再夕阳大家也不可能离开它，因为生产力是整个社会最基本的动力，大家都用手机和平板办公，整个社会的生产力就会成倍的降低，所以大家离不开 PC，我经常会讽刺那些说 PC 没用，平板才是未来的朋友：　“你用平板写代码或者你们公司的财务用平板给你算工资，我就愿意相信你”　。

移动终端本身就是面向普通老百姓的新一代计算设备，在这个行业，所有的人，所有的企业都在围绕安卓构建新的应用，面临一个日新月异更新换代的行业，对于操作系统厂商来说，这些不是机会，而是你无法挑战安卓系统的巨大阻碍，而且每天都会更大，因为有更多的开发者和开发厂商自己掏钱投入安卓阵营。人类社会是一个以跟风和模仿为基调的动物群体，当你做的和大多数人都不一样，各种人就会干扰你，导致你无法专心做好操作系统，而且面对一个不断发展的生态，整个行业的切换成本是你现在无法撼动安卓的重要原因，因为安卓构建的不光光是操作系统本身，构建更多的是日益越大的行业投入和切换成本。

反观 PC 行业，在真正有下一代生产力计算平台出现之前（安卓只是娱乐平台），PC 依然是整个社会生产力的核心，大家不可能离开 PC，PC 也不会像很多没有思考能力的人期望的那样消失殆尽。任何 PC 操作系统厂商只要一步一步的花费数十年的时间，终有一天会构建庞大的桌面应用生态，在生产力上和开放源代码上给这个社会带来更多的价值，其实 Mac 系统本身就是一个很好的例子。

PC 操作系统不是未来，但是 PC 操作系统是现代还不可或缺的计算平台，而且 PC 操作系统是全世界对软件工程要求最高的挑战。当一个团队具备实力能够完整构建像微软那样的 PC 操作系统能力和知识积累后，这个团队的实力能够在下一代计算平台掌握绝对的控制力。

大家熟知的励志故事就是：苹果在 PC 被微软打爆以后，用 iPhone 让微软再也爬不起来。

包格式只对系统核心有用，对于应用厂商的无意义

我一直认为包格式是服务器操作系统和桌面操作系统系统核心才需要的东西，因为具有依赖关系的包特别适合构建相互关联的操作系统底层核心库，只要你升级一下核心库，整个操作系统的核心技术就升级了，不用担心冗余和更新问题。

但是包格式对于应用厂商无意义，操作系统站在应用厂商的出发点最应该考虑的是提供一套接口抽象层和应用隔离机制，抽象接口层的目的是分离系统和应用，应用隔离机制的目的是隔离应用之间在文件系统上的依赖。

只有这样，才能真正构建一个 Linux 桌面的生态：

• 抽象层做好以后，操作系统可以在保持接口不变的同时，随意革新操作系统核心技术，而不用担心操作系统升级以后，应用程序无法运行的问题
• 应用隔离机制做好以后，应用厂商的不同版本和不同应用厂商的应用之间不会互相影响
• 开发者不用再写完软件还要考虑构建不同发行版的打包格式，这也是阻碍软件无法在所有 Linux 发行版运行的重要原因

这样做的目的是让彻底解放操作系统厂商，操作系统厂商的开发人员可以把所有精力放在核心技术的开发和应用开发接口的维护上，而不用每天除了开发操作系统还需要打包各种应用软件包。

应用的质量和功能应该由应用厂商自己维护，而不是丢锅给操作系统开发人员，应用的好坏本质上应该通过用户评价和经济刺激让应用厂商自己维护，如果应用长期没有作者维护，用户自然会抛弃应用的，进行自然淘汰，就像 Windows 上的应用，哪个作者更努力做的更好，用户就会越多。

而不是像现在 Linux 发行版的打包人员，固定的几十个人面对着成千上万的应用软件打包工作，不论从工作量还是持续发展来说，这种分担工作量的组织方式本来就是不合理的，如果每个应用都需要操作系统开发人员来维护，固定人数和固定时间面对无穷的应用时，势必会导致精力不够，甚至核心的系统开发者不再给开源社区做贡献时，他维护的应用的更新和质量就会下降，最后损害的还是用户。

所以应用隔离的技术不仅仅只是技术上模仿微软和苹果，而是从社会的生产力上彻底解决工作分担组织的问题，只有把应用的维护工作丢给应用开发者这些直接利益关系者才能持续的推动整个生态的前进，而不仅仅通过开源精神和信仰把所有的维护负担都丢给Linux发行版的开发者。

Linux 桌面的未来在哪里？

说了这么多，Linux 桌面的未来在哪里？

实话实说，我不知道，我要是知道的话，deepin 早已经打败微软了，哈哈哈。

但是从我这么多年开发桌面系统的精力，我总结了几条经验：

• PC 不需要革命性创新，只需满足桌面用户长期的习惯+微创新, 大多数 Linux 发行版自嗨式的折腾后，用户告诉我们他们最需要的 PC 操作系统就是那些尽量满足他们 PC 操作习惯的系统，如果有一些局部的微创新能够形成自己的特色就很好了
• 大力发展应用生态才是王道: Linux 精品应用还在千这个量级，不论自己研发，还是和应用厂商合作开发，抑或通过商业来刺激应用厂商自己开发，才会有越来越多的用户和行业去使用 Linux 操作系统，Linux 桌面要成功，这是最最重要的一个一点，而不仅仅是拿开源作者或学生业余写的软件当做产品去忽悠现代这些越来越挑剔的桌面用户
• Linux 桌面需要更深入的去解决普通用户的问题: 需要针对 Linux 桌面用户的痛点进行更深入的解决，除了上面说的应用外，比如显卡驱动、打印机驱动以及行业应用都是非常必要和重要的
• 更多的用户基数才能引爆 Linux 桌面生态: Ubuntu 聚集了大多数 Linux 开发者，真正的 Linux 桌面成熟，需要面对更为广阔的普通用户需求，只有解决了 10% 以上用户的需求（苹果 Mac 系统也就这个占有率），Linux 桌面才能自豪的说终于成功了

Linux 桌面是世界上最大的软件工程挑战, 也是所有 Linux 爱好者的希望

Linux 桌面以及桌面应用生态的构建是世界上最大的软件工程挑战，几十年各种伟大的开源公司和开源社区在为这个目标努力，我相信只要持续努力，最终可以从希望变成理想成真的。

Ubuntu 今天放弃战斗了，非常可惜一面 Linux 桌面的旗帜倒下了。

做为依然奋斗在 Linux 桌面事业的开发者，想跟未来的开源开发者说一句话：

累了就休息一下，但千万不要放弃！

（题图来自：fannone.com）

完美阅读及发表评论，请猛击：https://linux.cn/article-8426-1.html?utm_source=rss&utm_medium=rss

这是一篇用屏幕截图解释如何在 AWS EC2 Linux 服务器上打开端口的教程。它能帮助你管理 EC2 服务器上特定端口的服务。

AWS（即 Amazon Web Services）不是 IT 世界中的新术语了。它是亚马逊提供的云服务平台。它的免费帐户能为你提供一年的有限免费服务。这是尝试新技术而不用花费金钱的最好的方式之一。

AWS 提供服务器计算作为他们的服务之一，他们称之为 EC（弹性计算）。使用它可以构建我们的 Linux 服务器。我们已经看到了如何在 AWS 上设置免费的 Linux 服务器了。

默认情况下，所有基于 EC2 的 Linux 服务器都只打开 22 端口，即 SSH 服务端口（允许所有 IP 的入站连接）。因此，如果你托管了任何特定端口的服务，则要为你的服务器在 AWS 防火墙上打开相应端口。

同样它的 1 到 65535 的端口是打开的（对于所有出站流量）。如果你想改变这个，你可以使用下面的方法编辑出站规则。

在 AWS 上为你的服务器设置防火墙规则很容易。你能够在几秒钟内为你的服务器打开端口。我将用截图指导你如何打开 EC2 服务器的端口。

步骤 1 ：

登录 AWS 帐户并进入 EC2 管理控制台。进入“网络及安全”Network & Security 菜单下的安全组Security Groups，如下高亮显示：

AWS EC2 管理控制台

步骤 2 :

在安全组Security Groups中选择你的 EC2 服务器，并在 行动Actions 菜单下选择 编辑入站规则Edit inbound rules。

AWS 入站规则菜单

步骤 3:

现在你会看到入站规则窗口。你可以在此处添加/编辑/删除入站规则。这有几个如 http、nfs 等列在下拉菜单中，它们可以为你自动填充端口。如果你有自定义服务和端口，你也可以定义它。

AWS 添加入站规则

比如，如果你想要打开 80 端口，你需要选择：

• 类型：http
• 协议：TCP
• 端口范围：80
• 源：任何来源：打开 80 端口接受来自“任何IP（0.0.0.0/0）”的请求；我的 IP：那么它会自动填充你当前的公共互联网 IP

步骤 4:

就是这样了。保存完毕后，你的服务器入站 80 端口将会打开！你可以通过 telnet 到 EC2 服务器公共域名的 80 端口来检验（可以在 EC2 服务器详细信息中找到）。

你也可以在 ping.eu 等网站上检验。

同样的方式可以编辑出站规则，这些更改都是即时生效的。

via: http://kerneltalks.com/virtualization/how-to-open-port-on-aws-ec2-linux-server/

作者：Shrikant Lavhate 译者：geekpi 校对：jasminepeng

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8422-1.html?utm_source=rss&utm_medium=rss

Inxi 最初是为控制台和 IRC（网络中继聊天）开发的一个强大且优秀的命令行系统信息脚本。可以使用它获取用户的硬件和系统信息，它也用于调试或者社区技术支持工具。

使用 Inxi 可以很容易的获取所有的硬件信息：硬盘、声卡、显卡、网卡、CPU 和 RAM 等。同时也能够获取大量的操作系统信息，比如硬件驱动、Xorg 、桌面环境、内核、GCC 版本，进程，开机时间和内存等信息。

运行在命令行和 IRC 上的 Inxi 输出略有不同，IRC 上会有一些可供用户使用的默认过滤器和颜色选项。支持的 IRC 客户端有：BitchX、Gaim/Pidgin、ircII、Irssi、 Konversation、 Kopete、 KSirc、 KVIrc、 Weechat 和 Xchat 以及其它的一些客户端，它们具有展示内置或外部 Inxi 输出的能力。

在 Linux 系统上安装 Inxi

大多数主流 Linux 发行版的仓库中都有 Inxi ，包括大多数 BSD 系统。

$ sudo apt-get install inxi   [On Debian/Ubuntu/Linux Mint]
$ sudo yum install inxi       [On CentOs/RHEL/Fedora]
$ sudo dnf install inxi       [On Fedora 22+]

在使用 Inxi 之前，用下面的命令查看 Inxi 所有依赖和推荐的应用，以及各种目录，并显示需要安装哪些包来支持给定的功能。

$ inxi --recommends

Inxi 的输出：

inxi will now begin checking for the programs it needs to operate. First a check of the main languages and tools
inxi uses. Python is only for debugging data collection.
---------------------------------------------------------------------------
Bash version: 4.3.42(1)-release
Gawk version: 4.1.3,
Sed version:
Sudo version: 1.8.16
Python version: 2.7.12
---------------------------------------------------------------------------
Test One: Required System Directories (Linux Only).
If one of these system directories is missing, inxi cannot operate:
/proc....................................................................... Present
/sys........................................................................ Present
All the  directories are present.
---------------------------------------------------------------------------
Test Two: Required Core Applications.
If one of these applications is missing, inxi cannot operate:
df (info: partition data)................................................... /bin/df
gawk (info: core tool)...................................................... /usr/bin/gawk
grep (info: string search).................................................. /bin/grep
lspci (info: hardware data)................................................. /usr/bin/lspci
ps (info: process data)..................................................... /bin/ps
readlink.................................................................... /bin/readlink
sed (info: string replace).................................................. /bin/sed
tr (info: character replace)................................................ /usr/bin/tr
uname (info: kernel data)................................................... /bin/uname
wc (info: word character count)............................................. /usr/bin/wc
All the  applications are present.
---------------------------------------------------------------------------
Test Three: Script Recommends for Graphics Features.
NOTE: If you do not use X these do not matter (like a headless server). Otherwise, if one of these applications
is missing, inxi will have incomplete output:
glxinfo (info: -G glx info)................................................. /usr/bin/glxinfo
xdpyinfo (info: -G multi screen resolution)................................. /usr/bin/xdpyinfo
xprop (info: -S desktop data)............................................... /usr/bin/xprop
xrandr (info: -G single screen resolution).................................. /usr/bin/xrandr
All the  applications are present.
---------------------------------------------------------------------------
Test Four: Script Recommends for Remaining Features.
If one of these applications is missing, inxi will have incomplete output:
dig (info: -i first wlan ip default test)................................... /usr/bin/dig
dmidecode (info: -M if no sys machine data; -m memory)...................... /usr/sbin/dmidecode
file (info: -o unmounted file system)....................................... /usr/bin/file
hciconfig (info: -n -i bluetooth data)...................................... /bin/hciconfig
hddtemp (info: -Dx show hdd temp)........................................... /usr/sbin/hddtemp
ifconfig (info: -i ip lan-deprecated)....................................... /sbin/ifconfig
ip (info: -i ip lan)........................................................ /sbin/ip
sensors (info: -s sensors output)........................................... /usr/bin/sensors
strings (info: -I sysvinit version)......................................... /usr/bin/strings
lsusb (info: -A usb audio;-N usb networking)................................ /usr/bin/lsusb
modinfo (info: -Ax,-Nx module version)...................................... /sbin/modinfo
runlevel (info: -I runlevel)................................................ /sbin/runlevel
sudo (info: -Dx hddtemp-user;-o file-user).................................. /usr/bin/sudo
uptime (info: -I uptime (check which package owns Debian)).................. /usr/bin/uptime
All the  applications are present.
---------------------------------------------------------------------------
Test Five: Script Recommends for Remaining Features.
One of these downloaders needed for options -i/-w/-W (-U/-! [11-15], if supported):
wget (info: -i wan ip;-w/-W;-U/-! [11-15] (if supported))................... /usr/bin/wget
curl (info: -i wan ip;-w/-W;-U/-! [11-15] (if supported))................... /usr/bin/curl
All the  applications are present.
---------------------------------------------------------------------------
Test Six: System Directories for Various Information.
(Unless otherwise noted, these are for GNU/Linux systems)
If one of these directories is missing, inxi may have incomplete output:
/sys/class/dmi/id (info: -M system, motherboard, bios)...................... Present
/dev (info: -l,-u,-o,-p,-P,-D disk partition data).......................... Present
/dev/disk/by-label (info: -l,-o,-p,-P partition labels)..................... Present
/dev/disk/by-uuid (info: -u,-o,-p,-P partition uuid)........................ Present
All the  directories are present.
---------------------------------------------------------------------------
Test Seven: System Files for Various Information.
(Unless otherwise noted, these are for GNU/Linux systems)
If one of these files is missing, inxi may have incomplete output:
/proc/asound/cards (info: -A sound card data)............................... Present
/proc/asound/version (info: -A ALSA data)................................... Present
/proc/cpuinfo (info: -C cpu data)........................................... Present
/etc/lsb-release (info: -S distro version data [deprecated])................ Present
/proc/mdstat (info: -R mdraid data)......................................... Present
/proc/meminfo (info: -I memory data)........................................ Present
/etc/os-release (info: -S distro version data).............................. Present
/proc/partitions (info: -p,-P partitions data).............................. Present
/proc/modules (info: -G module data)........................................ Present
/proc/mounts (info: -P,-p partition advanced data).......................... Present
/var/run/dmesg.boot (info: -D,-d disk data [BSD only])...................... Missing
/proc/scsi/scsi (info: -D Advanced hard disk data [used rarely])............ Present
/var/log/Xorg.0.log (info: -G graphics driver load status).................. Present
The following files are missing from your system:
File: /var/run/dmesg.boot
---------------------------------------------------------------------------
All tests completed.

Inxi 工具的基本用法

用下面的基本用法获取系统和硬件的详细信息。

获取 Linux 系统信息

Inix 不加任何选项就能输出下面的信息：CPU 、内核、开机时长、内存大小、硬盘大小、进程数、登录终端以及 Inxi 版本。

$ inxi
CPU~Dual core Intel Core i5-4210U (-HT-MCP-) speed/max~2164/2700 MHz Kernel~4.4.0-21-generic x86_64 Up~3:15 Mem~3122.0/7879.9MB HDD~1000.2GB(20.0% used) Procs~234 Client~Shell inxi~2.2.35

获取内核和发行版本信息

使用 Inxi 的 -S 选项查看本机系统信息（主机名、内核信息、桌面环境和发行版）：

$ inxi -S
System: Host: TecMint Kernel: 4.4.0-21-generic x86_64 (64 bit) Desktop: Cinnamon 3.0.7
Distro: Linux Mint 18 Sarah

获取电脑机型

使用 -M 选项查看机型（笔记本/台式机）、产品 ID 、机器版本、主板、制造商和 BIOS 等信息：

$ inxi -M
Machine:   System: LENOVO (portable) product: 20354 v: Lenovo Z50-70
Mobo: LENOVO model: Lancer 5A5 v: 31900059WIN Bios: LENOVO v: 9BCN26WW date: 07/31/2014

获取 CPU 及主频信息

使用 -C 选项查看完整的 CPU 信息，包括每核 CPU 的频率及可用的最大主频。

$ inxi -C
CPU:       Dual core Intel Core i5-4210U (-HT-MCP-) cache: 3072 KB
clock speeds: max: 2700 MHz 1: 1942 MHz 2: 1968 MHz 3: 1734 MHz 4: 1710 MHz

获取显卡信息

使用 -G 选项查看显卡信息，包括显卡类型、显示服务器、系统分辨率、GLX 渲染器和 GLX 版本等等（LCTT 译注： GLX 是一个 X 窗口系统的 OpenGL 扩展）。

$ inxi -G
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
Card-2: NVIDIA GM108M [GeForce 840M]
Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.05hz
GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 11.2.0

获取声卡信息

使用 -A 选项查看声卡信息：

$ inxi -A
Audio:     Card-1 Intel 8 Series HD Audio Controller driver: snd_hda_intel Sound: ALSA v: k4.4.0-21-generic
Card-2 Intel Haswell-ULT HD Audio Controller driver: snd_hda_intel

获取网卡信息

使用 -N 选项查看网卡信息：

$ inxi -N
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be

获取硬盘信息

使用 -D 选项查看硬盘信息（大小、ID、型号）：

$ inxi -D
Drives:    HDD Total Size: 1000.2GB (20.0% used) ID-1: /dev/sda model: ST1000LM024_HN size: 1000.2GB

获取简要的系统信息

使用 -b 选项显示上述信息的简要系统信息：

$ inxi -b
System:    Host: TecMint Kernel: 4.4.0-21-generic x86_64 (64 bit) Desktop: Cinnamon 3.0.7
Distro: Linux Mint 18 Sarah
Machine:   System: LENOVO (portable) product: 20354 v: Lenovo Z50-70
Mobo: LENOVO model: Lancer 5A5 v: 31900059WIN Bios: LENOVO v: 9BCN26WW date: 07/31/2014
CPU:       Dual core Intel Core i5-4210U (-HT-MCP-) speed/max: 2018/2700 MHz
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
Card-2: NVIDIA GM108M [GeForce 840M]
Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.05hz
GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 11.2.0
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
Drives:    HDD Total Size: 1000.2GB (20.0% used)
Info:      Processes: 233 Uptime: 3:23 Memory: 3137.5/7879.9MB Client: Shell (bash) inxi: 2.2.35

获取硬盘分区信息

使用 -p 选项输出完整的硬盘分区信息，包括每个分区的分区大小、已用空间、可用空间、文件系统以及文件系统类型。

$ inxi -p
Partition: ID-1: / size: 324G used: 183G (60%) fs: ext4 dev: /dev/sda10
ID-2: swap-1 size: 4.00GB used: 0.00GB (0%) fs: swap dev: /dev/sda9

获取完整的 Linux 系统信息

使用 -F 选项查看可以完整的 Inxi 输出（安全起见比如网络 IP 地址信息没有显示，下面的示例只显示部分输出信息）：

$ inxi -F
System:    Host: TecMint Kernel: 4.4.0-21-generic x86_64 (64 bit) Desktop: Cinnamon 3.0.7
Distro: Linux Mint 18 Sarah
Machine:   System: LENOVO (portable) product: 20354 v: Lenovo Z50-70
Mobo: LENOVO model: Lancer 5A5 v: 31900059WIN Bios: LENOVO v: 9BCN26WW date: 07/31/2014
CPU:       Dual core Intel Core i5-4210U (-HT-MCP-) cache: 3072 KB
clock speeds: max: 2700 MHz 1: 1716 MHz 2: 1764 MHz 3: 1776 MHz 4: 1800 MHz
Graphics:  Card-1: Intel Haswell-ULT Integrated Graphics Controller
Card-2: NVIDIA GM108M [GeForce 840M]
Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa) Resolution: 1920x1080@60.05hz
GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 11.2.0
Audio:     Card-1 Intel 8 Series HD Audio Controller driver: snd_hda_intel Sound: ALSA v: k4.4.0-21-generic
Card-2 Intel Haswell-ULT HD Audio Controller driver: snd_hda_intel
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: 28:d2:44:eb:bd:98
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
IF: wlp2s0 state: down mac: 38:b1:db:7c:78:c7
Drives:    HDD Total Size: 1000.2GB (20.0% used) ID-1: /dev/sda model: ST1000LM024_HN size: 1000.2GB
Partition: ID-1: / size: 324G used: 183G (60%) fs: ext4 dev: /dev/sda10
ID-2: swap-1 size: 4.00GB used: 0.00GB (0%) fs: swap dev: /dev/sda9
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 56.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 234 Uptime: 3:26 Memory: 3188.9/7879.9MB Client: Shell (bash) inxi: 2.2.35

使用 Inxi 工具监控 Linux 系统

下面是监控 Linux 系统进程、开机时间和内存的几个选项的使用方法。

监控 Linux 进程的内存使用

使用下面的命令查看进程数、开机时间和内存使用情况：

$ inxi -I
Info:      Processes: 232 Uptime: 3:35 Memory: 3256.3/7879.9MB Client: Shell (bash) inxi: 2.2.35

监控进程占用的 CPU 和内存资源

Inxi 默认显示 前 5 个最消耗 CPU 和内存的进程。 -t 选项和 c 选项一起使用查看前 5 个最消耗 CPU 资源的进程，查看最消耗内存的进程使用 -t 选项和 m 选项； -t选项 和 cm 选项一起使用显示前 5 个最消耗 CPU 和内存资源的进程。

----------------- Linux CPU Usage -----------------
$ inxi -t c
Processes: CPU: % used - top 5 active
1: cpu: 53.7% command: plugin-container pid: 3066
2: cpu: 20.0% command: java pid: 1527
3: cpu: 19.7% command: firefox pid: 3018
4: cpu: 4.6% command: Xorg pid: 2114
5: cpu: 3.0% command: cinnamon pid: 2835

----------------- Linux Memoery Usage -----------------
$ inxi -t m
Processes: Memory: MB / % used - Used/Total: 3212.5/7879.9MB - top 5 active
1: mem: 980.51MB (12.4%) command: plugin-container pid: 3066
2: mem: 508.96MB (6.4%) command: java pid: 1527
3: mem: 507.89MB (6.4%) command: firefox pid: 3018
4: mem: 244.05MB (3.0%) command: chrome pid: 7405
5: mem: 211.46MB (2.6%) command: chrome pid: 6146

----------------- Linux CPU and Memory Usage -----------------
$ inxi -t cm
Processes: CPU: % used - top 5 active
1: cpu: 53.7% command: plugin-container pid: 3066
2: cpu: 20.0% command: java pid: 1527
3: cpu: 19.7% command: firefox pid: 3018
4: cpu: 4.6% command: Xorg pid: 2114
5: cpu: 3.0% command: cinnamon pid: 2835
Memory: MB / % used - Used/Total: 3223.6/7879.9MB - top 5 active
1: mem: 991.93MB (12.5%) command: plugin-container pid: 3066
2: mem: 508.96MB (6.4%) command: java pid: 1527
3: mem: 507.86MB (6.4%) command: firefox pid: 3018
4: mem: 244.45MB (3.1%) command: chrome pid: 7405
5: mem: 211.68MB (2.6%) command: chrome pid: 6146

可以在选项 cm 后跟一个整数（在 1-20 之间）设置显示多少个进程，下面的命令显示了前 10 个最消耗 CPU 和内存的进程：

$ inxi -t cm10
Processes: CPU: % used - top 10 active
1: cpu: 53.4% command: plugin-container pid: 3066
2: cpu: 19.8% command: java pid: 1527
3: cpu: 19.5% command: firefox pid: 3018
4: cpu: 4.5% command: Xorg pid: 2114
5: cpu: 3.0% command: cinnamon pid: 2835
6: cpu: 2.8% command: chrome pid: 7405
7: cpu: 1.1% command: pulseaudio pid: 2733
8: cpu: 1.0% command: soffice.bin pid: 7799
9: cpu: 0.9% command: chrome pid: 5763
10: cpu: 0.5% command: chrome pid: 6179
Memory: MB / % used - Used/Total: 3163.1/7879.9MB - top 10 active
1: mem: 976.82MB (12.3%) command: plugin-container pid: 3066
2: mem: 511.70MB (6.4%) command: java pid: 1527
3: mem: 466.01MB (5.9%) command: firefox pid: 3018
4: mem: 244.40MB (3.1%) command: chrome pid: 7405
5: mem: 203.71MB (2.5%) command: chrome pid: 6146
6: mem: 199.74MB (2.5%) command: chrome pid: 5763
7: mem: 168.30MB (2.1%) command: cinnamon pid: 2835
8: mem: 165.51MB (2.1%) command: soffice.bin pid: 7799
9: mem: 158.91MB (2.0%) command: chrome pid: 6179
10: mem: 151.83MB (1.9%) command: mysqld pid: 1259

监控网络设备

下面的命令会列出网卡信息，包括接口信息、网络频率、mac 地址、网卡状态和网络 IP 等信息。

$ inxi -Nni
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
IF: enp1s0 state: up speed: 100 Mbps duplex: full mac: 28:d2:44:eb:bd:98
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
IF: wlp2s0 state: down mac: 38:b1:db:7c:78:c7
WAN IP: 111.91.115.195 IF: wlp2s0 ip-v4: N/A
IF: enp1s0 ip-v4: 192.168.0.103

监控 CPU 温度和电脑风扇转速

可以使用 -s 选项监控 配置了传感器的机器 获取温度和风扇转速：

$ inxi -s
Sensors:   System Temperatures: cpu: 53.0C mobo: N/A
Fan Speeds (in rpm): cpu: N/A

用 Linux 查看天气预报

使用 -w 选项查看本地区的天气情况（虽然使用的 API 可能不是很可靠），使用 -W <different_location> 设置另外的地区。

$ inxi -w
Weather:   Conditions: 93 F (34 C) - smoke Time: February 20, 1:38 PM IST
$ inxi -W Mumbai,India
Weather:   Conditions: 93 F (34 C) - smoke Time: February 20, 1:38 PM IST
$ inxi -W Nairobi,Kenya
Weather:   Conditions: 70 F (21 C) - Mostly Cloudy Time: February 20, 11:08 AM EAT

查看所有的 Linux 仓库信息

另外，可以使用 -r 选项查看一个 Linux 发行版的仓库信息：

$ inxi -r
Repos:     Active apt sources in file: /etc/apt/sources.list.d/dawidd0811-neofetch-xenial.list
deb http://ppa.launchpad.net/dawidd0811/neofetch/ubuntu xenial main
deb-src http://ppa.launchpad.net/dawidd0811/neofetch/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/dhor-myway-xenial.list
deb http://ppa.launchpad.net/dhor/myway/ubuntu xenial main
deb-src http://ppa.launchpad.net/dhor/myway/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/official-package-repositories.list
deb http://packages.linuxmint.com sarah main upstream import backport
deb http://archive.ubuntu.com/ubuntu xenial main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu xenial-backports main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu/ xenial-security main restricted universe multiverse
deb http://archive.canonical.com/ubuntu/ xenial partner
Active apt sources in file: /etc/apt/sources.list.d/qbittorrent-team-qbittorrent-stable-xenial.list
deb http://ppa.launchpad.net/qbittorrent-team/qbittorrent-stable/ubuntu xenial main
deb-src http://ppa.launchpad.net/qbittorrent-team/qbittorrent-stable/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/slgobinath-safeeyes-xenial.list
deb http://ppa.launchpad.net/slgobinath/safeeyes/ubuntu xenial main
deb-src http://ppa.launchpad.net/slgobinath/safeeyes/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/snwh-pulp-xenial.list
deb http://ppa.launchpad.net/snwh/pulp/ubuntu xenial main
deb-src http://ppa.launchpad.net/snwh/pulp/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/twodopeshaggy-jarun-xenial.list
deb http://ppa.launchpad.net/twodopeshaggy/jarun/ubuntu xenial main
deb-src http://ppa.launchpad.net/twodopeshaggy/jarun/ubuntu xenial main
Active apt sources in file: /etc/apt/sources.list.d/ubuntu-mozilla-security-ppa-xenial.list
deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu xenial main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu xenial main

下面是查看 Inxi 的安装版本、快速帮助和打开 man 主页的方法，以及更多的 Inxi 使用细节。

$ inxi -v   #显示版本信息
$ inxi -h   #快速帮助
$ man inxi  #打开 man 主页

浏览 Inxi 的官方 GitHub 主页 https://github.com/smxi/inxi 查看更多的信息。

Inxi 是一个功能强大的获取硬件和系统信息的命令行工具。这也是我使用过的最好的 获取硬件和系统信息的命令行工具 之一。

写下你的评论。如果你知道其他的像 Inxi 这样的工具，我们很高兴和你一起讨论。

作者简介：

Aaron Kili 是一个 Linux 和 F.O.S.S 的狂热爱好者，即任的 Linux 系统管理员，web 开发者，TecMint 网站的专栏作者，他喜欢使用计算机工作，并且乐于分享计算机技术。

via: http://www.tecmint.com/inxi-command-to-find-linux-system-information/

作者：Aaron Kili 译者：vim-kakali 校对：wxy

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8424-1.html?utm_source=rss&utm_medium=rss

不管什么是在什么事情上，你所期待的结果，都是通过尽心设计才能得到的。所以，有拖延症的各位亲们，切莫把所有都拖到最后一分钟才去考虑解决方案哦，不然会死的很惨的。

译者简介：

GHLandy —— 生活中所有欢乐与苦闷都应藏在心中，有些事儿注定无人知晓，自己也无从说起。

via: http://turnoff.us/geek/the-depressed-developer-14/

作者：Daniel Stori 译者：GHLandy 校对：wxy 合成：GHLandy 点评：GHLandy

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8415-1.html?utm_source=rss&utm_medium=rss

深度操作系统是一个致力于为全球用户提供美观易用、安全可靠的 Linux 发行版。

深度操作系统 15.4 采用全新设计的控制中心以及重构桌面，模糊透明整体风格，全新的热区交互及窗口管理器动效，集成精挑细选的桌面壁纸；采用全屏化安装方式和升级最新稳定的内核版本，深度系列应用升级到最新版本；新增了繁体中文（香港）和阿姆哈拉语，台湾繁体改成正體中文。

全新设计，赏心悦目

全新的控制中心设计和交互，首页展示快速入口、常用快捷设置等，让操作更加方便和快捷；天气详情、通知中心通过插件展示，今后会开放插件接口，让您可以更多的参与定制。

智能安装，流畅体验

集成全新设计的安装器，采用全屏化操作、模糊化背景、智能化检测、贴心式提醒、扫码式反馈等，让安装的过程也变成一种享受。只需一杯咖啡的时间，便可体验不一样的精彩。

内核升级，更多兼容

新版内核升级至 4.9.8 版本，集成更多的驱动和硬件，提高系统稳定性和兼容性；让越来越多的设备能够得到更好的支持。

字体重绘，告别弹窗

重绘 MT Extra 和 webdings 图形字体并默认集成到系统中，从此告别打开WPS文档提示弹窗的烦恼。

窗管美化，多指触控

优化窗口管理器交互效果，默认工作区支持不同壁纸。系统默认集成触摸板多指手势功能，从此告别鼠标。

热区优化，精美壁纸

全新桌面热区的交互体验，新增演示动画向导，从此避免桌面误触发；集成全新的桌面壁纸，在壁纸桌面中领略大山大水领略世界的美。

在此，感谢独立摄影师@王金裕为深度操作系统 15.4 正式版提供精美高清的壁纸。

更多细节优化

任务栏

• 新增 24/12 小时制切换功能；
• 优化任务栏 UI 细节（菜单和 tooltip 的背景统一变模糊）；
• 优化图标显示，解决图标显示模糊的问题；
• 修复图标可能找不到的问题；
• 修复调节声音可能导致崩溃的问题；

控制中心

• 全新的毛玻璃加列表显示设计；
• 新增天气预报、通知中心；
• 新增试验性的远程投射功能；
• 新增首页快捷入口功能（声音、亮度、网络、蓝牙、投射等）；
• 新增记录 NumLock 状态的功能；
• 新增图标主题和光标主题；
• 解决按下 Capslock 导致窗口失去焦点问题；
• 优化键盘布局切换快捷键实现；
• 优化启动速度、内存占用情况；
• 优化多屏配置交互、彻底解决双屏交互逻辑问题；
• 优化时区选择交互逻辑，解决夏令时等问题；

桌面

• 对桌面进行重构，解决桌面操作中的逻辑问题；
• 优化桌面热区的交互体验；
• 修复设置壁纸程序缩略图可能跟实际壁纸不对应的问题；
• 修复在智能隐藏模式下切换任务栏遇到桌面图标未自动避让的问题；
• 修复桌面上文件夹和应用图标直接使用 Enter 键不能打开的问题；

启动器

• 优化启动器图标的显示效果；
• 启动器字体跟随系统字体大小；
• 优化启动器界面相关细节；

窗口管理器

• 新增多工作区设置不同壁纸的功能；
• 新增工作区切换的提示效果，切换工作区更加方便；
• 新增窗口背景毛玻璃效果支持；
• 界面细节更加丰富、交互更加流畅；
• 修复切换卡死等严重 bug；

其他

• 预装深度录屏；
• 预装深度录音；
• 预装最新的思源宋体；
• 预装福昕阅读器（中英文）；
• 预装新的 XServer 版本和驱动；
• 预装基于 CrossOver 16 的 QQ 8.9 版本；
• 统一登录界面、锁屏与系统的界面风格；
• 修复了 Steam 无法更新的问题；
• 修复了 BCM4322 等无线网卡无法使用的问题。

简单获取，轻松安装

只需一杯咖啡的时间，即可体验深度操作系统给您带来的无限魅力！

请您下载深度操作系统镜像，并观看安装视频教程，借助深度启动盘制作工具即可轻轻松松的将系统安装至您的电脑。

官方下载点：

64位：点此下载 （MD5值）

说明：深度操作系统 15.4 版本将不再对社区提供非商业用途的 32 位操作系统镜像下载。如果您需要获取针对 32 位操作系统的商业支持，请发送邮件至 tech@deepin.com 寻求有偿的商业支持。

其他下载点（同步中）：

百度云、Sourceforge、MEGA、Google Drive、社区ISO仓库

提示：深度操作系统 15.3版本可通过“控制中心→系统信息”将系统升级至最新版本。

崇尚自由，分享快乐

深度操作系统是一款针对普通用户而发行的开源桌面系统，您可自由下载、分发、修改和使用。

详情地址为 GitHub：https://github.com/linuxdeepin

欢迎您关注我们的微博、微信（深度操作系统）、Twitter和Facebook，以第一时间获取最新动态，同时也欢迎您前往我们的论坛，与我们交流和分享您的快乐。

最后，我们郑重感谢为深度操作系统提供测试、文档、翻译和镜像支持的社区团队与企业，感谢你们的无私的贡献，开源有你们更精彩！

完美阅读及发表评论，请猛击：https://linux.cn/article-8427-1.html?utm_source=rss&utm_medium=rss

自从 4 月 5 号 Canonical 宣布放弃 Unity 8 转投 GNOME 之后，开源社区就对此议论纷纷，赞成者有之，惋惜者有之。

然而，有很多人没有注意到，就在 Ubuntu 17.04 发布的前一天（13 日），Canonical 现任 CEO Jane Silber 下台，由 Ubuntu 创始人 Mark Shuttleworth 重新接过了她的职位，而 Jane Silber 则会在董事会任职，并负责社区事务。这背后所代表的意味，或许说明了 Canonical 对过去这几年的战略方向的反思和调整。与之同时的是，Canonical 内部的部门裁撤和人员的离开。

但无论社区是如何看待的， Ubuntu 17.04 还是在次日不慌不忙地陆续发布，就在我们以为 GNOME 成为 Ubuntu 主发行版本要在一年以后才能见分晓时，Canonical 内部却呈现加速逃离 Unity 8 的情形：

Ubuntu GNOME 风味版在 17.04 的发布公告中表示它们将和主发行版版本融合，现有的 Ubuntu GNOME 用户以后将升级到 Ubuntu 上（其实还是 GNOME）。

不过这似乎还不足以代表其转投 GNOME 的迫切心，Ubuntu 桌面开发团队已经在 IRC 中讨论，在 17.10 就转到 GNOME，这比原计划的 18.04 LTS 要早一个发布版本。事实上，他们除了已经准备发布的 Ubuntu 17.10 alpha 1 实在是来不及了，alpha 2 就会默认使用 GNOME 了。

但这还不是最快的。最快的是另外一个不太引人注目的 Ubuntu 官方风味版本，国内人可能知道的多一点的“优麒麟”（Ubuntu Kylin），这个发行版在 17.04 发布时，就决定抛弃 Unity 桌面，而是使用了一个基于 MATE 的自己设计的 UKUI 桌面。并且，据闻优麒麟将在 18.04 脱离 Ubuntu 主要分支行列，自己干了！

而 Kubuntu 仍旧不温不火地发布着 KDE Plasma 5.9 ，表示“我就看看”；新升级为官方分支的 Ubuntu Budgie 还沉浸在去掉“-remix”后缀而转正成功的喜悦之中，对大人们的事情表示不懂。

Canonical 放弃辛苦开发了几年的 Unity，重新投入到 GNOME 怀抱，是否代表着 Canonical 要减少在桌面和移动互联网上的投入、加大在云和物联网方面的力度？以及将来的发展如何，让我们拭目以待。

完美阅读及发表评论，请猛击：https://linux.cn/article-8428-1.html?utm_source=rss&utm_medium=rss

阿里云在美国奥斯汀投下了容器技术领域的一枚“重磅炸弹”。

美国中部时间 4 月 19 日，在容器技术领域年度风向标—— DockerCon 2017 上，阿里云飞天敏捷版（Apsara Stack Agility）正式对外发布。 

Docker 公司首席执行官 Ben Golub 在大会上宣布 Docker 在阿里云平台的 飞天敏捷版Apsara Stack Agility中落地，这是国内第一个支持 Docker 官方企业版（Docker Enterprise Edition）（EE）的容器类产品，可以部署在企业自有数据中心环境内，特别适用于企业专有云及混合云场景。

Ben 在演讲中提及阿里巴巴电商平台已经全面容器化，能够部署和管控超过几十万容器规模，在双 11 狂欢节稳定支撑了每秒175000 次的订单交易。阿里云不但是 Docker 的业务伙伴，同时也将为 Docker 带来大规模容器应用的实践经验。

阿里云是 Docker 公司在中国的首家合作伙伴。深受开发人员追捧的 Docker Hub 服务将于近期在国内推出，阿里云也将和 Docker 携手帮助容器技术在国内企业落地，推动业务创新。

Docker 是一个容器管理引擎。到目前，推出了 Docker 社区版（Docker Community Edition）（CE）和Docker 企业版（Docker Enterprise Edition） （EE）。Docker 企业版在社区版上增加了面向企业用户的管理和安全能力，同时提供了经过认证的操作系统、容器和插件。Docker 企业版在国内由阿里云和 Docker 联合提供技术支持，为企业客户提供稳定、安全、可以信赖的容器应用平台。

2015 年，阿里云在 Docker 社区版的基础上推出了阿里云容器服务。包括华大基因、上海证券公司、中信集团在内的十余家知名企业均是容器服务的客户。

此次推出的飞天敏捷版是面向企业专有云的云应用平台，它不仅支持 Docker 企业版所提供的企业级安全、管理功能，更集成了诸多阿里大规模使用容器的经验，DevOps 能力等。

阿里云首席架构师唐洪介绍：

“通过飞天底层基础设置管理、安全以及日志等功能，企业能实现高等级的安全和稳定的服务保障。“

据了解，阿里巴巴集团内部运用容器技术已有六年时间。2016 年阿里电商核心应用的基础平台全部转向 Docker，并通过天猫双 11 进行了技术验证。

Docker 公司副总裁 Nick Stinemates 表示：

“Docker 企业版与阿里云飞天敏捷版集成之后，将为企业专有云和混合云场景提供更安全、便捷和可用的解决方案。”

飞天敏捷版充分体现了云 + 容器的独特价值。不仅大大了降低容器服务的操作难度，移植性也很强，能在不同环境中进行应用部署。有了它，客户可以在一组云服务器上通过 Docker 容器来进行分布式应用的部署、更新和弹性伸缩，轻松实现混合云方案。当业务出现峰值流量时，快速将本地数据中心应用扩展到云端，利用云资源更好的进行灾备、应对峰值流量。

阿里云容器服务负责人易立表示：

“除了产品技术层面的合作，阿里云还将加大在社区的投入，并通过一系列技术活动提升中国 Docker 技术和应用的水平。“ 

在专有云领域，阿里云此前推出了面向中大型企业的全量云平台 Apsara Stack Enterprise 以及适用于轻量化的大数据客户的 Apsara Stack Insight。合作伙伴 ZStack 公司也推出了轻量化的混合云平台 ZStack For Alibaba Cloud。

完美阅读及发表评论，请猛击：https://linux.cn/article-8429-1.html?utm_source=rss&utm_medium=rss

服务器日志是一个由服务器创建并经常更新、用于抓取特定服务和应用的所有活动信息的日志文件。当你的应用或者服务出现问题时这个文件就会非常有用。从日志文件中你可以获取所有关于该问题的信息，例如基于警告或者错误信息它什么时候开始表现不正常。

LNAV（Log file Navigator）是 Linux 下一个基于控制台的高级日志文件查看器。它和其它文件查看器，例如 cat、more、tail 等，完成相同的任务，但有很多普通文件查看器没有的增强功能（尤其是它自带多种颜色和易于阅读的格式）。

它能在解压多个压缩日志文件（zip、gzip、bzip）的同时把它们合并到一起进行导航。基于消息的时间戳，lnav 能把多个日志文件合并到一个视图（Single Log Review），从而避免打开多个窗口。左边的颜色栏帮助显示消息所属的文件。

警告和错误的数量以（黄色和红色）高亮显示，因此我们能够很轻易地看到问题出现在哪里。它会自动加载新的日志行。

它按照消息时间戳排序显示所有文件的日志消息。顶部和底部的状态栏会告诉你位于哪个日志文件。如果你想按特定的模式查找，只需要在搜索弹窗中输入就会即时显示。

内建的日志消息解析器会自动从每一行中发现和提取详细信息。

当你用一个普通文件查看器打开一个日志文件时，它会用纯文本格式显示所有信息（如果用更直白的话说的话：纯白——黑底白字），这样很难去发现和理解哪里有警告或错误信息。为了克服这种情况，快速找到警告和错误信息来解决问题， lnav 是一个入手可用的更好的解决方案。

大部分常见的 Linux 日志文件都放在 /var/log/。

lnav 自动检测以下日志格式

• Common Web Access Log format（普通 web 访问日志格式）
• CUPS page_log
• Syslog
• Glog
• VMware ESXi/vCenter 日志
• dpkg.log
• uwsgi
• “Generic” – 以时间戳开始的任何消息
• Strace
• sudo
• gzib & bizp

lnav 高级功能

• 单一日志视图 - 基于消息时间戳，所有日志文件内容都会被合并到一个单一视图
• 自动日志格式检测 - lnav 支持大部分日志格式
• 过滤器 - 能进行基于正则表达式的过滤
• 时间线视图
• 适宜打印视图（Pretty-Print）
• 使用 SQL 查询日志
• 自动数据抽取
• 实时操作
• 语法高亮
• Tab 补全
• 当你查看相同文件集时可以自动保存和恢复会话信息。
• Headless 模式

如何在 Linux 中安装 lnav

大部分发行版（Debian、Ubuntu、Mint、Fedora、suse、openSUSE、Arch Linux、Manjaro、Mageia 等等）默认都有 lnav 软件包，在软件包管理器的帮助下，我们可以很轻易地从发行版官方仓库中安装它。对于 CentOS/RHEL 我们需要启用 EPEL 仓库。

[在 Debian/Ubuntu/LinuxMint 上安装 lnav]
$ sudo apt-get install lnav

[在 RHEL/CentOS 上安装 lnav]
$ sudo yum install lnav

[在 Fedora 上安装 lnav]
$ sudo dnf install lnav

[在 openSUSE 上安装 lnav]
$ sudo zypper install lnav

[在 Mageia 上安装 lnav]
$ sudo urpmi lnav

[在基于 Arch Linux 的系统上安装 lnav]
$ yaourt -S lnav

如果你的发行版没有 lnav 软件包，别担心，开发者提供了 .rpm 和 .deb 安装包，因此我们可以轻易安装。确保你从 开发者 github 页面 下载最新版本的安装包。

[在 Debian/Ubuntu/LinuxMint 上安装 lnav]
$ sudo wget https://github.com/tstack/lnav/releases/download/v0.8.1/lnav_0.8.1_amd64.deb
$ sudo dpkg -i lnav_0.8.1_amd64.deb

[在 RHEL/CentOS 上安装 lnav]
$ sudo yum install https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

[在 Fedora 上安装 lnav]
$ sudo dnf install https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

[在 openSUSE 上安装 lnav]
$ sudo zypper install https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

[在 Mageia 上安装 lnav]
$ sudo rpm -ivh https://github.com/tstack/lnav/releases/download/v0.8.1/lnav-0.8.1-1.x86_64.rpm

不带参数运行 lnav

默认情况下你不带参数运行 lnav 时它会打开 syslog 文件。

# lnav

使用 lnav 查看特定日志文件

要用 lnav 查看特定的日志文件，在 lnav 命令后面添加日志文件路径。例如我们想看 /var/log/dpkg.log 日志文件。

# lnav /var/log/dpkg.log

用 lnav 查看多个日志文件

要用 lnav 查看多个日志文件，在 lnav 命令后面逐个添加日志文件路径，用一个空格隔开。例如我们想查看 /var/log/dpkg.log 和 /var/log/kern.log 日志文件。

左边的颜色栏帮助显示消息所属的文件。另外顶部状态栏还会显示当前日志文件的名称。为了显示多个日志文件，大部分应用经常会打开多个窗口、或者在窗口中水平或竖直切分，但 lnav 使用不同的方式（它基于日期组合在同一个窗口显示多个日志文件）。

# lnav /var/log/dpkg.log /var/log/kern.log

使用 lnav 查看压缩的日志文件

要查看并同时解压被压缩的日志文件（zip、gzip、bzip），在 lnav 命令后面添加 -r 选项。

# lnav -r /var/log/Xorg.0.log.old.gz

直方图视图

首先运行 lnav 然后按 i 键切换到/出直方图视图。

查看日志解析器结果

首先运行 lnav 然后按 p 键打开显示日志解析器结果。

语法高亮

你可以搜索任何给定的字符串，它会在屏幕上高亮显示。首先运行 lnav 然后按 / 键并输入你想查找的字符串。为了测试，我搜索字符串 Default，看下面的截图。

Tab 补全

命令窗口支持大部分操作的 tab 补全。例如，在进行搜索时，你可以使用 tab 补全屏幕上显示的单词，而不需要复制粘贴。为了测试，我搜索字符串 /var/log/Xorg，看下面的截图。

via: http://www.2daygeek.com/install-and-use-advanced-log-file-viewer-navigator-lnav-in-linux/

作者：Magesh Maruthamuthu 译者：ictlyh 校对：wxy

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8430-1.html?utm_source=rss&utm_medium=rss

Anbox 以基于容器的方式，在像 Ubuntu 这样的常规的 GNU Linux 系统上启动一个完整的 Android 系统。

概述

Anbox 使用 Linux 命名空间（user、pid、uts、net、mount、ipc）来在容器中运行完整的 Android 系统，并在任何基于 GNU Linux 平台上提供 Android 应用。

容器内的 Android 无法直接访问任何硬件。所有硬件访问都通过主机上的 anbox 守护进程进行。我们重用基于 QEMU 的模拟器实现的 Android 中的 GL、ES 加速渲染。容器内的 Android 系统使用不同的管道与主机系统通信，并通过它发送所有硬件访问命令。

有关更多详细信息，请参考下文档：

• Android 硬件 OpenGL ES 仿真设计概述
• Android QEMU 快速管道
• Android 的 “qemud” 复用守护进程
• Android qemud 服务

Anbox 目前适合桌面使用，但也用在移动操作系统上，如 Ubuntu Touch、Sailfish OS 或 Lune OS。然而，由于 Android 程序的映射目前只针对桌面环境，因此还需要额外的工作来支持其他的用户界面。

Android 运行时环境带有一个基于 Android 开源项目镜像的最小自定义 Android 系统。所使用的镜像目前基于 Android 7.1.1。

安装

目前，安装过程包括一些添加额外组件到系统的步骤。包括：

• 启用用于 binder 和 ashmen 的非发行的树外内核模块。
• 使用 udev 规则为 /dev/binder 和 /dev/ashmem 设置正确权限。
• 能够启动 Anbox 会话管理器作为用户会话的一个启动任务。

为了使这个过程尽可能简单，我们将必要的步骤绑定在一个 snap（见 https://snapcraft.io ） 中，称之为 “anbox-installer”。这个安装程序会执行所有必要的步骤。你可以在所有支持 snap 的系统运行下面的命令安装它。

$ snap install --classic anbox-installer

另外你可以通过下面的命令下载安装脚本。

$ wget https://raw.githubusercontent.com/anbox/anbox-installer/master/installer.sh -O anbox-installer

请注意，我们还不支持除所有 Linux 发行版。请查看下面的章节了解支持的发行版。

运行下面的命令进行安装。

$ anbox-installer

它会引导你完成安装过程。

注意： Anbox 目前处于 pre-alpha 开发状态。不要指望它具有生产环境你需要的所有功能。你肯定会遇到错误和崩溃。如果你遇到了，请不要犹豫并报告它们！

注意： Anbox snap 目前 完全没有约束，因此它只能从边缘渠道获取。正确的约束是我们想要在未来实现的，但由于 Anbox 的性质和复杂性，这不是一个简单的任务。

已支持的 Linux 发行版

目前我们官方支持下面的 Linux 发行版：

• Ubuntu 16.04 (xenial)

未测试但可能支持的：

• Ubuntu 14.04 (trusty)
• Ubuntu 16.10 (yakkety)
• Ubuntu 17.04 (zesty)

安装并运行 Android 程序

从源码构建

要构建 Anbox 运行时不需要特别了解什么，我们使用 cmake 作为构建系统。你的主机系统中应已有下面这些构建依赖：

• libdbus
• google-mock
• google-test
• libboost
• libboost-filesystem
• libboost-log
• libboost-iostreams
• libboost-program-options
• libboost-system
• libboost-test
• libboost-thread
• libcap
• libdbus-cpp
• mesa (libegl1, libgles2)
• glib-2.0
• libsdl2
• libprotobuf
• protobuf-compiler
• lxc

在 Ubuntu 系统中你可以用下面的命令安装所有的依赖：

$ sudo apt install build-essential cmake cmake-data debhelper dbus \
    google-mock libboost-dev libboost-filesystem-dev libboost-log-dev \
    libboost-iostreams-dev libboost-program-options-dev libboost-system-dev \
    libboost-test-dev libboost-thread-dev libcap-dev libdbus-1-dev \
    libdbus-cpp-dev libegl1-mesa-dev libgles2-mesa-dev libglib2.0-dev \
    libglm-dev libgtest-dev liblxc1 libproperties-cpp-dev libprotobuf-dev \
    libsdl2-dev lxc-dev pkg-config protobuf-compiler

之后用下面的命令构建 Anbox：

$ mkdir build
$ cd build
$ cmake ..
$ make

一个简单的命令会将必要的二进制安装到你的系统中，如下。

$ make install

如果你想要构建 anbox snap，你可以按照下面的步骤：

$ mkdir android-images
$ cp /path/to/android.img android-images/android.img
$ snapcraft

结果会有一个 .snap 文件，你可以在支持 snap 的系统上安装。

$ snap install --dangerous --devmode anbox_1_amd64.snap

运行 Anbox

要从本地构建运行 Anbox ，你需要了解更多一点。请参考“运行时步骤”文档。

文档

在项目源代码的子目录下，你可以找到额外的关于 Anbox 的文档。

有兴趣可以看下：

• 运行时步骤
• 构建 Android 镜像

报告 bug

如果你发现了一个 Anbox 问题，请提交 bug。

取得联系

如果你想要与开发者联系，你可以在 FreeNode 中加入 #anbox 的 IRC 频道。

版权与许可

Anbox 重用了像 Android QEMU 模拟器这样的其他项目的代码。这些项目可在外部/带有许可声明的子目录中得到。

anbox 源码本身，如果没有在相关源码中声明其他的许可，默认是 GPLv3 许可。

via: https://github.com/anbox/anbox/blob/master/README.md

作者：Anbox 译者：geekpi 校对：jasminepeng

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

完美阅读及发表评论，请猛击：https://linux.cn/article-8431-1.html?utm_source=rss&utm_medium=rss

奥斯丁当地时间 4 月 19 日，一年一度的 Docker 盛会——DockerCon，比往年都要来得早一些。容器生态、Docker，这阵子最为核心的技术风，从去年的西雅图，一下刮到了今年的美国德州首府奥斯丁。作为数十年前全美的半导体中心，奥斯丁如今却因为 Docker 技术再次热闹。来自全球各地的 5000 名参与者，济济一堂，于奥斯丁会议中心，共同见证 Docker 的发展，探讨容器技术的落地。

DockerCon，作为 Docker 主办的最盛大的会议，大会上其核心领导层的一言一行，都将被万千 Docker 技术拥趸所细细品味。因此，Docker 公司去年的行业成绩单以及商业化何去何从，Docker 公司 CEO Ben Golub 自然有义务给大家细数开来；而 Docker 技术的发展，是秉承一向的定义未来，还是自足行业拥抱生态，则由创始人兼 CTO Solomon Hykes 一展蓝图。

四年增长，Docker 备受欢迎

秉承一贯的风格，DockerCon 依然在饶有趣味的场景下悄然开幕。全场 5000 位参会者，全球直播观众的瞩目下，全场放起了儿时小霸王和红白机的游戏，一度牵引万千程序员回到当时 IT 技术发源的起点。

Ben Golub 表示，对于一家成立 4 年以上的公司而言，“增长（Growth）”是一个无法回避的问题。Ben 显然不会向与会者透露 Docker 公司的营收增长，但对于这一年 Docker 在市场上的欢迎度的增长显得喜出望外。

纵观全球，Ben Golub 谈到三年来行业对 Docker 有足够多的青睐，也看到 Docker 在社会中充当了更重要的角色，这一切都是技术带来的红利，同样也是所有的参与者共同营造生态的结果。不过，Ben 一直在强调，Docker 之所以如此的受欢迎，与自身坚持的理念无法分离，即提供最便利的工具给 IT 人员，为行业创造 IT 价值。

数据显示，三年来 Docker 取得了翻天覆地的变化：

• 全球 140,000,000 的机器安装了 Docker；
• 全球的容器化应用高达 900,000， 而且这个数据将逐年快速增长；
• 一年来，Docker 为行业提供的就业岗位增长 770 倍；
• 如今全球已有多达 12,000,000,000 的镜像下拉次数；
• Docker 的全球贡献者已经达到 3300+ 人次。

Docker 的行业责任也逐渐渗透到诸多行业：

• 航空领域对 Docker 的运用；
• 每天处理十亿级美金数额的交易；
• 保障美国的医疗系统的正常运行；
• 支撑全美最大的金融机构等。

Ben Golub 毫不掩饰对容器生态中 Docker 的全球贡献者表示感谢，来自中国 DaoCloud 的工程师孙宏亮（Allen Sun）得到 Ben Golub 的最高赞扬，称赞来自中国的技术实力帮助完善 Docker，让运行在全球数据中心中的每一个 Docker 节点，都能安全有效的运行；同时 Ben Golub 也高度赞扬了同样作为华人的 Yong Tang ，他目前作为 Docker 的外部 Maintainer，任职于湾区的技术公司。

技术构建蓝图

Ben Golub 介绍 Docker 今年的发展之后，Docker 的传奇人物创始人兼 CTO Sololom Hykes 上台构筑了 Docker 的技术蓝图。

Solomon 的登场，似乎与刚才的 Ben Golub 有着某种默契。他挥舞着双臂，开口即谈工具链。从这个角度入手，Solomon 认为 Docker 为全球的 IT 领域提供了最好的工具。而这些工具，从根本上让很多事情变得简单，比如泥淖的应用封装，繁琐的异构环境等。

行业在数年前，一直有种不成文的规定：开发、运维，各有各的边界，职责清晰，部门权责独立。随着近年来 DevOps 理念的普及，大家逐渐认为开发运维不分家，而真正帮助到这一点的，无疑有工具的功劳。

关于这一点，Solomon 举了两个简单的例子。

• 在现有基础上，Docker 帮助用户构建的镜像可以越来越小。
• 应用向云的迁移部署将越来越方便，作为云原生最方便的工具。

两年前 Docker 收购 Tutum 公司，专注负责 Docker Cloud。话语间，Solomon 不忘做 Docker Cloud 的广告，随即开始了第一个演示环节。毫无疑问该演示专注于 Docker Cloud 如何帮助开发者简化流程，加速迭代。同样的，Swarm 的编排也是 Docker Cloud 的一大亮点，Docker Cloud 完全有能力借助 Swarm 帮助用户实现分布式应用的部署以及更新等。

另外，Docker 这两年内花了大量的精力在 Desktop 的开发上，演示最后展现的是：开发者如何完成本地开发，通过便利的工具实现本地到云端的部署。

借 Docker，运维准时下班

如果说，Docker 是开发的专属工具，我相信现场的每一个运维人员都不会同意，全球的运维人员更是都有话说。的确，Docker 更为运维而生。

首先，Solomon 直言传统运维的痛点，搞得现场的运维人员时不时爆出笑声。如何将用户应用部署到生产环境，一直是挑战，但现在我们有了 Docker。

当今行业分布式应用已然正在变为主流。主流之下，如何有效简单的完成编排，成为了一大难题。如何在编排的同时满足安全，难上加难。此时，Solomon 请上了 Docker 的安全专家 Monica 为大家演示了 SwarmKit 中自带的安全编排要点：

• 加密的节点标示；
• 所有节点之间的 Mutual TLS；
• 集群分区，主要通过 overlay 网络实现；
• 加密的网络，在 overlay 之间的传输进行 ipsec 加密；
• 安全的密钥分发，密码，token 等。

Solomon 坦言，传统运维面对异构的基础设施以及操作系统，现代化编排具备支持强大的移植性，这难道不就是 Docker 最大的优势吗？无论 Desktop，Linux Server，Cloud Provider，以及嵌入式设备等，都能被 Docker 以及 Docker Swarm 很好的管理。

运维给开发更多的选择，很重要的一点就是 Docker，作为 DevOps 的第一步，简化了流程。更好的工具，意味着更高的效率。当然只要是工具，你不会想要复杂的工具，用户需要的是开箱即用，而不是冗杂的部署以及环境。

独家发布 LinuxKit，安全上大台阶

Linux 操作系统不是为容器而生，多少年前，容器的安全还会为人所挑剔。曾几何时，笔者也一直认为，有朝一日，容器将成为主流，OS 必须有所变化。

Solomon 则为大家展现了 OS 发展的独到一面。Docker 发布 LinuxKit，安全，精简，强移植性，成为主基调。有意思的是，Solomon 现场开源了该项目，引来不少观众的掌声。

不得不说在操作系统层面，Docker 率先求变，降维打击，其他为容器而生的操作系统面临严峻竞争。Docker 带领的生态，有能力直接在基础设施上，运行 LinuxKit 以及 Containerd，从而管理容器。拥有巨大的势能优势，在行业中势必造成竞争，诸如 Intel 公司的 Clear Container 以及 hyper.sh 基于 VM 的容器技术，如何应对，相对而言将会成为局部关注热点。

Microsoft 和 Docker

早在三年前，Microsoft 在自身研发容器技术失败之后，开始重兵投入 Docker，尝试在 Windows 平台上兼容 Docker 的 API，底层使用 Windows 原有容器技术；而时间到了 2016 年，Microsoft 更是宣称已经支持两种 Windows 平台上的容器技术，而到了今年 2017 年的 DockerCon，Microsoft 更是宣布，Windows Docker 支持原生 Linux 容器，寓意 Linux、Windows 两大操作系统在 DockerCon 会师，未来值得期待。

重磅推出 Moby，Docker 成产品

2 个月前，Solomon 在全球的 Maintainer 列表中中，就发起了一个题为“Docker 是项目还是产品”的讨论，众说纷纭之下，今天他给了所有人一个答案。Docker 项目更名为 Moby  项目社区，Docker 关键字成为产品代名词。

Moby 项目诞生，衍生于 Docker 开源项目，意欲帮助容器生态模块化。Moby 项目提供一种框架来整合所有特定的容器系统，而不需要用户再重新造轮子。

• 2013－2014 年的初期，容器先锋活跃在技术的最前沿。那时只有十多个项目，100 多位贡献者，1000 多个部署，可谓是最初期的发展；
• 2015－2016 年，整个生态中有 100 多个项目，上千位贡献者，数万次部署；
• 2017－2018 年，项目、贡献者、以及部署都有指数级增长的趋势。

Solomon 认为容器生态的下一步是：所有内容都向一个模块化的方向发展，并有能力按需整合。“一个支撑微服务应用架构的平台需要自身满足微服务吗”，“一个工具可以模块化吗”。对的，平台也需要走向模块化，服务化。

那么，Moby 项目对于用户意味着什么？

对于原先的 Docker 的使用者而言，没有任何变化；对于系统构建者而言，按需使用，按需组件将有可能成为未来的方向。
总结而言，Docker 主动寻变，有无奈也有积极。

主要还是为了完成这样的计划：

• 澄清 Docker 的身份作为产品；
• 加快平台的组件化到不同的上游项目；
• 创建一个与 Docker 不同的新的合作项目，以协作作为一个社区，开发和组装这些组件在一起开放。

总结

有用户，就有市场；有变化，就有生机。生态如何，什么又是最适合于你的，客户的策略几何，明年的 DockerCon 再见。

完美阅读及发表评论，请猛击：https://linux.cn/article-8432-1.html?utm_source=rss&utm_medium=rss