Ollama现已支持AMD显卡（预览版）

核心公告

Ollama 于2024年3月14日宣布，在Windows和Linux平台上以预览版形式提供对AMD显卡的支持。这意味着在Linux和Windows系统上，AMD显卡现在可以加速Ollama的所有功能。

支持的显卡详情

支持范围涵盖多个AMD显卡和加速器家族，具体如下：

• AMD Radeon RX系列：

  • 7000系列：7900 XTX, 7900 XT, 7900 GRE, 7800 XT, 7700 XT, 7600 XT, 7600
  • 6000系列：6950 XT, 6900 XTX, 6900 XT, 6800 XT, 6800
  • Vega系列：Vega 64, Vega 56

• AMD Radeon PRO系列：

  • W7000系列：W7900, W7800, W7700, W7600, W7500
  • W6000系列：W6900X, W6800X Duo, W6800X, W6800
  • V系列：V620, V420, V340, V320
  • Vega系列：Vega II Duo, Vega II, VII SSG

• AMD Instinct系列：

  • MI300系列：MI300X, MI300A, MI300
  • MI200系列：MI250X, MI250, MI210, MI200
  • 早期型号：MI100, MI60, MI50

官方表示，更多AMD显卡型号的支持即将到来。

如何开始使用

用户可以通过下载适用于Linux或Windows的Ollama版本，来体验对AMD显卡的支持。

使用Google Project Zero工具对Ladybird进行模糊测试

工具与过程
作者使用Google Project Zero的Domato（一个DOM模糊测试器）对Ladybird浏览器进行压力测试。Domato会生成约500 KiB的随机网页，包含大量非常规但基本有效的HTML、CSS和JavaScript代码。作者在Ladybird的调试版本中加载这些页面，并观察错误。

发现的问题与修复
测试迅速暴露出多个漏洞，以下是主要案例：

1. 空指针解引用

   • 问题：<th>元素通过JavaScript插入到<mfrac>中，导致假设每个表格单元格都有<table>祖先的代码崩溃。
   • 原因：HTML解析器禁止这种结构，但JavaScript API可绕过规则。
   • 修复：将查找表格祖先的函数替换为first_ancestor_of_type<HTMLTableElement>()，并处理空值。

2. 无窗口文档的事件处理

   • 问题：对DOMParser创建的文档（无窗口对象）设置body.onblur时崩溃。
   • 原因：代码假设所有文档都有窗口对象，但DOMParser创建的文档没有。
   • 修复：让Document::window()返回可空值，并在相关事件处理中忽略无窗口情况。

3. SVG渐变自引用循环

   • 问题：SVG渐变引用自身导致无限循环。
   • 原因：未处理渐变引用链中的循环。
   • 修复：跟踪已访问的渐变，遇到重复时停止遍历。

4. iframe移除后的属性访问

   • 问题：移除iframe后访问其contentWindow的getSelection()时崩溃。
   • 原因：HTML规范错误假设属性访问时窗口始终有关联的浏览上下文。
   • 修复：添加空检查，并已向HTML规范提交问题报告。

5. DOMbefore()方法中的无限循环

   • 问题：使用before()移动元素时导致100% CPU占用。
   • 原因：兄弟节点遍历逻辑错误，不断获取同一前一个兄弟。
   • 修复：正确遍历兄弟节点链。

结论
模糊测试在极短时间内发现了五个实际漏洞（包括一个规范错误），并全部修复。这突显了模糊测试在提升软件健壮性方面的价值。作者计划未来对Ladybird进行持续自动化模糊测试，以进一步发现问题。

2024年2月，由域名注册商Freenom运营的顶级域名（.tk、.cf和.gq）大规模停止解析，导致约1260万个网站消失。这直接影响了Cloudflare，因为这些域名此前占其托管域名总数的23.1%。

关停事件的背景是Freenom因忽略滥用投诉被Meta起诉，随后于2023年3月暂停新域名注册，并于2024年2月12日正式宣布退出域名业务。关停效果在2月8日至10日就已显现，早于官方公告，令许多用户措手不及。

对Cloudflare而言，.tk、.cf和.gq域名数量减少了99.8%，使其托管的域名总量整体下降了22%。其中，.tk域名原本占比最高（16.2%），但顶级网站中使用极少。多数免费注册的域名突然失效，部分用户通过将域名标记为“付费域名”得以恢复。

