2018年11月

LinuxBoot 是私有的 UEFI 固件的开源 替代品。它发布于去年,并且现在已经得到主流的硬件生产商的认可成为他们产品的默认固件。去年,LinuxBoot 已经被 Linux 基金会接受并纳入开源家族。

这个项目最初是由 Ron Minnich 在 2017 年 1 月提出,它是 LinuxBIOS 的创造人,并且在 Google 领导 coreboot 的工作。

Google、Facebook、Horizon Computing Solutions、和 Two Sigma 共同合作,在运行 Linux 的服务器上开发 LinuxBoot 项目(以前叫 NERF)。

它的开放性允许服务器用户去很容易地定制他们自己的引导脚本、修复问题、构建他们自己的 运行时环境 和用他们自己的密钥去 刷入固件,而不需要等待供应商的更新。

下面是第一次使用 NERF BIOS 去引导 Ubuntu Xenial 的视频:

我们来讨论一下它与 UEFI 相比在服务器硬件方面的其它优势。

LinuxBoot 超越 UEFI 的优势

LinuxBoot vs UEFI

下面是一些 LinuxBoot 超越 UEFI 的主要优势:

启动速度显著加快

它能在 20 秒钟以内完成服务器启动,而 UEFI 需要几分钟的时间。

显著的灵活性

LinuxBoot 可以用在 Linux 支持的各种设备、文件系统和协议上。

更加安全

相比 UEFI 而言,LinuxBoot 在设备驱动程序和文件系统方面进行更加严格的检查。

我们可能争辩说 UEFI 是使用 EDK II 而部分开源的,而 LinuxBoot 是部分闭源的。但有人提出,即便有像 EDK II 这样的代码,但也没有做适当的审查级别和像 Linux 内核 那样的正确性检查,并且在 UEFI 的开发中还大量使用闭源组件。

另一方面,LinuxBoot 有非常小的二进制文件,它仅用了大约几百 KB,相比而言,而 UEFI 的二进制文件有 32 MB。

严格来说,LinuxBoot 与 UEFI 不一样,更适合于可信计算基础

LinuxBoot 有一个基于 kexec 的引导加载器,它不支持启动 Windows/非 Linux 内核,但这影响并不大,因为主流的云都是基于 Linux 的服务器。

LinuxBoot 的采用者

自 2011 年, Facebook 发起了开源计算项目(OCP),它的一些服务器是基于开源设计的,目的是构建的数据中心更加高效。LinuxBoot 已经在下面列出的几个开源计算硬件上做了测试:

  • Winterfell
  • Leopard
  • Tioga Pass

更多 OCP 硬件在这里有一个简短的描述。OCP 基金会通过开源系统固件运行一个专门的固件项目。

支持 LinuxBoot 的其它一些设备有:

上个月底(2018 年 9 月 24 日),Equus 计算解决方案 宣布 发行它的 白盒开放式™ M2660 和 M2760 服务器,作为它们的定制的、成本优化的、开放硬件服务器和存储平台的一部分。它们都支持 LinuxBoot 灵活定制服务器的 BIOS,以提升安全性和设计一个非常快的纯净的引导体验。

你认为 LinuxBoot 怎么样?

LinuxBoot 在 GitHub 上有很丰富的文档。你喜欢它与 UEFI 不同的特性吗?由于 LinuxBoot 的开放式开发和未来,你愿意使用 LinuxBoot 而不是 UEFI 去启动你的服务器吗?请在下面的评论区告诉我们吧。


via: https://itsfoss.com/linuxboot-uefi/

作者:Avimanyu Bandyopadhyay 选题:oska874 译者:qhwdw 校对:wxy

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

Dropbox 正考虑将同步支持限制为少数几种文件系统类型:Windows 的 NTFS、macOS 的 HFS+/APFS 和 Linux 的 Ext4。

Dropbox ends support for various file system types

Dropbox 是最受欢迎的 Linux 中的云服务之一。很多人都在使用 Linux 下的 Dropbox 同步客户端。但是,最近,一些用户在他们的 Dropbox Linux 桌面客户端上收到一条警告说:

“移动 Dropbox 文件夹位置, Dropbox 将在 11 月停止同步“

Dropbox 将仅支持少量文件系统

一个 Reddit 主题强调了一位用户在 Dropbox 论坛上查询了该消息后的公告,该消息被社区管理员标记为意外新闻。这是回复中的内容:

“大家好,在 2018 年 11 月 7 日,我们会结束 Dropbox 在某些不常见文件系统的同步支持。支持的文件系统是 Windows 的 NTFS、macOS 的 HFS+ 或 APFS,以及Linux 的 Ext4。

Dropbox 官方论坛

Dropbox official confirmation over limitation on supported file systems

Dropbox 官方确认支持文件系统的限制

此举旨在提供稳定和一致的体验。Dropbox 还更新了其桌面要求

那你该怎么办?

如果你在不受支持的文件系统上使用 Dropbox 进行同步,那么应该考虑更改位置。

Linux 仅支持 Ext4 文件系统。但这并不是一个令人担忧的新闻,因为你可能已经在使用 Ext4 文件系统了。

在 Ubuntu 或其他基于 Ubuntu 的发行版上,打开磁盘应用并查看 Linux 系统所在分区的文件系统。

Check file system type on Ubuntu

检查 Ubuntu 上的文件系统类型

如果你的系统上没有安装磁盘应用,那么可以使用命令行了解文件系统类型

如果你使用的是 Ext4 文件系统并仍然收到来自 Dropbox 的警告,请检查你是否有可能收到通知的非活动计算机/设备。如果是,将该系统与你的 Dropbox 帐户取消连接

Dropbox 也不支持加密的 Ext4 吗?

一些用户还报告说他们在加密 Ext4 文件系统同步时也收到了警告。那么,这是否意味着 Linux 的 Dropbox 客户端只支持未加密的 Ext4 文件系统?这方面 Dropbox 没有官方声明。

