首页 文章 精选 留言 我的

精选列表

搜索[劳动争议],共3389篇文章
优秀的个人博客,低调大师

新旧之争,JDK 团队发起 Project Skara 引争议

JDK 团队在上周五发起了一起名为 “Project Skara” 的意见征集,旨在讨论如何改进自 2008 年以来一直使用Mercurial 存储库的 JDK 源码管理方案。 据悉,发起这个项目的原因是想帮助 OpenJDK 贡献者提高效率。JDK 开发者和 OpenJDK 审查员Joe Darcy 在邮件中写道: 为帮助 OpenJDK 贡献者提高效率,Project Skara 建议无论是经验丰富的提交者还是新人,都来参与讨论代替 SCM 和代码审查的选项,比如基于 Git 而不再是 Mercurial,甚至是其他第三方选择。 为更好地进行对比,Project Skara 还打算未来在不同的服务商下托管 JDK 12 的源码。 Joe 还列出了一些评估标准,供贡献者参考: 性能:从主存储库进行克隆操作的时间,本地操作的时间等 空间效率:在不同地区的可用性 支持 Linux、Mac 和 Windows 等常见开发环境 能够轻松承载 JDK 的整个历史以及未来十年的增长预期 支持常用的 JDK 代码审查实践 程序化 API,可辅助或自动化审核和管理流程 邮件发起后,参与者的意见明显分为两组:认为从 Mercurial 到 Git 会更方便的,以及已经习惯 Mercurial ,不认为折腾有啥好处的。 对于 Project Skara 提出的建议你怎么看?欢迎评论。

优秀的个人博客,低调大师

支付宝灾备能力为何引发争议

