产品

用了大半年，最近卸载了。整体来说，不如最开始的期待。优点仍在，但缺点对于重度使用者来说，难以忍受。 将常见应用做到开箱即用，这是个很大的贡献，也是目前所有 Linux 发行版里做的最好的一个，这点不可抹杀。但正如其他的一些本地化分支一样，稳定性都相比于 Debian/Ubuntu 大幅度降低了。这点在长期使用中会逐渐暴露出来，并且抵消掉前者带来的优势。如果UOS想继续好好做下去，后面的着力点也应该是这个。 就我的体验来说，问题主要是以下几个： 电脑发热明显，最开始是非夏天用的感觉还不明显，到了夏天非常严重。而换了ubuntu之后好转。 移除了添加repo的一些命令，让开发者很难受 界面稳定性差，基本上难以做到经常不关机 这里面部分是 Deepin 的问题，部分是 UOS 的问题了。其他的国内的发行版总体来说都是更差。 从产品角度来说，用户想要什么以及该怎么做其实是很明显的。既然有这个人力物力了，就应该定好优先级，把这些核心的问题解决好，这样才能普及开来。 另外从美观程度上来讲，不算差，但也不算太好。很多方面也不如 Ubuntu 的 Unity. 如何用统一美观的设计语言去做出一个美观好用的界面，应该就是下一阶段的重点了。

除了 Emacs 和 Vim 之外的 Editor 战争，现在看起来 VSCode 已经赢了。 先不说现存的一些 Editor 的现状和对比，我们直接猜想一下一个比较完美的 editor 应该是什么样子的 modern look. 就是好看，让人想用. 易上手: 不需要学太多才能才能用好 易扩展: 就是 plugin 多到满足常用需求 跨平台，方便配置 这几点就差不多了，能做到这几点基本上就能做到广受欢迎了。下面一个一个细拆开讲讲. 决定特性 Modern Look 这点最成功的案例就是 JetBrains 的一系列产品，单是其 Darcula theme 就让多少人愿意试一试。Atom 和 VSCode, LightTable， Sublime 做的也都不错， Vim 和 Emacs 做的不行，太古老了。虽然可以配置好的好看，但默认配置太劝退了。 易上手 这点 vim 和 Emacs 还是做的最差，虽然最终效率最高，但学习曲线太漫长了。VSCode 和 Atom 比较像，做的都不错。 易扩展 但从扩展性上来讲，Atom/VSCode/Vim/Emacs都差不多，该有的插件都有，安装也不难。不过前两个明显使用起来更方便些，是真正的易扩展,直接在 UI上就可以点点安装 plugin。也有方便的介绍和使用说明。LightTable 插件太少，半死不活的。Sublime 插件也不算多。 跨平台 跨平台的能力不难做，前面提到的几个都能做到。难的是尽量保证一致性的体验和性能。这里面 VSCode 做的最好， Atom 是在哪个平台性能都不咋样.Emacs在Linux下性能最好，Mac下 UI 效果一般, Windows 下配置着更麻烦。Vim 主要是 Terminal 领域了。 ...

经历了 N 次在各个不同的环境里初始化 Hexo 的环境失败之后，我终于换了 Hugo. 从 Jekyll -> Hexo -> Hugo 我算是发现了，依赖不好处理的平台根本不适合做 static blog generator.想在一个新的环境里部署好一个这样的软件，而且你又没有这个语言的比较多的经验的时候，大量的时间会被浪费在配置环境上。这时候，像 hugo 这样的 static binary 就是一个 killer feature, 我根本不用看它有什么优缺点，就直接切换过来了。 事实上也是，从互联网的内容检索上来看，大部分的迁移路线基本上就是 Jekyll,Hexo -> Hugo, 基本上没有反着来的。 先不说 Golang 语言设计的怎么样，但说能如此方便地 build 出来一个 cross-platform 的 static binary, 简直是造福程序员。 曾经，我以为 Hexo 的 theme 与 content 分离已经很优秀了。没想到它还是个垃圾。

