「开源之道」适兕:“关起门来搞开源,做不了开源世界的Leader”

在腾讯,有多少技术Leader在写代码? 在腾讯,有多少技术Leader在写代码? 2020 年 3 月 9 日,腾讯公司正式对外发布了《腾讯研发大数据报告》。在这份报告中,腾讯披露了2019 年公司在产品及技术研发方面的重要数据,这也是腾讯自技术委员会成立以来第一次主动对外披露研发相关大数据,是腾讯对自身技术研发层面的一次阶段性总结。 该报告是由腾讯旗下敏捷研发协作平台TAPD、腾讯代码托管平台工蜂与腾讯集成交付系统腾讯CI联合出品,这... 阅读详情

回顾自己职业布道的这一路,适兕有过心酸,也有欣喜。近两年国内对开源的认知度有所提高,这件事可喜可贺,但开源的含义却远比大家所认识的要更加广泛、深刻。那我们该如何理解开源?本期《开源访谈录》邀请到了《开源之迷》作者适兕来分享他的见解。

本期受访嘉宾:
适兕,本名李建盛,作者,「开源之道」主创,Linux基金会亚太区开源布道者团队主席,Apache Local community Beijing 成员CCF 开源技术从书编委会委员。曾担任开源社执委会教育工作组成员,X-lab 开放实验室开源导师。著作作品《开源之迷》

随着近两年开源在国内有所起色,大家对开源和开源文化的认知也开始萌芽、成长。在这背后,离不开开源布道师们的“推波助澜”。作为中国“史无前例”的职业开源布道师,适兕(李建盛)在回忆起自己早年的经历时说到:“原来大家都认为我是个怪胎。我是一路被如此误解过来的。”确实,早年间大家对开源感知不深,都认为它很难理解,因为它不像是个能够解决现实问题的事物。

但是随着近两年开源的兴起,适兕欣喜地说到:“从2020年开始大家不把我当另类看了,发现我是可以沟通的,很多人愿意跟我沟通,这令我很欣喜。”但是,尽管情况在好转,开源在中国土壤上还仅仅只是撒下了种子,还需要更多的布道师站出来告诉大家如何参与开源、如何正确的认识开源、如何为开源付费等等一系列的问题。只有这样,中国开源才能茁壮成长,并在将来的某一天开花结果。

那么,我们该如何理解开源这件事?开源布道的目标是什么?中国开源从业者们的现状是怎么样的?我们该如何理解一些开源文化?本期我们邀请到了开源之道主创、《开源之谜》作者–适兕来和我们谈谈他对这些问题的见解。

《开源访谈录》--适兕

“开源信徒”的朝圣之路

优快云:媒体曾给你贴上开源信徒的标签,这个标签是准确的吗?在你心中开源是怎样一种存在?

适兕: 这其实是我给自己贴的标签,它是从英文中“open source believer”翻译而来。2017年的一次演讲,就是我用“开源信徒”的身份去做的。在那个阶段,我特别想要给大家树立一个形象:我是个认真做开源,并且坚定相信这件事情的人。这两年我反而淡化了“believer”这个标签,因为我已经用行动去践行了我的愿景。

我从业开源已经将近20个年头,在我整个职业生涯当中,开源一直占有很重要的地位,去年我开始投入精力写书,在这个过程中我也在不断思考开源是一种什么样的存在。最终我得到的结论是,开源是一个完整的文化世界,这个世界里面的人有自己的思考习惯、行为习惯等等。开源是一种人类切切实实的文化现象,对于我来说,开源以一个文化世界的形式存在着。

优快云:你作为开源布道师的工作主要涉及哪部分?日常工作节奏是什么,能否给大家分享一下?

适兕: 我目前最大的工程是预估用十年时间完成《开源三部曲》一系列共三本书。想把开源这件事讲清楚其实没那么容易,需要很多的知识积累。

我是个坚持写作的人,也会长期发布与开源相关的文章,内容会涉及到社区、基金会、经济、商业、社会的大环境等等。另外,我也会组织一些小型group发起的活动,比如开源之书共读这个活动大概运行了三年。除了这些,我还会参与一些由别的组织发起的活动,比如说Linux Foundation APAC发起的开源布道者计划,我作为一个chair person参与在其中。它是一个针对企业拥抱开源,或者是出境开源治理相关知识的传播活动。Linux Foundation 下还有一个项目叫open security foundation,总的来说我今年会把这两件事情做好。同时还有Apache local community,我也会在这个组织下面发起活动。

