马上周末了，想问下 V 友，大家每天做什么事，自己觉得生活是充实的？
mmrindextt:
腾讯云 deepseek 接口并发上限是 5，是给企业用的吗？
gefangshuai: 我们的业务是用 deepseek 分析总结客户上传的报告。
企业 5 个并发根本不够用啊！
后来研究火山发现是 30000RPM ，5000000TPM ，这是秒杀腾讯的级别啊。
有大神知道是为什么吗？腾讯为什么设置最多 5 个并发上限？资源不够？
企业 5 个并发根本不够用啊！
后来研究火山发现是 30000RPM ，5000000TPM ，这是秒杀腾讯的级别啊。
有大神知道是为什么吗？腾讯为什么设置最多 5 个并发上限？资源不够？
放弃日本45亿重大项目 电动汽车专家徐福国回国任教
据媒体报道，电动汽车控制系统专家徐福国，放弃了一项由日本政府资助、投资45亿日元（约2.2亿元人民币）的重大项目，选择回国任教，目前已加入大连理工大学，担任机械工程学院教授。
据介绍，徐福国2019年9月博士毕业于日本上智大学，其后分别在上智大学，日本东京都市大学和日本千叶大学从事博士后，助理教授和副教授。
他在日本工作了十年，期间曾为丰田汽车开展开创性研究，并在具有里程碑意义的汽车项目中担任领导角色。
他的研究主要集中在控制工程方面，包括新能源汽车动力系统的控制、智能网联汽车及其自动驾驶决策与控制、电网中电动汽车的充电控制，以及控制理论的研究。
2016年至2021年，徐福国主导了丰田汽车两个关键子课题研究：一是智能混合动力汽车的最优控制技术，二是大型电动汽车的最优充电控制技术，这些研究属于丰田开发下一代发动机控制技术的核心项目。
最近他还在日本新能源和工业技术开发组织发起的一项重大政府项目中担任领导角色，该项目涉及31所日本大学和75家汽车公司，旨在提高乘用车和商用车合成燃料的使用效率。
报道称，在大连理工大学网站此前的介绍中，曾指出徐福国参与一项45亿日元（约2.2亿元人民币）的项目，但相关信息已于3月26日修改，未标注具体金额。
此外，徐福国近年来还在Automatica、IEEE TVT、IEEE TITS等国际著名期刊发表论文40余篇。
美国对超 200 万辆本田汽车展开调查，自动启停故障导致车辆需“搭电启动”
IT之家 3 月 28 日消息，据路透社报道，美国国家公路交通安全管理局（NHTSA）今日宣布对 220 万辆本田汽车展开工程分析，以调查发动机重新启动故障的相关安全隐患。
部分车主投诉称，在启用自动启停（Auto Idle Stop）功能后，车辆在红绿灯或路口完全停下后无法自动重新启动，甚至需要“搭电启动”才能恢复行驶。
本田曾于 2023 年 1 月发布服务公告，针对部分车辆的“无法重新启动”问题提出两阶段解决方案。不过 NHTSA 缺陷调查办公室（ODI）表示，部分已实施本田解决方案的车主仍然报告了自动启停系统（AIS）失效的问题。
本次工程分析将评估该问题是否构成安全隐患，并进一步收集本田相关维修措施的数据。IT之家从报道中获悉，ODI 目前已收到 1384 起相关报告，其中 4 起导致事故或火灾，2 起造成人员受伤。
此次调查涵盖多个本田车型，包括在当地畅销的 Pilot SUV（2016 至 2025 款）和 Ridgeline 皮卡（2020 至 2025 款）等。
公众号发了篇文章最后贴了个新建的星球试试总没坏处的
cobbage:
Linux Flips Around Its Behavior For Spectre-BHB Handling On ARM64
All of the ARM64 changes were merged this week to the Linux 6.15 kernel for enhancing the 64-bit ARM processor support.
Linux 6.15 on the ARM64 architecture side adds SMT run-time controls for those running the rare ARM processors that support Simultaneous Multi-Threading. Now like x86_64 and other architectures, the SMT status can be toggled at run-time thanks to that work by HiSilicon.
With a change made by a Google engineer, Linux ARM64 will now assume AArch64 processors are vulnerable to the Spectre-BHB (Branch History Injection) vulnerability by default if they are unknown or aren't otherwise marked as safe from Spectre-BHB. As explained in the prior patch series that is now merged for Linux 6.15:
This Spectre-BHB change for ARM64 cores is also marked for back-porting to existing Linux kernel stable series pre-6.15. For more background reading on the topic: Some Qualcomm CPUs Left Exposed To Spectre Vulnerabilities On Mainline Linux.
The ARM64 code for Linux 6.15 also adds Arm "Rainier" CPU PMU support, support for partial virtualization of the Apple M1 PMU, MOPS memcpy/memset support for uaccess routines, and CPU type information reporting for some Qualcomm Kryo cores. More details for those interested via this pull.
Linux 6.15 on the ARM64 architecture side adds SMT run-time controls for those running the rare ARM processors that support Simultaneous Multi-Threading. Now like x86_64 and other architectures, the SMT status can be toggled at run-time thanks to that work by HiSilicon.
With a change made by a Google engineer, Linux ARM64 will now assume AArch64 processors are vulnerable to the Spectre-BHB (Branch History Injection) vulnerability by default if they are unknown or aren't otherwise marked as safe from Spectre-BHB. As explained in the prior patch series that is now merged for Linux 6.15:
"The code for detecting CPUs that are vulnerable to Spectre BHB was based on a hardcoded list of CPU IDs that were known to be affected. Unfortunately, the list mostly only contained the IDs of standard ARM cores. The IDs for many cores that are minor variants of the standard ARM cores (like many Qualcomm Kyro CPUs) weren't listed. This led the code to assume that those variants were not affected.
Flip the code on its head and instead list CPU IDs for cores that are known to be _not_ affected. Now CPUs will be assumed vulnerable until added to the list saying that they're safe.
As of right now, the only CPU IDs added to the "unaffected" list are ARM Cortex A35, A53, and A55. This list was created by looking at older cores listed in cputype.h that weren't listed in the "affected" list previously.
Unfortunately, while this solution is better than what we had before, it's still an imperfect solution. Specifically there are two ways to mitigate Spectre BHB and one of those ways is parameterized with a "k" value indicating how many loops are needed to mitigate. If we have an unknown CPU ID then we've got to guess about how to mitigate it. Since more cores seem to be mitigated by looping (and because it's unlikely that the needed FW code will be in place for FW mitigation for unknown cores), we'll choose looping for unknown CPUs and choose the highest "k" value of 32.
The downside of our guessing is that some CPUs may now report as "mitigated" when in reality they should need a firmware mitigation. We'll choose to put a WARN_ON splat in the logs in this case any time we had to make a guess since guessing the right mitigation is pretty awful. Hopefully this will encourage CPU vendors to add their CPU IDs to the list."
This Spectre-BHB change for ARM64 cores is also marked for back-porting to existing Linux kernel stable series pre-6.15. For more background reading on the topic: Some Qualcomm CPUs Left Exposed To Spectre Vulnerabilities On Mainline Linux.
The ARM64 code for Linux 6.15 also adds Arm "Rainier" CPU PMU support, support for partial virtualization of the Apple M1 PMU, MOPS memcpy/memset support for uaccess routines, and CPU type information reporting for some Qualcomm Kryo cores. More details for those interested via this pull.
据称可折叠iPhone的显示屏将采用类似iPad的4:3宽高比
据此前泄露过苹果即将推出的“iPhone Fold”显示屏尺寸的中国泄密者称，这款书本式设备的屏幕尺寸为 4:3，可折叠屏幕。微博账号“数码闲聊站”声称，苹果将在内屏上采用“大致”4：3的宽高比，以实现与外屏的一致性，并确保与现有 iPad 软件的一致性。
苹果的 iPad 和 iPad Pro 机型在历代产品中都保持了 4:3 的宽高比。该比例在纵向和横向模式下均能提供均衡的体验，使其特别适合阅读/浏览和分屏多任务处理。只有 8.3 英寸的 iPad mini 偏离了传统比例，而是采用了大约 3:2 的比例，因为它的尺寸略高且略窄。
数码闲聊站此前曾披露过iPhone Fold 的确切尺寸，称该设备外屏尺寸为 5.5 英寸，内屏尺寸为 7.8 英寸。著名苹果行业分析师郭明錤随后证实了该尺寸，并称内屏“无折痕”。
郭表示，该设备将采用钛合金外壳和金属玻璃铰链，并配备双镜头后置摄像头和前置摄像头，适用于折叠和展开状态。
值得注意的是，天风证券分析师郭明錤表示，这款手机将放弃 Face ID 身份验证，而是使用 Touch ID 侧键来节省宝贵的内部空间。它还将定位为“真正的人工智能手机”，更大的屏幕可以提供更好的多任务人工智能体验。
大多数人估计，iPhone Fold 在美国的售价约为 2000 至 2500 美元。彭博社记者马克·古尔曼预计，苹果首款可折叠设备将于明年某个时候上市。
Ubuntu进一步解释为何不对所有软件包进行“-O3”优化
自去年以来，Canonical 一直在研究使用 -O3 编译器优化来构建 Ubuntu 软件包，以便为 Ubuntu Linux 提供更好的性能。但几周前，他们决定不对所有软件包使用 -O3 优化。现在，他们提供了更多工程见解，以说明他们的理由以及对更多软件包使用 -O3 编译器优化的调查结果。
长话短说，对于发行版范围的 -O3 编译器优化，他们没有足够引人注目的性能优势来证明这种努力是合理的。他们还发现了一些性能倒退，并且 -O3 优化在某些情况下会对某些加载时间产生不利影响，并且会使二进制文件大小变大。
例如，他们发现 GNU Radio 的性能下降了 12%，TIFF 解压缩也倒退了近 12%，使用 -O3 优化默认值后，所有 Debian 软件包的大小增加了约 6%，桌面 ISO 的大小增加了近 4%。
在Ubuntu Discourse上，他们总结了他们的发现并得出结论：
“整个发行版的 O3 似乎并没有提供更好的性能，并且在交互任务中会倒退。它最多会影响 11.9% 的加载时间，这对努力实现快速应用程序启动的容器工作负载是不利的。总体而言，这种倒退主要是由于可执行文件大小的增加造成的。此外，在某些情况下，-O3 和链接时间优化结合在一起可能会导致过多的函数内联，进而导致性能倒退（可能是通过寄存器压力或指令缓存抖动）。
可以说，所有这些都符合传统观点：-O3 在某些情况下可以提供帮助，但不是一个合理的默认值。但验证这一点肯定比仅仅依赖民间知识要好！此外，我们仍然希望研究更多方法来提高 Ubuntu 的性能，每次我们锻炼基准测试能力时，我们都会做得更好。”
至少他们仍将探索选择性地为某些软件包启用 -O3 优化，以便获得合理的性能优势。
Ubuntu 25.04 预计将于 4 月中旬发布，并且确实带来了一些其他性能优势，同时更多的性能测试正在进行中。