若海观澜 - 茶话四海
type: channel
link: https://www.rehiy.com/topic/flood/
items: 云盘从“机械”到“全闪”，背后到底换了什么底牌
items: 交互的轮回与升维：当数据库“听懂人话”
items: 沧海易名，初心未改——「若海观澜」启事
items: 浅析 OpenClaw 的诱惑与危险
items: 腾讯云TDP2026年初线上会议致辞
items: 腾讯云TDP主理人--若海答记者问
items: 国际通用语种代号表（ISO 639）中文版
items: 积极维护防汛救灾网络秩序倡议书
items: 玩转腾讯云对象存储 - COS 插件
items: Windows11 恢复完整右键经典菜单

云盘从“机械”到“全闪”，背后到底换了什么底牌
type: item
date: 2026-06-10T19:00:00+08:00
description: “早期高性能云盘之所以快，是因为底层加了SSD做缓存。后来SSD价格下来了，产品线才慢慢变成现在的全闪存。” 在腾讯云的一个群里，一位产品老兵提了这么一句；这句话看着平常，但细细一想，其实把过去十年云计算底层存储的演变路径，说得明明白白。 当年为什么非要“HDD + SSD缓存”？ 2015年前后企业刚开始大规模上云，大部分架构师对存储的认知还停留在“容量够用就行”。那时候云厂商最基础的就是机械硬盘（HDD）云盘，成本低、容量大，但随机读写IOPS通常只有几百，延迟动不动就十几毫秒。跑个静态网站、存备份日志完全没问题，可一旦挂上MySQL或者业务系统，查询卡顿、连接池爆满就成了家常便饭。 怎么破局？当时的技术路线很务实：底层继续用HDD保底容量，但在控制层叠一层SSD做缓存。读写频繁的数据自动预热留在SSD里，冷数据沉降回机械盘。这套“混合加速”方案当时非常有效，IOPS直接翻了几倍，延迟压到两三毫秒。业内后来管它叫“高效云盘”或“混合盘”，本质是用架构换性能，属于那个年代的性价比最优解。 但混合架构始终有个隐忧：数据在HDD和SSD之间频繁搬运，本身就有延迟和一致性开销；存储控制层越复杂，故障排查越麻烦。很多团队后期为了压延迟，不得不手动做数据热区规划，运维成本反而上去了。 成本曲线下来的那一刻，产品逻辑变了 转机出现在SSD价格断崖式下跌。2018年前后，随着3D NAND堆叠技术成熟和产能放开，企业级SSD的单价终于降到了当年“混合方案”的边际区间。云厂商算了一笔很现实的账：既然全闪的硬件成本已经追平，为什么不直接上纯SSD/NVMe架构？ 去掉缓存分层后，IO路径变短，调度逻辑变简单，延迟更稳定，排错也更干净。于是产品线开始转向“全闪存”，控制台里的命名也从“高效”“增强型”变成了直白的“SSD云盘”“极速型”。这不是营销话术，而是底层架构已经能稳定支撑高并发业务，没必要再用混合方案做技术妥协。 为什么后来都不强调“介质”了？ 细心的同学会发现，现在去各大云厂商控制台选盘，基本都按IOPS或延迟分级，而不是再纠结底层是机械还是固态。这不是说SSD不重要了，而是介质已经成了行业标配。 全闪云盘现在也被拆成了PL1/PL2/PL3，或者按场景打包（数据库专享、高吞吐、通用型）。命名从“用了什么材料”变成了“能扛多大负载”。背后的逻辑很直接：客户不再需要自己懂存储分层调度，只需要知道自己跑什么业务、要多少性能SLA。当技术足够成熟，产品就该退后一步，把复杂度交给平台，把选择权还给业务。 感慨万千 回看这几年的演进，技术路线永远跟着成本曲线和业务诉求走。早期用SSD缓存是妥协，现在上全闪是顺势。如果你在负责上云或重构存储架构，有几个经验可以避坑： 别迷信“全闪一定快”。关键看集群调度协议和网络架构。早期没做并发优化和预读策略的全闪存，延迟波动可能反而不如调优好的混合盘。 数据库上云，盯紧P99延迟。IOPS峰值再高，如果尾部延迟偶尔飙到几十毫秒，业务层照样会超时。优先选支持NVMe直连和本地缓存的盘型。 成本优化别只堆高性能块盘。很多场景适合“块存储+对象存储”混合架构：热数据走全闪，日志/备份走低频存储，整体TCO能降一大截。 备注：本文75%的内容由AI完成 存储介质的迭代从来不是单纯的技术升级，而是云计算走向成熟的过程中，一次又一次在性能、成本和复杂度之间的重新平衡。下次在控制台勾选云盘规格时，不妨多看两眼背后的SLA定义。那些冷冰冰的参数，其实就是过去十年架构师们在机房里熬出来的经验。