其实开源布道这件事就是通过各种媒介输出如写文章、演讲、参与会议。我一年大概有二三十场演讲以及各种大大小小的会议,以上是我在日常会去做的事。如果哪天我能够安安心心地回去写程序,我的布道使命才算是完成了。

优快云:你的开源三部曲之一《开源之谜》在近期已经发布,可以和大家分享一下创作这本书的心路历程吗?

适兕: 其实写书这个事情花了我好长时间去酝酿。从2015年转行做布道师,我就开始不停写作。这是一个在二维世界里去探索三维的过程,我在黑暗中摸索了大概三四年的时间,一直想找一根儿线索把开源这个事情串联起来,但是现在看来这根本是个误区。19年下半年,有个技术类的译者一语点透了我:你要不要尝试一下好多根儿线索?我突然就想明白,开源,它应该是个网。

我可以从法律的角度去看,或者是从普通人、软件工程的人、技术员的角度去看,或是从商业、社会的角度去看开源,把它当成一个文化世界来描绘。这样一来,开源世界突然就清晰地呈现在了我眼前。我试图呈现的是一个静止的开源世界,假设我们的时间停留在这一刻,你去观察到的开源是什么样子?这个创作方法我觉得是个点睛之笔。

开源贡献者的生存现状难不难?

优快云:前一阵在开源圈内爆出了一个热点事件,知名开源项目Faker.js的作者Marak因为没有得到与自己贡献相匹配的回报而"删库跑路"。对于这个问题你怎么看?

适兕: 我对Marak这个小伙子的做法保持谴责态度,我认为不管是开源还是闭源,作为一个良善的现代法理社会公民,不应该做出如此极端的事情。

但与此同时,我也会反思自己。作为开源布道师,我的职责之一就是要保证这些从事开源的人有正确的道德、法律、文化观念。我认为从分配的角度上讲,Faker.js这个项目已经在很多场合下为整个社会运作产生一定贡献,但在现有的分配机制下Marak得不到相应的酬劳,这是有问题的,因此我倡导开源用户为这个项目付费。从经济学原理讲增加付费可以增加供给,这个道理大家都明白,想要保证为客户提供服务的这些系统可靠、可控,就应该为这些开源作者提供基本的生活保障,让他们能没有顾虑地做开源。这也是我作为布道师的作用之一。

优快云:你曾专门写文回答“适兕是如何生存的?”当前开源圈内的普遍生存状态是怎样的?

适兕: 我做布道这件事,自认为是很有意义的,因为开拓开源市场需要这样的人。我从2018年开始做自由职业者,在这种情况下就是勉强生存。但是近年来开源发展越来越好,随之而来出现了各种转机,包括资本对开源的青睐、大公司对开源的认可、开发者以及如优快云的技术媒体对开源的推动和认可。现在即使你从事开源中比如布道、communitymanager、运营,收入都不会很差,至少不比做闭源差。我身边很多做开源的同事现在都在一线城市买房了。

做开源的工程师有个特点,他们自身的素质和自驱力非常强,会主动寻找需要解决的问题。我还没见到做开源的同事抱怨35岁危机,他们常常保持头脑开放,适应这个技术迅速发展、快速变化的时代。当我们回顾技术变革的历程,你会发现编程语言、操作系统、架构、数据库等等这些技术每隔五年或十年都会发生变化,你之前所学的知识都没用了。但如果你在开源的世界里,每天都在应对新的问题,就能不断地学习并保持一个良好的状态和竞争力。总的来说,开源世界的小伙伴们目前生活得非常好。

有限的认知不足以预知无限的未来,enjoy开源就好!

优快云:对于想通过参与开源来提升个人技术的开发者你有什么建议或经验可以分享?

适兕: 对于这个问题,我只能给刚参加工作,或是还在学生阶段的一些年轻开发者提供一条可行的路径。由于开源的开放性,在过去20年中,年轻人在学习技术时接触到的技术已经被开源技术所占据,大家都在学习例如Linux、C语言、Python、Java等一些开源技术。软件是个实践性较强的专业,learning by doing,在这个时候开源项目就体现出它的优势。开源不设门槛,掌握了这些技术之后,你可以参与到开源community中去,提交一些测试中遇到的问题,或是在社区里解答别人的问题,可以事半功倍地自我提升。在社区中,你还可以看到顶级的工程师写的代码,甚至可以向他们求助或与他们沟通。

优快云:我们如何判断一个开源项目是否有前景,是否值得关注?