一个积极影响是，由于这些免费域名常被用于网络犯罪，关停后相关顶级域名的恶意URL数量下降了86.9%。

摘要

美国联邦贸易委员会（FTC）和司法部（DOJ）反垄断部门联合向美国版权局提交意见，要求豁免商用软冰淇淋机等设备免受《数字千年版权法》（DMCA）第1201条反规避规则的限制。该行动旨在解决许多设备因设计或缺乏零件、手册、专业工具而难以维修的问题，冰淇淋机作为典型例子，经常故障且维修被锁定以进行高利润服务。

FTC和DOJ指出，豁免范围还包括专有诊断套件、可编程逻辑控制器和企业IT设备。他们认为，豁免将为用户提供更多第三方和自我维修的选择，导致成本节约、更好的投资回报，并促进维修市场的竞争，防止公司利用DMCA法律强制垄断维修。

此联合意见建立在维修供应商iFixit和利益集团Public Knowledge先前请愿的基础上，该请愿主张广泛改革，并以麦当劳软冰淇淋机为例。麦当劳使用的Taylor C709商用软冰淇淋机经常故障，需要复杂的预热和清洁周期，产生晦涩的错误代码，且维修成本高昂（每15分钟服务收费350美元）。iFixit拆解该机器后，确认了其从启动到制作冰淇淋过程的冗长和复杂性，突显了维修障碍。

经济型轮式可刷新盲文显示器项目笔记

项目背景

• 全球约4000万盲人，多数在发展中国家，但即使发达国家盲文显示器获取也困难。
• 现有设备昂贵（最便宜40点8点显示器约700美元）、脆弱且难获取。
• 目标：开发一种价格实惠、易于制造的盲文显示器，利用经济规模降低单价。

核心挑战

• 盲文机械规格严格：点径1.6mm，点距2.5mm，单元宽7.6mm，行高10mm。
• 微型致动器空间和精度要求极高，导致现有设备成本高。
• 需集成电子、机械、电磁和软件，项目复杂且耗时。

关键设计探索与演进

1. 初始概念与现有设计分析

• Mahmoud的轮式设计：使用八面轮，每轮8个代码。优点：空间利用巧妙、垂直轮方向防误触。缺点：传动复杂昂贵（需蜗轮蜗杆）、制造精度高、脆弱难维护。
• 市场现状：设备价格范围（每单元$7-$100），Orbit Reader 20约$699，高端设备超$3500。缺乏大尺寸可负担显示屏。

2. 核心突破：轮式显示方案

• 轮上直接显示点阵：轮子侧面带凸起（代表盲文点），旋转至不同角度显示不同点组合。
• 多图案优化：每个轮可包含3个重复图案（每个图案对应2-3点组合），减少旋转角度（最大120°）。
• 尺寸合规：点径1.5mm，点距2.3mm（符合标准宽松下限），单元宽7.6mm。

3. 驱动方案迭代（复杂过程）

• 尝试多种致动器：
  • 笔式点击机构（便宜但噪音大、寿命短）。
  • 里程表式凸轮驱动（零件多、精度要求高）。
  • 音圈、压电、蜡基致动器等。
• 电磁驱动突破：
  • 三相步进驱动：每个轮集成22个微型永磁体（2×1mm），三组线圈（相位差120°）驱动。
  • 优势：低电压（3V）启动，高速（可达1000步/秒），扭矩足够，安静。
  • 挑战：磁体间距小（仅5mm），需精确避免相邻单元干扰。
• 定子优化：
  • 从外置线圈改为内置于轮内，使用定制钢制叠片定子，最大化磁场耦合。
  • 设计可量产制造的定子结构（冲压弯曲成型）。

4. 最终可行原型

• 规格：轮直径46mm（高于理想，但符合Orbit Slate 520标准），总高64mm。
• 物料成本估算：
  • 轴承、塑料件、磁体（批量价可低至$0.02/个）、铜线、钢材，合计约**$2**。
  • 电子与组装预算$3，目标每单元≤$5。
• 性能：显示清晰、定位准确、噪音低、扭矩适中。

设计原则与约束

