我有一台用于备份我的所有设备的网络存储（NAS）服务器。然而当我备份我的 Linux 笔记本时遇到了困难。当它休眠或挂起时我不能备份它。当我使用基于 Intel 的无线网卡时，我可以配置笔记本上的 WiFi 接受无线唤醒吗？

网络唤醒 Wake-on-LAN （WOL）是一个以太网标准，它允许服务器通过一个网络消息而被打开。你需要发送一个“魔法数据包”到支持网络唤醒的以太网卡和主板，以便打开被唤醒的系统。

无线唤醒 wireless wake-on-lan （WoWLAN 或 WoW）允许 Linux 系统进入低耗电模式的情况下保持无线网卡处于激活状态，依然与热点连接。这篇教程演示了如何在一台安装无线网卡的 Linux 笔记本或桌面电脑上启用 WoWLAN / WoW 模式。

请注意，不是所有的无线网卡和 Linux 驱动程序都支持 WoWLAN。

语法

在 Linux 系统上，你需要使用 iw 命令来查看和操作无线设备及其配置。 其格式为：

iw command
iw [options] command

列出所有的无线设备及其功能

输入下面命令：

$ iw list
$ iw list | more
$ iw dev

输出为：

phy#0
    Interface wlp3s0
        ifindex 3
        wdev 0x1
        addr 6c:88:14:ff:36:d0
        type managed
        channel 149 (5745 MHz)，width： 40 MHz， center1： 5755 MHz
        txpower 15.00 dBm

请记下这个 phy0。

查看无线唤醒的当前状态

打开终端并输入下面命令来查看无线网络的状态：

$ iw phy0 wowlan show

输出为：

WoWLAN is disabled

如何启用无线唤醒

启用的语法为：

sudo iw phy {phyname} wowlan enable {option}

其中，

1. {phyname} - 使用 iw dev 来获取其物理名。
2. {option} - 可以是 any、disconnect、magic-packet 等。

比如，我想为 phy0 开启无线唤醒：

$ sudo iw phy0 wowlan enable any

或者：

$ sudo iw phy0 wowlan enable magic-packet disconnect

检查一下：

$ iw phy0 wowlan show

结果为：

WoWLAN is enabled：
 * wake up on disconnect
 * wake up on magic packet

测试一下

将你的笔记本挂起或者进入休眠模式：

$ sudo sh -c 'echo mem > /sys/power/state'

从 NAS 服务器上使用 ping 命令 发送 ping 请求

$ ping your-laptop-ip

也可以 使用 wakeonlan 命令发送魔法数据包：

$ wakeonlan laptop-mac-address-here
$ etherwake MAC-Address-Here

如何禁用无线唤醒？

语法为：

$ sudo phy {phyname} wowlan disable
$ sudo phy0 wowlan disable

更多信息请阅读 iw 命令的 man 页：

$ man iw
$ iw --help

via: https://www.cyberciti.biz/faq/configure-wireless-wake-on-lan-for-linux-wifi-wowlan-card/

作者：Vivek Gite 译者：lujun9972 校对：wxy

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

在 GNOME 桌面上创建 Linux 虚拟机即将变得更加简单。

GNOME Boxes 的下一个主要版本能够直接在应用程序内下载流行的 Linux（和基于 BSD 的）操作系统。

Boxes 是自由开源软件。它可以用来访问远程和虚拟系统，因为它是用 QEMU、KVM 和 libvirt 虚拟化技术构建的。

对于新的 ISO-toting 的集成，Boxes 利用 libosinfo 这一操作系统的数据库，该数据库还提供了有关任何虚拟化环境要求的详细信息。

在 GNOME 开发者 Felipe Borges 的这个（起错标题的）视频中，你可以看到改进的“源选择”页面，包括为给定的发行版下载特定架构的 ISO 的能力。

尽管它是一个核心 GNOME 程序，我不得不承认，我从来没有使用过 Boxes。（我这么做）并不是说我没有听到有关它的好处，只是我更熟悉在 VirtualBox 中设置和配置虚拟机。

我承认在浏览器中下载一个 ISO 然后将虚拟机指向它（见鬼，这是我们大多数在过去十年来一直做的事）并不是一件很困难的事。

但是我内心的偷懒精神会欣赏这种集成。

