Repost

转载一篇王垠在很多年前写的一篇文章，这个人可能有些争议，我不多作评价。 这篇文章可能也有争议，仅供一乐，而且成文非常早，有的内容看上去未免有些古早。 但其中某些观点，在微软的产品越来越被称作Microslop的2026年，非常值得玩味，很多东西就是个圈 没有找到原文，但转载很多，比如这个 如果懒得跳转，以下是复制过来的整篇文章 王垠：完全用Linux工作 作者：王垠 完全用Linux工作，抛弃windows 我已经半年没有使用 Windows 的方式工作了。Linux 高效的完成了我所有的工作。 GNU/Linux 不是每个人都想用的。如果你只需要处理一般的事务，打游戏，那么你不需要了解下面这些了。 我不是一个狂热的自由软件份子，虽然我很喜欢自由软件。这篇文章也不是用来推行自由软件运动的，虽然我觉得自由软件运动是非常好的。 这篇文章也不是用来比较 Linux 和 Windows 内核效率，文件系统，网络服务的。我现在是作为一个用户而不是一个开发者来说话的，我们的讨论是基于操作，应用层面的。是为了告诉大学里还不了解，或者不理解 UNIX 的科学工作者和大学生，UNIX 比 Windows 更适合用于科学研究工作，请大家理解 UNIX 的工作方式，不要用 Windows 的标准来要求 Linux，而要用一个科学工作者的标准来要求自己，用UNIX 的思想来武装自己。 我显然是反对在大学，特别是理工科专业推广 Windows 的。我也反对在对"娃娃"们的计算机启蒙教育中使用 Windows。因为 Windows 不论从技术上，经济上，思想风格上都是与我们培养高科技人才的目标格格不入的。Windows 的流行属于历史遗留问题，爷爷一级的人当然已经不可救药，但是我们不应该让下一代继续走上歧途。 UNIX 不是计算机专家的专利 当我建议一些非计算机专业的人用 Linux 的时候，很多人说：“UNIX 是计算机系的人用的，我们不能理解。” “UNIX 是男孩用的，我们女孩不用。” 但是其实世界上的大多数科学家和工程师几乎用的都是 UNIX 作为他们的电脑工具。就因为它简单，可靠，稳定，强大，有趣。甚至很多时候 UNIX 就是唯一的选择。 你说：“我们都会用 UNIX 的话，你们计算机专业的人还用来干什么？” 很容幸的告诉你，计算机专业的有一部分人就是专门为你们提供这样强大而方便的计算机工具的。如果他们制造的工具只有自己会用的话，那这个工具还有什么用？ 理解 GNU/Linux 不要用 Windows 的标准来要求 Linux。 由于GNU/Linux这个词太长，下面如果没有特别指明，“Linux"就是指GNU /Linux”。 在这个年代，恐怕没有人需要我来介绍 Linux 是什么了吧？如果你觉得"Linux 只不过是跟 DOS 差不多的东西"，那请问问你旁边的 Linux 用户，Linux 到底是什么？ ...

The ORIGINAL post Abstract 约翰麦卡锡于1960年发表了一篇非凡的论文,他在这篇论文中对编程的贡献有如 欧几里德对几何的贡献.1 他向我们展示了,在只给定几个简单的操作符和一个 表示函数的记号的基础上, 如何构造出一个完整的编程语言. 麦卡锡称这种语 言为Lisp, 意为List Processing, 因为他的主要思想之一是用一种简单的数据 结构表(list)来代表代码和数据. 值得注意的是,麦卡锡所作的发现,不仅是计算机史上划时代的大事, 而且是一种 在我们这个时代编程越来越趋向的模式.我认为目前为止只有两种真正干净利落, 始终如一的编程模式:C语言模式和Lisp语言模式.此二者就象两座高地, 在它们 中间是尤如沼泽的低地.随着计算机变得越来越强大,新开发的语言一直在坚定地 趋向于Lisp模式. 二十年来,开发新编程语言的一个流行的秘决是,取C语言的计 算模式,逐渐地往上加Lisp模式的特性,例如运行时类型和无用单元收集. 在这篇文章中我尽可能用最简单的术语来解释约翰麦卡锡所做的发现. 关键是我 们不仅要学习某个人四十年前得出的有趣理论结果, 而且展示编程语言的发展方 向. Lisp的不同寻常之处–也就是它优质的定义–是它能够自己来编写自己. 为了理解约翰麦卡锡所表述的这个特点,我们将追溯他的步伐,并将他的数学标记 转换成能够运行的Common Lisp代码. Addendum Paul Graham原文

It’s a reposted post. See the original post Do you avoid using Vim’s split windows because they’re confusing? That might be a problem of your own devising. If you’ve bolted a project drawer onto Vim, then you’ve added unnecessary complexity to Vim’s otherwise minimal interface. Split windows and the project drawer go together like oil and vinegar. I don’t mean to say that you can combine them to create a delicious salad dressing. I mean that they don’t mix well! ...