• 必须保证：安全性（无夹伤风险）、点阵质量（等高、等距、不晃动）、字符宽度合规、低噪音、支持标准软件。
• 可妥协：更新速度（目标0.5Hz）、尺寸、重量、功耗、成本（初期允许较高）。
• 理想特性：长寿命、低功耗（USB-C供电）、易维修（无需工具）、防水防尘。

项目进展与下一步

• 已验证：轮式显示概念可行，三相电磁驱动方案成功。
• 剩余工作：
  • 工程优化：缩小轮径、减少高度、提升耐久性、降低功耗。
  • 解决相邻单元磁干扰（可能需要磁屏蔽或协调驱动）。
  • 开发低成本量产工艺（注塑、冲压、自动组装）。
  • 软件支持与用户测试。
• 后续方向：探索更小的3点轮并行方案、矩阵式显示等替代方案。

技术亮点

• 创新轮设计：带图案的旋转轮直接作为显示和编码机构。
• 集成驱动：将步进电机（永磁体+线圈）直接集成到轮子，简化传动。
• 制造导向：设计兼顾原型测试与量产可行性（如可冲压定子、注塑轮体）。

该项目证明了通过创造性机械设计和电磁驱动集成，可以显著降低盲文显示器成本，为普及助盲设备提供可行路径。

仓库目的：
以教学为目的，提供一个约100行CUDA代码的Flash Attention最小化实现，帮助CUDA初学者理解其核心原理。

实现特点：

• 前向传播代码量小（约100行），变量命名遵循原论文符号。
• 通过使用共享内存避免大规模N²读写。
• 线程分配方式与原版不同（每线程对应输出矩阵一行），简化实现但降低了矩阵乘法速度。

使用要求：

• 需安装PyTorch（支持CUDA）和Ninja（用于C++加载）。

基准测试结果：
在T4 GPU上测试，相较于手动注意力实现，该最小化实现的CUDA时间从52.545ms降至3.908ms，取得显著加速。

主要限制：

• 未实现反向传播（前向传播已足够展示共享内存的使用）。
• 线程分配简化导致矩阵乘法较慢，长序列/大块尺寸时性能可能下降。
• 使用float32（原版为float16）。
• 块大小固定为32（编译时设定）。

待办事项：

• 添加反向传播。
• 优化矩阵乘法速度（可参考tensorcore分支）。
• 实现动态块大小设置。

美国首个大型海上风电场正式启用，更多项目即将展开

美国首个商业规模的海上风电场South Fork Wind已正式投入运营。该项目由丹麦能源开发商Ørsted和美国公用事业公司Eversource建设，位于纽约蒙托克角以东约35英里（56公里）处，包含12台涡轮机，可产生132兆瓦的清洁电力，为超过7万户家庭供电。纽约州州长凯西·霍楚尔与内政部长德布·哈兰德共同出席启用仪式，标志着美国海上风电发展进入新阶段。

项目意义与后续规划

• 行业里程碑：South Fork Wind是美国首个通过竞争性招标建设的商业规模海上风电场，相较于2016年罗德岛附近仅5台涡轮机的试点项目，其规模显著扩大，证明了大型海上风电场在美国的可行性。
• 政策支持：拜登政府已批准6个商业规模海上风电项目，并在太平洋和墨西哥湾海岸首次拍卖风电租赁区域。纽约州近期又选出两个新项目，计划为超过100万户家庭供电。
• 后续项目：
  • Revolution Wind：将成为罗德岛和康涅狄格州的首个商业规模海上风电场，预计明年供电超过35万户家庭。
  • Sunrise Wind：纽约州计划与Ørsted合作建设更大规模项目，可为60万户家庭供电。
  • Empire Wind 1：由Equinor负责，计划为50多万户纽约家庭供电。
  • 这些项目均目标在2026年前投入运营。

行业现状与挑战

• 历史进程：美国首个海上风电项目本应是马萨诸塞州的Cape Wind，但因地方反对和诉讼于2001年提出后失败。试点项目Block Island Wind Farm于2016年启动，但规模有限。
• 近期挑战：2023年，由于通货膨胀、供应链中断及资本成本上升，Ørsted等开发商取消了东北部部分项目，认为其财务可行性不足。
• 2024年展望：随着利率下降和各州气候目标推动，行业预计2024年将更具行动力。马萨诸塞州的Vineyard Wind预计今年晚些时候全面投入运营，62台涡轮机将为40万户家庭和企业供电。