适兕: 这个问题我可能无法给出一个确切的答案,就像是我们人生中很多选择一样,我们不知道结果,只知道我们做这件事情的时候是否快乐。开源是一项工程,当我们回顾历史,没有人在最初就知道这个项目能否成功,人的认知是有局限的。当然,我们可以尽可能搜集更多的信息来了解这个项目,或是从一个宏观的社会环境下去猜测这个项目有没有前途。

举个例子,Ceph是个分布式存储系统,它试图统治块存储和文件存储。这个项目在2013年云计算和分布式开始流行的时候突然被很多人知道,但在这之前的七到八年中,是作者一直在默默无闻的坚持维护,后来它被红帽收购、捐赠给Linux基金会并以基金会的方式运作。还有很多类似的项目,虽然我们今天看起来很火,但在当年并不是这样。所以,我们没有办法预见一个开源项目的前景。

我能给到的建议是在你想要参与一个项目时,要考虑以下几点:你认为这件事能否满足你当下的需求?你能否enjoy这个过程?你能否在这个community中获得归属感,认不认同它的文化?我认为这几个因素是很关键的。

优快云:对于开源项目来说,它与闭源最大的区别就是工程师们可以在开源项目的源代码中做修改,然后自己进行配置、使用。这是否代表着参与或使用开源是有门槛的?

适兕: 这个问题我们需要细化场景,不能笼统地说。首先开源虽然允许用户自己修改,但是这个修改确实是有门槛的,需要你具有一定的技术实力。但是开源的参与不设置人为门槛,仅仅是技术门槛。在软件行业中想要掌握基本的计算机原理、知识及编程语言,并形成对某些系统的独特理解,大概需要四到五年的时间。任何一项技术、行业都有知识、技能的门槛,单把这种门槛归结为开源所拥有的不太恰当。开源欢迎任何人参与,但是需要你掌握一些知识和技能。总的来说,开源没有门槛,只对技能和知识储备有要求。

开源之“术”与“道”

优快云:开源中有很多非常先进的理念,比如开源治理、上游优先。可以通俗的解释下它们的含义吗?

适兕: 如果从经济学角度来理解开源治理,可以借用一个理论“科斯定理”。它解释了我们为什么会去组织一个企业,究其原因是成本问题,企业的内部的成本是小于它与外部沟通的成本。所谓的开源治理,其实一个人的时候用不上,但是遇到操作系统、数据库这种需要几千个人完成的大型工程就非常有必要了,比如Linux kernel,最多的时候有3000个人来提交一个版本。如何让几千人一条心地做一件事,而且没有利益纠纷?开源界摸索出了开源治理的概念,它是从比较成功的开源项目总结而来。当我们总结一个项目所有跟人相关的因素,包括人之间怎么沟通、谁有合并的权限、谁有review别人的权限等等,就是开源治理。后来的项目可以选择这些开源治理的方式,比如community over code,去指导自己的项目。

开源有个很好的特性,你随时可以退出,并且永远支持fork。要理解Upstream First我们首先要了解什么是上游。比如Linux发起的项目,Linux就是上游。假如我从Git上fork一个Linux的项目,我得到的版本跟Linux仓库里的代码是一样的,我可以对我fork的代码自己进行修改。但如果任何人都可以fork,人难免会因为意见不同而产生各种支流,最经典的就是各种Linux发行版。Linux发行版都是最初的Linux的分支。这个时候,你要不要让自己的代码跟上游保持一致,其实是个成本的问题。最可怕的是当你跟上游产生不一致时,随着时间的增长,你会发现维护自己版本的成本越来越高,并且跟上游比,功能越来越差。我之所以倡导Upstream First,是因为我发现很多公司或个人,甚至专门组建了一个团队去做这种修修补补没有创新的事情,这很让人痛心。所以说Upstream First其实是最合理,也是最能让开源快速发展一种理念。

优快云:你之前写过一篇关于 CHAOSS 开源指标解析的文章,你提到在没有搞清楚性质之前,不要迷信数据。所以你认为我们应该以一个什么样的态度去看这些数据?你觉得什么样的项目/社区是健康的?是否有通用的标准?

适兕: 从认知观的角度来看,我们现在所生存的世界是到处都是度量。在物理空间,我们在时间、空间、温度等维度都发明了各自的度量单位。对于认识我们所处的社会,我们会用GDP、GNI去衡量一个国家的发达程度。总的来说,衡量对于人类认识任何事物是非常重要的,从认识物理世界到认识我们所处的这个社会。但是GDP等等这些度量到底准不准确?和人们的幸福指数有直接关系吗?有,但不是因果关系。