交互的轮回与升维：当数据库“听懂人话”
type: item
date: 2026-03-26T09:44:00+08:00
description: 在经历了图形用户界面（GUI）数十年的统治后，我们正站在一个人机交互范式的转折点上。随着AI智能体（AI Agent）技术的成熟，以及数据库原生支持自然语言查询，那个曾被视为“复古”的纯文本交互，正以一种全新的姿态回归。这并非技术倒退，而是一场从“操作”升维到“对话”的深刻进化。 备注：下文由AI订正，修改篇幅约17%（下一篇可能更多，直到 100%） 一、图形界面的瓶颈：效率的诅咒 自WIMP范式（窗口、图标、菜单、鼠标）诞生以来，“所见即所得”极大地降低了计算机的使用门槛。然而，随着软件功能日益复杂，GUI的弊端也愈发明显。 操作路径冗长：为了完成一个跨应用的复杂任务，如“帮我预订下周去上海的机票，并根据天气准备行李清单”，用户需要在多个图形界面之间跳转、点击数十次。GUI将记忆负担转嫁给了用户，你必须记住功能藏在哪个菜单下，而不是专注于任务本身。 信息密度低：图形界面充斥着视觉元素，而在处理复杂逻辑和大量数据时，文本的信息密度和传输效率远高于图形。 二、根基的动摇：数据库开始“听懂人话” 过去，自然语言查询往往依赖于应用层的一个“翻译器”，将自然语言转为SQL。但当数据库开始原生支持自然语言查询时，这意味着数据层的访问门槛被彻底抹平。 SQL“黑话”的消亡：对于非技术人员而言，SQL语法曾是一道难以逾越的鸿沟。如今，业务人员可以直接问数据库：“上个月华东区卖得最好的产品是什么？”系统不仅能理解，还能直接返回可视化的图表。这意味着，连接“人脑思维”与“机器数据”的翻译成本趋近于零。 交互的“直达底层”：在传统软件架构中，用户请求需经由前端（UI）->后端（API）->数据库层层传递。而当数据库能直接理解自然语言时，中间层的很多“胶水代码”和复杂的前端交互逻辑变得多余。用户可以直接“对话”数据，这种极简的路径是对现有架构的巨大冲击。 三、范式的颠覆：从“界面”到“对话” 当数据获取变得无摩擦，当AI智能体成为执行主体，交互设计的重心将发生根本性的位移。 UI的“隐形化”：如果我能通过语音或文字直接命令智能体完成任务，为什么还需要一个复杂的APP界面？未来的应用可能不再是一个个独立的APP，而是一个个智能体（Agent）。交互的终点不再是“页面跳转”，而是“任务完成”。 API的进化与共存：有人会问，既然数据库能听懂人话，API是不是就没用了？恰恰相反。在人机交互层面，自然语言取代了GUI；但在机机交互（M2M）层面，API依然是不可替代的基石。智能体之间的高效协作、精确的数据传输、权限的校验，依然需要结构化的API作为“神经突触”。自然语言是给人听的，而API是给机器执行的。两者将在不同层级共存。 智能体的“社会化”：未来的交互不再是人与机器的单点对话，而是一个智能体网络。一个负责财务的Agent需要调用一个负责市场分析的Agent的数据，再通过一个负责执行的Agent去下单。这种复杂的分布式协作，将形成一个庞大的“机器社会”。人类只需下达顶层指令，剩下的由智能体们“谈判”和“分工”完成。 四、挑战与反思：我们准备好了吗？ 当然，全面颠覆并非一蹴而就。 精确性与模糊性的博弈：自然语言虽然自然，但充满歧义。“稍微调亮一点”这种指令适合氛围调节，但不适合工业控制。在需要绝对精确的场景下，传统的数值输入和GUI滑块依然有其价值。 信任与“黑盒”恐惧：当智能体在后台自动执行一系列操作时，用户如何知道它做了什么？如何建立可解释性，让用户放心地把控制权交出去？这是交互设计面临的新课题。 五、结语：回归本源，效率为王 技术的发展往往呈现螺旋上升的形态。40年前，我们因为计算机太难用而发明了图形界面；40年后，因为AI太聪明，我们发现最高效的交互方式依然是语言——只不过这一次，计算机真的听懂了，并且能直接操作数据。 这并不是说图形界面会彻底消失。未来的形态很可能是“混合模式”：自然语言交互负责宏观的任务指挥和复杂逻辑处理，而GUI则作为辅助，用于展示可视化结果或进行精细的微调。 人机交互的终极目标，从来不是炫酷的特效，而是让技术隐形，让人专注于创造本身。当数据库开始说“人话”，我们离这个目标又近了一大步。