统信 UOS 是今年国产化浪潮中比较出风头的一个做国产操作系统的公司。这几天换掉了我的 Manjaro 装上了 UOS 体验了一下。总体来说，可以打七八十分吧。 单说这个分数可能不是很好度量它究竟是个什么水平。可以横向对比一下，分两个方面。一个是底座上，linux 发行版里, Deepin 团队做的很出色，现在基本上是排名第十左右的发行版(按流行程度)。UOS 是基于 Deepin 改的，底座上有了不错的保证。 再跟国内这一众国产操作系统比的话，那简直是碾压。红旗之类的不用说，之前中国软件的麒麟，基于 Ubuntu 来改的( Deepin 的底座也是Ubuntu), 做了这么多年，了解 Linux 的基本上没啥好感，还不如 Ubuntu。因为国产操作系统向来上先往政企方面推，像麒麟这种大概率是拿到之后用户基本上就闲置不用了，继续用 Windows了。UOS 终于让人看到一点希望，至少，看起来让人有想尝试一直用用的念头了。 国产操作系统怎么做的问题，其实就是 Linux 桌面版怎么做的问题，虽然我们也自有国情在此。从操作系统内核来讲， Linux 比 Windows/MAC 并不差，问题全出在软件生态上。主要原因有以下几个: 非商业模式。只要商业公司才能做出像 Adobe / Oracle 这样的软件。有赚钱的目标，合理的分工及 KPI, 再卖出去软件形成一个正向循环。Linux 生态里有点像现在各家的 Andriod, 还更差，基本上连个统一付钱买软件的地方都没有，再说 Linux 用户普遍还没有养成这样的习惯 开发者太容易分散人力开发类似的项目了。大家对项目有了争议，可以立马基于当前版本重新立一个新项目，分开开发。这就导致现在 Linux 已经有了几百个发行版，N 个桌面系统，每一类软件都有 N 个不同的产品。除了个别的项目之外，大部分都不好用。 没有领导，群龙无首。跟上面说的两个问题相关。内核发展的好，是因为有强有力的领导。但桌面系统，基本上就是百家争鸣，谁也不服谁 这些问题杂糅起来，就形成了一个恶性循环。 Linux 桌面不好用 -> 用的人少 -> Linux 桌面发展缓慢，程序员各自魔改 -> 用的人更少。所以导致现在的局面就是，你想要一个方便使用的 Linux 桌面，如果没有一点编程背景，总会有一天栽在一个无法解决的最基本的硬件问题上。蓝牙坏了，网络连不上，显示器连不上，显卡配置不好等等在 MAC/WIN 上很少碰到的问题上。 假设硬件的问题解决了，那么更难的来了: 软件。国内因为更加封闭的互联网生态这个问题更加严重。让用户苹果/Wechat 二选一，大部分人会放弃苹果，Linux 也类似，没有微信这些软件，没有正常用户会喜欢用 Linux。问题摆在这，那么国产操作系统怎么做的答案也就呼之欲出了: ...

Hadoop 严格来说并不算完全失败了，不像 Mesos 那样，而是人们期待它成为一个大象， 而它却变成了一只兔子。 我刚毕业就开始接触Hadoop, 当时它基本上就是大数据的代名词。在这个光辉的表象之下，研发人原面临的是一个非常不透明，UI丑陋，运行缓慢的系统。当然，技术的狂热周期会让人放弃自己的疑虑，专心地去这座 shit mountain 扒拉东西。另外，也没得选。 同样的情况也发生在 Jenkins, Mesos 身上，当没有对比的时候，人们很难意识到自己面对的东西的优缺点是什么。时至今日，在吃尽了很多苦头之外，我们可以回过头来想想，为什么有的软件成功了？为什么有的失败了？ 成功的特性几乎是不言自明的，我们可以列举如下： 模块化 / 可扩展性好 接口用户友好 (页面，编程语言，API) 文档全面 这些就够了。而失败软件在每一方面，几乎都没做好。Hadoop 也是如此。 同时因为这些因素存在，人们从最初的狂热清醒下来之后，便开始想尽一切办法找寻可能的替代品。在数据量不大的时候尽量选择其他工具(pandas, unix tools等等)， Spark, Hive, Pig…. 甚至连 Hadoop 第二代的 YARN 都被 Kubernetes 无意打残了。当然，这个现状有一个比较好的词叫生态圈，但它和 Kuberentes 的生态圈还是很不同的。前者是因为太难用，被肢解，被不断替代。后者是根系稳固，枝叶繁茂。（没写完，待补。） Links What happened to Hadoop Don’t use Hadoop - your data isn’t that big Command-line Tools can be 235x Faster than your Hadoop Cluster Let’s build a modern Hadoop 与 Hadoop 对比，如何看待 Spark 技术？ Hadoop再凉凉，前大数据独角兽公司MapR被惠普企业（HPE）收购 驳「Hadoop 快不行了」 Hadoop 不再权威，开源大数据的未来何去何从？ The dark side of Hadoop

