守护石（水瓶座守护石）

满大街的老板都自称是产品经理，看看什么是真正的产品经理，别再说技术无用，是你掌握不了火候而已！

#产品经理# #乔布斯#

今天心血来潮的下载了一个FreeBSD13安装镜像，通过虚拟化做了简单安装。考虑有空专心玩转研究。

简单适应了一下，觉得还不错，用惯Linux后端的人借助网上搜索FreeBSD命令，会毫无违和感。

我觉得吧，中国想在操作系统上真正实现独立，不能完全寄希望于GPL协议束缚下的GNU/Linux，而是踏踏实实在更宽松的开源授权协议，例如：BSD License上实现商业化的持续性发展。

基于BSD协议，商业化可以“为所欲为”，我们只需要遵守三点即可：(1)再发布源代码，必须带有原来BSD协议的代码，(2)发布二进制类库/软件，文档的版权必须声明包含BSD协议代码，(3)不可以用开源代码的作者或机构的名字以及原来产品的名字做商业推广。

貌似MacOS的内核也是基于mach(微内核)基础上魔改纳入了FreeBSD的对外服务形成了XNU内核，再配上外围工具就组成了Darwin裸系统。[偷笑]

#操作系统# #freebsd#

Druid针对kafka的supervisor规格配置，有一个很重要的配置项:taskCount。

今天仔细对它进行了实验和测试。那么我们怎么去理解它的意义呢？

taskCount其实就是读取kafka topic分区的任务设定，若你的kafka topic设置了6个分区，那么这个taskcount设置为6是最佳的，相当于supervisor启动6个任务并行从6个topic分区读取流，那么1比1的配比，并行效率是最高的。

实际上你就算你把taskCount变为7，最终还是只会启动6个任务，也就是不会超过kafka的分区数。

另外更深入的地方来了，若你的supervisor摄取规格配置中打算给索引的segment设置为双副本，也就是replicas等于2，那么supervisor会启动多少个任务呢？

摘自：

最近大厂裁员程序员，真的是铺天盖地的卖惨，好像中国科技就此醉入悬崖一般。实际上大厂本身就是个人才冗余的大池子，裁员会让大厂更加稳固，人越多却又不能做到人尽其用的地方是非最多。

那为什么那么多人卖惨呢？还是我的观点，科技这个行业就跟中国足球一样，彻底带偏了，那些为了兴趣和科技使命感的人才被完全埋没了，现在的科技圈就是个名利场，各个都想着50w起步的年薪，百万不是梦，30岁财务自由的想法在头几年比比皆是，这种状态下，大家比的不是谁能创造，而是搞钱，创个毛线新，劣币逐良币而已，时代的红利没有了，金钱梦碎了一地，甚至有些人到处背债玩高杠杆，自以为科技福利就跟房价一样步步高升，你说能不惨吗？

现在的科技行业，尤其是互联网，就是在刺破这个逐梦的大泡泡，让科技人才回归理性，还能坚持往前冲的技术人，一定是有一种信念和兴趣在维系，这样的人才必然是时代所需要的为荣誉而战的创造者。

程序员现在挂在嘴边最多的话是什么？收到了几家offer啦！我要年薪五十，今生只认大厂收百万年薪，我要财务自由，嗨.....，这哪是科技人才，活脱脱第二个国足。所以人家大厂呢？你毕业啦！你不是我兄弟啦！大家都有意思吗？

我们天天说美国卡脖子，我们呢？程序员都沦为码农了！真的，这个行业需要的是真真正正热爱这份职业的技术人，勇于创造的技术人。

在线计算的程序如何实现？

应用场景：在线程序中选择远程计算工具，配置好参数后发送到后端，由后端服务接受命令请求并调用专业模型软件工具执行，客户端能捕获远程工具的运行结果，用于在线程序的计算流程的下一环节使用，并且动态监测工具日志变化。

去年刚设计了个类似的工具，是通过开发一个在线流程化集成框架，Java平台集成MATLAB，Python数学库之类的AI计算工具与算法库。

关键问题分为两部分，流程建模和流程引擎，借鉴类似工作流的特征，但是在流程活动的处理环节深度改造成对远程计算工具和异构Python运行库的集成。