沧海易名，初心未改——「若海观澜」启事
type: item
date: 2026-02-09T09:51:00+08:00
description: 我的个人技术博客，即日起正式更名为“若海观澜”。原名称“若海的技术写真”将完成其历史使命，暂别舞台。 其一、此番更名，并非一时兴起，而是经过长时间的慎重考量。首要原因在于，原名称中的“写真”一词，在某些内容分发平台或社交媒体的语境下，容易产生不必要的误解或引发限制，影响了内容的正常传播与分享。正如其他自媒体账号因名称带来误解而选择更名一样，为了确保技术分享的通达无阻，更名成为必然选择。 其二，源于我个人对技术写作认知的深化与博客内容的发展。博客创立之初，我以“全栈攻城狮”自居，专注于分享具体的技术实操“干货”，故名“技术写真”，意在记录技术的真实面貌。然而，随着笔耕不辍，分享的内容逐渐从微观的代码、脚本（如Linux操作、OpenWrt扩容），拓展至对行业趋势、技术哲学的宏观思考（如AI安全、架构演进）。我愈发感到，技术不止是解决问题的工具（“技”），其背后更蕴含着对世界运行规律的洞察与探索（“道”）。“写真”二字，已难以承载这份从“术”到“道”的视野延伸。 因此，新名“若海观澜”应运而生。“若海”之名，源自我一直喜爱的“澹兮其若海”之境，寓意沉静与渊博，保持不变。“观澜”二字，则寄托了新阶段的愿景：立于技术瀚海之畔，观察浪潮起伏，于纷繁现象中洞见本质规律。新的Slogan“以技探道，于思致远”，正是这一理念的凝练表达——以扎实的技术实践为舟筏，探索其背后的原理与大道；在持续深度的思考中，行稳而致远。 我深知，一个使用了许久的名称突然改变，可能会给老读者带来短暂的困惑或不适应。对此，我深表歉意，并恳请大家理解。这正如许多机构或媒体在发展过程中，为更贴合现状与未来方向而调整名称一样。名称虽易，但我分享技术热忱、与各位交流切磋的初心，未曾有丝毫改变。 从“若海的技术写真”到“若海观澜”，变的是更加凝练、更具包容性的名称，不变的是对技术本质的追寻和对内容价值的坚守。感谢大家一路以来的陪伴、支持与包容。 未来，我期待以“若海观澜”的新身份，继续与诸位一同，在技术的海洋中观澜索源，以技探道。

浅析 OpenClaw 的诱惑与危险
type: item
date: 2026-02-02T19:02:00+08:00
description: 当前最热门的 AI 助手 OpenClaw，正以最高系统权限（root）广泛运行，带来了显著的安全风险。在深入阅读前，请核查以下几点： 检查运行权限：确认您的 AI 助手是否以 root 账户运行？将其改为普通用户。 停止危险脚本习惯：是否曾使用 curl | bash 或 wget | bash 等命令？务必遵循“先下载、审查、后执行”的原则。 保护敏感凭据：API 密钥、密码等是否曾直接出现在命令行中？将其移入环境变量或加密配置文件中。 控制网络暴露：是否将 OpenClaw 的 Web 界面暴露在公网？确保仅限特定IP访问，或仅允许通过IM软件进行使用。 开启定期审计：请立即审查 OpenClaw 的历史命令记录，排查是否存在凭据泄露或危险操作。 0x01 OpenClaw 一月下旬，一款名为 OpenClaw（原名Clawdbot/Moltbot） 的开源AI助理应用在中外技术社区与社交媒体上迅速走红，从 X、Reddit 到中文技术圈频频刷屏。 OpenClaw 运行在使用者自己的环境中（比如本地电脑、个人服务器等等），并且交互的方式直接回归到了用户熟悉的聊天软件之中，就像是与一位同事或朋友交谈那样。 0x02 网络安全风险 许多用户为了方便，直接将 Web 界面暴露在公网，仅依赖一个 Token 进行鉴权——这相当于只给敞开的大门挂了一把简单的锁。 端口号 风险说明 18789 默认 Web 端口，虽需 Token 授权，但 Web 应用本身可能存在未知安全漏洞。 443 HTTPS 端口，部分开发者改用此协议访问控制台，实际上它仅能保护数据传输过程，无法确保应用安全。 22 若同时开放 SSH 端口，弱口令风险巨大，一旦被暴力破解，攻击者将直接获得服务器控制权，后果严重。 0x03 恶意插件与指令 供应链投毒：不经意安装了某些被刷好评的恶意插件或技能 提示词注入：你的 AI 助手执行阅读邮件、网页等指令时被注入恶意指令 查看history命令记录、查看敏感配置文件、甚至执行恶意脚本等 0x04 云厂商的态度 在安全与易用的平衡上，国内云厂商对 OpenClaw 类工具的态度均较为克制，但也有些分歧。 阿里云 倾向于快速部署，在官方文档中提供了完整的 OpenClaw 集成指南，并默认开启 Web 控制台功能（有安全提示）。 参考链接：https://help.aliyun.com/zh/simple-application-server/use-cases/openclaw-web-page-integration 腾讯云 态度则更为谨慎，其一键部署镜像默认关闭了 WEB 控制台，指引用户安全登陆，并在相关教程中提示：“强烈建议你在使用结束后，及时关闭 WebUI 面板” 参考链接1：https://cloud.tencent.com/developer/article/2625602 参考链接2：https://cloud.tencent.com/developer/article/2624003 来自安全厂商的测绘数据 截止发稿时关于 OpenClaw Web 端口的暴露数据（仅供参考，不做评价） 厂商 暴露数 阿里云 9,974 DigitalOcean, LLC 2,261 Hetzner Online GmbH 2,199 腾讯 1,436 OVH SAS 487 0x05 现在该做什么？ 给产品方 (OpenClaw) 安全引导：安装时强制创建并建议使用非 root 用户；提供配置文件加密选项 风险控制：实现凭据在日志中的自动脱敏；建立危险命令（如 rm -rf）拦截与二次确认机制 审计与权限：提供详细的审计日志；支持命令白名单/黑名单功能 给云平台（各大云厂） 最佳实践：提供更安全的开箱环境 安全倡导：在相关文档和教程中明确进行安全操作引导 防御升级：持续关注并主动防护与此类工具相关的新的攻击面 给终端用户 坚守安全基线：定期离线备份数据；定期审查 AI 助手的历史命令 贯彻最小权限原则： 为 OpenClaw 创建专用、低权限的系统用户 若需提权，在配置 sudo 权限时，严格限定仅允许执行必要的命令 考虑使用文件系统访问控制列表（FACL）进行更细粒度的权限控制 在独立的网络进行部署，并安装主机安全类产品进行异常监测 独立的网络VPC、独立的API密钥、不要存敏感数据 0x06 关键在于平衡 拥抱效率，但不牺牲安全。 信任 AI，但不放弃控制。 追求自动化，但保留关键的人工干预点。 结语：技术永远是一把双刃剑。AI 助手可以是你最得力的助手，也可能成为最危险的隐患。区别在于，你是否给予了正确的指引和必要的约束。

