Forwarded From Web to Album
Intel Begins Linux Preparations For Bartlett Lake
The first Linux patch was posted today by an Intel engineer that explicitly mentions "Bartlett Lake" in opening the door for any other Linux kernel patches explicitly catering to Bartlett Lake processors.
Intel Bartlett Lake has been rumored for embedded systems and other long-term deployments on LGA-1700. There has been rumors of a Q3-2025 debut for P-core-only Bartlett Lake processors utilizing Raptor Cove cores. Some rumors have also suggested Bartlett Lake would feature Lion Cove cores. With today's Linux kernel patch, Bartlett Lake is summed up as:
What was posted today by Intel for the Linux kernel was a simple one-liner patch acknowledging Bartlett Lake as a Raptor Cove part and using the Family 6 Model 215 (0xD7) for identification. Really a non-exciting patch besides un-blocking the door for other Bartlett Lake patches to now be published that depend upon this define being present in the kernel. This patch looks like it will go in through x86/urgent and thus come in as a "fix" for the Linux 6.15 kernel. Searching Linux Git yields no other Bartlett Lake mentions at this time.
We'll see what more Linux kernel patches come around Bartlett Lake but at least with making use of Raptor Cove and being P-core-only there is no kernel scheduler mess to worry about with P/E hybrid cores and the like. With relying on existing LGA-1700 platforms is also less to worry about when it comes to Linux support/compatibility.
Intel Bartlett Lake has been rumored for embedded systems and other long-term deployments on LGA-1700. There has been rumors of a Q3-2025 debut for P-core-only Bartlett Lake processors utilizing Raptor Cove cores. Some rumors have also suggested Bartlett Lake would feature Lion Cove cores. With today's Linux kernel patch, Bartlett Lake is summed up as:
"Bartlett Lake has a P-core only product with Raptor Cove."
What was posted today by Intel for the Linux kernel was a simple one-liner patch acknowledging Bartlett Lake as a Raptor Cove part and using the Family 6 Model 215 (0xD7) for identification. Really a non-exciting patch besides un-blocking the door for other Bartlett Lake patches to now be published that depend upon this define being present in the kernel. This patch looks like it will go in through x86/urgent and thus come in as a "fix" for the Linux 6.15 kernel. Searching Linux Git yields no other Bartlett Lake mentions at this time.
We'll see what more Linux kernel patches come around Bartlett Lake but at least with making use of Raptor Cove and being P-core-only there is no kernel scheduler mess to worry about with P/E hybrid cores and the like. With relying on existing LGA-1700 platforms is also less to worry about when it comes to Linux support/compatibility.
↩️ 小米进一步封锁了设备解锁通道：出厂 MIUI 但升级过 HyperOS 的设备，无论目前是否运行 MIUI，均需要通过社区获取解锁权限后才可在开发者选项中绑定账户。...
小米进一步封锁了设备解锁通道：出厂 MIUI 但升级过 HyperOS 的设备，无论目前是否运行 MIUI，均需要通过社区获取解锁权限后才可在开发者选项中绑定账户。这意味着，用户将无法通过请求售后降级系统的方式解锁设备。绕过社区权限绑定的漏洞也已失效。
同时，社区解锁申请资格审查内容新增：是否有与 BootLoader 解锁相关的投诉。
到底是谁还在为了解锁买小米
加人们太棒了 16g 挂了 5 个有效应用😊，开机 4h 不到，一加的内存管理真的是太🌶︎🐔了，下载最新的 scene bata 8.2.0 优化了算法防止作弊原型毕露，used...
加人们太棒了 16g 挂了 5 个有效应用😊，开机 4h 不到，一加的内存管理真的是太🌶︎🐔了，下载最新的 scene bata 8.2.0 优化了算法防止作弊原型毕露，used 最多使用到 103% 左右就开始杀后台，9.5g 都是摆设，回去开已经挂上的闲鱼再次查看 used 只剩 87%，使用第三方 hook 防杀后可以无限制压缩，但是 kswap 在 used 超过 130% 后 能随意吃满 8elite p 核导致返回桌面 or 开下一个 app 的同时进行 kswap 压缩的话动画就会掉帧卡顿，黑厂的 16g 给我用出不如别家 12g 的体验，我上一台一加 13 就是首发 买的 12g 版本，使用了 43 天就出掉就是因为保不住后台开相机乱杀，现在买了 16g 还是这样难道只有 24g 才是正常体验？所谓的普及 24g 不过是为你的🌶︎🐔内存管理找借口，24g 的价格用在你的产品就是食，现阶段 Originos，hyperos，Magicos 任何一家内存管理都远超 coloros，黑厂几年了都挂不住后台还喜欢作弊，假流畅真🤡，喜欢吹的游戏去除插帧或者没插帧不见得比 iQOO 好多少，打个王者对局日常大掉帧就是风驰的特色，日常也做的不咋地
AMD RDNA4 Paired Context Reg Feature Merged For RADV To Potentially Help Performance
After various commits to Mesa 25.1 in recent days in preparing for a new paired context registers feature of AMD RDNA4 (GFX12 graphics), the feature today is wired up for the Radeon Vulkan driver "RADV" with the upcoming Mesa 25.1 release. This feature has the possibility of helping performance for new AMD RDNA4 hardware but the performance benefits at this time aren't clear.
RADV lead developer Samuel Pitoiset of Valve's Linux graphics driver team has been working on this new performance feature with AMD RDNA4 graphics with the Radeon RX 9070 series. Pitoiset explains of it:
So the command processor (CP) is very slow on the new AMD GPUs and the paired context registers should help reduce the main bottleneck.
This merge request today landed the support for the RADV Vukan driver to use paired context regs when in an optimal state. But as brought up in the benchmarks on that merge request, in the few tests done so far there doesn't appear to be any solid benefit of this feature -- at least in its current state as wired up for RADV.
We'll see if future driver improvements make this paired context registers feature more worthwhile or not. In any event the initial enablement is now in place for Mesa 25.1 due out later this quarter.
Separately, also merged today is a fix for RDNA4 / RX 9070 series to avoid potential GPU hangs or corruption "garbage" issues after suspend and resume on Linux.
RADV lead developer Samuel Pitoiset of Valve's Linux graphics driver team has been working on this new performance feature with AMD RDNA4 graphics with the Radeon RX 9070 series. Pitoiset explains of it:
"CP is very slow on GFX12 and parsing the packet header is the main bottleneck. Using paired context regs reduce the number of packet headers and it should be more optimal.
It doesn't seem worth when only one context reg is emitted (one packet header and same number of DWORDS) or when consecutive context regs are emitted (would increase the number of DWORDS)."
So the command processor (CP) is very slow on the new AMD GPUs and the paired context registers should help reduce the main bottleneck.
This merge request today landed the support for the RADV Vukan driver to use paired context regs when in an optimal state. But as brought up in the benchmarks on that merge request, in the few tests done so far there doesn't appear to be any solid benefit of this feature -- at least in its current state as wired up for RADV.
We'll see if future driver improvements make this paired context registers feature more worthwhile or not. In any event the initial enablement is now in place for Mesa 25.1 due out later this quarter.
Separately, also merged today is a fix for RDNA4 / RX 9070 series to avoid potential GPU hangs or corruption "garbage" issues after suspend and resume on Linux.
英国高级警官呼吁禁止 16 岁以下儿童使用社交媒体
英国高级警官呼吁禁止 16 岁以下儿童使用社交媒体，称社媒推动和助长了犯罪。四名高级警官称，为了公共安全、国家安全和年轻一代的心理健康，有必要进一步控制社媒平台。Sarah Crew 称社媒平台让儿童面临被剥削和虐待的风险。她说今天的社媒平台就像 1850 年代的美国西部，快速扩张但没有监管和执法。负责反恐的 Matt Jukes 指出，去年因恐怖主义犯罪而被捕的人中有 20% 是儿童，他表示恐怖组织能通过社媒激进化年代一代。至于英国政府是否会考虑禁止儿童使用社交媒体，内政大臣 Yvette Cooper 早些时候对此表示，没有什么是不可以讨论的。
theguardian: UK police chiefs call for ban on social media for under-16s
theguardian: UK police chiefs call for ban on social media for under-16s
Linux PCACHE Proposed For Persistent Memory Cache For Block Devices
Sent out as a request for comments today is a patch series implementing PCACHE, a persistent memory cache for block devices. PCACHE was born out of code originally designed for the CXL block device driver but ultimately is useful outside the context of Compute Express Link as well.
Dongsheng Yang sent out the set of patches proposing PCACHE for the Linux kernel that is expanding the scope to any persistent memory device supporting direct access (DAX) rather than just CXL devices. The patch notes while PCACHE is a good fit for the discontinued Intel Optane product line, the Numemory NM101 storage-class memory is one product that could jive well with this proposed PCACHE.
One of the PCACHE patch messages goes on to explain:
There is also this diagram for comparing PCACHE features to the likes of BCache and the DeviceMapper write cache:
Those wanting to learn more about this PCACHE proposal can find it on the Linux kernel mailing list.
Dongsheng Yang sent out the set of patches proposing PCACHE for the Linux kernel that is expanding the scope to any persistent memory device supporting direct access (DAX) rather than just CXL devices. The patch notes while PCACHE is a good fit for the discontinued Intel Optane product line, the Numemory NM101 storage-class memory is one product that could jive well with this proposed PCACHE.
One of the PCACHE patch messages goes on to explain:
"This patch introduces the initial integration of `pcache`, a Linux kernel block layer module that leverages persistent memory (PMem) as a high-performance caching layer for traditional block devices (e.g., SSDs, HDDs).
- Persistent Memory as Cache:
- `pcache` uses DAX-enabled persistent memory (e.g., `/dev/pmemX`) to provide fast, byte-addressable, non-volatile caching for block devices.
- Supports both direct-mapped and vmap-based access depending on DAX capabilities.
- Modular Architecture:
- `cache_dev`: represents a persistent memory device used as a cache.
- `backing_dev`: represents an individual block device being cached.
- `logic_dev`: exposes a block device (`/dev/pcacheX`) to userspace, serving as the frontend interface for I/O.
- `cache`: implements core caching logic (hit/miss, writeback, GC, etc.).
Design Motivation:
`pcache` is designed to bridge the performance gap between slow-but-large storage (HDDs, SATA/NVMe SSDs) and emerging byte-addressable persistent memory. Compared to traditional block layer caching, `pcache` is persistent, low-latency, highly concurrent, and more amenable to modern storage-class memory devices than legacy caching designs.
This patch finalizes the series by wiring up the initialization entry point (`pcache_init()`), sysfs bus registration, root device handling, and Kconfig glue.
With this, the `pcache` subsystem is ready to load as a kernel module and serve as a cache engine for block I/O."
There is also this diagram for comparing PCACHE features to the likes of BCache and the DeviceMapper write cache:
Those wanting to learn more about this PCACHE proposal can find it on the Linux kernel mailing list.
Qualcomm Open-Sources The ELD Linker Embedded Linker
While LLVM LLD and Mold are two popular linkers on Linux systems with the latter being known for its impressive speed and much faster than GNU LD and Gold, this past week Qualcomm open-sourced a new linker: ELD.
ELD is a new linker open-sourced by Qualcomm focused on the needs of embedded developers. ELD is derived from mclinker and tailored for ELF files and the needs of embedded systems/developers. ELD can pair nicely with LLVM-based toolchains.
Qualcomm's ELD only targets AArch32, AArch64, the Qualcomm Hexagon NPU, and RISC-V architectures with x86/x86_64 being out of scope.
Those wanting to learn more about the ELD linker can do so via the Qualcomm blog and the code is under a BSD 3-clause license on GitHub.
ELD is a new linker open-sourced by Qualcomm focused on the needs of embedded developers. ELD is derived from mclinker and tailored for ELF files and the needs of embedded systems/developers. ELD can pair nicely with LLVM-based toolchains.
Qualcomm's ELD only targets AArch32, AArch64, the Qualcomm Hexagon NPU, and RISC-V architectures with x86/x86_64 being out of scope.
Those wanting to learn more about the ELD linker can do so via the Qualcomm blog and the code is under a BSD 3-clause license on GitHub.
[讨论]黄金只玩雾子小锤能上分吗？
目前坐标黄4，双排奶，对面双狗我小锤，正常雾子
队友固定安娜，奶不住他会掏莫伊拉，我雾子主奶
思路跟理解略有，知道侧面跟单c拉枪线，雾子能爬就爬高台，镖人抽奖，打打收割在Tp返场
目前赢一输一打的有点自闭
玩下来感觉只能保下限，赢的局很看T发挥，c混点没事
玩雾子平时不敢镖人，遇到队友没有掩体意识基本都化身摩西死命奶保人，小锤平时容易激情做事拿人头送，但基本死两次就开龟保人。
玩双奶上分原因，一方面枪马玩c很菜，另一方面他单排奶玩安娜受罪，我俩沟通起来起码在奶位能做到不送、互保、奶量兜底。
队友固定安娜，奶不住他会掏莫伊拉，我雾子主奶
思路跟理解略有，知道侧面跟单c拉枪线，雾子能爬就爬高台，镖人抽奖，打打收割在Tp返场
目前赢一输一打的有点自闭
玩下来感觉只能保下限，赢的局很看T发挥，c混点没事
玩雾子平时不敢镖人，遇到队友没有掩体意识基本都化身摩西死命奶保人，小锤平时容易激情做事拿人头送，但基本死两次就开龟保人。
玩双奶上分原因，一方面枪马玩c很菜，另一方面他单排奶玩安娜受罪，我俩沟通起来起码在奶位能做到不送、互保、奶量兜底。
2022 年全球逾 300 万儿童死于抗生素耐药性感染
根据 ESCMID Global 2025 上发表的一项研究，2022 年全球逾 300 万儿童死于抗生素耐药性感染。抗生素耐药性正日益成为全世界面临的一大公共卫生风险。抗生素用于治疗或预防各种细菌感染，但由于过度使用和不当使用，部分细菌对抗生素产生了耐药性，而新抗生素发现和生产的速度则要慢得多。研究人员报告，在 2022 年东南亚有逾 75.2 万名儿童、非洲有 65.9 万名儿童，世界其他地区有逾 150 万名儿童死于抗菌药物耐药性相关并发症。许多死亡与使用“观察类”抗生素（耐药风险高的药物或 watch antibiotics）和储备抗生素（用于治疗严重耐多药感染的最后手段 或 reserve antibiotics）有关。2019-2021年间，东南亚和非洲的“观察类”抗生素使用量分别增长了 160% 和 126%。东南亚和非洲的“储备类”抗生素使用量同期分别增长了 45% 和 125%。
clintonhealthaccess：Over 3 million children died from AMR-related infections in 2022, major study shows
clintonhealthaccess：Over 3 million children died from AMR-related infections in 2022, major study shows