©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: join.nostr.moe
#吐槽

In reply to nevent1q…lp40
_________________________

事实证明人不怕机器. 人怕人, 更怕操纵机器的人.

如果 ATM 机里面是人类, 这样本质上和钢化玻璃背后坐一个柜员没区别, 但是对人心理上是个很大的负担. ATM 和额外带有自助的业务电脑正常的翻译是「自动柜员机」, 基本上就是银行业早期引入自动化的时候和人类柜员的认知作过渡然后一直沿用至今的名词, 但如今我认识的人除了银行职员没人会把 ATM 叫做柜员机, 只会叫做取款机, 最多会在形容只能办理业务无法取款的银行机器的时候才会搬出这个词.

人只会承认机器具有人类的业务能力, 不会轻易就认为机器是因为有人类的意识才能有的业务能力. 如今的机器和人工智能还只是学会了最基本的预测, 预测像素周围应该是什么像素, 就有了绘画模型, 预测一个 token 后面可能是什么 token, 就有了对话模型. 类似的还有自动售货机, 小时候也会有笑话说自助贩卖机里面其实装的是人, 也只有人当作是笑话. 现在, 人投进去提示词, 取出来生成物, 这是种数据自动贩卖机, 甚至不需要 "补货".

后来, 人开始变得像机器, 开始和虚拟融合, 第一个开始的到如今大多数活跃的虚拟偶像一样, 背后还是人.
quoting
nevent1q…3vjp
这场资本的试验结论是, 最好一开始虚拟形象的背后就不是人, 要给人工智能造皮套, 而不是给皮套造人工智能.
https://www.bilibili.com/video/av641552244
人会因为吃了包装巧克力就会爱上巧克力流水线上的工人吗? 如果这条流水线永远只有一个工人呢? 有人会爱上食品工业化后的巧克力, 也会有爱上生产工业食品的流水线机械, 没有人会去真正爱为了维持流水线流动的人, 等到巧克力不再生产或不再畅销, 流水线停运, 工人就下岗了. 还会有人去爱可可果和可可豆吗? 或者会有人会去爱被氢化前的那些植物油吗? 现在好了, 我这个人这个星期吃代可可脂吃到几乎食物中毒了, 没办法去爱那些植物油了.

人已经可以信任机器了, 人已经发明了各种东西确保人机之间的信任, 还耗费无数人力去维护和生产新机器. 人和人之间的信任没办法比人机的信任建立地更快更牢固了, 现在还有要求人直接或间接交出密钥而确保人与人之间信任, 没有人会为了更好的世界主动交出自己的密钥, 更不能接受自己的数据在加密前就被扫描. 在 AGI 之前, 人只会怕有人用机器取代自己, 但人不能毁掉人, 只能毁掉机器, 或毁掉生产机器的流水线. 现在, 轮到人开始害怕机器自己思考自己行动了, 然后做到不再需要人的指挥就能完成对人的价值取代. 总有一天, 抗人工智能计算的难度要超过抗量子计算, 既要防人还要防机器, 真的很麻烦.

via Nostr@cxplay
#article #read

AI 购物应用 CEO 被控欺诈,AI 的背后其实是人

AI 购物应用 Nate 的创始人、前 CEO Albert Saniger 被控欺诈投资者。Nate 成立于 2018 年,从 Coatue 和 Forerunner Ventures 等投资者筹集了逾 5000 万美元,2021 年完成了由 Renegade Partners 领投的 3800 万美元 A 轮融资。Nate 声称,在 AI 的帮助下其应用的用户只需点击一下即可在任何电商网站上购物。但起诉书指出,Nate 实际上严重依赖菲律宾呼叫中心的数百名合同工手动完成购买操作。Saniger 声称 Nate 能“无需人工干预”进行在线交易,除非出现 AI 无法完成交易的极端情况。但美国司法部称,尽管 Nate 获得了一些 AI 技术并聘用了数据科学家,但其应用的真实自动化率实际上为 0%。
美国司法部的 起诉书 称,Nate公司资金耗尽,于2023年1月被迫出售资产,导致其投资者“几乎全部”损失。Albert Saniger的领英个人资料显示,他自2023年起不再担任首席执行官。