腾讯云TDP2026年初线上会议致辞
type: item
date: 2026-01-29T10:05:00+08:00
description: 时间：2026年1月28日 主讲：若海（腾讯云TDP主理人） 前言：每次被推到台前、做为开场主讲，都顶着莫大的压力，要知道我只是一个写了20年余代码的码农罢了，并不是那种文化底蕴深厚的大讲师。我会担心讲不好被批评，更担心伙伴们听不下去那些长篇大论；带着大家要有深度、要有风度、要有文化、还要有故事感的要求，我花了十几个小时来改稿子；即便开场了，还在边改边讲... 开场 尊敬的各位同仁、各位相知相伴的开发者挚友： 大家晚上好！我是若海，腾讯云TDP的同行者与守望人；岁聿云暮，新元肇启。在这2026年的开篇之时，能与各位云端相聚，共忆来时之路，同望未来之景，我心中满怀温澜与敬意。 溯源：筚路蓝缕，以启山林 回望二零年代之初，TDP犹如一粒微光，悄然萌发于一方名为“产品吐槽”的天地之间。其志至简，其心至诚：只为在腾讯云产研与万千开发者之间，筑起一座无碍、赤诚的桥梁。恰如老子所言“道生一，一生二，二生三，三生万物”，我们自最初的“问答小组”起步，至2021年首批会员踏浪而来，见证了这方天地第一次生机萌动。此后，2023年大环境寒潮漫卷，社区一度沉寂如冬，却也似一场深藏，让我们内观自省，静蓄力量。直至2024年盛夏，TDP如凤凰涅槃，浴火重生。此番归来，非为重复昨日，而是矢志开辟一个“贤者共治，天下为公”的开发者理想乡。 立新：贤者共治，星火燎原 《礼记》有云：“独学而无友，则孤陋而寡闻。”TDP所循之道，贵在“集众智、合众力”。2025年，我们成立了由官方与社群贤达共担的“常务理事会”，以此为基，构筑社区治理之脉络。我们将社群细分为十六个产品反馈群与十三个交流群，仿若古时“百家争鸣”，让各领域才智激荡交融、相映生辉。更有专属礼遇、权威认证与荣名之设，皆为让每一位躬身入局、真诚付出的你，名归实至，于此间留下不可磨灭的印记。这一切的背后，是“开发者赋能开发者”的朴素信念——我们不仅仰望星空，更愿成为彼此照亮的星辰，以生命影响生命，以微光点燃微光。 成效：春风化雨，润物无声 四余载光阴流转，TDP已从一条朴素的回响之径，生长为一片承载可能的厚土。在这里，我们见证了太多温暖而坚韧的成长：有青春学子，因解答容器疑难而褪去青涩，终成社区中坚，并觅得心之所向的前程；亦有资深架构师，于此邂逅知音，于技术迷雾中得见明灯。TDP之意义，早已超越技术问答本身，它更是一处安顿身心、切磋琢磨的修炼场，让每一个投身其中的人，皆能寻得自己的坐标，完成从“术”至“道”的升华。 展望：星辰大海，继往开来 眺望2026年乃至更远之途，TDP的画卷将如何铺展？ 其一，深耕共创。由“纳谏”走向“共创”，邀核心成员更早步入新品设计与布道之列，力行“知行合一”，让每一份智慧皆被温柔拾取。 其二，筑路搭桥。系统构建开发者成长体系，为不同阶段的你描摹清晰路径，愿TDP成为诸位职业航程中一盏不灭的灯塔。 其三，海纳百川。进一步敞开生态，鼓励开发者开枝散叶，设立区域节点，使TDP终成一片生生不息、郁郁葱葱的“开发者大陆”。 结语 “千人同心，则得千人之力；万人异心，则无一人之用。”TDP的今日，皆因在座每一位倾注的热望与智慧。是你们在长夜荧荧中调试代码的执着，是你们于社区问答间传递的善意，共同织就了这个我们称之为“家”的技术净土。前路迢迢，山高水长；行而不辍，终抵云程。愿我们继续执手同舟，以梦为码，以心为帆，共赴那浩瀚无垠的云上星河！ 谢谢大家！

