结果导向来看的话：能解决别人解决不了的问题。

如何达到这个结果，在不同环境和情况下可能需要不同的能力。
所以核心竞争力更多是老板或招聘者认为你有什么核心竞争力，而不是你自己认为你在所有同行中有什么核心竞争力。

苹果重新定义了擦丝器。

Linux 的桌面环境灵活性很大，比如 Gnome 来说，X 和 Wayland 在不同硬件环境性能表现不一样，另外本身还有 Classic 模式和普通模式之分，显卡驱动也是个坑。
DE 本身肯定不是为了“卡的难受”而设计出来的，Linux 这种面向折腾的系统向来都不是开箱即用的（不可否认这点与商业产品有很大差距，但兴趣驱动和金钱驱动效果肯定不一样），肯定都是需要大量调优的，这是 Linux DE 的短板，但同时也是很多人感兴趣的原因。

最后菜是原罪，如果不能客观评估的话，那就是引战贴了，对广大 V 友以及对楼主自己都没有好处。

话说 V2 什么时候能开类似 Reddit CMV 的节点。

不打包。

什么工具合适得看你打包代码的根本目的是什么。

Google 的决策层都不是傻子，不大会明着作恶，这点和苹果是类似的，对于和自己利益有冲突的东西，要么想出一个互惠的方案，要么就以保护用户权益为由不支持。

从初衷来讲，一个是由商业组织控制的，另一个是由非盈利性基金会控制的，发展的思路肯定是有差异的。

不吹不黑，只是想说现在其他的浏览器都发展得越来越好，Chrome 垄断的程度会日益缓和。

自己是很多年 Chrome 用户，上周开始换 Firefox，开始主要是因为 Android 端 Chrome 不支持 Extension，Firefox Android 版支持 Extension，装了 ublock 和 tampermonkey 用起来很爽，解决了一些网站的流氓问题，比如知乎在手机端想看更多答案必须下载 App 才可以，用 tampermonkey 脚本直接搞定。

后来 PC 上也换了 Firefox，不可否认 V8 是性能王者，但现在硬件都很强，自测性能上和 Chrome 没啥可感知的差别。

唯一的坎就是云同步，书签之类的以前都是放在 Google 账号上的，用了一些工具才同步过去的。

我具体没实践过，有一个项目叫 Motrix 是用的 electron-builder 来打不同平台的包的，你可以看看他们是怎么实现的。基本上就是先用 webpack 编译，然后使用 electron-builder 根据在 package.json 里写的打包配置来自动打出多平台的包。

比如监听端口：
const http = require('http');
const server = http.createServer(console.log);
server.listen(8080);
console.log(`Server is running.`);

又比如 Promise 预期会执行 resolve 或 reject，只不过暂时还没有执行的时候：
new Promise((res, rej) => {
setTimeout(res, 5000);
})

死循环也会出现进程一直没退出的现象。

用的什么打包工具？

一种是配置打包工具，最终每个平台打一个包，然后每个包只包含自己平台的 ffmpeg。
另一种方案是打全平台的包，然后运行时再根据运行平台下载特定平台的 ffmpeg，这样如果用户系统内已经安装了可用版本的 ffmpeg 也可以不下载直接用系统的。

非商业用途是免费的吧，我自己是够用的，有更高需求肯定得考虑自己搭或付费了。

从公司连到家里遇到过警告商业用途的情况，但没妨碍使用，我发了个邮件给 TeamViewer，说明我是从公司连到家里的电脑，是非商业用途，然后他们就回了邮件说给我加如白名单了。

不黑不吹，也不说无关的事。

有人喜欢放在统一的目录里，有的人喜欢相互隔离，事实上确实不同应用场景下有不同的需求，不能说哪一种绝对好；工具只能提供一种默认方案（两种就不叫默认了），但工具也可以提供足够的灵活性来让人们自助解决需求差异。

Node 对与 node_modules 的搜索是有一个规则的，规则不满足需求也可以用 NODE_PATH 机制来指定，可以结合一些 Npm 的指令以及自动化脚本来 Hack 出一个基于 Npm 的集中包管理机制。
Npm 并不是 Node modules 的唯一管理工具，pnpm 就可以提供“ One version of a package is saved only ever once on a disk.”的特性。

实现整个系统环境或用户环境有一个共享的包目录所遇到的问题，肯定比实现每个项目下有一个包安装目录遇到的问题要复杂。举个例子，要删除一个包或一个版本的包的时候，肯定是基于一个项目的需求来删除的，但共享目录是所有项目都在用的，那仅当只有这一个项目依赖这个包的时候才可以删除这个包，这有点类似垃圾回收机制。类似的问题肯定是可以有解决方案的，只不过也一定是需要额外的成本的，将一个项目的问题封锁在项目目录内，相当于是将包管理的问题降维，这可能是 Npm 一直在用这个方案的一个历史原因。