你使用的是什么文件系统?你也收到了警告吗?如果你在收到警告后仍不确定该怎么做,你应该前往该方案的官方帮助中心页面

请在下面的评论中告诉我们你的想法。


via: https://itsfoss.com/dropbox-linux-ext4-only/

作者:Ankush Das 选题:lujun9972 译者:geekpi 校对:wxy

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

当程序员们谈论各类编程语言的相对优势时,他们通常会采用相当平淡的措词,就好像这些语言是一条工具带上的各种工具似的 —— 有适合写操作系统的,也有适合把其它程序黏在一起来完成特殊工作的。这种讨论方式非常合理;不同语言的能力不同。不声明特定用途就声称某门语言比其他语言更优秀只能导致侮辱性的无用争论。

但有一门语言似乎受到和用途无关的特殊尊敬:那就是 Lisp。即使是恨不得给每个说出形如“某某语言比其他所有语言都好”这类话的人都来一拳的键盘远征军们,也会承认 Lisp 处于另一个层次。 Lisp 超越了用于评判其他语言的实用主义标准,因为普通程序员并不使用 Lisp 编写实用的程序 —— 而且,多半他们永远也不会这么做。然而,人们对 Lisp 的敬意是如此深厚,甚至于到了这门语言会时而被加上神话属性的程度。

大家都喜欢的网络漫画合集 xkcd 就至少在两组漫画中如此描绘过 Lisp:其中一组漫画中,某人得到了某种 Lisp 启示,而这好像使他理解了宇宙的基本构架。

另一组漫画中,一个穿着长袍的老程序员给他的徒弟递了一沓圆括号,说这是“文明时代的优雅武器”,暗示着 Lisp 就像原力那样拥有各式各样的神秘力量。

另一个绝佳例子是 Bob Kanefsky 的滑稽剧插曲,《上帝就在人间》。这部剧叫做《永恒之火》,撰写于 1990 年代中期;剧中描述了上帝必然是使用 Lisp 创造世界的种种原因。完整的歌词可以在 GNU 幽默合集中找到,如下是一段摘抄:

因为上帝用祂的 Lisp 代码

让树叶充满绿意。

分形的花儿和递归的根:

我见过的奇技淫巧之中没什么比这更可爱。

当我对着雪花深思时,

从未见过两片相同的,

我知道,上帝偏爱那一门

名字是四个字母的语言。

