好资源和短想法
The first RISC-V portable computer is now available https://lunduke.substack.com/p/the-first-risc-v-portable-computer
#杂
昨天在推上看到一则讨论SRE的推,见:
https://twitter.com/forrest_zhao/status/1503540454289133571
于是想起来推特好友里有一位SRE(@laixintao),于是at了他,看到这则推之后,laixintao和另外的人也去做了几个回复:
https://twitter.com/9hills/status/1503576474908979203
https://twitter.com/laixintao/status/1503596051759915010
这几条时间线上的讨论,都可以展开看看。
顺便,还看到了laixintao博客上关于devops的两篇篇文章:
《Devops 中的 Overfitting》 https://www.kawabangga.com/posts/4145
《SRE 的工作介绍》https://www.kawabangga.com/posts/4481
我对SRE不了解,但是这几篇讨论和文章我看下来,第一反应是:所谓“大公司”光鲜亮丽的光环下面,比如对外公开、PR的技术文档,可能仅仅只是职级晋升的产物,而实则里面做相关事情的人,并不这么光鲜亮丽。
这有时候就是痛苦的来源:外人觉得大公司各种好,而自己身处其中,晋升、职级、工作内容、进步等等的都不理想。以上说的是我曾经的感受。
引用laixintao推特里的一段话描述这段经历:“阿里的高可用都是人肉盯盘,给故障定责,出问题开除、325堆出来的。”
所以,这样所谓“光鲜亮丽”的工作,对个体而言,意义在哪里,也许需要落到具体个人身上才能想清楚。于我而言,一份工作,如果技能没有能让我精进的空间,这种所谓的“稳定”是没有太大意义的。
昨天在推上看到一则讨论SRE的推,见:
https://twitter.com/forrest_zhao/status/1503540454289133571
于是想起来推特好友里有一位SRE(@laixintao),于是at了他,看到这则推之后,laixintao和另外的人也去做了几个回复:
https://twitter.com/9hills/status/1503576474908979203
https://twitter.com/laixintao/status/1503596051759915010
这几条时间线上的讨论,都可以展开看看。
顺便,还看到了laixintao博客上关于devops的两篇篇文章:
《Devops 中的 Overfitting》 https://www.kawabangga.com/posts/4145
《SRE 的工作介绍》https://www.kawabangga.com/posts/4481
我对SRE不了解,但是这几篇讨论和文章我看下来,第一反应是:所谓“大公司”光鲜亮丽的光环下面,比如对外公开、PR的技术文档,可能仅仅只是职级晋升的产物,而实则里面做相关事情的人,并不这么光鲜亮丽。
这有时候就是痛苦的来源:外人觉得大公司各种好,而自己身处其中,晋升、职级、工作内容、进步等等的都不理想。以上说的是我曾经的感受。
引用laixintao推特里的一段话描述这段经历:“阿里的高可用都是人肉盯盘,给故障定责,出问题开除、325堆出来的。”
所以,这样所谓“光鲜亮丽”的工作,对个体而言,意义在哪里,也许需要落到具体个人身上才能想清楚。于我而言,一份工作,如果技能没有能让我精进的空间,这种所谓的“稳定”是没有太大意义的。
#杂
有时候想看一个技术问题的时候,想起来自己以前写过文章,一打开发现写得认真图画得也很清楚,这时候真心是感谢自己以前这么认真细致。
比如最近要看leveldb,找到自己以前写过一篇:
https://codedump.info/post/20190215-leveldb/
不吹牛逼得说:图画得是真好!
技术文章就是应该多画图少贴代码,即便贴代码也最好是讲解重点的伪代码,因为如果贴的源代码那还是作者原先的思路,写给别人或者自己看的时候,就得用自己的语言组织翻译成有重点的伪代码。如果不是这样,我可能回头看还是看不懂我自己的文章都写了啥。
对于一段输出,如果想到以后需要消化这段输出的人是自己,往往在当时能写得更好一些。这里的“输出”,包括并且不限于:代码、代码注释、文章、代码提交注释,等等。
有时候想看一个技术问题的时候,想起来自己以前写过文章,一打开发现写得认真图画得也很清楚,这时候真心是感谢自己以前这么认真细致。
比如最近要看leveldb,找到自己以前写过一篇:
https://codedump.info/post/20190215-leveldb/
不吹牛逼得说:图画得是真好!
技术文章就是应该多画图少贴代码,即便贴代码也最好是讲解重点的伪代码,因为如果贴的源代码那还是作者原先的思路,写给别人或者自己看的时候,就得用自己的语言组织翻译成有重点的伪代码。如果不是这样,我可能回头看还是看不懂我自己的文章都写了啥。
对于一段输出,如果想到以后需要消化这段输出的人是自己,往往在当时能写得更好一些。这里的“输出”,包括并且不限于:代码、代码注释、文章、代码提交注释,等等。
Show HN: Vim Reference Guide https://learnbyexample.github.io/vim_reference/Introduction.html
Light mode, Dark mode, and Gen-Z mode? https://www.getfilteroff.com/blog/light-mode-dark-mode-and-gen-z-mode
How to Learn Nix https://ianthehenry.com/posts/how-to-learn-nix/introduction/
Welcome to Web 3.0 https://welcome2web3.com
Code review decision fatigue https://tylercipriani.com/blog/2022/03/12/code-review-procrastination-and-clarity/
WIRED 这篇关于 Joel Kaplan 的长报道非常棒。
从头到尾挖掘了他是如何从一个自由派学生领袖右倾,帮助布什在 2000 年赢得大选,一路做到白宫幕僚长;之后加入 Facebook,帮助 Facebook「躲过」数次灭顶之灾,但仍然把 Facebook 塑造成了一家与政治深度捆绑,且可能是整个硅谷最右的公司。
以前我们会认为,Facebook 「右倾」的火苗源自 Peter Thiel,但读完这篇就能感觉到,Kaplan 才是最重要的「执行人」。
其中颇有意思的一个细节是,Kaplan 加入 Facebook,追根溯源,是因为他和 Sandberg 在哈佛读书的时候「谈过」。
过去几年,华盛顿对 Facebook 的攻势,都被 Kaplan 一一拆招,但 Facebook 最终还是被一家由「左派」亲手建立并发展壮大的公司,Apple,打得溃不成军。
从 2022 年初至今,FB 市值已经缩水了 45%。
https://www.wired.com/story/facebook-joel-kaplan-washington-political-influence/
从头到尾挖掘了他是如何从一个自由派学生领袖右倾,帮助布什在 2000 年赢得大选,一路做到白宫幕僚长;之后加入 Facebook,帮助 Facebook「躲过」数次灭顶之灾,但仍然把 Facebook 塑造成了一家与政治深度捆绑,且可能是整个硅谷最右的公司。
以前我们会认为,Facebook 「右倾」的火苗源自 Peter Thiel,但读完这篇就能感觉到,Kaplan 才是最重要的「执行人」。
其中颇有意思的一个细节是,Kaplan 加入 Facebook,追根溯源,是因为他和 Sandberg 在哈佛读书的时候「谈过」。
过去几年,华盛顿对 Facebook 的攻势,都被 Kaplan 一一拆招,但 Facebook 最终还是被一家由「左派」亲手建立并发展壮大的公司,Apple,打得溃不成军。
从 2022 年初至今,FB 市值已经缩水了 45%。
https://www.wired.com/story/facebook-joel-kaplan-washington-political-influence/