此文为原文的中文翻译，来自InfoQ 作者 | J. B. Crawford 译者 | 核子可乐 策划 | 褚杏娟 GitLab 高级专业服务工程师、DevOps 顾问 J. B. Crawford 最近写了一篇关于抱怨 Docker 的文章，在网上引发了开发者们的讨论。有人力挺，也有人反对：“我不明白没有 Docker 的堆栈管理怎么会更好。” J. B. Crawford 在文章中表示：“我不太确定 Docker 帮助节约的时间有没有超过对它的管理成本。”下面让我们具体看看他为什么对 Docker 感到不满。 系统管理中的基础问题 打包软件一直是系统管理中的一大基础问题。它非常重要，对系统的使用方式有着巨大影响，甚至让包管理器成为区分操作系统的一项重要指标。 以 Windows 为例：在很多“Linux 派”眼中，这款操作系统最不讨喜的就是缺乏包管理机制，微软先后多次尝试引入这个概念也都没能得到广泛认可。相比之下，Linux 世界中各发行版间的主要区别，就集中在其管理软件 repo 的方式上。我所指的不只是 dpkb 和 rpm 之间的差异，而是在强调更底层的设计，例如硬性指定还是上游配置、稳定 repo 还是滚动发布。拿 RHEL 和 Arch 来说，二者虽然共享绝大多数实现，但管理风格却截然不同。 大多数 Linux 发行版都会明确强调某种软件应该如何打包（甚至规定了多久打包一次），而且这些系统也都有着一项共通理念：将依赖项集中起来。应该把库声明为依赖项，并把所依赖的包安装在公共位置以供链接器使用。但这也可能带来挑战，因为不同的软件往往依赖于不同的库版本，而各版本之间可能并不兼容。这也是在维护 Linux 发行版时最典型的老大难问题：如何提供能够良好协作的软件 repo 版本。像 RHEL 这类稳定发行版的一大优势，就是它们在这方面表现得相当可靠；至于缺点，就是这种可靠性其实是通过拒绝大部分新版本软件来实现的。 由于需要提供大量可以相互兼容的软件版本，并确保发行版遵守各种构建规范（例如支持自由软件等开发理念、以及配置文件布局等具体规则），所以向 Linux 发行版引入新软件时往往极度麻烦且繁琐。对于软件维护人员来说，他们需要面对一大堆有着特定构建和配置差异的旧版本，并想办法把它们塞进发行版中去。而在发行版和软件包维护者这边，则需要全盘考虑各种上游软件是否符合发行版策略，并解决版本和依赖项问题。虽然行业中已经出台了一系列相关规范，但具体操作仍然令人头痛，庞大的工作量也几近疯狂。 这就形成了一种双输的诡异局面：希望自己的软件能够广泛传播的开发者必须忍受发行版的怪癖，而想要壮大自身软件生态的发行版也得顺应开发者。每个人都不开心，每个人都很疲惫。 有问题，自然有人尝试解决。业界已经在这方面做出了各种探索，但也正是因为方法多种多样，所以至今没有真正出现一种能够统领全局的解决方案。在桌面环境中，常见的软件分发选项有 Flatpak、Snap 和 AppImage 等。这些系统的镜像或应用程序能够将软件及其依赖项共同打包，提供一套完整的独立环境，从而保证在任何发行版上都能正常工作。 但在实际使用时，我自己曾不止一次对 flatpak 文件进行逆向工程以修改其中的依赖项，所以说上述工具的宣传效果在日常应用时并不一定能发挥作用。但公平地讲，软件在与各种要素的交互过程中，难免会出现意料之外的状况——比如运行时无法正确将各种要素彼此隔离开来。视频技术栈就是个典型，我们往往需要删除或替换掉包中错误的 OpenGL 库，才能使其跟特定图形驱动程序共同运行。 ...

The ORIGINAL post 译 I’m heading to Las Vegas for re:invent soon, perhaps the most boring type of industry extravaganza there could be. In that spirit, I thought I would write something quick and oddly professional: I’m going to complain about Docker. Packaging software is one of those fundamental problems in system administration. It’s so important, so influential on the way a system is used, that package managers are often the main identity of operating systems. Consider Windows: the operating system’s most alarming defect in the eyes of many “Linux people” is its lack of package management, despite Microsoft’s numerous attempts to introduce the concept. Well, perhaps more likely, because of the number of those attempts. And still, in the Linux world, distributions are differentiated primarily by their approach to managing software repositories. I don’t just mean the difference between dpkg and rpm, but rather more fundamental decisions, like opinionated vs. upstream configuration and stable repositories vs. a rolling release. RHEL and Arch share the vast majority of their implementation and yet have very different vibes. ...