(LCTT 译注:“四个字母”,参见:四字神名,致谢 no1xsyzy

以下这句话我实在不好在人前说;不过,我还是觉得,这样一种 “Lisp 是奥术魔法”的文化模因实在是有史以来最奇异、最迷人的东西。Lisp 是象牙塔的产物,是人工智能研究的工具;因此,它对于编程界的俗人而言总是陌生的,甚至是带有神秘色彩的。然而,当今的程序员们开始怂恿彼此,“在你死掉之前至少试一试 Lisp”,就像这是一种令人恍惚入迷的致幻剂似的。尽管 Lisp 是广泛使用的编程语言中第二古老的(只比 Fortran 年轻一岁) 1 ,程序员们也仍旧在互相怂恿。想象一下,如果你的工作是为某种组织或者团队推广一门新的编程语言的话,忽悠大家让他们相信你的新语言拥有神力难道不是绝佳的策略吗?—— 但你如何能够做到这一点呢?或者,换句话说,一门编程语言究竟是如何变成人们口中“隐晦知识的载体”的呢?

Lisp 究竟是怎么成为这样的?

Byte 杂志封面,1979年八月。

Byte 杂志封面,1979年八月。

理论 A :公理般的语言

Lisp 的创造者 约翰·麦卡锡 John McCarthy 最初并没有想过把 Lisp 做成优雅、精炼的计算法则结晶。然而,在一两次运气使然的深谋远虑和一系列优化之后,Lisp 的确变成了那样的东西。 保罗·格雷厄姆 Paul Graham (我们一会儿之后才会聊到他)曾经这么写道, 麦卡锡通过 Lisp “为编程作出的贡献就像是欧几里得对几何学所做的贡献一般” 2 。人们可能会在 Lisp 中看出更加隐晦的含义 —— 因为麦卡锡创造 Lisp 时使用的要素实在是过于基础,基础到连弄明白他到底是创造了这门语言、还是发现了这门语言,都是一件难事。

最初, 麦卡锡产生要造一门语言的想法,是在 1956 年的 达特茅斯人工智能夏季研究项目 Darthmouth Summer Research Project on Artificial Intelligence 上。夏季研究项目是个持续数周的学术会议,直到现在也仍旧在举行;它是此类会议之中最早开始举办的会议之一。 麦卡锡当初还是个达特茅斯的数学助教,而“ 人工智能 artificial intelligence (AI)”这个词事实上就是他建议举办该会议时发明的 3 。在整个会议期间大概有十人参加 4 。他们之中包括了 艾伦·纽厄尔 Allen Newell 赫伯特·西蒙 Herbert Simon ,两名隶属于 兰德公司 RAND Corporation 卡内基梅隆大学 Carnegie Mellon 的学者。这两人不久之前设计了一门语言,叫做 IPL。

当时,纽厄尔和西蒙正试图制作一套能够在命题演算中生成证明的系统。两人意识到,用电脑的原生指令集编写这套系统会非常困难;于是他们决定创造一门语言——他们的原话是“ 伪代码 pseudo-code ”,这样,他们就能更加轻松自然地表达这台“ 逻辑理论机器 Logic Theory Machine ”的底层逻辑了 5 。这门语言叫做 IPL,即“ 信息处理语言 Information Processing Language ”;比起我们现在认知中的编程语言,它更像是一种高层次的汇编语言方言。 纽厄尔和西蒙提到,当时人们开发的其它“伪代码”都抓着标准数学符号不放 —— 也许他们指的是 Fortran 6 ;与此不同的是,他们的语言使用成组的符号方程来表示命题演算中的语句。通常,用 IPL 写出来的程序会调用一系列的汇编语言宏,以此在这些符号方程列表中对表达式进行变换和求值。

麦卡锡认为,一门实用的编程语言应该像 Fortran 那样使用代数表达式;因此,他并不怎么喜欢 IPL 7 。然而,他也认为,在给人工智能领域的一些问题建模时,符号列表会是非常好用的工具 —— 而且在那些涉及演绎的问题上尤其有用。麦卡锡的渴望最终被诉诸行动;他要创造一门代数的列表处理语言 —— 这门语言会像 Fortran 一样使用代数表达式,但拥有和 IPL 一样的符号列表处理能力。

当然,今日的 Lisp 可不像 Fortran。在会议之后的几年中,麦卡锡关于“理想的列表处理语言”的见解似乎在逐渐演化。到 1957 年,他的想法发生了改变。他那时候正在用 Fortran 编写一个能下国际象棋的程序;越是长时间地使用 Fortran ,麦卡锡就越确信其设计中存在不当之处,而最大的问题就是尴尬的 IF 声明 8 。为此,他发明了一个替代品,即条件表达式 true;这个表达式会在给定的测试通过时返回子表达式 A ,而在测试未通过时返回子表达式 B而且,它只会对返回的子表达式进行求值。在 1958 年夏天,当麦卡锡设计一个能够求导的程序时,他意识到,他发明的 true 条件表达式让编写递归函数这件事变得更加简单自然了 9 。也是这个求导问题让麦卡锡创造了 maplist 函数;这个函数会将其它函数作为参数并将之作用于指定列表的所有元素 10 。在给项数多得叫人抓狂的多项式求导时,它尤其有用。

然而,以上的所有这些,在 Fortran 中都是没有的;因此,在 1958 年的秋天,麦卡锡请来了一群学生来实现 Lisp。因为他那时已经成了一名麻省理工助教,所以,这些学生可都是麻省理工的学生。当麦卡锡和学生们最终将他的主意变为能运行的代码时,这门语言得到了进一步的简化。这之中最大的改变涉及了 Lisp 的语法本身。最初,麦卡锡在设计语言时,曾经试图加入所谓的 “M 表达式”;这是一层语法糖,能让 Lisp 的语法变得类似于 Fortran。虽然 M 表达式可以被翻译为 S 表达式 —— 基础的、“用圆括号括起来的列表”,也就是 Lisp 最著名的特征 —— 但 S 表达式事实上是一种给机器看的低阶表达方法。唯一的问题是,麦卡锡用方括号标记 M 表达式,但他的团队在麻省理工使用的 IBM 026 键盘打孔机的键盘上根本没有方括号 11 。于是 Lisp 团队坚定不移地使用着 S 表达式,不仅用它们表示数据列表,也拿它们来表达函数的应用。麦卡锡和他的学生们还作了另外几样改进,包括将数学符号前置;他们也修改了内存模型,这样 Lisp 实质上就只有一种数据类型了 12

到 1960 年,麦卡锡发表了他关于 Lisp 的著名论文,《用符号方程表示的递归函数及它们的机器计算》。那时候,Lisp 已经被极大地精简,而这让麦卡锡意识到,他的作品其实是“一套优雅的数学系统”,而非普通的编程语言 13 。他后来这么写道,对 Lisp 的许多简化使其“成了一种描述可计算函数的方式,而且它比图灵机或者一般情况下用于递归函数理论的递归定义更加简洁” 14 。在他的论文中,他不仅使用 Lisp 作为编程语言,也将它当作一套用于研究递归函数行为方式的表达方法。

通过“从一小撮规则中逐步实现出 Lisp”的方式,麦卡锡将这门语言介绍给了他的读者。后来,保罗·格雷厄姆在短文《 Lisp 之根 The Roots of Lisp 》中用更易读的语言回顾了麦卡锡的步骤。格雷厄姆只用了七种原始运算符、两种函数写法,以及使用原始运算符定义的六个稍微高级一点的函数来解释 Lisp。毫无疑问,Lisp 的这种只需使用极少量的基本规则就能完整说明的特点加深了其神秘色彩。格雷厄姆称麦卡锡的论文为“使计算公理化”的一种尝试 15 。我认为,在思考 Lisp 的魅力从何而来时,这是一个极好的切入点。其它编程语言都有明显的人工构造痕迹,表现为 Whiletypedefpublic static void 这样的关键词;而 Lisp 的设计却简直像是纯粹计算逻辑的鬼斧神工。Lisp 的这一性质,以及它和晦涩难懂的“递归函数理论”的密切关系,使它具备了获得如今声望的充分理由。

理论 B:属于未来的机器

Lisp 诞生二十年后,它成了著名的《 黑客词典 Hacker’s Dictionary 》中所说的,人工智能研究的“母语”。Lisp 在此之前传播迅速,多半是托了语法规律的福 —— 不管在怎么样的电脑上,实现 Lisp 都是一件相对简单直白的事。而学者们之后坚持使用它乃是因为 Lisp 在处理符号表达式这方面有巨大的优势;在那个时代,人工智能很大程度上就意味着符号,于是这一点就显得十分重要。在许多重要的人工智能项目中都能见到 Lisp 的身影。这些项目包括了 SHRDLU 自然语言程序Macsyma 代数系统ACL2 逻辑系统

然而,在 1970 年代中期,人工智能研究者们的电脑算力开始不够用了。PDP-10 就是一个典型。这个型号在人工智能学界曾经极受欢迎;但面对这些用 Lisp 写的 AI 程序,它的 18 位地址空间一天比一天显得吃紧 16 。许多的 AI 程序在设计上可以与人互动。要让这些既极度要求硬件性能、又有互动功能的程序在分时系统上优秀发挥,是很有挑战性的。麻省理工的 彼得·杜奇 Peter Deutsch 给出了解决方案:那就是针对 Lisp 程序来特别设计电脑。就像是我那关于 Chaosnet 的上一篇文章所说的那样,这些 Lisp 计算机 Lisp machines 会给每个用户都专门分配一个为 Lisp 特别优化的处理器。到后来,考虑到硬核 Lisp 程序员的需求,这些计算机甚至还配备上了完全由 Lisp 编写的开发环境。在当时那样一个小型机时代已至尾声而微型机的繁盛尚未完全到来的尴尬时期,Lisp 计算机就是编程精英们的“高性能个人电脑”。

有那么一会儿,Lisp 计算机被当成是未来趋势。好几家公司雨后春笋般出现,追着赶着要把这项技术商业化。其中最成功的一家叫做 Symbolics,由麻省理工 AI 实验室的前成员创立。上世纪八十年代,这家公司生产了所谓的 3600 系列计算机,它们当时在 AI 领域和需要高性能计算的产业中应用极广。3600 系列配备了大屏幕、位图显示、鼠标接口,以及强大的图形与动画软件。它们都是惊人的机器,能让惊人的程序运行起来。例如,之前在推特上跟我聊过的机器人研究者 Bob Culley,就能用一台 1985 年生产的 Symbolics 3650 写出带有图形演示的寻路算法。他向我解释说,在 1980 年代,位图显示和面向对象编程(能够通过 Flavors 扩展)在 Lisp 计算机上使用)都刚刚出现。Symbolics 站在时代的最前沿。