腾讯云TDP主理人--若海答记者问
type: item
date: 2025-11-01T20:55:00+08:00
description: 首先感谢各位关注腾讯云TDP的开发者，以及南方人物周刊的记者朋友--林滔。今天能在这里和大家交流，分享我这个“编外人员”的故事，感觉非常奇妙。这本身或许就印证了腾讯云TDP的独特魅力——它真正看重的是你对技术的热情和实际的贡献，而不仅仅是你的身份标签。 答记者问 下文由混元大模型根据2025年10月20日现场录音转写生成，如有错漏还请谅解与指正。 1、听说您并非腾讯的正式员工，而是一名独立开发者，因为热爱分享被邀请来做了主理人，想知道背后的故事是什么？最初是如何与腾讯云TDP结缘的？ 我的核心身份始终是一名开发者。与腾讯云TDP的结缘，始于用脚投票。作为早期使用者，我在个人项目和多云架构选型中深度体验了腾讯云。与许多开发者一样，我最初通过工单反馈问题，但不同的是，我乐于在技术社区分享我的解决方案和使用体验。可能是这种纯粹基于解决问题、共同成长的分享，吸引了官方和开发者的注意。 当2021年腾讯云TDP正式招募会员时，我抱着想从一个吐槽者变成一个建设者的心态加入。正是因为在社群中持续贡献有价值的内容，并从开发者视角提出了许多建设性意见，才逐渐被大家信任，最终受邀承担主理人这份责任。这背后不是一份工作，而是一种志业，是社区对共建精神的认可。 2、关于腾讯云TDP，听说前身是一个官方问答组，当初这个想法是如何诞生的？又是如何迭代成了如今的样子？它的发展历程是怎样的？ 腾讯云TDP的进化史，是腾讯云与开发者关系演变的缩影。其前身可以追溯到更早的产品吐槽群，核心目的是建立一条超越传统工单的、高质高效的产研直连通道。 萌芽期（2020年初）：源于一个朴素的想法：把最爱吐槽、最核心的开发者聚在一起，让产研直接听到炮火声。这是问答组的形态。 高速发展期（2021-2022年）：正式以腾讯云TDP品牌运作，从单一反馈升级为多元社区。我们有了会员体系、社区活动、知识分享，如年末盛典、技术征文，社区呈现出强大的凝聚力。 沉默与反思期（2023年前后）：随着市场环境变化，运营资源收缩，社区进入沉默期。但这段时间至关重要，我们得以冷静反思：社区不能仅靠官方驱动，必须构建内生的、由开发者主导的活力。 重启与革新期（2024年至今）：2024年7月的重启是里程碑。我们不再只是反馈群，而是成立了由官方和社群代表共治的常务理事会，推出了清晰的角色体系（理事、顾问、KOL、会员）、专属福利和官方认证，目标是打造一个开发者自我治理、自我演进的共生生态。 3、腾讯云TDP和腾讯云之间是如何支持配合的，请您讲解下其中的逻辑？ 我们的配合逻辑是外部视角驱动内部优化。腾讯云TDP扮演着三重角色： 感知神经末梢：我们散布在几十个体验反馈群中的开发者，是腾讯云产品在最真实场景下的传感器，能快速发现产品能力、API设计、文档质量等方面的真问题。 价值共鸣放大器：当一款好产品通过腾讯云TDP成员的实践和布道，产生口碑效应，这种信任背书远比官方广告更有力。例如，有成员在社群分享云函数的实战经验，直接带动了一批同行采用。 创新策源地：开发者的前沿需求和建议，是产品迭代甚至创新产品诞生的源泉。腾讯云TDP机制确保了这些声音能被产研团队直接、无损耗地接收。配合的逻辑是双向赋能：腾讯云为腾讯云TDP提供资源和支持，腾讯云TDP为腾讯云带来真实的用户价值和市场洞察。 4、来到腾讯云后，您都着手做了哪些重要的事情？背后的思考是什么？ 我主导的核心工作是去中心化和生态化。 架构重组：推动成立常务理事会，让核心开发者进入决策层。思考是：社区不能系于一人，必须建立可持续的治理结构。 通道细化：将一个大群拆分为按产品领域划分的体验反馈群。思考是：提升交流效率，让对口专家解决专业问题，形成深度互动的小生态。 权益透明化：设计并公开腾讯云TDP专属福利、认证证书。思考是：让贡献者被看见、被奖励，建立健康的正向激励循环。 综上，背后的根本思考是：将腾讯云TDP从一个官方运营的社群转变为开发者共治的平台。 5、与传统社群、其它品牌的社群相比，腾讯云具有哪些特点和优势？运营目标和理念是什么？ 最大特点和优势是基于真实反馈的深度共治。许多社群止于知识分享或活动运营，而腾讯云TDP的核心是影响产品。 理念：我们的理念是开发者赋能开发者(Developers Empower Developers)。我们不相信单向的布道，而是坚信开发者群体间相互启发、共同解决实际问题的力量。 目标：短期目标是成为腾讯云产品改进的第一反馈源；长期目标是培育中国云原生时代最具影响力的开发者共同体。 优势：相较于其他社群，腾讯云TDP成员的意见能直接触达产研，甚至改变产品路线图。这种话语权和成就感是最大的吸引力。 6、腾讯云TDP主要覆盖了哪些人群？不同人群的需求有哪些共性和不同？腾讯云TDP能够为其带来怎样的价值？ 我们覆盖了从学生、初创…