所以，感谢这个功能，我将在明年 3 月份发布 GNOME 3.28 时，在我的系统上解压 Boxes。我会启动 Boxes，闭上眼睛，随意从列表中挑选一个发行版，并立即拓宽我的视野。

via: http://www.omgubuntu.co.uk/2017/12/gnome-boxes-install-linux-distros-directly

作者：JOEY SNEDDON 译者：geekpi 校对：wxy

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

当上世纪九十年代互联网开始被广泛使用的时候，其大部分的通讯只使用几个协议：IPv4 协议路由这些数据包，TCP 协议转发这些包到连接上，SSL（及后来的 TLS）协议加密连接，DNS 协议命名那些所要连接的主机，而 HTTP 协议是最常用的应用程序协议。

多年以来，这些核心的互联网协议的变化几乎是微乎其微的；HTTP 增加了几个新的报文头和请求方式，TLS 缓慢地进行了一点小修改，TCP 调整了拥塞控制，而 DNS 引入了像 DNSSEC 这样的特性。这些协议看起来很长时间都一成不变（除了已经引起网络运营商们的大量关注的 IPv6）。

因此，希望了解（甚至有时控制）互联网的网络运营商、供应商和决策者对这些协议采用的做法是基于其原有工作方式 —— 无论是打算调试问题，提高服务质量，或施加政策。

现在，核心互联网协议的重要改变已经开始了。虽然它们意图与互联网大部分兼容（因为，如果不兼容的话，它们不会被采纳），但是它们可能会破坏那些在协议中没有规定的地方，或者根本就假设那些地方不存在变化。

为什么我们需要去改变互联网

有大量的因素推动这些变化。

首先，核心互联网协议的局限性越来越明显，尤其是考虑到性能的时候。由于在应用和传输协议方面的结构性问题，网络没有得到高效使用，导致终端用户认为性能不能满足要求（特别是，网络延迟）。

这就意味着人们有强烈的动机来演进或者替换这些协议，因为有 大量的经验表明，即便是很小的性能改善也会产生影响。

其次，演进互联网协议的能力 —— 无论在任何层面上 —— 会随着时间的推移变得更加困难，这主要是因为上面所讨论的对网络的非预期使用。例如，尝试去压缩响应的 HTTP 代理服务器使得部署新的压缩技术更困难；中间设备中的 TCP 优化使得部署对 TCP 的改进越来越困难。

最后，我们正处在一个越来越多地使用加密技术的互联网变化当中，首次激起这种改变的事件是，2015 年 Edward Snowden 的披露事件（LCTT 译注：指的是美国中情局雇员斯诺登的事件）。那是一个单独讨论的话题，但是与之相关的是，加密技术是最好的工具之一，我们必须确保协议能够进化。

让我们来看一下都发生了什么，接下来会出现什么，它对网络有哪些影响，和它对网络协议的设计有哪些影响。

HTTP/2

HTTP/2（基于 Google 的 SPDY） 是第一个重大变化 —— 它在 2015 年被标准化。它将多个请求复用到一个 TCP 连接上，从而避免了客户端排队请求，而不会互相阻塞。它现在已经被广泛部署，并且被所有的主流浏览器和 web 服务器支持。

从网络的角度来看，HTTP/2 带来了一些显著变化。首先，这是一个二进制协议，因此，任何假定它是 HTTP/1.1 的设备都会出现问题。

这种破坏性问题是导致 HTTP/2 中另一个重大变化的主要原因之一：它实际上需要加密。这种改变的好处是避免了来自伪装的 HTTP/1.1 的中间人攻击，或者一些更细微的事情，比如 strip headers 或者阻止新的协议扩展 —— 这两种情况都在工程师对协议的开发中出现过，导致了很明显的支持问题。

当它被加密时，HTTP/2 请求也要求使用 TLS/1.2，并且将一些已经被证明是不安全的算法套件列入黑名单 —— 其效果只允许使用 短暂密钥 ephemeral keys 。关于潜在的影响可以去看 TLS 1.3 的相关章节。

最终，HTTP/2 允许多个主机的请求被 合并到一个连接上，通过减少页面加载所使用的连接（从而减少拥塞控制的场景）数量来提升性能。

例如，你可以对 www.example.com 建立一个连接，也可以将这个连接用于对 images.example.com 的请求。而未来的协议扩展也允许将其它的主机添加到连接上，即便它们没有被列在最初用于它们的 TLS 证书中。因此，假设连接上的通讯被限制于它初始化时的目的并不适用。