回到开源圈中,CHAOSS项目是一个非常好的探索。如何去衡量一个软件项目?我们刚才讨论过,如何判断一个项目是否有前景。一个不开源的软件项目,有哪些指标来衡量它?你可能会考虑这个项目花了多少钱、人员能产生出多少代码等等这些指标。

那么开源项目需要看那些方面?

  • 看Star数或者Fork数等等这些指标,它代表这个项目被关注过。
  • 看软件本身的问题,比如注释写的怎么样、测试文档写得好不好、测试用例写的全不全、代码review的过程严不严谨。
  • 看关于community的指标,这些指标是很难定量的。对于无法定量的事件可以给它定性,比如你觉得一个文化是好还是坏。

CHAOSS也会做一些定性的问题。

  • 比如看参与这个项目的contributor的人气如何、他的network是怎样的、是名校还是普通大学毕业的。
  • 看一个人的社交资本,或者是social reputation,这些东西都是无法量化的,它只能是定性的。

在CHAOSS这个项目的指标中,有定量的的指标,同时也有一些定性的。定性的事件是从个人立场出发的,每个人的看法可能都不同。 总结下来,我观点是对于我们人来说,量化是非常重要的,但是它的难度很高。在定性这方面确实会引起很多争论,确实也是比较难的一件事情,我赞同尽可能把它用数学的方式统计出来,给后来者提供方向,让他们少走一些弯路。

优快云:Apache这个组织作为开源行业的标杆,其内部有一句非常流行的话叫做Community over Code。从你的角度来看,随着开源历史的发展,Apache为什么越来越推崇这句话?我们该如何理解它?

适兕: Community over Code中的“Community”这个词,我建议将它理解为“共同体”。这个翻译是从科学共同体的概念继承下来的,含义为从事开源的这些人,他们不是乌合之众,是接受过多年科学教育或是计算机相关技能训练的人。他们基于互联网发展出一些文化规则,以支持他们协作推进一个项目。

Community over Code是Apache之道中非常重要的理念,甚至不亚于“没有在邮件里发生的事就没有发生”这条规则。为什么呢?我们以Apache最早期的项目Apache httpd为例。在研发这个项目的时候,用户有很多其它选择,比如Netscape、Web服务器。但 Apache这些早期的创始人对于代码的理解是,某个功能的实现有很多种方式。他们更加信仰以自己认可的方式去做这件事情,并且认为过程比具体的成果更加重要。Apache Foundation下面的组织理念贯彻了对democracy和meritocracy的实践。其组织理念不注重超强的个人能力,甚至在淡化某些与个人能力相关的事。它提倡共同体大于代码,但这并不意味着Apache不注重代码的质量,它只是提倡以文明的方式去讨论。软件代码的实现可以有很多种方法,但是这样的共同体更难得。

关起门来搞开源,做不了开源世界的Leader

优快云:回顾2021年的开源发展,哪些事让你印象特别深刻?

适兕: 这一年我大部分时间在创作,因为疫情,做活动的频率也比较低。我所遇到的挑战其实是,整个全球的逆全球化的思潮,很让人担忧。“关起门来搞开源”对我国开源的发展挑战非常大,尤其是当我们国内软件产业发展程度不是很高的情况下,相当危险。当你阻断了与这个世界交流的通道,开源的全球发展就会将我们甩在身后,这是很可怕的事情。中国作为一个世界大国,一个文化强国,我们拥有非常勤奋的人民,应该去担起整个人类命运共同体该有的担当,去把具有划时代意义的开源基础设施共同建设起来,而不只是作为一个consumer。在开源的世界里,我们如果想要站起来、建立影响力、做领导者,就必须去付出、去做KT标准,承担起一个大国的责任。这是2021年让我比较担忧和难过的事情。

2021年也有一些让人欣喜的事情。这一年,开源被写进了十四五规划,突然有很多人知道了开源这两个字。虽然开源在社会中起着很大的作用,但即使是我们行内的人,也把它当怪胎,或者是当亚文化去看待。当我们现在去关注开源,你会发现所有企业的业务80-90%都是用的开源软件、开源项目来做的。当这些数字量化的东西展现在世人面前,你会发现,开源原来发挥着如此重要的作用。另一方面,开源在这一年也得到了更加正向的传播。我们国家有非常好的生源,非常优秀的工程师,如果他们能认同开源文化,认同开源思想,愿意去打开自己的头脑去献身给编程、扎根于开源10-20年,这对于我们意义更加重大。

优快云:你认为这一年的关键词是什么?为什么?