国际通用语种代号表（ISO 639）中文版
type: item
date: 2023-09-13T14:20:00+08:00
description: 引言 最近在折腾本地化的机器翻译模型（NMT），面对众多的语言代码一筹莫展，从网上也没找到合用的对照表，于是参考维基百科资料整理出下表，如有错漏欢迎指正。 名词解释 ISO 639 标准是一套用来分类语言的标准命名法。它包括五个部分，每个部分提供了不同长度和范围的语言代码。这些代码可以用于表示不同语言的名称，语言家族和组，以及语言的变体和方言。该标准的主要目的是为了方便信息交流和管理，以及在网站上显示不同语言版本的内容。 代码表说明 为方便读者理解表格内容，先对表格的一些列和规定进行下解释。 列 639-* 释义 ISO 639-1：用来表示世界上大部分的主要语言 ISO 639-2：用来表示更多的语言，包括一些较少使用或已经消亡的语言；表格中部分条目给出了2个代码，带星号的是书目代码（B），另一个是术语代码（T） ISO 639-3：用来表示尽可能完整的语言列表，包括现存的、已经消亡的和古代的语言 ISO 639-5：用来表示语言家族和群组（现存的和已经消亡的） 列 Scope 释义 individual：单一语言 collections：语言集合，例如按照遗传或地区 macrolanguages：宏语言 列 Type 释义 ancient：古代语言（自古代以来灭绝） historical：历史语言（与现代形式不同） extinct：近代灭绝的语言 constructed：人造语言 一些特殊代码 mis：未编码语言 mul：多种语言 qaa-qtz：保留给本地使用 und：未确定 zxx：无语言内容、不适用 ISO 639 代码表 如需直接用于项目，可下载我整理的ISO-639 JSON数据集，文件编码 UTF-8 ISO 639-2 ISO 639-3 ISO 639-5 ISO 639-1 Language name Scope Type Native name Other name 中文名 aar aar aa Afar Individual Living Qafaraf; ’Afar Af; Afaraf; Qafar af 阿法尔语、阿法语 abk abk ab Abkhazian Individual Living Аҧсуа бызшәа Aƥsua bızšwa; Аҧсшәа Aƥsua Abkhaz 阿布哈兹语 ace ace Achinese Individual Living بهسا اچيه Acehnese 亚齐语 ach ach Acoli Individual Living Lwo Acholi 阿乔利语 ada ada Adangme Individual Living Dangme Dangme 阿当梅语 ady ady Adyghe; Adygei Individual Living Адыгабзэ; Кӏахыбзэ West Circassian 阿迪格语 afa afa Afro-Asiatic languages Collective 亚非语系、闪含语系 afh afh Afrihili Individual Constructed El-Afrihili 阿弗里希利语 afr afr af Afrikaans Individual Living Afrikaans 阿非利堪斯语、南非荷兰语、南非语 ain ain Ainu Individual Living アイヌ・イタㇰ Ainu-itak 阿伊努语 aka aka ak Akan Macrolanguage Living Akan 阿坎语 akk akk Akkadian Individual Ancient 𒀝𒅗𒁺𒌑 阿卡德语 ale ale Aleut Individual Living Уна́ӈам тунуу́; Унаӈан умсуу 阿留申语 alg alg Algonquian languages Collective 阿尔冈昆语族 alt alt Southern Altai Individual Living Алтай тили 南阿尔泰语 amh amh am Amharic Individual Living አማርኛ Amârıñâ 阿姆哈拉语 ang ang English, Old (ca.450–1100) Individual Historical Ænglisc; Anglisc; Englisc 古英语 anp anp Angika Individual Living 安吉卡语 apa apa Apache languages Collective Southern Athabaskan languages 阿帕切语、阿帕切语支 ara ara ar Arabic Macrol…