值得注意的是，尽管存在这些变化，HTTP/2 并没有出现明显的互操作性问题或者来自网络的冲突。

TLS 1.3

TLS 1.3 刚刚通过了标准化的最后流程，并且已经被一些实现所支持。

不要被它只增加了版本号的名字所欺骗；它实际上是一个新的 TLS 版本，全新打造的 “握手”机制允许应用程序数据从头开始流动（经常被称为 ‘0RTT’）。新的设计依赖于短暂密钥交换，从而排除了静态密钥。

这引起了一些网络运营商和供应商的担心 —— 尤其是那些需要清晰地知道那些连接内部发生了什么的人。

例如，假设一个对可视性有监管要求的银行数据中心，通过在网络中嗅探通讯包并且使用他们的服务器上的静态密钥解密它，它们可以记录合法通讯和识别有害通讯，无论是来自外部的攻击，还是员工从内部去泄露数据。

TLS 1.3 并不支持那些窃听通讯的特定技术，因为那也是 一种针对短暂密钥防范的攻击形式。然而，因为他们有使用更现代化的加密协议和监视他们的网络的监管要求，这些使网络运营商处境很尴尬。

关于是否规定要求静态密钥、替代方式是否有效、并且为了相对较少的网络环境而减弱整个互联网的安全是否是一个正确的解决方案有很多的争论。确实，仍然有可能对使用 TLS 1.3 的通讯进行解密，但是，你需要去访问一个短暂密钥才能做到，并且，按照设计，它们不可能长时间存在。

在这一点上，TLS 1.3 看起来不会去改变以适应这些网络，但是，关于去创建另外一种协议有一些传言，这种协议允许第三方去偷窥通讯内容，或者做更多的事情。这件事是否会得到推动还有待观察。

QUIC

在 HTTP/2 工作中，可以很明显地看到 TCP 有相似的低效率。因为 TCP 是一个按顺序发送的协议，一个数据包的丢失可能阻止其后面缓存区中的数据包被发送到应用程序。对于一个多路复用协议来说，这对性能有很大的影响。

QUIC 尝试去解决这种影响而在 UDP 之上重构了 TCP 语义（以及 HTTP/2 流模型的一部分）。像 HTTP/2 一样，它始于 Google 的一项成果，并且现在已经被 IETF 接纳作为一个 HTTP-over-UDP 的初始用例，其目标是在 2018 年底成为一个标准。然而，因为 Google 已经在 Chrome 浏览器及其网站上部署了 QUIC，它已经占有了超过 7% 的互联网通讯份额。

• 阅读 关于 QUIC 的答疑

除了大量的通讯从 TCP 到 UDP 的转变（以及隐含的可能的网络调整）之外，Google QUIC（gQUIC）和 IETF QUIC（iQUIC）都要求全程加密；并没有非加密的 QUIC。

iQUIC 使用 TLS 1.3 来为会话建立密钥，然后使用它去加密每个数据包。然而，由于它是基于 UDP 的，许多 TCP 中公开的会话信息和元数据在 QUIC 中被加密了。

事实上，iQUIC 当前的 ‘短报文头’ 被用于除了握手外的所有包，仅公开一个包编号、一个可选的连接标识符和一个状态字节，像加密密钥轮换计划和包字节（它最终也可能被加密）。

其它的所有东西都被加密 —— 包括 ACK，以提高 通讯分析 攻击的门槛。

然而，这意味着通过观察连接来被动估算 RTT 和包丢失率将不再变得可行；因为没有足够多的信息。在一些运营商中，由于缺乏可观测性，导致了大量的担忧，它们认为像这样的被动测量对于他们调试和了解它们的网络是至关重要的。

为满足这一需求，它们有一个提议是 ‘Spin Bit’ — 这是在报文头中的一个回程翻转的位，因此，可能通过观察它来估算 RTT。因为，它从应用程序的状态中解耦的，它的出现并不会泄露关于终端的任何信息，也无法实现对网络位置的粗略估计。

DOH

即将发生的变化是 DOH — DNS over HTTP。大量的研究表明，对网络实施政策干预的一个常用手段是通过 DNS 实现的（无论是代表网络运营商或者一个更大的权力机构）。