适兕: 2021年很魔幻。这一年可能是个转折点,大家对开源的认知从简单的技术上升到了另外一个层次,甚至是以国家的力量去倡导,如果加上文化方法与技术实力,我们超越欧美的开发者、在开源的世界里做leader、成为大国担当的目标是有希望的。我是个爱国情怀很重的人,方法可能也和一些人有所区别,我更倡导打开世界,在Internet上直接用实力影响别人,用技术实力说话,而不是把别人阻挡在门外。我们需要加油,加倍努力把这些已经验证过的开源文化与相应的技术项目结合起来。在五年到十年的技术迭代周期内,去达成我们的目标。但前提条件是,接受别人的挑战,并保持开放。

《开源访谈录》是一档聚焦开源发展的访谈类栏目,每周将邀请1位具代表性及影响力的开源专家,探讨大家广泛关注的开源话题,从不同角度还原开源圈真实面貌。

Leader/Follower多线程网络模型介绍 之前分享过《轻量级web server Tornado代码分析》,介绍了目前我们采用nginx + tornado的方式搭建升级、配管、数据中心等各类服务组建客户端迭代体系。最近注意到,淘宝目前公开了其网络服务器源代码Tengine。根据官方介绍,Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上,针对大访问量网站的需求,添加了很多高级功能和特性。Tengine的性能和稳定性已 阅读详情

相关推荐

【kafka运维】Leader重新选举运维脚本

文章目录kafka-leader-election Leader重新选举More 日常运维 、问题排查 怎么能够少了滴滴开源的 滴滴开源LogiKM一站式Kafka监控与管控平台 kafka-leader-election Leader重新选举 1 指定Topic指定分区用重新PREFERRED:优先副本策略 进行Leader重选举 > sh bin/kafka-leader-election.sh --bootstrap-server xxxx:9090 --topic test_create

石臻说AI(szzdzhp001) 【原名 石臻臻的杂货铺】 5679

专访开源之道主创 · 适兕:真实的开源世界依旧冷清

| 转载自:SegmentFault| 作者:马玮|编辑:钱英宇| 设计:宋传琪|责编:王玥敏访谈者:马玮,SegmentFault 思否技术编辑受访者:李建盛(适兕)作家,开源之道主...

开源社KAIYUANSHE的博客 622

开源软件之道(中文高清版)

第1篇 了解开源软件 第1章 开源软件概述 1.1 开源软件的理解 1.2 开源软件的定义 1.3 开源软件定义的意义 1.4 开源软件和其他类型软件的比较 第2章 开源软件的历史与未来 2.1 开源软件的历史 2.2 开源运动背后的理想与现实 2.2.1 理想主义的兴起 2.2.2 技术精英的推动 2.2.3 现实业界的需求 2.3 开源社区的壮大 2.4 开源软件的领袖 2.5 开源软件的未来 第3章 开源软件的好处 3.1 高质量 3.2 零许可证费 3.3 开放和自由 3.4 灵活可定制 3.5 公开透明 3.6 良好的学习平台 第4章 开源软件的成本 4.1 部署和迁移成本 4.2 人员和培训成本 4.3 管理维护和技术支持成本 4.4 风险控制成本 第2篇 使用开源软件 第5章 正确使用开源软件 5.1 管理体制 5.2 法律风险 5.2.1 法律因素之著作权 5.2.2 法律因素之许可证 5.2.3 法律因素之专利 5.2.4 问题解析 5.2.5 验证著作权,正本清源 5.2.6 调查专利,借力打力 5.2.7 解读许可证,明察秋毫 5.3 成熟度 5.3.1 优秀的领导者 5.3.2 差异化的开发者社区 5.3.3 庞大的优质用户群 5.3.4 健康的项目“脉动” 5.3.5 健全的安全补丁体制 5.3.6 较完善的文档 5.4 服务 5.5 寻找合适的开源软件 第6章 开源软件之语言和平台 6.1 Harmony 6.2 Android 6.3 Python 6.4 Ruby 6.5 PHP 6.6 Groovy 6.7 Perl 6.8 Flex 6.9 OpenLaszlo 第7章 开源软件之框架和库 7.1 Spring 7.2 Struts 7.3 JBossSeam 7.4 Equinox 7.5 Hibernate 7.6 iBATIS 7.7 Lucene 7.8 Webkit 第8章 开源软件之服务器软件 8.1 ApacheHTTP服务器 8.2 Tomcat 8.3 Jetty 8.4 Geronimo 8.5 JBoss 8.6 GlassFish 8.7 MySQL 8.8 PostgreSQL 8.9 Derby 8.10 FileZillaServer 第9章 开源软件之开发工具 9.1 Eclipse 9.2 NetBeans 9.3 ApacheAnt 9.4 ApacheMaven 9.5 CVS 9.6 Subversion 9.7 GIT 9.8 Bugzilla 9.9 JUnit 9.10 TestNG 第10章 开源软件之桌面应用 10.1 GNOME 10.2 OpenOffice.org 10.3 Emacs 10.4 Firefox 10.5 Thunderbird 10.6 GIMP 10.7 FreeMind 10.8 7-Zip 第3篇 参与开源项目 第11章 开源社区的基础设施 11.1 基础设施 11.1.1 主页(HomePage) 11.1.2 代码库(CodeRepository) 11.1.3 邮件列表(MailingList) 11.1.4 缺陷追踪系统(BugTrackingSystem) 11.1.5 Wiki 11.1.6 其他 11.2 开源项目托管网站 第12章 开源组织和社区 12.1 Apache软件基金会 12.1.1 Apache的历史 …… 第13章 商业模式与实例 第14章 参与开源社区 第15章 开创事业