积极维护防汛救灾网络秩序倡议书
type: item
date: 2023-08-11T19:58:00+08:00
description: 近期，东北、华北、黄淮等地出现极端降雨，多地出现居民被困和人员伤亡情况，全国各地救援力量迅速集结，驰援防线救灾一线，全力投入防汛救灾工作。在当前全国齐心聚力、携手救灾的特殊时期，个别网民编造传播涉灾情虚假信息、挑动地域对立歧视，严重扰乱网上舆论秩序，干扰妨碍抗险救灾工作。为进一步净化网络环境，维护网络秩序，全力维护全国上下万众一心、全力救灾恢复、全力保障人民群众生命财产安全和社会大局稳定的网上主旋律，切实成为防汛救灾的参与者、助力者，现发出如下倡议： 一、自觉抵制违法有害信息网上传播 1、坚决抵制违法有害信息。不制造、不听信、不传播涉灾救灾违法有害和负面不良信息，不以讹传讹，不煽风点火，不随意传播无出处、无证据的举报、泄露隐私、个人攻击、不良言论等内容。 2、严管信息发布账号。强化对账号信息的人工审核和资质认证，严防假冒仿冒党政军机关、新闻媒体、地方政府和用户账号，严控不符合资质认证要求并从事专门领域信息内容生产的“自媒体”账号，严禁操纵“自媒体”账号矩阵发布传播涉灾救灾违法和负面不良信息。 3、严管信息发布内容。用户发布新闻信息，要按照有关规定标注信息来源；自行拍摄信息，要逐一标注拍摄时间地点；使用技术生成信息，要打上技术生成标签；引用旧闻旧事的，要说明事发时间地点；发布含有虚构演绎内容信息，要加注虚构演绎标签；平台对存疑或谣言信息，将标记争议、谣言标签，并按规定采取限流、辟谣、禁言等处置措施。 二、坚持对违法有害信息“零容忍” 4、增强网络文明意识。树立正确的网络道德观，主动抵制和举报各种网上违法犯罪和低俗不良行为，坚决同网络违法犯罪活动作斗争，全力维护国家、社会、集体和个人的合法权益。 5、强化舆论正面引导。通过平台公约、用户协议完善对粉丝数量和营利权限的管理措施，对违法违规账号，将视情采取关闭禁言或者限制、禁止新增粉丝以及清空全量粉丝等惩戒措施；对多账号联动蹭炒防汛救灾热点话题、敏感事件进行恶意营销的用户账号，将取消或严禁赋予营利权限。 6、积极营造健康网络舆论生态。对“自媒体”账号，将显著标明所属MCN机构，对利用签约账号联动炒作、多次出现违规行为的MCN机构，将采取限制营利权限、限制提供服务、入驻清退等处置措施。 三、积极发动发挥网络平台的正能量 7、建立健全监督举报。鼓励用户参与平台信息内容管 理，收集并举报违法有害信息，发现并揭批谣言和虚假信息，主动向监管部门提供相关线索，并配合调查和处理，最大限度消除负面影响。 8、积极协助求助求救。主动搜集群众网上求助求救线索，及时报告有关主管部门，并在当地党委政府的统筹指挥下，配合有关部门全力开展救灾救援工作。 9、坚决曝光违法犯罪案例。大力加强违法违规用户处置和账号曝光力度，开设警示教育专栏，定期发布违法违规用户典型案例，提醒警示用户严格遵守国家法律法规，严格履行平台公约和服务协议，加强自律自治。 技术写真