5月27日下午5点,拥有将近3亿活跃用户的支付宝出现了大面积访问故障,全国多省市支付宝用户出现手机和电脑支付宝无法登陆、余额错误等问题。对于导致此次事件的原因,蚂蚁金服方面的解释并未获得金融和互联网界的广泛认同。 在蚂蚁金服发给《财经》的官方回应中称,出现这一问题的原因在于市政施工导致杭州市某地光缆被挖断,影响了支付宝一个主要机房的正常运转。当天晚上19时左右,即在事故发生大约两个多小时以后,支付宝服务才恢复正常。 蚂蚁金服称,无法精确统计在故障时间段内使用支付宝的具体用户数量。 拥有超过4万亿年交易总额的支付宝是中国第一大第三方交易平台,约占中国整体社会消费金额的六分之一。故障发生后,用户普遍担心账户资金安全问题,亦有用户反应出现账户余额不同步的现象。 蚂蚁金服对此回应,支付宝有完善的技术和措施保护用户的资金安全,支付宝中的任何一个交易,同时都会有多份记录,数据可靠性极高。如果有用户出现交易不同步的情况,后续都会得到妥善解决。 这份蚂蚁金服发给《财经》的官方回应还指出,支付宝异地多活的系统架构在此次意外中发挥了巨大作用:一方面,没有因光缆被挖断而影响全部用户;另一方面,紧急将故障机房的流量切换至了其他机房。在当晚7点支付宝服务恢复时,被挖断的光缆还没有修复。 蚂蚁金服一位高管向《财经》记者表示,大流量网站实时切换涉及资金时有难度,需要安全地将用户的数据,尤其是资金数据也切换到其它机房,所以切换操作需要花费较多的时间。“技术上可以做到更快恢复,之所以较慢是为了确保不丢数据。” 蚂蚁金服对于这次事故的内部总结是,数据校验较多,怕丢数据,所以花了较多时间。内部认为这是一次安全但不够漂亮的灾备实战,就好比跳水,起跳不错,空中动作也还行,但入水压水花不够好。 《财经》记者了解,支付宝采用异地双活的系统架构,的确有多个机房。正因为如此,本次支付宝杭州机房网络中断,只影响了一个机房,其它机房的业务不受影响。 但这依然受到外界质疑。质疑焦点有二:一是恢复时间竟然长达两个小时;二是究竟是出于资金安全考虑而主动放缓速度还是支付宝应急预案出现漏洞? 一位国有大型银行内部人士向《财经》记者表示,如果在银行的支付系统发生大面积瘫痪超过2个小时,已经属于重大安全事故,很有可能要向国务院汇报备案。 他向《财经》记者强调,传统金融机构发生这样波及全国范围的安全问题几率微乎其微,原因在于银行涉及用户资金的重要系统灾备方案十分完备,一般是“两地三中心”云备份方案,保证“同城灾备结合异地灾备”,目的在于防止重大灾难或战争等极端情况。 上述国有大型银行内部人士认为,正因为此,如果银行系统出现支付宝因光缆被挖断而导致一个数据中心停摆的情况,用户流量和系统会向同城或异地其他数据中心切换。“就算不会是即时切换,也不会花费太长时间,同城可能会更快,就是用户根本感受不到延迟。” 这一说法得到多位接受《财经》记者采访的电信技术人士的支持。中国电信的一位技术高层人士分析,服务故障切换机制应该是自动的,根据一定的事先设置的策略,无需人为干预,人工可以在服务切换后,再重新定义流量疏导方式。 该人士称,支付宝多中心制的网络架构设计,不同于普通用户接入光缆宽带服务,不可能只是用一个区域性的小机房,一根光缆被挖断了就断服务了。支付宝机房服务的路由应该非常多,不可能只接一家运营商,即便只是一家,肯定也是多路由接入。“数据路由就像供电,来自不同的变压器和能原地。” 一位曾在汤森路透工作的阿里巴巴程序员亦向《财经》记者表示,汤森路透号称世界最大金融网络,处理全球实时金融数据,要求不能宕机,哪怕自然灾害或战争。他们机房这样建的:两条不同电信公司的光缆和不同电力公司的电缆分别从机房的两个方向进入,同一个机房的所有系统实时双备份,并建设两个不同城市(巴黎、日内瓦)机房同时实时处理相同的数据。 某大型国企网络运维人员称,从技术角度看,支付宝此次事故可能是内部应用模块出了问题,未经严格验证的应用被统一升级后,被意外触发到未知状态,会导致此类问题。 上述运维人员还表示,经他观察,支付宝DBA(数据管理人员)紧急恢复了RPO=10days的完整数据(RPO,Recovery Point Objective,复原点目标,是指当服务恢复后,恢复得来的数据所对应时间点,理想的状态是RPO=0,故障出现立即恢复,但需要极大投入),并不停地进行分段增量数据恢复,历时约2小时余,这就是应用模块的问题。 上述中国电信技术人士则分析认为,出现这种问题的可能性是,支付宝多个数据中心之间的自动流量切换机制出现问题,只能人工介入。还可能是其他三种原因:一是很有可能是支付宝遭到了攻击;二是支付宝的路由配置瘫痪了;三是支付宝的云服务器瘫痪了,亚马逊也出现过这个问题。号称最先进最安全的阿里云系统对自家业务并没支撑好。 就以上相关问题,《财经》记者询问了蚂蚁金服方面,蚂蚁金服回应称,具体的技术分析正在加紧进行,但得出结论判断还需要一段时间。 微妙的是,在蚂蚁金服更早的一份媒体回应中称,之所以花费较长时间,是在流量向支付宝位于深圳的数据中心迁移的时候,切换系统也受到了光纤断裂的影响,所以切换上花费了一些时间。这与“技术上他们可以做到更快恢复,之所以较慢是为了确保不丢数据”这一说法并不一致。 另有行业人士评价,此次事件反应出支付宝在故障倒换能力和应急反应速度上还有待提高,反应出互联网公司在应急处理能力上的普遍短板,互联金融系统的运行稳定性并不如此前所宣称那样完善。在支付宝发生大面积瘫痪事故之后,互联网企业的运维人员建立微信群对此展开了讨论。 随着云计算和大数据的逐步普及,以及人们在互联网应用越来越重的资产托付,IT技术领域普遍呼吁互联网公司改变“尽力而为”的服务承诺和网络架构,向传统电信、IT领域高达99.999%的“5个9”安全级别靠拢。 蚂蚁金服表示,支付宝将不断提升灾备切换速度,希望未来这样的切换能让用户无感知或者最小化感知。 对于此次事故带来的具体损失额度,蚂蚁金服表示,暂时无法统计。 作者:谢丽容 由曦 宋玮 来源:51CTO

优秀的个人博客,低调大师

李开复再回应争议:受益于开源也贡献开源