开源之道·收入:适兕是如何生存的?

、OC SELECTED、点击上方蓝字 关注开源之道凡是遇到开源相关的聚会,无论是小型聚会,还是大型研讨,很多人都会对我的生存状态表示关心:适兕是如何生存的?通常情况下,这个问题是极为让...

johnwoo_lee的专栏 450

ArcGIS实战:地形湿度指数(TWI)计算全流程解析

本文详细解析了ArcGIS中地形湿度指数(TWI)的计算全流程,从DEM数据获取、填洼处理到水流方向与汇流累积量计算,最终实现TWI的精准计算。通过实战步骤指导,帮助读者掌握水文建模和土壤湿度预测的关键技术,适用于农业规划、生态研究等领域。

weixin_29231725的博客 872

MIPI DSI2接口开发避坑指南:以RK3576的GM8775C桥接芯片调试为例

本文以RK3576平台搭配GM8775C桥接芯片为例,深入剖析MIPI DSI2接口开发中的常见问题与解决方案。文章详细解读了从U-Boot阶段到内核DRM驱动架构的完整显示通路构建,重点分享了电源时序管理、寄存器配置与硬件协同调试等实战经验,为嵌入式显示系统开发者提供了一套系统化的避坑指南和调试方**。

weixin_29290379的博客 329

浅谈开源之道

以下是2021-10-09演讲的全部文字稿:我是来自第六组的Jacky,接下来我将阐述一下,我对“为什么要系统学习和理解开源之道,对企业,个人和组织参与开源项目有哪些指导意义?”的一点理解在我学习开源之道以前,我理解的开源就是“开放源码”,再加上一些CI工具,将源码再打包,发布到中央仓库,那么我就完成了开源工作。

2401_89308151的博客 939

国产麒麟系统下用Rider开发C#桌面应用:从环境配置到Avalonia UI实战

本文详细介绍了在国产麒麟系统上使用JetBrains Rider开发C#桌面应用的完整流程,重点讲解了Avalonia UI框架的实战应用。从环境配置、Rider安装到Avalonia项目创建和UI开发技巧,全面覆盖了在非Windows环境下进行C#开发的关键步骤和优化建议,助力开发者高效构建跨平台桌面应用。

weixin_27791839的博客 387

开源布道师适兕访谈录

「 没有人会理解一个中年男人为什么会在四十岁这个压力最大的年纪,放弃稳定的技术主管生活,去坚持做“开源布道”这件看起来没有名,也没有利,甚至前路漫漫的事情。」李建盛,1982年生,在临近35岁危机做出了一个令人困惑的决定:他要辞去技术主管的职务,做全职开源布道师。开源布道师对于大多数人而言是一个陌生的词汇,这在本土确实是一个新兴且十分小众的职业,它以推广开源为工作内容,通过演讲、出书、参加会议等方...

开源社KAIYUANSHE的博客 602

信号完整性仿真SI之Cadence Sigrity SPEED2000_眼图仿真(四)

今天给大家分享一个仿真的操作流程,是关于Cadence Sigrity SPEED2000的时域波形仿真和眼图仿真。我们会经常看见硬件工程师调试示波器上的一些信号的波形变化,其实这些也可以通过仿真电路的搭建来做出投板前的仿真,来优化走线,以减少版本的迭代次数。如果要和实际的信号保持一致,就要求仿真设置的参数和实际的参数保持一致,这也是仿真的重点和难点。下面先让我们了解一下Cadence Sigrity SPEED2000时域仿真的操作流程: 1.仿真模式选择与文件导入 选择Cadence Sigrity下的