对于 Node 服务开发来说，依赖包占用空间多的情况较少，问题主要集中在网页开发方面，这个其实不是 Npm 的锅，主要是现在网页开发应用的语言太多，每种都需要特定的编译程序的支持，比如 JSX、Vue、Sass、TypeScript 等等，空间占用大，编译时间长，最终生成的网站大小并不大（否则就会有流量问题和加载性能问题了）。

所以建议根据项目的具体情况来选择包管理方案。

1. Node 现在多线程是试验阶段，不过已经离稳定发布不远了，现在最新版 Node 已经不需要加 flag 就可以使用 https://nodejs.org/api/worker_threads.html 如果对稳定性（主要是 API，程序已经很稳定了，不保证正式发布前 API 是否会做调整，不过大概率不会有大变动）要求不严格可以开始用了。或者可以去找一些 Web worker 的其他方案。
如果接受多进程方案的话，Cluster、Chield Process 都很稳定，可以根据自己的需要使用。
2. 没抠过这个，用得比较多的方案是上传 SDN 再从 Node 上下载，这样对弹性分布式+消息总线的系统友好一些。
3. 跟 Node 没关系，个人没怎么做过，不过有思路是用 HTML5 API 读取本地文件然后再用 Canvas 画出来，这样可以支持上传前编辑，最终上传的应该是页面内存里的那个编辑过的图片数据。可以找找有没有相关的前端组件。
4. 软件工程没有银弹，在不同的地方使用最合适的技术栈才是最明智的。

小睡或闭目养神 20 分钟，长了醒不过来，短了力度不够，20 分钟正好。

旧有的特别是大型的项目往往迁移成本高，所以现在用 Go 的一般都是新项目，特别是新成立的企业用的比较多。

https://en.wikipedia.org/wiki/Hype_cycle

个人感受是 Go 是在第二阶段到第三阶段之间，过了第三阶段应该就会有越来越广泛的应用了（也可能不会）。

我们公司 2013 年成立，现在 500+员工，目前是多半 Node.js+少半 Go，也有其他语言的项目。

字节是新厂，扩张超快，听说是主 Go，不过也在招聘 Node.js 和 Rust，其实没有任何一门语言是万能的，一家成熟的公司的业务也不可能只靠一种技术栈支撑，比如一家企业是 Web+人工智能+大数据，那至少同时在用 3 种语言。

Rust 目前处于第一阶段，生态和特性远不及 Go，不过先天条件很好（给人非常“现代化”感觉的一个语言），坐稳系统开发的阵地，未来在 Web 服务、中间件和 DevOps 领域可能可以和 Go 竞争（也可能不会）。

现在用 UHK，不是奔着机械轴，主要是奔着开源硬件+分体式设计，手腕好多了。

开放的东西只要有人愿意贡献，并且管理得当，就能有广泛的应用。

https://www.bilibili.com/video/av48925225?from=search&seid=18240965666298982491

不过 LTT 的机房都是用的 Windows Server，对于一些特定场景来说，Windows 会很方便。毕竟 Windows 的价值不是软件本身，更多的是成熟稳定又有售后的解决方案。

群辉，一劳永逸。
自己家里是用的 OpenMediaVault，熟悉 Debian 的话可以小折腾一下。
外网可以用 VPN 来加强安全问题。

Spring 是一个框架，而框架是被设计出来解决特定应用场景上的需求和问题的，如果不了解需求和问题上来就学框架，肯定就会感觉没有头绪。

自己了解到的是 Sprint 的初衷是降低 Java EE 的使用难度，而 Java EE 是为各种企业级应用场景（最常见的是 Web ）提供了各种现成的 API，这些 API 自己用 Java SE 写成本很高，而且相比来说 Java EE 更标准化、社区更成熟，所以往往人们都是直接用 Java EE 的接口。

不知道你是否学明白 Java SE 了，如果学明白了可以自己尝试用 Java 核心 API 写一些简单的 Web 接口，体会一下哪些工作其实是可以用 Java EE 的接口来实现的；然后再使用 Java EE 写一些简单的 Web 接口，体会一下 Spring 是如何降低 Java EE 的使用难度的；最后再了解一下业内的一些企业级服务在开发过程遇到的一些问题是靠着 Spring 提供的哪些思想或者基于 Spring 的哪些思想来解决的。理解了需求和解决问题的思路应该就能更快掌握这个框架。

当然 Java EE 很重，Spring 一方面要应对 Java EE，另一方面要给这么多年来的各种各样企业级服务提供解决方案，所以 Spring 也会很重，涉及到的思想和方案也会很多，学起来也就很花时间。

我自己学 Spring 当年是直接放弃了的。。。所以我对 Java 技术栈的了解可能并不准确。
这些年都是用其他语言的轻框架来做 Web，但不管什么语言什么框架，肯定都是用于解决特定的问题而不是用来制造麻烦的。