针对旗下“零一万物” 开源的 Yi 大模型近日被质疑照搬 Llama 架构,只对两个张量(Tensor)名称做了修改的风波,李开复在朋友圈转发了“零一万物对 Yi-34B 训练过程的说明”文章,并配文回应称: 零一万物 Yi-34B 模型训练的说明也回应这两天大家对于模型架构的探讨。全球大模型架构一路从 GPT2-->Gopher-->Chinchilla-->Llama2->Yi,行业逐渐形成大模型的通用标准(就像做一个手机 app 开发者不会去自创 iOS、Android 以外的全新基础架构)。01.AI 起步受益于开源,也贡献开源,从社区中虚心学习,我们会持续进步。 相关阅读: 李开复旗下 AI 公司 “零一万物” 开源的 Yi 大模型照搬 Llama 架构 “零一万物” 回应 Yi 开源大模型 “套壳” Llama 零一万物对 Yi-34B 训练过程的说明

优秀的个人博客,低调大师

《硅基加速之后:AI 时代的教育、劳动与公平制度》前言

我写这本书,不是为了再回答一次“AI 会不会取代人类”。这个问题太容易把我们带进一种简单的恐惧:仿佛未来只有两个选项,要么机器胜利,要么人类退场。我更关心的是另一个更难、也更现实的问题:当机器能力以硅基速度跃迁,而人的教育、职业转换和公共制度仍以碳基节奏缓慢更新时,我们怎样避免生产率提升演变成结构性断裂?

优秀的个人博客,低调大师

微软 AI 应用 Copilot “捆绑” LG 电视,不可卸载引发争议

据techpowerup报道,有用户发现LG电视webOS系统更新后预装了微软Copilot AI应用。 报道称,多位用户在 Reddit 等社区反馈同样情况,称Copilot以系统应用形式存在,无法通过常规方式卸载。部分用户担忧此类AI集成可能带来隐私与非必要数据处理问题。 此举被视为微软加速AI生态布局、拓展至电视等日常设备的最新动作。目前该应用在电视端具体功能尚不明确。此外,LG电视内置的“Live Plus”功能可在开启时识别屏幕内容,用于个性化推荐与广告投放。官方称其为“增强观看体验”,用户可通过设置菜单手动关闭。

优秀的个人博客,低调大师

谷歌与 FFmpeg 因 AI 发现漏洞引发开源责任争议

近日,Google Project Zero 因使用其 AI 工具 “Big Sleep” 批量发现 FFmpeg 等项目中的安全漏洞,引发了与 FFmpeg 开源社区的激烈争论。 今年 7 月,Google 推出新的“报告透明度”流程:漏洞发现后一周内告知上游项目,但仍维持 90 天公开披露期限。8 月,AI 工具 Big Sleep 在 FFmpeg 中检测出约 20 个安全漏洞。Google 随即向项目通报问题,但并未提供修复补丁。 这让由志愿者维护的 FFmpeg 社区强烈不满,认为 Google 等大型公司使用自动化工具大量生成漏洞报告,却将修补压力完全推给开源志愿者,既不公平,也加剧了维护负担。FFmpeg 开发者直言:“巨型科技公司用 AI 找漏洞,却要志愿者来修,这合理吗?” FFmpeg 社区称他们由志愿者维护,而非商业供应商,不应被迫承担由 Google 用 AI 工具发现漏洞所带来的“紧迫责任”。 Google 与安全研究人员则强调,FFmpeg 广泛嵌入浏览器、操作系统与应用中,是关键基础设施,必须及时处理安全问题。

优秀的个人博客,低调大师

Redis 试图控制 Rust 客户端库,引发商标争议

