今天去看了个电影《年会不能停》，说来也好笑，我其实没有看到任何这个电影的宣发，居然还是偶然刷脉脉发现的，再经过同事的力荐，周六晚上在考虑要干嘛时，“鬼使神差"地买下了周日的电影票。我不是专业的影评人，这篇文章也没有什么深思熟虑，是最直接的、即兴的观后感，写到哪儿算哪儿吧。 我不常去电影院看电影（正版侠求放过..），更少看喜剧电影，因为我相信的是优秀的喜剧内核都是悲剧。我是个还蛮多愁善感的人，很容易会不自主都想到它悲剧的一面。我不想让自己在休息之余，还要让自己的精神受到这样的"折磨”，所以我看一些影视作品，更多的是看一些纯粹的情绪输出的，亲情、友情（甚至爱情😢），包括一些所谓"爆米花"的作品，我觉得可能才是我作为社畜的我更需要的，在生活中压抑得太久，需要一个输出口，让自己暂时忘记一些东西，所以我很少看喜剧电影。 但这部作品，我是在同事的强力推荐下去看的。同事嘛，你懂的，大家都在一个环境下，是有一些情感共鸣在的，我就是抱着这样的想法，去了电影院的。老实说，这个电影的故事还是很简单的，甚至就是个"正义打败邪恶"的故事。但我觉得它是对得起它的口碑的，至少对于我来说，它确实给了我这样卑微的打工人足够的情绪输出点。当然我也有一些其他的感受，随便列列吧。 没有什么鸡汤（或许有一丢丢），没有什么政治正确，能带动打工人的情绪，引起大家的共鸣。 片头的那一段历史，多少还是让人会有些感触吧。 让大家在影院笑，一起笑。虽然这些个大家心领神会、不约而同的笑点背后其实是很残酷的社会现实，但它确实让社畜们在影院里，暂时忘记了职场上那操蛋的一切。 “互联网"只是电影的外壳，除了"裁员”、“互联网黑话"和"英文昵称"之外，电影想讽刺的、观众想输出的东西，难道不是在整个社会，这难道不是在互联网之外的国企们或者体制内更甚吗？老实说除了裁员之外，后两者在其他地方，只是以别的形式展现了不是吗。不取昵称，也有XX总；没有"抓手”/“颗粒度”，也有"贯彻"/“纠正”；那些可有可无的"废话"和所谓的"领导之术"，是在大型互联网企业独有的吗？ 不过讲真，“吕子乔"的"颗粒度"演出反而让我觉得稍有些尬，有点刻意去靠这种阿里味的烂梗了（阿里对不起，不是刻意贬低，只是这确实是很多人的"互联网黑话"的印象起源）不知道是不是刻意演成这样的。 没怎么看过白客以前的作品，感觉他在这片子里有点小帅的，特别是最后屋顶爆发的那一下。 “小道消息才可靠呢” ，真实。 想要一个没有年龄歧视、公平公正的职场环境，已经是一种理想主义了。 潘妮很飒、很漂亮、很潇洒，也是全片我最羡慕的一个人，因为她虽然看得明白，也委曲求全过，但最终仍然去追求自己当歌手的梦想了。 你问我推不推荐，推荐。你不用想这么多，喜剧电影的第一个作用：搞笑，它是够格的，去到电影院，放开所有，去笑，去让演员代替你发泄情绪就好了。也许它并没有解决现实里的任何问题，它至少也能当个充电宝，让你暂时放下一些东西，去补充你的精神能量。 最后，我也想你一个问题，看完这个片子后，你会羡慕谁呢，是回到厂子的胡建林、是追逐梦想的潘妮、还是最终升职加薪的马杰克呢？

常见使用方式： 打开IDE/编辑器中的“文件资源管理器”(File Explorer)，用鼠标一级一级点开 在导航栏里打开对应目录，缩小搜索范围 在标签页上 优点 直观，在有一定其他工具使用经验的背景下，几乎没有学习成本 在只有浅层级搜索时，并不是很影响效率 缺点 层级多/同时打开的文件多时，搜索效率可能会降低 需要不断重复定位、搜索、确认这一流程，加之手可能需要再“心流”状态可能被打断 推荐的替代方案 聚集于可预测的单一窗口，复用文件搜索和展示文件内容功能，（Where Split Windows and the Project Drawer comes into play ），并使用“模糊搜索”的工具/技巧。 什么是模糊搜索 模糊搜索的优缺点 优点 只要键盘还是人机交互的主要途径之一，以及在键盘密集型的工作场景里，在多数情况下，效率是高过直白使用鼠标的 搜索范围会缩小得很快，因此筛选过程非常快 结合“可预测的单一窗口”这一理念，几乎不存在你需要额外确认这个文件会从哪里跳出来，或者窗口布局会发生什么样的变化（而让你需要反应一下）。 可以选用各种各样的模糊搜索工具，也可以组合使用，来进一步提升搜索效率 缺点 一些其他的场景，比如简单切换，比如“在两个文件间来回切换”这个场景，效率并不是很高 效率建立在一定的打字速度和搜索技巧上，否则会适得其反 我正在使用的模糊搜索工具 FZF fzf.vim telescope.nvim VSCode 有类似思想的工具 搜索引擎的“关键字搜索” gopls的workspace_symbol接口 …

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. ...