Mesos/Marathon 的失败，怎么说，太过典型了。如教科书一般，清晰的不能再清晰。 首先，它流行的时候，是因为大家没得选。一个还在蹒跚学步阶段的 Kubernetes 就开始将它打的节节败退。到了现在，连Mesosphere 已经转向了 Kubernetes。 从一开始，这就是一个学术界的产品。由一堆并不擅长编写工业化软件的研究室的学生和老师写出。这导致了 Mesos / Marathon 的致命缺陷 首先，用 C++ 写 Mesos， C++可以说是学术界和工业界态度差别最大的编程语言了。对学术界来说，这是一个可以用来探究编程语言极限的编程语言，数不清的高级设计，数不清的语言学设计，你再任何其他语言里都见不到这么博大精深的体系。但对工业界来说，这是一种灾难级的编程语言。Linux 都在天天骂它，难学难用难调试，市场占有率也一直不断下滑。Mesos 选择了 C++之后，极大地减少了开源社区去贡献代码的可能性，彻底沦为了创世的开发团队自己的作品。 更灾难的是，Marathon 用了 Scala，一个除了 C++之外第二复杂的语言。其同样程度的撕裂性，对研发人员的折磨，让人都开始怀疑为什么当初要选择编程这份工作。语言设计者一旦觉得自己过于聪明，会趋向出设计出来大众难以理解的东西。这并不怪大众，而是怪语言设计者。两个世界上最复杂的语言，组合起来，成了一个大部分研发人员都不愿意碰的黑盒子。然而，它又不是稳定到不出什么问题，总会有出故障需要排查的时候。这便是让所有人都痛苦的时刻。所以即使今天大家发现 Kubernetes 已经非常复杂难以理解了，但没有人会抱怨太多，因为只要你肯花点时间，分析分析代码，总能慢慢理解。而对于 Mesos/Marathon,如果你发现了一个问题，想去阅读代码，大部分时间你都在纠结：这个语法什么意思？这个语法又是什么意思？ 另外一种研究室出来的代码的问题在于，很少有人会考虑到架构的可扩展性。有了一个 idea,实现出来，发个 paper，大部分就完了。等到真正开始用户多的时候已经来不及了。而工业界的产品不一样，从一开始可扩展性就是所有系统在设计之初必须考虑的一个问题。所以我们看到，Mesos/Marathon 自发布之后，后续的功能扩充是极其微弱的，难以有任何实质性的功能增强。而 Kubernetes 在发布之后，新功能如井喷一般。当然这里面也有编程语言本身的功能。Golang 问题再多，简单易用本身就足够让很多人开始使用了。

我想记录一下工作中使用过的软件里的一些在设计上比较失败的。因为它们，工作中多了很多痛苦。 Jenkins 便是其中之一。跟很多软件一样，Jenkins 在商业上是成功的，成功的原因就是用户并没有什么选择。对 Jenkins 非常了解的人来说，能很容易列举出非常多的详细的jenkins 的问题。从一个普通使用者的角度来看，最直观的两个感觉就是: Jenkinsfile 难写，流水线很慢。 对我来讲，Jenkinsfile 就是最大的设计败笔。从工作中的反馈来看，即使看了文档，也没人知道怎么去写一个正确的 Jenkinsfile。用户想描述好一些流水线步骤，最直观的想法应该就是贴近于 Makefile, 每个步骤几条命令，清清楚楚。再加上其他一些并发控制，产出物管理即可。用 YAML 或者 TOML 这样的配置文件即可。 几乎除了 Jenkins 之外的所有 CI/CD 工具，都选择了 用YAML。而 Jenkins 使用了 Jenkinsfile, Groovy 语言，意味着用户需要首先了解 Groovy，在学习 jenkins的语法，才能写好 Jenkinsfile。一些自作聪明的开发人员在类似的设计问题时，会有一种炫技的想法，总想用 DSL 来解决问题。结果通常是不好的，既给用户带来了沉重的负担，也让系统变得难以理解。基于 JVM 的很多语言都是如此命运。 即使你费劲千辛万苦，终于写出了一个能跑通的 Jenkinsfile,这时候你会发现，在 Jenkins 的流水线里面，有很多复杂的难以理解的东西。为什么多出来很多莫名其妙的步骤？系统日志和构建日志怎么这么杂乱无章地堆在一块？为什么速度总是这么慢？界面为什么这么丑？不一而足。 想深刻地理解这些问题在哪，当然可以去好好探究一下它的架构，然后了解这些问题的根源。但这是在没有必要了，对于一个将死的系统来说。作为用户来讲，在已经有了替代品之后，赶快逃离就是了。