刘小同学的博客 1万+

Transformer实战(30)——Transformer注意力机制可视化

在本节中,我们讨论了人工智能面临的最重要问题之一:可解释人工智能 (explainable artificial intelligence, XAI)。随着语言模型的不断发展,可解释性成为一个严峻的问题。本节中,我们从 Transformer 的角度出发,研究了 Transformer 架构中的自注意力机制,尝试通过各种可视化工具理解这些机制的内部过程。

盼小辉丶的博客 2686

“关起门来搞开源,做不了开源世界的Leader”

回顾自己职业布道的这一路,适兕有过心酸,也有欣喜。近两年国内对开源的认知度有所提高,这件事可喜可贺,但开源的含义却远比大家所认识的要更加广泛、深刻。那我们该如何理解开源?本期《开源访谈录》...

优快云资讯 1448

Easy系列PLC远程IO模块的安装配置和地址访问(EtherCAT总线)

EtherCAT分布式时钟DC(SOEM源码解析)EtherCAT分布式时钟DC(SOEM源码解析)_soem dc同步-优快云博客文章浏览阅读1.2k次。分布式时钟(DC,Dsitributed Clock)可以使所有 EtherCAT设备使用相同的系统时间,从而控制各设备任务的同步执行。_soem dc同步1200PLC连接分布式IO组态编程应用(ES200SP固件版本不同解决方法)

RXXW_Dor的博客 178

关起门来搞开源,做不了开源世界的Leader

现如今开源已成为全球技术创新的主流模式,并正赋能千行百业,特别是互联网行业秉承同样的“自由”与“开放”精神,更是与开源精神一脉相承,成了开源最大的推动力。

詹Sir的博客 226

文章ACCEPT之后填写内容教程-Springer-Verlag即施普林格

1. 确认corresponding author通讯作者机构是否正确(最好细分到系,如搜不到系只填大学也可)这些信息因为在投稿的时候都填过,所以一般都没问题,可确认并继续。2. Co-Author: 这篇文章有没有其他作者,如果有就选yes,并确认投稿时所填的作者姓名和机构是否正确。这个也是如果前期都填对了就不用修改。3. Research funders: 问文章的研究有没有资助,没有就选no,有就选yes,并填写机构名称和grant/contact numbers。

ZhangJiqun&191cm&85kg 4796

Allegro172版本DFM功能介绍

Allegro172版本提供了实时DFM检查的功能,让违反要求的地方实时以DRC的形式报出来,让加工不可加工因素在设计的时候同步避免。打开Constraint,选择Manufacturing, 所有DFM相关DRC都在这。把所有下面DRC开关(DFM,DFA,DFT)都选择on,选择OK。这个规则和物理和间距规则等等都没有关系,单独的一个加工规则。这些DRC大部分是正常的,正常的可以去修改规则来消除。等待DRC刷新,板子上会出现很多DRC,类似下图。下面介绍如何调用和产生DFM规则。一直往下点击next。

weixin_54787054的博客 1341

Leader-Line 开源项目教程