- https://www.solidot.org/story?sid=81028
- https://techcrunch.com/2025/04/10/fintech-founder-charged-with-fraud-after-ai-shopping-app-found-to-be-powered-by-humans-in-the-philippines/

#AI

via Nostr@cxplay_clip
#吐槽

我知道我为什么讨厌宋体了, 实际上是在讨厌某些宋体的 "字形" 设计. 喜欢楷体的时候, 某些字形设计的楷体也变得很难看, 还是都说不上喜欢.

方正书宋 - 方正字库
https://www.foundertype.com/index.php/FontInfo/index/id/151

之前, 衬线体喜欢方正书宋, 然后是正楷, 现在喜欢思源的宋体. 霞鹜文楷很多人都喜欢用, 可能主要还是因为是开源的字体, 然后字形相对宋体更饱满, 比正楷又更活泼. 但我现在还是比较喜欢思源的宋体, 不是很喜欢这种调和状态的字形.

#design #font

via Nostr@cxplay
AnyViewer 使用兑换码 8297-3F39-6C61-7A1D 再得一年专业版订阅. #羊毛

via CXPLAY's Memos
Paas 平台 ClawCloud Run 提供每月免费 5USD 额度

ClawCloud Run 是 ClawCloud 推出的 PaaS 平台. 免费注册可获取包含一次性的 5 USD 额度免费层计划, 使用注册时间在 180 天以上的 GitHub 账户注册登录可以获取额外的每月 5 USD 的额度. 计费计划包含每个月与套餐计费相同的计算资源额度, 更高的层级能够使用更多的 vCPU 和 RAM.

基础设施

无月费的免费(Free)计划存在明显的资源限制, 只能使用最多 4 个 vCPU 和 8GB RAM, 而流量和磁盘均被限制在极低的 10GB, 且只能创建 1 个工作区. 而 5 USD 和 20 USD的爱好(Hobby)和专业(Pro)计划都可以消费无限量的流量和磁盘资源.

计算资源计费均按分钟计费, 总体价格为:

● vCPU: 4 USD / 月
● RAM: 2 USD / GB / 月
● 磁盘: 0.12 USD / GB / 月
● 流量: 0.05 USD / GB / 月

注册区域与工作区内的可用计算资源的网络位置直接关联, 可选的注册区域包括: 新加坡, 美国东部, 德国, 美国西部, 日本. 内部和外部网络和 ClawCloud 的经典虚拟服务器相同, 均为阿里云.

● 演示站点: https://clawcloudrun-jp-demo.autoconfiguration.eu.org/

注册

通过推荐新用户注册, 每达成 5 个新用户注册邀请人可获得 1 个月的价值 5 USD 的 Hobby 计划, 最多邀请 300 位新用户获取最多 60 个月的 Hobby 计划.

主页: run.claw.cloud
邀请注册: https://url.cx.ms/clawcloudrun

#PaaS #羊毛

via CXPLAY's Memos
#吐槽

In reply to nevent1q…jg20
_________________________

虽然 NIP-68 里面没有要求 imeta 标签是谁提供, 但目前大多数支持这个 NIP 的客户端好像都是默认在客户端计算的元数据. 不管媒体文件服务器提不提供元数据, 所有的客户端都在自己计算元数据.
而 NIP-68 里面的 imeta 示例相比 NIP-94 的实例正好缺了 origin hash 标签 "ox", 这个标签也只有在媒体服务器提供服务端媒体优化的时候才会提供. 现在一看 NIP-68 没有了, 是不是就在默认元数据的处理是客户端的责任?
那如果一个 kind:20 事件只有 .content, 其他的 .tags.* 一律没有, 这个 kind:20 事件还算是有效的吗? 在这个自由网络里面, 应该也最多算是不佳实践? 会有中继会针对 kind:20 过滤掉不包含 imeta 标签的事件吗?
quoting
nevent1q…k07m
NIP-68 - Picture-first feeds
https://nips.nostr.com/68

