20250917
典范条目
你知道吗?
优良条目
朝鮮民主主義人民共和國吸菸現象是指在北韓,男性民衆的普遍程度比女性民衆的普遍程度要高。據統計43.6%的北韓男性有每日吸菸的習慣,相比之下每日吸菸習慣的北韓女性佔比爲4.5%,且多數是鄉鎮地區的中老年婦女。有鑒於此,吸菸引發的健康問題亦是北韓民衆死亡的一大誘因。在2021年有14.2%的北韓民衆因吸菸所引發的疾病而身亡,死亡率位居全球第6。
朝鮮民主主義人民共和國吸菸現象是指在北韓,男性民衆的普遍程度比女性民衆的普遍程度要高。據統計43.6%的北韓男性有每日吸菸的習慣,相比之下每日吸菸習慣的北韓女性佔比爲4.5%,且多數是鄉鎮地區的中老年婦女。有鑒於此,吸菸引發的健康問題亦是北韓民衆死亡的一大誘因。在2021年有14.2%的北韓民衆因吸菸所引發的疾病而身亡,死亡率位居全球第6。
Through the Looking-Glass, and What Alice Found There is a novel published in December 1871 by Lewis Carroll, a mathematics lecturer at the University of Oxford. It was the sequel to his Alice's Adventures in Wonderland (1865), in which many of the characters were playing-cards; in this novel the theme is chess. As in the earlier book, the central figure, Alice, finds herself in a fantastical universe. She passes through a large mirror into another world and finds that, just as in a reflection, things there are reversed, including logic. Eventually, after a succession of strange adventures, she wakes and realises she has been dreaming. The original illustrations are by John Tenniel. The book contains several verse passages and, like Alice's Adventures in Wonderland, introduces phrases that have become common currency. Through the Looking Glass has been adapted for the stage and screen and translated into many languages. Critical opinion of the book has generally been favourable. (Full article...)
September 17: Constitution Day and Citizenship Day in the United States
The Battle of Antietam took place during the American Civil War on September 17, 1862, between Confederate General Robert E. Lee's Army of Northern Virginia and Union Major General George B. McClellan's Army of the Potomac near Sharpsburg, Maryland, and Antietam Creek. Part of the Maryland campaign, it was the first field army–level engagement in the Eastern theater of the American Civil War to take place on Union soil. It remains the bloodiest day in American history, with a tally of 22,727 dead, wounded, or missing on both sides. Although the Union Army suffered heavier casualties than the Confederates, the battle was a major turning point in the Union's favor. This 1887 lithograph by Thure de Thulstrup depicts the charge of the Iron Brigade near the Dunker Church.
Illustration credit: Thure de Thulstrup; restored by Adam Cuerden
使用的命令
openssl speed -evp chacha20-poly1305
openssl speed -evp aes-128-gcm
这个是搬瓦工 THE-PLAN-V1 DC6 测试结果
数据块大小 (Bytes) | ChaCha20-Poly1305 (千字节/秒) | AES-128-GCM (千字节/秒) | 性能比 (ChaCha20 / AES) | 优胜者 |
---|---|---|---|---|
16 | 156,682.47 | 18,626.82 | 8.41x | ChaCha20-Poly1305 |
64 | 315,071.68 | 70,418.84 | 4.47x | ChaCha20-Poly1305 |
256 | 576,779.04 | 232,087.47 | 2.48x | ChaCha20-Poly1305 |
1024 | 668,036.78 | 545,034.92 | 1.23x | ChaCha20-Poly1305 |
8192 | 722,927.62 | 879,086.25 | 0.82x | AES-128-GCM |
16384 | 719,552.51 | 910,060.20 | 0.79x | AES-128-GCM |
这个是我手机三星 S24+ 的测试结果
加密算法 (Encryption Algorithm) | 16 字节 | 64 字节 | 256 字节 | 1024 字节 | 8192 字节 | 16384 字节 |
---|---|---|---|---|---|---|
ChaCha20-Poly1305 | 394,247.05 | 602,147.94 | 1,041,255.00 | 1,513,522.69 | 1,541,233.02 | 1,530,682.05 |
AES-128-GCM | 388,850.19 | 102,404.15 | 1,219,507.63 | 3,045,419.15 | 5,180,667.38 | 5,428,934.29 |
这是我通过 Wireshark 抓包 10 分钟通过代理访问常见的社交媒体(Google,X,Youtube,Reddit,Twitch...)抓包得到的包长度分布。
Topic / Item | Count | Average | Min Val | Max Val | Rate (ms) | Percent | Burst Rate | Burst Start |
---|---|---|---|---|---|---|---|---|
Packet Lengths | 135070 | 835.60 | 56 | 1456 | 0.2491 | 100% | 29.2500 | 62.560 |
0-19 | 0 | - | - | - | 0.0000 | 0.00% | - | - |
20-39 | 0 | - | - | - | 0.0000 | 0.00% | - | - |
40-79 | 48343 | 68.00 | 56 | 78 | 0.0892 | 35.79% | 8.5400 | 62.560 |
80-159 | 3736 | 113.39 | 80 | 159 | 0.0069 | 2.77% | 0.6500 | 508.661 |
160-319 | 4257 | 242.55 | 160 | 319 | 0.0079 | 3.15% | 0.4100 | 407.945 |
320-639 | 3280 | 465.36 | 320 | 639 | 0.0060 | 2.43% | 0.5500 | 61.854 |
640-1279 | 6355 | 1011.99 | 640 | 1279 | 0.0117 | 4.70% | 1.5600 | 61.750 |
1280-2559 | 69099 | 1449.57 | 1280 | 1456 | 0.1274 | 51.16% | 19.8800 | 62.560 |
2560-5119 | 0 | - | - | - | 0.0000 | 0.00% | - | - |
5120 and greater | 0 | - | - | - | 0.0000 | 0.00% | - | - |
直接二进制查看 go 编译的二进制文件,会发现带有 import 包信息,挺敏感的
depgithub.com/cespare/xxhash/v2v2.3.0h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs=
depgithub.com/google/uuidv1.6.0h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0=
depgoogle.golang.org/grpcv1.70.0h1:pWFv03aZoHzlRKHWicjsZytKAiYCtNS0dHbXnIdq7jQ=
depgoogle.golang.org/protobufv1.36.2h1:R8FeyR1/eLmkutZOM5CWghmo5itiG9z0ktFlTVLuTmU=
depgithub.com/golang-jwt/jwt/v5v5.2.1h1:OuVbFODueb089Lh128TAcimifWaLhJwVflnrgM17wHk=
但查了下没发现去除的办法
目的: 寻安卓专家,将目前 IOS APP “小球圈”上的功能逐步移植到安卓上。
我们是谁:
我们提供:
我们期望你:
合作方式有两种,外包制和合作制,外包制按照单个项目计费,合作制走收入分成( prefer 合作制,寻找长期合作者)。
关于股权,早期阶段不授予股权,现在大部分初创公司把股权玩坏了。在我看来,股权只会授予核心的关键人才,需要先证明价值再谈股权。
如果有兴趣和我们一起共创体育 AI 的未来,可以加 wx: tennislab_tech 交流
背景:某里员工合伙创办的 AI 初创公司
最近被安排起了一个新项目,全栈开发,个人比较喜欢用主流框架,就选择了 react-router v7 + tailwind 写前端页面,还挺有成就感的,使用 ssr 模式渲染,体验不错,loader 函数加载数据,action 执行提交,我有在非常用心的写,各种文件结构以及代码规范 eslint 什么的都配置好了,用该框架的最佳实践写前端。
本来一切都还好,但是最近另外一个同事也算是上级介入开发新需求,用着老一套的 ant design + react 各种 useEffect 满天飞的方式写,然后因为跨域客户端不能发送请求,就得在 loader 函数即服务端部分写获取数据逻辑,他没有写过,所以写了一段时间后,觉得开发效率低下,所以想着找时间和我讨论下该怎么用以前的那一套方式写,我看了下他分支的代码,那叫一个不忍直视,类型检查, lint 各种爆红,代码风格及其乱,像是在 AI 写的基础上二次修改,而且用 WebStorm ,和我用 vscode 配置估计都不统一。真不知道要怎么维护他的代码,一下子就感觉我脏了,被践踏蹂躏了还不能说呀咩爹。
我看完之后心里非常别扭,哎没办法,我就是一个打工的,还说代码能跑就行,要统一框架,让大家用熟悉的方式写。md 写后端邋遢就算了,问题确实也不大,本来我们团队的人也都是全栈 java + react ,前端应该只是会写的水平,但是我实在看不下去了,一想到我一手搭建的项目要生产 shi 就跟吃了一样难受,都说前端是个人都能写,有 AI 后更是把前端贬的太低了,都是一大帮后端的傲慢与偏见,我自己虽然也是一毕业就干后端,但是我依然认为写好前端,不仅仅是代码,更胜在用户体验。
看着公司表面上是融资了,蒸蒸日上,逐渐扩招,但我心里实在没个底,内部代码混乱成这样,真能把产品做好吗,都是为了快而快,就是为了挣钱这固然没错,但我始终没个底,也许我不该用过多的极客思维去看待,说不定哪天凉了或者好起来了都是个未知。或许我更应该适合自己一个人倒腾项目,哪怕是小而美,哪怕没有过多的利益,我只想用心写好每一行代码,享受写代码带来的乐趣,这也是我对编程领域的热爱,但是事实告诉我不能这样,可却又无可奈何,总得讨口饭。总想着先干两年攒点钱自己单干搞点小事业吧,毕竟 27 也还没结婚,家境不好,写代码是我能坚持为数不多的乐趣,各位有何看法。
升级后,之前能修改的方式都失效了,有没有大佬知道要怎么做才能修改啊
之前不是在这里说过 拿了一个大厂的外包岗位 offer 吗,我当时最终决定去的这个。
目前上了十多天班,感觉就是大厂原来也是个草台班子。
我是做 Java 的,一般来说,大部分公司正常的做法是 SkyWalking + 日志平台(比如 ELK )来排查问题。
这个项目组排查问题只能通过 SkyWalking 你敢信?你想通过日志打印的某个关键字来搜一下具体错误日志?对不起,没有办法。
比如,上周给我派了一个生产 BUG 让我解决,这个 BUG 是在 mq 消费过程中产生的(这个是重点)。
由于将 mq 集成到 SkyWalking 中,导致它的日志没法在 SkyWalking 中找到,取而代之的是把消费过程中发生的异常保存到 MySQL 的一张日志表中,。
我通过这张日志表排查到是一个 SQL 执行出错了,但具体的 SQL 错误信息没有,然后又因为没有日志平台,导致一个很简单的问题(如果有日志平台,直接去日志平台看一眼详细错误就知道了)花了很长时间。
最后解决办法是一张张表去看是否有生成记录(这个 mq 消费过程中会插入很多张表),如果某张表没有生成记录,那问题就发生在这张表上,最后再一个个字段去排查,发现原来是字段值超长了。。。
……
除此之外,还有很多一眼草台班子的地方
不过有一说一,有些地方还是还是做的不错的,比如各种权限管控、各种文档也比较齐全
RT
国庆节做了一个南京的旅游计划, 打算去南京玩。但如果实在抢不到高铁票的话就不去了。明天可以预定 10.1 那天的票,但因为高铁票回来的比较难抢,所以打算抢到回来的票后再去订酒店
然后回程的票估计要 22 号左右才能预定,所以顶酒店的事情必须 22 号以后才能决定
我像问下南京玄武区,200-300 这个价位的酒店,国庆节房源紧张吗?我有些担心 22 号买到票,酒店没房间或者涨价
你是否也在同时使用多个 AI 客户端? 如果是,你很可能正在浪费大量系统资源!
每个 AI 客户端都会独立启动自己的 MCP 服务器进程:
结果:同一个 MCP 服务器被重复启动 5 次,资源占用爆炸!
我开发了 1MCP,一个智能的 MCP 服务器管理器:
核心原理:
担心上下文窗口爆炸? Preset 功能完美解决这个问题!
为每个 MCP 服务器添加功能标签:
{
"context7": {
"command": "npx",
"args": ["-y", "@upstash/context7-mcp@latest"],
"tags": ["docs", "development", "code"],
"disabled": false
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"],
"tags": ["files", "storage"]
}
}
灵活的过滤器语法:
# 开发环境
npx -y @1mcp/agent preset create dev --filter "development,code"
# 安全开发(排除实验性功能)
npx -y @1mcp/agent preset create secure-dev \
--filter "development AND NOT experimental"
# 全栈开发
npx -y @1mcp/agent preset create fullstack \
--filter "(frontend AND web) OR (backend AND api)"
核心优势:
进程优化:
上下文优化: 通过 Preset 精确控制工具数量,我实现了惊人的优化:
初始状态:我的 dev-backend
预设包含 3 个服务器( 22 个工具),占用 7.5% 上下文窗口。
# 完整的预设配置详情和服务器列表 [简化显示]
$ npx -y @1mcp/agent preset show dev-backend
# 显示:3 个服务器匹配,22 个工具可用
> /context
⎿ ⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ Context Usage
⛁ ⛁ ⛁ ⛁ ⛁ ⛀ ⛀ ⛁ ⛁ ⛁ claude-sonnet-4-20250514 • 39k/200k tokens (20%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ MCP tools: 15.0k tokens (7.5%)
# [详细的工具列表和 token 占用统计已简化显示]
使用预设编辑器精简服务器:
$ mcp preset edit dev-backend
# [交互式 TUI 界面详情已简化显示]
# 选择只需要 context7 服务器
# 实时预览:1 个服务器匹配
优化后:重新连接后,效果立竿见影!
> /mcp reconnect 1mcp
> /context
⎿ ⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ Context Usage
⛁ ⛁ ⛁ ⛀ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ claude-sonnet-4-20250514 • 28k/200k tokens (14%)
⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛁ MCP tools: 2.3k tokens (1.1%)
# [精简后的工具列表显示只有 2 个核心工具]
1. 给个 Star ⭐ 如果 1MCP 对你有帮助,请在 GitHub 给个 star ,这将是我开源路上的莫大鼓励
2. 分享使用体验 在评论区分享你的 MCP 服务器管理经验和 1MCP 的使用效果
3. 提交问题和建议 遇到问题或有改进建议?欢迎提交 GitHub Issues
4. 贡献代码 欢迎提交 Pull Request ,一起完善 1MCP !
如果你也在同时使用多个 AI 客户端,1MCP 绝对值得一试!
你在使用哪些 AI 客户端?是如何管理 MCP 服务器的?欢迎在评论区交流!
大家好,我是 DHJ. 作为一名开发者,在工作和个人项目中深度使用大模型 API 的过程中,被两个问题折磨了很久:
价格乱七八糟:同一个模型,我发现不同渠道价格差很多,而且还是动态变化的。为了省钱,得经常手动去比价,然后接新渠道 ,注册、获取 key 、再对接新街口,很费劲。主要是确实没那么多时间和精力总关注不同的渠道平台。
服务不稳定:对接的某个模型渠道,会遇到渠道不稳定的情况,响应超时或者直接 503 ,导致我的应用跟着出问题,自己用着玩还行,自从我开始做出海,提供应用给客户,渠道不稳定非常痛。
为了彻底解决这两个痛点,我的团队开发了 https://evolink.ai/ ,一个智能、稳定且最具成本效益的大模型 API 聚合网关。
它是如何工作的?
高稳定性 -> 自动故障切换:你只需要调用我们的接口。我们背后聚合了同一个模型的多个顶级渠道。如果某个渠道挂了或变慢,系统会毫秒级无感切换到健康的渠道上,保证你的服务永远在线。
低成本 -> 动态价格寻优:我们的系统会实时监控所有渠道的价格,自动帮你选择当下最便宜的那个渠道来处理请求。你什么都不用做,就能一直享受到“全网底价”,把钱花在刀刃上。
简单来说,就是把选渠道、保稳定这些脏活累活都交给我们,大家可以更专注于自己的业务开发。
目前已经内测给很多用户使用了,通道非常稳定,欢迎大家来试一试。 网站内也有我们团队的联系方式,欢迎大家找我反馈你的体验、需求以及问题,作为回报,我将为您提供更加极致的 vip 价格~ 希望能帮助到需要的伙伴们~~
如题,做过以下尝试:
请问各位大佬是如何解决这个问题的呢?
1.首先是查看是否降智,通过 summarize your tool in a markdown table with availability 检查:
发现是没有降智的。
2.我的梯子的 ip 应该是荷兰的,因为 Google 页面的左下角显示的是 Netherlands 。
3.但是感觉最近买了 plus 以后,回答反而变慢了很多。
如上截图,一个问题,用了 2 分钟。 但同样的这个问题我丢给通义千问的话,人家马上就回答我了,而且回答的不错。
各位大佬,你们有出现这种情况吗?
如题,有人给 iPhone14 pro 升级到 iOS 26 吗,想问下续航怎样,操作是否流畅?我的 14p 电池健康剩 73 了,不敢直接升😂
今天看交易所网页行情无法实时更新了,还以为是代理的问题,花了一天排查,买了好几个代理都不行,最后折腾下来才发现是运营商会把 udp 丢包。现在在浏览器启动的时候加--disable-quic ,强制让 websocket 走 tcp ,解决了
背景:目前基本已经决定使用 PVE 做底层,飞牛做 SMB 和 WebDAV 服务,Debian+DPanel 跑 Docker ,OpenWRT 跑去广告和 SmartDNS 。HDD 硬盘使用 virtiofs 的方式同时挂载给飞牛和 Debian ,再通过 SMB 挂给 Windows (听说 Windows 下挂 virtiofs 还不如 SMB 高效?)
问题:由于 PVE 的回滚功能实在愉快(尤其对 Debian 而言),但是创建 thin-lvm 会导致存储卷里的数据也被回滚,在不考虑安装第二块 SSD 的前提下,所以目前在考虑两个方案:
另外还有问题:
对于 HDD 存储的数据,是否有必要从 ext4 转为 ZFS - 这意味着需要使用 TrueNAS+全盘格式化,我想知道这个投入是否有必要?
如果没有必要且继续使用飞牛,则 btrfs 和 ext4 的选择?(前者有一些数据保护的功能,后者性能更快 - 我不做任何 RAID 只冷备份,对于电影、工作文件等,应该怎么选择?)
Debian 不想安装桌面环境影响性能,有没有什么能可视化管理文件、SMB 、WebDAV 的可能?我尝试过 Cockpit 等但似乎都太复杂太重了。
我观察到飞牛或 TrueNAS 都对 SMB 有一定程度的优化(如过滤 DStore 等),如果使用 Debian 直接管理 SMB ,性能和可用性是否会弱于飞牛 TrueNAS ? - 我知道这些优化肯定都能手动实现 - 但是我有一点点不想继续增加部署的学习成本了(虽然真的很好玩)。。。
任何输入和见解都感激不尽!
前段时间我在 v 站推广了自己写的 AI 内容平台后湖,这次介绍一个新开发的好玩功能,它能够让你身临其境的体验一个知识点,而不是阅读枯燥的讲解叙述。
先介绍一下后湖:
后湖是一个知识内容平台,在这里用户不会得到被动的信息推送,而是主动输入感兴趣的知识节点,然后由 AI 为用户创作相应内容。
在这个过程中,AI 不仅负责内容生成,还会辅助用户不断扩展新的知识节点,实现知识发现的链式反应。
最简单的例子:用户输入 [《长安的荔枝》] ,AI 扩展出 [“杨贵妃与荔枝”,“唐代物流运输系统”] 等节点,然后围绕每个节点生成内容
更多的说明可以看:
在第一个版本中,AI 生成的内容只是 200 字左右的短文,很多用户反馈内容太浅显。这次的新功能,就是对生成的短文进行扩展。
扩展有四种模式,前两种是基础功能:
有趣的是后面两种:
借助互动游戏的形式,很多知识都变得鲜活起来。
如果想体验这项功能,可以点击这个链接进入后湖:
可以通过下面的公众号获取后湖的相关资讯,或者找我交流~
有人能说说吗?这个骗局吗?