Helm is big success for sure, it’s nearly the standard application package format in kubernetes.You only need to provide some metadata about your application’s name, version, description….Helm can help you package up and upload to a central or custom chart repo.Just like npm,rpm,docker image, or whatever other package management system. About a year ago, Helm3 was drafted. Since it’s still on the proposal stage, most users are still using helm2, include us. The journey we spent with helm was not a very pleasant one, we struggled very hard to make it work. In the end, we decided to create a kubernetes controller based on Helm3 proposal, it works well and we open source it on github: captain. ...

考虑良久，决定将 Blog 迁移到 hexo。整个过程比想象的简单很多，也看了下二者的异同。相对于来讲，我觉得 hexo 在设计上比 jekyll 更为优良一些，更适合作为一个静态博客生成器。 那么，jekyll 的问题在哪? 目录结构 jekyll 的目录结构是 posts/themes/settings 等杂糅在一起，初看起来更好理解，但使用起来是很痛苦的。尤其是在更换 theme 的时候，需要小心翼翼地甄别哪些目录需要更换而哪些不需要。而 hexo 的目录结构更加清晰，每个 themes 的内容都包含在一个单独的目录中，与其他部分互不干扰。想要更换 theme 直接 clone 一个新的改一个配置参数即可。 更换 theme 的次数越多，jekyll 的目录结构会越来越乱，分不清哪些文件是当前必须的。而 hexo 没这个问题。 默认主题 jekyll 没有默认主题。或者说有，但大家不这样用。通常的用法都是找一个现成的第三方 blog clone 下来，然后按自己的需求改。这样有个问题就是，总会有一种不适配的感觉。因为主题都是别人为自己的使用配置的。而 hexo 提供了默认的主题，它是这个软件自带的一部分，是理所应当的属于我们自身的。而且这个默认的主题已经足够好用，同时第三方的next主题也占据了相当大的份额。不是说选择少，而是在 hexo 上能够更快地完成theme配置这一环而专注于内容。 功能 jekyll 各个 theme 的功能丰富程度差别很大，分页、评论、TAG 等等。不同主题想要添加新功能的方式不同，遇到问题处理的简易程度也不一样。而这种情况也往往导致用户会选择更换主题，然后继续恶性循环。hexo 的默认主题提供了对大多数常用功能的支持，而扩充起来也比较方便，不同主题在这块的差别也比较小。 内容发布 这块 jekyll 完全没做，必须得自己手动创建 md，添加头部的 attribute,之前还借鉴了其他人的 shell 脚本来根据模板自动生成这些内容。而 hexo 提供了new命令来创建新的 post,自动补上头部的内容，这样学习成本基本上就只剩 markdown 了。 目前静态博客软件的内容发布还是太偏程序员化了，可以参考 wordpress 的地方还有很多。目前已经有一些 admin 页面的项目流行起来，但还没有达到能让普通用户无学习成本使用的程度。 其他 目前静态博客的分化是好事，但有点像 linux distros 那样，最终也带来了很多恶性循环。大家不关注易用性去普及用户，而更关注彼此设计理念的不同。一堆程序员圈地自嗨，最终可能只是落得自娱自乐罢了。