使用加密去规避这种控制已经 讨论了一段时间了，但是，它有一个不利条件（至少从某些立场来看）— 它可能与其它通讯区别对待；例如，通过它的端口号被阻止访问。

DOH 将 DNS 通讯搭载在已经建立的 HTTP 连接上，因此，消除了任何的鉴别器。希望阻止访问该 DNS 解析器的网络只能通过阻止对该网站的访问来实现。

例如，如果 Google 在 www.google.com 上部署了它的 基于 DOH 的公共 DNS 服务，并且一个用户配置了它的浏览器去使用它，一个希望（或被要求的）被停止访问该服务的网络，将必须阻止对 Google 的全部访问（向他们提供的服务致敬！）（LCTT 译注：他们做到了）。

DOH 才刚刚开始，但它已经引起很多人的兴趣，并有了一些部署的传闻。通过使用 DNS 来实施政策影响的网络（和政府机构）如何反应还有待观察。

阅读 IETF 100, Singapore: DNS over HTTP (DOH!)

僵化和润滑

让我们返回到协议变化的动机，有一个主题贯穿了这项工作，协议设计者们遇到的越来越多的问题是网络对流量的使用做了假设。

例如，TLS 1.3 有一些临门一脚的问题是中间设备假设它是旧版本的协议。gQUIC 将几个对 UDP 通讯进行限流的网络列入了黑名单，因为，那些网络认为 UDP 通讯是有害的或者是低优先级的。

当一个协议因为已有的部署而 “冻结” 它的可扩展点，从而导致不能再进化，我们称它为 已经僵化了 。TCP 协议自身就是一个严重僵化的例子，因此，太多的中间设备在 TCP 协议上做了太多的事情，比如阻止了带有无法识别的 TCP 选项的数据包，或者，“优化”了拥塞控制。

防止僵化是有必要的，确保协议可以进化以满足未来互联网的需要；否则，它将成为一个“公共灾难”，一些个别网络的行为 —— 虽然在那里工作的很好 —— 但将影响整个互联网的健康发展。

有很多的方式去防止僵化；如果被讨论的数据是加密的，它并不能被除了持有密钥的人之外任何一方所访问，阻止了干扰。如果扩展点是未加密的，但是通常以一种可以明显中断应用程序的方法使用（例如，HTTP 报头），它不太可能受到干扰。

协议设计者不能使用加密的扩展点不经常使用的情况下，人为地利用扩展点——我们称之为 润滑 它。

例如，QUIC 鼓励终端在 版本协商 中使用一系列的诱饵值，来避免假设它的实现永远不变化（就像在 TLS 实现中经常遇到的导致重大问题的情况）。

网络和用户

除了避免僵化的愿望外，这些变化也反映出了网络和它们的用户之间关系的进化。很长时间以来，人们总是假设网络总是很仁慈好善的 —— 或者至少是公正的 —— 但这种情况是不存在的，不仅是 无孔不入的监视，也有像 Firesheep 的攻击。

因此，当那些网络想去访问一些流经它们的网络的用户数据时，互联网用户的整体需求和那些网络之间的关系日益紧张。尤其受影响的是那些希望去对它们的用户实施政策干预的网络；例如，企业网络。

在一些情况中，他们可以通过在它们的用户机器上安装软件（或一个 CA 证书，或者一个浏览器扩展）来达到他们的目的。然而，在网络不拥有或无法访问计算机的情况下，这并不容易；例如，BYOD 已经很常用，并且物联网设备几乎没有合适的控制接口。

因此，在 IETF 中围绕协议开发的许多讨论，触及了企业和其它的 “叶子” 网络有时相互竞争的需求，以及互联网整体的好处。

参与

为了让互联网在以后工作的更好，它需要为终端用户提供价值、避免僵化、让网络有序运行。现在正在发生的变化需要满足所有的三个目标，但是，人们需要网络运营商更多的投入。

如果这些变化影响你的网络 —— 或者没有影响 —— 请在下面留下评论。更好地可以通过参加会议、加入邮件列表、或者对草案提供反馈来参与 IETF 的工作。

感谢 Martin Thomson 和 Brian Trammell 的评论。

本文作者 Mark Nottingham 是互联网架构委员会的成员和 IETF 的 HTTP 和 QUIC 工作组的联席主席。