Bob Culley 的寻路程序。

Bob Culley 的寻路程序。

而以上这一切导致 Symbolics 的计算机奇贵无比。在 1983 年,一台 Symbolics 3600 能卖 111,000 美金 16 。所以,绝大部分人只可能远远地赞叹 Lisp 计算机的威力和操作员们用 Lisp 编写程序的奇妙技术。不止他们赞叹,从 1979 年到 1980 年代末,Byte 杂志曾经多次提到过 Lisp 和 Lisp 计算机。在 1979 年八月发行的、关于 Lisp 的一期特别杂志中,杂志编辑激情洋溢地写道,麻省理工正在开发的计算机配备了“大坨大坨的内存”和“先进的操作系统” 17 ;他觉得,这些 Lisp 计算机的前途是如此光明,以至于它们的面世会让 1978 和 1977 年 —— 诞生了 Apple II、Commodore PET 和 TRS-80 的两年 —— 显得黯淡无光。五年之后,在 1985 年,一名 Byte 杂志撰稿人描述了为“复杂精巧、性能强悍的 Symbolics 3670”编写 Lisp 程序的体验,并力劝读者学习 Lisp,称其为“绝大数人工智能工作者的语言选择”,和将来的通用编程语言 18

我问过 保罗·麦克琼斯 Paul McJones (他在 山景城 Mountain View 计算机历史博物馆 Computer History Museum 做了许多 Lisp 的保护工作),人们是什么时候开始将 Lisp 当作高维生物的赠礼一样谈论的呢?他说,这门语言自有的性质毋庸置疑地促进了这种现象的产生;然而,他也说,Lisp 上世纪六七十年代在人工智能领域得到的广泛应用,很有可能也起到了作用。当 1980 年代到来、Lisp 计算机进入市场时,象牙塔外的某些人由此接触到了 Lisp 的能力,于是传说开始滋生。时至今日,很少有人还记得 Lisp 计算机和 Symbolics 公司;但 Lisp 得以在八十年代一直保持神秘,很大程度上要归功于它们。

理论 C:学习编程

1985 年,两位麻省理工的教授, 哈尔·阿伯尔森 Harold Hal Abelson 杰拉尔德·瑟斯曼 Gerald Sussman ,外加瑟斯曼的妻子 朱莉·瑟斯曼 Julie Sussman ,出版了一本叫做《 计算机程序的构造和解释 Structure and Interpretation of Computer Programs 》的教科书。这本书用 Scheme(一种 Lisp 方言)向读者们示范了如何编程。它被用于教授麻省理工入门编程课程长达二十年之久。出于直觉,我认为 SICP(这本书的名字通常缩写为 SICP)倍增了 Lisp 的“神秘要素”。SICP 使用 Lisp 描绘了深邃得几乎可以称之为哲学的编程理念。这些理念非常普适,可以用任意一种编程语言展现;但 SICP 的作者们选择了 Lisp。结果,这本阴阳怪气、卓越不凡、吸引了好几代程序员(还成了一种奇特的模因)的著作臭名远扬之后,Lisp 的声望也顺带被提升了。Lisp 已不仅仅是一如既往的“麦卡锡的优雅表达方式”;它现在还成了“向你传授编程的不传之秘的语言”。

SICP 究竟有多奇怪这一点值得好好说;因为我认为,时至今日,这本书的古怪之处和 Lisp 的古怪之处是相辅相成的。书的封面就透着一股古怪。那上面画着一位朝着桌子走去,准备要施法的巫师或者炼金术士。他的一只手里抓着一副测径仪 —— 或者圆规,另一只手上拿着个球,上书“eval”和“apply”。他对面的女人指着桌子;在背景中,希腊字母 λ (lambda)漂浮在半空,释放出光芒。

SICP 封面上的画作

SICP 封面上的画作。

说真的,这上面画的究竟是怎么一回事?为什么桌子会长着动物的腿?为什么这个女人指着桌子?墨水瓶又是干什么用的?我们是不是该说,这位巫师已经破译了宇宙的隐藏奥秘,而所有这些奥秘就蕴含在 eval/apply 循环和 Lambda 演算之中?看似就是如此。单单是这张图片,就一定对人们如今谈论 Lisp 的方式产生了难以计量的影响。

