snakesss

snakesss 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 个人简介什么都没有

个人动态

snakesss 赞了文章 · 4月7日

思否开源项目推介丨EventMesh:云原生事件基础设施

开源项目名称:EventMesh
开源项目简介:动态插件式云原生基础服务
开源项目类型:企业开源项目
项目创建时间:2020 年 8 月
GitHub 数据:416 Star,105 Fork
GitHub 地址:https://github.com/WeBankFinT...

一、项目背景

近年来,随着微服务、容器、服务网格、 Serverless 等云原生技术的发展,事件驱动架构也再次成为热点,引起 IT 界广泛的关注。事件驱动架构是一种用于设计应用的软件架构和模型。对于事件驱动系统而言,事件的捕获、通信、处理和持久保留是解决方案的核心结构。事件驱动架构可以最大程度减少耦合度,很好地扩展与适配不同类型的服务组件,因此是现代化分布式应用架构的理想之选。

而微众开源的 EventMesh 项目就是以事件驱动为核心的分布式服务运行时,通过动态的插件式云原生基础服务层,将应用程序和中间件层分离,并提供了灵活,可靠和快速的事件分发和处理能力,同时可以对事件进行管理,可以作为应用进程的连接层,提供企业实现其数字化转型的目标所需的全套应用进程间通信模式。

EventMesh 项目于 2020 年 8 月在 GitHub 上对外开源,早期是为了解决微众银行内部多语言客户端接入消息总线的问题,随着云原生技术的不断发展成熟与落地,富客户端的复杂逻辑逐渐下沉到 EventMesh 中,演变成为了 Sidecar 服务,同时也可作为 Gateway 集群部署,以一种更通用的协议接口暴露服务,简化事件应用开发,供各种事件源和事件目标集成。

今年 2 月 EventMesh 正式通过国际顶级开源组织 Apache 软件基金会(简称 ASF )的投票决议,以全票通过的优秀表现成为 ASF孵化器项目。这是国内金融行业首个进入 ASF 孵化器的开源项目,标志着微众银行在践行金融科技全面开源道路上的重要里程碑。

二、项⽬介绍

image.png

EventMesh是一个动态的云原生事件驱动架构基础设施,用于分离应用程序和后端中间件层,它支持广泛的用例,包括复杂的混合云、使用了不同技术栈的分布式架构。

EventMesh架构:

image.png

EventMesh云原生结构:

image.png

Event Mesh允许将来自一个应用程序的事件动态路由到任何其他应用程序。Event Mesh的一般功能:

  • 事件驱动
  • 事件治理
  • 动态路由
  • 云原生
  • 流控
  • 负载均衡

关键部件:

  • eventmesh-runtime:一种中间件,用于在事件产生者和使用者之间传输事件,支持云原生应用程序和微服务
  • eventmesh-sdk-java:当前支持HTTP和TCP协议,未来会支持gRPC等
  • eventmesh-connector-rocketmq : 一种基于OpenMessagingConnector 接口的实现,该实现支持将RocketMQ作为事件存储,实现事件的发布与订阅

三、项目核心特性与能力

  • 可插拔式事件存储

EventMesh 不仅将事件生产者与消费者进行解耦,还降低了运行时与事件存储代码之间的耦合度。事件存储(DeFiBus/RocketMQ/Kafka/Redis 等)以插件化的形式接入 EventMesh,因此 EventMesh 可以更为灵活地扩展事件存储,通过对接不同的事件存储,用户可以享受到不同事件存储所具有的特性。

  • 云原生

EventMesh 遵循面向云原生的 OpenMessaging 接口定义,通过不同事件存储插件对接口的实现,完成事件的发布订阅,同时 EventMesh 对事件的定义遵循 Cloud Event 标准协议,统一了不同语言事件接入的协议入口。同时 EventMesh 支持 sideCar 形式的部署模式,可通过K8S进行管理。

  • 多语言代理接入,协议简化

EventMesh 可为多种语言 (java/go/python/c/...)进行代理,目前提供http/tcp 两种接入方式, 客户端不需关注事件存储组件的相关协议,仅需遵循 EventMesh 协议,与 EventMesh 对接,减少了直接对接事件存储的复杂度,降低不同语言客户端的接入成本。

  • 集群高可用

EventMesh 具有集群化能力,客户端通过负载均衡策略与 EventMesh 集群建连,支持 gateWay 形式的部署模式,EventMesh 对客户端支持组级别代理。

四、项目推荐

EventMesh 可以作为 Service Mesh 的补充,在应用程序之间实现更好的通信,并允许应用程序通过将某些功能放在网络层和应用程序层之间使我们可以更多地关注业务逻辑。但是,相比之下,两者有一些重要的区别:

image.png

这些区别体现了 EventMesh 的异步通信的特点和优势,以及相比 Service Mesh 具有覆盖更广泛应用场景的能力。诚邀关注云计算的你一同参与到 EventMesh 的建设中。

五、项目自荐

以 EDA+Serverless 架构理念驱动的 Apache EventMesh 填补了开源领域在 Eventing as A Infrastructure 的空白,它能解耦、屏蔽应用与底层中间件交互细节,结合 Knative、KEDA 等容器化技术,实现多形态部署,具有非常光明的发展前景。非常期待更多的贡献者加入到这个极富生命力的社区,共同打造云原生时代面向应用开发的核心基础设施。

思否开源项目推介

该项目已入选「SFOSSP - 思否开源项目支持计划」,我们希望借助社区的资源对开源项目进行相关的宣传推广,并作为一个长期项目助力开源事业的发展,与广大开发者共建开源新生态。

有意向的开源项目负责人或团队成员,可通过邮箱提供相应的信息(开源项目地址、项目介绍、团队介绍、联系方式等),以便提升交流的效率。

联系邮箱:pr@segmentfault.com

segmentfault 思否

查看原文

赞 8 收藏 1 评论 0

snakesss 关注了用户 · 4月6日

波波Nadia @bobonadia

SegmentFault 思否 COO
思否技术人访谈专栏作者,寻求报道、个人/厂商投稿、提供线索: nadia@sifou.com

关注 106

snakesss 关注了用户 · 4月6日

思否编辑部 @writers

让我们陷入困境的不是无知,而是看似正确的谬误论断。思考、否定、再思考,出家人不打诳语,撰文者不说空话。

欢迎通过私信投稿、提建议、分享素材、传闲话。

联系邮箱 pr@sifou.com 小姐姐微信:https://segmentfault.com/n/13...

关注 6252

snakesss 发布了文章 · 4月3日

尤雨溪深夜官宣:Vue 3 将不再支持 IE11

早在开发之初,尤雨溪便计划在 Vue 3 发布并稳定后兼容 IE11。如今 Vue 3 ,已发布多时,但 IE11 的全球使用率却呈明显下降趋势。Vue 3 是否还会针对 IE11 开发兼容版本?