核心是流程图形化建模的改造，图元这时候代表了不同的模型计算阶段，图元间形成有向无环图，每个图元增加调用方法、传参方式、结果捕获方法、日志监测等元素，最终导出文件或数据表配置。例如：MATLAB图元，需要配置选择MATLAB远程调用脚本，执行脚本id和参数写入图元元数据库，运行引擎的流程执行到此图元时，获取图元元数据，执行元数据脚本发起MATLAB程序执行，并捕获MATLAB日志反馈在线程序。

整个流程包括：步骤一数据采集图元，也就是调用某个服务端进行数据采集，步骤二数据分析图元，也就是关联到某个服务从上一个采集服务的数据输出点读取数据进行分析，步骤三web展示与操作，包括拓扑的每一阶段的调试输出。

有些情况需要远程登录到对端服务器打开UI界面去人工执行可能要用到脚本，完成执行前后的系统操作和数据适配，驱动计算流程的流转。

#计算# #MATLAB# #程序员#

最好的编程技术一定能做出最好的软件产品吗？

这个逻辑在程序员界其实是一个很有历史传承的问题。我认为最好的软件产品的必要条件是不是最好的编程技术，关键是看在什么样的环境下形成了这种必要条件。

比如说约翰卡马克，其无与伦比的第一人称游戏编程技术，开创了fps 3d游戏引擎，记好，是开创，不是创造，所以他是宗师级的程序员。若没有卡马克的极致游戏编程技术，那么根本不可能在那个时候产生3d引擎，那么我们曾经玩过的CS反恐精英至少要推后好几年甚至更长时间，而卡马克所在的id公司也创造了脍炙人口的游戏doom和quake，这全部得益于卡马克的宗师般编程技能。这种例子还有很多，所以我们可以总结出创造性软件的核心技术问题是软件的成败关键所在的时候，那么突破技术瓶颈，精益求精的编程技术，就能产生最好的软件。

反之，在大多数情况下，软件编程技术并不是软件的成败关键，我们主要通过对软件反复迭代重构，夯实软件的结构松散，达到系统结构精密，接口更柔性，这就算达到大多数工程在编程技术的一个很高的高度，实际上大多数软件系统都是屎山。

但这与产生最好的软件并没有什么关系，例如微软最成功的操作系统版本是win7，对win7的替代只能是微软自己来埋葬，可是win7怎么盖土，还是在喘着气，可见其产品生命力有多顽强。但是从编程角度看，越多的补丁，证明系统在不断地堆积问题，所谓按起葫芦浮起了瓢，解决一堆问题，又会产生一堆问题，最终维护成本都超过了软件收益，那么可以推断无数补丁的win7的工程代码量已经臃肿到一个可怕的程度。微软不再维护win7是不得不为之的事情。

再比如操作系统中FreeBSD的源代码技术质量可谓是孤品，极品，GUN/Linux在FreeBSD面前就显得粗糙，碎片化，散乱，但是FreeBSD的流行度，就难以形成生态支持，缺少的支持太多了，就很难成为最好的软件产品；黑莓10的微内核QNX也一样，是世界上最好的微内核技术了，用在车载系统就是最好的软件产品，用在了bb10上就成了最失败的软件产品。

因此往往最蹩脚的编程技术是用在最臃肿的程序代码上解决最诡异的问题，这样的情况最是常见，从另外一个角度也证明了软件产品已经具有所在领域悠久的历史，完善的生态，其产品生命力更强，更符合用户需要，常见于各领域最流行的商业软件产品，行业中占据市场领导地位的软件产品，很多流行的开源软件也存在这样的问题。例如像：Windows，Oracle，Adobe，iOS，Android等，它们必须继承程序代码的历史遗留包袱，反复地补丁更新，久而久之，软件产品的功能结构，系统编程质量都在下降，就不再是最好的编程技术，但不能否认做出了最好的软件产品。

但绝大多数情况下，因为一些行业垄断行为，以及市场能力才是决定因素的情况下，是很难具有持续的，精益求精的编程技术驱动力，更产生不了最好的软件产品，只能产生够用的产品，甚至是因为代码质量太差，导致无法正常维护与扩展，而反复推翻重做的软件产品。常见于政府，大企业的应用软件项目。

因此谈最好的编程技术是一件比较纯粹的事情，但是当谈到最好的软件产品时，这就包含了太复杂的环境因素了！

#程序员# #产品经理# #操作系统# #计算机专业#