Redis 是当今广受欢迎的开源内存数据库,但其母公司 Redis Inc. 最近的一些举措在开源社区中引发了广泛的不满和担忧。 近日,Redis 公司联系了 Rust 语言的 Redis 客户端库 redis-rs 的维护者,表达了接管该项目的意愿。作为 redis-rs 目前的掌控者,Armin Ronacher 在网上披露了与 Redis 产品经理的沟通过程。Redis 表示,他们希望能有一个官方支持的 Rust 客户端,为此建议接管 redis-rs,未来会加入一些企业级的功能,但仍会继续接受社区贡献,并与 Redis 社区版保持兼容。 然而,Ronacher 从与对方的交谈中感受到,Redis 可能认为 redis-rs 这个名称侵犯了他们的商标权。而 Redis 给出的选择是,要么将项目所有权转让给他们,要么就得改名。Ronacher 表示不想卷入任何商标纠纷,但也担心这会影响到那些将 redis-rs 与 Redis 的开源替代品 Valkey 一起使用的用户。 事实上,Redis 在今年3月份已经将其核心代码的许可证从原来的 BSD-3 改为了更严格的 Redis Source Available License v2 或 Server Side Public License v1,从而限制了代码的使用范围。这导致出现了 Valkey 这样的项目,试图基于当时的 Redis 7.2.4 版本继续沿用 BSD-3 许可进行开发。 对于这一事件,技术社区论坛 HackerNews 上出现了大量讨论。不少开发者对 Redis 的做法表示失望,认为这是在滥用商标权利,对开源生态造成伤害。有人表示要转而使用 Valkey 这样的替代方案。但也有人指出,库的维护者个人是难以承担与商业公司对抗的法律成本的。 开源软件的许可证变更和商标归属问题,已经成为近年来开源界的一大挑战。当项目作者面对商业公司的压力时,如何权衡自身利益和项目的健康发展,并没有一个标准答案。这起 Redis 事件的后续进展,值得我们继续关注。开源社区需要探讨如何在商业利益与开源精神之间取得平衡。 询问AI

优秀的个人博客,低调大师

Ubuntu 开发商 Canonical 公司招聘问题引争议

网友分享了应聘Canonical 公司(Ubuntu 开发商)的经历。据介绍,这名网友面试的是 Ubuntu WSL 工程师岗位。不过面试刚开始他就选择了“跑路”,因为Canonical 公司 HR 发送的一封邮件列出了三四十个问题,并要求求职者以 PDF 形式进行书面回答。 于是这名网友看到邮件后,果断撤回了职位申请。 从这名网友提供的邮件截图可以看到,这些问题涉及到教育经历、软件开发工程经历、个人的行业影响力,以及对 Canonical 的看法和对 Canonical 文化的了解情况(考察文化契合度)等。有人认为,Canonical 此举不是招聘人才,而是赶走人才。因为这些问题无疑是将最好的候选人拒之门外。 在帖子的留言中,有网友分享了自己的技术面试经历: 电话面试 (phone screen) 完成在线任务(通常需要 4-30 小时) 自动在线编码挑战 视频通话形式的编码面试(通常 3-5 轮) 考察架构知识的白板面试(1-2轮) 文化契合度面试(1-2 轮) 直属经理面试以及最后四场面试可以合并成一个“现场面试”,如果幸运的话,基本上是在 6-8 小时的时间里连续进行各种面试。

优秀的个人博客,低调大师

报告数据泄露反被起诉,法案灰色地带再引争议