政府目标与行业转型

• 内政部长哈兰德强调，美国清洁能源转型“正在此时此地发生”。
• 拜登政府目标到2030年实现海上风电为1000万户家庭供电。
• Ørsted（前身为丹麦石油天然气公司DONG Energy）自2008年起专注于海上风电开发，现已发展为全球最大风电开发商之一，其战略转型体现了行业向清洁能源的转变。

South Fork Wind的启用被视为美国应对气候变化和推动碳中和电力系统建设的关键一步，为后续大规模海上风电开发奠定了基础。

Pretzel 是一个基于 Jupyter 的开源项目，旨在通过集成 AI 功能增强数据探索和编码体验。其核心目标是在浏览器内实现本地数据操作，结合了 DuckDB-WASM 和 PRQL 等技术。以下是其主要内容的概述：

项目定位与核心特性

• 基于 Jupyter 的增强版本：作为 Jupyter 的分支，保留了原有配置、扩展的兼容性，实现无缝迁移。
• AI 驱动功能：支持内联代码补全、AI 代码生成与编辑、侧边栏聊天及错误修复。
• 交互模式：在单元格中输入即可触发自动补全；通过快捷键（如 Cmd+K）呼出 AI 提示框；使用 @ 符号引用会话中的变量和数据框。

安装与使用

• 快速安装：通过 pip install pretzelai 安装，运行 pretzel lab 启动界面，也可使用免费托管版本（pretzelai.app）。
• Docker 支持：提供 Dockerfile 配置，便于容器化部署，支持本地目录映射。
• 错误处理：针对依赖安装问题（如 PyStemmer），提供了各操作系统（Windows、Ubuntu、macOS）的构建工具安装指南。

AI 功能详解

• 内联补全：使用 Mistral 的 Codestral 模型，响应速度快；支持通过设置切换不同模型（如 GPT-4o）。
• 代码生成与编辑：AI 可基于自然语言指令生成新代码或修改现有代码；支持选择部分代码进行定向编辑。
• AI 侧边栏：通过快捷键激活，可用于提问、生成代码或搜索现有代码，并自动将当前单元格代码作为上下文。
• 错误修复：遇到错误时，可直接点击按钮尝试 AI 修复。

配置与自定义

• 开箱即用：无需配置即可使用默认 AI 模型，且不存储用户代码或数据。
• 模型配置：支持切换不同 AI 服务（如 OpenAI、Anthropic、本地模型），需在设置中配置 API 密钥或端点。
• 推荐模型：建议使用 GPT-4 级别模型（如 GPT-4 Turbo、Claude-3.5 Sonnet）以获得最佳性能。

隐私与数据政策

• 数据收集：仅收集匿名使用事件（如“Ask AI”的点击），不收集用户代码；托管版本基于邮箱创建账户，30 天未登录自动删除数据。
• 提示词遥测：默认收集用户提示词以改进体验，可在设置中关闭。

常见问题与规划

• 路线图：计划增加实时协作、SQL 支持、可视化构建器、仪表板创建等功能。
• 许可证：采用 AGPLv3 许可证，允许免费使用和修改，但要求衍生作品同样开源；若仅内部使用则不受限制。
• 商业模式：计划通过托管企业版（含数据权限控制、团队协作等功能）盈利，个人版本永久免费。

其他说明

• 项目早期曾探索基于浏览器的可视化数据操作工具，现版本以 AI 增强编码为主。
• 反馈与问题可通过 GitHub Issues 或邮箱提交。

Pretzel 通过融合 Jupyter 的成熟生态与 AI 技术，降低了数据工具的切换成本，同时强调隐私保护和本地化处理，适用于个人及企业场景。

文章标题：计算机科学中什么成功了：1999年 vs. 2015年

本文基于Butler Lampson在1999年关于“计算机系统研究”的演讲，对比评估了在1999年被视为“成功”、“可能成功”或“不成功”的各项技术，在2015年的实际发展状况。评估标准侧重于技术是否被绝大多数程序员广泛采用并产生实际影响。

1999年“成功”的技术在2015年依然成功：