昨日凌晨,尤雨溪在知乎针对上述问题给出了答案:Vue 3 将不再支持 IE11。RFC 详细地从原因、成本、后续维护等方面给出了解释。

image
以下为 RFC 原文翻译


原因

从 Vue 3 开发开始,一直到 2018 年底,我们就一直被问及 IE11 支持的问题。

很多用户都问过,Vue 3 是否会支持 IE11,我们最初的计划是先发布 Vue 3,让它稳定下来,然后再增加对 IE11 的支持。

在漫长的开发过程中,我们也对 IE11 的兼容性进行了研究和实验,但较高的复杂度以及手上繁多的工作,让我们不得不推迟它的优先级

当时间来到 2021 年,我们重新审视这个问题时,浏览器和 JavaScript 已经发生了很大的变化。

越来越多的开发人员开始使用更现代的语言特性,更重要的是,微软自己也开始通过对 Edge 的投资,积极推动用户停止对 IE 的使用

微软还在其主要项目(如 Microsoft 365)中放弃了对 IE11 的支持

就在几天前,WordPress 也决定放弃对 IE11 的支持

IE11 的全球使用率已经降至 1% 以下

当我们谈论面向公众的网站和应用程序时,IE11 正在明显快速下滑。

已经到了重新考虑 Vue 3 对 IE11 支持的时机了。


在 Vue 中支持 IE11 的成本

行为不一致

Vue 2 的响应式系统是基于 ES5 getter / setters 的。

Vue 3 利用 ES2015 Proxy 提供了一个性能更好、更加完善的响应式系统,而 IE11 无法 polyfill 这些特性。

这是主要的障碍,因为这意味着 Vue 3 要支持 IE11,它本质上需要发布两个具有不同行为的版本:一个使用基于 Proxy 的响应式系统,另一个使用类似于  Vue 2 的基于 ES5 getter / setters 的版本。

Vue 3 基于 Proxy 的响应式系统提供了近乎完整的语言特性覆盖。

它能够检测到许多在 ES5 中不敢想象的操作,例如属性的添加/删除、数组索引和长度突变,以及 in 操作符的拦截。

为 Vue 3 的 Proxy 版本编写的应用肯定不能在 IE11 版本中工作。这不仅给我们带来了技术上的复杂性,也给开发人员带来了持续的精神负担。

我们最初的计划是在 IE11 版本的开发构建中同时发布 Proxy 和 ES5 的两种响应性版本

当它在支持 Proxy 的开发环境中运行时,会检测并警告不兼容 IE11 的一些用法。理论上可行,但是复杂度巨大,因为它需要将两种实现混合在一起,并且有可能导致开发和生产之间的行为差异


长期维护负担

支持 IE11 也意味着我们必须考虑在整个代码库中使用的语言特性,并为我们的发布版本找到合适的 poliyfill / 编译策略。

每一个不能在 IE11 中被 polyfill 的新特性都会带来新的行为警告。一旦 Vue 3 承诺支持 IE11,就永远没办法摆脱了,直到下一个大版本。


库作者的复杂性

如果 Vue 本身可以完全覆盖掉这些复杂度,那么一定程度上我们还是可以接受的。然而,在与社区成员讨论后,我们意识到共存的两个响应性实现也不可避免地影响库作者的开发

通过在 Vue 3 中支持 IE11,库作者本质上也需要同样做一些决定。库作者不得不考虑他们的库使用的是哪种 Vue 3 版本(可能还支持 Vue 2)。如果他们决定支持 IE11,他们在编写库时,脑子里也必须时刻考虑 ES5 响应式系统的一些缺陷。


为 IE11 贡献持久力

没有人想支持 IE11。它是一个死气沉沉的浏览器,停留在过去。Web 生态系统向前发展得越远,我们在尝试支持它时,需要填补的缺口就越大。讽刺的是,通过在 Vue 3 中支持 IE11,我们给了它更多的生命力。考虑到我们的用户基础,放弃对 IE11 的支持可能会让它更快地被淘汰


对于需要 IE11 支持的用户

我们很清楚,对 IE11 的真正需求来自那些没办法做升级的人:金融机构、教育部门和那些依赖 IE11 作为屏幕阅读器的人。如果你正在构建一个针对这些领域的应用,你可能没有选择。

如果您需要 IE11 支持,我们的建议是使用 Vue 2。与其为 Vue 3 和未来的版本承担巨大的技术债,我们相信,把工作重心放在让 Vue 2 拥有更多 Vue 3 类似的特性更有意义,让两个版本之间的开发体验更相似。

一些我们考虑带给 Vue 2.7 的功能:

  • @vue/composition-api plugin 合并进 Vue 2,这会让使用 Composition API 开发的库同时支持 Vue 2 和 Vue 3
  • 单文件组件(SFC)中的 script setup 语法
  • emits 选项
  • 提升 TypeScript 类型支持
  • 在 Vite 中正式支持 Vue 2 (目前通过非官方插)

注:以上列表是暂时的/不详尽的,我们最后会在单独的 RFC 中讨论/最终确定。

原文链接:
https://github.com/vuejs/rfcs...
image

查看原文

赞 8 收藏 1 评论 5

snakesss 赞了文章 · 3月26日

自由软件之父回归自由软件基金会,惨遭 1933 人和21 家组织联名反对

Richard M. Stallman(RMS)是一个自由软件社区领域中的两极化人物,有人喜欢他,也有不少很讨厌他。

喜欢他的人说Richard Stallman为自由软件运动竖立了道德、政治及法律框架,是当今自由软件的斗士、伟大的理想主义者。这些人还认为他是自由软件运动的精神领袖,因为他创立了GNU计划及自由软件基金会FSF(Free Software Foundation)。

讨厌他的人说RMS经常发表一些让女性感到不舒服的极端言论,甚至有不少人说RMS的话充满了歧视,听了他的发言后认为这是一个可耻的人。

2019 年,他在已故 MIT 人工智能实验室创始教授 Marvin Minsky 卷入亿万富翁 Jeffrey Epstein 涉嫌性侵和拐卖少女案件中发表了不当的言论,迫于外界压力,RMS 宣布从自由软件基金会与 MIT 离职。

近日他要回归FSF(Free Software Foundation,自由软件基金会)的事件引发了自由软件领域激烈讨论,甚至有 1933 人和21 家组织联名反对他的回归。

RMS是如何回来的?

FSF本身并没有正式宣布这一消息,尽管其网站确实将RMS列为FSF董事会成员。FSF推特的最新消息是:「在Richard Stallman的声明公开之前,没有任何FSF相关人员被告知。」

FSF执行董事 John Sullivan 在接受采访时表示,按照FSF的章程,"董事由FSF有投票权的成员(包括董事)选举产生,不过也可以只由董事选举产生。"