via: https://blog.apnic.net/2017/12/12/internet-protocols-changing/

作者：Mark Nottingham 译者：qhwdw 校对：wxy

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

学习怎么去使用 Python 的 web 框架中的对象关系映射与你的数据库交互，就像你使用 SQL 一样。

你可能听说过 Django，它是一个被称为“完美主义者的最后期限” 的 Python web 框架。它是一匹 可爱的小矮马。

Django 的一个强大的功能是它的 对象关系映射 Object-Relational Mapper （ORM），它允许你就像使用 SQL 一样去和你的数据库交互。事实上，Django 的 ORM 就是创建 SQL 去查询和操作数据库的一个 Python 式方式，并且获得 Python 风格的结果。 我说的是一种方式，但实际上，它是一种非常聪明的工程方法，它利用了 Python 中一些很复杂的部分，而使得开发者更加轻松。

在我们开始去了解 ORM 是怎么工作之前，我们需要一个可以操作的数据库。和任何一个关系型数据库一样，我们需要去定义一堆表和它们的关系（即，它们相互之间联系起来的方式)。让我们使用我们熟悉的东西。比如说，我们需要去建模一个有博客文章和作者的博客。每个作者有一个名字。一位作者可以有很多的博客文章。一篇博客文章可以有很多的作者、标题、内容和发布日期。

在 Django 村里，这个文章和作者的概念可以被称为博客应用。在这个语境中，一个应用是一个自包含一系列描述我们的博客行为和功能的模型和视图的集合。用正确的方式打包，以便于其它的 Django 项目可以使用我们的博客应用。在我们的项目中，博客正是其中的一个应用。比如，我们也可以有一个论坛应用。但是，我们仍然坚持我们的博客应用的原有范围。

这是为这个教程事先准备的 models.py：

from django.db import models

class Author(models.Model):
    name = models.CharField(max_length=100)

    def __str__(self):
        return self.name

class Post(models.Model):
    title = models.CharField(max_length=100)
    content = models.TextField()
    published_date = models.DateTimeField(blank=True, null=True)
    author = models.ManyToManyField(Author, related_name="posts")

    def __str__(self):
        return self.title

现在，看上去似乎有点令人恐惧，因此，我们把它分解来看。我们有两个模型：作者（Author）和文章（Post）。它们都有名字（name）或者标题（title）。文章有个放内容的大的文本字段，以及用于发布时间和日期的 DateTimeField。文章也有一个 ManyToManyField，它同时链接到文章和作者。

大多数的教程都是从头开始的，但是，在实践中并不会发生这种情况。实际上，你会得到一堆已存在的代码，就像上面的 model.py 一样，而你必须去搞清楚它们是做什么的。

因此，现在你的任务是去进入到应用程序中去了解它。做到这一点有几种方法，你可以登入到 Django admin，这是一个 Web 后端，它会列出全部的应用和操作它们的方法。我们先退出它，现在我们感兴趣的东西是 ORM。

我们可以在 Django 项目的主目录中运行 python manage.py shell 去访问 ORM。

/srv/web/django/ $ python manage.py shell

Python 3.6.3 (default, Nov  9 2017, 15:58:30)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>>

这将带我们进入到交互式控制台。shell 命令 为我们做了很多设置，包括导入我们的设置和配置 Django 环境。虽然我们启动了 shell，但是，在我们导入它之前，我们并不能访问我们的博客模型。

>>> from blog.models import *

它导入了全部的博客模型，因此，我们可以玩我们的博客了。

首先，我们列出所有的作者：

>>> Author.objects.all()

我们将从这个命令取得结果，它是一个 QuerySet，它列出了我们所有的作者对象。它不会充满我们的整个控制台，因为，如果有很多查询结果，Django 将自动截断输出结果。

>>> Author.objects.all()
<QuerySet [<Author: VM (Vicky) Brasseur>, <Author: Rikki Endsley>,
 <Author: Jen Wike Huger>, '...(remaining elements truncated)...']

我们可以使用 get 代替 all 去检索单个作者。但是，我们需要一些更多的信息才能 get 一个单个记录。在关系型数据库中，表有一个主键，它唯一标识了表中的每个记录，但是，作者名并不唯一。许多人都 重名，因此，它不是唯一约束的好选择。解决这个问题的一个方法是使用一个序列（1、2、3 ……）或者一个通用唯一标识符（UUID）作为主键。但是，因为它对人类并不好用，我们可以通过使用 name 来操作我们的作者对象。

