此文为原文的中文翻译，来自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. ...

Introduction Many people would say that configuring Vim/Emacs(or some other obsession with tools) is time-consuming and even be “a waste of time” 1. The core point is that tools are paths to the goal, not the goal itself. Quoted2: Obsession with tools is an insidious form of procrastination. This form of resistance masquerades itself as the opposite, as a form of improvement and development. It really reveal one of the reasons why some people are obsessed with tools. I quite agree with it (thus I am not an Emacs guy :) ). ...

If you find problems … Points for me to setup my server: Configure as root user is better, although non-root users still can find a way to do it (as the following). Set your web root folder to somewhere you have write access to. For example, $HOME/www/html. For Nginx to access to your new web root, you might want to change the user in the nginx.conf, otherwise you could encounter a failure when issuing a cert. By the way, in my opinion, using acme.sh is better than CertBot on a virtualised machine, such as a VPS, because the latter doesn’t support the OpenVz architecture(but the setup is simpler, more or less), which is usually the cheapest type that you can buy. ...

I’ve been using zsh as my main shell for years. It works really well, and I love it. But recently, I started to give fish a try, and I found it is great and have set it as my default shell on my Mac. I’m gonna give you my reasons, for your reference. Its autosuggestion and completion functionalities work out of the box, which I would have to download oh-my-zsh for zsh. It’s nice but annoying to sync between devices. In fish, you don’t need any other plugins and settings, they just work. Actually that’s the main reason for me, then I can sync my configurations with my dotfiles. It is really friendly for configuration. I’m not a great hacker and not the kind of guy who wants to dive in everything. Fish offer a web-based config interface. You can invoke it by typing fish_config in the shell, then you can configure your shell by clicking the UI, AND the changes you make are essentially text in several files, which you can carry them with whatever your sync system is. Zsh is strong and nice, but some of its syntax and concepts(some inherited from the older sh/bash) are really hard to understand. For example, “variable substitution” or the “$@/$?/…” stuff. I don’t think they are human-readable. Fish shell language, however, is more like a modern programming language, with better documentation(type help in fish, you will also get a web-based doc!) But I’m not saying that I will use fish ONLY and FOREVER. Zsh is also great and better for some scenarios, so here are my opinions about what kind of people may want to use zsh, even bash. ...