RMS的情况是哪一种?John Sullivan没有直接说。

但从董事会成员的评论来看,RMS是由董事而不是投票成员选举产生的。FSF董事会成员、技术律师凯特-沃尔什在推特上写道:「不管RMS的回归能带来什么价值,我都不支持恢复其身份的决定。我很高兴我能表达我的观点,并投下反对票,但我很遗憾最终结果没有按照我的想法。」

RMS为什么被众多人反对?

其实RMS并没有做出什么违反公序良俗的举动,但他的确说了太多带有侮辱性质的话。可笑的是这些话并非有人刻意去收集,RMS本人将它们整理到网站上,并将其起名为《查理德·斯托曼的个人政治笔记》。

下面是他曾发表的一些观点:

1、当RMS谈到马文明斯基对一名被拐卖的妇女进行性侵犯的指控时,他说:「最可信的情况是,她向他展示自己是完全自愿的,这不是 "性侵犯",因为"'侵犯'假定他应用武力或暴力,而正在讨论的报告没有说这样的事情,只说他们发生了性关系。」

2、他在自己的个人网站里分享他对未成年人 「完全自愿」的看法,他经常反复评论「不诚实」的法律将与青少年的性行为贴上「强奸」的标签,即使她们是自愿的。

他还将美国法律与苏丹法律进行比较,称美国法律将强奸定义为包括与N岁以下的自愿性行为(其中N不等),这两部法律都伪造了强奸的含义。

对于一个女人与未成年人发生性关系,他说:我希望在我14岁的时候,有一个有魅力的女人这样「虐待」我。

讨论有关儿童色情的话题时他说:制作这样的照片应该是一种犯罪,但拥有这些照片并不是犯罪。 他还为恋童癖辩护:"几乎没有证据证明自愿参与'恋童癖'会伤害儿童的广泛假设是合理的。

3、他还发表了三篇关于唐氏综合症的文章。他建议,如果有人发现自己怀孕了,而孩子的唐氏综合症检测结果呈阳性,正确的做法是将孩子打掉。

他说人们决定把患有唐氏综合症的胎儿生下来是一种反常行为,患有唐氏综合症的人来到世上是没有任何意义,他甚至还说唐氏综合症的孩子与宠物没有区别。

4、RMS还在最初出版的《GNU Kind交流指南》中,用「它」来形容变性人,意味着变性人在他眼里并非人类。

遭 1933 人、21 家组织联名抵制

超过1933个人和21家组织联名发布抵制信,他们呼吁罢免自由软件基金会的整个董事会,因为他们允许RMS重新加入。

欧洲自由软件基金会表示对RMS的回归感到震惊,这个独立于FSF的组织呼吁RMS辞去所有FSF机构的职务。并终止与FSF和任何Richard Stallman担任领导职务的其他组织合作。其他众多的开源组织,包括OSI、Mozilla基金会和TOR项目也都要求将RMS从FSF中移除。软件自由保护协会(Software Freedom Conservancy)也停止了与FSF的合作。

抵制者们还认为应该将RMS从所有领导职位(包括GNU项目)中撤职,并禁止他参加包括自由软件、技术伦理、数字权利和技术社区的所有领域的讨论。

为了实现这一目标,抵制者们敦促那些有能力的人停止支持自由软件基金会,并建议他们拒绝为与FSF和RMS相关的项目做出贡献,同时建议大家不要参加FSF任何活动,也不要在有关欢迎RMS的事件中发表任何言论。


这一切的结果都源于RMS和FSF违背了自由这一理念,自由并非随意表达观点,而是要让更多人有权利去讨论,RMS固执己见的发表不受欢迎的内容,最终结果只能与「自由」理念背道而驰,FSF也是如此,如果不立即改变方向,将会有越来越多人终止合作。

查理德·斯托曼的个人政治笔记:
https://web.archive.org/web/2...

公开信:https://rms-open-letter.githu...

image.png

查看原文

赞 2 收藏 0 评论 0

snakesss 赞了文章 · 3月26日

专访中科院副总工程师武延军:“参与开源人数变多是好事,但要小心「开源踩踏事件」”

不久前,「一源初始,开放共创」开放原子开源基金会 2020 年度峰会于北京圆满落幕。峰会由开放原子开源基金会主办,阿里巴巴、百度、华为、趣链科技、SegmentFault 思否、招商银行等开源项目代表单位及开源社区协办,亦得到了全体理事单位的大力支持。

本次峰会围绕开源运营治理、开源教育与公益等方向开展了主题论坛分享。会议中,来自中国科学院软件研究所的副总工程师武延军以《开源操作系统和开源软件供应链的教学实践》为主题进行了分享。在大会上,武延军提到了开源软件供应链面临的三个主要问题:产业价值不高、社区贡献不足、生态受制于人。

为了进一步了解开源软件供应链的定位与目标,以及有哪些举措可以解决我国开源软件领域的困境等问题,SegmentFault 思否对武延军老师进行了专访。

专访 - 武延军

Q1:开源领域有很多角色分工,比如宣讲者、推动者等。您认为您在开源领域中的角色是什么?

我觉得我更像是教育工作者。科研院所本身具有培养学生的职能,目前全所有 500 多名学生,每年会新吸纳 100 多人,我们有责任把这些人往开源软件的大模式上去引领。

之前大部分人对开源还没有太多概念,包括像开源社区的运作模式、开源软件的开发模式、开源规则背后的理念,可能都没有太多理解。我们作为教育者把这些都教给学生后,对他们后续从事科研工作,是有很大帮助的。

对此我们也进行过一些实践,比如我们在实验室内部长期维护一份新生新员工指导手册,我们会推荐学生去看一些开源入门项目,比如 GitHub上 有个「first contribution」项目,可以教大家如何第一次为开源做贡献。

Q2:是否会涉及帮助学生分析、挑选开源项目的内容?有没有一些基本标准?

中科院的研究生基本第一年都在集中上课,第二年开始参与科研,第三年要开始找工作,算下来只有一年多的时间在专心做科研。从学生培养角度来说,我们有义务尽早告诉他们哪些开源项目是高质量的、有价值的、参与其中对他们的成长是有益的。

还有一个重要维度,是哪些开源项目对产业有帮助,甚至更大意义上说是哪些项目对解决国家面临的“卡脖子”问题是有帮助的。两者如果能结合在一起是最好的一种方式。

这也是软件所发起开源软件供应链点亮计划的初衷。我们希望从供应链的角度去分析哪些项目有价值,或者处于有风险的状态。

一个开源项目可能被很多工业级产品使用,但是有可能我们国家现在还没有人去参与,也没有人能掌握。如果这个开源项目出现了缺陷漏洞,或者后续版本不开源了,在这种情况下我们应该有人去把它承担起来,而不是一直“拿来主义”。