既然 NIP-68 都出现了, 原本就是 kind:1 的功能越来越被细分, 要求也变得越来越细致. 那为什么一个事件不能有多个 kind 呢?🙂本身就可以视作是 kind:1 的子集, 客户端也不会因为只支持 kind:1 而不支持显示 NIP-68 吧?


via Nostr@cxplay
#吐槽

In reply to nevent1q…3t9e
_________________________

另外, 现在在 Nostr 批量上传媒体文件体验很差. 不管是 NIP-96 还是 Blossom 兼容的客户端体验都很差, 多图的事件更需要文件元数据特别是长宽信息让客户端预先绘制出视图.
但现在要发很多图片的话, 要么一张一张选择然后慢慢上传, 要么提前上传得到图片链接一次性全部插入然后丢失文件元数据. 而 Blossom 的 BUD-08 还没有全面普及, 用 Blossom 基本上就意味着元数据默认缺失.

所以, 为什么所有客户端都不会去主动计算媒体文件特别是图片的元数据?

via Nostr@cxplay
#吐槽

In reply to nevent1q…sytg
_________________________

为什么所有的 NIP-94 实现都仅出现在服务端上, 特别是 NIP-96 服务器. 真的只有服务端才能计算文件的元数据吗? 为什么不在客户端上完成这一过程? 如果我插入一张随机的网络模因图片是不是就意味着我就永远无法添加这些对客户端很有意义的元数据了(除非我考虑手动编写事件 JSON)?
据我所知, 用于 Torrent 索引的 NIP-35 的所有文件元数据都是客户端提供的, 用户甚至能自己填写, 但不知为何在 NIP-96 身上就变成了仅服务器的事务了.

via Nostr@cxplay
#吐槽

Why are all the NIP-94 implementations server-side only, especially the NIP-96 server, and is it really only the server that can compute the metadata for a file? Why isn't this process done on the client side, and if I insert a random network memes does that mean I'll never be able to add the metadata that makes sense to the client (unless I consider writing event JSON manually)?
As far as I know, all the file metadata for the NIP-35 for Torrent indexing is client-supplied, and users can even fill it in themselves, but somehow it's become a server-only affair with the NIP-96.

#nostr #asknostr

via Nostr@cxplay
#吐槽

NIP-68 - Picture-first feeds
https://nips.nostr.com/68

既然 NIP-68 都出现了, 原本就是 kind:1 的功能越来越被细分, 要求也变得越来越细致. 那为什么一个事件不能有多个 kind 呢?🙂本身就可以视作是 kind:1 的子集, 客户端也不会因为只支持 kind:1 而不支持显示 NIP-68 吧?

via Nostr@cxplay
#吐槽

njump 又把数据库切回了 badger, 然后问题就消失了. 自定义实例已经合并上游更改了, 本地测试也通过了, 目前暂未出现问题.
https://github.com/fiatjaf/njump/commit/91ed172f56c4775705c922b5f5888be71644a5d8
quoting
nevent1q…sy3x
LMDB 切换之后似乎从本地数据库请求事件出了点奇怪的问题... 暂时切换成了完全即时从中继获取, 现在的新 SDK 支持发件箱模型了, 但还得观察一段时间.


via Nostr@cxplay
#吐槽

In reply to nevent1q…ugaw
_________________________

I think most of the reason is that the overhead of replacing these DNS-related components is greater than the overhead of replacing the DNS itself. If there is a DNS replacement, it has to be able to coexist with DNS for a long time and be ready to replace it for at least half a century. IPv6 is in this slow and painful process today.

via Nostr@cxplay
#吐槽

In reply to nevent1q…vydp
_________________________

Nostr can't change the status quo unless DNS and all its associated infrastructure is replaced. If you can't beat them, join them.

via Nostr@cxplay
Back to Top