Posts

A talk from TED STATUS ANXIETY EMBRACE MEDIOCRITY SYMBOLIC VIOLENCE THE COURAGE TO BE ORDINARY Avoid doing “symbolic violence” to ourselves.

今天去看了个电影《年会不能停》，说来也好笑，我其实没有看到任何这个电影的宣发，居然还是偶然刷脉脉发现的，再经过同事的力荐，周六晚上在考虑要干嘛时，“鬼使神差"地买下了周日的电影票。我不是专业的影评人，这篇文章也没有什么深思熟虑，是最直接的、即兴的观后感，写到哪儿算哪儿吧。 我不常去电影院看电影（正版侠求放过..），更少看喜剧电影，因为我相信的是优秀的喜剧内核都是悲剧。我是个还蛮多愁善感的人，很容易会不自主都想到它悲剧的一面。我不想让自己在休息之余，还要让自己的精神受到这样的"折磨”，所以我看一些影视作品，更多的是看一些纯粹的情绪输出的，亲情、友情（甚至爱情😢），包括一些所谓"爆米花"的作品，我觉得可能才是我作为社畜的我更需要的，在生活中压抑得太久，需要一个输出口，让自己暂时忘记一些东西，所以我很少看喜剧电影。 但这部作品，我是在同事的强力推荐下去看的。同事嘛，你懂的，大家都在一个环境下，是有一些情感共鸣在的，我就是抱着这样的想法，去了电影院的。老实说，这个电影的故事还是很简单的，甚至就是个"正义打败邪恶"的故事。但我觉得它是对得起它的口碑的，至少对于我来说，它确实给了我这样卑微的打工人足够的情绪输出点。当然我也有一些其他的感受，随便列列吧。 没有什么鸡汤（或许有一丢丢），没有什么政治正确，能带动打工人的情绪，引起大家的共鸣。 片头的那一段历史，多少还是让人会有些感触吧。 让大家在影院笑，一起笑。虽然这些个大家心领神会、不约而同的笑点背后其实是很残酷的社会现实，但它确实让社畜们在影院里，暂时忘记了职场上那操蛋的一切。 “互联网"只是电影的外壳，除了"裁员”、“互联网黑话"和"英文昵称"之外，电影想讽刺的、观众想输出的东西，难道不是在整个社会，这难道不是在互联网之外的国企们或者体制内更甚吗？老实说除了裁员之外，后两者在其他地方，只是以别的形式展现了不是吗。不取昵称，也有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! ...

🌐 English version 此文为原文的中文翻译，来自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 等。这些系统的镜像或应用程序能够将软件及其依赖项共同打包，提供一套完整的独立环境，从而保证在任何发行版上都能正常工作。 ...