所以我们要把学生尽可能的引导到有价值且对产业有贡献的开源软件上,让他们既能完成自己的学业,学到有价值的东西,同时也能解决社会和国家的问题。

Q3:您认为学生群体在开源生态中是一个什么角色?

相对来讲,学生没有功利性和目的性,自我成长的意愿比较强,所以他们在社区里的活跃度会比较高。虽然不一定是贡献最多的,但在一定程度上确实可以推动社区的活跃度。

第二点来说,学生类似于接班人的角色。新生力量对开源的参与融入,意味着很有可能他将来走向工作岗位后会优先使用开源软件,使用开源社区中的开发模式,将开源文化带到他的工作当中,最后潜移默化的变成开源推广者。

培养学生参与开源的过程像是制作火种。学生开源群体就像火种一样,先是慢慢的被点燃,接着到更广阔的空间中去发光放热。

Q4:您认为开源的核心价值是什么?

首先我认为开源是人类社会共享互助精神在数字时代的体现,并在互联网的催化下将这种精神发扬光大。

第二点我认为开源是一种非常棒的人类文明薪火相传的模式。一个成果如果垄断在一个人或者一个团队手中,成果的传承会有非常多的不确定性,但开源可以将成果一直延续下去,实现累进叠加式的发展。

Q5:您认为国内的开源行业,现在发展到了哪个阶段?

近几年,特别是从去年到今年这一时期,国内的开源发展非常迅速。以前可能是分散的“点”,现在则形成了“面”。

具体而言,以前我们零零星星能听到一些国内发起的开源项目,个别开源老前辈也有一定的国际影响力,但并没有形成一种大的社区和生态。

从今年开始,像 openEuler 这样的开源社区在华为的大力推动下,变成了一个有目标、有组织、成体系的社区。它以操作系统为主线,把上下游生态全部连接起来,很短的时间就吸引到 2000 人以上的活跃开发者,这是以前从来没有过的。

还有像产学研协作,在以往的开源社区是很难出现的。但今年开源行业一个很重要的特征,便是产学研合作在开源社区里出现了,这将大大缩短学术界与产业的距离。

如果说以前我们叫游击队式的「开源 1.0」,今年开始可能真的到了正规军式的「开源 2.0」阶段,这是一个非常明显的质的变化。

Q6:您觉得推动开源发展的力量是什么?

我觉得跟国际形势变化有很大的关系。以前大家觉得“拿来主义”没问题,能满足商业诉求就可以。但贸易摩擦后,大家发现不能只考虑短期的商业利益,还要考虑业务的可持续性。像华为就是一个最明显的转变样板。

第二点我觉得可能是疫情的原因。大家在线上的时间变长,数字世界的一些文化自然而然会得到比较广泛的传播。

很多应用领域的 IT 工程师以前可能知道开源这个词,也接触过Linux等开源产品,但对开源的力量并没有直观感受。今年「武汉 2020」开源项目的出现,让大家一下就明白了——原来开源是通过充分的、自发的协作,让大家一起以共同的信念,去完成一个普通个人无法完成的宏大目标。

线上会议的普及对开源来说也是很好的推进。以前开源社区里的成员想聚到一起开会很难,但现在大家可以通过线上视频会议的形式来讨论、学习,让更多的人通过线上会议的形式参与到开源当中。

Q7:您觉得现在这种发展趋势,对开源来说是一件好事吗?

肯定是好事,这种状态如果能够一直延续下去,可能未来几年内我们就会进入到开源3.0阶段。

开源 3.0 是什么状态?我现在个人预期是,以后在中文世界里中国人主导的主流开源项目会越来越多,然后会以这些开源项目为起点,在世界开源产业里占有一席之地。国内也可能会出现类似于 Red Hat、Snowflake 这类重量级的开源公司,并能在商业上取得成功。

Q8:供应链是 2020 年的热词之一。开源软件供应链相比其它领域有什么独特性吗?

我觉得独特性体现在两个方面:“软件”和“开源”。

供应链这个概念在各行各业都有,特别是传统行业供应链已经非常成熟。但对于软件行业,有它本身的特点:迭代周期短、供应全球化、开发线上化、复制成本低、仓储集中化、用户多样化等等。

其中仓储集中化是一个比较有意思的特点。在没有 GitHub 的时候,每个站点可能都会存储自己的开源项目,但现在开源项目有 90% 以上应该都集中存储在 GitHub 中。这跟传统供应链完全不一样,传统供应链在每个国家、每个港口城市都有自己的仓储系统,但开源软件领域将这些都存放在同一个平台上。这是一个特点,但也可能是一种风险。

Q9:您进入操作系统领域已经有 20 年了,您认为开源对操作系统的发展有哪些促进或者影响?

开源对操作系统的促进作用是非常大的。回顾 Linux 的发展之路,可以发现它也是在开源运动之后才得到迅速的发展。

首先从开源操作系统的组成来看,一个主流开源操作系统包含的开源软件包大概有3万多个,是汇集很多人一起才能完成的一件事情。做一个商用操作系统是一件很严肃的事情,这3万多个包都需要保证得到很好的维护,才能进行大规模商用。例如谷歌的安卓系统,软件包和第三方库都是经过长期筛选之后,才变成一个成熟的商用操作系统。

第二点是从操作系统的推广和使用上来讲,开源操作系统在现阶段用户的接受度会更好一些。相对来说,开源会比较透明和开放,大家不需要过于担心系统的可控性以及数据的安全问题。所以我觉得开源操作系统会是社会未来最认可的一种模式。

第三点是操作系统的最终属性。从产业角度来看,操作系统已经过了直接盈利的阶段,它可能逐渐会演化为一种社会公共基础品,会成为一种基础设施。

想基于基础设施本身开展商业行为是很难的,肯定会依托于类似服务订阅的方式。在这种方式下,大家为什么选择你?可能就是要靠广泛的社区认可,靠对开源的贡献程度。

你在开源操作系统上做的贡献越多,大家可能就越倾向于找你来提供服务。未来操作系统一旦变成公共品,那可能围绕操作系统的商业必须要完全的去拥抱开源,通过对开源的贡献证明自己的实力。

Q10:OpenHarmony 是为这种操作系统提供一个生态平台吗?您觉得它对于整个生态有哪些推进作用?或者说它的价值点是什么?

我觉得 OpenHarmony 的核心定位也应该是根操作系统社区,跟 openEuler 一样,这样它才能价值高、意义大。

根操作系统社区作为商业版操作系统社区的基础,可以让商业版节省大量的人力物力,将更多的精力放在满足客户需求上,尽可能的去满足国内现阶段的一些共性需求,然后逐渐走向国际。