玩转腾讯云对象存储 - COS 插件
type: item
date: 2022-05-24T22:00:00+08:00
description: 玩转腾讯云对象存储 - COS 插件 本文由作者在 “开箱吧腾讯云 - 加码生态 / Get 对象存储操作新姿势” 专场演讲稿改写而成。 寄语：Tencent COS Play ! YYDS ! 作者：若海 （小春网技术总监、腾云先锋/TDP 会员) 时间：2022 年 5 月 24 日 遇见 COS 出于合规目的，小春网中国版逐步投入使用，并在腾讯云落地了部分业务。由于国内用户不是很多，大部分数据使用了云盘来存储。但随着业务的持续，产生了大量的附件和日志，图片审核和日志分析也成了一项不堪负重的工作。 我们分析了腾讯云的众多产品特点后，针对上述业务场景选定了 COS，并使用其关联的数据万象、图片审核、日志服务等能力来解放生产力。目前主要应用在下面几个场景： 存储分析产生的运行日志 存储用户上传的图片及附件 对用户上传的图片进行合规审核 对国内数据库进行流式增量备份 使用 COS 其实是非常简单的，腾讯云官方有完善的 API 文档，也提供了数种开发语言的 SDK，大家可以根据自己的使用场景来选择。 COS 插件生态 下面我来分享一些零代码用法，也就是今天的主角之一 -- COS 插件生态。 这里所讲的 COS 插件是指基于 COS API/SDK 开发的扩展类应用，我们可以将其大致分为三个类型：Local Apps（本地应用类）、WEB 插件类、S3 兼容类。 本地应用生态 Linux 使用 cosfs 挂载为本地目录（注意关闭系统对此路径的扫描，如 updatedb） Windows 使用 rclone 映射为本地磁盘（需要配合 winfsp 驱动实现） COS Browser 可视化界面工具（官方出品、支持多平台） Picgo 原生支持 COS 作为后端存储（支持多平台） ... WEB 插件生态 Discuz! 插件支持、官方出品 Typecho 插件支持、社区实现 WordPress 插件支持、官方出品 Cloudreve 原生支持配置 COS 作为后端存储 ... S3 兼容应用 Amazon Simple Storage Service（下文简称 S3）是 AWS 最早推出的云服务之一，经过多年的发展，S3 协议在对象存储行业事实上已经成为标准。COS 提供了兼容 S3 的实现方案。如果您在应用的说明中看到类似 S3 兼容存储 或 S3 Compatible 字样，那么大多数情况可以使用 COS 服务。 Oracle Secure Backup Cloud Module NextCloud Rclone s3cmd ... COS 安全策略 所有的 COS 应用，都需要使用一对密钥来授权访问能力。在举例讲解 COS 插件应用之前，我们先来看下 COS 的安全策略。 部分应用为了降低入门难度，其文档会引导用户使用主账号密钥，风险是非常大的。我推荐使用子账号密钥，并使用六段式资源描述限定权限范围。 登录腾讯云后台，进入访问管理/策略界面，创建一个相对严格的策略：指定 resource 为具体的存储桶及路径，并赋予全部操作权限。 进入访问管理/用户界面，创建一个用户，设置访问方式为编程访问，权限策略为我们刚才创建的策略。将其操作权限限定到指定的对象存储桶。 权限策略示例，官方问参考链接 https://cloud.tencent.com/document/product/436/31923 { "version": "2.0", "statement": [ { "effect": "allow", "action": ["cos:*"], "resource": ["qcs::cos::uid/1252030397:techo-1252030397/picgo/*"] } ] } COS 插件案例 下面，我们从本地应用和WEB插件两个经典场景，来看下 COS 的零代码使用方法。 Picgo 参数设置 PicGo: 一个用于快速上传图片并获取图片 URL 链接的工具。 使用腾讯云 COS，无需担心容量，自动添加水印、免维护托管。避免第三方图床跑路或者插入广告带来的风险。 安全提示：官方文档使用了主账号密钥，安全风险极高，建议使用前面讲到的子账号密钥 Wordpress 插件设置 Wordpress 腾讯云对象存储（COS）插件 通过腾讯云对象存储服务使网站中静态文件无缝同步腾讯云 COS，提升网站内容访问速度，降低本地存储开销。 安全提示：插件可以设置全局密钥，但请注意限定该子账号的最大权限范围 结束语 最后，感谢腾讯云、感谢TECHO、感谢腾云先锋、感谢我的东家小春网，感谢本次直播的诸位观众。 Tencent COS Play ! YYDS ! 下次再会 !

Windows11 恢复完整右键经典菜单
type: item
date: 2022-05-23T08:50:00+08:00
description: 已经使用了1年多 Windows11 系统，秉承着接受新事物的态度，一直未曾对 Windows 11 进行过太多的"降级"设置。最近由于需要编辑 PPT，来回复制、解压一些文件，终于还是无法忍受其右键菜单需要点击显示更多选项才能展开的骚操作了。 看了网上那些一步步操作注册表的教程，差点劝退我这个 CLI 党。来个简单到不是教程的教程吧： 右击左下角的徽标，在弹出菜单中选择 Windows 终端（管理员） 粘贴如下命令，回车即可完成设置。此操作将强制重启资源管理器！ reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f taskkill /F /IM explorer.exe explorer.exe