>>> Author.objects.get(name="VM (Vicky) Brasseur")
<Author: VM (Vicky) Brasseur>

到现在为止，我们已经有了一个我们可以交互的对象，而不是一个 QuerySet 列表。我们现在可以与这个 Python 对象进行交互了，使用任意一个表列做为属性去查看对象。

>>> vmb = Author.objects.get(name="VM (Vicky) Brasseur")
>>> vmb.name
u'VM (Vicky) Brasseur'

然后，很酷的事件发生了。通常在关系型数据库中，如果我们希望去展示其它表的信息，我们需要去写一个 LEFT JOIN，或者其它的表耦合函数，并确保它们之间有匹配的外键。而 Django 可以为我们做到这些。

在我们的模型中，由于作者写了很多的文章，因此，我们的作者对象可以检索他自己的文章。

>>> vmb.posts.all()
QuerySet[<Post: "7 tips for nailing your job interview">,
 <Post: "5 tips for getting the biggest bang for your cover letter buck">,
 <Post: "Quit making these 10 common resume mistakes">,
 '...(remaining elements truncated)...']

我们可以使用正常的 Python 式的列表操作方式来操作 QuerySets。

>>> for post in vmb.posts.all():
...   print(post.title)
...
7 tips for nailing your job interview
5 tips for getting the biggest bang for your cover letter buck
Quit making these 10 common resume mistakes

要实现更复杂的查询，我们可以使用过滤得到我们想要的内容。这有点复杂。在 SQL 中，你可以有一些选项，比如，like、contains 和其它的过滤对象。在 ORM 中这些事情也可以做到。但是，是通过 特别的 方式实现的：是通过使用一个隐式（而不是显式）定义的函数实现的。

如果在我的 Python 脚本中调用了一个函数 do_thing()，我会期望在某个地方有一个匹配的 def do_thing。这是一个显式的函数定义。然而，在 ORM 中，你可以调用一个 不显式定义的 函数。之前，我们使用 name 去匹配一个名字。但是，如果我们想做一个子串搜索，我们可以使用 name__contains。