更高一层的意义在于,在当今世界格局下,中国对于操作系统的需求是非常强烈且场景是丰富的、市场是巨大的。我们有理由也应该有能力抓住这个机遇,发展一个属于我们的根社区,吸纳更多的软件包、吸引更多的开源人士、覆盖更多产业需求。

所以说 OpenHarmony 的意义是巨大的,期待它以后也能起到类似于高速公路、水电站和特高压电网这样基础设施的作用。


开源正在改变世界,开源软件、开源硬件、开源内容在各行各业有着越来越重要的地位,开源的模式在改变着各个行业的生产方式并大大提高了生产效率,但开源的发展仍需各界人士的积极参与。

开放原子开源基金会的使命是“一切为了开发者,一切为了全世界”。随着发展,开放原子开源基金会已经展现出了能力与价值。以「开源」为纽带的开放原子开源基金会号召各界人士一起来推动中国的开源事业,基金会愿意持续构建一个开源的生态,帮助大家共建、共治、共享。

segmentfault 思否

查看原文

赞 11 收藏 0 评论 0

snakesss 赞了文章 · 3月26日

专访 Tetrate.io 创始工程师吴晟:开源领域需要 40+ 的开发者,也需要更张扬的年轻人

不久前,「一源初始,开放共创」开放原子开源基金会 2020 年度峰会于北京圆满落幕。峰会由开放原子开源基金会主办,阿里巴巴、百度、华为、趣链科技、SegmentFault 思否、招商银行等开源项目代表单位及开源社区协办,亦得到了全体理事单位的大力支持。

会议中,Tetrate.io 创始工程师、Apache Member、Apache SkyWalking 创始人吴晟进行了主题分享,并参与了开源运营治理分论坛的圆桌讨论环节。在分享中,吴晟提出了对国内开源环境以及开源和商业间的思考。SegmentFault 思否对吴晟进行了专访。

image.png

Q1:如果需要给“开源”下一个定义,您认为是什么?

开源在我的印象中,是一个技术工程师在跨商业实体间合作的平台与机会。在传统的开发模式中,工程师开发的软件只能在公司内部共享,而借助开源,可以和其他公司的人一起来开发、分享。对于工程师来说,这样的开发模式会更有成就感,项目的质量要求相比之前也会高很多。

Q2:开源领域有很多角色分工,比如工程师、宣讲者等等,您认为您在开源领域当中的角色是什么?

主要还是一个工程师的角色。SkyWalking 最早就是我自己参与开发的项目,所以开发者的身份在我的日常当中占据很大的比例。布道、运营之类的工作也会有一些,但主要是在项目进入 Apache 基金会并顺利毕业之后,会有一些外部活动邀请进行相关的经验分享。

Q3:现在比较普遍的一种认知是,开源的参与者不只局限于开发者。您觉得各种角色的加入对开源来说会造成哪些促进或影响?

其实就像一个软件公司,除了开发者之外也是包含很多其它角色的。比如宣传市场、售前售后等等,但无论是哪一种身份,大家都是抱着同一个目的,在为同一个产品或开源项目在服务,在合作共建。

开源只是将这件事情放大了,把公司里由几个人干的事情进行更广泛的分工,找到更多擅长的人来一起完成。因为不可能一个人什么都会,需要有不同身份的角色参与其中。

Q4:能否分享一下您对国内开源领域的看法?

国内开源领域有一个现象,是大家现在看到了开源背后的更明确的商业价值,所以有点“一窝蜂式”的涌入。

这个现象的结果可能跟其它所有行业一样,在“一窝蜂”的涌入后,会在一个时间内变的非常繁荣,但到了下一个阶段,其中有一部分人可能会被淘汰掉。但泡沫总是会破灭的,能剩下的才是那些真正务实的项目和人。

开源项目的核心是为了解决一个具备通用性的问题。如果项目真的能解决一批人的问题,那不管泡沫破不破灭,它都会一步一个脚印的活下来。但如果单纯是靠造势、造泡沫发展起来,就会长得快破的也快,项目很快也会被大家忘掉。

Q5:您认为开源与商业间的关系是什么?开源项目应该如何协调与商业间的关系?

我最近在和 PingCAP 的朋友聊天中,谈到一个很有共性的思考。

以前的开源项目有几个发展阶段,最开始会是卖所谓的商业版产品,但这种方式在今天的成功率已经很低了。做开源项目的商业版,意味着会“藏”一些东西。但“藏”这个事情对于开源领域来说是很反感的,用户会认为你只是开源了一个玩具,开源出来的项目本身就没有多少价值,也会和商业版产生竞争关系。

比如你将一些功能“藏”了起来,外部的项目贡献者为你提供了一个一模一样的功能,你就需要考虑是否要将这项功能合并进来,如果不合并又需要用什么样的理由去拒绝。

所以现在最典型的开源模式就是像 RedHat 一样的全开源,项目功能全部都是开放的,只售卖咨询服务。全开源保留的只是“人”。写项目的人是我的,所以我在这个项目中最专业、最擅长。

第二种就是卖云服务。云服务应该是现在相对比较好挣钱的方式,但也有一定的门槛。比如说太小的开源项目或者太组件化的项目就很难售卖配套的云服务,而偏产品化的产品就相对比较好卖。

第三类在国内还相对较少,就类似于我们在北美的那家公司一样,做的是一个商业产品,但产品 95% 以上的功能都是来自几个不同的顶级开源项目。我们把它们“捏”在一起为客户解决一个实际的场景需求,提供了一个完整的商业产品。

Q6:您觉得什么样的企业适合参与开源?

我之前接触过各种各样的企业,如果要细分的话,如果一家想要主导开源,或者想要新做一个开源项目的话,企业一定要具备“技术范儿”,是一个技术导向的企业。

我们可以看到国内很多互联网企业开源的很多东西,可能过了两三年就没人管了。本质上开源的目的是因为内部需要,但很长时间没有进行改进,外部也只是拿走去用,然后开源项目的热度就慢慢降下去,没有人再使用了。这是一个最常见的情况。

另外一种,如果只是参与开源,那门槛其实就没有那么高。只要是自身也需要这个领域的东西,无论是使用还是贡献其实都是参与的一种方式。

Q7:企业开源项目两三年后便不再维护的原因,一般都有哪些?

没有找到商业化路径肯定是原因之一,没有利益驱动会导致后续不再投入成本进行维护。

第二种常见的现象是国内互联网公司的一个特性。很多公司的员工从一个职级晋升到另一个职级时,开源项目会是一个评估指标,所以很多工程师会利用工作时间和业余时间来完成这个指标。但随着两三年后的晋升成功,到了下一个级别的情况就不一样了。国内很少有高职级的纯工程师,基本上华为 20 级以上、阿里 P8 以上的时候,很难会有沉下心来写代码的工程师。