“农夫与蛇”的故事 近期,一个开放系统非营利组织的安全工程师(也曾是该项目的开发人员之一)近期向高组织报告了一次数据泄露事件。 按理来说,作为回报,他首先应该得到该组织的感谢,感谢他负责任地披露,但后来得到的却是警察和律师的来电,估计他心都凉了一大半。 Apperta基金会是一家总部位于英国的非营利机构,由英国国家医疗服务体系(NHS England)和英国国家医疗服务体系(NHS Digital)提供支持,旨在促进数字健康和社会医疗领域的开放系统和标准。 GitHub存储库泄露了密码、密钥和数据库 就在这个星期,一位名叫Rob Dyke的英国云安全工程师公开讲述了一次负责任的数据时间披露是如何让他陷入法律困境的。 本月早些时候,Dyke发现了一个公开的GitHub存储库,它泄露了属于Apperta基金会的密码、API密钥和敏感财务记录。 在发现这个GitHub存储库时,Dyke表示,这个存储库至少从2019年就暴露在外网了,工程师私下向Apperta报告了这一点,并得到了他们的感谢。 然而,在3月9日,他收到了上诉律师的法律信函,导致他不得不聘请自己的律师来代表他处理这件事情。 除此之外,他还收到了一封来自诺森布里亚警方一名网络调查员的电子邮件,其中的内容涉及到关于“滥用计算机设备”的控诉。 在接受BleepingComputer的电话采访时,Dyke表示,他此前也曾与Apperta合作过,作为目前在IT部门工作的人,他非常熟悉Apperta的既定机制以及向供应商负责报告安全漏洞的行业做法。 当他发现数据泄露时,Dyke立即向Apperta报告了相关事件详情。 然而,为了记录他所报告的内容,研究人员对他遇到的数据进行了加密,并将其安全地存储了90天,这也是作为协调披露过程的一部分。 Dyke在接受采访时说到:“我知道该怎么向他们报告。因此,我通过他们既定的程序向他们报告了此事,我当时也收到了他们的回复,他们向我表示了感谢,并承诺会立刻解决相关问题。之后我就再也没去想这些问题了...” 但是,一个多星期之后,Dyke收到了Apperta的律师发来的一封信,并声称Dyke的行为是“非法行为”,然后要求其书面承诺删除Dyke查看过的任何数据。 这件事情让Dyke非常的惊讶,尤其是考虑到他曾为Apperta工作过,而且Apperta团队里面有很多人还认识他。 在BleepingComputer看到的电子邮件中,Dyke进一步向Apperta的律师澄清,他所看到的信息已经在GitHub上公开泄露了两年多,并不是作为非法黑客活动的一部分而获得的专有数据。 作为责任披露的一部分,Dyke收集的细节是从Apperta在互联网上发布的可公开访问的公共URL获取的。 Dyke还专门发表了书面声明,并表示自己会销毁从公共网络服务(GitHub)获得的任何存储库副本,并提供销毁证明。 这名工程师告诉BleepingComputer,他相信警方的调查与Apperta事件有关,因为诺森布里亚警方负责监督Apperta办公室所在的司法管辖区。 Dyke表示:“我认为,对于一个提倡公开的组织来说,这不是一个可行的方法,所有这些都是与之相关的:透明度、问责制和责任感。既然我发现了这个漏洞,并帮助他们解决了,这根本不是解决问题的方法。我向[他们]保证数据会被删除,而且已经删除了。” 英国计算机滥用法案吓跑了80%的信息安全专业人士 这并不是信息安全工程师第一次被指控进入英国《计算机滥用法案》(CMA)的法律灰色地带。而英国的各大企业、组织和学术界都在敦促英国政府对已过时的《计算机滥用法案》进行改革。 根据CyberUp的调查研究,80%的安全专业人员在日常工作中都害怕触犯计算机滥用行为。 1990年发布的英国《计算机滥用法案》的规定非常广泛,甚至可以简单地将遇到数据泄露便可视为“犯罪行为”。根据该法案,甚至英国威胁情报提供者探测外国系统的工作活动也可能被视为非法行为。 BleepingComputer曾多次联系Apperta基金会和诺森布里亚警方征求意见,但我们没有得到回复。

优秀的个人博客,低调大师

豆包回应“安全漏洞”争议:恶意传播并夸大漏洞风险

针对近期网上流传的“豆包手机助手存在安全漏洞”内容。豆包手机助手团队发布严正声明称,相关内容系恶意炒作,相关作者在未向厂商报告漏洞信息的情况下,恶意传播并夸大漏洞风险。 声明如下: 一、字节跳动高度重视用户信息安全,设有公开的安全漏洞响应平台,为漏洞报告者提供丰厚奖励。截至目前,我方并未收到豆包手机助手漏洞的详细报告,也未接到网络安全相关监管部门的通报。根据国家《网络产品安全漏洞管理规定》,违规公开漏洞已涉嫌违法。 二、网传的漏洞演示视频,需要用户主动要求AI查看恶意邮件或恶意短信,才会触发攻击。如果没有用户指令,AI并不会去自动执行高风险操作。针对视频演示的攻击方法,豆包手机助手已升级了相应的防护措施。 三、任何系统都会存在漏洞,重要的是负责任地披露和修复漏洞。在未经权威机构核实、未向厂商合规上报、在相关漏洞没有完整技术细节的背景下,网络平台上出现大批量有组织的安全恐吓内容,这是典型的黑公关炒作。我司严正谴责此类危害用户利益、违背商业道德的恶意竞争行为,已对相关内容进行取证,并保留依法追究相关主体法律责任的权利。 四、屏幕视觉理解与自动化操作能力,是当前全球AI终端领域的前沿技术创新方向,谷歌近期发布的新款手机也搭载了与豆包手机助手同类技术驱动的自动操作功能。任何前沿技术的发展与成熟,都需要持续的迭代完善。豆包手机助手预览版仍处于测试阶段,我们始终以严谨负责的态度打磨产品,持续升级安全防护能力。

资源下载

更多资源
Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册