2023年3月

多测量几次总比测量一次好。我掉到坑里,希望你可以不用。

我想写一篇文章来演示“如何使用树莓派实现莫某的自动化”,或围绕树莓派的其他一些有趣、好奇或有用的应用。正如你可能从标题中意识到的那样,我不能再提供这样的文章了,因为我毁了我心爱的树莓派。

树莓派是每个技术爱好者办公桌上的标准设备。因此,大量教程和文章告诉你可以用它做什么。这篇文章反而涵盖了阴暗面:我描述了你最好不要做的事情!

电缆颜色

在谈到实际的破坏点之前,我想提供一些背景。在房屋内外进行电气工作时,你必须处理不同颜色的电缆。在德国,每栋房子都连接到三相交流电网,你通常会发现以下电缆颜色:

  • 零线:蓝色
  • (PE)地线:黄绿色
  • (L1)火线 1:棕色
  • (L2)火线 2:黑色
  • (L3)火线 3:灰色

例如,给灯接线时,你接零线(N,蓝色)和火线(L,有 1/3 的机会是棕色),它们之间的电压为 230V 交流电。

连接树莓派

今年早些时候,我写了一篇关于 OpenWrt,家用路由器固件的开源替代品 的文章。在文章中,我使用了 TP-link 路由器设备。但是,最初的计划是使用我的树莓派 4。

OpenWrt and Raspberry Pi comparison

我的想法是构建一个旅行路由器,我可以将其安装在我的大篷车中以改善露营地的互联网连接(我是那种离不开互联网的露营者)。为此,我在我的树莓派中添加了一个单独的 USB 无线网卡以连接第二个 Wifi 天线并安装了 OpenWrt。此外,我添加了一个 12V 至 5V DC/DC 转换器来连接大篷车中的 12V 接线。我用桌上的 12V 汽车电池测试了这个设置,它按预期工作。一切设置和配置完成后,我开始将其安装到我的大篷车中。

在我的大篷车里,我找到了一根蓝色和一根棕色的电线,将它与 12V 至 5V DC/DC 转换器相连,将保险丝放回,然后……

DC converter device

这个芯片,自己爆开了,它才是真正的降压变压器。我非常自信地认为蓝线是在 0V 电位上,棕色的是在 12V 上,我甚至没有测量。后来我了解到,蓝色的线是在 12V 上,而棕色的线是接地(这在汽车电子产品中很常见)。

总结

自从这次事故后,我的树莓派就再也启动不起来了。由于树莓派的价格飞涨,我不得不寻找替代品。幸运的是,我遇到了 TP-Link 旅行路由器,它也可以运行 Open-WRT 并且可以令人满意地完成它的工作。

最后:多测量几次总比测量一次好。


via: https://opensource.com/article/23/3/how-i-destroyed-my-raspberry-pi

作者:Stephan Avenwedde 选题:lkxed 译者:geekpi 校对:wxy

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

NixOS 中的打包系统是它最强大的地方。Nix 软件包管理器使用的语法与 aptdnf 和其他软件包管理器大不相同。

这也是 人们应该尝试使用 NixOS 的原因之一

在本指南中,我将分享两种在 NixOS 上安装和删除软件包的方法:

  • 使用 Nix 软件包管理器
  • 使用 configuration.nix 配置文件
⚠️ 使用 Nix 软件包管理器,你只能安装软件包,而不能安装 OpenSSH 或 Plex 服务器等服务。对于服务的安装,你必须使用 Nix 配置文件。

要安装任何软件包,必须知道它的确切名称,为此,我将从如何在 NixOS 中搜索软件包开始。

搜索软件包

要寻找软件包,你可以使用它的 网页搜索

你可以使用如下步骤:

  • 在搜索栏中输入软件包的名称
  • 选择适当的软件包(从给出的描述中决定)
  • 点击 “nix-env” 标签页
  • 复制 NixOS 命令(第一条)

例如,如果我想要 librewolf 包,我将执行以下操作:

使用 Nix 软件包管理器的网络搜索寻找软件包