到了这种级别就需要分出一部分精力参与项目合作、市场宣传、管理等等,而开源项目的发展必然就会受到影响,甚至死掉。

但其实很多所谓的“KPI 开源项目”都是好项目,也有很多人用,也能解决很多实际的问题。但问题就是缺乏延续性,给大家一种感觉就是国内没有“开源大项目”。没有历史悠久、在领域内耕耘多年、特别资深的项目,国内这样的项目确实是比较少的。

Q8:您认为基金会的出现和介入,对这种情况是否能有所改善?

这个和基金会的运作模式有关系,也就是基金会模型的问题,比较典型的就是 CNCF 和 Apache 之间的区别。

如果一个项目捐献到 Apache,如果社区没有建立好,初始的人离开项目还是很容易死掉的。CNCF 也类似,会要求 3-4 家公司成为项目的主要构建者,如果少了一家公司可能不会对项目造成太大的影响,如果再少一家公司,情况可能就不同了。

基金会只是一种组织形式,可以让大家放掉很多顾虑。不会出现一家公司影响项目生死的情况,但项目的具体发展,即使是在 Apache 或者 CNCF 这类基金会中也有很多不那么成功的项目,包括我自己在 CNCF 中有一个参与了的项目,就做的很不成功。虽然那个项目做了铺天盖地的广告宣传、有名厂站台,但项目本身不是非常被市场需要,并没有预期中那么有用。

包括像我们这种最早的项目参与者,认为这个东西好像挺有用的,可以解决很多的问题,但随着深入,大家都觉得这个产品似乎并没有那么好,事实上的效果也没有达到预期。

所以项目会起到决定性的因素,如果项目不好,哪怕是最顶尖的工程师来操刀、加入最顶尖的基金会,该做不起来还是做不起来。

Q9:您觉得对于开源项目有没有一些评判标准?

最关键的就是项目的主人或核心贡献者,他们最清楚项目的价值与优劣。

往往我们在评价别人的开源项目时,会有很多空子可以钻。比如说 Star、Fork、Watch、Contributer、提交频率、issue 解决时间等等,这些都是有空子可钻的。尤其是对开发者来说,各种接口都摆在那儿,找到规律之后甚至都不要人来具体执行。

所以评价项目是不是真的有价值的重点,是有没有那么多人或者厂商,真的基于自己的需求在不停的和项目之间进行沟通、相互提高。如果能在项目中看到这种情况,那么这个社区可能就是成功的。哪怕有很强的商业背景、很强的 KPI 背景,只要用户认可,认为这是一个好项目,贡献者也认为这个项目符合我解决特定问题的思路,我们就会把这个事情干好。

我们举个最简单的例子,比如一个知名厂商开源的系统可以在一夜之间吸引到 1000 个工程师,吸引到 1000 个 contributer ,但另一个项目可能只有两三百位贡献者,不过都是真正有需求的用户,这两个项目的社区活跃性、体系化和延续性,都有很大的差异。后者实际上要强大的多。

不同的项目贡献者的数量肯定也是不一样的,如果是一个全套的 IT 系统,那么覆盖的人群就会非常广,而另一个项目可能只是其中某一个非常具体化、细节化的需求,覆盖的人群就会相对少很多。所以不能单纯从数量来作比较,还要考虑一个市场占比的问题。

Q10:SkyWalking 作为一个顶级的开源项目,成功的关键因素是什么?有哪些环节您认为做的比较好?

最重要的一点是大家真的需要这样的一个产品。SkyWalking 没有专职的 Marketing 同事,相对其他项目在宣传、包装之类的方面做得非常少。

我们还是希望好好的做技术,和研发人员打成一片。只要真的愿意来贡献,我们就可以深入探讨如何将这个事情做好。

下一步的计划比较清晰,要涵盖监控领域绝大多数的场景。

最早的阶段 SkyWalking 只做追踪这一块的业务,后来增加了拓扑图分析、Metrics计算、API 监控、Service Mesh、日志监控等等。我们会推出更全面的解决方案,也是因为看到一些贡献者有这样明显的倾向。

当初最难的问题我们解决了,现在大家希望的是将工具都能往这个上面来靠,将一些相对陈旧的东西迁移到最新的产品当中,保证平台的唯一性。

从项目本身来看,我们在 Agent 和 Mesh 做的最好,最核心的重点肯定会在这个方向,但从社区来看,是有这样的一个趋势。

Q11:国内外的开源社区,在运营模式和发展方向上是否存在一些区别?

主要的区别有两点。

第一点是参与者的专业性。国外有很多专业的“开源玩家”,在他们的职业生涯中可能碰到过 2、3 个成功的顶级开源社区或者开源项目,在做一个新的开源社区时会更加得心应手,不会走弯路。

第二点是团队作战,这在国内是最难的一件事情。我们的开源项目没有跨实体的集团做的,都是一两个人或者一家公司,在对抗国外可能是五家十家全球顶级企业开发的项目,在对抗一个行业。

国外很多行业都有一种私下的“君子协定”,他们会在同一个航道中走,而如果想跳出这个航道或者做一个平行航道,那就会不在同一个水位线上,很容易被对方淹没。

Q12:有哪些技术领域,国内可以通过开源来占据一些地位?

我们还是举 SkyWalking 的例子。在最开始做这个项目的时候,绝大多数人对 API 都不太了解,但国外做的其实是非常强的。我们要考虑的几个点是自己能不能走得出去。

全球化社交对中国来说是一个硬伤,这并不单纯是语言的问题,更多还是一个大的生活习惯和文化环境导致的。我们国家幅员辽阔,在大家的概念中出国永远都是一件“大事”,包括我之前所在的公司,出国参加一个会议,审批都要比国外多好几级。

但有些时候,出国甚至比国内出差在地理距离上还要近,比如去日韩、东南亚之类的,并且出国也很方便,但我国企业在这些地方发展的还是很有限。除了一些出海产品走出去了,但缩小到技术领域来看就更少了。

比如在东南亚和印尼,当地的技术活动是很多的,但中国没有机会去互相沟通、交流、推广开源解决方案等。我们可能需要先把这个壁垒打破,技术反而不是第一个致命的问题。

现在的问题是我们有好技术,但推不出去,是被迫在国内搞。而大家又会因为你的项目只在国内活跃,大家就会担忧你的盘面会不会太小、不被国外企业厂商接受。

现在行业内有一个共识,就是不能只在国内市场发展。短期可以,但可能不会做的太长久。

Q13:解决国内开源问题,最重要的一步是什么?

我的想法是“一上一下”。

大家都在讨论开发者 35 岁或者 40 岁会是一道鸿沟,我觉得这在短期内确实很难避免,毕竟这和国内很多企业实际的运营情况相关。“上”就是指 35 岁以上、40 岁以下的工程师能不能有更多的人留下来,企业给他们更大的空间去写代码?