>>> Author.objects.filter(name__contains="Vic")
QuerySet[<Author: VM (Vicky) Brasseur>, <Author: Victor Hugo">]

现在，关于双下划线（__）我有一个小小的提示。这些是 Python 特有的。在 Python 的世界里，你可以看到如 __main__ 或者 __repr__。这些有时被称为 dunder methods，是 “ 双下划线 double underscore ” 的缩写。仅有几个非字母数字的字符可以被用于 Python 中的对象名字；下划线是其中的一个。这些在 ORM 中被用于显式分隔 过滤关键字 filter key name 的各个部分。在底层，字符串用这些下划线分割开，然后这些标记分开处理。name__contains 被替换成 attribute: name, filter: contains。在其它编程语言中，你可以使用箭头代替，比如，在 PHP 中是 name->contains。不要被双下划线吓着你，正好相反，它们是 Python 的好帮手（并且如果你斜着看，你就会发现它看起来像一条小蛇，想去帮你写代码的小蟒蛇）。

ORM 是非常强大并且是 Python 特有的。不过，还记得我在上面提到过的 Django 的管理网站吗？

Django 的其中一个非常精彩的用户可访问特性是它的管理界面，如果你定义你的模型，你将看到一个非常好用的基于 web 的编辑门户，而且它是免费的。

ORM，有多强大？

好吧！给你一些代码去创建最初的模型，Django 就变成了一个基于 web 的门户，它是非常强大的，它可以使用我们前面用过的同样的原生函数。默认情况下，这个管理门户只有基本的东西，但这只是在你的模型中添加一些定义去改变外观的问题。例如，在早期的这些 __str__ 方法中，我们使用这些去定义作者对象应该有什么？（在这种情况中，比如，作者的名字），做了一些工作后，你可以创建一个界面，让它看起来像一个内容管理系统，以允许你的用户去编辑他们的内容。（例如，为一个标记为 “已发布” 的文章，增加一些输入框和过滤）。

如果你想去了解更多内容，Django 美女的教程 中关于 the ORM 的节有详细的介绍。在 Django project website 上也有丰富的文档。

（题图 Christian Holmér，Opensource.com 修改. CC BY-SA 4.0）

作者简介：

Katie McLaughlin - Katie 在过去的这几年有许多不同的头衔，她以前是使用多种语言的一位软件开发人员，多种操作系统的系统管理员，和多个不同话题的演讲者。当她不改变 “世界” 的时候，她也去享受烹饪、挂毯艺术，和去研究各种应用程序栈怎么去处理 emoji。

via: https://opensource.com/article/17/11/django-orm

作者：Katie McLaughlin 译者：qhwdw 校对：wxy

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

保持对我们的网络的管理，防止任何程序过度使用网络、导致整个系统操作变慢，对管理员来说是至关重要的。有几个网络监视工具可以用于不同的操作系统。在这篇文章中，我们将讨论从 Linux 终端中运行的 10 个网络监视工具。它对不使用 GUI 而希望通过 SSH 来保持对网络管理的用户来说是非常理想的。

iftop

Linux 用户通常都熟悉 top —— 这是一个系统监视工具，它允许我们知道在我们的系统中实时运行的进程，并可以很容易地管理它们。iftop 与 top 应用程序类似，但它是专门监视网络的，通过它可以知道更多的关于网络的详细情况和使用网络的所有进程。

我们可以从 这个链接 获取关于这个工具的更多信息以及下载必要的包。

vnstat

vnstat 是一个缺省包含在大多数 Linux 发行版中的网络监视工具。它允许我们对一个用户选择的时间周期内发送和接收的流量进行实时控制。

我们可以从 这个链接 获取关于这个工具的更多信息以及下载必要的包。

iptraf

IPTraf 是一个基于控制台的 Linux 实时网络监视程序。它会收集经过这个网络的各种各样的信息作为一个 IP 流量监视器，包括 TCP 标志信息、ICMP 详细情况、TCP / UDP 流量故障、TCP 连接包和字节计数。它也收集接口上全部的 TCP、UDP、…… IP 协议和非 IP 协议 ICMP 的校验和错误、接口活动等等的详细情况。（LCTT 译注：此处原文有误，径改之）

我们可以从 这个链接 获取这个工具的更多信息以及下载必要的包。

Monitorix - 系统和网络监视

Monitorix 是一个轻量级的免费应用程序，它设计用于去监视尽可能多的 Linux / Unix 服务器的系统和网络资源。它里面添加了一个 HTTP web 服务器，可以定期去收集系统和网络信息，并且在一个图表中显示它们。它跟踪平均系统负载、内存分配、磁盘健康状态、系统服务、网络端口、邮件统计信息（Sendmail、Postfix、Dovecot 等等）、MySQL 统计信息以及其它的更多内容。它设计用于去管理系统的整体性能，以及帮助检测故障、瓶颈、异常活动等等。

下载及更多 信息在这里。

dstat

这个监视器相比前面的几个知名度低一些，但是，在一些发行版中已经缺省包含了。

我们可以从 这个链接 获取这个工具的更多信息以及下载必要的包。

bwm-ng

这是最简化的工具之一。它允许你去从连接中交互式取得数据，并且，为了便于其它设备使用，在取得数据的同时，能以某些格式导出它们。

我们可以从 这个链接 获取这个工具的更多信息以及下载必要的包。

ibmonitor

与上面的类似，它显示连接接口上过滤后的网络流量，并且，明确地将接收流量和发送流量区分开。

我们可以从 这个链接 获取这个工具的更多信息以及下载必要的包。 ​

Htop - Linux 进程跟踪

Htop 是一个更先进的、交互式的、实时的 Linux 进程跟踪工具。它类似于 Linux 的 top 命令，但是有一些更高级的特性，比如，一个更易于使用的进程管理界面、快捷键、水平和垂直的进程视图等更多特性。Htop 是一个第三方工具，它不包含在 Linux 系统中，你必须使用 YUM 或者 APT-GET 或者其它的包管理工具去安装它。关于安装它的更多信息，读这篇文章。

我们可以从 这个链接 获取这个工具的更多信息以及下载必要的包。

arpwatch - 以太网活动监视器

arpwatch 是一个设计用于在 Linux 网络中去管理以太网通讯的地址解析程序。它持续监视以太网通讯并记录一个网络中的 IP 地址和 MAC 地址的变化，该变化同时也会记录一个时间戳。它也有一个功能是当一对 IP 和 MAC 地址被添加或者发生变化时，发送一封邮件给系统管理员。在一个网络中发生 ARP 攻击时，这个功能非常有用。

我们可以从 这个链接 获取这个工具的更多信息以及下载必要的包。

Wireshark - 网络监视工具

Wireshark 是一个自由的应用程序，它允许你去捕获和查看前往你的系统和从你的系统中返回的信息，它可以去深入到数据包中并查看每个包的内容 —— 以分别满足你的不同需求。它一般用于去研究协议问题和去创建和测试程序的特别情况。这个开源分析器是一个被公认的分析器商业标准，它的流行要归功于其久负盛名。

最初它被叫做 Ethereal，Wireshark 有轻量化的、易于理解的界面，它能分类显示来自不同的真实系统上的协议信息。

结论

​在这篇文章中，我们看了几个开源的网络监视工具。虽然我们从这些工具中挑选出来的认为是“最佳的”，并不意味着它们都是最适合你的需要的。例如，现在有很多的开源监视工具，比如，OpenNMS、Cacti、和 Zennos，并且，你需要去从你的个体情况考虑它们的每个工具的优势。

另外，还有不同的、更适合你的需要的不开源的工具。

你知道的或者使用的在 Linux 终端中的更多网络监视工具还有哪些？

via: http://www.linuxandubuntu.com/home/best-network-monitoring-tools-for-linux

作者：​​LinuxAndUbuntu 译者：qhwdw 校对：wxy

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

“实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ 不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。”

— 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座

指责开源软件总是离奇难用已经不是一个新论点了；这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？

在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为 编写代码实现和一个跟 StackOverflow 一样的系统可以简单到爆，并自信的 声称他们可以在 7 月 4 号的周末就写出一版和 StackOverflow 原版一模一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品 就已经是一个很好的例证了。

秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以像我一样打字飞快，一分钟能敲 100 个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计 2.3MB 的源码来估计（包括 .CS、 .SQL、 .CSS、 .JS 和 .aspx 文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。

或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄 StackOverflow 源代码用时的十倍时间来让我自己写 StackOverflow，我可是打死也做不到。

好的，我知道你在听到这些假设的时候已经开始觉得泄气了。你在想，如果不是全部实现，而只是实现 StackOverflow 大部分 的功能呢？这总归会容易很多了吧。

好的，问题是什么是 “大部分” 功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题及其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且与 Markdown 结合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的 那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标、小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。

但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。

除非……除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登录事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和 徽章 Badge 。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot、Reddit 或是 StackOverflow 这些动作影响到。

在这之后！你会以为你基本已经大功告成了！

……为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的 CSS 设计、AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一模一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。

那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？

正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码:

create table QUESTION (ID identity primary key,
                                             TITLE varchar(255), --- 为什么我知道你认为是 255
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             USER integer references USER(ID));
create table RESPONSE (ID identity primary key,
                                             BODY text,
                                             UPVOTES integer not null default 0,
                                             DOWNVOTES integer not null default 0,
                                             QUESTION integer references QUESTION(ID))

如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登录和注销功能、评论功能、投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登录和评论的功能。

但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它的数据库的 Schema 没有多大关系 —— 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后大量的精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。

这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿徽章功能来说，如果你要针对普通终端用户来设计徽章， 则要么需要实现一个用户可用来个性化设置徽章的 GUI，要么则取巧的设计出一个比较通用的徽章，供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给徽章这种东西设计一个功能全面的 GUI 是根本不可能的。而且他们会固执地把任何标准徽章的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制，提供以 Python 或 PHP 为基础的一些系统 API， 以便那些可以自如使用 Python 或 PHP 的人可以轻松的通过这些编程接口来定制化他们自己的徽章。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法）

同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何 mod 的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计（即要求用户必须拥有一个 OpenID 并知道如何使用它）在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的却是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。

开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。

这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache、Django、PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 Ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。

相比之下，MS SQL (微软的 SQL 数据库) 则不需要你手工配置以上的任何一样东西。至于 Apache …… 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机、MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也 只是 一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就 恰恰在 这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。

所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的在一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。

via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/

作者：Benjamin Pollack 译者：hopefully2333，yunfengHe 校对：yunfengHe，wxy

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