然而,这本书的内容通常并不比封面正常多少。SICP 跟你读过的所有计算机科学教科书都不同。在引言中,作者们表示,这本书不只教你怎么用 Lisp 编程 —— 它是关于“现象的三个焦点:人的心智、复数的计算机程序,和计算机”的作品 19 。在之后,他们对此进行了解释,描述了他们对如下观点的坚信:编程不该被当作是一种计算机科学的训练,而应该是“ 程序性认识论 procedural epistemology ”的一种新表达方式 20 。程序是将那些偶然被送入计算机的思想组织起来的全新方法。这本书的第一章简明地介绍了 Lisp,但是之后的绝大部分都在讲述更加抽象的概念。其中包括了对不同编程范式的讨论,对于面向对象系统中“时间”和“一致性”的讨论;在书中的某一处,还有关于通信的基本限制可能会如何带来同步问题的讨论 —— 而这些基本限制在通信中就像是光速不变在相对论中一样关键 21 。都是些高深难懂的东西。

以上这些并不是说这是本糟糕的书;这本书其实棒极了。在我读过的所有作品中,这本书对于重要的编程理念的讨论是最为深刻的;那些理念我琢磨了很久,却一直无力用文字去表达。一本入门编程教科书能如此迅速地开始描述面向对象编程的根本缺陷,和函数式语言“将可变状态降到最少”的优点,实在是一件让人印象深刻的事。而这种描述之后变为了另一种震撼人心的讨论:某种(可能类似于今日的 RxJS 的)流范式能如何同时具备两者的优秀特性。SICP 用和当初麦卡锡的 Lisp 论文相似的方式提纯出了高级程序设计的精华。你读完这本书之后,会立即想要将它推荐给你的程序员朋友们;如果他们找到这本书,看到了封面,但最终没有阅读的话,他们就只会记住长着动物腿的桌子上方那神秘的、根本的、给予魔法师特殊能力的、写着 eval/apply 的东西。话说回来,书上这两人的鞋子也让我印象颇深。

然而,SICP 最重要的影响恐怕是,它将 Lisp 由一门怪语言提升成了必要的教学工具。在 SICP 面世之前,人们互相推荐 Lisp,以学习这门语言为提升编程技巧的途径。1979 年的 Byte 杂志 Lisp 特刊印证了这一事实。之前提到的那位编辑不仅就麻省理工的新 Lisp 计算机大书特书,还说,Lisp 这门语言值得一学,因为它“代表了分析问题的另一种视角” 22 。但 SICP 并未只把 Lisp 作为其它语言的陪衬来使用;SICP 将其作为入门语言。这就暗含了一种论点,那就是,Lisp 是最能把握计算机编程基础的语言。可以认为,如今的程序员们彼此怂恿“在死掉之前至少试试 Lisp”的时候,他们很大程度上是因为 SICP 才这么说的。毕竟,编程语言 Brainfuck 想必同样也提供了“分析问题的另一种视角”;但人们学习 Lisp 而非学习 Brainfuck,那是因为他们知道,前者的那种 Lisp 视角在二十年中都被看作是极其有用的,有用到麻省理工在给他们的本科生教其它语言之前,必然会先教 Lisp。

Lisp 的回归

在 SICP 出版的同一年, 本贾尼·斯特劳斯特卢普 Bjarne Stroustrup 发布了 C++ 语言的首个版本,它将面向对象编程带到了大众面前。几年之后,Lisp 计算机的市场崩盘,AI 寒冬开始了。在下一个十年的变革中, C++ 和后来的 Java 成了前途无量的语言,而 Lisp 被冷落,无人问津。

理所当然地,确定人们对 Lisp 重新燃起热情的具体时间并不可能;但这多半是保罗·格雷厄姆发表他那几篇声称 Lisp 是首选入门语言的短文之后的事了。保罗·格雷厄姆是 Y-Combinator 的联合创始人和《Hacker News》的创始者,他这几篇短文有很大的影响力。例如,在短文《 胜于平庸 Beating the Averages 》中,他声称 Lisp 宏使 Lisp 比其它语言更强。他说,因为他在自己创办的公司 Viaweb 中使用 Lisp,他得以比竞争对手更快地推出新功能。至少,一部分程序员被说服了。然而,庞大的主流程序员群体并未换用 Lisp。

实际上出现的情况是,Lisp 并未流行,但越来越多 Lisp 式的特性被加入到广受欢迎的语言中。Python 有了列表推导式。C# 有了 Linq。Ruby……嗯,Ruby 是 Lisp 的一种。就如格雷厄姆之前在 2001 年提到的那样,“在一系列常用语言中所体现出的‘默认语言’正越发朝着 Lisp 的方向演化” 23 。尽管其它语言变得越来越像 Lisp,Lisp 本身仍然保留了其作为“很少人了解但是大家都该学的神秘语言”的特殊声望。在 1980 年,Lisp 的诞生二十周年纪念日上,麦卡锡写道,Lisp 之所以能够存活这么久,是因为它具备“编程语言领域中的某种近似局部最优” 24 。这句话并未充分地表明 Lisp 的真正影响力。Lisp 能够存活超过半个世纪之久,并非因为程序员们一年年地勉强承认它就是最好的编程工具;事实上,即使绝大多数程序员根本不用它,它还是存活了下来。多亏了它的起源和它的人工智能研究用途,说不定还要多亏 SICP 的遗产,Lisp 一直都那么让人着迷。在我们能够想象上帝用其它新的编程语言创造世界之前,Lisp 都不会走下神坛。