我有一个感受,在国内大家可能觉得我是一个资深的工程师,但每次出国参加活动我都是最年轻的。国外有些工程师可能代码已经写了 40 年,头发都白了。之所以坚持下来,也许他挣得足够多,也许他只是单纯的喜欢,但那个环境给了他这样的一个机会。

我们在日常的项目运营中,看到很多年轻工程师有精力、有一腔热血,但做事情很容易走错方向,因为行业经验太少了,是按照以往的经验来干活,不知道前面可能有一些什么样的坑在等着。

但假如有这种 40 岁以上的开发者能帮他们指出问题,就可以少走弯路。哪怕他们的代码量不多,但代码质量相对来说一定会是很好的,并且更能沉得住气来解决问题,更能接受长线的运营项目,就像中国的第 N 个五年计划一样。我觉得这是对高年龄程序员的一个定位。

我非常愿意看到有一天,当我们在 coding 的时候既有年轻人,也有资深年长的程序员,

“一下”,指的是学生群体。现在很多老师已经做了很多工作,所以这部分的发展比上面的发展要好很多。我经常能看到很多新鲜血液,比如 SkyWalking 的群里就有高中生。虽然我们的项目是个工业项目,不知道对他来说会怎样使用,但能吸引年轻人的重视,是一件很好的事情。

现在大家都很重视年轻人,无论是媒体、政府还是厂商,都非常重视对于学校的布道,只要我们把该讲的讲对了,别布错了方向,那我觉得这部分之后的发展,问题不大。

Q14:您觉得给年轻群体推广开源文化,有哪些需要注意的点?

我觉得要让我们的学生更张扬一些。我喜欢现在的一些 90 后,能在文字的环境中表现出张扬的一面,但我希望他们能够再张扬一些。

你要相信你的观点和观念,真有经过讨论和学习,确认别人的观点更好或者更准确的情况下,再去放弃自己的观点和观念。但无论如何,都要能站出来,持续的表达自己的观念。现在能看到很多大学生观念很强,但对于维护自身观念的坚持不够。

第二点就是需要给学生更多上台的机会。我国的教育常年造成的一个现象是没有人愿意站在台上讲,一上台就会跑掉一半的人。做卷子可以、写文章写邮件文字采访可以,但如果要上台讲个 10 分钟,那分享的东西可能就乱套了。

国外的学生因为教育的原因,在个性方面相对会更加张扬,更能在公开场合坚持表达自己的观点。SkyWalking 有一个 90 后的贡献者,他就是那种知道自己经验不足但会坚持表达的人,这样才可能做出一些之前想不到的事情。比如他把 SkyWalking 集成到了 IDE 中,在源代码中就可以看到指标,这个思路就很特别。

这就是年轻人的独特价值,是 40 岁的开发者提供不了的。但 40 岁的开发者可以保障你的奇思妙想得到很好的、快速的实现,避免走偏路。

只有“上下”都发展起来,整个开源的队伍才能建立起来。现在开源领域大部分的开发者工作年限可能也就是 5、6 年,虽然也能在一些项目中看到一些 40+ 的开发者,但他们大部分都是没有开源经验的。国内这方面的发展可能确实还需要再熬一熬、等一等。

开放原子开源基金会在开源领域开了一个先例,我们虽然不能指望有什么快速的产出,但他给了我们一种可能性、一个靶子。给了我们一个去做比较、去发现问题的方式。

基金会中第一批开源的项目,我们不能下定义它们是否会成功,但无论结果如何,在发展的过程中会有很多教育和借鉴的意义,这可能是最有价值的地方。


segmentfault 思否

查看原文

赞 8 收藏 0 评论 0

snakesss 赞了文章 · 3月24日

“既违反了隐私,又违反了信任”!亚马逊资深驾驶员因不满公司监管辞职

Amazon

技术监管与个人隐私保护是一个老生常谈,但边界模糊的问题。借助技术力量进行监管可以有效降低安全风险、增加流程效率,但不可避免的会涉及到对个人隐私的侵犯。

近日,一位亚马逊的物流司机就因为公司在货车中安装 AI 摄像头而辞职,认为公司对个人信息的监控实在是太多了,并表示“这既违反了隐私,又违反了信任。”

“这既违反了隐私,又违反了信任。”

Insider 在前不久的一个报道中称,亚马逊正在为所有送货车辆配备 AI 摄像头系统 —— Driveri,该系统由一家名为 Netradyne 的公司生产。摄像头始终处于打开状态,并扫描驾驶员的肢体语言,车辆速度,甚至睡意。然后,系统使用“自动口头警报”来告知驾驶员是否检测到违规行为。

看起来是一项驱动社会进步改革的技术,能有效提高司机的驾驶安全以及物流的运输安全,但从货车司机的视角来看,这更像是给他们戴上了一副“枷锁”。

Vic 从 2019 年开始在亚马逊担任货车驾驶员的工作,亲身经历了近两年亚马逊政策的变化。他告诉媒体,亚马逊的监管机制正变得越来越严格,最开始是提供了一个应用程序来跟踪货车的行驶路线,然后是借助 App 每天进行人脸打卡,而“压死骆驼的最后一根稻草”,就是这次的 AI 摄像头。他还表示,公司要求驾驶员同意接受持续监视以完成工作,这看起来像是一种“强迫”。

在该技术应用在货车上时,亚马逊曾在一次媒体采访中表示,“我们在运营方面进行了一笔安全投资,开始在我们的物流车队中推出业界领先的基于摄像头的安全技术。该技术将为驾驶员提供实时信息以及警报,帮助他们在旅途中保持安全。”并表示驾驶员录像不会自动提供给亚马逊,并且只有在检测到安全或违反政策后才会触发“实时反馈”。

而此次离职事件发酵后,亚马逊尚未发表相关评论。此前这家科技巨头就因对仓库中的员工进行跟踪与监视,陷入技术监管与个人隐私间的争议,并引起整个社会以及科技领域的关注。

“两难困境”,作何解?

亚马逊陷入的困境,前不久国内的一家物流公司也遇到了类似的情况,不过情况正好相反 —— 亚马逊因为监管过渡,受到内部驾驶员的公开抵制,货拉拉因为监管不到位,陷入社会舆论的风波。如何应对多样复杂的场景,如何借助技术力量管理、辅助驾驶员,同时又不过度侵犯驾驶员与乘客的个人隐私,这样的两难困境是否有解?

在货拉拉发布安全整改举措公告两周后,货拉拉宣布上线行程录音功能并试运行车载设备。货拉拉方面对记者表示,目前已经完成的具体举措和对应进展是:跟车/搬家订单的全程录音功能上线;承载录像和信息采集功能的“安心拉”智能行驶记录仪,已开始在长沙装车进行产品验证,试运行和优化后逐步向全国推广;其他整改措施也正按计划推进。