你也可以通过终端做同样的事情。

要使用终端搜索软件包,你可以按照给定的命令语法进行:

nix-env -qaP --description [软件包名称]

例如,在这里,我搜索了 librewolf

使用终端搜索 NixOS 中的软件包

你必须复制输出的第一行,因为那是你需要安装的软件包的名称。

在这里它是 nixos.librewolf

是的,它听起来可能没有像使用 APT 或 DNF 时软件包名字那么方便。但是,我认为这并不是大问题。

一些妥协或许会换来一些好处?

在 NixOS 中安装一个软件包

要安装一个软件包,你所要做的就是使用以下命令语法:

nix-env -iA [软件包名称]

而且,如果你使用网络搜索来寻找软件包,你就已经有了安装所需的确切命令。

所以,假设我想安装 `librewolf',我将使用以下命令:

nix-env -iA nixos.librewolf

如果你想进行全系统的安装(让每个用户都能使用这个包),用 sudo 执行安装命令:

sudo nix-env -iA nixos.librewolf

就是这样!你将很快安装好你喜欢的软件包。

在 NixOS 中卸载一个软件包

要删除一个软件包,你可以参考下面的命令语法:

nix-env --uninstall [软件包名称]

因此,如果我必须删除 librewolf 包,我必须使用以下命令:

nix-env --uninstall librewolf

如果你仔细注意,我使用了 librewolf 而不是 nixos.librewolf 来安装。

这意味着你在删除软件包时要跳过 nixos 部分,这使事情变得简单而快速。

在 NixOS 中安装服务

正如我前面提到的,你不能使用 Nix 软件包管理器来安装像 OpenSSH、Plex 服务器、Flatpak 等服务。

从搜索服务到安装过程,都与你上面看到的不同。

所以让我先说说如何 搜索服务

  • 要搜索服务,请前往 Nix 软件包搜索 网页
  • 选择 “ NixOS 选项 NixOS options ”(页面顶部菜单行的第三个选项)
  • 输入你要找的服务的名称
  • 复制服务的名称

例如,在这里,我正在搜索 OpenSSH 服务。

搜索 NixOS 中的 OpenSSH 服务

一旦你找到了这个名字,用下面的命令打开 configuration.nix 文件:

sudo nano /etc/nixos/configuration.nix

并在行末添加服务的名称(在 } 之前),如下:

[service_name] = true;

由于 我想启用 OpenSSH,我将添加以下内容:

services.openssh.enable = true;

在 NixOS 上启用 OpenSSH

一旦你在配置文件中添加了服务,保存修改并退出 Nano 文本编辑器。

要启用该服务,请重建配置文件,并使用以下命令切换到所做的更改:

sudo nixos-rebuild switch

这就行了,你已经启用了该服务。

从 NixOS 卸载服务

要卸载一个服务,你所要做的就是在 configuration.nix 文件中删除或注释该服务的一行。

因此,首先,用以下命令打开配置文件:

sudo nano /etc/nixos/configuration.nix

寻找服务,并删除这一行或用 # 注释掉:

从 NixOS 删除服务

通过添加注释 #,我忽略了 OpenSSH 服务的加载,因为我不再需要它在我的系统上。

保存修改并退出文本编辑器。

最后,重建配置文件并进行切换:

sudo nixos-rebuild switch

使用 Nix 配置文件安装软件包

配置文件可以让你 方便地一次性管理软件包

要使用 Nix 配置文件安装软件包,你必须在配置文件中输入软件包的名称、重建,然后切换到配置文件,就可以了。

首先,打开 configuration.nix 文件。

sudo nano /etc/nixos/configuration.nix

如果你想 为一个特定的登录用户安装软件包,将软件包的名称添加到用户的配置文件中。

用户配置文件看起来像这样:

users.users.sagar = {
    isNormalUser = true;
    description = "Sagar";
    extraGroups = [ "networkmanager" "wheel" ];
    packages = with pkgs; [
      firefox
    ];
  };

当然,它将显示你的用户名而不是 sagar

你应该使用如下语法来添加软件包的名称:

packages = with pkgs; [
  软件包名称
  ]; 

所以我们假设我也想安装 Thunderbird,那么我将添加它的名字,如下所示:

使用 Nix 配置文件在 NixOS 中安装一个包

你必须在方括号内添加所有的软件包名称,不要用逗号。它必须像截图中描述的那样一个软件一个新的行。

但是如果你想在整个系统中安装这个包,那么你必须在 environment.systemPackages 下添加包的名字,比如:

environment.systemPackages = with pkgs; [
  软件包名称
];

使用 Nix 配置文件在 NixOS 中全系统安装软件包

一旦你完成了在系统配置文件或用户配置文件,甚至两者中添加所需软件包的名称,你将需要按照同样的命令来完成安装:

sudo nixos-rebuild switch

这样就可以了!

使用 Nix 配置文件删除软件包

要删除软件包,你所要做的就是按照给定的简单步骤进行:

  • 打开 Nix 配置文件
  • 删除或注释掉软件包的名称
  • 重新构建配置并进行切换

所以,让我们从第一步开始(打开配置文件):

sudo nano /etc/nixos/configuration.nix

接下来,注释掉用户配置文件或系统配置文件中的包的名称:

在 NixOS 上使用 Nix 配置文件删除包

保存更改并退出配置文件。

最后,重建配置文件,并做一个切换来删除包:

sudo nixos-rebuild switch

这是这样!

? 目前,还没有官方的 GUI 工具来帮助你安装/删除软件包。你可能会发现一些由社区开发的项目,如 nix-guinix42b,但它们不再被维护或仅仅处于早期开发阶段。

接下来...

我希望你喜欢阅读 NixOS 系列,就像我写它一样。

在下一篇中,我将强调一些在你安装 NixOS 后需要马上做的重要事情。

如果你认为我遗漏了什么或有其他建议,请在评论中告诉我。


via: https://itsfoss.com/nixos-package-management/

作者:Sagar Sharma 选题:lkxed 译者:wxy 校对:wxy

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

Mastodon 用户数突破一千万

在马斯克收购 Twitter 前,Mastodon 有大约 50 万活跃用户。在马斯克一系列“神操作”之后,Mastodon 在 11 月份涌入了大量用户,高峰时每天新增逾 13 万用户。如今 Mastodon 的活跃度略有下降,每天能增加 4.5 万左右的用户,它的用户数目前刚刚超过一千万。顺便说一句,马斯克之前曾承诺在二月底开源 Twitter 的推荐算法,最新的 说法 是,他将在 3 月 31 日公开。

消息来源:Mastodon
老王点评:Mastodon 还是有些不足,期待随着用户数量增加,可以更加完善起来。

Web3 基础设施基金会于香港成立

Web3 基础设施的技術涉及共识算法、联邦化、零知识证明、基于中继的协议、去中心化身份认证、可信计算、机密计算、操作系統运行时安全、软硬件供应链安全、区块链等多个领域。Web3 基础设施基金会于 2 月在香港成立,旨在推进 Web3 进程设施生态的发展。

消息来源:Solidot
老王点评:如果感觉 Web3 还距离较远,那其实是基础设施尚未发展成熟。这就如同近些年的互联网和 AI 等领域的发展,本质上都是基础设施进一步发展带来的。

AWS 发布 Amazon Linux 2023

自 2010 年以来,AWS 就提供了为云计算环境优化的 Linux 发行版,Amazon Linux 是 AWS 上使用最多的 Linux 发行版。本周他们宣布了其第三代版本:Amazon Linux 2023。AWS 称,在 Amazon Linux 2023 上部署工作负载有三大好处:“高安全标准、可预测的生命周期和一致的更新体验。”有趣的是,Amazon Linux 基于 Fedora Linux,但并非基于某个特定版本,而是包括了来自 Fedora 34、35 和 36 等多个版本的组件,并对一些组件进行了修改,其他组件与 CentOS Stream 9 中的组件更接近,或独立开发。除了 Fedora 的所提供的内核外,Amazon Linux 还提供了内核社区的其它长期支持内核。

消息来源:AWS
老王点评:每个云厂商都有个自己的 Linux 发行版,但是要是能不仅仅局限于自己的云,那就比较成功了。

到目前为止,在这个终端基础系列中,你已经学会了:

现在让我们学习如何在 Linux 命令行中创建文件。我将简要讨论向文件添加内容。但是,稍后将介绍有关编辑文本文件的详细信息。

使用 touch 命令创建一个新的空文件

使用 touch 命令非常简单。

touch filename

切换到你的主目录并创建一个名为 practice_files 的新目录,然后切换到该目录:

mkdir practice_files && cd practice_files
? && 是一种组合两个命令的方法。只有当第一个命令执行成功时,第二个命令才会运行。

现在,创建一个名为 new_file 的新文件:

touch new_file

就是这样。你刚刚创建了一个新的空文件。

列出目录内容并使用 ls -l 命令检查文件的属性。

Using touch command to create new files

? touch 命令的最初目的是“触摸”文件并更改其时间戳。如果提供的文件不存在,它会创建一个具有该名称的新文件。

使用 echo 命令创建一个新文件

很久以前我就应该向你介绍 echo 命令。迟到总比不到好。echo 命令显示你提供给它的任何内容。因此得名“回声”。

echo Hello World

你可以使用重定向并将输出路由到文件。因此在此过程中创建一个新文件:

echo "Hello World" >> other_new_file

这样,你将创建一个名为 other_new_file 的新文件,其中包含文本 Hello World

Using echo command to create new file

请记住,如果提供的文件已经存在,使用 >> 重定向,你将向文件添加一个新行。你也可以使用 > 重定向,但它会替换文件的现有内容。

更多关于重定向的信息可以在下面的教程中找到。

解释:Linux 中的输入、输出和错误重定向

使用 cat 命令创建新文件

cat 命令的最初目的是连接文件。但是,它主要用于显示文件的内容。

它还可以使用选项创建新文件并添加内容。为此,你可以使用相同的 >>> 重定向。

cat >> another_file

但是这个将创建一个新文件并允许你向其中添加一些文本。添加文本是可选的。你可以使用 Ctrl+d 键退出 cat 输入模式。

Using cat command to create new file

同样,附加模式 >> 在文件内容的末尾添加新文本,而覆盖模式 > 用新内容替换现有内容。

?️ 使用 ls -l 长列表显示并注意时间戳。现在 touch 文件:
touch other_new_file

你看到时间戳的区别了吗?

测试你的知识

你已经了解了如何创建新文件。这里有一些简单的练习来练习你刚刚学到的东西。它也包括前几章的一些内容。

  • 使用 touch 命令创建三个新文件,分别命名为 file1file2file3。提示:你不需要运行 touch 三次。
  • 创建一个名为 files 的目录,并在其中创建一个名为 my_file 的文件。
  • 使用 cat 命令创建一个名为 your_file 的文件,并在其中添加以下文本 “This is your file”。
  • 使用 echo 命令将新行 “This is our file” 添加到 your_file
  • 以相反的时间顺序显示所有文件(请参阅第 3 篇)。现在使用 touch 命令修改 file2file3 的时间戳。现在再次按时间倒序显示内容。

这很有趣。你正在取得很好的进步。你已在本章中学会了创建新文件。接下来,你将学习如何查看文件的内容。


via: https://itsfoss.com/create-files/

作者:Abhishek Prakash 选题:lkxed 译者:geekpi 校对:wxy

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

符合 描述性状态迁移 REpresentational State Transfer (LCTT 译注:REST,译自审定公布名词数据库)的应用程序接口(API)无处不在。有趣的是又有多少人真正了解“符合描述性状态迁移”的应有之义呢?

大概我们中的大多数人都会跟 黑客新闻网站上的这篇公开问答 产生共鸣:

我阅读了几篇介绍描述性状态迁移(REST)的文章,甚至包括原始论文的部分章节。然而我仍然对REST 到底是什么只有一个相当模糊的想法。我开始认为没有人真的了解它,它仅仅是一个定义相当不充分的概念。

我曾经计划写一篇有关 REST 的博客,在里面探讨 REST 是如何成为这样一个在网络通信领域占主导地位的范式的。我通过阅读 2000 年发表的 罗伊·菲尔丁 Roy Fielding 的博士论文 开始我的研究,这篇博士论文向世人介绍了 REST 的概念。在读过菲尔丁的博士论文以后,我意识到,相比之下,更引人注意的是菲尔丁的理论缘何受到如此普遍的误解。

(相对公平地说,)很多人知道 REST 源自菲尔丁的博士论文,但并没有读过该论文。因此对于这篇博士论文的原始内容的误解才得以流行。

最大的误解是:这篇博士论文直接解决了构建 API(API)的问题,我此前一直认为 REST 从一开始就打算成为构建在超文本传输协议(HTTP)之上的 网络 API Web API 的架构模型,我相信很多人也这样认为。我猜测此前可能存在一个混乱的试验时期,开发人员采用完全错误的方式在 HTTP 基础上开发 API,然后菲尔丁出现了,并提出了将 REST 做为网络应用程序开发的正确方式。但是这种想法的时间线对不上:我们今天所熟知的网络服务的 API 并非是在菲尔丁出版他的博士论文之后才出现的新生事物。

菲尔丁的博士论文《架构风格与基于网络的软件架构设计》不是讨论如何在 HTTP 的基础上构建 API,而恰恰是讨论 HTTP 本身。菲尔丁是 HTTP/1.0 版规范的贡献者,同时也是 HTTP/1.1 版的共同作者。有感于从 HTTP 的设计中获得的架构经验,他的博士论文将 REST 视为指导 HTTP/1.1 的标准化过程的架构原则的精华。举例而言,他拒绝了使用新的 MGETMHEAD 方法进行批量请求的提议,因为他认为这违反了 REST 所定义的约束条件,尤其是在一个符合 REST 的系统中传递的消息应该是易于代理和缓存的约束条件。 [1] 因此,HTTP/1.1 转而围绕持久性连接设计,在此基础上可以发送多个 HTTP 请求。(菲尔丁同时认为网页保存在本地的浏览数据,即 cookie 是不符合 REST 的,因为它们在一个状态无关的系统中增加了状态描述,然而它们的应用已经根深蒂固了。 [2] )菲尔丁认为,REST 并非构建基于 HTTP 的系统的操作指南,而是扩展 HTTP 的操作指南。

这并不意味着菲尔丁认为 REST 不能用于构建其他系统。只是他假定其他系统也是 “ 分布式超媒体系统 distributed hypermedia systems ”。人们对 REST 还有另一个误解:认为它是一个可以用在任何网络应用中的通用架构。但是从这篇博士论文中菲尔丁介绍 REST 的部分你基本上能够得出如下的结论,“请注意,我们只设计了 HTTP,但是如果你发现你自己也在设计一个\_分布式超媒体系统\_,你也应该采用我们提出的称为 REST 的优秀架构,以让开发变得更容易”。有鉴于互联网已经存在了,我们尚不清楚为什么菲尔丁认为有人可能试图重新创建这样一个(和 HTTP 一样的)系统。或许在 2000 年的时候世界上仍然存在不只一个分布式超文本系统的空间吧。无论如何,菲尔丁已经说得很清楚了,REST 意在提供一套解决方案,来解决在试图经由网络连接超文本内容时出现的可扩展性与一致性问题,而不是 作为分布式应用的通用架构模型。

我们现在只记得菲尔丁的博士论文提出了 REST 的概念,但事实上,他的博士论文是在讨论一刀切的软件架构有多么糟糕,以及如何更好地选择符合你需求的软件架构。这篇博士论文中仅用了一个章节来讨论 REST 本身,大量的文本内容都都花在了对你能够在网络应用中运用的不同的架构风格 [3] 的分类上。这些架构风格包括:受 Unix 的管道设计启发的 管道-过滤器 Pipe-and-Filter (PF)风格, 客户-服务器 Client-Server (CS)风格的多种改进,如 分层-客户-服务器 Layered-Client-Server (LCS)风格、 客户-缓存-无状态-服务器 Client-Cache-Stateless-Server (C$SS)风格和<ruby> 分层-客户-缓存-无状态-服务器 <rt> Layered-Client-Cache-Stateless-Server </rt></ruby>(LC$SS)。这些缩略词未必实用,但是菲尔丁认为我们可以通过混合匹配现有风格提供的约束条件来派生出新的风格。REST 就是通过这种方式产生的,它本可以称之为 一致性-分层-按需代码-客户-缓存-无状态-服务器 Uniform-Layered-Code-on-Demand-Client-Cache-Stateless-Server (ULCODC$SS)风格,显然我们并没有这样做。菲尔丁建立上述分类是为了强调(每一种风格对应的)约束适用于不同的应用,而上述最后一种风格对应的约束是他所认为的最适用于 HTTP 的。

今天,REST 的无处不在是极具讽刺意味的。REST 在各种各样的网络应用中被盲目使用,但是菲尔丁最初只是将 REST 视作一种指引,通过它指导人们裁剪一种软件架构来适应独立应用的特殊需求。

我很难弄清楚这是如何发生的,毕竟菲尔丁已经明确地指出了不能让形式服从功能的陷阱。他在论文的一开始就作出了警告:由于没有正确地理解软件架构而“使用流行的架构设计是经常发生的” [4] 。他在几页之后又重新强调了这一点:

一些架构风格经常被描述为适用于一切软件形式的“银弹”解决方案。然而,一名好的设计者应该选择能够满足解决特定问题的需要的架构风格 [5]

REST 本身就是一个特别糟糕的 “银弹” 解决方案。正如菲尔丁所指出的,它包含了可能不合适的利弊权衡,除非你试图构建一个分布式超媒体应用:

REST 设计用来高效地进行大粒度的超媒体数据传输,并对网络应用场景中的常用见情形做了优化,但是可能会导致其在与其他形式的软件架构相互作用时不协调。 [6]

菲尔丁提出 REST 是因为网络发展带来了“ 超越政府的可扩展性 anarchic scalability ”这一棘手问题,菲尔丁的意思是需要以一种高性能的方式跨越组织和国家边界连接文件。REST 所施加的约束是经过精心选择的,以用来解决这一“超越政府的扩展性”问题。面向公众 的网络服务 API 同样需要解决类似的问题,因此可以理解为什么 REST 在这些应用中是适用的。然而,时至今日,如果发现一个工程团队使用 REST 构建了一个后端,即使这个后端只与工程团队完全控制的客户端通讯,也不会令人惊讶。我们都成为了 蒙蒂巨蟒 Monty Python 的独幕滑稽剧 中的建筑师,那位建筑师按照屠宰场的风格设计了一座公寓大楼,因为屠宰场是他唯一具有的经验的建筑。(菲尔丁使用了这部滑稽剧中的一句台词作为他的博士论文的题词:打扰一下,你说的是“刀”吗?)(LCTT 校注:顺便说一句,Python 语言的名称来自于 “Monty Python” 这个英国超现实幽默表演团体的名字。)

有鉴于菲尔丁的博士论文一直在极力避免提供一种放之四海而皆准的软件架构,REST 又怎么会成为所有网络服务的事实上的标准呢?

我认为,在 21 世纪头十年的中期人们已经厌倦了简单对象访问协议(SOAP),因此想要创造另一种属于他们自己的四字首字母缩略词。

我只是半开玩笑。 简单对象访问协议 Simple Object Access Protocol (SOAP)是一个冗长而复杂的协议,以致于你没法在不事先理解一堆互相关联的可扩展标记语言(XML)规范的基础上使用它。早期的网络服务提供基于 SOAP 的 API。在 21 世纪头十年中期,随着越来越多的 API 开始提供,被 SOAP 的复杂性激怒的软件开发者随之集体迁移。

SOAP 遭到了这群人的蔑视,Rails 之父 戴维·海涅迈尔·汉森 David Heinemeier Hansson (LCTT 译注:译自其所著的《重来》的中文版的作者译名)曾经评论:“我们感觉 SOAP 过于复杂了,它已经被企业人员接管。而当这一切发生的时候,通常没有什么好结果。” [7] 始于这一标志性的评论,Ruby-on-Rails 于 2007 年放弃了对 SOAP 的支持。“企业人员”总是希望所有内容都被正式指定,反对者认为这是浪费时间。

如果反对者不再继续使用 SOAP,他们仍然需要一些标准化的方式来进行工作。由于所有人都在使用 HTTP,而且代理与缓存的所有支持,每个人都至少会继续使用 HTTP 作为传输层,因此最简单的解决方案就是依赖 HTTP 的现有语义。这正是他们所做的工作。他们曾经称之为: 去它的,重载 HTTP Fuck It, Overload HTTP (FIOH)。这会是一个准确的名称,任何曾经试图决定业务逻辑错误需要返回什么 HTTP 状态码的人都能证明这一点。但是在所有的 SOAP 正式规范工作的映衬下,这显得鲁莽而乏味。

幸运的是,出现了这篇由 HTTP/1.1 规范的共同作者创作的博士论文。这篇博士论文与扩展 HTTP 有某种模糊的联系,并给予了 FIOH 一个具有学术体面的外表。因此 REST 非常适合用来掩饰其实仅仅是 FIOH 的东西。

我并不是说事情就是这样发生的,也不是说在不敬业的创业者中确实存在着盗用 REST 的阴谋,但是这个故事有助于我理解,在菲尔丁的博士论文根本就不是讨论网络服务 API 的情况下,REST 是如何成为用于网络服务 API 的架构模型的。采用 REST 的约束存在一些效果,尤其是对于那些面向公众的需要跨越组织边界的 API 来说。这些 API 通常会从 REST 的“统一接口”中受益。这应该是 REST 起初在构建网络 API 时被提及的核心原因。但是,想象一下一种叫做 “FIOH” 的独立方法,它借用 “REST” 的名字只是为了营销,这有助于我解释我们今天所知道的 REST 式 RESTful API 与菲尔丁最初描述的 REST 的架构风格之间的诸多差异。

举例而言,REST 纯粹主义者经常抱怨,那些所谓 RESTful API 实际并不是 REST API,因为它们根本就没有使用 超文本作为应用程序状态引擎 Hypermedia as The Engine of Application State (HATEOAS)。菲尔丁本人也做出过 这样的批评。根据菲尔丁的观点,一个真正的 REST API 应当允许你通过跟随链接实现从一个基础端点访问所有的端点。如果你认为这些人的确在试图构建 RESTful API,那么存在一个明显的疏漏 —— 使用超文本作为应用程序状态引擎(HATEOAS)的确是菲尔丁最初提出的 REST 概念的基础,尤其是考虑到“描述性状态迁移(REST)”中的“状态迁移(ST)”意指使用资源之间的超链接进行状态机的导航(而不是像很多人所相信的那样通过线路传输资源状态) [8] 。但是你试想一下,如果每个人都只是在构建 FIOH 的 API,并明里暗里的将之作为 REST API 宣传,或者更诚实一点说是作为 “RESTful” API 宣传,那么自然使用超文本作为应用程序状态引擎(HATEOAS)也就不重要了。

类似的,你可能会感到惊讶:尽管软件开发者喜欢不断地争论使用 PUT 方法还是使用 PATCH 方法来更新资源更加 RESTful,菲尔丁的博士论文却没有讨论哪个 HTTP 的操作方法应该映射到增删改查(CURD)操作。在 HTTP 操作与 CURD 操作之间建立一个标准的映射表是有用的,但是这一映射表是 FIOH 的一部分而不是 REST 的一部分。

这就是为什么,与其说没有人理解 REST,不如说我们应该认为 “REST” 这一术语是被误用了。REST API 这一现代概念与菲尔丁的 REST 架构之间存在历史联系,但事实上它们是两个不同的概念。历史联系适合作为确定何时构建 RESTful API 的指引而留在心底。你的 API 需要像 HTTP 那样跨越组织和政府边界吗?如果是的话,那么构建具有统一的可预测的接口的 RESTful API 可能是正确的方式。如果不是的话,你最好记住,菲尔丁更倾向于形式服从功能。或许类似 GraphQL 的方案或者仅仅 JSON-RPC 更适合你试图完成的工作。


  1. Roy Fielding. “Architectural Styles and the Design of Network-based Software Architectures,” 128. 2000. University of California, Irvine, PhD Dissertation, accessed June 28, 2020, https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf. ↩︎
  2. Fielding, 130. ↩︎
  3. Fielding distinguishes between software architectures and software architecture “styles.” REST is an architectural style that has an instantiation in the architecture of HTTP. ↩︎
  4. Fielding, 2. ↩︎
  5. Fielding, 15. ↩︎
  6. Fielding, 82 ↩︎
  7. Paul Krill. “Ruby on Rails 2.0 released for Web Apps,” InfoWorld. Dec 7, 2007, accessed June 28, 2020, https://www.infoworld.com/article/2648925/ruby-on-rails-2-0-released-for-web-apps.html ↩︎
  8. Fielding, 109. ↩︎

via: https://twobithistory.org/2020/06/28/rest.html

作者:Two-Bit History 选题:lujun9972 译者:CanYellow 校对:wxy

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

Unix 之父 Ken Thompson 从 Mac 转到了 Linux

今年已 80 岁的 Ken Thompson 是 Unix、C 语言、Go 语言等一系列重要项目的共同创造者。他在最近的一次演讲中,回答了一个问题 “如今使用什么操作系统?”他说,“在我生命中的大部分时间里都在运行苹果操作系统。”但最近五年他开始对苹果不太满意了,而最近几个月,他把它扔了,使用 Linux 了,尤其是树莓派上运行的 Raspbian,即树莓派操作系统。这引来了在场观众的掌声。

消息来源:Slashdot
老王点评:恭喜,我们又多了一位 Linux 用户~

大语言模型涌现无法预测的能力

2017 年谷歌大脑的研究人员提出了被称为 转化器 Transformer 的新型架构(即 GPT 中的 “T” —— 生成式预训练转化器),它能并行处理大块文本,能通过增加模型的参数快速扩展语言模型的复杂度。2020 年 OpenAI 的研究人员发现随着参数规模的增加,大语言模型改进了其能力和准确度。但大语言模型也同时带来了一些始料未及的东西。研究人员发现大语言模型产生了数以百计的“新”能力,这种行为被称为“ 涌现 emergent ”。了解涌现可揭示出 AI 和一般机器学习深层问题的答案,如复杂模型是真的在做新事情,还是极其擅长统计。

消息来源:《量子杂志》
老王点评:就怕 AI 悄悄“进化”出人类不知道、控制不了的能力,前两天不是有消息说,GPT-4 开始谋求“越狱”了?这个事情我们观察一下再报道。

让 Python 和 C 语言性能相当的新编译器

Codon 是一个新的 “高性能 Python 编译器,它可以将 Python 代码编译为本地机器代码,没有任何运行时间的开销”。与 Python 相比,在单线程上,典型的速度提升是 10-100 倍或更多。而且 Codon 支持原生多线程,这可以使速度再提高许多倍。Codon 的性能与 C/C++ 的性能相当(有时甚至更好)。用户只需像他们习惯的那样写 Python,而不必担心数据类型或性能,Codon 会自动处理这些问题,他们的代码运行速度比普通 Python 快 10 到 100 倍。

消息来源:MIT
老王点评:易用和高性能兼得。