via: https://twobithistory.org/2018/10/14/lisp.html

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

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


  1. John McCarthy, “History of Lisp”, 14, Stanford University, February 12, 1979, accessed October 14, 2018, http://jmc.stanford.edu/articles/lisp/lisp.pdf
  2. Paul Graham, “The Roots of Lisp”, 1, January 18, 2002, accessed October 14, 2018, http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf.
  3. Martin Childs, “John McCarthy: Computer scientist known as the father of AI”, The Independent, November 1, 2011, accessed on October 14, 2018, https://www.independent.co.uk/news/obituaries/john-mccarthy-computer-scientist-known-as-the-father-of-ai-6255307.html.
  4. Lisp Bulletin History. http://www.artinfo-musinfo.org/scans/lb/lb3f.pdf
  5. Allen Newell and Herbert Simon, “Current Developments in Complex Information Processing,” 19, May 1, 1956, accessed on October 14, 2018, http://bitsavers.org/pdf/rand/ipl/P-850_Current_Developments_In_Complex_Information_Processing_May56.pdf.
  6. ibid.
  7. Herbert Stoyan, “Lisp History”, 43, Lisp Bulletin #3, December 1979, accessed on October 14, 2018, http://www.artinfo-musinfo.org/scans/lb/lb3f.pdf
  8. McCarthy, “History of Lisp”, 5.
  9. ibid.
  10. McCarthy “History of Lisp”, 6.
  11. Stoyan, “Lisp History”, 45
  12. McCarthy, “History of Lisp”, 8.
  13. McCarthy, “History of Lisp”, 2.
  14. McCarthy, “History of Lisp”, 8.
  15. Graham, “The Roots of Lisp”, 11.
  16. Guy Steele and Richard Gabriel, “The Evolution of Lisp”, 22, History of Programming Languages 2, 1993, accessed on October 14, 2018, http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf.[↩](#fnref16)[↩sup1/sup](#fnref16:1)
  17. Carl Helmers, “Editorial”, Byte Magazine, 154, August 1979, accessed on October 14, 2018, https://archive.org/details/byte-magazine-1979-08/page/n153.
  18. Patrick Winston, “The Lisp Revolution”, 209, April 1985, accessed on October 14, 2018, https://archive.org/details/byte-magazine-1985-04/page/n207.
  19. Harold Abelson, Gerald Jay. Sussman, and Julie Sussman, Structure and Interpretation of Computer Programs (Cambridge, Mass: MIT Press, 2010), xiii.
  20. Abelson, xxiii.
  21. Abelson, 428.
  22. Helmers, 7.
  23. Paul Graham, “What Made Lisp Different”, December 2001, accessed on October 14, 2018, http://www.paulgraham.com/diff.html.
  24. John McCarthy, “Lisp—Notes on its past and future”, 3, Stanford University, 1980, accessed on October 14, 2018, http://jmc.stanford.edu/articles/lisp20th/lisp20th.pdf.

为开源项目作贡献最好的方式是为它减少代码,我们应致力于写出让新手程序员无需注释就容易理解的代码,让维护者也无需花费太多精力就能着手维护。

在学生时代,我们会更多地用复杂巧妙的技术去挑战新的难题。首先我们会学习循环,然后是函数啊,类啊,等等。当我们到达一定高的程度,能用更高级的技术写更长的程序,我们会因此受到称赞。此刻我们发现老司机们用 monads 而新手们用 loop 作循环。

之后我们毕业找了工作,或者和他人合作开源项目。我们用在学校里学到的各种炫技寻求并骄傲地给出解决方案的代码实现。

哈哈,我能扩展这个项目,并实现某牛 X 功能啦,我这里能用继承啦,我太聪明啦!

我们实现了某个小的功能,并以充分的理由觉得自己做到了。现实项目中的编程却不是针对某某部分的功能而言。以我个人的经验而言,以前我很开心的去写代码,并骄傲地向世界展示我所知道的事情。有例为证,作为对某种编程技术的偏爱,这是用另一种元编程语言构建的一个 线性代数语言,注意,这么多年以来一直没人愿意碰它。

在维护了更多的代码后,我的观点发生了变化。

  1. 我们不应去刻意探求如何构建软件。软件是我们为解决问题所付出的代价,那才是我们真实的目的。我们应努力为了解决问题而构建较小的软件。
  2. 我们应使用尽可能简单的技术,那么更多的人就越可能会使用,并且无需理解我们所知的高级技术就能扩展软件的功能。当然,在我们不知道如何使用简单技术去实现时,我们也可以使用高级技术。

所有的这些例子都不是听来的故事。我遇到的大部分人会认同某些部分,但不知为什么,当我们向一个新项目贡献代码时又会忘掉这个初衷。直觉里用复杂技术去构建的念头往往会占据上风。

软件是种投入

你写的每行代码都要花费人力。写代码当然是需要时间的,也许你会认为只是你个人在奉献,然而这些代码在被审阅的时候也需要花时间理解,对于未来维护和开发人员来说,他们在维护和修改代码时同样要花费时间。否则他们完全可以用这时间出去晒晒太阳,或者陪伴家人。

所以,当你向某个项目贡献代码时,请心怀谦恭。就像是,你正和你的家人进餐时,餐桌上却没有足够的食物,你只索取你所需的部分,别人对你的自我约束将肃然起敬。以更少的代码去解决问题是很难的,你肩负重任的同时自然减轻了别人的重负。

技术越复杂越难维护

作为学生,逐渐使用高端技术证明了自己的价值。这体现在,首先我们有能力在开源项目中使用函数,接着是类,然后是高阶函数,monads 等等。我们向同行显示自己的解决方案时,常因自己所用技术高低而感到自豪或卑微。

而在现实中,和团队去解决问题时,情况发生了逆转。现在,我们致力于尽可能使用简单的代码去解决问题。简单方式解决问题使新手程序员能够以此扩展并解决其他问题。简单的代码让别人容易上手,效果立竿见影。我们藉以只用简单的技术去解决难题,从而展示自己的价值。

看,我用循环替代了递归函数并且一样达到了我们的需求。当然我明白这是不够聪明的做法,不过我注意到新手同事在这里会遇上麻烦,我觉得这种改变将有所帮助吧。

如果你是个好的程序员,你不需要证明你知道很多炫技。相应的,你可以通过用一个简单的方法解决一个问题来显示你的价值,并激发你的团队在未来的时间里去完善它。

当然,也请保持节制

话虽如此,过于遵循 “用简单的工具去构建” 的教条也会降低生产力。通常用递归会比用循环解决问题更简单,用类或 monad 才是正确的途径。还有两种情况另当别论,一是只是只为满足自我而创建的系统,或者是别人毫无构建经验的系统。


via: http://matthewrocklin.com/blog/work/2018/01/27/write-dumb-code

作者:Matthew Rocklin 译者:plutoid 校对:wxy

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

如果你是一个 Linux 方面的新手,你可能会在 morelessmost 这三个命令行工具之间产生疑惑。在本文当中,我会对这三个命令行工具进行对比,以及展示它们各自在 Linux 中的一些使用例子。总的来说,这几个命令行工具之间都有相通和差异,而且它们在大部分 Linux 发行版上都有自带。

我们首先来看看 more 命令。

more 命令

more 是一个老式的、基础的终端分页阅读器,它可以用于打开指定的文件并进行交互式阅读。如果文件的内容太长,在一屏以内无法完整显示,就会逐页显示文件内容。使用回车键或者空格键可以滚动浏览文件的内容,但有一个限制,就是只能够单向滚动。也就是说只能按顺序往下翻页,而不能进行回看。

更正

有的 Linux 用户向我指出,在 more 当中是可以向上翻页的。不过,最原始版本的 more 确实只允许向下翻页,在后续出现的较新的版本中也允许了有限次数的向上翻页,只需要在浏览过程中按 b 键即可向上翻页。唯一的限制是 more 不能搭配管道使用(如 ls | more)。(LCTT 译注:此处原作者疑似有误,译者使用 more 是可以搭配管道使用的,或许与不同 more 版本有关)

q 即可退出 more

更多示例

打开 ostechnix.txt 文件进行交互式阅读,可以执行以下命令:

$ more ostechnix.txt

在阅读过程中,如果需要查找某个字符串,只需要像下面这样输入斜杠(/)之后接着输入需要查找的内容:

/linux

n 键可以跳转到下一个匹配的字符串。

如果需要在文件的第 10 行开始阅读,只需要执行:

$ more +10 file

就可以从文件的第 10 行开始显示文件的内容了。

如果你需要让 more 提示你按空格键来翻页,可以加上 -d 参数:

$ more -d ostechnix.txt

如上图所示,more 会提示你可以按空格键翻页。

如果需要查看所有选项以及对应的按键,可以按 h 键。

要查看 more 的更多详细信息,可以参考手册:

$ man more

less 命令

less 命令也是用于打开指定的文件并进行交互式阅读,它也支持翻页和搜索。如果文件的内容太长,也会对输出进行分页,因此也可以翻页阅读。比 more 命令更好的一点是,less 支持向上翻页和向下翻页,也就是可以在整个文件中任意阅读。

在使用功能方面,lessmore 命令具有更多优点,以下列出其中几个:

  • 支持向上翻页和向下翻页
  • 支持向上搜索和向下搜索
  • 可以跳转到文件的末尾并立即从文件的开头开始阅读
  • 在编辑器中打开指定的文件

更多示例

打开文件:

$ less ostechnix.txt

按空格键或回车键可以向下翻页,按 b 键可以向上翻页。

如果需要向下搜索,在输入斜杠(/)之后接着输入需要搜索的内容:

/linux

n 键可以跳转到下一个匹配的字符串,如果需要跳转到上一个匹配的字符串,可以按 N 键。

如果需要向上搜索,在输入问号(?)之后接着输入需要搜索的内容:

?linux

同样是按 n 键或 N 键跳转到下一个或上一个匹配的字符串。

只需要按 v 键,就会将正在阅读的文件在默认编辑器中打开,然后就可以对文件进行各种编辑操作了。

h 键可以查看 less 工具的选项和对应的按键。

q 键可以退出阅读。

要查看 less 的更多详细信息,可以参考手册:

$ man less

most 命令

most 同样是一个终端阅读工具,而且比 moreless 的功能更为丰富。most 支持同时打开多个文件。你可以在打开的文件之间切换、编辑当前打开的文件、迅速跳转到文件中的某一行、分屏阅读、同时锁定或滚动多个屏幕等等功能。在默认情况下,对于较长的行,most 不会将其截断成多行显示,而是提供了左右滚动功能以在同一行内显示。

更多示例

打开文件:

$ most ostechnix1.txt

e 键可以编辑当前文件。

如果需要向下搜索,在斜杠(/)或 Sf 之后输入需要搜索的内容,按 n 键就可以跳转到下一个匹配的字符串。

如果需要向上搜索,在问号(?)之后输入需要搜索的内容,也是通过按 n 键跳转到下一个匹配的字符串。

同时打开多个文件:

$ most ostechnix1.txt ostechnix2.txt ostechnix3.txt

在打开了多个文件的状态下,可以输入 :n 切换到下一个文件,使用 键选择需要切换到的文件,按回车键就可以查看对应的文件。

要打开文件并跳转到某个字符串首次出现的位置(例如 linux),可以执行以下命令:

$ most file +/linux

h 键可以查看帮助。

按键操作列表

移动:

  • 空格键或 D 键 – 向下滚动一屏
  • DELETE 键或 U 键 – 向上滚动一屏
  • 键 – 向下移动一行
  • 键 – 向上移动一行
  • T 键 – 移动到文件开头
  • B 键 – 移动到文件末尾
  • > 键或 TAB 键 – 向右滚动屏幕
  • < 键 – 向左滚动屏幕
  • 键 – 向右移动一列
  • 键 – 向左移动一列
  • J 键或 G 键 – 移动到某一行,例如 10j 可以移动到第 10 行
  • % 键 – 移动到文件长度某个百分比的位置

窗口命令:

  • Ctrl-X 2Ctrl-W 2 – 分屏
  • Ctrl-X 1Ctrl-W 1 – 只显示一个窗口
  • O 键、Ctrl-X O – 切换到另一个窗口
  • Ctrl-X 0 – 删除窗口

文件内搜索:

  • S 键或 f 键或 / 键 – 向下搜索
  • ? 键 – 向上搜索
  • n 键 – 跳转到下一个匹配的字符串

退出:

  • q 键 – 退出 most ,且所有打开的文件都会被关闭
  • :N:n – 退出当前文件并查看下一个文件(使用 键、 键选择下一个文件)

要查看 most 的更多详细信息,可以参考手册:

$ man most

总结

more – 传统且基础的分页阅读工具,仅支持向下翻页和有限次数的向上翻页。

less – 比 more 功能丰富,支持向下翻页和向上翻页,也支持文本搜索。在打开大文件的时候,比 vi 这类文本编辑器启动得更快。

most – 在上述两个工具功能的基础上,还加入了同时打开多个文件、同时锁定或滚动多个屏幕、分屏等等大量功能。

以上就是我的介绍,希望能让你通过我的文章对这三个工具有一定的认识。如果想了解这篇文章以外的关于这几个工具的详细功能,请参阅它们的 man 手册。


via: https://www.ostechnix.com/the-difference-between-more-less-and-most-commands/

作者:SK 选题:lujun9972 译者:HankChow 校对:wxy

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

欢迎回到我们为了构建更快网页所写的系列文章。本系列的第一部分第二部分讲述了如何通过优化和替换图片来减少浏览器脂肪。本部分会着眼于在 CSS(层叠式样式表)和字体中减掉更多的脂肪。

调整 CSS

首先,我们先来看看问题的源头。CSS 的出现曾是技术的一大进步。你可以用一个集中式的样式表来装饰多个网页。如今很多 Web 开发者都会使用 Bootstrap 这样的框架。

这些框架当然方便,可是很多人都会将整个框架直接复制粘贴走。Bootstrap 非常大:目前 Bootstrap 4.0 的“最小”版本也有 144.9 KB. 在这个以 TB 来计数据的时代,它可能不算多。但就像所说的那样,一头小牛也能搞出大麻烦。

我们回头来看 getfedora.org 的例子。我们在第一部分中提过,第一个分析结果显示 CSS 文件占用的空间几乎比 HTML 本身还要大十倍。这里显示了所有用到的样式表:

那是九个不同的样式表。其中的很多样式在这个页面中并没有用上。

移除、合并、以及压缩/缩小化

Font-awesome CSS 代表了包含未使用样式的极端。这个页面中只用到了这个字体的三个字形。如果以 KB 为单位,getfedora.org 用到的 font-awesome CSS 最初有 25.2 KB. 在清理掉所有未使用的样式后,它只有 1.3 KB 了。这只有原来体积的 4% 左右!对于 Bootstrap CSS,原来它有 118.3 KB,清理掉无用的样式后只有 13.2 KB,这就是差异。

下一个问题是,我们必须要这样一个 bootstrap.cssfont-awesome.css 吗?或者,它们能不能合起来呢?没错,它们可以。这样虽然不会节省更多的文件空间,但浏览器成功渲染页面所需要发起的请求更少了。

最后,在合并 CSS 文件后,尝试去除无用样式并缩小它们。这样,它们只有 4.3 KB 大小,而你省掉了 10.1 KB.

不幸的是,在 Fedora 软件仓库中,还没有打包好的缩小工具。不过,有几百种在线服务可以帮到你。或者,你也可以使用 CSS-HTML-JS Minify,它用 Python 编写,所以容易安装。现在没有一个可用的工具来净化 CSS,不过我们有 UnCSS 这样的 Web 服务。

字体改进

CSS3 带来了很多开发人员喜欢的东西。它可以定义一些渲染页面所用的字体,并让浏览器在后台下载。此后,很多 Web 设计师都很开心,尤其是在他们发现了 Web 设计中图标字体的用法之后。像 Font Awesome 这样的字体集现在非常流行,也被广泛使用。这是这个字体集的大小:

current free version 912 glyphs/icons, smallest set ttf 30.9KB, woff 14.7KB, woff2 12.2KB, svg 107.2KB, eot 31.2

所以问题是,你需要所有的字形吗?很可能不需要。你可以通过 FontForge 来去除这些无用字形,但这需要很大的工作量。你还可以用 Fontello. 你可以使用公共实例,也可以配置你自己的版本,因为它是自由软件,可以在 Github 上找到。

这种自定义字体集的缺点在于,你必须自己来托管字体文件。你也没法使用其它在线服务来提供更新。但与更快的性能相比,这可能算不上一个缺点。

总结

现在,你已经做完了所有对内容本身的操作,来最大限度地减少浏览器加载和解释的内容。从现在开始,只有服务器的管理技巧才才能帮到你了。

有一个很简单,但很多人都做错了的事情,就是使用一些智能缓存。比如,CSS 或者图片文件可以缓存一周。但无论如何,如果你用了 Cloudflare 这样的代理服务或者自己构建了代理,首先要做的都应该是缩小页面。用户喜欢可以快速加载的页面。他们会(默默地)感谢你,服务器的负载也会更小。


via: https://fedoramagazine.org/design-faster-web-pages-part-3-font-css-tweaks/

作者:Sirko Kemter 选题:lujun9972 译者:StdioA 校对:wxy

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