• 虚拟内存、地址空间、分组网络、对象/子类型、RDB与SQL、事务、位图与GUI、万维网、算法：这些在1999年被列为“成功”的技术，到2015年仍然是现代计算机系统的基石。

原为“可能成功”或“不成功”类别的演变：

1. 并行性：从“可能”到“可能”。

   • 尽管芯片暴露了大量并行性，且并发处理变得更容易，但要充分利用硬件性能仍然极其困难。Lampson曾指出，锁和条件变量这些机制被证明程序员难以有效利用。尽管有硬件支持（如Intel的协同调度），其大规模应用仍不普遍。

2. RISC：从“可能”到“不”。

   • 1980-90年代，RISC（如PowerPC、Alpha）曾被视为x86的有力竞争者。然而，Intel在1995年发布的Pentium Pro凭借强大性能摧毁了RISC在消费级市场的可行性。如今，x86主导工作站和超算市场，而其他RISC ISA（如MIPS、ARM）主要在低利润的嵌入式市场（如网络设备）生存，这部分是因为Intel不愿进入该低利润率领域。RISC的成功更多体现在商业策略（指令集套利）而非技术优势。

3. 垃圾回收：从“可能”到“是”。

   • 自1999年以来，所有成功的主流语言（如Java, Python, Ruby, Go等）都内置了垃圾回收机制。尽管Rust等语言提供了替代方案，但垃圾回收无疑已成为内存管理的主流选择。

4. 复用：从“可能”到“是”。

   • 面向服务的架构（SOA）及类似模式已成为广泛接受的复用方式。

5. 能力安全：从“不”到“是”。

   • 能力安全模型在移动操作系统（如Android、iOS的权限模型）中得到广泛应用。

6. 花哨的类型系统：从“不”到“不”。

   • 以Scala或Haskell为标准，高级类型系统仍未进入主流。主流趋势是采用动态语言或类型系统“不那么花哨”的语言（如Go）。

7. 函数式编程：从“不”到“可能”。

   • 纯函数式语言本身仍属小众，但其核心思想（如不可变性）已被广泛吸收并融入主流编程实践中。

8. 形式化方法：从“不”到“可能”。

   • 在芯片设计（模型检测）和特定工具（如驱动验证、静态分析）中影响巨大，但对绝大多数开发者而言仍属小众技术。

9. 软件工程：从“不”到“不”。

   • 学术研究与工业实践之间仍存在巨大鸿沟，二者缺乏有效交流。

10. 远程过程调用：从“不”到“是”。

    • RPC已变得极为普遍，甚至出现了关于其滥用的批评。

11. 分布式计算：从“不”到“是”。

    • 云服务（如AWS、Azure）使得分布式系统无处不在，即使是缺乏专业知识的初创公司也能可靠使用。

12. 安全：从“不”到“可能”。

    • 尽管产生了高影响力的研究成果，但安全仍未成为大多数程序员的首要关注点。

总结：

• 1999年所有“成功”的技术在2015年依然成功。
• 在“可能成功”和“不成功”的类别中，有七项获得了升级（向更积极的方向转变），仅有一项（RISC）被降级。
• 许多在1999年未被考虑的技术（如神经网络）已成为明确的成功范例。
• 文章最后指出，预测哪些技术将在未来三十年变得有价值是极其困难的，对那些目前影响有限但具有潜力的研究领域应保持乐观。

摘要： 随着公众对隐私和监控威胁意识的提升，VPN在过去十年中稳步增长。为此，一些政府试图通过利用“双用途”深度包检测技术识别VPN连接来限制访问。为探究VPN被封锁的可能性，本研究开发了针对最流行商业VPN协议OpenVPN的精确连接指纹识别机制。研究基于协议特征（如字节模式、数据包大小和服务器响应）识别出三种指纹。通过模拟控制网络的攻击者角色，研究设计了一个分两阶段进行的框架，依次执行被动指纹识别和主动探测。

研究与一家拥有百万用户的ISP合作进行评估，发现该框架能以极低的误报率识别超过85%的OpenVPN流量，表明基于OpenVPN的服务可以被有效封锁且不会造成严重的附带损害。尽管部分商业VPN采取了规避检测的反制措施，但该框架仍成功识别了41种“混淆”VPN配置中的34种。