“安心拉”通过多路摄像头(驾驶室摄像头、路面摄像头、货厢摄像头)、GPS 等传感器全方位采集车内环境和货物数据,获取更多订单内实时信息,并且与货拉拉 App 联通。这一举措与亚马逊的 AI 摄像头类似,作为一种积极的尝试,不知道真的全面推行后是否会面临同样的问题。

隐私保护与社会发展,需要一个合适的平衡点

在如今这个智慧时代,人们的生活正在变得越来越方便:打开手机,就能随时查阅新闻,点外卖;打开电视,可通过语音交互寻找最想看的内容,或是控制全屋智能家电设备。然而,在享受智能生活的同时,人们也无法避免自己的生活被转换成大量的数据。

对于用户来讲,个人信息安全已经越来越重要,关乎财产安全甚至生命安全。越少的曝光途径就越安全,哪怕隐私数据不会被收集,也没有人愿意在监视器下生活。但另一方面,如果借助技术的力量获取更多有效信息,必然可以为社会的稳定与积极发展带来不可估量的价值,这也是一个不可逆转的社会发展方向。

隐私保护与社会发展,需要找到一个合适的平衡点,而这个点到底在哪里?可能没有任何一个单独的角色可以给出答案。

segmentfault 思否

查看原文

赞 2 收藏 0 评论 3

snakesss 赞了文章 · 3月24日

恐怖的未来战争!美国AI战斗机即将进行实机测试

被外界称为五角大楼「疯狂科学部」的美国国防高级研究计划局(DARPA )开发的人工智能战斗机马上进入实机测试阶段。

该军事研究机构的算法在去年的虚拟混战中成功击落一架战斗机,今年2月,该机构对战斗机进行了团队测试,这场战斗中两架F-16对阵一架「敌机」,每架战斗机都配备了一门用于短距离交战的火炮和用于较远目标的导弹,结果在意料之中,「敌机」被快速摧毁。

DARPA是谁?

美国国防高级研究计划局 (Defense Advanced Research Projects Agency),简称 DARPA ,是美国国防部属下的一个行政机构,负责研发用于军事用途的高新科技。

该机构成立于1958年,当时的目的是对苏联突然发射第一颗人造卫星的回应。他们的宗旨是“保持美国的技术领先地位,防止潜在对手意想不到的超越”。

DARPA成绩不仅仅体现在军事上,众多重大科技成果上都能追溯到DARPA的资助,如互联网、半导体、个人计算机操作系统 UNIX 、激光器、 全球定位系统(GPS)等。

DARPA在20世纪90年代就提出无人机作战的理念,曾有不少人讥讽为“DARPA的幻想”,而现在这幻想马上就要成为现实。


DARPA战略技术办公室的项目经理Dan "Animal "Javorsek上校说,测试多种武器和飞机会为试验带来新的动力:

这些新的交战代表了在算法中建立信任的重要一步,因为它们允许我们评估人工智能代理如何处理为防止自相残杀而设置明确的火力限制。当包括有人驾驶的战斗机在内的动态和混乱的环境中使用进攻性武器进行操作时,这是极其重要的,并且还提供了增加与操纵两架飞机与对手有关的复杂性和团队合作的机会。

DARPA也在评估飞行员对系统的信任程度。Javorsek说,他们已经在喷气式飞机上安装了传感器来测量生理反应,比如飞行员的头部指向哪里,眼睛在哪里移动。

这使我们能够看到飞行员通过观察窗外的情况来检查自主权的程度,并将其与他们在战斗管理任务上花费的时间进行比较。

在真实世界进行测试

在完成虚拟测试后,DARPA快速的将测试计划推进到真实世界的飞机上。为此,DARPA正在打造一架L-39喷气式教练机的航空性能模型,一旦模型完成,将开始把它与飞机融合。

DARPA计划在2023年底或2024年初的真实世界飞行混斗中测试它们。

这一计划得到了不少美国人的支持,但也有一些批评者对试验的价值提出了质疑,因为就AI算法完全掌握了空中混斗,但模拟训练的数据都是美国20年前的作战数据,而且模拟器上提供的完美情况在实战中是无法获得的。他们认为在真实的对战中,这些人工智能战斗机将吃大亏。

还有一些学者认为还有一个更紧迫的问题是,AI军备竞赛可能导致各国在人工智能的安全性上放松警惕,结果可能会引发一张战争....


美国作家海明威曾在《致下一场战争:一封主题严肃的信件》写道:「在现代战争里,你只能像牲畜一样毫无意义地死去。」

那么未来的战争呢?我相信人工智能战斗机已经给出了答案,我们在AI眼里和一块「石头」没有任何区别,正验证了那句话:毁灭你与你何干。

image.png

查看原文

赞 1 收藏 0 评论 0

snakesss 关注了专栏 · 3月24日

微众开源动态

关注 761

snakesss 关注了专栏 · 3月24日

SegmentFault 行业快讯

第一时间为开发者提供行业相关的实时热点资讯

关注 63483

snakesss 关注了专栏 · 3月24日

民工哥技术之路

公众号:民工哥技术之路、《Linux系统运维指南 从入门到企业实战》作者。专注系统架构、高可用、高性能、高并发,数据库、大数据、数据分析、Python技术、集群中间件、后端等开源技术分享。

关注 31981

snakesss 关注了专栏 · 3月24日

终身学习者

我要先坚持分享20年,大家来一起见证吧。

关注 57075

snakesss 关注了专栏 · 3月24日

疯狂的技术宅

本专栏文章首发于公众号:前端先锋 。

关注 31420

snakesss 关注了专栏 · 3月24日

恒温

关注 1105

snakesss 关注了专栏 · 3月24日

前端路漫漫

路漫漫其修远兮 吾将上下左右东西南北中发白而求索

关注 3566

snakesss 关注了用户 · 3月24日

lulu_up @lulu_up

自信自律, 终身学习.
躬身入局, 皆为吾辈.

关注 2306

snakesss 关注了用户 · 3月24日

码哥字节 @magebyte

公众号-码哥字节

一个有品位的博主,不跟风不扯淡,助力程序员成长。

一线大厂互联网工作经验,左手微服务、右手中间件、前脚高并发、后脚分布式。

关注 6342

snakesss 关注了用户 · 3月24日

MrWang @mrwang_5aefec8fc0f13

理想的光芒很难照进现实

关注 1323

snakesss 关注了用户 · 3月24日

lryong @lryong

专注于 Go 程序开发和技术进阶,包括操作系统、计算机网络、系统设计、算法数据结构和开发进阶。不定期分享在程序员道路上的思考和见解。

我的微信公众号:【程序开发进阶

欢迎同行朋友关注,我们一同交流,相互学习,共同成长!!

关注 1178