Leader-Line 是一个用于在网页上绘制连接线的 JavaScript 库。以下是其基本的目录结构: ``` leader-line/ ├── LICENSE ├── README.md ├── package.json ├── src/ │ ├── leader-line.js │ └── ... └── examples/ ├── index.html └── ...

gitblog_00523的博客 436

NTscan扫描工具

ntscan是一个扫描器,可以扫描没有密码和弱密码的共享,先到配置文件中填写猜测的用户名和密码,扫描过程中右侧出现的是扫描日志。

Kafka Leader机制解析

在分布式系统中,数据的高效传输和一致性维护是至关重要的。以Kafka为例,它是一个分布式流处理平台,能够处理高吞吐量的数据流。在Kafka集群中,数据的生产和消费是通过多个生产者和消费者节点来完成的。然而,当涉及到数据的一致性时,就需要引入一个核心的概念——Leader。场景问题:假设在一个Kafka集群中,多个生产者同时向同一个主题(topic)发送消息,同时也有多个消费者从该主题中读取消息。如果没有一个明确的领导者来协调这些操作,那么可能会导致数据的不一致和消息的丢失。

AIHacksCash的博客 1098

华为的C语言编程规范.pdf

华为技术有限公司内部技术规范。本规范制定了编写C语言程序的基本原则、规则和建议。从代码的清晰、简洁、可测试、安全、程序效率、可移植各个方面对C语言编程作出了具体指导。

计算机控制技术及应用

《计算机控制技术及应用》通过总结作者的科研成果和吸收国内外的先进理论、方法和技术,以计算机控制系统的网络化、开放化、智能化和集成化发展趋势为主线索,主要介绍计算机控制系统的基本概念和计算机控制系统的典型形式,计算机控制系统的数学描述与基本分析方法,以及数字PID控制器、最少拍控制系统、达林算法、状态变量设计法等设计方法及其各种改进算法。重点突出计算机控制系统输入输出通道接口的设计方法和典型控制系统的设计案例与实现方法等。

当了leader才发现,大厂最想裁掉的,不是上班总迟到的,也不是下班搞失联的,而是经常把这3句话挂在嘴边的

程序员作为一个有个性的创造性群体要专注精进技术这本身没错,但是职场毕竟也是一个充满人情世故的江湖,掌握一些通用的职场规则和沟通艺术也是十分有必要的,所以。当员工说出“这个需求做不了”时,背后的含义有可能是“我不想做”、“我不会做”或“我觉得没必要做”。回到文首的话题,说的似乎有些夸张,但在真实的职场里确实是存在的,工作能力当然重要,但是“沟通艺术”和“向上管理”同样也不容忽视。“当了 leader 才发现,公司最想裁掉的,不是上班总迟到的,也不是下班搞失联的,而是经常把这 3 句话挂在嘴边的”

CodeSheep 487

win10 跳过U8环境检测的IE WebControls.rar

win10 安装u8的时候 提示IE WebControls 不通过,这个工具可以欺骗u8的检查。 跳过U8环境检测的IE WebControls。提示导入失败后,重新检测通过。

如何做好技术Leader

遇到事情,不要只在后面push,大喊给我上,而能做到站在队伍头儿上,大喊跟我上。用我们开发代码来举例子,需求落地有一万种方式,而哪种方式最好,最容易维护,效率最高,这几乎不可能被有效的追踪,很大程度上依赖员工的自觉程度,其用心多,思考深,则效果好,其混日子,好摸鱼,虽非最优方案,但需求也能落地,只是为以后埋雷。汤姆索亚历险记里有个很好的例子:小汤姆的姨妈让他用油漆刷院子里的栅栏,这本来是一件枯燥的苦差使,但汤姆灵机一动,装作很陶醉痴迷的样子来刷栅栏,引得小伙伴们纷纷要体验一下,最终以物相易,才能换得机会。

ConstCpp的博客 940

Leader-Follower线程模型概述

1、 引言 大家知道,多线程网络服务最简单的方式就是一个连接一个线程,这种模型当客户端连接数快速增长是就会出现性能瓶颈。当然,这时候,我们理所当然会考虑使用线程池,而任何池的使用,都会带来一个管理和切换的问题。 在java 1.4中引入了NIO编程模型,它采用了Reactor模式,或者说观察者模式,由于它的读写操作都是无阻塞的,使得我们能够只用一个线程处理所有的IO事件,这种处理方式是同步的。为了提高性能,当一个线程收到事件后,会考虑启动一个新的线程去处理,而自己继续等待下一个请求。这里可能会有性能问题,就

图灵学院庄周老师 的博客 1576

【Kafka中的leader选举】

——— Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的 (replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理 大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、 Storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编 写,Linkedin于 2010 年贡献给了Apache基金会并成为顶级开源 项目。

m0_74120645的博客 1489

LEADER - 大模型蒸馏的药物推荐模型

特征级知识蒸馏:提出了一种新颖的特征级知识蒸馏方法,将 LLMs 最后一层 transformer 的隐藏状态作为知识传递给学生模型,而非传统的输出层概率蒸馏,更有效地转移了 LLMs 的语义理解能力。LEADER 的核心思想是利用 LLMs 的语义理解能力来提升药物推荐的准确性,并通过知识蒸馏将 LLMs 的能力转移到小型模型上,解决 LLMs 推理成本高的问题。考虑药物相互作用 (DDI):在基于 LLM 的药物推荐模型中引入药物相互作用的考量,进一步提升药物推荐的安全性和准确性。

simoncool23的博客 1284

zookeeper源码(07)leader、follower和observer

本文分析zookeeper中leader、follower的核心工作流程

xuguofeng2016的博客 1522
上一篇: 白鲸开源代立冬:一年5个孵化项目来自于中国,佛系Apache如何帮助中国开源立足全球?
下一篇: 姜宁当选2022ASF董事,将致力于帮助Apache全球化发展
开源头条
博客等级 码龄13年 1475粉丝 226原创
评论 7
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值