Forwarded from 科技圈🎗在花频道📮
Cloudflare 宣布向所有用户开放企业级功能
Cloudflare 宣布将在未来一年内向所有客户开放几乎所有功能，无需企业账户即可购买使用。该公司表示将取消"企业专属"功能概念，让任何规模的团队都能使用最先进的配置选项。
首个开放功能是仪表板单点登录（SSO），现已向所有计划用户免费提供。Cloudflare 还新增 GitHub 社交登录支持，并承诺未来所有新功能都将遵循这一开放模式，无需销售团队介入即可自助购买。
Cloudflare 官方博客
🍀在花频道 🍵茶馆 📮投稿
Cloudflare 宣布将在未来一年内向所有客户开放几乎所有功能，无需企业账户即可购买使用。该公司表示将取消"企业专属"功能概念，让任何规模的团队都能使用最先进的配置选项。
首个开放功能是仪表板单点登录（SSO），现已向所有计划用户免费提供。Cloudflare 还新增 GitHub 社交登录支持，并承诺未来所有新功能都将遵循这一开放模式，无需销售团队介入即可自助购买。
Cloudflare 官方博客
🍀在花频道 🍵茶馆 📮投稿
Forwarded from Manjusaka 的碎碎念（以及摇曳露营 S4 制作确定！）
简单复盘一下 AWS 这次事件作为一个 AIGC Startup SRE 的一些操作吧，希望能帮到大家
从入职开始发现我们主要的集群在 USE1 之后，我就开始做一些准备了。
我主要做的事情有这几件事
1. 将我们核心的几个数据库做了多地的备份，形成了 USE1，Tokyo，SG 三地备份。这样在极端情况下，我们损失一部分数据，但是也能保证服务的继续
2. 将我们 SG 的测试集群从原本的 EC2 自己简单搭的 K3S，重构为了一个标准的 AWS EKS 集群。这样可以在灾害时刻快速 warmup 一个集群，复用 AWS 已有组件。将 manifest 变更的代价降至最小
3. 简单梳理了一个 SOP，包含用户公告，DNS 切换，封版等事宜
回到今天，我大概在 AWS 事故发生后的10min，发现了我们容器中有新的 Pod 无法 setup。
在和 AWS 支持确认是 USE1 的问题后，我意识到 ECR 的事件必然关联其余事件，于是我就果断按照我自己规划的 Tier1 等级事件开始处理（对于 SRE 来说，这种事情宁可错，但是不能错过）
T+0 min，我发布了全员公告，开始进入紧急模式。我 setup 了一个全员公开会议。所有人员可以随时加入
T+2 min，我确认事件如我所预期的一样，在逐渐扩大，我发出了两个指令，1. 全线禁止任何代码合入/提交（主要是避免新创建资源会导致 Pod rotate 进而影响流量），2. 请运营同学准备公告
T+3 min, 我开始按照 SOP，开始进行数据库在 SG 区域的恢复，并且级联创建诸如 OpenSearch / Redis 等在内的依赖
T+5 min，我们开始正式的确认上下游依赖的具体问题，确认一个新上线的核心服务受到影响
T+10min，我们停服公告和其余服务的受影响公告发出
T+10min，我请另外两位同时协助 setup 新的 ECR 以及清理测试环境已有资源，并同步 CTO ，在极端情况下，我们可能会存在保体验，丢数据的决策。
T+15min， 我们最终确认目前已创建的资源以及流量入方向不会受到太大影响。切换方案挂起，但是我们继续准备相关资源
T+30min，我们第一个数据库恢复完毕
T+40min，我们第二个数据库恢复完毕
T+1h，我们所有关联的核心 infra，RDS/ES/Redis 都 stand by，并且按照生产架构设置主从等优化选项。同时我们也开始正在新的集群启动新的服务
所幸，最终 AWS 的 crash 没有影响我们全部服务。我们无须面对切换流量后复杂的数据修复工作
大概 T+2h 到 T+3h 后，我正式通报全员，紧急状态解除。为保险起见，今晚依旧对 feature 封版。
回顾整个事故，我还可以做的更多
1. 将我之前为自己准备的极端 case SOP，对全员公开。这样确保我即便不在线，也有人能接替我
2. 我们可以做一些提前的预先演练
3. 指令下达可以更果断一些
差不多就是这样，一点分享，希望能帮到大家
从入职开始发现我们主要的集群在 USE1 之后，我就开始做一些准备了。
我主要做的事情有这几件事
1. 将我们核心的几个数据库做了多地的备份，形成了 USE1，Tokyo，SG 三地备份。这样在极端情况下，我们损失一部分数据，但是也能保证服务的继续
2. 将我们 SG 的测试集群从原本的 EC2 自己简单搭的 K3S，重构为了一个标准的 AWS EKS 集群。这样可以在灾害时刻快速 warmup 一个集群，复用 AWS 已有组件。将 manifest 变更的代价降至最小
3. 简单梳理了一个 SOP，包含用户公告，DNS 切换，封版等事宜
回到今天，我大概在 AWS 事故发生后的10min，发现了我们容器中有新的 Pod 无法 setup。
在和 AWS 支持确认是 USE1 的问题后，我意识到 ECR 的事件必然关联其余事件，于是我就果断按照我自己规划的 Tier1 等级事件开始处理（对于 SRE 来说，这种事情宁可错，但是不能错过）
T+0 min，我发布了全员公告，开始进入紧急模式。我 setup 了一个全员公开会议。所有人员可以随时加入
T+2 min，我确认事件如我所预期的一样，在逐渐扩大，我发出了两个指令，1. 全线禁止任何代码合入/提交（主要是避免新创建资源会导致 Pod rotate 进而影响流量），2. 请运营同学准备公告
T+3 min, 我开始按照 SOP，开始进行数据库在 SG 区域的恢复，并且级联创建诸如 OpenSearch / Redis 等在内的依赖
T+5 min，我们开始正式的确认上下游依赖的具体问题，确认一个新上线的核心服务受到影响
T+10min，我们停服公告和其余服务的受影响公告发出
T+10min，我请另外两位同时协助 setup 新的 ECR 以及清理测试环境已有资源，并同步 CTO ，在极端情况下，我们可能会存在保体验，丢数据的决策。
T+15min， 我们最终确认目前已创建的资源以及流量入方向不会受到太大影响。切换方案挂起，但是我们继续准备相关资源
T+30min，我们第一个数据库恢复完毕
T+40min，我们第二个数据库恢复完毕
T+1h，我们所有关联的核心 infra，RDS/ES/Redis 都 stand by，并且按照生产架构设置主从等优化选项。同时我们也开始正在新的集群启动新的服务
所幸，最终 AWS 的 crash 没有影响我们全部服务。我们无须面对切换流量后复杂的数据修复工作
大概 T+2h 到 T+3h 后，我正式通报全员，紧急状态解除。为保险起见，今晚依旧对 feature 封版。
回顾整个事故，我还可以做的更多
1. 将我之前为自己准备的极端 case SOP，对全员公开。这样确保我即便不在线，也有人能接替我
2. 我们可以做一些提前的预先演练
3. 指令下达可以更果断一些
差不多就是这样，一点分享，希望能帮到大家
👍2❤1
Forwarded from 科技圈🎗在花频道📮
TinyCorp 成功让 MacBook 通过 USB4 运行 Nvidia GPU
AI 初创公司 TinyCorp 成功开发出驱动程序，让 Nvidia RTX 30、40、50 系列显卡能够通过外置 GPU 扩展坞在 ARM 架构的 MacBook 上运行。该公司在 X 平台展示了 MacBook Pro M3 Max 通过 USB4 连接 ADT-UT3G 扩展坞运行 RTX GPU 的演示。
不过这些驱动程序专为 AI 开发设计，不支持显示输出功能。对于 AI 开发者来说，这项技术能让他们在 MacBook 上运行本地大语言模型和其他 AI 模型，性能远超苹果 M 系列 GPU。TinyCorp 此前已成功让 AMD 显卡在苹果芯片 MacBook 上运行，现在将这一技术扩展到了 Nvidia GPU。
Tom's Hardware
🍀在花频道 🍵茶馆 📮投稿
AI 初创公司 TinyCorp 成功开发出驱动程序，让 Nvidia RTX 30、40、50 系列显卡能够通过外置 GPU 扩展坞在 ARM 架构的 MacBook 上运行。该公司在 X 平台展示了 MacBook Pro M3 Max 通过 USB4 连接 ADT-UT3G 扩展坞运行 RTX GPU 的演示。
不过这些驱动程序专为 AI 开发设计，不支持显示输出功能。对于 AI 开发者来说，这项技术能让他们在 MacBook 上运行本地大语言模型和其他 AI 模型，性能远超苹果 M 系列 GPU。TinyCorp 此前已成功让 AMD 显卡在苹果芯片 MacBook 上运行，现在将这一技术扩展到了 Nvidia GPU。
Tom's Hardware
🍀在花频道 🍵茶馆 📮投稿
Forwarded from 阿卡琳 🦀
不要小看“玩具项目”。
在企业级项目中，由于历史包袱、技术债务、组织层级和上下游协作关系等因素，开发过程往往充满妥协。架构设计需要兼容旧系统，技术选型受到预算和交付周期的约束，甚至连功能优先级都可能被业务方反复拉扯。最终的成果也许稳定、成熟、可扩展，但往往早已偏离最初的理想，只是一个“在现实中能活下来的产物”。
而玩具项目恰恰相反。它的价值不在于规模，而在于纯粹。你是唯一的决策者，可以自由地尝试最新的技术栈、探索更优雅的架构、实践理想化的工程哲学。没有历史负担，没有审批流程，没有妥协的必要。这样的环境，才能让你在不受干扰的状态下追求“正确”的设计，构建出真正体现个人技术理念的作品。
玩具项目也许没有用户，但它可以让你保持技术的前沿感，验证新思路，积累经验。很多伟大的框架、工具和公司，最初都源自开发者的“玩具项目”。所以，不要低估它的意义——它不仅是实验场，更是技术成长的温床。
在企业级项目中，由于历史包袱、技术债务、组织层级和上下游协作关系等因素，开发过程往往充满妥协。架构设计需要兼容旧系统，技术选型受到预算和交付周期的约束，甚至连功能优先级都可能被业务方反复拉扯。最终的成果也许稳定、成熟、可扩展，但往往早已偏离最初的理想，只是一个“在现实中能活下来的产物”。
而玩具项目恰恰相反。它的价值不在于规模，而在于纯粹。你是唯一的决策者，可以自由地尝试最新的技术栈、探索更优雅的架构、实践理想化的工程哲学。没有历史负担，没有审批流程，没有妥协的必要。这样的环境，才能让你在不受干扰的状态下追求“正确”的设计，构建出真正体现个人技术理念的作品。
玩具项目也许没有用户，但它可以让你保持技术的前沿感，验证新思路，积累经验。很多伟大的框架、工具和公司，最初都源自开发者的“玩具项目”。所以，不要低估它的意义——它不仅是实验场，更是技术成长的温床。
Forwarded from 咕 Billchen 咕 🐱 抹茶芭菲批发中心 (billchenchina | 缩缩)
All modern digital infrastructure
https://mk.absturztau.be/notes/af9ier31oog102r8
https://mk.absturztau.be/notes/af9ier31oog102r8
Forwarded from AprilNEA
你让 AI 写代码，AI 能写的你要能写，AI 不能写的你也要能写，AI 设计不了的你要能设计，AI 理解不了的你要能理解，做不到就不要让 AI 写代码
#Rust #OpenSource
昨晚睡前看到 yihong 的博客，受到启发，决定
看看 rust-lang 有啥可做的。结果还真有一个非常
简单的测试需要添加，今天早起就被合并了。
https://github.com/rust-lang/rust/pull/150434
昨晚睡前看到 yihong 的博客，受到启发，决定
看看 rust-lang 有啥可做的。结果还真有一个非常
简单的测试需要添加，今天早起就被合并了。
https://github.com/rust-lang/rust/pull/150434
GitHub
Add test for never type fallback in try blocks with `Into<!>` by AprilNEA · Pull Request #150434 · rust-lang/rust
Summary
Adds UI tests for issue #125364, which involves the interaction between
never type fallback, try blocks, and From/Into trait bounds.
Changes
Added tests/ui/never_type/try-block-never-type-...
Adds UI tests for issue #125364, which involves the interaction between
never type fallback, try blocks, and From/Into trait bounds.
Changes
Added tests/ui/never_type/try-block-never-type-...
Forwarded from Sukka's Notebook
#BugFi #UniFi
UniFi Cloud Gateway Fiber 基本上实锤 用的就是 联发科 MTK Filogic 方案。
上图是 广东比派科技 的 香蕉派 R4 Pro 方案（联发科 MTK Filogic 880），可以看到和 UCG Fiber 几乎完全一致：
4 个 2.5 GbE RJ45 电口
一个 10 GbE RJ45 电口
两个 10 GbE SFP+ 光口
M.2 总线
A73 ARM64 CPU
这也解释了为什么 UCG Fiber 竟然有 PPPoE 硬件加速、而 BugFi 目前所有机架式路由器都不支持。并不是 UniFi 主动要求供应商提供，纯粹是联发科方案自带。
注：「BugFi 目前所有机架式路由器」指代 EFG、UDM Pro/SE/Pro Max、UXG。截至本消息发布，UniFi 尚未正式官宣 下一代机架式 UDM 型号 UDM Beast、预计搭载 Marvell 方案的 ARM64 CPU、同样不带 PPPoE 硬件加速。
UniFi Cloud Gateway Fiber 基本上实锤 用的就是 联发科 MTK Filogic 方案。
上图是 广东比派科技 的 香蕉派 R4 Pro 方案（联发科 MTK Filogic 880），可以看到和 UCG Fiber 几乎完全一致：
4 个 2.5 GbE RJ45 电口
一个 10 GbE RJ45 电口
两个 10 GbE SFP+ 光口
M.2 总线
A73 ARM64 CPU
这也解释了为什么 UCG Fiber 竟然有 PPPoE 硬件加速、而 BugFi 目前所有机架式路由器都不支持。并不是 UniFi 主动要求供应商提供，纯粹是联发科方案自带。
注：「BugFi 目前所有机架式路由器」指代 EFG、UDM Pro/SE/Pro Max、UXG。截至本消息发布，UniFi 尚未正式官宣 下一代机架式 UDM 型号 UDM Beast、预计搭载 Marvell 方案的 ARM64 CPU、同样不带 PPPoE 硬件加速。
❤1