一个语言的流行程度与多种因素相关,语法的简易性，package 的数量，性能，适用的场景等等。Perl 因为语法的怪异而逐渐无人问津，ROR因性能等问题也用的人越来越少。 一向处于主流地位的 C/CPP 在这几年也比不上 JavaScript 以及 Golang 的热度。在 Github 上，我们可以看到热门的项目中，JS 以及 Golang 等热门语言占据了相当瞩目的位置。 语言之间的较量从来就不是在单纯的语言层面本身，而是整个生态系统的对比。而不知不觉间，Github 也成了每个语言生态体系的一部分。 当代的主流程序员中，大多数都有 C/CPP 的语言背景。但在大部分的工作选择上，python 与 Golang 的数量越来越多，也越来越占主流。究其原因，一方面是在语法层面上，采用了与 C 相似而更简单的表达方式。但更重要的是，从一开始，他们就考虑到了包管理系统的重要性，因为它是语言生态系统的发动机，而 C/CPP 等语言到现在仍未有一个内建的实现。 对 Python 而言，在 Github 流行之前，pip 已经非常成熟。这让他成为了一个在任何需求面前都是被优先选择的语言之一。http 请求、web 框架、爬虫、图片解析等等，只要你想要的任何功能，都可以在 pip 里找到已经有的实现。有了 Github 之后，python 的 package 的数量的扩充进一步加快。代码在 github,二进制包在 pip,文档在 readthedocs,这是一个非常完善而让人信任的体系。 对于 Golang 来说，它就是生于 Github,流行于 Github 的。从一开始 docker/kubernetes 项目的流行，以及整个容器生态的成熟，给了 golang 一个良好的开端。go 内置的对于 github 上代码仓库的支持，即使有很多小问题，但总体来讲，这让 golang 以极快的速度建立起来了超越于 c/cpp 甚至能赶上 python/pip 的生态体系。在常规的开发场景以及业务需求上，golang 以及没有短板了。 而反观 c/cpp，在 github 之前，假设我们想要去找一个 package，只能借助于搜索引擎。也许在某些奇怪的网站上，能找到一个实现方案。但是相比于 golang/github 模式，这样的方式有明显的缺陷: ...

早期互联网的美妙之处在于，它真的是万维网,由无数的由个人或者公司搭建的互联网。没有如此大公司固定平台的限制，这些网站充满了无数的可能性。 之前工作无聊时发现的一个the useless web, 它给了我们一个magit button,每次点击都可以打开一个新的神奇的无聊网站： 有最神奇的可以随鼠标晃动的东西: 一个向下拉有无限长的腿的马: 一个不知道什么的隐喻： 被偷了 bucket 的海象… 这是一个几乎无限长的例子。几乎也是自由互联网的意义所在。很像<Rick and Morty>里他们看的宇宙电台一样，无穷无尽的稀奇古怪的电视节目。 无尽的无趣，比有限的伪装要好太多了。

每个程序员都会遇到这一天，他要做一个决定，vim 还是 emacs,还是 IDE。 近来一直主要用 Golang, 早已不再年轻的我自然是选择功能强大的 Goland, 日常工作无压力。即使没有免费的注册码了，我也毫不犹豫地买了正版。只是，它太慢了，太卡了，16GB 内存的 Mac 跑起来都不轻松。 在无数次的痛苦的等待中，我终于决定换一个 Editor 试一试。Atom 也慢，Code 看起来都很不错，插件多，界面舒服，速度也快，但我面对它总有一种无所适从的感觉。我偶尔会用它来做些零碎的工作，但从来没法把它当作 一个主要的开发工具。 这几天偶然翻起来一直装在电脑里确很久没有打开的 Emacs, 才明白了 Code 的问题在哪。 Code 是一个优秀的 Editor, 但也仅此而以。我们用它来写代码，代码和 Editor 是两个东西。我们要学习怎么去使用这个软件，这个学习的过程和写代码是两套系统。它像 PS,像 Word，是一个精巧的软件，是编程的产物。 而 Emacs 不同，它是一个 Editor, 但又和任何的 Editor 不同。它即是一个精巧的软件，也是一个操作系统，也是编程本身。 首先，它基于 Elisp 编写，是 lisp 到今天少有的面向大众的软件产品。他的所有扩展也都是 lisp 代码。lisp 良好的可读性能让人很容易理解一个扩展是怎么写出来的，你可以如何修改它，照着它写一个新的。你在用它的时候，能明确地感觉到你在写的代码和编辑器不是分离的两个东西。它不是一个服务于你的黑盒子，而是一个对你透明的软体。你可以随时打开它看看他的内在，修改它，调整它，让他的形态更适用于你的需求。在很多人使用 emacs 的时候，会经常发现，你打开的文件列表经常会有 lisp 代码。好像他们属于一个项目似的。 elisp 主要的功能都是面向文本编辑的，所以它比普通的 editor 有更多的概念: 缓冲区/ring buffer/minibuf/mode-line 等等。这些概念加起来，造就了最为精准丰富的文本处理和表现系统。无数在其他 editor 无法实现或者很难实现的功能，在这里都可以很容地用代码写出来。是的，就是用 elisp 代码。最终，是 elisp 代码组成了 emacs, 而对其他的 editor 来说，组成他们的是基本功能 + 扩展。 Editor/IDE 的分化，是因为用常规的软件设计思路，无法作出一个满足以下功能的开发工具: ...