文章讨论了VPN可被指纹识别对不同威胁模型的影响，并提出了短期防御措施。从长远来看，研究敦促商业VPN提供商更透明地说明其混淆方法，并采用更原则性的检测对抗措施，例如在审查规避研究中已开发的技术。

macOS 14.4 更新引入了导致 Java 虚拟机（JVM）进程意外终止的问题，影响从 Java 8 到 JDK 22 早期访问版本的所有 Java 版本。该问题最初未在 macOS 14.4 的早期版本中出现，直到正式版发布后才被发现。目前没有可用的解决方法，且由于难以回退 macOS 更新，受影响的用户可能需要依赖此前的系统备份才能恢复稳定配置。

问题根源在于 Apple Silicon（M1、M2、M3）处理器对动态生成代码的内存保护机制。正常情况下，JVM 在即时编译（JIT）和执行过程中可能会访问受保护的内存区域，系统会通过发送 SIGBUS 或 SIGSEGV 信号通知进程，进程可处理这些信号并继续运行。然而，macOS 14.4 将这一行为改变为：当线程处于写入模式时，若尝试访问受保护内存，系统将发送不可处理的 SIGKILL 信号，导致进程被强制终止。

JVM 依赖此信号机制来保障正确性（例如处理内存映射文件截断）和提升性能，因此 macOS 14.4 的变更会直接导致 Java 应用终止，而非继续处理异常。使用 GraalVM Native Image 提前编译的应用应不受影响，但构建新镜像的能力可能受损。

Oracle 已通知客户、Apple 及 OpenJDK 合作伙伴，并建议基于 ARM 的 Apple 设备用户跳过 macOS 14.4，直接升级至已修复此问题的 macOS 14.4.1。该问题的追踪编号为 JDK-8327860（可在 bugs.java.com 查看）。

版权声明与网站信息：

• 内容受Anubis保护，由Techaro提供。
• 制作地点为加拿大（🇨🇦）。
• 吉祥物设计由CELPHASE负责。
• 网站运行Anubis版本v1.25.0-56-ga08b0f4。

文章摘要：芯片功耗成本攀升

功耗已成为芯片设计与系统开发的核心挑战。随着晶体管密度持续增加，其产生的热量已超过传统散热能力，导致热管理问题日益严峻且相互交织，影响覆盖整个产业链（包括EDA公司、设备商、晶圆厂、封装厂等）。

问题根源与演进

• 工艺节点持续微缩（如FinFET在3nm面临挑战，GAA FET引入，未来CFET出现）使设计、测量与测试更复杂昂贵。
• 漏电功耗问题反复出现，晶体管密度提升推高总功耗，导致温度上升、性能受限，形成“热-功耗”恶性循环。
• 瞬态热梯度在先进工艺中变得不可预测，引发材料应力、翘曲、电迁移、介电层击穿（TDDB）等可靠性问题。

多维度影响

1. 性能与可靠性：高温加速器件老化，影响存储器速度、信号完整性，并缩短芯片寿命。
2. 系统级挑战：2.5D/3D-IC封装中热叠加可能形成全局热点，导致结构应力与连接失效。
3. 噪声与干扰：低电压下噪声问题凸显，数字模拟混合设计中尤其敏感。
4. 经济与环境：数据中心功耗剧增带来成本与环境压力，延长设备寿命成为关键目标。

应对策略与方案

• 协同优化：强调硬件-软件协同设计，通过优化预取、减少数据移动、调整算法降低功耗。
• 技术改进：
  • 背面供电技术简化供电网络，减少电阻损耗。
  • 采用新材料与热通路设计（如铜导线、优化TSV布局）改善散热。
  • 在芯片内嵌入传感器实时监测电压、温度与老化。
• 设计方法：
  • 避免过度设计，严格评估功能必要性以控制PPA（性能、功耗、面积）。
  • 运行真实负载进行功耗分析，提前预测行为变化。
  • 采用热-机械协同仿真，早期识别风险。

结论
功耗问题已从高端芯片扩展至汽车电子等多领域，与架构、布局、信号完整性、可靠性等深度耦合。随着chiplet与3D-IC发展，全行业需协同应对功耗挑战，推动创新解决方案落地。