从许多角度来说，Linux kernel这个项目在用的工具都太过时了，远远落后于现代的孩子们经常用的工具。kernel的工作流程在过去几年表现都很好，不过已经有些迹象表明它不会永远保持不变。一直以来都有一些讨论关于如何改善kernel的工作流程，不过基本还没怎么真正动起来。最近新提出的一个名为get-lore-mbox的简单工具可能预示了工作流程的改进会逐渐加速。
kernel项目一直以来都依赖email，这一点让许多人感到很惊奇，觉得它很过时。这也许真的跟kernel社区开发人员的年龄层次有关。许多开发者，尤其是那些重要的maintainer们，都是在那些基于网页的git服务管理网站出现之前就开始做现在的工作了。许多人其实还用过打孔编程的方式，他们中的许多人仍然没有接受文本编辑器的价值。不过，kernel一直依赖emal的真正的原因其实还是因为没有多少其他工具可以用来支撑这么大规模以及多样化的一个社区。
所以，尽管看起来email（这里不是指那些Gmail这类的公司服务）的未来还不是很明确，但是kernel社区后续会有什么替换工具还很不明朗。首先需要能说服开发者们，新工具会让他们更轻松，而不是更麻烦。对于那些非常繁忙的maintainer来说，如果有什么改进方式会让做事情更慢，他们一定不会接受的。
Konstantin Ryabitsev提出的get-lore-tool并不是一个需要大量开发工作的产物，它仅仅有500行左右的Python代码。核心功能很简单：提供某封email的message ID，它会为你从lore.kernel.org下载完整的email thread，生成一个车本地的mbox文件。这个功能本身其实对所有需要了解某个email塔轮的来龙去脉的人都有用，不过它还拥有许多有用的功能：
-a 选项，只会下载这个email thread中最核心的那一系列patch文件，排好序并整理好格式，方便直接传递给git am命令。同时在email thread中如果有一些回复里包含有用的tag（例如Acked-by），也会自动加到相应的patch上去。
-t 选项，可以把那些只回复给这组patch的cover letter的tag都打到这组中所有的patch上面去。
如果这个email thread中有多个版本的patch，那么只会保存最新一个版本的patch文件。也可以用 -v 选项来指定要求某个特定版本的patch文件。
如果没有提供message ID，此工具可以从标准输入中读入一个email message，提取出message ID。这样在许多邮件阅读软件里面只要按一个键就可以完成所有工作了。
Kernel maintainer经常需要花许多时间来阅读email thread，从中整理patch，打上tag，等等。这个工具一发出来，最早的反馈（也包括在kernel.org内部用户的邮件列表上的反馈）都是说这是他们长久以来一直渴求的工具。仅需要花很短的时间写出这样一个工具，就能省下许许多多的开发者的时间，不过此前一直没人做这件事情。
也许有人好奇这个工具为什么直到现在才出现。其实要想完成这个工作，首先有两个前提条件。其中之一就是要把所有的kernel mailing list的内容都要可靠地存放起来，并且能用一个程序来简单地进行查询。此前一直缺少一个可靠地存放服务，并且没有一个集中式的地方包含所有的kernel相关的list。在这个问题解决之前，get-lore-mbox这种类型的工具也无从查询历史邮件。lore.kernel.org服务就解决了这个问题，目前看来它已经成为了kernel开发流程的一部分，不过其实它也才出现了不到两年。
早在1975年的时候，Fredrick Brooks在他名为Mythical Man-Month（《人月传说》）的书中，断定说一个高效的软件开发团队需要像一个手术团队一样工作，不同的人做完成不同的角色的任务。kernel项目中也有这样的核心“外科大夫”，同时也有许多其他的专家来完成其他工作。Brooks认为每个团队都要有两位秘书，而kernel社区看起来一直没有这样的角色。他还说每个团队都要有位工具专家，专注于创建团队所需的工具。
kernel项目长期以来一直缺少这样的工具专家。甚至没有一个人能把各位maintainer为了方便自己的工作来创建的工具搜集起来，改为适合大家使用的工具。因此，maintainer在日常工作中经常没有一个合适的工具，或者在使用他们自己简单拼凑出来的工具。这样导致社区失去了改善整体开发效率的 一些 机会。
在自由软件（free-software）世界里，有一个众所周知的秘密：有一部分开发工作得到了许多公司的支持，但还有一些一直没有公司投入进来。kernel里面也有同样的情况，甚至可以说，有许多很急迫的工作，因为看起来并不是某个人导致的问题，因此没有人会花精力来进行响应的开发。对这类问题的忽视，已经引出了许多问题：精疲力尽的开发者用尽方法来利用自己的业余时间开发来确保项目能有进展；许多安全漏洞；缺少测试和文档；缺少整个社区都需要的工具，等等等等。
除非有哪个业界巨头或者组织愿意投入一些精力和资源来解决这类问题。对kernel来说，Linux Foundation就是这样的一个角色。Linux Foundation一直在许多方面对kernel社区进行支持，包括雇佣了一些关键开发者，在2011年kernel.org被攻破之后接手了它的系统维护工作（此前这个工作一直被大家无视了）。最近，Linux Foundation支持了创建并运营lore.kernel.org，也包括get-lore-mbox工具本身。
关于kernel工作流程的讨论已经达成了不少共识，不过在这个领域还有许多工作需要完成。kernel的开发流程和工具在过去多年一直缺乏关注，从某种意义上来说，这也是因为表面上所有一切都还能正常 工作 。kernel社区在努力把自己运营好，这方面的工作，比起多数项目来说都做得好得多。当kernel社区找到一段时间来专注于改进工具的时候——Git就是一个很好的例子——最终的产物都会在开发社区中产生连锁影响。不过还是需要先让kernel项目的开发流程碰到一些危机、证明它无法良好支持社区运营，才能有动力进行工具的改善。
真希望今后kernel这边的开发流程的大改变能够跳过这个“先遇到危机”的阶段。其实只要能对kernel社区投入足够的支持工作和资源，这一点希望是很有可能实现的。也就意味着，现在Linux Foundation在做的事情不仅不应该停下来，反而应该能变得更加宏大。支持这个开发工作（包括让Linux Foundation的成员公司来支持）将会是Linux Foundation今后能对整个kernel项目进行支持的最好方式。
Better tools for kernel developers
By Jonathan Corbet
February 6, 2020
原文来自：https://lwn.net/Articles/811528/
常用的前端开发者的工具、库和资源
这篇文章简单的分享一套我认为有助于提升开发者工作流的工具集。这套工具集中的大部分你可能见过，也可能没见过，如果有哪个/些让你眼前一亮，那么我的分享就很值了。这个列表包含许多种类的资源，所以这里我将它们分组整理。
web前端程序员代码编辑器推荐
今天给大家分享前端程序员最爱用的代码编辑器，来看看你用哪款？包括：Visual Studio Code、Atom、HBuilder、Sublime Text、Dreamweaver、Brackets、Notepad++
JavaScript常用工具方法封装
Js常用工具方法封装:type 类型判断、Date、Array、String 字符串操作、Number、Http、DOM、Other 其它操作
Node.js 命令行工具的编写
日常开发中，编写 Node.js 命令行工具来完成一些小任务是很常见的操作。其编写也不难，和日常编写 Node.js 代码并无二致。package.json 中的 bin 字段
一百行js代码实现一个校验工具
做过校验需求的小伙伴们都知道，校验其实是个麻烦事。规则多，需要校验的字段多，都给我们前端带来巨大的工作量。一个不小心，代码里就出现了不少if else等不可维护的代码。因此，我觉得一个团队或者是一个项目
Licia 支持小程序的 JS 工具库
Licia 是一套在开发中实践积累起来的实用 JavaScript 工具库。该库目前拥有超过 300 个模块，同时支持浏览器、node 及小程序运行环境，提供了包括日期格式化、md5、颜色转换等实用模块，可以极大地提高开发效率。
程序员常用命令行工具
WordGrinder它是一款使用起来很简单，但拥有足够的编写和发布功能的文字编辑器。Proselint：它是一款全能的实时检查工具。GNU Aspell：
Web前端开发工程师常用的工具！
工欲善其身必先利器，作为前端行业的你，如果知道一些好用的软件工具可以帮助他们更好的工作。下面，就给大家分享Web前端开发工程师常用的工具。
用100行代码，完成自己的前端构建工具！
ES2017+，你不再需要纠结于复杂的构建工具技术选型。也不再需要gulp,grunt,yeoman,metalsmith,fis3。以上的这些构建工具，可以脑海中永远划掉。100行代码，你将透视构建工具的本质。
欺骗技术13款开源工具分享
一旦被那些受利益驱使或有政府背景的黑客团伙盯上，在这场不太公平的攻防博弈中，你会明显感到力不从心。他们有充足的时间，有娴熟的技术和丰富的资源，而且只要在无数次的尝试中成功一次就可以大获全胜
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!